Boot error: Failed to start D-Bus System Message Bus

dano · 24 November 2024 14:01

I followed this guide, i.e.

Open the crypted boot volume
Mount it to some helper folder (e.g. /chroot)
Mount the efi partition inside (/chroot/boot/efi)
Add the additional mounts described, i.e.

mount --bind /proc /chroot/proc
mount --bind /dev /chroot/dev
mount --bind /sys /chroot/sys

Chroot with `chroot /chroot’

Then I try to fix grub following this guide, shared by @soundofthunder:

Instead of chroot /chroot' I use manjaro-chroot /chroot /bin/bash`
Re-install grub with

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck

Then create the config with:

grub-mkconfig -o /boot/grub/grub.cfg

I end up at boot with message:

ERROR: device 'UUID=3e5e...'  not found. Skipping fsck

mount: /new_root: can't find UUID=3ef5....
ERROR: Failed to mount UUID=3ef5... 
You are no being dropped to emergency shell.
...

I use

cryptsetup -v luksOpen /dev/<dev> <mapper_name>

for opening the luks.

For completeness, I also share my crypttab and fstab:

# /etc/crypttab: mappings for encrypted partitions.
#
# Each mapped device will be created in /dev/mapper, so your /etc/fstab
# should use the /dev/mapper/<name> paths for encrypted devices.
#
# See crypttab(5) for the supported syntax.
#
# NOTE: You need not list your root (/) partition here, but it must be set up
#       beforehand by the initramfs (/etc/mkinitcpio.conf). The same applies
#       to encrypted swap, which should be set up with mkinitcpio-openswap
#       for resume support.
#
# <name>               <device>                         <password> <options>



#luks-794e3e8d-403e-4dcf-9547-3a021ef2f604 /dev/disk/by-uuid/794e3e8d-403e-4dcf-9547-3a021ef2f604     /crypto_keyfile.bin luks
#luks-7f38ff02-ee3b-42f0-8f2d-ebb9ba67de56 /dev/disk/by-uuid/7f38ff02-ee3b-42f0-8f2d-ebb9ba67de56     /crypto_keyfile.bin luks
#luks-919c4578-3819-48c3-b125-ed4e33881fe7 /dev/disk/by-uuid/919c4578-3819-48c3-b125-ed4e33881fe7     /crypto_keyfile.bin luks

luks-794e3e8d-403e-4dcf-9547-3a021ef2f604 UUID=794e3e8d-403e-4dcf-9547-3a021ef2f604     /crypto_keyfile.bin luks
luks-7f38ff02-ee3b-42f0-8f2d-ebb9ba67de56 UUID=7f38ff02-ee3b-42f0-8f2d-ebb9ba67de56     /crypto_keyfile.bin luks
luks-919c4578-3819-48c3-b125-ed4e33881fe7 UUID=919c4578-3819-48c3-b125-ed4e33881fe7     /crypto_keyfile.bin luks

# /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>
UUID=CD10-10B9                            /boot/efi      vfat    umask=0077 0 2
/dev/mapper/luks-794e3e8d-403e-4dcf-9547-3a021ef2f604 /              ext4    defaults,noatime 0 1
tmpfs                                     /tmp           tmpfs   defaults,noatime,mode=1777 0 0
/swapfile none swap defaults 0 0
/etc/fstab (END)

Nachlese · 24 November 2024 14:07

That guide would be wrong if it told you to do what you said it did.

you mount your system root → /
you mount any other directories (which might reside on different partitions) to that system root
not the other way around

you can’t mount /boot and then mount / (root) to it
that won’t work …
you’ll end up with an empty /boot

you mount / and then /boot to it …

and then you don’t need the “manual” process (which you didn’t describe accurately)
you can then simply use
manjaro-chroot /mountpoint

dano · 24 November 2024 14:15

Puuh, I don’t get you point, sorry! So the guide is wrong?

Anyway, this is the requested output:

[manjaro /]# ls -al /dev/mapper/
total 0
drwxr-xr-x  2 root root      80 Nov 24 10:59 .
drwxr-xr-x 22 root root    5020 Nov 24 14:03 ..
lrwxrwxrwx  1 root root       7 Nov 24 10:59 boot_crypt -> ../dm-0
crw-------  1 root root 10, 236 Nov 24 10:53 control

