Strange booting problem

[jd1008]

On 06/26/2015 06:09 PM, Rick Stevens wrote:
> On 06/26/2015 04:42 PM, jd1008 wrote:
>>
>>
>> On 06/26/2015 05:29 PM, Rick Stevens wrote:
>>> On 06/26/2015 04:05 PM, jd1008 wrote:
>>>>
>>>>
>>>> On 06/26/2015 04:55 PM, Gordon Messmer wrote:
>>>>> On 06/26/2015 02:51 PM, jd1008 wrote:
>>>>>> Just wondering about the bytes in the first sector which
>>>>>> you thought might be boot code that is confusing BIOS
>>>>>> to think that my usb drive is bootable.
>>>>>> The bytes you already saw are obviously not boot code.
>>>>>
>>>>> What is obvious to you is not obvious to the CPU, which simply
>>>>> executes instructions.  Everything in bytes is 0-446 is boot code,
>>>>> whether it does anything useful or not.
>>>> Fine! No argument there.
>>>> Where do device (or partition) labels reside? In the partitions?
>>>
>>> fdisk- (dos-) style partition tables do not have partition labels. GPT
>>> partitions do. They are 72 bytes long, starting at offset 56 in the
>>> partition's entry in the partition table.
>>>
>>> The location of the partition table is given in an 8-byte value
>>> starting at offset 72 in the GPT header. Generally, they start at the
>>> second LBA (LBA1) on the disk and are 128 bytes long.
>>>
>>> Filesystem labels (regardless of DPT or GPT partitioning) are located
>>> in the filesystem's superblock(s). They are 16 bytes long starting at
>>> offset 120 in each copy of the superblock.
>>
>> OK. So if only GPT partitions have labels,
>> what does mlabel do (i.e. where does it place the label?).
>>
>> $ yum provides /usr/bin/mlabel
>> Loaded plugins: langpacks, refresh-packagekit
>> mtools-4.0.18-4.fc20.x86_64 : Programs for accessing MS-DOS disks
>> without mounting the disks
>> Repo        : fedora
>> Matched from:
>> Filename    : /usr/bin/mlabel
>
> The location of a filesystem label (if supported) is dependent on the
> filesystem type, so perhaps I misled you a tad. Sorry! The 16-byte
> label area starting at offset 120 of the superblock I mentioned above
> is for ext2|3|4 filesystems.
>
> For FAT12 and FAT16 filesystems, the label is stored in an 11-byte area
> starting at offset 43 in the partition's header. For FAT32 filesystems,
> it's stored in an 11-byte area starting at offset 71 in the partition's
> header.
>
> You really can google this stuff yourself, you know.
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?

As I have already indicated, bios is not moving on to the next
disk; in this case, the internal HD.
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).
I even read a passage that said something to the effect
....."implementation dependent"....

Of course, the dependency being based on different requirements or
different standards .... etc.

Should have kept the darned page so I could give the URL.

I recall Prof. Andrew /Tannenbaum's maxim:
The great thing about standards is that there are so many of them.

/