Long delays for USB realbtx boot

[Bruce M. Simpson]

Bruce M. Simpson wrote:
> Woops, I noticed right after I sent this message, that there was an 
> I/O error writing to the USB key from dd in my shell -- I think I was 
> using a 32768 block size instead of 16384 which might account for the 
> problem.
> I'll be sure to try this all again after I've had some sleep.

    Sure enough, this was my screwup.

    In short: I found the problem. The "active" flag wasn't set on any 
MBR slices. Tried booting from USB on 3 machines, and it all works 
perfectly.

Thanks to kib@ and jhb@ for all their hard work on real mode BTX.

For details of the bug bashing, read on.

    There is a thread here on the SYSLINUX list about USB long boot times:
        http://syslinux.zytor.com/archives/files/2005-January/004592.html
    Unrelated, as USB-HDD mode appears OK here.

    I tried this again with the EDD stuff disabled in mbr and boot1 as 
per your suggestion. Didn't make any difference. The boot delay (up to a 
minute) is still present. I note that the access light on the flash 
device DOES NOT flicker during this period, so I'm not sure that we're 
seeing sector-by-sector access.

    Of course without a POST card who can tell -- I didn't get one of 
those involved yet.

    After the delay I decided to interrupt loader(8) and do 'lsdev'. 
According to loader(8), the USB key is seen as BIOS drive C: (number 1) 
when 'mbr' is used as the mbr bootstrap.

    Turns out the AMI BIOS v2.58 on the ASUS Vintage AH-1 lets you force 
the boot mode for attached USB mass storage devices. This option is 
buried under Advanced->Chipset->SouthBridge Configuration->USB 
Configuration->USB Mass Storage Device Configuration->Emulation Type. It 
only appears if a USB mass storage device is plugged in at boot time.

    Choosing "Hard Disk" made no difference. Presumably this is because 
"Hard Disk" mode is chosen anyway if "Auto" is selected (the default) as 
the device is larger than 530MB.
    I re-examined the MBR on the key and it looks like it is using 
USB-HDD style geometry.
    Choosing "Forced FDD" mode seems to break boot completely, no change 
after 2m 40s. I'd expect this because there is an MBR on the disk, 
instead of a huge FAT filesystem.
    So USB-HDD mode appears to be chosen by the BIOS for this device as 
a default.

    So I tried reinstalling boot0 which lets me change packet/setdrv 
modes, as well as giving me some visual feedback about the boot stage.

    ...after much tweaking...

    So it appears the "active" flag was not being set for the first 
partition, it seems NanoBSD's fdisk script didn't set it; that should 
probably get patched, as this was the root cause of the USB booting delay.
    PS If there are any other drives present, then the boot menu does 
get displayed, regardless of the "mask" setting in boot0cfg.

cheers
BMS