grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems

grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems

[Thomas Schmitt]

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

Re: grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems

[Daniel Kiper]

Hi,

CC-ing Vladimir...

On Wed, Dec 18, 2019 at 07:24:45PM +0100, Thomas Schmitt wrote:
> 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.

It does not seem like reasonable idea.

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

Where this automatic change should happen? grub-mkrescue or libisofs?

> [ ] 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.

What kind of duties do you think about?

> 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.

I do not see any reason to have labels for EFI FAT filesystem. Do you?

Daniel

Re: grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems

[Thomas Schmitt]

Hi,

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

Daniel Kiper wrote:
> Where this automatic change should happen? grub-mkrescue or libisofs?

In libisofs. The decisive code gesture is in Vladimir's contribution
  https://sources.debian.org/src/libisofs/1.5.2-1/libisofs/hfsplus.c/#L1632

If agreed on, i would change

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

to something like

  char *hfs_label;
  hfs_label = calloc(1, strlen(target->image->volume_id) + 8 + 1);
  sprintf(hfs_label, "%s%s", target->image->volume_id, "_HFSPLUS");
  ret = set_hfsplus_name (target, hfs_label,
                          &target->hfsp_leafs[target->hfsp_curleaf]);
  free(hfs_label);

and publish a new development snapshot of GNU xorriso so that interested
grub-mkrescue users can immediately make use of the change.


> > [ ] 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.

> What kind of duties do you think about?

The duty of creating a separate label for the HFS+ aspect, of which they might
not even be aware.
Users of grub-mkrescue can set the ISO 9660 label (Volume Id) by xorrisofs
option -V. If the HFS+ label shall become independent of this, then they need
to care for using a version of xorriso to which they can submit their desired
HFS+ label. (The new option would probably be named "-hfsplus-label".)


> I do not see any reason to have labels for EFI FAT filesystem. Do you?

I got new insight and unexpected influence on that topic.
It might be better to have a non-empty label. Overall the situation is messy
but with good hope for improval.

The current versions of udev in the wild misattribute the label of the
filesystem on the "parent" device (e.g. /dev/sdd) to any partition device
which bears no own filesystem label.
Since a few years, program lsblk uses the udev results for its own display.
So what should currently look like

  NAME    SIZE FSTYPE  TRAN LABEL
  sdc     1.9G iso9660 usb  ISOIMAGE
  |-sdc1  136K
  |-sdc2  2.8M vfat
  |-sdc3 11.8M hfsplus      ISOIMAGE
  `-sdc4  300K

rather looks like

  NAME    SIZE FSTYPE  TRAN LABEL
  sdc     1.9G iso9660 usb  ISOIMAGE
  |-sdc1  136K              ISOIMAGE
  |-sdc2  2.8M vfat         ISOIMAGE
  |-sdc3 11.8M hfsplus      ISOIMAGE
  `-sdc4  300K              ISOIMAGE

All five are racing for becomming target of the /dev/disk/by-label/ISOIMAGE
link. /dev/sdc never wins.

The race between ISO 9660 and HFS+ is the least harmful, because both
filesystems are supposed to present the same file tree. Nevertheless i
propose to end it.
The race between ISO 9660/HFS+ and VFAT is more problematic, because the
tree in the EFI partition differs completely from the ISO's.
The race between the not-mountable partitions and the others is of course
the worst.

We can take HFS+ and VFAT out of the race and thus sanitize their
presentation by udev and its dependends. We cannot take ISO 9660 out of
the race. This can only be done by an improved udev rule.

By my complaint on systemd's GitHub appearance and the substantial help of
Daniel Drake this improved rule is in systemd/udev upstream now:
  https://github.com/systemd/systemd/commit/19212f27816686a5cac2c965301cea8624ac467f
This led to the reversion of last december's workarounds in blkid, which
first were potentially harmful for grub-mkrescue's payload and later would
not have corrected the misperception of its partitions without label:
  https://github.com/karelzak/util-linux/pull/913

But for a few years we have to expect the old buggy udev rule to be around.
It might be a nice gesture to grub-mkrescue users to take the vfat partition
out of the inappropriate race by giving it some label. E.g. some characters
out of existing grub-mkreacue.c variable "iso_uuid", which is a timestamp.

HFS+ will be out of the race after it got a label that differs from ISO 9660.

I think the following would be the best preparation for current udev:

  NAME    SIZE FSTYPE  TRAN LABEL
  sdc     1.9G iso9660 usb  ISOIMAGE
  |-sdc1  136K              ISOIMAGE
  |-sdc2  2.8M vfat         60206114747
  |-sdc3 11.8M hfsplus      ISOIMAGE_HFSPLUS
  `-sdc4  300K              ISOIMAGE

(The iso_uuid of this image is "2016-02-06-11-47-47-00". man mformat says
that option -v takes up to 11 characters. I propose to use the last digit
of the year and then all digits of month, day, hour, minute, seconds.)

In this proposal, "ISOIMAGE" would be a parameter set by the user of
grub-mkrescue via xorrisofs option -V.

The VFAT label would of course have to be set by grub-mkrescue's run of
program mformat. One could introduce a grub-mkrescue option which
overrides the automatic setting of iso_uuid from time(), or one could
let environment variable SOURCE_DATE_EPOCH override time().
  https://reproducible-builds.org/docs/source-date-epoch/

xorriso is prepared to obey this variable as default value, but overrides
it by own options if they are given.
(E.g. the --modification-date= set by grub-mkrescue currently overrides
 the SOURCE_DATE_EPOCH time.)


Have a nice day :)

Thomas