Bug#743879: Aw: Re: Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
> 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.
Yes, correct.
> 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.
Yes, that's correct. Only the position of the command line changed.
> How to recognize a PALO that is "newer" ?
It should be palo 1.92 or higher.
> 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.
I could update it to 5.
Up to now it was no need to update it, because it behaves backwards compatible.
AFAIK, there is not even a check for the value of the version number in
the palo bootloader code (but there is one in the palo userspace part).
> As for the compressed kernels:
>
> If you plan to use them,
I will most likely revert the compression of the kernels in debian-cd.
It was mostly developed for on-disk usage because often the /boot partition
was small. This is not the case for CD's.
> then i need to populate bytes 220 to 227.
Not necessarily. I tested your code yesterday with compressed kernels.
It seems to work, but I'm not sure if I got everything worked out in palo correctly.
That's the reason why I plan to revert the debian-cd change.
We shouldn't make xorriso more complicated than necessary.
> libisofs should be able to recognize gzip'ed files and to unpack
> them for size determination, if zlib developement was available
> at compile time.
Ok, that would be a nice option.
But again, do you really think we should add this complexity?
> 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 ?
I'm not sure yet.
My long term goal is to add the decompression routines to the kernel itself,
so that it can unpack itself at boot. That way I can use all supported
compression techniques in the kernel and I'm not limited to gzip.
And it reduces the complexity for xorriso.
The downside is then, that we have compressed kernels in /boot (on harddisk)
which could make debugging of kernel problems harder.
But if you like to try it, I would be happy and can test it.
> There will be a new xorriso-1.3.7.tar.gz soon.
Cool.
Helge
Reply to: