Missing `/dev/disk-by-*` folders (/dev/disk-by-uuid/ /dev/disk-by-partlabel etc)

I don't have on my system (OpenWrt SNAPSHOT, r19726-b21b98627d netgear xr500):
folders/devices links:

/dev/disk-by-id/        
/dev/disk-by-partlabel/ 
/dev/disk-by-partuuid/  
/dev/disk-by-path/      
/dev/disk-by-uuid/ 

is there a way to install them ? Am I missing a package

1 Like

Not really, OpenWrt doesn't use udev.

:frowning: is there a way to use UUIDs in commandline ?

As a workaround to hotplug.d not executed issue
I thought to create a custom script with decryption command.

But as /dev/sda is sometimes detected as /dev/sdb (2 usb devices) I wanted to use UUIDs

but it's complaining:

root@OpenWrt:/home/marcin# cryptsetup luksOpen UUID="4a3e4e1f-ee73-43dd-8269-4a2a9549c3a7" crypt --key-file /a-path-to-keyfile 
Device /dev/disk/by-uuid/4a3e4e1f-ee73-43dd-8269-4a2a9549c3a7 does not exist or access denied.

/dev/sd* way works but it's unrelalible in my case (2 usb devices):

root@OpenWrt:/home/marcin# cryptsetup luksOpen /dev/sdb4 crypt --key-file /a-path-to-keyfile
root@OpenWrt:/home/marcin# ls /dev/mapper/
control  crypt
1 Like

Similar problem here, /dev/mmcblk2 is sometimes enumerated as /dev/mmcblk0 and vice versa. One is SD card, one is eMMC. I need something static I can pass to the linux kernel as root filesystem parameter instead of root=/dev/mmcblk2p2. ARM machine, sun8i-h3-cortexa7 orangepi-plus-2. (I need a way that makes it already working at boot time when the kernel first probes the devices, that it generates deterministic device names.)

Back when I setup auto-mount for a usb drive to save log data and stats to, mounting by UUID was an option in Luci and I selected it. I think I was on version 21.xx then. Looking at Luci on 22.03 rc1 it is "Mount Points" under the System menu. https://192.168.1.1/cgi-bin/luci/admin/system/mounts.

An excerpt from my uci config shows it and possibly what might be tracking config to remount on inserting the usb device:

fstab.@mount[0]=mount
fstab.@mount[0].enabled='1'
fstab.@mount[0].target='/mnt/usb-flsh-p1'
fstab.@mount[0].uuid='811E-1A0A'
ucitrack.@fstab[0]=fstab
ucitrack.@fstab[0].exec='/sbin/block mount'

I think uci also creates the /etc/config/fstab file with the same info.

It looks like you can get the UUID from lsblk -f

NAME        FSTYPE   FSVER LABEL       UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
loop0       f2fs           rootfs_data b36c4dac-6d3d-4d58-8063-7c139871ffcb    9.6M    90% /overlay
sda                                                                                        
├─sda1      vfat           RDATA       811E-1A0A                               9.4G     0% /mnt/usb-flsh-p1
└─sda2      vfat           P2          69A8-19E8                                           
mmcblk1                                                                                    
├─mmcblk1p1 ext4           kernel      84173db5-fa99-e35a-95c6-28613cc79ea9                
└─mmcblk1p2 squashfs                                                              0   100% /rom

I think I installed lsblk so you may also need to in order to get the filesystem UUID unless there is an existing utility that shows the filesystem UUID and not the the UUID for the partitions or disk etc.

I hope this helps you.

Back when I setup auto-mount for a usb drive to save log data and
stats to, mounting by UUID was an option in Luci and I selected it.
I think I was on version 21.xx then. Looking at Luci on 22.03 rc1 it
is "Mount Points" under the System menu.

In 22.03 I have it in LuCi.

But this does not help for my problem where the root device for bootup
is concerend. root=/dev/mmcblk2p2 is passed from the u-boot bootloader
to linux. I can change that, but only to any static device node, since
linux does not provide by itself /dev/disk/by-uuid/* and so on, and
we have no initrd or so in OpenWrt that could handle generating that
files in userspace before continuing boot process.

Ah, I see. Sorry that I didn't pick up on that on my first read.

I'm a novice but encrypting more of the file system has been an interest of mine so I have been looking into the system more.

I'll offer a few more tidbits in case they are of use.

It looks like my platform, FriendlyElec NanoPi R4S, seems to boot by PARTUUID reference, there may be hope for your platform.

[ 0.000000] Kernel command line: console=ttyS2,1500000 earlycon=uart8250,mmio32,0xff1a0000 root=PARTUUID=5452574f-02 rw rootwait

I don't know if this documentation refers to the initial kernel image or not but I mention it so you are aware of it. It describes early state and pre-init.

OpenWrt does load the kernel from an initial image so you might be able to build a custom image with the kernel options and mods that you need.

Good luck! Please update this post if you find / develop a solution.
Thanks.

Thanks, I did not know about PARTUUID. This did completely solve the problem for me. From U-Boot, I could get the partition UUID by part uuid mmc 1:2. Now I also use this command line option to specify the root device.

Regards!

1 Like

There should be even automagic possible with U-Boot -- which would survive re-partitioning/ partition re-creation:

part uuid mmc 1:2 partuuid
setenv bootargs earlycon=uart8250,mmio32,0xff1a0000 root=PARTUUID=${partuuid} rw rootwait

(part uuid mmc 1:2 partuuid reads the UUID into the variable partuuid.)

So if we regularly flash a complete new image with newly created partitions, we leverage that for U-Boot the device ID stays stable, to translate it into a UUID which is for Linux a predictable thing to get predictable booting even when the UUID might change over an upgrade.

1 Like