Re: New Hardware + old disks not recognized [SOLVED + lessons learned]

[Ross Boylan <rossboylan@stanfordalumni.org>]

ORIGINAL PROBLEM
Move disks into a new system (hardware) and found I couldn't boot into
the old system (OS on the disk).  The initrd couldn't even see the
drives.

CAUSE
New hardware required drivers missing from  the initrd, which had been
created with MODULES=dep.  Also, fstab referenced a drive left in the
old hardware.  My OS used crypto and LVM, although that only became
relevant once the "no drives" problem was fixed.

SOLUTION:
Boot into alternate system on the new hardware and mount the old OS.
Create a new  initrd
      1. unpack the old initrd.
      2. chroot into old OS, change to MODULES=most, and regenerate
the initrd.  This produces error messages about the result not being
right.  It's not right, but unpack it anyway.
      3. copy files present in the old and absent in the new initrd to
the new initrd.
      4. merge/inspect/evaluate file conflicts.  In particular, the
old cryptroot should replace the new, empty cryptroot.
       5.  Use depmod -b to regenerate the module dependency list
(otherwise the modules copied in step 3 will be ignored).
       6.  Adjust fstab and networking as needed for new interface
names.  These are on the real system, not the initrd.
       7.  pack up the revised initrd and boot.

5 + 6 were the steps I added since my last message.  Without 5 the
crypto modules copied in 3 were not accessible, and I couldn't unlock
the drives.
Without 6,  fstab referred to one drive that stayed in the old system;
apparently that was enough to keep systemd from booting into the
regular system (it kept dropping me in an emergency shell, albeit
after pivot to the real OS from the initrd).

I did most of my network adjustments after booting into the system I
was trying to bring up.  Most of the networking related services
needed to be restarted after fixing that up.  In retrospect there is
an

ALTERNATE SOLUTION
   1. Move drives back to old system.
   2. Ensure MODULES=most and fstab only refers to drives that will be
in the new hardware.
   3. update-initramfs.
   4.  move drives back to new system.

There are also probably ways to get a correct initrd generated from
within the chroot environment on the new hardware.  I don't understand
initramfs-tools well enough to know how to pull that off.

LESSONS
1. Don't ever get in this situation.  It's a mess.
2. If you're planning on moving to new hardware, ensure your initrd is
generated with MODULES=most BEFORE the move.
3. Just because initramfs.conf has MODULES=most doesn't mean that's
what you get.  In my case, conf.d/driver-policy overrode it.
4. Manually constructing or modifying an initrd is pretty delicate business.
5. systemd seems to react very badly to a mount failure in fstab.

THANKS
To Pascal and songbird for their help.

Ross