perhaps the drive firmware presents the drive as bootable when first awakened .. to load driver like software .. or perhaps malware ...
On Fri, Jun 26, 2015 at 7:35 PM, jd1008 <jd1008@xxxxxxxxx> wrote:
I have been googling and read wikis.
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:Fine! No argument there.
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.
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.
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.
/
--
users mailing list
users@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
-- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
