Bug#740504:
Correct me if I got this wrong, but the bug in question is supposed to have existed in upstream until 1.3.4? I built several ISOs of our Ubuntu Privacy Remix live project using upstream xorriso 1.3.0 and 1.3.1 So far I have not seen any UEFI test machine which failed booting from USB drive prepared with these ISOs. Just to be sure, I will do again with 1.3.6 -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/5342a79...@gmx.com
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi, > the bug in question is supposed to have existed in upstream until 1.3.4? No. It was introduced by 1.2.4 and fixed by 1.3.0. So the version in Debian testing should be ok. It's just that xorriso-1.3.6.pl01 is the newest upstream release, which i would of course like to see in Debian testing. The bug seems not to hamper booting. But it keeps partition editors from recognizing the GPT. gdisk for example says: Found invalid GPT and valid MBR; converting MBR to GPT format. The bug is/was that the CRC number of the GPT header block was computed from all 512 bytes, rather than from the 92 bytes which actually bear information. The fix is tested since a year. At two occurences in libisofs/system_area.c, the number 512 needs to be replaced by 92: - crc = iso_crc32_gpt((unsigned char *) buf, 512, 0); + crc = iso_crc32_gpt((unsigned char *) buf, 92, 0); See http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/revision/1071/libisofs/system_area.c If Debian decides to e.g. fix xorriso-1.2.6 on the debian-cd production machine, then it would be helpful to also update the timestamp in xorriso/xorriso_timestamp.h to e.g. #define Xorriso_timestamP "2014.04.07.133000" in order to indicate the fixed program version in the Preprarer Id of the emerging ISO images. Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/30329669484380980...@scdbackup.webframe.org
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Package: debian-cd
Version: 3.1.14
Severity: normal
Tags: patch
debian-cd is currently broken for the hppa/parisc architecture.
The attached patch to the tools/boot/jessie/boot-hppa file fixes three issues:
1. The bootloader on hppa is "palo". Remove one line in the script which tries
to move a non-existant "delo.2nd" file.
2. On hppa/sid we now provide a 32bit-UP (vmlinux-*-parisc) and a 64bit-SMP
kernel (vmlinux-*-parisc64-smp) only. Adapt the script to take this change into
account. Specifically, a vmlinux-*-parisc (non-SMP) kernel doesn't exists any
longer and as such it breaks the current debian-cd hppa script.
3. Feature: The hppa bootloader is now able to load gzipped-kernels. So, put
gzip'ed kernels on the CD, which saves CD/netinst space.
It would be nice if you could apply this architecture-specifc patch to the next
version of debian-cd.
Thanks,
Helge
diff -up ./tools/boot/jessie/boot-hppa.org ./tools/boot/jessie/boot-hppa
--- ./tools/boot/jessie/boot-hppa.org 2014-04-07 18:46:18.343475765 +
+++ ./tools/boot/jessie/boot-hppa 2014-04-07 18:48:37.291361920 +
@@ -30,7 +30,6 @@ if [ -z "$PALODEB" ] ; then
fi
(dpkg --fsys-tarfile "$MIRROR/$PALODEB" | \
tar xf - -C . ./usr/share/palo/iplboot)
-mv boot/delo.2nd $CDROOT/boot/delo.2nd
mv usr/share/palo/iplboot $CDROOT/install/iplboot
if [ -n "$ARCHIVE_EXTRACTED_SOURCES" ]; then
@@ -48,18 +47,19 @@ else
wget -r -nd --no-parent -P "$DI_DIR" "$DI_WWW_HOME"
fi
-cp "$DI_DIR"/vmlinux-*-parisc "$CDROOT/install"
-cp "$DI_DIR"/vmlinux-*-parisc64 "$CDROOT/install"
+K32=$(basename "$DI_DIR"/vmlinux-*-parisc)
+K64=$(basename "$DI_DIR"/vmlinux-*-parisc64*)
+
+# palo >= 1.91 can load gzip-compressed Linux kernels
+gzip -c "$DI_DIR"/$K32 > "$CDROOT/install"/$K32
+gzip -c "$DI_DIR"/$K64 > "$CDROOT/install"/$K64
cp "$DI_DIR"/initrd.gz "$CDROOT/install"
install_languages "$CDROOT"
-K32=$(ls $CDROOT/install/vmlinux-*-parisc|head -1 | sed 's?^.*/install/?install/?g')
-K64=$(ls $CDROOT/install/vmlinux-*-parisc64|head -1 | sed 's?^.*/install/?install/?g')
-
add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-cmdline '0/vmlinux initrd=0/ramdisk${KERNEL_PARAMS:+ $KERNEL_PARAMS}'"
-add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-kernel-32 $K32"
-add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-kernel-64 $K64"
+add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-kernel-32 install/$K32"
+add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-kernel-64 install/$K64"
add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-bootloader install/iplboot"
add_mkisofs_opt $CDROOT/../$1.mkisofs_opts "-hppa-ramdisk install/initrd.gz"
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi, in january we had a conversation about xorriso and PALO. I implemented the boot sector as learned from genisoimage: version number 4 and the short command line at byte 24 to 151. Further there is the proposed version 5 with long command line at byte 1024 to 2047, and the yet unexplained "ipl_entry" at byte 248 to 251. Because our discussion stalled, i did not publish the enhancements of libisofs API and xorriso CLI with the recent release 1.3.6. They are still available in the last 1.3.5 development snapshot: http://www.gnu.org/software/xorriso/xorriso-1.3.5.tar.gz It has header version 5 as default. Version 4 can be achieved by -as mkisofs option -hppa-hdrversion 4 The five traditional -hppa-* options of genisoimage are supported by the -as mkisofs emulation. The disabled code gets back into effect by defining the macro Libisofs_enable_unreleased_hppa_palO (in CFLAGS or in libisofs.h). For exporting the API from libisofs.so, it is further necessary to add in libisofs/libisofs.ver the lines iso_image_set_hppa_palo; iso_image_get_hppa_palo; So if i get a definition of "ipl_entry" at byte 248 to 251, and some testing is made by owners of HP-PA machines, then -hppa-* options could be in xorriso-1.3.8. Together with my new boot sector analyzer which will tell e.g.: Volume id: 'Debian 5.0.8 hppa Bin-1' ... PALO header version: 4 HP-PA cmdline : 0/vmlinux initrd=0/ramdisk HP-PA boot files : ByteAddrByteSize Path HP-PA 32-bit kernel: 13346816 4187315 /install/vmlinux-2.6.26-2-parisc HP-PA 64-bit kernel:7557120 5789547 /install/vmlinux-2.6.26-2-parisc64 HP-PA ramdisk :2324480 5193978 /install/initrd.gz HP-PA bootloader :7520256 36864 /install/iplboot (The output with debian-7.4.0-amd64-netinst.iso is a bit longer :)) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/14247669396895346...@scdbackup.webframe.org
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi Thomas,
On 04/07/2014 10:03 PM, Thomas Schmitt wrote:
> in january we had a conversation about xorriso and PALO.
Yes, I did not forgot it :-)
> I implemented the boot sector as learned from genisoimage:
> version number 4 and the short command line at byte 24 to 151.
>
> Further there is the proposed version 5 with long command line at
> byte 1024 to 2047, and the yet unexplained "ipl_entry" at byte
> 248 to 251.
>
> Because our discussion stalled, i did not publish the enhancements
> of libisofs API and xorriso CLI with the recent release 1.3.6.
That's really sad!
It would have been easier for me, if you would have added them, even
if they were not perfect.
> They are still available in the last 1.3.5 development snapshot:
> http://www.gnu.org/software/xorriso/xorriso-1.3.5.tar.gz
> It has header version 5 as default. Version 4 can be achieved by
> -as mkisofs option
> -hppa-hdrversion 4
> The five traditional -hppa-* options of genisoimage are supported
> by the -as mkisofs emulation.
>
> The disabled code gets back into effect by defining the macro
> Libisofs_enable_unreleased_hppa_palO
> (in CFLAGS or in libisofs.h).
> For exporting the API from libisofs.so, it is further necessary to
> add in libisofs/libisofs.ver the lines
> iso_image_set_hppa_palo;
> iso_image_get_hppa_palo;
>
>
>
> So if i get a definition of "ipl_entry" at byte 248 to 251,
I just looked into the code of palo again.
Full code is here:
http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/
or alternatively you can just download the palo debian source package.
(BTW, that's what I have been working on during the last few weeks,
to get palo back into debian unstable. It now compiles on all debian arches,
see:
https://buildd.debian.org/status/package.php?p=palo&suite=sid
and
http://buildd.debian-ports.org/status/package.php?p=palo&suite=sid
)
It seems, that ipl_entry can be calculated like this:
(see lib/elf32.c or lib/elf64:)
Elf32_Ehdr eh;
load the elf-header of the Linux kernel (vmlinux or vmlinux64),
ipl_entry_temp = __be32_to_cpu(eh.e_entry);
ipl_entry = __cpu_to_be32(ipl_entry_temp - first);
"first" is the first address where the binary is loaded.
See lib/elf32.c:
For all PT_LOAD sections of the ELF file, search the lowest address.
This address becomes "first". Here is a simplification, better look at the code!
eh.e_phnum = __be16_to_cpu(eh.e_phnum);
for (i = 0; i < eh.e_phnum; i++)
{
Elf32_Phdr ep;
if (__be32_to_cpu(ep.p_type) != PT_LOAD)
continue;
start = __be32_to_cpu(ep.p_vaddr);
if (loadable->first == 0 || start < loadable->first)
{
loadable->first = start;
}
}
So, ipl_entry is the relative address where to jump into the loaded executable
address range.
> and
> some testing is made by owners of HP-PA machines, then -hppa-*
> options could be in xorriso-1.3.8.
I will test.
> Together with my new boot sector analyzer which will tell e.g.:
>
> Volume id: 'Debian 5.0.8 hppa Bin-1'
> ...
> PALO header version: 4
> HP-PA cmdline : 0/vmlinux initrd=0/ramdisk
> HP-PA boot files : ByteAddrByteSize Path
> HP-PA 32-bit kernel: 13346816 4187315 /install/vmlinux-2.6.26-2-parisc
> HP-PA 64-bit kernel:7557120 5789547
> /install/vmlinux-2.6.26-2-parisc64
> HP-PA ramdisk :2324480 5193978 /install/initrd.gz
> HP-PA bootloader :7520256 36864 /install/iplboot
>
> (The output with debian-7.4.0-amd64-netinst.iso is a bit longer :))
You want to test some other hppa installer images which I currently built?
They are at: http://mkhppa3.esiee.fr/
Helge
--
To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/534310f8.6070...@gmx.de
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi, > > Because our discussion stalled, i did not publish the enhancements > > of libisofs API and xorriso CLI with the recent release 1.3.6. > That's really sad! > It would have been easier for me, if you would have added them, even > if they were not perfect. Ah no. It's a tiny bit inconvenient. You may either test with xorriso-1.3.5 or enable it by macro in 1.3.6 and 1.3.7. Withholding the API and CLI is much better than releasing them in incomplete state, and having to create new ones after testing. We would need to prod debian-cd for upgrading xorriso, anyway. It is still on 1 year old xorriso-1.2.6 with its known GPT CRC bug. > > So if i get a definition of "ipl_entry" at byte 248 to 251, > It seems, that ipl_entry can be calculated like this: > (see lib/elf32.c or lib/elf64:) > [...] > http://mkhppa3.esiee.fr/ I will use the netinst image for practicing. The command line looks truncated: HP-PA cmdline : 0/vmlinux initrd=0/ramdisk panic_timeout=60 panic=-1 debian -installer/allow_unauthenticated=true mirror/http/hostname=debian-p It seems you need the header version 5. :)) Regrettably there is 0x at byte 248, where i hoped for an example of ipl_entry. Can you tell me the correct value for the bootloader file in the ISO ? So i have a test for my own computation. > load the elf-header of the Linux kernel (vmlinux or vmlinux64), Kernel ? Doesn't it belong to the "bootloader file" at ipl_adr (byte 240 to 243 in my cheat sheet) ? At least that's what i understand from function write_bootloader() in palo.git/tree/palo/palo.c . I.e. in your debian-7.0-hppa-NETINST-1.iso HP-PA bootloader : 159295488 45056 /install/iplboot If it belongs to a kernel: to which one of both ? Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/15642669398256357...@scdbackup.webframe.org
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi, looking at your description of ipl_entry computation - after midnight - makes me search for alternatives. I would have to duplicate a non-trivial part of PALO which then would have to be validated against the original code. From then on, i would have to maintain it without having much clue. How about i provide an option -hppa-ipl-entry NUMBER by which debian-cd can tell xorriso -as mkisofs the value to use, and you provide a program which computes the NUMBER for debian-cd ? This would give you full control over this aspect of ISO production, with one single code base for PALO and ipl_entry calculator. (Actually you could provide any constant field value by a data file and option -G. This would be the template into which libisofs will write the -hppa-* parameters. An option -hppa-ipl-entry is just more convenient.) Have a nice day :) Thomas -- To UNSUBSCRIBE, email to debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/14877669385065795...@scdbackup.webframe.org