I’ll try with more convenient `manjaro-chroot’ then.

Isn’t that what I’ve described:

Nachlese · 24 November 2024 14:16

I’ll not go analyzing the guide.
My guide is here …

mount /
mount anything important (like: /boot) to it
then chroot into where you mounted the stuff to

I read it differently, that’s why I said what I said.

you only answered half of the question … you gave the result, but not the command which produced the result

dano · 24 November 2024 14:25

Is this what you are asking for?

Nachlese · 24 November 2024 14:30

yes
so: boot_crypt was what you chose for your <mapper_name>
you can choose whatever name you like - it is just a name, so pick one that is telling you something …

dano · 24 November 2024 14:43

Using manjaro-chroot yields slighty different result, after re-installing and configuring grub. I stuck again at boot, this time, the message fits to my /etc/fstab:

ERROR: device 'UUID=luks-794e...'  not found. Skipping fsck

mount: /new_root: can't find UUID=794e....
ERROR: Failed to mount UUID=794e... 
You are no being dropped to emergency shell.
...

The corresponding /etc/fstab entry is:

/dev/mapper/luks-794e3e8d-403e-4dcf-9547-3a021ef2f604 /              ext4    defaults,noatime 0 1

The corresponding /etc/crypttab entry is:

luks-794e3e8d-403e-4dcf-9547-3a021ef2f604 UUID=794e3e8d-403e-4dcf-9547-3a021ef2f604     /crypto_keyfile.bin luks

I’d therefore conclude that the encrypted boot partition is not opened during boot.

Nachlese · 24 November 2024 15:34

I don’t know what to conclude from all that scattered information.

If you want to chroot (manjaro-chroot)

you open all the encrypted partitions that are needed - /boot is certainly one of them, /home is not needed …
then you mount / (which will then be called /dev/mapper/whatever_you_called_it)
then you mount /boot to it (which will then also be called /dev/mapper/whatever_name_you_called_it)

… shorthand: you open / and /boot as well - and mount /boot onto /

Why would you expect that your encrypted /boot would magically be opened and mounted through the chroot procedure?

It’s not.
You have to do that.

dano · 24 November 2024 16:23

I appreciate your help, but we are not on the same page.

Nachlese · 24 November 2024 16:27

We are not?
How so?

Perhaps you can try to bring me and perhaps others up to speed?
Without that: I’d still like to help - but can’t - and will refrain from further comments.

brahma · 24 November 2024 16:43

maybe post the commands with the output you used for chroot…
also try chrooting using these commands:

sudo cryptsetup -v luksOpen /dev/nvme0n1p2 cryptDrive
sudo mount /dev/nvme0n1p1 /mnt/boot/efi
sudo mount /dev/mapper/cryptDrive /mnt
sudo manjaro-chroot /mnt

any errors? if not, run:
mkinitcpio -P && update-grub
any errors?

Nachlese · 24 November 2024 17:00

the EFI isn’t encrypted - it is just VFAT
but /boot is - this is where the EFI is mounted to …
and /boot is a separate encrypted partition

The system needs to be assembled correctly for anything to work in chroot

dano · 24 November 2024 17:02

Maybe I misunderstood…

I chroot like this:

cryptsetup -v luksOpen /dev/nvm2 sys_crypt
mkdir /chroot
mount /dev/mapper/sys_crypt /chroot
mount /dev/nvm1 /chroot/boot/efi
manjaro-chroot /chroot /bin/bash

@Nachlese : Is this ok?

Then I try to update grub like this:

grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=manjaro --recheck
grub-mkconfig -o /boot/grub/grub.cfg

Then:

I reboot
Stuck during reboot with the error message that my system partition cannot be mounted

@Nachlese: Since I started at some completely different point with this post, do you recommend to create new issues instead of continuing here?

I hope this makes it more clear now.

Thanks!

Nachlese · 24 November 2024 17:05

dano:

I chroot like this:

cryptsetup -v luksOpen /dev/nvm2 sys_crypt
mkdir /chroot
mount /dev/mapper/sys_crypt /chroot
mount /dev/nvm1 /chroot/boot/efi
manjaro-chroot /chroot /bin/bash

@Nachlese : Is this ok?

definitely not o.k.
for multiple reasons -

is just one of them

I don’t know what your current most pressing issue is anymore.
It’s probably better to start over.

dano · 24 November 2024 17:09

Ok?

More precisely it is:

mount /dev/nvm0n1p1 /chroot/boot/efi

It is the efi partition and it is not encrypted. I don’t get it…?

Nachlese · 24 November 2024 17:14

But you have a separate (encrypted) /boot partition - or do you not?

You’d have to open this as well, attach it to the / (root) - and then mount the EFI to it.

It is a strange setup that you have - not easily created by the Calamares installer.
Much more custom, implying that you knew what you where doing and why you where doing it when you set this up.

dano · 24 November 2024 17:18

Maybe the confusion stems from my selected name for the unencrypted root partition, which I called boot_crypt above.

I’d better call it sys_crypt. No additional boot partition is available. It’s the encrypted partition + the efi. This should be all.

Nachlese · 24 November 2024 17:23

It doesn’t matter what you name it.

Maybe you know what is what.
I don’t.

To explain, step by step, could we start with:
lsblk -f
after a fresh boot from USB?

From what I saw so far: you have three (3) encrypted partitions.

You should know, which encrypted partition is which
(which is /
which is /boot
which is /whatever).

If you don’t - let’s go from there.

How did we even end up here?
… from a perfectly well and booting system with some “exists in file system” errors
to discussing the intricacies of chroot …?

dano · 24 November 2024 17:34

lsblk -f                                                                                                                   ✔ 
NAME        FSTYPE      FSVER            LABEL            UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       squashfs    4.0                                                                          0   100% /run/miso/sfs/livefs
loop1       squashfs    4.0                                                                          0   100% /run/miso/sfs/mhwdfs
loop2       squashfs    4.0                                                                          0   100% /run/miso/sfs/desktopfs
loop3       squashfs    4.0                                                                          0   100% /run/miso/sfs/rootfs
sda         iso9660     Joliet Extension MANJARO_KDE_2412 2024-11-04-04-24-27-00                     0   100% /run/miso/bootmnt
├─sda1      iso9660     Joliet Extension MANJARO_KDE_2412 2024-11-04-04-24-27-00                              
└─sda2      vfat        FAT12            MISO_EFI         8BF0-EDB3                                           
nvme0n1                                                                                                       
├─nvme0n1p1 vfat        FAT32            NO_LABEL         CD10-10B9                                           
├─nvme0n1p2 crypto_LUKS 1                                 794e3e8d-403e-4dcf-9547-3a021ef2f604                
├─nvme0n1p3 crypto_LUKS 1                                 7f38ff02-ee3b-42f0-8f2d-ebb9ba67de56                
└─nvme0n1p4 crypto_LUKS 1                                 919c4578-3819-48c3-b125-ed4e33881fe7

nvme0n1p1 => efi partition
nvme0n1p2 => /
nvme0n1p3 => data
nvme0n1p4 => data

Nachlese · 24 November 2024 17:39

dano:

nvme0n1                                                                                                       
├─nvme0n1p1 vfat        FAT32            NO_LABEL         CD10-10B9                                           
├─nvme0n1p2 crypto_LUKS 1                                 794e3e8d-403e-4dcf-9547-3a021ef2f604                
├─nvme0n1p3 crypto_LUKS 1                                 7f38ff02-ee3b-42f0-8f2d-ebb9ba67de56                
└─nvme0n1p4 crypto_LUKS 1                                 919c4578-3819-48c3-b125-ed4e33881fe7

You created them - do you know which is which?
Do you know how they need to be stacked together?

seems to be your / (root)

what are the others?

cryptsetup open /dev/nvme0n1p3 what_is_it
mount /dev/mapper/what_is_it /mnt

then look at it’s contents …

ls -al /mnt

afterwards:
umount /mnt
cryptsetup close what_is_it

Serious question - I truly don’t know anymore why we are even here:
Does your system boot or not?
Do you even need to use chroot?