Thomas Schmitt
2017-Mar-23 08:58 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
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 should have caused a different error message than reported by David. But successfully reading a wrong block address should not have yielded all zeros. @Martin: Can you provide a binary MBR with the bug fix and diagnostic prints ? If we cannot get testing from David then i would be interested to keep such an MBR for the next occasion. Have a nice day :) Thomas
Thomas Schmitt
2017-Mar-23 10:20 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
Hi, i posted an update report to the Debian bug and Cc'ed David: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857597#45 Have a nice day :) Thomas
Martin Str|mberg
2017-Mar-23 20:17 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
On Thu, Mar 23, 2017 at 09:58:08AM +0100, Thomas Schmitt via Syslinux wrote:> @Martin: > Can you provide a binary MBR with the bug fix and diagnostic prints ? > If we cannot get testing from David then i would be interested to keep > such an MBR for the next occasion.Cc:ing David. Yes, here <http://www.ludd.ltu.se/~ams/tmp/isohdpf_dump.tgz>. It contains isohdpfd.{S,bin,lst} and isohdpfc.{S,bin,lst}. isohdpfd is head/sector corrected from the previous one. isohdpfc is the same but won't even check for EBIOS (similar to force_cbios). For David's old machine it shouldn't matter which one he uses. Would the syslinux project like that I add them somewhere? E. g. in diag/mbr/? They won't stay forever at the address above. -- MartinS
Martin Str|mberg
2017-Mar-24 07:05 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
CC:ing syslinux. Thanks for testing David. On Thu, Mar 23, 2017 at 05:23:51PM -0700, David Christensen wrote:> Trying isohdpfd.bin:...> Boot it in D865GBFLK Pentium 4 3.4E GHz -- I see a screenful of information, > with "Key?" at the bottom (see attached picture IMG_1578-r.JPG). > > > When I press a key, I see the following message at the bottom and the > computer stops: > > ISOLINUX 6.03 20150819 CHDDisolinux: Image checksum error, sorry... > > > Trying isohdpfc.bin:...> Boot it in D865GBFLK Pentium 4 3.4E GHz -- I see a screenful of information, > with "Key?" at the bottom.Is it exactly the same numbers as in the picture you attached for the isohdpfd.bin boot?> When I press a key, the following message flashes by at the bottom: > > ISOLINUX 6.03 20150819 EHDD Copyright (C) 1994-2014 H. Peter Anvin et al > > > The screen goes black, the PC speaker beeps, then the Debian Installer > starts. When I select Install, there is a delay of ~20 seconds, the screen > goes black, then the following message flashes by at the top:... [Successful start of install snipped.] What the ??!! There shouldn't be any difference. Looking at the code I see there might be a difference in CX _if_ the EBIOS check call succeeds but doesn't return correct value in BX. Please try this new isohdpfd.bin that indicates which part of EBIOS detection fails: <http://www.ludd.ltu.se/~ams/tmp/isohdpf_dump.2.tgz> * If an EBIOS is not detected outputs: * <X><LBA0>/<C0>/<H0>/<S0> * <LBA1>/<C1>/<H1>/<S1> * <LBA2>/<C2>/<H2>/<S2> * <LBA3>/<C3>/<H3>/<S3> * <Big hex dump of first loaded sector> * Key? * * and waits for a key press. * <X> is A if the EBIOS detection failed the extended disk access * support bit, B if the EBIOS detection failed the BX signature and * C if EBIOS detection failed with carry return. If my theory is correct then this one will print B for <X>. The included isohdpfc version really forces no EBIOS calls this time as it makes sure to clear the flag. Amazingly the size of the code in isohdpfd decreased by one byte although it's more informative! -- MartinS
Thomas Schmitt
2017-Mar-24 09:32 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
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 should actually be equivalent on David's BIOS. MartinS wrote:> Looking at the code I see there might be a difference in CX _if_ the > EBIOS check call succeeds but doesn't return correct value in BX.Can this cause a failure to read the further 79 blocks from isolinux.bin ? ------------------------------------------------------------------ Reasoning: David Christensen wrote:> Trying isohdpfd.bin: > attached picture IMG_1578-r.JPG:The data block shown is the correct start block of isolinux.bin. Whatever happened next, it is not due to failure to address the right block. (I did not compare byte by byte. But two start lines , two end lines, and magic number FBC07870 match.)> ISOLINUX 6.03 20150819 CHDDisolinux: Image checksum error, sorry...This error message stems from isolinux.bin, not from the MBR. So we really ended up in the running boot image program. The checksum is tested with all isolinux.bin starts. From CD too. It belongs to the Boot Info Table feature inside isolinux.bin (see "man mkisofs" or libisofs-*/doc/boot_sectors.txt): Byte Range | Value | Meaning ---------- | ---------- | ---------------------------------------------------- 8 - 11 | pvd_lba | Block address of the Primary Volume Descriptor. | | This is the session start LBA + 16. | | 12 - 15 | file_lba | Block address of the start of the boot image file | | content. Block size is 2048. | | 16 - 19 | file_len | Number of bytes in boot image file content. | | 20 - 23 | checksum | The sum of all 32-bit words of the file content | | from byte 64 to file end. | | 24 - 63 | 0 | Reserved ---------- | ---------- | ---------------------------------------------------- All numbers are stored little-endian. In the shown data (and in isolinux.bin hexdump): pvd_lba = 10 00 00 00 = 0x10 = 16 file_lba = 3F 08 00 00 = 0x83f = 2111 = 8444 / 4 file_len = 00 A0 00 00 = 0xa000 = 40960 I can confirm that these table entrys are correct for this ISO. In question is only: checksum = 31 2C D2 93 The boot info table was written by xorriso. The boot success with many systems tells us that the checksum is ok in normal situations. "-ls -l" and field "file_len" both say that in total 80 blocks should be read by the MBR. ---------- The riddle of the all zero first block is now explainable: The address conversion 8444 -> 1/6/3 matches two geometries: H/C= 128 S/H= 63 H/C= 195 S/H= 42 I would assume the first one. It would yield with the MBR bug: 8444 -> 1/2/125 which is not a valid C/H/S address under S/H=63 and thus does not have to yield a successful read operation by the BIOS. ----------- MartinS wrote:> Amazingly the size of the code in isohdpfd decreased by one byte > although it's more informative!I still did not find the spot in the Intel manual which tells me the bytes sizes of instructions and their operands. Yesterday i riddled which bytes after the DIVB instruction are the stack address: f6 36 ee 7b and whether to add or to subtract 2 with that address. Finally isohdpfc.bin told me that "ee" must become "f0" to correct the bug. (This would mean we can correct existing ISOs by this bash command echo -n $'\xf0' | dd conv=notrunc bs=1 seek=256 count=1 of=the.iso ) ----------- All old riddles seem solved now. The confusion of the two stack addresses explains the failures. The new riddle is: Why did isohdpfd.bin not load correctly the content of the following 79 blocks of isolinux.bin ? Is this reproducible in multiple attempts ? ----------- Have a nice day :) Thomas
Martin Str|mberg
2017-Mar-24 20:01 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
CC:ing syslinux David Christensen reports that my latest isohdpfd.bin reported C, thus it failed early (carry set) in finding an EBIOS. My interpretation is that it must corrupt CX so isolinux is fooled into trying EBIOS first. So, again David, can you please try this one: <http://www.ludd.ltu.se/~ams/tmp/isodavid.tgz> To keep your (our?) spirits up I've named it of you. It won't boot anything, but it will: * Hacked special David version. Won't boot anything. * * Will print the result of INT 0x13, AH=0x41: * * <CARRY> * AX * BX * CX * DX * I die now. * * where <CARRY> is either "No carry." or "Carry." depending of the * setting of the carry flag after the call. I predict it will print: Carry. <something> <something> <0 != something> <something> I die now. If it doesn't I don't know and ideas what you (Thomas mainly I suppose) want me to code/try for you/us are accepted. (Starting to flap my arms uselessly.) Meanwhile Thomas found that isolinux expects the number of heads and sectors parameters in the way that the offsets was (in isohdpfx.bin), not the pushes, so I've made another more correct corrected isohdpfx.bin here: <http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324> Please try that one too. It should work if my prediction above is right. Thanks. -- MartinS
Thomas Schmitt
2017-Mar-25 18:44 UTC
[syslinux] "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
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 now offer it for download in case the ISO fails to boot from stick on old iron: http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324 The source patch is at the second half of http://www.syslinux.org/archives/2017-March/025706.html --------------------------------------------------------------------- Details: Martin Str|mberg wrote:> > > <http://www.ludd.ltu.se/~ams/tmp/isodavid.tgz> > > > * <CARRY> > > > * AX > > > * BX > > > * CX > > > * DX > > > * I die now.i wrote:> > I place my bet on CX value 4. :))David Christensen wrote:> No carry. > 3000 > AA55 > 0004 > 0080 > I die nowHah ! CX announces no LBA addressing but Enhanced Disk Drive Support. https://en.wikipedia.org/wiki/INT_13H#INT_13h_AH.3D41h:_Check_Extensions_Present So isohdpfc pushed CX = 4 onto the stack, because it skipped andw 1,%xc So isolinux.bin read in "EHDD" mode by LBA and succeeded although it did not announce this capability. isohdpfd reached the "andw" instruction. So CX was set to (1 & 4) = 0 before it got pushed. So isolinux.bin read in "CHDD" mode by C/H/S and thus ran into the stack sequence bug. Martin:> > > http://www.ludd.ltu.se/~ams/tmp/isohdpfx.bin.170324David:> the following flashes by near the top: > ISOLINUX 6.03 20150819 CHDD Copyright (C) 1994-2014 H. Peter Anvin et alHere we have C/H/S addressing in isolinux.bin, as expected. I understand that loading and verifying the whole isolinux.bin has already succeeded when the copyright message appears. David:> Then the Debian Installer runs. I choose "Install", there is delay of ~20 > seconds and then the next screen comes up. Everything tests normally > through the partitioning screen (when I stop testing)Jubel ! \o/ No further obstacles on the way to a running Linux. We can conclude that the BIOS is not mad but just overly modest. It does not brag with its ability to use INT 13 AH 42 for LBA addressing.> It would be nice if the patch made it into Debian 8.8.I will report at the Debian bug. I am not sure whether we can convince Steve McIntyre to put a newly created MBR into the installation ISOs by default. But at least the fixed MBR should be offered for download and local application. The necessary dd command is very similar to the one which one already needs to put the ISO on stick. Have a nice day :) Thomas
Maybe Matching Threads
- "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
- "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
- "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
- "isolinux.bin missing or corrupt" when booting USB flash drive in old PC
- Initial support for sector size >512