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
