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