Hi,
the proposed patch for the boot sector documentation looks at the
topic from the PALO user perspective. But the perspective of the
file boot_sectors.txt is the one of an ISO 9660 producer.
So i would like to re-arrange the info.
How about this for the command line part ? Would it be technically correct ?
--------------------------------------------------------------------------
HP-PA via PALO header version 4
...
This format is expected by older versions of PALO unconditionally. It serves
as fallback for newer versions, which expect header version 5, if a 0-byte
is found at byte position 1024.
...
HP-PA via PALO header version 5
...
This format is expected by newer versions of PALO. They fall back to version 4
if a 0-byte is found at byte position 1024.
...
--------------------------------------------------------------------------
How to recognize a PALO that is "newer" ?
I see that in palo.git/tree/lib/common.h the value of PALOHDRVERSION
is still defined as 4.
In man xorriso i perkily assumed that it would be incremented to 5.
As for the compressed kernels:
If you plan to use them, then i need to populate bytes 220 to 227.
libisofs should be able to recognize gzip'ed files and to unpack
them for size determination, if zlib developement was available
at compile time.
I see that Debian enables this in its packages by requiring zlib1g:
https://packages.debian.org/sid/libisofs6
Shall i implement automatic handling of compressed kernels ?
----------------------------------------------------------------------
There will be a new xorriso-1.3.7.tar.gz soon.
I just got a SIGSEV when playing with gzip compression via native xorriso
commands. It hits me when multi-session emulation updates the superblock.
A very fresh bug. I did not even commit it yet to SVN. But it is in the
tarball. Only good this is not a release version.
The SIGSEGV does not happen with mkisofs emulation, which disables
multi-session emulation by default. So valgrind did not find it when
i tested this morning.
Have a nice day :)
Thomas
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
Archive: https://lists.debian.org/[email protected]
