asynchronous device name allocation -> persistent naming

[rufwoof]

My understanding is that udev assigns device names asynchronously - randomly. So in /etc/rc.d/rc.local (Fatdog 8.2) I've added code to map (sym link) /dev/hdd to /dev/sda1 (or sdb1) assuming that is my HDD, and /dev/usb to the usb I use to boot (sdb1 (or sda1)). Pretty much (one choice of) standard practice to ensure you access/write-to where you intended. i.e. look for a file on /mnt/hdd instead of /mnt/sda1 (that due to async naming could alternatively be /mnt/sdb1).

Mostly device names can remain the same if you boot the exact same way each time, but there are no guarantees and even a simple change such as adding in a pkeys=uk kernel boot parameter can result in the device names changing.

My question is, can the desktop drives, sda1, sda2 ...etc be easily modified to instead show the sym-linked names (hdd, usb ...etc.)?

Or alternatively is there a (easy) way to make device names persistent? I did have a play with writing udev rules for that, without success.

As-is my rc.local code is (highly) bespoke. Would be nice if that could be replaced with a alternative that was more generic.

[rufwoof]

... silence. So I'll just post some observations about using udev (under Fatdog 8.2)

Inspect a device such as sda1 using ...

Code: Select all

udevadm info -a -p  $(udevadm info -q path -n /dev/sda1)

Pick a appropriate existing file (or add a new one) into the udev rules folder i.e. /etc/udev/rules.d/...

where the command above helps you identify a specific device. i.e for my sda1 the size was indicated as 953319424 so I used that for identification

SUBSYSTEM=="block", ATTRS{idVendor}=="ATA", ATTR{size}=="953319424", SYMLINK+="your_device_name"

Once you've created/edited the udev rule then reload the udev rules with

Code: Select all

udevadm trigger

That aside, I've personally opted to just have a entry in /etc/rc.d/rc.local that creates a symbolic link for /mnt/hdd that links to either /mnt/sda1 or /mnt/sdb1 according to whichever is determined to be the actual hdd in question ... and not bother with udev rules.