Upgrading an Ancient FC14 to Fedora 24

Having successfully completed a recent Fedora 23 installation to an aging netbook, I started to grow frustrated with my ~6 year old aging Fedora Core 14 installation from 2010. The annoyances I faced with my 2010 desktop installation was the lack of upgrade paths for many of the useful daily software components and the aging desktop environment.

With the ease and painless install of Fedora 23, I wondered if the FC14 system could also be easily replaced. Obviously there were some complications.

The first problem/laziness factor was my current home area on FC14 was littered with too many utils/docs/files that I just didn't want to have to backup and reinstate so I wanted any new installation to be able to preserve some of the existing LVM partitions: standard locations (root, /usr and /var could all go though)

The second problem was the way the system was built: the machine had 2 disks installed with first (factory shipped) disk containing the original Windows 7 installation and the second (aftermarket) disk containing the FC installation. However, the grub boot loader was ONLY installed to the second disk to isolate both OS: booting to linux, I force the BIOS boot selection at startup to boot from the second disk and thus invoking grub. I didn't want any new installation to change the bootloader setup.

Windows Rescue Disk

The system was shipped with Windows 7 pre-installed and there were no installation or rescue media supplied. However, to ensure that I would have some safety I wanted the option to fix Windows bootloader problems. Fortunately Windows 7 provides a way to create a bootable rescue CD (for some reason the Dell Vostr 430, even with latest 2.4.0 firmware, does NOT boot from USB devices):

start Backup and Restore
select from left hand panel Create a System Repair Disk

A CD is burned and bootable. On the disk, the bootrec tool is available where you can use the bootrec /FixMbr or bootrec /FixBoot to attempt to rewrite the Windows 7 bootloader. Other resources suggest that syslinux's MBR file can also restore/fix a Windows 7 bootloader.

Install Fedora

