Talk:Persistent block device naming

systemd-boot entry with label

Should we add a systemd-boot entry using LABEL to the bottom section? --Betseg (talk) 15:17, 29 July 2015 (UTC)

Could do, but it might also be worthwhile to consider slim down that section and crosslink more instead. Or, as a first step, you could convert the LABEL example at the end to a systemd-boot one and crosslink it to Systemd-boot#Standard root installations for the additional info there. --Indigo (talk) 20:35, 29 July 2015 (UTC)

Plus, there is already Kernel parameters#Configuration. -- Lahwaacz (talk) 06:20, 30 July 2015 (UTC)

udev rule to add gpt partitioned disk to disk/by-uuid

I added the following to the page today:

To have not only partitions but also (GPT partitioned) disks appear under /dev/disk/by-uuid you can add the following udev rule:

ENV{DEVTYPE}=="disk", ENV{ID_PART_TABLE_UUID}=="*", SYMLINK+="disk/by-uuid/$env{ID_PART_TABLE_UUID}"

Another user reverted my edit, giving the reason, that by-uuid is for filesystem uuids. I could not find any definitive source for this claim. And even if it is true, that this "is so", then the question is still, whether the status quo is what needs to remain. zfs adds /dev/zd* and /dev/zvol/* to the mix, other kernel modules add other device nodes. What makes up /dev does change over time.

And the other options (/dev/disk/by-path and /dev/disk/by-id) do contain both the disk itself and the partitions. Of course by-uuid contains only filesystems that have uuids and cannot contain those that do not. And even filesystems that do have a UUID might have all kinds of content and need special treatment that someone who uses /dev/disk/by-uuid needs to handle. So is there anything that speaks against making that change?

And more importantly, people who land on this page are looking for a way to make accessing their devices persistent, including disks and not just filesystems. A responsible user should have the option to choose whether she wants to have her system behave in the traditional way or in some custom way. But a responsible user cannot make this choice, if pages such as this one, do not inform her of the possibility.

If it is dangerous or against convention, then that should be mentioned and the user should be warned. But I mean this forum is full of unconventional solutions to all kinds of problems, so why not allow it in this case?

—This unsigned comment is by Devvymoniker (talk) 15:03, 12 September 2024 (UTC). Please sign your posts with ~~~~!

Sorry, but it's wrong to step into defined/established territories. It's OK to add a new subdir under /dev/disk/ for this, but /dev/disk/by-uuid/ is clearly for filesystem UUIDs. Note that it isn't remotely comparable to any GPT concept. At the very minimum this should be under disk/by-partuuid (even then you're confusing completely different stuff though, as the naming is clear on "part").

I don't know how this strawman over "customizability" and "responsibility" came to be BTW. It's completely fine to do this properly, by introducing its own concept under a new dir. You can even submit this to the upstream if appropriate. But reusing by-uuid is simply not feasible.

-- YHNdnzj (talk) 16:38, 12 September 2024 (UTC)