| View previous topic :: View next topic |
| Author |
Message |
Cheesyjuggler64
n00b
Joined: 16 May 2024
Posts: 53
|
 Posted: Thu Jul 10, 2025 12:49 am Post subject: dev/mapper disappearing from /dev after switch_root [Solved] |
 |
|
I have an init script that decrypts a luks device and mounts it as cryptroot, however when swiitching to my actual init script it is no longer present.
devtmpfs options are on in the kernel
init
| Code: |
#!/bin/busybox sh
rescue_shell() {
echo "$@"
echo "Something went wrong. Dropping you to a shell."
# The symlinks are not required any longer
# but it helps tab completion
/bin/busybox --install -s
exec /bin/sh
}
busybox mount -t devtmpfs none /dev || rescue_shell "Error: mount /devtmpfs failed !"
busybox mount -t proc none /proc || rescue_shell "Error: mount /proc failed !"
busybox mount -t sysfs none /sys || rescue_shell "Error: mount /sysfs failed !"
cryptsetup luksOpen /dev/nvme0n1p3 cryptroot || rescue_shell "Failed to decrypt"
wait
mount -o rw,noatime,compress-force=zstd:3,ssd,space_cache=v2,subvol=/@ /dev/mapper/cryptroot /mnt/root || rescue_shell "Error: mount /root failed!"
echo "All done. Switching to real root."
umount /proc
umount /sys
umount /dev
exec switch_root /mnt/root /sbin/init
|
do I need to find it again or something, I may be misunderstanding but all devices prsently detected by the kernel should be copied into /dev because of devtmpfs?
help appreciated
Last edited by Cheesyjuggler64 on Wed Jul 16, 2025 6:39 pm; edited 1 time in total |
|
| Back to top |
|
 |
tholin
Apprentice
Joined: 04 Oct 2008
Posts: 208
|
| Posted: Thu Jul 10, 2025 9:24 am Post subject: |
|
|
This is probably https://bugs.gentoo.org/706434
Basically, if you have an initramfs without udev and instead use devtmpfs, then udev on the real root will not populate all the device nodes.
I have the same problem and work around it using the following file:
| Code: | /etc/udev/rules.d/09-DM-hack.rules
# fix for non-udev initramfs DM.rules
# without this /dev/disk/by-* are not populated on boot
# https://bugs.gentoo.org/706434
#
# 10-dm.rules checks DM_UDEV_PRIMARY_SOURCE_FLAG
#
ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}="1"
|
|
|
| Back to top |
|
|
user
Apprentice
Joined: 08 Feb 2004
Posts: 239
|
| Posted: Thu Jul 10, 2025 10:32 am Post subject: |
|
|
Hi Cheesyjuggler64,
did you check that umount /dev before swich_root successful executed? I have my doubts.
How about moving /dev to newroot?
| Code: | # mount -o move /dev /mnt/root/dev"
|
|
|
| Back to top |
|
|
zen_desu
Guru
Joined: 25 Oct 2024
Posts: 321
|
| Posted: Thu Jul 10, 2025 3:51 pm Post subject: |
|
|
| tholin wrote: | This is probably https://bugs.gentoo.org/706434
Basically, if you have an initramfs without udev and instead use devtmpfs, then udev on the real root will not populate all the device nodes.
I have the same problem and work around it using the following file:
| Code: | /etc/udev/rules.d/09-DM-hack.rules
# fix for non-udev initramfs DM.rules
# without this /dev/disk/by-* are not populated on boot
# https://bugs.gentoo.org/706434
#
# 10-dm.rules checks DM_UDEV_PRIMARY_SOURCE_FLAG
#
ACTION=="add|change", SUBSYSTEM=="block", KERNEL=="dm-[0-9]*", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}="1"
|
|
ugrd handles it like this:
https://github.com/desultory/ugrd/blob/2.0.1/src/ugrd/fs/fakeudev.py
Have you looked into patching this to handle this properly without udev? https://github.com/lvmteam/lvm2/issues/153
---
Maybe don't unmount /dev near the end: 'umount /dev'
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
zen_desu
Guru
Joined: 25 Oct 2024
Posts: 321
|
| Posted: Thu Jul 10, 2025 3:53 pm Post subject: |
|
|
| user wrote: | Hi Cheesyjuggler64,
did you check that umount /dev before swich_root successful executed? I have my doubts.
How about moving /dev to newroot?
| Code: | # mount -o move /dev /mnt/root/dev"
|
|
non-busybox switch_root should do this for you iirc
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
Cheesyjuggler64
n00b
Joined: 16 May 2024
Posts: 53
|
| Posted: Wed Jul 16, 2025 6:39 pm Post subject: |
|
|
| Yeah the move option worked it seems that mdev doesn't handle /dev/mapper devices by default and therefore it wasn't loading it properly when my init script was being ran, the move option fixed this, on another note on another note @zen_desu has there been any progress in implementing TPM2 to ugRD |
|
| Back to top |
|
|
zen_desu
Guru
Joined: 25 Oct 2024
Posts: 321
|
| Posted: Wed Jul 16, 2025 7:18 pm Post subject: |
|
|
| Cheesyjuggler64 wrote: | | Yeah the move option worked it seems that mdev doesn't handle /dev/mapper devices by default and therefore it wasn't loading it properly when my init script was being ran, the move option fixed this, on another note on another note @zen_desu has there been any progress in implementing TPM2 to ugRD |
not much progress, I started making a mechanism to handle key creation/enrolling similar to clevis, but I think using the "token" mechanism of cryptsetup, if possible, would be best. I personally prefer to use my yubikey, so am not really itching to add that feature (myself) for any reason other than to learn. Here's the (super half baked) implementation currently: https://github.com/desultory/cattleguard it's mostly just some python wrappers for tpm2 tools
If you're interested in trying to make this happen, I'm happy to help with the module writing process. Theoretically this could be implemented mostly as a "key command" which hooks into the cryptsetup module. The way it current works, is that a "key command" is used to create the "key data" file which is passed to cryptsetup as the --key-file. This works, but writes the key data to a temporary file which is cleared later, and nuked before ugrd does switch_root. Not ideal, but not the worst thing either. Tokens seem like a more elegant solution, but I struggled to find any implementation other than systemd cryptenroll/similar.
https://github.com/desultory/ugrd/blob/2.0.2/src/ugrd/crypto/cryptsetup.py#L520
_________________
µgRD dev
Wiki writer |
|
| Back to top |
|
|
|
Kernel & Hardware
