I already explained to you
1. The disk is partitioned using fdisk.
2. I cleared the 446 bytes to nulls.
3. None of the partitions have a boot signature.
You comment "bug" is not a word for "something I don't understand"
or
"something I don't like."
is so totally irrelevant to what I have already reported wrt the drive
at hand and the BIOS at hand.
Such comments are sounding more and more like coming from an a*al attitude!!
On 06/30/2015 03:21 PM, Gordon Messmer wrote:
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."