search for: sysinux

On 11/26/2013 06:52 AM, Gerardo Exequiel Pozzi wrote: >> >> Yes. I done the rebuild, but I can not test just now (enconding >> video!). I will post the result in ~10 hours ;) > > Yes! Fixed :) > > I tested at LBA 65536 (~128M) and 655360 (~1280M) and works fine in > both cases. > > The big mistery is why this works in some machines and why fails > in

Hi, Carl Duff wrote: > (at least some) OSs not using syslinux 6.02 won't > recognise ISOs that do. For example, the file managers of Mint 13, Windows > 7, and Windows 8 all wrongly "see" blank discs). > [...] > This is certainly not an issue with corrupted downloads, burning, or dodgy > computer disc-drives. You mean real CD or DVD with operating systems on real

> It is impossible to boot Linux-based ISOs that use Syslinux 6.02 via CD or > DVD on older - non-UEFI - systems. Any attempt to do so will result in the > following error message: ISOLINUX 6.02 ETCDisolinux: Disk error 01, AX = > 4279, drive FE Is this happening on "every" system? Or are we talking about specific models or with specific characteristics? Is this behavior

Hi, Ady wrote: > I wonder if isolinux.bin should be limited to max. 16 sectors (of > 2KiB each), as that's the default limit in mkisofs "-G > <generic_boot_image>" option. Option -G is not related to the El Torito boot image isolinux.bin. It inserts its data into the System Area of the ISO, which is indeed limited to 32 KiB. Use cases are MBR and other kinds of

> Hi, > > Ady wrote: > > I wonder if isolinux.bin should be limited to max. 16 sectors (of > > 2KiB each), as that's the default limit in mkisofs "-G > > <generic_boot_image>" option. > > Option -G is not related to the El Torito boot image isolinux.bin. > It inserts its data into the System Area of the ISO, which is > indeed limited

> Their isolinux/isolinux.cfg has > DEFAULT loadconfig > LABEL loadconfig > CONFIG /arch/boot/syslinux/archiso.cfg > The file arch/boot/syslinux/archiso.cfg is readable too. > IIRC, Arch isolinux/isolinux.cfg should say: DEFAULT loadconfig LABEL loadconfig CONFIG /arch/boot/syslinux/archiso.cfg APPEND /arch/ Or it might be using relative paths: DEFAULT

> The very early code that emits this message is *identical* between > Syslinux 4 and Syslinux 6. The biggest difference is the size of > isolinux.bin, so it is possible that that might be the source of the > problem. > > -hpa I wonder if isolinux.bin should be limited to max. 16 sectors (of 2KiB each), as that's the default limit in mkisofs "-G

Hi, my apologies to Mattias Schlenker for not remembering our discussion about UEFI of march 2013. It would have been more relevant in this context than the ia64 problems of debian-cd of may 2013. Gerardo Exequiel Pozzi wrote: > The problem is the load LBA too high. Nevertheless, this is the first confirmation that BIOS dislikes high block addresses. At least the older versions of mkisofs

Hi, Ady wrote: > I guess that being isolinux.bin 4.07 smaller than 32KiB (24KiB), > while isolinux.bin 6.02 being bigger (42KiB), and with the addition > of multiple alternative boot images in the same ISO, the chances of > isolinux.bin being located on a higher sector in the media seem to be > higher. > > So, perhaps the potential problem was always there, just that the

Thomas wrote: > >Nevertheless, this is the first confirmation that BIOS >dislikes high block addresses. >At least the older versions of mkisofs and genisoimage >do not force the boot images to low addresses. >I am curious what a mass test with the users will bring. >From experience of making Debian CDs, we've had bug reports years ago about buggy BIOS implementations that

Hi, Gerardo Exequiel Pozzi wrote: > Looks like there is something beyond LBA 65535 (As Mattias confirmed) I wanted to ask him now, whether this was already with version 6. But meanwhile he reported that it was 5. > I can push isolinux.bin (4.07) to a really high LBA address and boot > without any issue. (Load LBA: 2048034 (0x001f4022)) ~4G This is riddling, given the statement of

On 11/25/2013 06:32 PM, H. Peter Anvin wrote: > On 11/25/2013 04:12 PM, Gerardo Exequiel Pozzi wrote: >> >> I made some more and more experiments beyond LBA 65535 >> >> Works: * isolinux-4.07.bin (size 24574) * isolinux-5.00.bin (size >> 34816) >> >> Does not work: * isolinux-5.01.bin (size 34816) * isolinux-5.10.bin >> (size 36864) *

> > these are the cmds I'm using now, which are working with syslinux4 just > fine: > > xorriso -as mkisofs ${_qflag} \ > -iso-level 3 -rock -joliet \ > -max-iso9660-filenames -omit-period \ > -omit-version-number \ > -relaxed-filenames -allow-lowercase \ > -volid "${LABEL}" \ >

Hi, hpa wrote: > - mov dx,cx > + movzx edx,cx Gerardo Exequiel Pozzi: > Yes! Fixed :) > (maybe garbage in high word of "edx"?) I am now pondering too, why my machine booted from high LBAs. I understand that the new code zeros the upper 16 bit of EDX. Was there remaining garbage from early BIOS activity before isolinux.bin got started ? Does my

On 26.11.2013 17:14, Thomas Schmitt wrote: > Does my BIOS perhaps clean registers before handing over > control ? Hardly anyone reads manuals these days. LoL! Bee awesome.:! poma

Hi, poma wrote: > Hardly anyone reads manuals these days. There are manuals ? El Torito just specifies how to direct the BIOS to the boot image, and what the boot image can learn from the BIOS about its origin. Possibly this silently builds on MBR specs. But about those i can only find wikipedia rumors: "the CPU is in real mode and the general-purpose and segment registers are

On 11/26/2013 02:22 AM, Gerardo Exequiel Pozzi wrote: > On 11/26/2013 01:14 AM, H. Peter Anvin wrote: >> On 11/25/2013 06:32 PM, H. Peter Anvin wrote: >>> On 11/25/2013 04:12 PM, Gerardo Exequiel Pozzi wrote: >>>> >>>> I made some more and more experiments beyond LBA 65535 >>>> >>>> Works: * isolinux-4.07.bin (size 24574) *

Hi, i am experiencing strange boot failures after repacking the ISO image archlinux-2013.11.01-dual.iso without isohybrid and EFI: # mount -o loop archlinux-2013.11.01-dual.iso /mnt $ xorriso -as mkisofs \ -o arch_repacked.iso \ -c isolinux/boot.cat \ -b isolinux/isolinux.bin \ -no-emul-boot -boot-load-size 4 -boot-info-table \ -V "ARCH_201311" \

Hi, > I am the maintainer of archiso (live-iso creator for Arch Linux). Thank you, too, for flying xorriso. :) > So I have two ISO images with same contents, same versions, same version > of program to generate it, but one works and other does not work!. So the size of the boot image alone cannot be the problem. > < 2013.11.23 = BAD > > 2013.11.24 = OK > <

Hi, the riddle about the failing repacks is solved, thanks to ISOLINUX wiki: "does support long (level 2) ISO 9660 plain filenames" The archlinux ISO makes use of such names. So i have to follow the wiki advise "use the "-l" or "-iso-level 2" option to mkisofs" Thus, a CD-bootable archlinux ISO without isohybrid and EFI can be repacked by # mount -o