Open hv15 opened 4 years ago
please confirm lvm
is present in /etc/mkinitcpio.conf
HOOKS=(base keyboard autodetect modconf block filesystems fsck systemd sd-lvm2 systemd-tool)
try to read through more lvm-related wiki cases https://github.com/random-archer/mkinitcpio-systemd-tool/wiki/Case:-Sysroot-on-LVM https://github.com/random-archer/mkinitcpio-systemd-tool/wiki/Case:-Complete-BTRFS-Setup-(step-by-step)
Hi @Andrei-Pozolotin, oops forgot to include content of mkinitcpio.conf
(hooks):
HOOKS=(base keyboard autodetect modconf block filesystems fsck systemd sd-vconsole sd-lvm2 systemd-tool)
assume resolved
I'm actually running into the same issue on several systems (with a system setup close to the one described above).
When booting without network access (e.g. on a laptop), after typing in the password, a start job for dev-gpt-auto-root.device
blocks early userspace for 1:30m. After that boot commences.
When booting with network access the message about the service is never shown, but I can see it in the list of units (i.e. systemctl list-units -a
) as "starting" when ssh'ing to the machine and using the shell.
Fun fact: My fstab for mkinitcpio-systemd-tool does not have a x-systemd.device-timeout=9999h
set, so eventually the Starting Cryptography Setup for xxx...
fails. As I have now also added the sd-encrypt hook to my mkinitcpio.conf, I can still ssh to the machine after the timeout is reached, type in my password and the boot goes through instantly (no .device
unit blocking).
This is of course no improvement (as waiting for the timeout takes even longer), but an interesting observation about this issue.
Also, this entire issue does not appear, when I do not use crypttab and fstab in the initrd but rely on kernel commandline parameters.
@dvzrv great, since you can actually reproduce this :-)
I believe I have figured out what triggers this behavior (in my case), now that I had some time to read up on things.
The systemd-gpt-auto-generator acts according to the "discoverable partitions specification", which in turn makes a few assumptions about the layout of a partition.
My system facilitates btrfs on LUKS in a flat hierarchy. Here the default subvolume (id 5) is not mounted as /
, but a specific subvolume below it is used for that. The opened device is named root0
in my case (as I have an automatic way of installing systems using ansible, that may use more than one disk to e.g. form a btrfs raid).
This does not seem to go too well with the aforementioned generator which probably tries to use the default subvolume (id 5) as root until timing out (also, its default is to open the device as root
).
I have now added systemd.gpt_auto=no
to my kernel parameters to disable the generator altogether (as fstab is in use anyways) and the systemd boots without delay.
@hv15 I hope this will also fix your issues (which seem to be of the same nature, but I'm not 100% sure). @Andrei-Pozolotin I guess this is worth documenting, because I believe I am not the only one who is using a flat hierarchy for the btrfs subvolumes.
@dvzrv What is there inside your /etc/mkinitcpio-systemd-tool/config/fstab
? In my case I specified the subvolume there (because I also use a flat hierarchy) and it works.
@ArchangeGabriel it is only:
/etc/mkinitcpio-systemd-tool/config/fstab
:
/dev/mapper/root0 /sysroot btrfs noatime,ssd,subvolid=259,subvol=/@,subvol=@ 0 1
On that specific machine I only have a subvolume for home otherwise, so that's not important in early userspace (which is why I only specify /sysroot
.
That being said, this is my list of subvolumes:
D 256 gen 17832 top level 5 path @home
ID 257 gen 8 top level 5 path @swap
ID 259 gen 17830 top level 5 path @
ID 262 gen 25 top level 259 path @/var/lib/portables
ID 263 gen 26 top level 259 path @/var/lib/machines
@ArchangeGabriel did you set your btrfs subvolume used for /
as the default (i.e. btrfs subvolume set-default
)? I did not and maybe that is the culprit (doing it is also mentioned in the generator's man page).
No, I did not. Over I notice that you specified 3 time the subvol directive, not sure that’s a good thing (I know all three settings are correct, but ykk). My line is just:
/dev/mapper/root /sysroot auto subvol=@,x-systemd.device-timeout=9999h 0 1
@dvzrv re: doc: added to wiki home: https://github.com/random-archer/mkinitcpio-systemd-tool/wiki
@ArchangeGabriel ah, I believe that it is because your device opens as /dev/mapper/root
, mine as /dev/mapper/root0
.
The generator defaults to using root
as device according to their specification. I guess in my case the generator finds a btrfs device through device-mapper, but it is not able to mount it, because it is already mounted via root0 at that point in time.
Hi there,
Problem:
I keep experience a delay on system startup due to systemd not being able to load the root device (see
journalctl
output bellow). To be clear, the system does boot and eventually I reach a TTY to login to. Funnily though, my/boot
partition does not get mounted, I suspect this is due to the dependency on the root device.Any suggestions are welcome :smile_cat: !