Emergency mode on Kinoite, LUKS encrypted. Mounted unavailable partition to home

Ask Fedora
, , ,
1

I had to swap SSDs to see if Windows would fix its stuff when internally, it didnt.

I ran Kinoite in an external SSD case instead, did an rpm-ostree update too.

The update went well, I rebooted into that again, used it a while, turned it off and unplugged the SSD. I think I waited until everything was completely black, pretty sure.

I had Windows 11 boot up once, attempting to do a “disk repair” and that failed for some reason, it doesnt boot up too. I guess that messed up my boot partition.

But now, I swapped ssds again, I can boot grub2, select any deployment and both give me the emergency mode, directly after selecting the deployment in grub (I have it set to show).

What can I do to fix this??

Thanks in advance.

Update

I can enter the “administrator password” which is the LUKS password for some reason.

The emergency mode occurs AFTER unlocking the LUKS drive. On my Laptop its when the screen brightness starts to be controlled.

Also, I cant boot into Live USBs for some reason, the F12 boot menu just lists UEFI entries. Didnt manage to create one poorly.

This is the output. Looks like Windows did something horrible, mixing my partitions?

IMG_20231023_205848_966
IMG_20231023_205848_9663024×4032 2.82 MB

2

Found the answer. I tried mounting an external Windows partition to my home, as it was not showing up. The lack of this partition at the correct place then prevented my system from booting.

This should not happen… but removing the line from the /etc/fstab fixed it.

1 Like
3

Any mount that is in /etc/fstab that fails will halt the boot. The only way I know to allow the system to continue to boot when a mount fails is to have ‘nofail’ as one of the options for that particular device mounting.

1 Like
4

So something like this would work:

/dev/sda1 /home/user/Windows-SSD ntfs nofail 0 0
5

Yes, but you don’t need defaults. That’s just a placeholder for when you don’t specify any options.

Also, it’s more robust to identify the partition by UUID or label.

6

@boredsquirrel

This is because it is quite common for devices to change names. What was configured yesterday as /dev/sda may be /dev/sdc today with the use of usb devices that are configured the same as internal sata devices. Using more than one usb device may mean confusion if using the /dev/sd?X name, while using the UUID for the filesystem on the partition only changes the line in fstab from

/dev/sda1 /home/user/Windows-SSD ntfs nofail 0 0

to

UUID=<actual filesystem uuid here>  /dev/sda1 /home/user/Windows-SSD ntfs nofail 0 0

and by doing so that device and only that device will be mounted at that particular mount point when connected. In fact, since udev is aware of fstab and its entries, when the device is connected after a boot it still should be automatically mounted the same location.

1 Like