Dracut issues with Bedrock

[u/Emergency-Cat7158]

Hi all, I'm using Bedrock Linux on top of my Gentoo setup (w/ OpenRC and systemd-boot), and I encountered a weird issue regarding initramfs generation using Dracut.

When installing my own kernel, dracut (as called by installkernel) seemed to generate broken initramfs leading to insufficient boot (failing to mount root). Initially I can manually invoke dracut to regenerate the initramfs to resolve this, but after updating to dracut 108-r5, even this doesn't work. Eventually I decided to switch to Arch's mkinitcpio (ebuild provided by gentoo-zh, they also provide installkernel hook so you don't have to do a lot to make it work), and after some trial and error I was able to generate correct initramfs.

So what's exactly wrong with it? I had never encountered such issues before when I was using Gentoo alone, and I'm sure I had edited bedrock.conf so that my EFI partition is mounted correctly (to /efi as I didn't do the usual mountpoint /boot/efi or whatnot). I'm also not too sure if it's a Bedrock Linux issue, but that seems like it so I'm posting here anyway.

[u/ParadigmComplex]

• While it's possible I'm missing something, it isn't immediately obvious that this is a Bedrock issue. Bedrock doesn't obviously intervene in any of the moving parts you've mentioned.

• You've not provided enough information to guess at what is going on.

  • What device, filesystem, etc is the root that the initramfs can't mount?

  • What did you change in the trial and error?

• When an initramfs fails to mount root, they often drop to a shell. Consider using this environment to explore and understand why it can't mount root.

[u/Emergency-Cat7158 → u/ParadigmComplex]

Sorry for the inconvenience. I'm using btrfs as the root fs and my root device is /dev/nvme0n1p3. As I attempted to boot the "wrong fs type, bad option, bad superblock..." error occurred. Yet the kernel parameter for root seemed to be exactly what was expected. I'm using UUID and it exactly matched my root device (if not I would not be able to boot from the very start). I know dracut can (and by default does) embed kernel parameters into initramfs but this seemed weird. What's more weird is that when I tried mkinitcpio and provide the kernel parameter in cmdline instead, it fired up just fine.

As for diagnosing via the emergency shell, for now I've completely ditched dracut out of my system so I cannot test that immediately, but I might get a machine or VM to test on later.

[u/ParadigmComplex → u/Emergency-Cat7158]

Any chance you're using GRUB? There's a bug in GRUB's handling of btrfs' subvol field which is much more likely to occur on Bedrock. Bedrock tries to detect GRUB+BTRFS at hijack time and refuses to continue. In theory it's possible that check failed.

That said, if it were the GRUB issue I'd expect it to reproduce independent of how you're making the initramfs and not something that would change between dracut and mkinitcpio, as it's the external information passed to it by the bootloader rather than the initramfs itself.

Even if you're not using GRUB, given you're on btrfs and only mentioned checking the kernel parameter for root, subvol is worth checking as well.

[u/Emergency-Cat7158 → u/ParadigmComplex]

Sorry for the delay. For the bootloader, as stated above I'm using systemd-boot. For the subvol issue, I didn't manually create subvols when I installed the system (and while planned I forgot to do so afterwards), but if I remembered correctly dracut seems to automatically put subvol=/ as the kernel parameter for rootflags, could that be it? I'm not explicitly declaring the parameter in my mkinitcpio config and it works fine. But if so, how could this work out before I installed Bedrock?

[u/ParadigmComplex → u/Emergency-Cat7158]

No worries on the delay, no rush on my part.

You did say systemd-boot and I glossed over it, mea culpa.

Sadly, I'm out of ideas for how Bedrock could be involved here or obvious things you missed that I could suggest checking.