similar to: Isolinux freezes loading configuration file.

Greetings, I have been using isolinux with Microsoft's cdimage.exe for my Utility / Preinstallation cds. I just upgraded from 3.36 to 3.55 and found it to be non functional. I didn't use the -debug version, it just hangs at the version banner. I went through several previous versions, and it appears that 3.50-pre23 is the last working version. I didn't see anything between that

In fact, I discovered that the bug is caused when there is no primary hard disk image (no hard disk 0). When an HD image is created and attached, ISOLINUX works well: ISOLINUX 1.75 2002-06-14 Copyright (C) 1994-2002 H. Peter Anvin isolinux: Starting up, DL = 99 isolinux: Loaded spec packet OK, drive = 99 isolinux: Sector size appears to be 0800 isolinux: Loading main image from LBA = 0000001C

Hi, for some reason David always omits the Cc: to this list. He has now reported to Martin and me the outcome of the latest two MBR test proposals. - His BIOS announces no LBA addressing but another extra feature. This lead to unexpected success in one of David's tests. - The newest fix proposal by Martin is a full success ! Distros which produce isohybrid should consider to already

I've created a bootable cd with isolinux but it can't load the kernel. It detects everything fine, decompresses the initrd, loads and decompresses the kernel and then tries to boot the kernel. But after that the computer hangs. Here's the screen dump: ISOLINUX 1.73 2002-05-26 Copyright (C) 1994-2002 H. Peter Anvin isolinux: Starting up, DL = 9F isolinux: Loaded spec packet OK,

Hi e, I am normally use gnome and would do the following to make my CD / DVD mount with exec gnome-mount --write-settings --device /dev/sdc0 -o exec What is the equivalent in KDE ? My initial research suggests that I actually have to write a custom udev rule to achieve this. This has led me as far as running udevinfo -q path -n /dev/scd0 udevtest /block/sr0 (the output is below) My

Hello ! I have only 2 questions concerning my problem : 1) is there any limitation on the size of the kernel with isolinux ? (mine is 1230215 bytes. perhaps it's too big ?) 2) Is isolinux compatible with the use of the -z option of mkisofs, (transparent iso compression) even if the isolinux directory is not concerned by the compression ? That's all. sylvain

Hi, i now believe to see a difference between isohdpfd.S and isohdpfc.S which explains why isohdpfc.bin works with isolinux.bin on our virtual BIOSes: isohdpfc pushes the CX value to the stack which it gets from INT 13 AH 41. Quite surely bit 0 of that CX is not set. But bit 2 "Enhanced Disk Drive" could be set. https://en.wikipedia.org/wiki/INT_13H I understand on David's BIOS

On Wed, Mar 22, 2017 at 03:18:44PM +0100, Thomas Schmitt via Syslinux wrote: > Hi, > > > In theory, the geometry assumed in the MBR should > > match the one assumed by the BIOS. > > To be exacting: The geometry assuming part of the MBR is the partition > table, not the executable MBR code. > > Of course it would be nice if C/H/S was not such a brain damaged

I am experiencing a problem booting a machine with ISOLINUX on a machine that has no hard drive (CD-ROM only). I've tried two different machines, a Dell Poweredge 2600 and a Dell Poweredge 1300, both exhibit identical symptoms. When I boot the exact same cd on a system with a hard drive, the boot is just fine. I had been using ISOLINUX 1.66, but I just upgraded to 2.02 and I am having the

Hi, > In theory, the geometry assumed in the MBR should > match the one assumed by the BIOS. To be exacting: The geometry assuming part of the MBR is the partition table, not the executable MBR code. Of course it would be nice if C/H/S was not such a brain damaged concept which has two semi-secret parameters. The geometry parameters are not recorded anywhere in the MBR. One can sometimes

Hi, funny or enlightening observation: With my qemu-system-i386 it would work if the detected Heads/Cylinder and Sectors/Head factors would change positions ! The effective read operation seems to use H/C = 32 , S/H = 63. The correct LBA would be addressed by H/C = 63 , S/H = 32. -------------------------------------------------------------------------- Reasoning: I have transplanted the

H, Ady wrote: > A_ The default checksum included in the tested isolinux.bin (offset 20, > 4-bytes-long) is the "correct" one (as oppose to the current situation, > since version 4.00). That's good news. > F_ In the tested isolinux.bin file, there are two additional bytes that > I found to be changed/affected by some ISO-building tools (e.g. > mkisofs), at

I am trying to rebuild Red Hat Linux 9 on DVD. I am using the provided isolinux 2.00 (I tried the latest 2.04, with the same results), and I get an error trying to boot from the DVD. I burned the boot.iso (basically a triple-wide boot disk using the same isolinux directory) to DVD, and it booted fine. The error I get when booting the DVD using isolinux-debug.bin is this (copied by hand):

Hi, Ady wrote: > We seem to be suggesting to just dd' the first 432 bytes of their USB > devices with Martin's isohybrid Yes. As long as it is not about the old Macs which the APM of Fedora and some Gentoo ISOs wants to make boot, and not about ISOs made with isohybrid options --partok -ctrlhd0 --forcehd0. > which would be the step-by-step instructions for users of other >

> Hi, > > funny or enlightening observation: > > With my qemu-system-i386 it would work if the detected Heads/Cylinder and > Sectors/Head factors would change positions ! > > The effective read operation seems to use H/C = 32 , S/H = 63. > The correct LBA would be addressed by H/C = 63 , S/H = 32. > The original MBR included in

> Hi, > > Ady wrote: > > If a specific BIOS' CHS/LBA translations cannot cope with the above, it > > is no surprise that we get some mess, somewhere. > > Currently my suspicion is that the isohdpfx.S code simply mishandles > the two conversion factors which it correctly got from BIOS call > INT 13H AH 8. > > > > Boot System ID : First

Hi, MartinS wrote: > Is it the isohdppx or isohdpfx (or both) that is relevant? The file /.disk/mkisofs in the ISO tells that option -isohybrid-mbr syslinux/usr/lib/ISOLINUX/isohdpfx.bin was used. (This file is a Debian specialty.) I guess you can see at the first bytes of the ISO that the partition interpreter code is not there. > For isohdpfx.bin it will print: > E if EBIOS >

Hi, Gene Cumm wrote: > it seems the stack format got > set, changed, then mostly reverted back, with this code being the last > piece missing from 2009. The commit to isohdpfx.S of 2009-05-31 looks incomplete. The sequence of the stack pointers was swapped, but the sequence of stack pushes was not.

I have tried to use isolinux 2.05, and I am running into a problem where it will not boot. I have previously used version 1.66, and the older version works just fine. Changing nothing except dropping the new version in does not work. Below is all of the relevant info, I believe. This occurs on multiple machines with different BIOS. I am currently in process of doing a binary search to find the

Hi, Ady wrote: > If a specific BIOS' CHS/LBA translations cannot cope with the above, it > is no surprise that we get some mess, somewhere. Currently my suspicion is that the isohdpfx.S code simply mishandles the two conversion factors which it correctly got from BIOS call INT 13H AH 8. > Boot System ID : First : Last : Relative : Number of: > Flag