0

Recently I added a new disk to my computer. I had a free SATA slot, so nothing else changed. A few days after the disk was inserted the computer stopped to boot.

I use Debian Bookworm. I have an encrypted partition which contains a LVM with several virtual partitions, including the root partition.

Usually after Grub I am prompted for the password of sda2_crypt. Now Grub passes, then the computer hangs for a while and I land in something I think is BusyBox telling me some command timed out. I tried to run sudo grub-mkconfig but it did not help.

I noticed that the boot fails only for a newer Kernel. Trying to boot the older kernel still works.

1 Answer 1

0

It turned out that by adding a second disk the drive letters changed. The disk containing the root file system was /dev/sda before but became /dev/sdb. This made it impossible for the system to decrypt the root partition.

Please note that Grub was fine, it loaded the Kernel correctly. Thus all attempts to repair the system targeting Grub were doomed to failure.

The shell that presented the error was a initramfs, not a BusyBox. It allows to to fix errors so the boot process can continue. A dedicated section in this answer explains how to do so.

Another section explains how to permanently fix the issue.

How to temporarily fix the issue in initramfs

Actually it is very simple. This answer has some more details but the steps regarding LVM were not necessary in my case.

What blocks the system to proceed to boot is that the device containing the root file system cannot be found. In my case this was /dev/mapper/ssd-root. For it to appear one has to manually open the encrypted partition:

cryptsetup open /dev/sdb2 some-arbitrary-mapname

After that, one must exit initramfs:

exit

Of course, one must use the device that contains the root file system. As map name, anything can be used. One could go with the generic sdb2_crypt, but one might choose to use a self-describing name like ssd500-crypt.

If one does not use the expected map name, e.g. sda2_crypt, one again will be prompted for a password some time later, again after a brief hang. The expected map name can be found in /etc/crypttab.

How to permanently fix the issue

In order to permanently fix the issue initramfs has to be updated. The following sequence of steps was used by the author:

  1. Fix the issue temporarily in initramfs.
  2. Change the map name in /etc/crypttab to something new. Anything goes, so one might use a self-describing value like ssd500-crypt.
  3. sudo update-initramfs -u and reboot
  4. Again temporarily resolve the issue in initramfs. However, this time the map name must be the one used at step (2).
  5. sudo update-initramfs -u and reboot

Possibly step (1) can be omitted if the new map name is chosen there already.

2
  • 1
    Drive device names are explicitly not guaranteed to be persistent across reboots. The advice from kernel devs and pretty much everybody else is that you shouldn't use them in any config files or scripts (interactive CLI use is OK), you should use UUIDs (unique and persistent) or LABELs (user-created & easily changed so they are as unique and persistent as you want them to be). See Persistent disk name /dev/sd'x', changing with almost every reboot and other dupes at unix.stackexchange.com/search?q=persistent+drive+names Commented Dec 11, 2022 at 12:55
  • I agree with you. Except for the manual commands, I do not use device names anywhere. However, somehow a change of device names messed up the original initramfs. So, the question and answer are legit, because they solve an issue I wasn't responsible for. Commented Dec 12, 2022 at 7:10

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.