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 _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
