Is mkinitrd with Btrfs root subvolume still broken?
 

Hi everyone,

recently I decided to switch from the huge kernel to the generic kernel.
Usually I stick with the huge kernel because I'm too lazy to build an initrd and the huge kernel has always worked flawlessly for my needs (I don't use LUKS+LVM or any other configuration that needs an initrd).

Despite that, few days ago I decided to make the jump and I installed the generic kernel.
I used mkinitrd_command_generator.sh, I read /boot/README.initrd and I used mkinitrd --help in order to generate a proper command line.

But, when I rebooted my machine the boot failed because the initrd's init script was not able to launch /sbin/init, due to the fact that my root is on top of a Btrfs subvolume.


My current configuration is:
__current/ROOT ==> /
__current/HOME ==> /home
__snapshots/ROOT ==> /.snaps
__snapshots/HOME ==> /home/.snaps
<snapshots subvolumes>

In order to make the kernel aware of this configuration, I added the rootflags=subvol=__current/ROOT parameter to the boot command line, but the initrd seems to ignore it.

So, I decided to investigate and I noticed that the init script actually parses the command line from /proc/cmdline, but it ignores rootflags and it mounts the root with the only "ro" mount option.

And this behavior breaks the boot because /mnt will not contain the real root but the __current and __snapshots subvolumes.


There are two workarounds to avoid this bug:
1) Generating first /boot/initrd-tree, patching init and then generating the gz-compressed image;
2) Set __current/ROOT as the default subvolume in order to mount the subvolume automatically when no subvol flag is passed to the mount command line.

But there is a problem with the latter "solution": it does not really solve the bug.
Indeed if I boot from a snapshot the initrd will still mount __current/ROOT and not __snapshots/ROOT/ROOT@<description>, because it will still ignore the rootflags= parameter and it will mount my Btrfs pool with the default subvolume aka __current/ROOT.

So, the only viable workaround seems to be the first one.

Since it seems to be a known bug, are there any hopes to see it fixed?

Cheers,
Luca De Pandis