Typing this from a new computer
Last week I upgraded my computer changing everything except the hard drives. I’m typing this text from the new system already, having migrated my Linux installation to it, and having reinstalled Windows.
I always thought my previous system ran close to perfection, and the only reason for the upgrade was gaming. I wanted a new graphics card and, with it, I didn’t want other part of the system to be a performance bottleneck, so I ended up upgrading it almost completely. I’m now using an Intel Core i5-4690S, 8 GiB of RAM and an EVGA GTX 760 Superclocked ACX. The performance is just amazing, and the price very fair.
As I mentioned, I also migrated my Linux installation to this new computer. By migrating I mean I continue running the same system without reinstalling, preserving the state of the OS and personal data. It’s the third time I did such an operation, and it’s been at least ten or eleven years since I installed this system. I’ve been running the rolling release installation of Slackware Linux since then, across several computers.
I’ve never fully documented my migration procedure. The following notes serve mainly as a reference for myself in the future.
Kernel preparation
I start from the old system by first removing all custom kernel modules I have installed, which these days is mostly the binary NVIDIA driver. Then, I switch from a modular kernel with an initial RAM disk to a huge everything-included kernel that would be suitable to boot any system, including the new one for which I still don’t know which modules are essential to boot.
In Slackware there’s a specific package for that called kernel-huge. Just in case it’s useful, the kernel config and image file are easily available. I proceed to boot my old system with this kernel and without an initial RAM disk to check everything is fine.
Data transferring
I then proceed to transfer all data to the new computer. In this case it meant just plugging the old hard drive in the new computer, but it depends on the situation. The previous time I used an external USB hard drive to copy data from a laptop to my now-old desktop computer, which was booting from a Live-CD or Live-USB. If both systems have Gigabit Ethernet ports, a crossover cable can be a fast solution too.
In this step you may have decided to change the partitioning scheme to be used in the new system, so a bit of data juggling and temporary mounts may be needed. Once the new system has the data, 80% of the work is done and only the other 80% is left.
Finishing touches and booting
Time to try to boot the new system. For that, I usually chroot into the new system from a Live-CD or Live-USB. I first attempt to configure the bootloader correctly. I always install GRUB (these days v2) in the MBR of the appropriate hard drive the BIOS will try to boot. This will probably change with EFI, but I still run my system in Legacy BIOS mode (take into account my gaming OS is Windows 7).
The hard drive order as detected by the BIOS or GRUB may not match the order in the kernel. This happens in my new computer. hd0 and hd1, as detected by GRUB, match to /dev/sdb and /dev/sda respectively. I adjust the GRUB config file accordingly.
After installing GRUB, I pay attention to these other files and tweak everything until the system boots correctly.
-
/etc/fstab, paying attention to the new partitioning scheme, if any, and the hard drive names.
-
Remove autogenerated persistent udev configuration files. In Slackware they sit in /etc/udev/rules.d.
-
Tweak or disable personal commands run at boot time from rc.local and other scripts (no systemd yet in Slackware). Some of those may be related to specific kernel modules or hardware tuning.
-
Review the /etc/smartd.conf configuration file for possible changes or disable SMART until the new system is ready.
Post-booting
At this point I’m happy because I should be running my system in the new computer.
The next step is using mkinitrd-command-generator.sh from Slackware team member AlienBOB to find out which modules I need to boot the computer, and reverting to a modular kernel with an initial RAM disk.
Finally, re-enable or review everything that may have been temporarily disabled previously from boot scripts and SMART. Also, save a fresh copy of the new ALSA settings with “alsactl store”.
I then reinstall the NVIDIA driver and other binary kernel modules, re-configure X11 as needed and tweak any specific system scripts and tools I have stored in /usr/local/sbin and similar places, checking if anything needs to be changed or if there’s been a change in device names.
And that’s it. Typically it’s an evening’s work. Reinstalling Windows, on the other hand, and having to apply around 200 security updates takes ages, but at least it’s mostly unattended.