Re: New Hardware + old disks not recognized
I think you're right about the missing drivers, but fixing it has
proven challenging.
First, my original initrd was created with MODULES=dep. This was
somewhat hidden by the fact that in initramfs.conf, MODULES=most. :)
Apparently it was overriden by the setting in conf.d/driver-policy,
which I have since edited.
lspci -nn confirms one of the device ids you expected. I also
included the NVMe device too:
02:00.0 Serial Attached SCSI controller [0107]: LSI Logic / Symbios
Logic SAS2116 PCI-Express Fusion-MPT SAS-2 [Meteor] [1000:0064] (rev
02)
71:00.0 Non-Volatile memory controller [0108]: Samsung Electronics Co
Ltd NVMe SSD Controller SM961/PM961 [144d:a804]
First try: chroot into the old system and update-initramfs. The
result can see the disks (yay) but has no, or at least insufficient,
crypto.
Second try: rsync from the old initrd to the new one.* Considered
using -u, but that left an empty cryptroot file in place. Booting
using initrd post-rsync is back to the old situation with no disks
visible. Presumably some files that should have been merged (e.g.,
modules) were overwritten by the rsync.
Third try: do lsmod in ubuntu and insert all the modules into the
initrd modules file. Still no disks visible. I'm not sure if I
should have been using module names as reported by lsmod or something
more like the file names, and I later noticed that the modules are
loaded in the order given. I don't know if the order was right.
Fourth try: regenerate a "clean" initrd as in the first step and
attempt to merge in the old initrd files that are missing or
different. For some reason this produced a lot more complaints than
the first time I did it.** That includes the modules.aliases file.
However, some of the module management files are binary (ld.so.cache).
I wasn't sure how regenerating them in a chroot would work. Booting
with this got further: disks are recognized and I get a prompt to
decrypt the root partition. However, my password is not accepted. In
the past I've seen this when the right crypto modules were not loaded.
I did copy over some crypto modules and associated binaries in the
fourth try, but perhaps I need to regenerate the caches/management
files to get them to work properly. It's a little odd they weren't
there to begin with, given the MODULES=most selection and the presence
of some crypto modules.
There are also some differences in font-related files; I'm hoping they
don't matter (e.g., cache files with different names, different uuid
in local/share/fonts/.uuid).
@songbird: maybe I should try installing buster somewhere on the SSD,
but I'm not sure that's going to get me much closer into booting my
old system. If I ensured that it had similar drivers (i.e., setup
using LVM and encrypted root) it should be closer, but it's still not
my target system.
I wouldn't want to use a system without encryption, and at any event
my employer requires it.
Ross
* I'm using a bit of a short-hand. I expand the initrd into a
directory, manipulate files in that directory or comparing those with
files expanded from another initrd, and then recreate the initrd file
from the directory.
** The complaints are all on point however, and the condition they
describe was true the first time too:
# update-initramfs -u -k 4.19.0-5-amd64
update-initramfs: Generating /boot/initrd.img-4.19.0-5-amd64
/usr/share/initramfs-tools/hooks/cryptroot: 64:
/usr/share/initramfs-tools/hooks/cryptroot: cannot open /proc/mounts:
No such file
cryptsetup: WARNING: Couldn't determine root device
sed: can't read /proc/cmdline: No such file or directory
/usr/share/initramfs-tools/hooks/cryptroot: 64:
/usr/share/initramfs-tools/hooks/cryptroot: cannot open /proc/mounts:
No such file
cryptsetup: WARNING: The initramfs image may not contain cryptsetup binaries
nor crypto modules. If that's on purpose, you may want to uninstall the
'cryptsetup-initramfs' package in order to disable the cryptsetup initramfs
integration and avoid this warning.
W: Couldn't identify type of root file system for fsck hook
/proc/mounts isn't accessible in the chroot; even if it were, it would
not give the mounts appropriate for the system I'm trying to set up.
Reply to: