0

I have a strange problem I don't understand.

I have a Kubuntu 19.04 installation that has a guided install of an encrypted LVM root.

lsblk
NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda                        8:0    0 465,8G  0 disk  
└─sda1                     8:1    0 465,8G  0 part  
sdb                        8:16   0 223,6G  0 disk  
├─sdb1                     8:17   0   731M  0 part  /boot
├─sdb2                     8:18   0     1K  0 part  
└─sdb5                     8:21   0 222,9G  0 part  
  └─sdb5_crypt           253:0    0 222,9G  0 crypt 
    ├─kubuntu--vg-root   253:1    0 221,9G  0 lvm   /
    └─kubuntu--vg-swap_1 253:2    0   980M  0 lvm   [SWAP]

sdb is a SSD and sda a HDD.

sda is just a mass storage of unimportant data and not encrypted.

cat /etc/fstab 
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
/dev/mapper/kubuntu--vg-root /               ext4    errors=remount-ro 0       1
# /boot was on /dev/sdb1 during installation
UUID=5502e3df-bf98-4ec3-9277-0b2d22308be2 /boot           ext4    defaults        0       2
/dev/mapper/kubuntu--vg-swap_1 none            swap    sw              0       0

with

/dev/sda1: UUID="86b8c281-dc71-4102-92b5-070843eb2784" TYPE="ext4" PARTUUID="998890db-01"
/dev/sdb1: UUID="5502e3df-bf98-4ec3-9277-0b2d22308be2" TYPE="ext4" PARTUUID="4b7c5ebc-01"
/dev/sdb5: UUID="85e69429-53aa-4348-83d9-cb2b68128ec4" TYPE="crypto_LUKS" PARTUUID="4b7c5ebc-05"
/dev/mapper/sdb5_crypt: UUID="ysVfBL-KvGw-tce2-g1ko-5cUu-ichc-31kfCO" TYPE="LVM2_member"
/dev/mapper/kubuntu--vg-root: UUID="8995e215-a95b-499c-b83d-a12987e20600" TYPE="ext4"
/dev/mapper/kubuntu--vg-swap_1: UUID="72f9eb33-6d0e-4f86-9c3e-d1eb5e83aa63" TYPE="swap"

So imho everything should be fine if I demount sda, which is 86b8c281-dc71-4102-92b5-070843eb2784. But if I do this, the system does not boot. In fact, if I look into my BIOS/UEFI, in reality I boot from the HDD and not the SSD.

If I change the boot device to the SSD or demount the HDD, nothing happens (besides a blinking underscore on the top left screen were I cannot read/write anything)

Does anybody have an idea what is (or I understand) wrong here?


Additional info:

cat /etc/crypttab 
sdb5_crypt UUID=85e69429-53aa-4348-83d9-cb2b68128ec4 none luks,discard
1

The syntax of the PARTUUID values indicates your disks are probably using MBR partitioning and classic BIOS-style boot. And the symptoms suggest that your bootloader is actually written onto sda rather than sdb, even though your /boot partition is sdb1. This is because in BIOS-based systems, the OS installer cannot necessarily tell in which order BIOS will see the disks, and will generally assume that the first detected disk (sda) is the disk the BIOS will boot the system from.

When you remove sda, you're left with no functional MBR-based bootloader, and unfortunately your system BIOS fails to give you a good error message for that.

Assuming that you're using the default GRUB bootloader, it's embedded into the actual Master Boot Record and in the space between MBR and the beginning of the first partition. So it's not a regular file and cannot be moved or otherwise manipulated as one.

However, this is fairly easy to fix.

First, you should edit the /boot/grub/device.map file to say:

(hd0) /dev/sdb

This will tell the GRUB installation tool (that you'll soon be using): "When installing a new instance of GRUB, assume that the disk that is currently sdb will be the first detected disk on the system." This is important because we're preparing to remove sda from the system.

Once the file is successfully modified, you should run:

sudo grub-install /dev/sdb

This will not do any harm to your existing GRUB instance, but will write a new one to sdb.

Now you should be able to remove the sda disk, and still have the system boot normally.

Since the original sda disk is now removed, the sdb disk will probably appear as sda, unless Kubuntu has a mechanism to persist disk device names (in which case you'll probably find the record associating the name sdb to the disk at /etc/udev/rules.d/). So you should edit the /boot/grub/device.map again to match the new system state (or just remove the file altogether):

(hd0) /dev/sda

This will be important if/when an update for GRUB is installed.

  • Your analysis was/is correct. Grub was installed on sda and not sdb. My system had no device.map file and researching it showed that it seems not necessary to use it anymore. Installing grub on sbd solved the problem. The device shows now, like you thought, as sda. – WhatIsThisThing May 21 at 18:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.