similar to: No subject

Hi, friends It is described at this page: http://superuser.com/questions/195275/usb-boot-no-default-or-ui-configuration-directive-found <http://superuser.com/questions/195275/usb-boot-no-default-or-ui-configuration-directive-found>help, thanks! -- regards chenge

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

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

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 >

On Fri, Mar 24, 2017 at 2:55 PM, Martin Str|mberg via Syslinux <syslinux at zytor.com> wrote: > 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. >>

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.

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

I have tested isolinux without a config file and discovered the following: ISOLINUX 3.86 30-g9cc609c ETCD Copyright (C) 1994-2010 H. Peter Anvin et al No DEFAULT or UI configuration directive found! boot: and ISOLINUX 4.02 4.02* ETCD Copyright (C) 1994-2010 H. Peter Anvin et al ERROR: No configuration file found seems to hang here. no_default_msg gets printed too, but is overwritten since the

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

Hi, David Christensen wrote: > I use this USB flash drive for bootable installer images; I do not > attempt to mount it. I don't know that I could, even if I wanted to: mkdir /mnt/iso mount /dev/sdc /mnt/iso or, because partition 1 starts at block 0, you may mount it too mount /dev/sdc1 /mnt/iso > # fdisk -l /dev/sdc > WARNING: GPT (GUID Partition Table) detected on

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, 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

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

On 03/18/2017 03:02 PM, Thomas Schmitt via Syslinux wrote: > Hi, > > David Christensen wrote: >> I use this USB flash drive for bootable installer images; I do not >> attempt to mount it. I don't know that I could, even if I wanted to: > > mkdir /mnt/iso > mount /dev/sdc /mnt/iso > > or, because partition 1 starts at block 0, you may mount it too >

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

At first I thought, I was dealing with the known EBIOS/CBIOS-problem. The symptom was exactly the same (hangs at ...EBIOS). As 3.10-pre8 and 3.10-pre9, in contrary what was mentioned in the ML, did not bring any improvement, I looked deeper into what could be my specific problem. I found out that the program just halted at 'cmp [esi],edx' (line 658; ldlinux.asm 3.10-pre9)! By replacing

Hey folks, I am seeing this issue with machines on which I do I/O ops thru cbios mode. I noticed some of the reads at high sectors seem to be returning the wrong data even though the op itself succeds. The output of the int 13 call returns EFLAGS: 0x246 (CF is 0) and EAX is 0x1, which indicates success according to ralph brown's int13/02h page. The I/O code is exactly the same as the one in

> > 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 >