![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Slackware forklift upgrade
Dec. 11th, 2018 07:21 pmI have been running Slackware 14.1 (with security patches) for several years now and it has been rock solid (it even survived a power supply failure without so much as a scratch). The time has come to upgrade to Slackware 14.2 and then Slackware-current because I need features that are only available in newer packages (e.g. PHP). It's time, and has been for a while, but I have been resistant because I know it's going to be more of a lifestyle while I do it than a project. I installed a pair of new terabyte drives into the server yesterday and it went startlingly smoothly (with a caveat regarding device naming, which I now need to fix, but that will be the first task). My plan is to do a fresh install of 14.2 on the new disks after I partition and mirror everything, and just leave the 14.1 install on the older mirrored terabyte drives so I can always switch back if needed (or at least that's the theory, I can imagine all kinds of things going horribly wrong... again, a reason why I have been procrastinating on this).
So, the first thing that happened is when I plugged in the new drives (into SATA ports 3 and 4, where the existing drives are in ports 1 and 2) and when I booted, it renamed the old drives from /dev/sda and /dev/sdb to /dev/sda and /dev/sdc, and added the new disks as /dev/sdb and /dev/sdd. The LVMs and RAID stuff seems to figure it out fine on its own because it seems to use the UUID to figure out which is which, but I had set up a swap partition on /dev/sdb2 and that is obviously not working (the other swap partition on /dev/sda2 [non-mirrored of course] was found). Ugh. There is a Slackware-specific page on device naming, so off to read it and see if I can come up with a plan to fix the naming.
So here is the current partition setup for both old drives (just substitute sda for sdc for the other drive):
Going on the assumption that the RAID and LVM stuff will automagically figure themselves out (so far so good), I went ahead and partitioned the system: a mirrored boot partition (I doubled its size to 200MiB since it was at 64% with two kernels on it on the old disks), a swap partition (unmirrored, 8GiB), a mirrored 80GiB root partition (I was only at 27% on the old disks with the root partition of the same size), and the last primary partition is also mirrored and will be used for LVM volumes. Did it on both sdb and sdd.
Because I already have four RAID devices on my old disks, I created the new RAID devices as 4 through 6. The name is very important! Not the first part (it can be anything, I used "slackware" here), but the colon and the number are critical. The number after the colon is used by Slackware to ensure that the devices are renumbered dynamically after a reboot (which would muck things up pretty bad if you were using the md# to access the drive, although you could use the "/dev/disk/by-uuid" or something to get around that... it's still distasteful to me that the numbers change without the naming convention, so this works for me and keeps me happy). Only the first partition, the "/boot" partition, needs to have the RAID metadata at version "0.90" to maintain compatibility with LILO (which can't understand more recent metadata versions).
Next, I needed to update all the packages to the latest versions to make sure any known security issues were addressed. I did this from the rebooted Slackware 14.2 system. I edited the "/etc/slackpkg/mirrors" file and uncommented the closest mirror to me (only uncomment one line!) for the slackware-14.2 release stream (I decided not to go to Slackware-current since I want maximum stability, there is a list for each of the major release streams in the mirrors file). Then to upgrade everything at once (since I'm lazy and the system wasn't doing productive work so it was not a big deal if I borked anything):
Next up: migrating all of my configurations from my old drives to the new drives, moving the databases over, getting the web server running, getting Samba going, getting CUPS running, etc. ad nauseum. I will keep careful records of what I do, but won't be sharing it here (hopefully this stuff will help someone, but I can't imagine that stuff being of much use).
Today, instead of a video, I'd like to share an album I listened to on the way to/from my work trip on the plane. It is called "Light of the Fearless" and it's by the UK electronica group Hybrid. I've been enjoying the heck out of it! You can really tell they've been doing movie and video game soundtracks the past eight years. The Prague Philharmonic Orchestra certainly adds a certain amount of epic as well... Oh, and the last track was a bit of surprise: a cover of a Tom Petty song, but what a cover and a half, wow!
So, the first thing that happened is when I plugged in the new drives (into SATA ports 3 and 4, where the existing drives are in ports 1 and 2) and when I booted, it renamed the old drives from /dev/sda and /dev/sdb to /dev/sda and /dev/sdc, and added the new disks as /dev/sdb and /dev/sdd. The LVMs and RAID stuff seems to figure it out fine on its own because it seems to use the UUID to figure out which is which, but I had set up a swap partition on /dev/sdb2 and that is obviously not working (the other swap partition on /dev/sda2 [non-mirrored of course] was found). Ugh. There is a Slackware-specific page on device naming, so off to read it and see if I can come up with a plan to fix the naming.
So here is the current partition setup for both old drives (just substitute sda for sdc for the other drive):
Device Boot Start End Blocks Id System /dev/sdc1 * 2048 206847 102400 fd Linux raid autodetect /dev/sdc2 206848 8595455 4194304 82 Linux swap /dev/sdc3 8595456 176367615 83886080 fd Linux raid autodetect /dev/sdc4 176367616 1953525167 888578776 5 Extended /dev/sdc5 176369664 344141823 83886080 fd Linux raid autodetect /dev/sdc6 344143872 1953525167 804690648 fd Linux raid autodetectThe mirroring scheme is as follows ("cat /proc/mdstat"):
md3 : active raid1 sdc6[1] sda6[0] md2 : active raid1 sdc5[1] sda5[0] md1 : active raid1 sdc3[1] sda3[0] md0 : active raid1 sda1[0] sdc1[1]And my "/etc/lilo.conf" file is:
lba32 # Allow booting past 1024th cylinder with a recent BIOS boot = /dev/sdb append=" vt.default_utf8=0" prompt timeout = 50 vga = normal image = /boot/vmlinuz-generic-3.10.17 initrd = /boot/initrd-3.10.17.gz root = /dev/md1 label = Linux-3.10 read-only # Partitions should be mounted read-only for checkingI remember that what I did was set "boot=/dev/sda" and ran "lilo" then set "boot=/dev/sdb" and ran "lilo" again so the BIOS could boot either of the disks (LILO was installed on both disk's MBRs). One of the things that doesn't help is that LILO seems to be abandonware at the moment. On the flip side, it just seems to work well with a couple of caveats. The main issue is that it doesn't support the modern versions of the RAID metadata from what I can understand, so the RAID drives need to be created with metadata version 0.9 (1.2 seems to be the current version). Not an issue, and this is no change since I last installed Slackware. The repository seems to be at http://elilo.sourceforge.net.
Going on the assumption that the RAID and LVM stuff will automagically figure themselves out (so far so good), I went ahead and partitioned the system: a mirrored boot partition (I doubled its size to 200MiB since it was at 64% with two kernels on it on the old disks), a swap partition (unmirrored, 8GiB), a mirrored 80GiB root partition (I was only at 27% on the old disks with the root partition of the same size), and the last primary partition is also mirrored and will be used for LVM volumes. Did it on both sdb and sdd.
Device Boot Start End Blocks Id System /dev/sdb1 * 2048 411647 204800 fd Linux raid autodetect /dev/sdb2 411648 17188863 8388608 82 Linux swap /dev/sdb3 17188864 184961023 83886080 fd Linux raid autodetect /dev/sdb4 184961024 1953525167 884282072 fd Linux raid autodetectTo see the UUIDs used by the RAID system, use the command "/sbin/mdadm -E -s". It also shows the numbering scheme for the "/dev/md*" devices. Putting around, it does seem that RAID and LVM systems don't use device numbering, but actually look at the disks for their unique identifiers. Marvy!
Because I already have four RAID devices on my old disks, I created the new RAID devices as 4 through 6. The name is very important! Not the first part (it can be anything, I used "slackware" here), but the colon and the number are critical. The number after the colon is used by Slackware to ensure that the devices are renumbered dynamically after a reboot (which would muck things up pretty bad if you were using the md# to access the drive, although you could use the "/dev/disk/by-uuid" or something to get around that... it's still distasteful to me that the numbers change without the naming convention, so this works for me and keeps me happy). Only the first partition, the "/boot" partition, needs to have the RAID metadata at version "0.90" to maintain compatibility with LILO (which can't understand more recent metadata versions).
mdadm --create /dev/md4 --name=slackware:4 --metadata=0.90 --level=1 --raid-devices=2 /dev/sdb1 /dev/sdd1 mdadm --create /dev/md5 --name=slackware:5 --level=1 --raid-devices=2 /dev/sdb3 /dev/sdd3 mdadm --create /dev/md6 --name=slackware:6 --level=1 --raid-devices=2 /dev/sdb4 dev/sdd4If you need to stop and modify a RAID device, you can use, e.g. "mdadm --stop /dev/md4", and if you need to start it again, there is no "start" option and you have to use something like "mdadm --assemble /dev/md4 /dev/sdb1 /dev/sdd1". Then it was time to create the "/boot" and root "/" filesystems:
mkfs.ext4 -L boot /dev/md4 mkfs.ext4 -L root /dev/md5Then, I created and populated an LVM on the last partition (just showing one example of one logical volume called "lvdbase" in the "vgexp01" volume group):
pvcreate /dev/md6 vgcreate vgexp01 /dev/md6 lvcreate --name lvdbase --size 10G vgexp01 mkfs.ext4 -L dbase /dev/vgexp01/lvdbaseAfter that was all done, I installed Slackware 14.2 on the system (indicated that "/dev/md4" should be mounted as "/boot" and that "/dev/md5" should be mounted as "/" so it knew where to put stuff). The trick was, after it was installed, to get it to boot. I had done it before and had my notes, so it wasn't as horrific as last time. The thing that needs to be done is to make an "initial RAM disk" (initrd) and load it as part of the boot process so it has the information it needs to load on mirrored RAID disks and such. Booting off the installation DVD, here's what I had to do:
mount /dev/md5 /mnt mount /dev/md4 /mnt/boot cp /proc/partitions /mnt/proc/partitions cp /mnt/etc/mdadm.conf /mnt/etc/mdadm.conf.orig mdadm -E -s > /mnt/etc/mdadm.confThe last command there is important because it ensures the RAID device numbering is consistent during the boot process (otherwise it gets names like /dev/md123 and nobody wants that). It gets included into the initrd.gz file. The next thing to do is edit the /mnt/etc/lilo.conf file, here's what mine looked like:
boot = /dev/sdb # And then /dev/sdd bitmap = /boot/slack.bmp bmp-colors = 255,0,255,0,255,0 bmp-table = 60,6,1,16 bmp-timer = 65,27,0,255 append=" vt.default_utf8=0" prompt timeout = 50 vga = normal image = /boot/vmlinuz initrd = /boot/initrd.gz root = /dev/md5 label = Slackware14.2+ read-only # Partitions should be mounted read-only for checkingThen, make the initial RAM disk (on Slackware 14.1 I had to tell it to include the ext4 module with "-m ext4", but it is already loaded on Slackware 14.2 so I didn't have to use it) and install the boot information with LILO:
chroot /mnt mkinitrd -R -f ext4 -r /dev/md5 chroot /mnt lilo -v -v -vEdited the "/mnt/etc/lilo.conf" file to change the boot line to "boot = /dev/sdd", then ran LILO again the same way. I use a static IP address for my server, so I had to add the nameservers to use to the /mnt/etc/resolv.conf file, and for some reason, the installation stuff didn't add the gateway to the configuration, so I had to add my router's IP address in the GATEWAY line for my Ethernet interface in the "/mnt/etc/rc.d/rc.inet1.conf" file. Rebooted and everything worked.
Next, I needed to update all the packages to the latest versions to make sure any known security issues were addressed. I did this from the rebooted Slackware 14.2 system. I edited the "/etc/slackpkg/mirrors" file and uncommented the closest mirror to me (only uncomment one line!) for the slackware-14.2 release stream (I decided not to go to Slackware-current since I want maximum stability, there is a list for each of the major release streams in the mirrors file). Then to upgrade everything at once (since I'm lazy and the system wasn't doing productive work so it was not a big deal if I borked anything):
slackpkg update gpg slackpkg update slackpkg upgrade-allThe documentation said to run "slackpkg clean-system". I will read a bit more then figure out if I want to or not. The upgrade installed a new kernel. The one on the ISO image was 4.4.14, and the one installed after the upgrades was 4.4.157! So... I had to regenerate the initrd and re-run LILO. I did the following (I had to specify the kernel number to mkinitrd explicitly because it was not the kernel that was running):
rm /boot/initrd.gz rm -rf /boot/initrd-tree mkinitrd -R -f ext4 -k 4.4.157 -r /dev/md5 lilo -v -v -vAnd then changed the boot line in "/etc/lilo.conf" to "/dev/sdb" again and re-ran LILO one more time. Everything booted and everything seems in good shape.
Next up: migrating all of my configurations from my old drives to the new drives, moving the databases over, getting the web server running, getting Samba going, getting CUPS running, etc. ad nauseum. I will keep careful records of what I do, but won't be sharing it here (hopefully this stuff will help someone, but I can't imagine that stuff being of much use).
Today, instead of a video, I'd like to share an album I listened to on the way to/from my work trip on the plane. It is called "Light of the Fearless" and it's by the UK electronica group Hybrid. I've been enjoying the heck out of it! You can really tell they've been doing movie and video game soundtracks the past eight years. The Prague Philharmonic Orchestra certainly adds a certain amount of epic as well... Oh, and the last track was a bit of surprise: a cover of a Tom Petty song, but what a cover and a half, wow!
