How can I figure out why I'm being dropped to a initramfs shell?

[Praxis]

My situation is a bit weird. I originally installed the first iteration of SpiralLinux, which is a live spin of Debian with a Calamares installer. I did this because I use encrypted LUKS installs and the normal Debian installer that I used for some of my 10 year old Debian installations created an unencrypted ~243 MB /boot partition which was inadequate at the time and finally became a real PITA because it was too small to hold two kernels so I had to make a new unencrypted larger /boot partition somewhere, use dracut or apt would become wedged over time. The Calamares installer didn't require an unencrypted /boot partition, which seemed like a big plus at the time. Spiral only included the standard Debian repositories plus fasttrack for virtualbox, so I figured it would be OK.

(By the way, I recently did a fresh LUKS encrypted install from Trixie alpha 1 installer and it seems to create a 1 GB partition, still a little tight probably as the kernel continues to get bigger over time, but probably good enough for the rest of my natural life. Cmon, team, drive space is CHEAP, you could buy a 120GB SSD for $40 back in the Jessie/Etch times when I did my first encrypted installs with the 243MB /boot partitions.)

Unfortunately, SpiralLinux is not straight Debian and introduced issues of its own. One of these is that over time long after I'd upgraded from bookworm to trixie in two of the former SpiralLinux systems I found I was being dropped to an emergency shell in one case and to a initramfs shell in the other. I figured out that the non-root encrypted partitions were no longer being automatically decrypted by the keyfiles referenced in my /etc/crypttab. At some point during an upgrade the systemd-cryptsetup package was being stripped away and I had to chroot to the OS and install systemd-cryptsetup to get the /usr/lib/systemd/system-generators/systemd-cryptsetup-generator file.

That worked properly for one of the upgraded SpiralLinux installs but not entirely for the other (they were both created by a dd of the original SpiralLinux install). In the second case I wouldn't be dropped to an emergency root prompt, but a initramfs shell, which is really pretty useless to me, it doesn't have enough commands to allow me to proceed. But I learned that after installing systemd-cryptsetup I could decrypt my LUKS partition and boot into emergency mode from grub, then enter my root password and just hit "Control + D" to boot normally. I edited my /etc/default/grub file to automatically boot my last chose option (emergency mode), then did an "update-grub", so I'm basically functional, but this is a crummy long-term option.

Is there some way to figure out exactly why I am being dropped to initramfs? I looked over dmesg but didn't see anything.

[mrmazda]

There might be a file named /run/initramfs/rdsosreport.txt that reports more than dmesg.

[pbear]

FYI, the Bookworm live ISO doesn't create a boot partition. Uses keyctl and leaves /boot on the system partition. Does create a separate encrypted swap partition. And of course the EFI partition isn't encrypted.

[Praxis]

There might be a file named /run/initramfs/rdsosreport.txt that reports more than dmesg.

Unfortunately there isn't such a file when I try to boot normally. Attached is a snapshot of when I let the system drop me to initramfs. I cd to /run/initramfs and the folder is empty.

But when I try the 'exit' command I get:

Code: Select all

Gave up waiting for root file system device. Common problems:
- Boot args (cat /proc/cmdline)
   - Check rootdelay= (did the system wait long enough?)
- Missing modules (cat /proc/modules: ls /dev)
ALERT! /dev/mapper/luks-b98sunc-h8wof-9num4dbers does not exist. Dropping to a shell!

The UUID is the proper one for my encrypted volume with my root partition, so apparently when the system tries to boot normally it isn't waiting long enough to decrypt the system. These seem to be the most relevant lines in my /etc/default/grub:

Code: Select all

