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.
(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.
Statistics: Posted by Praxis — 2025-01-24 01:13 — Replies 1 — Views 57