root-remount fails on certain occasions

[Stargirl-chan]

For context, my system setup is a bit special. It uses a custom kernel, uses f2fs as rootfs and boots with efistub using no initramfs / initrd.

f2fs support is compiled as built-in into my kernel:

> zgrep -i f2fs /proc/config.gz
CONFIG_F2FS_FS=y

And the root disk is giving as PARTUUID:

cat /proc/cmdline
quiet root=PARTUUID=dcb5b027-a023-4043-ae61-d608c5932f7c <other unrelated stuff>

On system boot, the root-remount script fails with following error message:

mount: /: can't find PARTUUID=dcb5b027-a023-4043-ae61-d608c5932f7c`

Despite blkid successfully reporting it for my disk:

> blkid | grep nvme0n1p2
/dev/nvme0n1p2: LABEL="system" UUID="ccfce50c-3ca1-480d-80dd-4e8d67384223" BLOCK_SIZE="4096" TYPE="f2fs" PARTUUID="dcb5b027-a023-4043-ae61-d608c5932f7c"

A fix to this issue is changing:

exec mount -o remount,${dinit_early_root_remount:-ro,rshared} /

To:

exec mount -o remount,${dinit_early_root_remount:-ro,rshared} / /

I do not know why adding the extra / is needed and I am seeing if I can reproduce it in a VM using ext4 as fs. It might just be a specific f2fs quirk, however, adding an extra / to the end of the mount command causes no issue for ext4 or xfs

[nekopsykose]

i think passing the extra / ends up using something other than the thing that ends up looking up the partuuid at all (fstab?). you can strace the difference to see that it ends up looking at different things (for / /, seems to be some fancy open_tree and other things?)

the core issue is still that partuuid detection fails somehow so the workaround doesn't really matter