All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: grub-devel@gnu.org
Subject: grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems
Date: Wed, 18 Dec 2019 19:24:45 +0100	[thread overview]
Message-ID: <1221694109649607190@scdbackup.webframe.org> (raw)

Hi,

during tests about the changes in blkid which are still discussed in
  https://github.com/karelzak/util-linux/pull/913
i noted that a grub-mkrescue ISO for x86 BIOS and EFI shows the same
filesystem label with its ISO 9660 and HFS+ filesystem superblocks.

  # lsblk -o NAME,FSTYPE,LABEL /dev/sdd
  NAME   FSTYPE  LABEL
  sdd    iso9660 ISOIMAGE
  ├─sdd1
  ├─sdd2 vfat
  ├─sdd3 hfsplus ISOIMAGE
  └─sdd4

On Linux this causes a name collision when udev creates /dev/disk/by-label
links. Usually HFS+ wins. But that's not guaranteed.

The label identity is currently hardcoded in libisofs. The code stems from
Vladimir Serbinenko. I am in charge of maintaining it, though.
See
  https://sources.debian.org/src/libisofs/1.5.2-1/libisofs/hfsplus.c/#L1632

  ret = set_hfsplus_name (target, target->image->volume_id,
                          &target->hfsp_leafs[target->hfsp_curleaf]);

It looks like the Volume Id from the libisofs ISO 9660 model is set as
name of HFS+ node target->hfsp_leafs[0]. I guess this is the root node.

Whatever, it is the only occurence of volume_id in Vladimir's code.
Thus this line must be the gateway of "LABEL" between libisofs settings
and HFS+ metadata production. ("ISOIMAGE" is the default Volume Id of
xorriso.)

--------------------------------------------------------------------------

So what to do ?

[ ] Leave both labels identical and continue to confuse users via udev.

[ ] Change HFS+ LABEL automatically by adding "_HFSPLUS" to the upto 32
    characters of Volume Id.

[ ] Have independent setting and default of HFS+ LABEL in libisofs.
    This is most flexible but also creates new duties for the users of
    grub-mkrescue, if both LABELs have to be unique in comparison to other
    filesystems on other devices.

I would vote for the middle alternative, if i had any experience with HFS+
beyond hosting Vladimir's code in libisofs.

Vladimir ? Anybody else with HFS+ experience ?

--------------------------------------------------------------------------

Further:

Should grub-mkrescue give the EFI FAT filesystem a LABEL, too ?

man mformat says about option -v
   v      Specifies the volume label. A volume label identifies  the  disk
          and  can  be  a  maximum  of  11  characters. If you omit the -v
          switch, mformat will assign no label to the disk.

"GRUBMKR_EFI" ?

On the other hand, no LABEL means no label problems.


Have a nice day :)

Thomas



             reply	other threads:[~2019-12-18 18:23 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-18 18:24 Thomas Schmitt [this message]
2020-01-17 13:25 ` grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems Daniel Kiper
2020-01-17 15:36   ` Thomas Schmitt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1221694109649607190@scdbackup.webframe.org \
    --to=scdbackup@gmx.net \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.