Strange booting problem

[Gordon Messmer]

On 06/26/2015 07:35 PM, jd1008 wrote:
> I have been googling and read wikis.
> None of them really explain clearly
> If
>       1. a drive has no bootable partitions and
>       2. the boot code in the 1st 446 bytes does not exist (all nulls)
> then
> how does bios decide it is not bootable, move on to the next in the 
> sequence?

I didn't get a satisfactory answer from wikis, either, so I did an 
experiment.  I loaded a bootable image on a flash drive and connected 
that to a virtual machine as a USB disk.  I also added a bootable ISO to 
the VM.  I configured the VM to boot from the USB drive first, then the ISO.

The VM successfully booted from the flash drive.  I backed up the MBR.
# dd if=/dev/sdb bs=512 count=1 of=sdb.mbr

Then I zeroed 446 byes of the flash drive.
# dd if=/dev/zero bs=446 count=1 of=/dev/sdb

The VM halted when trying to boot, so I restored the boot sector and 
wiped the boot signature.
# dd if=sdb.mbr of=/dev/sdb
# dd if=/dev/zero bs=2 count=1 seek=255 of=/dev/sdb

With the boot signature wiped, the VM would boot from the ISO.

Based on testing, we can conclude that at least SeaBIOS will treat a 
boot sector with all nul bytes as a valid boot sector and run it. It 
will skip a boot sector if the boot signature in that MBR is not present.

Note that as I previously mentioned, the BIOS doesn't use the boot flag 
in the partition table.  A "bootable" partition is ONLY relevant to DOS 
type boot loaders, which use it to identify the C: drive from which they 
will boot.  It does not matter to BIOS whether a disk has any bootable 
partitions or not.

> For bios to spend an eternity looking for the boot code on a non-bootable
> drive tells me it is a bug, even if implemented according to specs 
> (thus the
> specs themselves would be at fault).

It's not looking for boot code.  It identifies a valid boot sector, 
where validity is determined by the presence of a boot signature, and 
runs that code.

I'm not an expert on BIOS, but the extent to which I've read 
documentation is fairly clear and consistent.  Execution begins at a 
specific memory location where BIOS is expected to reside.  BIOS locates 
a boot device (possibly a hardware ROM, or a disk) and continues 
execution of that code.  That code loads a kernel into memory and 
continues execution of that code.  It's not described as a stack.  
Nothing indicates that control will return to the previous chunk of code 
if it finishes or does nothing.

"bug" is not a word for "something I don't understand" or "something I 
don't like."