From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1isTg7-0000l6-Ex for mharc-grub-devel@gnu.org; Fri, 17 Jan 2020 10:36:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:37778) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1isTg1-0000hi-PA for grub-devel@gnu.org; Fri, 17 Jan 2020 10:36:53 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1isTfx-00081t-MD for grub-devel@gnu.org; Fri, 17 Jan 2020 10:36:49 -0500 Received: from mout.gmx.net ([212.227.15.19]:52875) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1isTfx-0007yq-8T for grub-devel@gnu.org; Fri, 17 Jan 2020 10:36:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1579275402; bh=QGGswZkeoGJj05O0DNIGlePzF5PjbQ7oujXwa0gZGtg=; h=X-UI-Sender-Class:Date:From:To:Subject:Cc:References:In-Reply-To; b=RH27c+NlNRwO67G4IXSlNlJXuk1aeVTEZlO/t1V1JzPHcB7J1Udac3eRvV7id9hH4 FTPLNDIvQ2RvTBF6+FodaEDMCNZDfP1Z/anol/2lx7nMMlLbfOmIA6tV/p6nV7qt5c u3k/8kXe2EN9f8CJoYUa+BZNV5NPQkZg1cnAfkeU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from scdbackup.webframe.org ([91.8.168.145]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MC34h-1imk7Q3WRx-00CPTK; Fri, 17 Jan 2020 16:36:41 +0100 Date: Fri, 17 Jan 2020 16:36:51 +0100 From: "Thomas Schmitt" To: grub-devel@gnu.org Subject: Re: grub-mkrescue: The blkid LABELs of its ISO 9660, HFS+, FAT filesystems Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Cc: phcoder@gmail.com, dkiper@net-space.pl References: <20200117132547.elmaeehbyypwwznz@tomti.i.net-space.pl> In-Reply-To: <20200117132547.elmaeehbyypwwznz@tomti.i.net-space.pl> Message-Id: <17113713359279175539@scdbackup.webframe.org> X-Provags-ID: V03:K1:lFrl2MaOOjaTrS95B4pc4lxzCxWKdna+yM6ToBYETE5Ee1XszOo rsnfNbEAoRDlNs//8618LlC6OotU1ME88JWAC+FvBS3QXD7pmjrmG94lj7qrxOOlsF7IPrs Iqbskmb0Oi31AkSdi1P3C3nZfifIOJwV0IsBZdYObVzcqcFI7htTMKdXi9iJKqIokXOT3av si8B78PvPQocFUTodyTiA== X-UI-Out-Filterresults: notjunk:1;V03:K0:pY4YJV1SM1E=:knFQZmDfGK/arGB5epdju3 C4zYo6Wiwnjo6/HCpPiKp95lfEsqxDyJ724Oj7xRhQtcPMaQTyREcWN39URFFRAzFWe2bcYs7 yRMDa3mWwz0pleVI6aEPKSt4Rb4YgJl1VKUOU7P7LPlJC7oMI5PuYonYfej2zKXSKvtTdQVKg 1+LSWwqoALl8brCye7T3EbnHfFaignHH49HNplMLdTpPG1v6UyOmOOMW1I862FOY0M2zShOfE ee5GuCh5kYTKUd5bGpjrKQd86CSdLG9ADozhF2cMss70LXYvkQEg2/Kt043Zx3/sClfFJFl9t ZQEgl3Fa8QJ79HDhGj6jNkDuOo6MsGhPTXLy48FBWiSV2zAUy/FBpnoei6asB71pz+moOCjJ+ pMSR15I4nyYiVKRfpe17mQabhugKsRlU+ZW75TgUP1M5Orq1OqiiP3+ELyp9BMrev7jKZN0+C T1SdBYt8lDMshx64/eQy3jiliZpY3mWTaFG0tcitWxR+A9eqJWlqEOYCU1/T/iYHR8Jmb5dbm Rttv/PqkOB2szMLeuvY/nGBCUJRhNoepqZ+6zia3cA+n3a3Ko8F4JF5lvbtHIOCTIy5fHuZt+ xvWAiKb9F5BlHjKvt4FQK2pb/DVLkgF/+32DAc+TqLlI8wquWlLpFS+QdCdyJHmsmT0EyFSPT JIFvmRMMLGy+tOMNOwHsacG4VfTmd/3UQMxJVpnkRR7oezwsr8AI44gRFTVxY8NE2lQcSOyqj +0b1Yvm1oh5xzypdDItPhjzfs3rjXdZbyc91wx7kdg742eSLOQUaomtclDFJfLTXWZtsuORER i1GgYNzizNLbv4RTJVaa/oVU/f51W8pZM4DZtPY2RMap0fFc7+lP4YLvFBdI7bk8Hte/MDAQK QVCRct/bC4+1qqHlTvq056NkSaj6s2hPAW3i9LLH2GVsYyBFYXdoK9GS65bs5GnXc+k3vnKdL GFgMXXTrXIphzAjR64DdJWg8yIbElaZrN51lvzsXBQOhSsd1jz+QCiMJlC+eaO0v0Vz/bwf5A FE1TPBy+tB1tHG9zP93kdYnCNiOQ/2eCyJcULrcoHNupYFGS31ypkrRUFinymuTlM0fFPkSUP smkNT0exAcpUMe3YZ4iTDYwvQr91hbg65yQSsh8TucDdpKYKJ8LiY8C5D19hZlrHxHicSv4DW DTX4Uqqy19/IRrMrYnpk3XMpSimEHva8fFaD+69LImvmxf4xj/XnXiTHWTRCyxjh6YsETkZos c8MQuG8QFI7LawJixB7xmDGNyvtnUiWgzE3Mo0dpHR2PA1LWYDUwVzTJ1grM= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.19 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 15:36:54 -0000 Hi, i wrote: > > [ ] Change HFS+ LABEL automatically by adding "_HFSPLUS" to the upto 3= 2 > > 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/#L163= 2 If agreed on, i would change ret =3D set_hfsplus_name (target, target->image->volume_id, &target->hfsp_leafs[target->hfsp_curleaf]); to something like char *hfs_label; hfs_label =3D calloc(1, strlen(target->image->volume_id) + 8 + 1); sprintf(hfs_label, "%s%s", target->image->volume_id, "_HFSPLUS"); ret =3D 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 o= ther > > 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 m= ight 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 n= eed to care for using a version of xorriso to which they can submit their desi= red 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 mes= sy 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/ISOIMAG= E 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/19212f27816686a5cac2c965301cea= 8624ac467f 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 partiti= on out of the inappropriate race by giving it some label. E.g. some character= s 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 96= 60. 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=3D set by grub-mkrescue currently overrides the SOURCE_DATE_EPOCH time.) Have a nice day :) Thomas