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

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

From: MartinS <ams at ludd.ltu.se> isohdp[fp]v.S which says E or C if EBIOS or CBIOS is used. isohdppv.S also says G or M if a GPT or MBR partition is detected. Signed-off-by: MartinS <ams at ludd.ltu.se> --- Comments? diff --git a/mbr/Makefile b/mbr/Makefile index be2bded..7095396 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -21,7 +21,8 @@ include $(MAKEDIR)/embedded.mk all:

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, do we have bystanders who can read x86 assembler code or know easy-to-grasp reference docs? (I left machine code programming when i gave up using my VIC-20.) The MBR template isohdppx.bin stems from http://git.zytor.com/syslinux/syslinux.git/tree/mbr/isohdpfx.S with macro PARTITION_SUPPORT defined. One can see the error message text in there: bad_signature: call error .ascii

Thomas Schmitt wrote: > Since we know that the isolinux.bin binary is well ok on other partitions, > i'd say that the MBR code does not load the right blocks from disk when > it wants to get isolinux.bin. Yes, these are my thoughts as well. I think the jump from GRUB to the isohybrid code on the logical partition is working fine, but when the isohybrid code is trying to jump to

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

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 372 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 377 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

Hi, Martin Str|mberg wrote: > And given that space in isohdpfx is very limited (432 bytes) perhaps > the right thing might be to not have that xor in there. > But then better safe than sorry, and given that there is space _now_, > why not? I still agree. But while answering Ady's questions i get to a question of my own: Do all six fixed isohdp*.bin variations still fit into 432

Thomas Schmitt said: > I am wondering about the meaning or reason of "+20" in this assembler line: > > movl (32+20)(%si), %ecx > > Why that extra offset 20 on the byte offset 32 which is specified by > GPT specs (UEFI 2.4, 5.3.3) ? (Do i get the language wrong ?) Well I've been looking at this. It seems gptmbr.S

hello everybody, apologies if I'm missing something here Just tried to build 6.04-pre1 test version with: make bios installer and found some problems all (seemingly) related to inaccurate paths in various Makefiles. I enclose a complete patch at the end of this email, which details the problems I found and how they got fixed for me. As an example, this is the first error I got:

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 371 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 376 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

On Sun, Mar 26, 2017 at 10:13:28PM +0200, Thomas Schmitt via Syslinux wrote: > Do all six fixed isohdp*.bin variations still fit into 432 bytes ? > > mbr/Makefile builds among other MBRs: > isohdpfx.bin isohdppx.bin isohdpfx_c.bin isohdppx_c.bin > isohdpfx_f.bin isohdppx_f.bin Yes. I make my changes in my syslinux git clone. All of the above is build from isohdpfx.S with

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 >

--- mbr/Makefile | 6 +- mbr/mbr-diag.S | 377 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 382 insertions(+), 1 deletions(-) create mode 100644 mbr/mbr-diag.S diff --git a/mbr/Makefile b/mbr/Makefile index 0bdf7e3..b9d743d 100644 --- a/mbr/Makefile +++ b/mbr/Makefile @@ -17,7 +17,7 @@ topdir = .. include $(topdir)/MCONFIG.embedded -all: mbr.bin gptmbr.bin

On Sat, Mar 25, 2017 at 06:51:50PM +0100, Geert Stappers via Syslinux wrote: > It is good to see this > ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- > Date: Sat, 25 Mar 2017 05:54:09 -0700 > From: syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> > Subject: [syslinux:master] mbr/isohdpfx.S: correct pointer for

Ferenc Wagner <wferi at niif.hu> writes: > The internal Gnu-EFI build gives me grief: [...] Previous points still standing, but now I tried cleaning out everything by hand. I don't know whether it matters, but building gnu-efi pollutes its source directory (unlike syslinux itself) with the following files at least (found by git status in the gnu-efi submodule):

It is good to see this ----- Forwarded message from syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> ----- Date: Sat, 25 Mar 2017 05:54:09 -0700 From: syslinux-bot for Martin Str|mberg <ams at ludd.ltu.se> To: Syslinux commits mailing list <syslinux-commits at zytor.com> Cc: ams at ludd.ltu.se Subject: [syslinux:master] mbr/isohdpfx.S: correct pointer for heads/sectors

On Wed, Mar 22, 2017 at 12:06:12PM +0100, Thomas Schmitt via Syslinux wrote: > 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, %cx /* Sector count */ > popw %bx /* EBIOS flag */ > pushw %cx /* -16: Save

Hi, > The ISO will boot successfully (when chainloaded from grub) on 2 and > 3, but not on 5 and 6. Did you try with a boot loader other than GRUB ? Afaik, the MBRs of newly bought USB sticks often contain code which hops on the MBR code of the partition that is marked by the boot flag. At least one could exclude that your problem is in a GRUB peculiarity. Have a nice day :) Thomas

The following series of patches add a work-around for a BIOS bug to the MBR code. The user can press a Ctrl key at boot-time to force the MBR to ignore the BIOS-reported drive number (passed in register DL) and use the first hard-disk device (0x80). This works around a common problem that otherwise results in the "Missing operating system" message. If the BIOS-defined boot device order