To install Fedora 24, I burned the(~500MB) netinstall image to CD (see the note above regarding Dell's inability to boot from USB) and booted - the netinstall image has the advantage of not requiring post install updates as the main system pkgs are downloaded from a Fedora site but it does mean a longer install and secondly the installation stage allows you to select the installation type (Workstation/Server) and then also the variation of installations such as the desktop environment and some control of pkgs (the compiler suite for instance that would not typically installed from a live image). Note the netinstall is not a live image and you can not try out the system: it is only to provide an install.

When the CD system booted it provides an option for disk partitioning. This is the important option for my first requirement. Selecting manual partition will force the installer to scan for existing partitions and it successfully found all of my FC14 partitions (LVM and standard partitions). As the LVM previous installation named the logical volumes (vg/lv_root, vg/lv_usr etc) it was sensible to use the same LVM partitions for the new installation. At this point I was able select the existing partitions and chose to have these partitions (/export/home for instance) to be made available on the new installation: the installer will ask, given a select existing partition, where you wish to mount this on the new installation.

At this stage, you are also able to extend/reduce the size of LVM partitions. Following the full installation (plus various additional pkgs) the system disk utilisation looked like this:

Filesystem Size Used Avail Use% Mounted on
devtmpfs 5.9G 0 5.9G 0% /dev
tmpfs 5.9G 4.1M 5.9G 1% /dev/shm
tmpfs 5.9G 1.4M 5.9G 1% /run
tmpfs 5.9G 0 5.9G 0% /sys/fs/cgroup
/dev/mapper/vg_lv-root 976M 112M 798M 13% /
/dev/mapper/vg_lv-usr 24G 6.4G 16G 29% /usr
/dev/mapper/vg_lv-export 146G 70G 70G 50% /export
/dev/sdb7 934M 173M 698M 20% /boot
/dev/mapper/vg_lv-var 2.0G 346M 1.5G 19% /var
/dev/mapper/vg_lv-tmp 976M 589M 320M 65% /tmp

You can shape your system accordingly, although with LVM you can resize later.

One note however was the /boot partition had been kept off the LVM and was only 128Mb. This based on my recent Fedora 23 installation experience (/boot required about 190Mb) was going to be too small but luckily I had a separate swap partition (also not on LVM) that was larger and could be used as the new /boot partition.

Which partitions to format

I had the installer format /boot, /, /usr and /var. For /var, the older FC14 used a /var/run directory but Fedora 24 expects a symbolic link /var/run -> ../run. If /var is not formatted, the system will boot and complain that the logind service has failed along with many other services - the system will take a long time before presenting you a login prompt. If this happens, you will need to remove /var/run and create the symbolic link and reboot to resolve this problem.

boot loader

At the completion of installation, the installer wrote the boot loader without any prompting or options which made me slightly nervous.

However when the system rebooted, I observed the installer had written the grub bootloader to the second disk (the Fedora installation) and left the first disk (Windows 7 installation) alone!!! Exactly what I needed.

Post Install

Upon the reboot, I followed my previous self help instructions here and here to install the relevant additional pkgs and setup NFS, the NIS server on this host etc and to reset the machine to have a static IP (DHCP was use in the install to avoid me introducing gateway/routing issues).

Additionally, if you forgot to set the hostname during the install, this can be fixed: hostnamectl set-hostname foo

In all, the upgrade from a really old FC14 installation to Fedora 24 was reasonably flawless.

Post Install: nVidia

The graphics support seemed perfectly fine out of the box. However I wanted to use nVidia's proprietary driver over the system provided. The main problem is that the system loads at boot time the 'nouveau' driver which is incompatible/causes problems with nVidia: to install you have first disable the nouveau driver.

A more complete Fedora nVidia installation guide is available here but the summary steps:

• download the nVidia driver - get 367.35 onwards due to the changes in the linux 4.x kernel header prototypes
• ensure you have all the compiler tools:
  dnf -y install gcc kernel-devel
• blacklist the nouveau driver to avoid post boot load:
  echo "blacklist nouveau" >> /etc/modprobe.d/blacklist.conf
• modify the boot option to disable initial nouveau driver load and force the system into multiuser mode (no X). Boot and at grub screen, edit the linux boot params to add:
  rd.driver.blacklist=nouveau 3
  to the line starting linux16 /vmlinuz
  
• with booted system, verify nouveau is not loaded and then start the automated nVidia build/install:
  lsmod | grep nouveau # should return nothing
  chmod +x ./NVIDIA-Linux-x86_64-367.35.run && ./NVIDIA-Linux-x86_64-367.35.run
  telinit 5


• If all is successful, make the grub options permanent:
  /boot/grub2/grub.cfg
  linux16 /vmlinuz-... rd.driver.blacklist=nouveau vga=837
  
  /etc/sysconfig/grub
  GRUB_CMDLINE_LINUX="... rd.driver.blacklist=nouveau vga=837"
  


• install the VDPAU h/w accelerated video decoding libraries:
  dnf -y install vdpauinfo libva-vdpau-driver libva-utils
  Additionally, force mplayer to use VDPAU:
  # ~/.mplayer/config
  vo=vdpau,
  vc=ffh264vdpau,ffmpeg12vdpau,ffodivxvdpau,ffwmv3vdpau,ffvc1vdpau
  Playing back full HD (1080p) files results in 1.2-1.7% CPU utilisation (according to top). Using -vo xv or -vo x11 with -vc ffh264 results in CPU usage of 17-30%. Surprisingly, vlc that has menu options to enable h/w decode acceleration (VDPAU in this case) runs the CPU closer to 40%! For mplayer, forcing the VDPAU video output driver and using the VDPAU ffmpeg h264 video decoder is a big improvement.
  

Kernel updates require the modules to be recompiled.

./NVIDIA-Linux-x86_64-367.35.run -a -K -k non running kernel name

The name of the newly installed kernel can be inferred from /lib/modules such as 4.7.2-201.fc24.x86_64 which would be the arg for -k param above.

Post Install: vmware

Install is easy from vmware's own website, although it's now only available as 64bit. The 'product' pages are sometimes out of date from the latest available versions which can be found the My VMware pages. Whilst the VWware Workstation download contains the (free) VWplayer, the latter is also available as a downloadable and is 3x smaller. Kernel updates require the vmware modules to be recompiled:

vmware-modconfig --console --install-all

Post Install: Interfacing with Synology DSM 4.x NFSv3 only

I have various other linux NFS servers that I access and one of them is a old synology NAS running DSM 4.2 (based on a 2.6.32.x kernel). The F24 installation by default is set up to try NFSv4 when mounting/automounting the remote NFS but this fails with the Synology NAS: looking at the automount, you will see the remote dirs but you can not traverse then. Mounting directly (using NFSv4 options) will result with mount.nfs: mount system call failed and NFS: nfs4_discover_server_trunking unhandled error -22. Exiting with error EIO in the system logs. It is clear there are some issues with NFSv4 on the Synology NAS. Manually mount you can force the NFS mount to always try NFSv3; manual mounts can be verified by specifying -o nfsvers=3 and for autofs you can fix in the /etc/nfsmount.conf needs to be updated specify Defaultvers=3 or mountvers=3. Fixing the problem on the synology server side requires you explicitly disabling NFSv4 via the nfsd during the rc.d NFS launch scripts. /usr/syno/etc/rc.d/S83nfsd.sh

/usr/sbin/nfsd -N 4 $N ## don't supprt v4 /bin/mkdir -p /var/lib/nfs/sm /usr/sbin/mountd -V 3 -p 892 ## limit mounts to v3 too /usr/sbin/statd

and then restart /usr/syno/etc/rc.d/S83nfsd.sh restart. rpcinfo will confirm.

Post Install: HP network printer/scanner setup

Setting up a scanner is relatively simple via the HP Linux imaging and Printing system, hplip.

$ dnf -y install hplip hpijs libsane-hpaio hplip-libs hplip-common $ hp-probe -bnet # request scan of network for responding HP printers $ hp-setup -i 192.168.0.250 # ip address of your printer from probe

^{the libsane-hpaio is for the CUPS PDD file} Once HP setup is completed starting simple-scanis relatively flawless, allowing simple scanning and saving multi page scans to PDF or jpeg. At this point, a CUPS supported network printer should also be available. Scanning using a HP M1217nfw MFP is typically problem free, although sometimes the scanning utils don't see the printer but a power cycle or the printer usually clears down whatever bug is in the current software packages. If you require other scanners, the sane backend can also be installed and used (sane-backends, sane-backends-drivers-scanners andxsane) Sometimes I come across problems where the previously working scanner complains that it does not recognise the scanner and needs to update the binary driver but fails to download; the binary drivers can be found OpenPrinting - you will need both the .run and the .run.asc file and enter locations during the installation wizard.

Post Install: openning/securing SSH for external SFTP upload

This linux box will intermittently be available on the internet to provide SFTP access for one user only who is not allowed to login (default shell /bin/nologin) and belongs to a special group sftpusers; no other user or SSH service will be allowed remote/internet originated access for security - the gateway will forward traffic to this box via NAT. All users will continue to have ALL SSH/SFTP access to the box from the internal network (198.168.*) but only the SFTP user will be allowed from the outside and only for SFTP. Additionally, all users will continue to use passwords except for the SFTP user who will only permitted to authenticate via SSL key/cert which additionally will have a passphrase. The SSL ~/.ssh/authorized_keys file must be 0600 and the home dir of the SFTP user must be 0700 otherwise the client connection will be dropped with Permission denied (publickey) error. The SFTP user will also be jailed to a specific dir (all paths up to and including the chroot must be owned by root) to further protect the machine. The following lines must be added to the end of the SSH config file due to the Match directives.

# /etc/ssh/sshd_config # force umask for file creations on upload Subsystem sftp internal-sftp -f DAEMON -u 0133 # restrict origin of connections for users AllowUsers *@192.168.* sftp@* # restrict root login from internal network (overkill due to AllowUsers) PermitRootLogin no Match Address 192.168.*.* PermitRootLogin yes Match User root X11Forwarding no AllowTcpForwarding no # restrict user to key/cert auth and chroot jail Match User sftp PasswordAuthentication no ChrootDirectory /export # drop user into dir relative to the chroot jail # ForceCommand internal-sftp -d incoming

For investigating setup errors, the sshd daemon can be run in a root session with "-d -e" flags and the ssh client (ssh or sftp) can add "-vvv" to its argument list; particularly useful to debug/identify the strict file and folder permissions required at the server side.