similar to: "isolinux.bin missing or corrupt" when booting USB flash drive in old PC

> > I ponder whether it would be possible to create a diagnostic MBR > which does not necessarily have to boot but rather tells what the > isohybrid MBR would perceive: Presence of partition table, > EBIOS or CBIOS, block address used with INT 13, content of the block > read by the first INT 13, ... > > One could preserve the isohybrid MBR of an ISO and replace it by >

Hi, MartinS wrote: > Sigh. Ok. I deserve that. I was stubbornly looking at the structure of the documentation rather than at the documented sequence of instruction parameters. I ponder whether it would be possible to create a diagnostic MBR which does not necessarily have to boot but rather tells what the isohybrid MBR would perceive: Presence of partition table, EBIOS or CBIOS, block

Thomas Schmitt wrote: > I ponder whether it would be possible to create a diagnostic MBR > which does not necessarily have to boot but rather tells what the > isohybrid MBR would perceive: Presence of partition table, > EBIOS or CBIOS, block address used with INT 13, content of the block > read by the first INT 13, ... ... > The diagnostic MBR should only use 432 bytes because at

On Tue, Mar 21, 2017 at 09:03:35AM +0100, Thomas Schmitt via Syslinux wrote: > I think we should offer David a binary which he can combine with > the MBR of the ISO and the image with the recognizable blocks. > I will later today upload a binary version of my block producer > and post the URL. > > The combination will be: > 432 bytes from Martin's MBR > 80 bytes

Thomas Schmitt wrote: > So if we had a MBR which prints the content of the first 512 read bytes > we could tell whether they are block aligned and from which block they > come. Ok. I'll try. Is it the isohdppx or isohdpfx (or both) that is relevant? Meanwhile I have a hacked isohdppx.bin that prints: G if GPT M if MBR <nothing> if no partition info E if EBIOS C if not EBIOS

On Fri, Mar 24, 2017 at 05:38:31PM +0100, Thomas Schmitt via Syslinux wrote: > 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 after > > andw $1,%cx

Thomas Schmitt wrote: > My main point of interest is which block is really loaded as first one > of isolinux.bin. [Program snipped.] > (It could be shorter if i did not insist in big endian words.) Why insisting? Anyway appended is a dumper version. I could put up a binery version if needed. Let me know if so. -- MartinS /*

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.

On 03/18/2017 01:18 AM, Ady Ady via Syslinux wrote: > Some of the things you should / could (re)test / (re)try: > > _ Verify the md5sum of the ISO image. SHA256 verified for downloaded image and for contents of USB flash drive (see below). > _ Is this particular USB device _still_ capable of booting newer > computers? Yes. > What happens if you would try _again_ to boot a

Hi, Geert Stappers wrote: > Contact David off-list, he did unsubscribe. Can you tell when he unsubscribed (i.e. which of the messages he got as last one) ? > Martin posted elsewhere in this thread "Thomas, you found the bug" > and provided a patch. Open question is whether the fix helps with David's BIOS. The newest answer from Martin indicates that a failure to read

Thomas Schmitt wrote: > I have some problems understanding the details of the program's flow. > > - The code inside PARTITION_SUPPORT is supposed to be inactive with > MBR isohdpfx.bin. It belongs to isohybrid --partok which is equivalent > to MBRs isohdppx*.bin. Debian uses isohdpfx.bin. Yes. isohdpfx.bin is generated from isohdpfx.S in which PARTITION_SUPPORT is not

Hi, C/H/S addressing and reading of first block seems to be ok in isohdpfd.bin. The main suspect for the failure of the attempt with isohdpfd.bin is the number or content of the blocks read after the first one. But i have no clue why isohdpfc.bin should do better than isohdpfd.bin. They differ just by one instruction (JC = 0x72 versus JMP = 0xEB) which both are performed before the reading and

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

Hi, i am looking now at the code which i assume loads the rest of isolinux.bin. The entry point for program execution from the MBR is obviously at http://git.zytor.com/syslinux/syslinux.git/tree/core/isolinux.asm#n186 (Do i get it right that this is the Intel syntax ? (Gronfff)) If POP yields the victim of the most recent not yet popped PUSH, then this does not look correctly coordinated

Hi, Ady wrote: > so, why the original isohybrid image from Debian and many other > isohybrid images have mostly (but not all) "00s" in place of the "90s"? That's a fake Block0 of an Apple Partition Map. Part of mjg's layout. Caused by isohybrid option --mac or xorrisofs option -isohybrid-apm-hfsplus. * Fedora has it with EFI FAT filesystem in one partition

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

syslinux at zytor.com: I have two older computers with Intel D865GBFLK motherboards (~2003) and Pentium 4 HT CPU's. They both have the latest available BIOS installed. I would like to put Debian on them. I have downloaded: http://cdimage.debian.org/debian-cd/current/i386/iso-cd/debian-8.7.1-i386-xfce-CD-1.iso When I put debian-8.7.1-i386-xfce-CD-1.iso on a CD-R, it boots correctly.

> Hi, > > Ady wrote: > > http://repo.or.cz/syslinux.git/tree/HEAD:/diag > > "handoff.bin > > This does not look like it would tell much of the properties in question. > Nevertheless its print functions might be of interest for an isohybrid > diagnostic MBR. > > > > and at least 2 geodsp*.{bin,img(gz)} > > I am now reading >

Hi, given the fact that the conversion has the factor HC*SH = "secpercyl", which is invariant under swapping, there remains as suspect in read_sector_cbios only this division: divb (sectors) There is a suspicious discrepancy in the code: heads = (stack-16) sectors = (stack-18) ... /* here we computer CHS values or just do some dummy computation for EBIOS */ andw $0x3f,