[gentoo-dev] Re: newsitem: unmasking udev-181

[Duncan <1i5t5.duncan@cox.net>]

Robin H. Johnson posted on Sun, 11 Mar 2012 23:14:46 +0000 as excerpted:

> On Sun, Mar 11, 2012 at 11:03:50PM +0000, Duncan wrote:
>> Meanwhile, also note that there's PARTLABEL, PARTUUID and ID, that the
>> mount manpage promises to honor.  I've not used these myself, but there
>> was a thread on the btrfs list discussing GPT format and users of its
>> partition-labels (as opposed to filesystem labels), that pointed out
>> that mount honors these, since it internally uses the udev symlinks
>> mechanism to support (fs) labels, etc, so they get support for
>> gpt-partition- labels, etc, essentially "for free".

> What manpage are you reading?
> # man 8 mount |grep PART # man 2 mount |grep PART Nada.
> 
> When the blkid tool can read PARTUUID/PARTLABEL, then it will just work
> with genkernel, as we use blkid for doing that.

mount (8) under device indication:

>>>>>

Most devices are indicated by a file name (of a block special device), 
like /dev/sda1, but there are other possibilities.  [...] It is possible 
to indicate a block special device using its volume LABEL or UUID (see 
the -L and -U options below).

The recommended setup is to use LABEL=<label> or UUID=<uuid> tags rather  
than /dev/disk/by-{label,uuid} udev symlinks in the /etc/fstab file. The 
tags are more readable, robust and portable.  The mount(8) command 
internally uses udev symlinks, so use the symlinks in /etc/fstab has no 
advantage over LABEL=/UUID=.  For more details see libblkid(3).

<<<<<

As I said, it wasn't apparent to me until someone pointed it out to me on 
the btrfs list, but apparently, mount understands SOMETHING= as 
referencing /dev/disk/by-something, using those symlinks internally, so 
while the manpage doesn't specifically mention PARTLABEL, etc, according 
to that person, it "just works".  Upon seeing that claim, I reread the 
manpage, and sure enough, that meaning can be seen "between the lines" if 
you already know to look for it.

I had intended to try it, since I use gptfdisk and gpt partitions pretty 
much universally now, and referencing the PARTLABEL would have meant that 
I could for instance do a mkfs and redo my backup partitions without 
having to update fstab's labels because I could use the partlabels 
instead.  Unfortunately, when I actually checked to see what symlinks 
udev was putting in /dev/disk/by-partlabel, while indeed the gpt 
partlabels for the physical disks were there, the partlabels for the
gpt-partitioned md/raid devices were NOT, and that's what I actually 
needed, so unfortunately I couldn't try using partlabels after all.  
That's why I've yet to actually verify the claim.

At some point I'll probably verify it with a USB attached external drive, 
as it's my last-resort backup, and/or on my netbook, with only one drive 
so no raid, but I've not gotten that far, yet.


FWIW, the thread started with someone complaining that a btrfs label on a 
multi-device filesystem (since btrfs can do that) was attached to the 
filesystem, NOT the device/partition.  Various people pointed out that 
it's a filesystem label and that btrfs thus had it correct.  Meanwhile, 
on one subthread I pointed out gpt partition labels as an alternative, 
but said I didn't think Linux could actually do much with them yet.  
That's when someone else replied that it could do more than I thought, 
mount and fstab handled partlabel, and he thought the kernel root= 
parameter could take it as well.

Here's his post on gmane:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/16023

As I said, after reading that, rereading the mount (8) manpage, it /did/ 
seem to hint that it should do so even if it doesn't outright say it, 
since it specifically mentions using udev's symlinks internally.

But as I've not tried it yet I have only his post and my reparsing of 
that manpage based on it, to go on.  Is it incorrect?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman