You are not logged in.
Some weeks ago my arch main system, after running fine for some years, died when the motherboard went completely dead. I now have a new barebones desktop, and have transferred the nvme ssd from the old unit to the new one, and increased the amount of RAM in the new hardware. Having thought about what may be needed to try to get the old system ssd running on the new hardware, I have been planning the steps that may be needed. Initially I intend to boot an arch install drive on usb as a rescue drive, and arch-chroot into the mounted root partition on the pre-existing ssd. The system was booted with sd-boot previously, so the key steps I thought would be to check/amend the fstab, regenerate the initramfs entries and update the boot entries with bootctl. Hopefully the system will then boot and I can update networking and other standard services and also check login to the desktop works.
However if anyone has had experience of doing this using a previously working nvme/ssd transferred into a new motherboard, and has any hints and tips on key things that need to be done to make this work successfully, then I would appreciate it. The arch wiki does have some notes on migrating an install though focuses on a new install on the new machine, and then transferring files to the new system. For my system I am trying to use the existing ssd and making minimal necessary changes to get it to boot. Any help is appreciated.
Last edited by mcloaked (2025-03-19 15:50:17)
Mike C
Offline
What you're looking to do is described as the bottom to top approach and it is listed in the wiki: https://wiki.archlinux.org/title/Migrat … w_hardware
EDIT: said it wrong. it's top-to-bottom
Last edited by mackin_cheese (2025-03-18 18:16:34)
Online
systemd-boot, by default, installs itself to the default loader location, so you should be able just tell the system to boot it, choose the fallback initramfs, and boot just fine.
Offline
systemd-boot, by default, installs itself to the default loader location, so you should be able just tell the system to boot it, choose the fallback initramfs, and boot just fine.
Thanks. I guess updating the kernel (and rest of the system) whilst chrooted from the rescue drive should do that and allow booting once the rescue drive is removed too? I was unsure about the nvram entry since the hardware hasn't previously been booted.
Mike C
Offline
You missed my point, there's no need for the rescue disk at all.
Once in the system, you can regen the initramfs to avoid having to use the fallback, and add the nvram entry
Last edited by Scimmia (2025-03-18 18:01:37)
Offline
You missed my point, there's no need for the rescue disk at all.
Once in the system, you can regen the initramfs to avoid having to use the fallback, and ass the nvram entry
I did take your point, and thank you for doing so - but in my case for some time I had switched off generating the fallback image because in about 20 years of running arch I had never actually booted the fallback! As you point out this is the one occasion when having the fallback image would would have made life simpler for me! So without the fallback image I guess my option is to boot the rescue drive and run a full system update. The old hardware failed about a month and a half ago, so it is still a reasonable number of packages that would update on the new system, with a download I am guessing of a couple of GB of update files.
Mike C
Offline
Ah, yeah, without the fallback you would need it. An update will almost certainly regen the initramfs, or you can just do it directly and skip the update. There's some issues right now whether you can add the nvram entry from chroot, so you may have to do that part after booting the system
Offline
Oh OK - I hadn't thought about being possibly unable to generate the nvram entry from chroot - though I guess I could alter the config file for the initrd, and let it produce the fallback entry, and add in a system-boot entry for it if it turns out that the nvram isn't writeable when chrooted in. Thank you for that important point.
Edit: I found there is a thread about this both in the arch forum recently https://bbs.archlinux.org/viewtopic.php?id=301920 , and on github https://github.com/systemd/systemd/issues/36174 so this is useful to know.
Last edited by mcloaked (2025-03-18 18:23:00)
Mike C
Offline
I made a mistake lol the method is actually called top to bottom
Online
Those are two separate things. Once you've regenerated the initramfs, you don't need the fallback. It doesn't matter if you start sdboot from an nvram entry or from the default loader location.
Offline
OK Thanks I will try that without generating the fallback when I get to the new hardware and start working on getting the system going (probably at the weekend). Thank you for all your help with this. One possibly important point is that this is a pure arch system - no other OS is installed. Also I separately had a very old arch system on an old NUC that was brought in as an emergency replacement, after having not been used at all for about 6 years. It booted, and I ran a huge pacman update that failed to complete without error - but in order to get it to boot after the failed pacman update, back on a normal boot, using the following single pacstrap command from the rescue drive did allow a successful update, which then let it boot directly:
pacstrap -K /mnt --overwrite '*' pacman coreutils glibc openssl gnuupg gpgme bash grep gettext gawk systemd acl systemd-libs linux base libarchive mkinitcpio tpm2-tss
So if all else failed then this approach may just get it going again. But your suggestion looks like it should hopefully be all that is necessary. I will report back once I have worked on the system.
Last edited by mcloaked (2025-03-18 18:32:41)
Mike C
Offline
I had some time earlier today so I connected up the new hardware, and started the boot selecting the normal boot entry from the sd-boot options. I was relieved to find the computer booted just fine. Pacman update worked without error (3GB download) via the wired connection, and then rebooted to the new kernel, that started the system and graphical desktop (plasma) without any problem at all. The only adjustment needed was to reset the sensors on the plasma desktop network speed widget. So Scimmia was spot-on, almost - I didn't need the fallback image after all though, nor a rescue drive, to boot. The old system hardware was a small fanless desktop with AMD Ryzen 7 5800U CPU, and the new hardware was the same CPU but in a different motherboard in a different enclosure. Both had an M.2 slot for the nvme ssd drive, and the only difference was an increase in RAM from 16GB to 64GB (new), both DDR4. So in the event of a total motherboard failure in the future I will be less apprehensive about simply moving the nvme drive from the old machine to the new machine. The Arch Wiki focuses on migration by cloning the hard drive from old machine to new - but in this case a physical transfer of the old drive to the new machine was very much simpler to get going than I had expected. I will mark this as closed.
Mike C
Offline