On Wed, 25 Aug 2021 12:29:48 +0200 "Thomas Schmitt" <scdbac...@gmx.net> wrote:
> Hi, > > the xorriso run for testing zisofs in > > tests/util/grub-fs-tester.in > > looks not like it would cause any zisofs compression in the ISO. > > Line 1024: > > xorriso -compliance rec_mtime -set_filter_r --zisofs -- -zisofs > default -as mkisofs ... some options ... -- > -set_filter_r --zisofs -- -zisofs default -add > /="$MASTER" ;; > > should probably become > > xorriso -compliance rec_mtime \ > -as mkisofs ... same options as above ... -- \ > -add /="$MASTER" -- \ > -zisofs default \ > -set_filter_r --zisofs / -- > ;; > > In the current run, both times when "-set_filter_r --zisofs" is > executed in xorriso's native command mode, the emerging root > directory is still empty. So -set_filter_r cannot yet affect the > files of "$MASTER" which get added only later. > > Command -zisofs sets parameters for -set_filter_r. So it must be > executed before any successful -set_filter_r. Only the lack of any > installed compression filters keeps the existing run from failing with > libisofs: FAILURE : Cannot set global zisofs parameters while > filters exist > > Further: > Command -set_filter_r expects one or more paths in the ISO as > parameters. The empty path list defaults to "/" indeed, but that's > not a documented feature. > Command -add has a variable length parameter list and should thus be > terminated by '--'. In my proposal it has to be terminated because > more commands follow. > > > Experiment: > > Currently the run is essentially like > > xorriso -compliance rec_mtime \ > -as mkisofs -o test.iso --graft-points -- \ > -add /=test -- -set_filter_r --zisofs / -- > > My test directory contains > > -rw-r--r-- 1 thomas thomas 51200 Aug 25 11:51 zeros > -rw-r--r-- 1 thomas thomas 6 Aug 25 09:37 ÄÖÜß > > No zisofs compression gets applied by above run to the files, as can > be seen by a subsequent run of > > xorriso -indev test.iso -find / -exec show_stream -- > > which reports > > '/zeros' < image:'/zeros' > '/ÄÖÜß' < image:'/ÄÖÜß' > > In contrast, my proposed xorriso run causes compression of file > "zeros", which then causes the xorriso run with -indev to install a > decompression filter to that file: > > '/zeros' < --zisofs-decode:pz:32k < image:'/zeros' > '/ÄÖÜß' < image:'/ÄÖÜß' > > The small "ÄÖÜß" staid uncompressed, because compression yielded no > gain in terms of 2048 byte blocks. If I'm not mistaken, there is currently no test which actually exercises that code, ie no test runs "grub-fs-tester ziso9660". I think it could be a good idea to have one though. However, when attempting to run the test manually, I'm getting a failure probably related to what you've found. $ ./grub-fs-tester ziso9660 xorriso 1.5.2 : RockRidge filesystem manipulator, libburnia project. Drive current: -outdev 'stdio:/tmp/tmp.82yFdjU5NO/ziso9660_512_512_1_0.img' Media current: stdio file, overwriteable Media status : is blank Media summary: 0 sessions, 0 data blocks, 0 data, 4621m free xorriso : FAILURE : -volid: Text too long (1650 > 32) xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE' I haven't dug very far, but I'm unsure if GRUB currently is supposed to support this. Glenn _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel