Re: Debian Live CD on USB 3.0?
Hello Andrew, The strange behaviour that I had experienced was on two differents pc: 1) lenovo w530 2) assemblend wit motherboard asus p8h77-i Both with more than one usb3 ports, at first boot with live plugged in one port doesn't start, at the second try with different usb3 port work fine like a charm... On Apr 9, 2014 12:41 AM, "Andrew M.A. Cater" wrote: > Debian Live CD appears to have a problem booting on USB 3.0 ports but > boots well on USB 2.0 ports. No specifics I'm afraid > because a friend reported this to me fron an HP all-in-one desktop that > normally runs Windows 8 > > Has anybody else seen this one, by any chance? > > All the very best, > > AndyC > > > -- > 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/20140408223530.ga5...@galactic.demon.co.uk > >
Re: Debian Live CD on USB 3.0?
Am 09.04.2014 00:35, schrieb Andrew M.A. Cater: Debian Live CD appears to have a problem booting on USB 3.0 ports but boots well on USB 2.0 ports. No specifics I'm afraid because a friend reported this to me fron an HP all-in-one desktop that normally runs Windows 8 Has anybody else seen this one, by any chance? All the very best, AndyC I think we need more info on that: is the boot media USB 2.0 or USB 3.0? Where in the boot process does it fail? Do you get to the bootloader or does the drive not even try to boot at all? Booting from USB 3.0 ports requires that the firmware/BIOS supports it. This is not the case with many earlier USB 3.0 implementations (an FAQ entry from the german c't magazine from end of 2011 tells this was not possible at that time with most if not all USB 3.0 boards). I did, however, successfully boot several Lenovo and HP machines from USB 3.0 which were bought in the last 12 months. Did you test with any other live CD/distro that booting from USB 3.0 works at all? Booting from USB 2.0 media on USB 3.0 ports often does not work. That's one of the reasons all USB 3.0 equipped machines still have USB 2.0 ports as well. If the boot process starts but gets stuck because it cannot find the root filesystem, the live system might be lacking xhci support. But that should not be the case with any recent debian live. Bye, Andreas -- 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/534506dc.6050...@gmx.com
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi, uploaded is a new (semi-stable) development snapshot http://www.gnu.org/software/xorriso/xorriso-1.3.7.tar.gz with the new features for PALO on HP-PA, which are now promised to stay compatible in future releases. MD5: 961939a15cdb2b9893fbe25f453d9ac4 Version timestamp : 2014.04.09.073038 debian-cd uses the mkisofs emulation. So see man xorrisofs and search for "HP-PA" if you are interested in the documentation. To Helge Deller: Please check-read my descriptions of header versions 4 and 5 beginning at doc/boot_sectors.txt line 975 resp. http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt#L972 for terminology, unclear or false statements, ... To debian-cd, especially Steve McIntyre: I tested by re-packing debian-7.4.0-amd64-netinst.iso debian-7.0-hppa-NETINST-1.iso and checking whether El Torito and the various partition tables point to the appropriate blocks. The time gap between xorriso-1.2.6 and today's snapshot is 15 months. http://libburnia-project.org/browser/libisoburn/trunk/ChangeLog So if xorriso-1.3.7 is to be used for general debian-cd, then there should also be a call for heavy testing of the exotic arches. (Except "powerpc", of course, which is still made by genisoimage.) 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/3190566864913...@scdbackup.webframe.org
Bug#743879: Aw: Re: Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
> To Helge Deller: > Please check-read my descriptions of header versions 4 and 5 beginning at > doc/boot_sectors.txt line 975 > resp. > > http://bazaar.launchpad.net/~libburnia-team/libisofs/scdbackup/view/head:/doc/boot_sectors.txt#L972 > for terminology, unclear or false statements, ... Thanks Thomas! Doc looks good. I added some comments. Patch for the docs are attached. Helgediff -up ./doc/boot_sectors.txt.org ./doc/boot_sectors.txt --- ./doc/boot_sectors.txt.org 2014-04-09 15:21:34.186537252 +0200 +++ ./doc/boot_sectors.txt 2014-04-09 15:49:36.554845164 +0200 @@ -1033,7 +1033,17 @@ Sources: http://git.kernel.org/cgit/linux/kernel/git/deller/palo.git/tree/lib/ (especially struct firstblock in common.h and struct partition in part.h) -There are five parameters which get encoded into the first 248 bytes of the +Version 5 of the palo header is backwards compatible to version 4 and +introduced two new options: +1. The Linux kernel commandline was extended to 1023 characters. For that the + new command line is stored at offset 1024 of the image. The new palo bootloader + will first look at offset 1024 and use the commandline stored there. If it's + empty, it will fall back to the command line at offset 24. +2. Palo is now able to load and uncompress gzip-compressed Linux kernels. For + that the original length of the uncompressed Linux kernels are stored at + offsets 220 and 224. + +There are five parameters which get encoded into the first 2048 bytes of the System Area: cmdline, bootloader, 32-bit kernel, 64-bit kernel, and ramdisk. They are all mandatory. While cmdline is simply a string of at most 1023 characters, the other four
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
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 debian-cd-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1763669021419767...@scdbackup.webframe.org
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 -- 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/trinity-bbb291ac-e3fa-4406-87aa-3912edc74fcd-1397057190085@3capp-gmx-bs10
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi, > > How to recognize a PALO that is "newer" ? > It should be palo 1.92 or higher. > > ... PALOHDRVERSION ... > I could update it to 5. I think it is appropriate. Readers of libisofs docs and of PALO could make a clear connection. > We shouldn't make xorriso more complicated than necessary. Yeah. It already has a sufficient set of dark and dusty corners where new bugs quickly find a home. Notify me when you have more tangible plans for compressed kernels in ISO. For now i settle with the assessment that it should be well possible to let libisofs determine the uncompressed sizes. > > There will be a new xorriso-1.3.7.tar.gz soon. > Cool. Two "semi-stable" snapshots in one day is rather lukewarm. :)) 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/4314669009886726...@scdbackup.webframe.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi, the GPT header CRC of http://cdimage.debian.org/cdimage/daily-builds/daily/arch-latest/amd64/iso-cd/debian-testing-amd64-netinst.iso looks ok now for me and for gdisk of oldstable (which formerly complained about amd64 ISOs). Now it says: GPT fdisk (gdisk) version 0.8.1 Partition table scan: MBR: MBR only BSD: not present APM: not present GPT: present Found valid MBR and GPT. Which do you want to use? (I wonder why it does not recognize the APM in the ISO. Well, the combination of MBR, GPT, and APM is quite a dirty hack.) Today i got a report about younger fdisk and gdisk with GRUB2-style MBR and GPT. Both programs hate the ISO. I will have to find out what might be wrong there. ISOLINUX style and GRUB2 style differ: ISOLINUX wants nested mountable partitions. GRUB2 wants disjoint partitions. 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/29015669012639950...@scdbackup.webframe.org
Bug#740504: cdimage.debian.org: Released ISO images have invalid GPT tables
Hi, my newest bug about gdisk hating an ISO with GPT and MBR is not affecting debian-cd. (Further it is not GRUB2 specific.) I can reproduce the user's symptoms with gdisk 0.8.1 and can work around them by explicitely disabling multi-session emulation when producing the ISO. This disabling is default with mkisofs emulation. Today's debian-testing-amd64-netinst.iso shows no such symptoms and thus should be ok at least for gdisk. 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/15431669027945997...@scdbackup.webframe.org
Bug#743879: debian-cd: Fixes for hppa architecture (patch attached)
Hi Thomas, On 04/09/2014 05:53 PM, Thomas Schmitt wrote: >>> How to recognize a PALO that is "newer" ? >> It should be palo 1.92 or higher. >>> ... PALOHDRVERSION ... >> I could update it to 5. > > I think it is appropriate. > Readers of libisofs docs and of PALO could make a clear connection. Ok, committed. I need some testing though until I push a new palo upstream version. >> We shouldn't make xorriso more complicated than necessary. > > Yeah. It already has a sufficient set of dark and dusty corners where > new bugs quickly find a home. > > Notify me when you have more tangible plans for compressed kernels > in ISO. For now i settle with the assessment that it should be well > possible to let libisofs determine the uncompressed sizes. Ok. 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/5345a510.1070...@gmx.de