GRUB_DEFAULT=saved
GRUB_SAVEDEFAULT=true
GRUB_TIMEOUT=15
GRUB_DISTRIBUTOR=`( . /etc/os-release; echo ${NAME:-Debian} ) 2>/dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet loglevel=0 cryptdevice=UUID=c3e91c5d-78fb-449d-bab8-59704720fcdf:luks-c3e91c5d-78fb-449d-bab8-59704720fcdf root=/dev/mapper/luks-c3e91c5d-78fb-449d-bab8-59704720fcdf splash"
GRUB_CMDLINE_LINUX=""

I'm guessing that GRUB_CMDLINE_LINUX_DEFAULT= may be the problem, it was probably created by the Calamares installer. The equivalent line on my new Trixie alpha installer encrypted install /etc/default/grub is shorter and sweeter:

Code: Select all

GRUB_CMDLINE_LINUX_DEFAULT="quiet"

The problem with using the SpiralLinux luks encrypted install is not just that it seems to have more weird issues upgrading than my kept-up-to-date 10+ year old straight Debian installs, but that decrypting the luks partition is really cockamamie. I type in my decryption key and then I have to wait about 30 seconds for it to actually decrypt. And if I fat-finger my long decryption key it goes on for maybe another 30 seconds before dropping me in a grub shell, no second chances, I just have to reboot and try again. It drives me crazy.

@pbear, do you know if the Bookworm live ISO exhibits the same annoying behavior on a full disk luks-encrypted install?

[pbear]

@pbear, do you know if the Bookworm live ISO exhibits the same annoying behavior on a full disk luks-encrypted install?

Not sure I understand the question. If you're asking whether it boots correctly, the answer is "of course" (or I wouldn't have mentioned it). Here's what the partition table looks like:

Code: Select all

pbear@debian-fde:~$ df -hT -x tmpfs
Filesystem     Type      Size  Used Avail Use% Mounted on
udev           devtmpfs  2.8G     0  2.8G   0% /dev
/dev/dm-0      ext4      114G   25G   83G  23% /
/dev/sda1      vfat      300M  5.9M  294M   2% /boot/efi

As mentioned, /boot is a folder on /, at of today 286 MB for three kernels. Space used on a Standard Installer LVM system (also three kernels) is 242 MB of the (unencrypted) 456 MB boot partition, i.e., 45% full.

Caveat: I don't use or recommend system encryption. (I do use encryption for a subset of my data files, i.e., the ones I consider actually sensitive.) These are VBox VMs for test purposes, not exposed to the vagaries of daily use. Also, if I did use encryption, it would be system partition + encrypted data + non encrypted boot, separate partitions (no LVM), which can be set up reasonably easily with the Standard Installer (I have another VM test box with that setup).

[mrmazda]

There might be a file named /run/initramfs/rdsosreport.txt that reports more than dmesg.

Unfortunately there isn't such a file when I try to boot normally.

Code: Select all

# grep RETT /etc/os-release
PRETTY_NAME="Debian GNU/Linux trixie/sid"
# lsinitramfs /boot/initrd | grep sos
# lsinitramfs /disks/stw/boot/initrd | grep sos
usr/sbin/rdsosreport
# 

Apparently, installed Trixie initrds are not by default equipped with rdsosreport. When I force Tumbleweed into dracut emergency shell, /run/initramfs/rdsosreport.txt exists, size 1,637,036.

[Praxis]

@pbear, do you know if the Bookworm live ISO exhibits the same annoying behavior on a full disk luks-encrypted install?

Not sure I understand the question. If you're asking whether it boots correctly, the answer is "of course" (or I wouldn't have mentioned it).

I assumed the installer sets up luks so that it boots correctly, what I was asking was whether the Bookworm live install displays the annoying behaviors I have encountered with two luks-encrypted modified Debian installations (SpiralLinux & NeptuneOS) made with the Calamares installer and no unencrypted /boot partition, to wit:

• It takes a very long time to decrypt the OS drive with the typed key, about 30 seconds

• If I mistype the key it takes another 30 or so seconds to fail and drops me to a grub shell with no chance of reentering the decryption key, I have to reboot

[pbear]

You're moving the goal posts. Never mind and good luck.