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