koverstreet / bcachefs-tools

http://bcachefs.org
GNU General Public License v2.0
116 stars 88 forks source link

Mounting an encrypted bcachefs rootfs from an initrd troubles. #292

Closed 0xBOBF closed 1 month ago

0xBOBF commented 2 months ago

I've been having issues when trying to mount an encrypted bcachefs rootfs with an initrd on Slackware. This is with kernel 6.9.3 and bcachefs-tools 1.7.0. What happens is that the "ask policy" for 'bcachefs mount' is failing to ask for the password, leaving only the "wait policy" to work. When the ask policy fails, it ends up reporting the unhelpful error:

ERROR - bcachefs::commands::cmd_mount: Fatal error: No such device or address (os error 6)

The problem is the console in the busybox initrd is not a tty, so it fails the "is_terminal" check in bcachefs-tools/src/key.rs.

I can get the ask policy working by prefacing the bcachefs mount command in busybox with the following (where ROOTDEV is my UUID= string from my encrypted multidevice bcachefs root filesystem): setsid cttyhack /sbin/bcachefs mount -o read_only $ROOTDEV /mnt

With the 'setsid cttyhack' bit, the "is_terminal" check passes and I get prompted for the password. Without it I get "os error 6". Note I referenced busybox's FAQ here for that hint about the tty: https://busybox.net/FAQ.html#job_control

What is strange/inconsistent is that I can use "bcachefs unlock" and then "bcachefs mount -k wait" without having to be a tty terminal in the initrd, but to use "bcachefs mount" directly with asking for the password, I have to something like the above with cttyhack.

A side note: It would be nice if "bcachefs unlock" could unlock by UUID too. I had to switch to UUID because udev kept changing my device node names around and causing mounting by device nodes to occasionally fail. The UUID consistency is better, but that means having to use "bcachefs mount", with these ask policy troubles in the initrd.

Do what you will with the issue report here. I've seen a few reports of troubles with mounting encrypted bcachefs root filesystems with initrds and wanted to share my findings here.

tmuehlbacher commented 2 months ago

Could you check if you're still having any of these issues with v1.9.1?

tmuehlbacher commented 2 months ago

Sorry nevermind, the points you're making are only marginally improved now. Does your udev also create links like /dev/disk/by-uuid/...? In that case that may be a quick fix to be able to use bcachefs unlock.

0xBOBF commented 2 months ago

Could you check if you're still having any of these issues with v1.9.1?

I tried with version 1.9.1 and bcachefs mount still fails in the same way with regards to failing to ask for password due to the tty check. Using the 'cttyhack' method works for a workaround.

Sorry nevermind, the points you're making are only marginally improved now. Does your udev also create links like /dev/disk/by-uuid/...? In that case that may be a quick fix to be able to use bcachefs unlock.

/dev/disk/by-uuid/... works as expected and can also be used as a workaround to get bcachefs unlock to unlock the device, followed up by mount or bcachefs mount -k wait after unlocking.

I was trying to get bcachefs mount to work since its one step to unlock and mount, vs. two steps with unlock and then mount. Both bcachefs mount and mount -t bcachefs fail to ask for the password in the initrd environment without a workaround using cttyhack, or using two steps with bcachefs unlock first, then a separate mount.