6:25 p.m.
Laptop: Dell Latitude E6510.
OS: F20 with all updates
Grub installed on sda.
Power up ,and after bios's internal works, I do not get the grub menu.
All I get is an empty screen with the underscore cursor blinking at
upper left corner.
Reboot.
Press F12 to get the BIOS boot menu.
Select Internal HDD
Boots just fine.
6:57 p.m.
On 06/24/2015 04:25 PM, jd1008 wrote:
Laptop: Dell Latitude E6510.
OS: F20 with all updates
Grub installed on sda.
Power up ,and after bios's internal works, I do not get the grub menu.
All I get is an empty screen with the underscore cursor blinking at
upper left corner.
Reboot.
Press F12 to get the BIOS boot menu.
Select Internal HDD
Boots just fine.
Looks like the BIOS' concept of the primary boot drive is different
than "internal HDD". Check the boot order on the BIOS.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- It is better to have loved and lost. Cheaper, too! -
----------------------------------------------------------------------
7:07 p.m.
On 06/24/2015 05:57 PM, Rick Stevens wrote:
On 06/24/2015 04:25 PM, jd1008 wrote:
> Laptop: Dell Latitude E6510.
>
> OS: F20 with all updates
>
> Grub installed on sda.
>
> Power up ,and after bios's internal works, I do not get the grub menu.
> All I get is an empty screen with the underscore cursor blinking at
> upper left corner.
>
> Reboot.
>
> Press F12 to get the BIOS boot menu.
>
> Select Internal HDD
>
> Boots just fine.
Looks like the BIOS' concept of the primary boot drive is different
than "internal HDD". Check the boot order on the BIOS.
Boot order is
1. CD drive
2. USB drive
3. Internal Drive
4. Network
7:24 p.m.
On 06/25/2015 02:07 AM, jd1008 wrote:
On 06/24/2015 05:57 PM, Rick Stevens wrote:
> On 06/24/2015 04:25 PM, jd1008 wrote:
>> Laptop: Dell Latitude E6510.
>>
>> OS: F20 with all updates
>>
>> Grub installed on sda.
>>
>> Power up ,and after bios's internal works, I do not get the grub menu.
>> All I get is an empty screen with the underscore cursor blinking at
>> upper left corner.
>>
>> Reboot.
>>
>> Press F12 to get the BIOS boot menu.
>>
>> Select Internal HDD
>>
>> Boots just fine.
>
> Looks like the BIOS' concept of the primary boot drive is different
> than "internal HDD". Check the boot order on the BIOS.
Boot order is
1. CD drive
2. USB drive
3. Internal Drive
4. Network
Presuming this is a real BIOS system (not UEFI), my wild guess would be:
You have a "malconfigured" grub installed in the MBR (/dev/sda) and a
"configured" grub installed in /dev/sda<boot-partition>.
Should this reasoning apply, marking /dev/sda<boot-partition> "bootable"
(using gparted, fdisk etc.) should help.
Ralf
7:30 p.m.
On 06/24/2015 06:24 PM, Ralf Corsepius wrote:
On 06/25/2015 02:07 AM, jd1008 wrote:
>
>
> On 06/24/2015 05:57 PM, Rick Stevens wrote:
>> On 06/24/2015 04:25 PM, jd1008 wrote:
>>> Laptop: Dell Latitude E6510.
>>>
>>> OS: F20 with all updates
>>>
>>> Grub installed on sda.
>>>
>>> Power up ,and after bios's internal works, I do not get the grub menu.
>>> All I get is an empty screen with the underscore cursor blinking at
>>> upper left corner.
>>>
>>> Reboot.
>>>
>>> Press F12 to get the BIOS boot menu.
>>>
>>> Select Internal HDD
>>>
>>> Boots just fine.
>>
>> Looks like the BIOS' concept of the primary boot drive is different
>> than "internal HDD". Check the boot order on the BIOS.
> Boot order is
> 1. CD drive
> 2. USB drive
> 3. Internal Drive
> 4. Network
Presuming this is a real BIOS system (not UEFI), my wild guess would be:
You have a "malconfigured" grub installed in the MBR (/dev/sda) and a
"configured" grub installed in /dev/sda<boot-partition>.
Should this reasoning apply, marking /dev/sda<boot-partition>
"bootable" (using gparted, fdisk etc.) should help.
Ralf
It IS set to bootable (sda3)
But grub is on sda.
# fdisk -l /dev/sda
Disk /dev/sda: 931.5 GiB, 1000204886016 bytes, 1953525168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: dos
Disk identifier: 0x0004ccd9
Device Boot Start End Blocks Id System
/dev/sda1 2048 83888127 41943040 7 HPFS/NTFS/exFAT
/dev/sda2 83888128 84035583 73728 c W95 FAT32 (LBA)
/dev/sda3 * 84035584 1919970735 917967576 83 Linux
/dev/sda4 1919970736 1953525167 16777216 82 Linux swap / Solaris
7:25 p.m.
On 06/24/2015 05:07 PM, jd1008 wrote:
On 06/24/2015 05:57 PM, Rick Stevens wrote:
> On 06/24/2015 04:25 PM, jd1008 wrote:
>> Laptop: Dell Latitude E6510.
>>
>> OS: F20 with all updates
>>
>> Grub installed on sda.
>>
>> Power up ,and after bios's internal works, I do not get the grub menu.
>> All I get is an empty screen with the underscore cursor blinking at
>> upper left corner.
>>
>> Reboot.
>>
>> Press F12 to get the BIOS boot menu.
>>
>> Select Internal HDD
>>
>> Boots just fine.
>
> Looks like the BIOS' concept of the primary boot drive is different
> than "internal HDD". Check the boot order on the BIOS.
Boot order is
1. CD drive
2. USB drive
3. Internal Drive
4. Network
Ok, so do you have a CD in the drive or a USB drive plugged in? If
so, it's going to try to boot from them first.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- NEWS FLASH! Intelligence of mankind decreasing! Details at... -
- uh, when, uh, the little hand is, uh, on the... Aw, NUTS! -
----------------------------------------------------------------------
7:36 p.m.
On 06/24/2015 06:25 PM, Rick Stevens wrote:
On 06/24/2015 05:07 PM, jd1008 wrote:
>
>
> On 06/24/2015 05:57 PM, Rick Stevens wrote:
>> On 06/24/2015 04:25 PM, jd1008 wrote:
>>> Laptop: Dell Latitude E6510.
>>>
>>> OS: F20 with all updates
>>>
>>> Grub installed on sda.
>>>
>>> Power up ,and after bios's internal works, I do not get the grub menu.
>>> All I get is an empty screen with the underscore cursor blinking at
>>> upper left corner.
>>>
>>> Reboot.
>>>
>>> Press F12 to get the BIOS boot menu.
>>>
>>> Select Internal HDD
>>>
>>> Boots just fine.
>>
>> Looks like the BIOS' concept of the primary boot drive is different
>> than "internal HDD". Check the boot order on the BIOS.
> Boot order is
> 1. CD drive
> 2. USB drive
> 3. Internal Drive
> 4. Network
Ok, so do you have a CD in the drive or a USB drive plugged in? If
so, it's going to try to boot from them first.
OK, so how long before bios times out and move on
to the internal HD? The usb drive, which is
NOT bootable, has no booter installed, and
neither one of it's partitions are bootable:
# fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1bc5003b
Device Boot Start End Blocks Id System
/dev/sdb3 2048 3890251950 1945124951+ 83 Linux
/dev/sdb4 3890288670 3907029166 8370248+ 82 Linux swap / Solaris
7:40 p.m.
On 06/24/2015 05:36 PM, jd1008 wrote:
On 06/24/2015 06:25 PM, Rick Stevens wrote:
> On 06/24/2015 05:07 PM, jd1008 wrote:
>>
>>
>> On 06/24/2015 05:57 PM, Rick Stevens wrote:
>>> On 06/24/2015 04:25 PM, jd1008 wrote:
>>>> Laptop: Dell Latitude E6510.
>>>>
>>>> OS: F20 with all updates
>>>>
>>>> Grub installed on sda.
>>>>
>>>> Power up ,and after bios's internal works, I do not get the grub
menu.
>>>> All I get is an empty screen with the underscore cursor blinking at
>>>> upper left corner.
>>>>
>>>> Reboot.
>>>>
>>>> Press F12 to get the BIOS boot menu.
>>>>
>>>> Select Internal HDD
>>>>
>>>> Boots just fine.
>>>
>>> Looks like the BIOS' concept of the primary boot drive is different
>>> than "internal HDD". Check the boot order on the BIOS.
>> Boot order is
>> 1. CD drive
>> 2. USB drive
>> 3. Internal Drive
>> 4. Network
>
> Ok, so do you have a CD in the drive or a USB drive plugged in? If
> so, it's going to try to boot from them first.
OK, so how long before bios times out and move on
to the internal HD? The usb drive, which is
NOT bootable, has no booter installed, and
neither one of it's partitions are bootable:
# fdisk -l /dev/sdb
Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x1bc5003b
Device Boot Start End Blocks Id System
/dev/sdb3 2048 3890251950 1945124951+ 83 Linux
/dev/sdb4 3890288670 3907029166 8370248+ 82 Linux swap / Solaris
It's irrelevant. You might get a "No OS found" message after a while,
but it's going to keep trying to boot that as long as it's plugged in.
If you MUST leave that plugged in, then change the boot order to:
CD-->HDD-->USB-->Network
and I'll bet it works.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- "How does that damned three seashell thing work?" -
- -- Sylvester Stallone, "Demolition Man" -
----------------------------------------------------------------------
7:47 p.m.
On 06/24/2015 06:40 PM, Rick Stevens wrote:
On 06/24/2015 05:36 PM, jd1008 wrote:
>
>
> On 06/24/2015 06:25 PM, Rick Stevens wrote:
>> On 06/24/2015 05:07 PM, jd1008 wrote:
>>>
>>>
>>> On 06/24/2015 05:57 PM, Rick Stevens wrote:
>>>> On 06/24/2015 04:25 PM, jd1008 wrote:
>>>>> Laptop: Dell Latitude E6510.
>>>>>
>>>>> OS: F20 with all updates
>>>>>
>>>>> Grub installed on sda.
>>>>>
>>>>> Power up ,and after bios's internal works, I do not get the grub
>>>>> menu.
>>>>> All I get is an empty screen with the underscore cursor blinking at
>>>>> upper left corner.
>>>>>
>>>>> Reboot.
>>>>>
>>>>> Press F12 to get the BIOS boot menu.
>>>>>
>>>>> Select Internal HDD
>>>>>
>>>>> Boots just fine.
>>>>
>>>> Looks like the BIOS' concept of the primary boot drive is different
>>>> than "internal HDD". Check the boot order on the BIOS.
>>> Boot order is
>>> 1. CD drive
>>> 2. USB drive
>>> 3. Internal Drive
>>> 4. Network
>>
>> Ok, so do you have a CD in the drive or a USB drive plugged in? If
>> so, it's going to try to boot from them first.
>
> OK, so how long before bios times out and move on
> to the internal HD? The usb drive, which is
> NOT bootable, has no booter installed, and
> neither one of it's partitions are bootable:
>
>
>
> # fdisk -l /dev/sdb
>
> Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 512 bytes
> I/O size (minimum/optimal): 512 bytes / 512 bytes
> Disklabel type: dos
> Disk identifier: 0x1bc5003b
>
> Device Boot Start End Blocks Id System
> /dev/sdb3 2048 3890251950 1945124951+ 83 Linux
> /dev/sdb4 3890288670 3907029166 8370248+ 82 Linux swap / Solaris
It's irrelevant. You might get a "No OS found" message after a while,
but it's going to keep trying to boot that as long as it's plugged in.
If you MUST leave that plugged in, then change the boot order to:
CD-->HDD-->USB-->Network
and I'll bet it works.
Well, that is strange!!! It really says that BIOS is
busted
and does not have the good sense to realize the drive is not
bootable - just as in the case of having an audio CD in the
CD drive, and it ignores the presenc of the audio CD and
moves on to the next item (USB drive), which is also not
bootable, and none of it's partitions are marked bootable.
I think that what I will resort to is unplugging the usb drive
for the first few seconds to let the BIOS select internal HD
and start the boot, then plugin in the USB drive.
Sometimes, I do need to boot from a USB drive.
8:13 p.m.
On 06/24/2015 05:47 PM, jd1008 wrote:
On 06/24/2015 06:40 PM, Rick Stevens wrote:
> On 06/24/2015 05:36 PM, jd1008 wrote:
>>
>>
>> On 06/24/2015 06:25 PM, Rick Stevens wrote:
>>> On 06/24/2015 05:07 PM, jd1008 wrote:
>>>>
>>>>
>>>> On 06/24/2015 05:57 PM, Rick Stevens wrote:
>>>>> On 06/24/2015 04:25 PM, jd1008 wrote:
>>>>>> Laptop: Dell Latitude E6510.
>>>>>>
>>>>>> OS: F20 with all updates
>>>>>>
>>>>>> Grub installed on sda.
>>>>>>
>>>>>> Power up ,and after bios's internal works, I do not get the
grub
>>>>>> menu.
>>>>>> All I get is an empty screen with the underscore cursor blinking
at
>>>>>> upper left corner.
>>>>>>
>>>>>> Reboot.
>>>>>>
>>>>>> Press F12 to get the BIOS boot menu.
>>>>>>
>>>>>> Select Internal HDD
>>>>>>
>>>>>> Boots just fine.
>>>>>
>>>>> Looks like the BIOS' concept of the primary boot drive is
different
>>>>> than "internal HDD". Check the boot order on the BIOS.
>>>> Boot order is
>>>> 1. CD drive
>>>> 2. USB drive
>>>> 3. Internal Drive
>>>> 4. Network
>>>
>>> Ok, so do you have a CD in the drive or a USB drive plugged in? If
>>> so, it's going to try to boot from them first.
>>
>> OK, so how long before bios times out and move on
>> to the internal HD? The usb drive, which is
>> NOT bootable, has no booter installed, and
>> neither one of it's partitions are bootable:
>>
>>
>>
>> # fdisk -l /dev/sdb
>>
>> Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
>> Units: sectors of 1 * 512 = 512 bytes
>> Sector size (logical/physical): 512 bytes / 512 bytes
>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>> Disklabel type: dos
>> Disk identifier: 0x1bc5003b
>>
>> Device Boot Start End Blocks Id System
>> /dev/sdb3 2048 3890251950 1945124951+ 83 Linux
>> /dev/sdb4 3890288670 3907029166 8370248+ 82 Linux swap / Solaris
>
> It's irrelevant. You might get a "No OS found" message after a while,
> but it's going to keep trying to boot that as long as it's plugged in.
>
> If you MUST leave that plugged in, then change the boot order to:
>
> CD-->HDD-->USB-->Network
>
> and I'll bet it works.
Well, that is strange!!! It really says that BIOS is busted
and does not have the good sense to realize the drive is not
bootable - just as in the case of having an audio CD in the
CD drive, and it ignores the presenc of the audio CD and
moves on to the next item (USB drive), which is also not
bootable, and none of it's partitions are marked bootable.
I think that what I will resort to is unplugging the usb drive
for the first few seconds to let the BIOS select internal HD
and start the boot, then plugin in the USB drive.
Sometimes, I do need to boot from a USB drive.
I, also, occasionally need to boot off USB, but I have my boot
sequence set up as I mentioned. On the rare occasions I have to boot
from USB, THEN I use the F12 (or whatever) to select the boot drive.
This is basic engineering practice: Default to normal, provide a way to
bypass it when needed.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Is it progress if a cannibal uses a knife and fork? -
- -- Stanislaw J. Lec -
----------------------------------------------------------------------
8:27 p.m.
On 06/24/2015 07:13 PM, Rick Stevens wrote:
On 06/24/2015 05:47 PM, jd1008 wrote:
>
>
> On 06/24/2015 06:40 PM, Rick Stevens wrote:
>> On 06/24/2015 05:36 PM, jd1008 wrote:
>>>
>>>
>>> On 06/24/2015 06:25 PM, Rick Stevens wrote:
>>>> On 06/24/2015 05:07 PM, jd1008 wrote:
>>>>>
>>>>>
>>>>> On 06/24/2015 05:57 PM, Rick Stevens wrote:
>>>>>> On 06/24/2015 04:25 PM, jd1008 wrote:
>>>>>>> Laptop: Dell Latitude E6510.
>>>>>>>
>>>>>>> OS: F20 with all updates
>>>>>>>
>>>>>>> Grub installed on sda.
>>>>>>>
>>>>>>> Power up ,and after bios's internal works, I do not get
the grub
>>>>>>> menu.
>>>>>>> All I get is an empty screen with the underscore cursor
>>>>>>> blinking at
>>>>>>> upper left corner.
>>>>>>>
>>>>>>> Reboot.
>>>>>>>
>>>>>>> Press F12 to get the BIOS boot menu.
>>>>>>>
>>>>>>> Select Internal HDD
>>>>>>>
>>>>>>> Boots just fine.
>>>>>>
>>>>>> Looks like the BIOS' concept of the primary boot drive is
different
>>>>>> than "internal HDD". Check the boot order on the BIOS.
>>>>> Boot order is
>>>>> 1. CD drive
>>>>> 2. USB drive
>>>>> 3. Internal Drive
>>>>> 4. Network
>>>>
>>>> Ok, so do you have a CD in the drive or a USB drive plugged in? If
>>>> so, it's going to try to boot from them first.
>>>
>>> OK, so how long before bios times out and move on
>>> to the internal HD? The usb drive, which is
>>> NOT bootable, has no booter installed, and
>>> neither one of it's partitions are bootable:
>>>
>>>
>>>
>>> # fdisk -l /dev/sdb
>>>
>>> Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
>>> Units: sectors of 1 * 512 = 512 bytes
>>> Sector size (logical/physical): 512 bytes / 512 bytes
>>> I/O size (minimum/optimal): 512 bytes / 512 bytes
>>> Disklabel type: dos
>>> Disk identifier: 0x1bc5003b
>>>
>>> Device Boot Start End Blocks Id System
>>> /dev/sdb3 2048 3890251950 1945124951+ 83 Linux
>>> /dev/sdb4 3890288670 3907029166 8370248+ 82 Linux swap /
>>> Solaris
>>
>> It's irrelevant. You might get a "No OS found" message after a
while,
>> but it's going to keep trying to boot that as long as it's plugged in.
>>
>> If you MUST leave that plugged in, then change the boot order to:
>>
>> CD-->HDD-->USB-->Network
>>
>> and I'll bet it works.
> Well, that is strange!!! It really says that BIOS is busted
> and does not have the good sense to realize the drive is not
> bootable - just as in the case of having an audio CD in the
> CD drive, and it ignores the presenc of the audio CD and
> moves on to the next item (USB drive), which is also not
> bootable, and none of it's partitions are marked bootable.
>
> I think that what I will resort to is unplugging the usb drive
> for the first few seconds to let the BIOS select internal HD
> and start the boot, then plugin in the USB drive.
> Sometimes, I do need to boot from a USB drive.
I, also, occasionally need to boot off USB, but I have my boot
sequence set up as I mentioned. On the rare occasions I have to boot
from USB, THEN I use the F12 (or whatever) to select the boot drive.
This is basic engineering practice: Default to normal, provide a way to
bypass it when needed.
That works too.
But my BIOS is broken and I am surprised that Dell
f***** up on this.
12:22 p.m.
On 06/24/2015 05:47 PM, jd1008 wrote:
Well, that is strange!!! It really says that BIOS is busted
and does not have the good sense to realize the drive is not
bootable - just as in the case of having an audio CD in the
CD drive, and it ignores the presenc of the audio CD and
moves on to the next item (USB drive), which is also not
bootable, and none of it's partitions are marked bootable.
That's not how BIOS booting works.
Each device in the boot order is searched for boot loader code. If code
is found, control is handed off, and that code is expected to boot the
system. There's no timeout, because BIOS is no longer in control of the
system.
The bootable flag isn't used by the BIOS at all. It's used by DOS boot
loaders to determine which partition to continue boot from.
Your USB drive appears to have boot code of *some* kind in the MBR. Your
BIOS isn't broken. Dell did not "f*** up". You just need to clear the
boot sector. You can do that with:
dd if=/dev/zero of=/dev/sdb bs=446 count=1
Standard disclaimers apply: Back up your data first. Double check the
command before following advice from some rando on the internet. etc.
I think that what I will resort to is unplugging the usb drive
for the first few seconds to let the BIOS select internal HD
and start the boot, then plugin in the USB drive.
Sometimes, I do need to boot from a USB drive.
You could do that, or you could change the boot order to boot HDD before
USB, and use F12 when you need to boot USB.
Otherwise, you can't do a remote reboot because you won't be there to
unplug the USB drive.
1:33 p.m.
On 06/25/2015 11:22 AM, Gordon Messmer wrote:
On 06/24/2015 05:47 PM, jd1008 wrote:
> Well, that is strange!!! It really says that BIOS is busted
> and does not have the good sense to realize the drive is not
> bootable - just as in the case of having an audio CD in the
> CD drive, and it ignores the presenc of the audio CD and
> moves on to the next item (USB drive), which is also not
> bootable, and none of it's partitions are marked bootable.
That's not how BIOS booting works.
Each device in the boot order is searched for boot loader code. If
code is found, control is handed off, and that code is expected to
boot the system. There's no timeout, because BIOS is no longer in
control of the system.
The bootable flag isn't used by the BIOS at all. It's used by DOS
boot loaders to determine which partition to continue boot from.
Your USB drive appears to have boot code of *some* kind in the MBR.
Your BIOS isn't broken. Dell did not "f*** up". You just need to
clear the boot sector. You can do that with:
dd if=/dev/zero of=/dev/sdb bs=446 count=1
Standard disclaimers apply: Back up your data first. Double check the
command before following advice from some rando on the internet. etc.
> I think that what I will resort to is unplugging the usb drive
> for the first few seconds to let the BIOS select internal HD
> and start the boot, then plugin in the USB drive.
> Sometimes, I do need to boot from a USB drive.
You could do that, or you could change the boot order to boot HDD
before USB, and use F12 when you need to boot USB.
Otherwise, you can't do a remote reboot because you won't be there to
unplug the USB drive.
Thanx Gordon . -but
I bought the usb drive brand new and had not installed anything
on it. Just partitioned it and used it.
So, how could it contain any boot code?
Is this what manufacturers do by default? I had not encountered
this issue you raise before.
Also Re: dd: The drive is THE backup drive for the laptop :)
So, I do not have a 3rd drive to back it up to.
4:32 p.m.
On 06/25/2015 11:33 AM, jd1008 wrote:
I bought the usb drive brand new and had not installed anything
on it. Just partitioned it and used it.
So, how could it contain any boot code?
Is this what manufacturers do by default? I had not encountered
this issue you raise before.
Have a look at it:
dd if=/dev/sdb bs=446 count=1 | od -c
Does it have anything other than nul bytes?
4:51 p.m.
On 06/25/2015 03:32 PM, Gordon Messmer wrote:
On 06/25/2015 11:33 AM, jd1008 wrote:
> I bought the usb drive brand new and had not installed anything
> on it. Just partitioned it and used it.
> So, how could it contain any boot code?
> Is this what manufacturers do by default? I had not encountered
> this issue you raise before.
Have a look at it:
dd if=/dev/sdb bs=446 count=1 | od -c
Does it have anything other than nul bytes?
OK, here is the output.
Is the ; \0 305 033 the cause of the problem for BIOS?
# dd if=/dev/sdb bs=446 count=1 | /usr/bin/od -c
1+0 records in
1+0 records out
446 bytes (446 B) copied, 4.7578e-05 s, 9.4 MB/s
0000000 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0 \0
*
0000660 \0 \0 \0 \0 \0 \0 \0 \0 ; \0 305 033 \0 \0
0000676
5:26 p.m.
On 06/25/2015 02:51 PM, jd1008 wrote:
Is the ; \0 305 033 the cause of the problem for BIOS?
Possibly? Though, I should have also suggested that you check bytes at
0x1FE and 0x1FF:
# dd if=/dev/sda bs=2 count=1 skip=255 2>/dev/null | od -x
0000000 aa55
0000002
Those bytes are a signature that indicates that a boot loader is
present, at least by convention, according to wikipedia :)
5:55 p.m.
On 06/25/2015 04:26 PM, Gordon Messmer wrote:
On 06/25/2015 02:51 PM, jd1008 wrote:
> Is the ; \0 305 033 the cause of the problem for BIOS?
Possibly? Though, I should have also suggested that you check bytes
at 0x1FE and 0x1FF:
# dd if=/dev/sda bs=2 count=1 skip=255 2>/dev/null | od -x
0000000 aa55
0000002
Those bytes are a signature that indicates that a boot loader is
present, at least by convention, according to wikipedia :)
OK, but since this drive is my only backup drive, I feel
I cannot run dd to clobber those 466 bytes :(
Too risky, even if I feel nothing can go wrong, but ...
murphy's law ....
Re: sda1: here is the output:
dd if=/dev/sda bs=2 count=1 skip=255 2>/dev/null | od -x
0000000 aa55
0000002
11:51 p.m.
On 06/25/2015 03:55 PM, jd1008 wrote:
OK, but since this drive is my only backup drive, I feel
I cannot run dd to clobber those 466 bytes :(
Too risky, even if I feel nothing can go wrong, but ...
murphy's law ....
Re: sda1: here is the output:
dd if=/dev/sda bs=2 count=1 skip=255 2>/dev/null | od -x
0000000 aa55
Sure, caution is warranted. Setting your BIOS to boot HDD first, and
using F12 when you need USB boot is a perfectly reasonable solution.
My point is merely that there's nothing wrong with your BIOS.
4:51 p.m.
On 06/25/2015 03:32 PM, Gordon Messmer wrote:
On 06/25/2015 11:33 AM, jd1008 wrote:
> I bought the usb drive brand new and had not installed anything
> on it. Just partitioned it and used it.
> So, how could it contain any boot code?
> Is this what manufacturers do by default? I had not encountered
> this issue you raise before.
Have a look at it:
dd if=/dev/sdb bs=446 count=1 | od -c
Does it have anything other than nul bytes?
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 about disk label?
Could those bytes be a disk label?
5:55 p.m.
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.
6:05 p.m.
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?
6:24 p.m.
On 06/26/2015 04:05 PM, jd1008 wrote:
Where do device (or partition) labels reside? In the partitions?
In MBR, partitions don't have labels. Filesystems do regardless of what
container they're in. In GPT, partitions have 72 bytes for a label/name.
https://en.wikipedia.org/wiki/Master_boot_record
https://en.wikipedia.org/wiki/GUID_Partition_Table
6:29 p.m.
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.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Change is inevitable, except from a vending machine. -
----------------------------------------------------------------------
6:42 p.m.
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
7:09 p.m.
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.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Money can't buy happiness, but it can take the sting out of being -
- miserable! -
----------------------------------------------------------------------
9:35 p.m.
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.
/
11:10 p.m.
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(a)gmail.com> wrote:
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.
/
--
users mailing list
users(a)lists.fedoraproject.org
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
5:18 p.m.
observations:
1. GRUB's boot.img, the 440 bytes of code in the MBR/LBA 0, does not
use the partition active bit (the boot flag). So boot flag is
irrelevant in a GRUB context. The GRUB boot.img code contains the
specific LBA to jump to where core.img is found, which on MBR disks is
in the MBR gap.
2. The most likely explanation for the problem, as someone else
alluded to, is the USB drive has stale bootloader code on it that
points to no where and hangs. If this drive was partitioned with
parted (including gparted which leverages libparted), the described
behavior is intended behavior by parted developers. [1]
The solution is to do one of two things: change the boot order in
BIOS; or zero the first 440 bytes of LBA 0 with this:
# dd if=/dev/zero of=/dev/sdX bs=440 count=1
##where X is the letter for the USB drive
---
Chris Murphy
[1] Which I've complained about, but the parted developers don't
appear to care, or think they're doing the majority a favor.
If LBA 0 is completely blank at the time parted partitions it, parted
writes out some basic jump code in the first 440 bytes of the MBR that
honors the active bit to determine the jump location. If the drive
isn't meant to be a boot drive, this code just causes the CPU to jump
to nowhere. There isn't even any error handling in this jump code. So
you get exactly the behavior described.
Now, I find it absurd, but, that's life with people who think everyone
else is a moron. Because after all, if you're not creating a drive
intended to boot you have no good reason to partition it at all: a.)
format the entire block device with a file system; or b.) use LVM on
the whole block device as the method of partitioning, which is vastly
superior to MBR or GPT partitioning. Note that parted will not
overwrite already present bootloader code in the MBR.
6:13 p.m.
On 06/30/2015 03:18 PM, Chris Murphy wrote:
2. The most likely explanation for the problem, as someone else
alluded to, is the USB drive has stale bootloader code on it that
points to no where and hangs.
One of jd's earlier messages included the boot sector. It was mostly
nul bytes.
The solution is to do one of two things: change the boot order in
BIOS; or zero the first 440 bytes of LBA 0 with this:
# dd if=/dev/zero of=/dev/sdX bs=440 count=1
Why 440? The boot sector is 446 bytes.
We've already established that his BIOS will attempt to boot the system
when the first 440 bytes are zeros. That was the situation we've been
discussing all thread long.
6:19 p.m.
On Tue, Jun 30, 2015 at 5:13 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
On 06/30/2015 03:18 PM, Chris Murphy wrote:
>
> 2. The most likely explanation for the problem, as someone else
> alluded to, is the USB drive has stale bootloader code on it that
> points to no where and hangs.
One of jd's earlier messages included the boot sector. It was mostly nul
bytes.
> The solution is to do one of two things: change the boot order in
> BIOS; or zero the first 440 bytes of LBA 0 with this:
> # dd if=/dev/zero of=/dev/sdX bs=440 count=1
Why 440? The boot sector is 446 bytes.
The boot loader code area is variably sized depending on what writes
it out. GRUB's is 446 bytes. But syslinux and variants are 440 bytes,
and the parted code is maybe half that size. So wiping out 440 bytes
is sufficient but there's nothing wrong with wiping out 446 bytes.
Also, "the boot sector" is the same thing as LBA 0, which is the same
thing as MBR, in the present context. A sector is 512 bytes.
--
Chris Murphy
4:21 p.m.
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."
4:28 p.m.
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."
4:47 p.m.
On 06/30/2015 02:28 PM, jd1008 wrote:
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.
The boot signature is at bytes 511 and 512, and you indicated that it is
present:
https://lists.fedoraproject.org/pipermail/users/2015-June/462295.html
Those bytes indicate to BIOS that the disk contains boot code. I tested
wiping those bytes and verified that SeaBIOS, at least, will not attempt
to run the boot sector of a disk after they are wiped.
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!!
Computers are just machines that execute instructions. They don't
reason. They don't make decisions. Their design may not always be the
one you like, but that's not the same as being "buggy".
I'm trying to reasonably explain and demonstrate that you can predict
and control the computer's behavior, while you rant about Dell "f***ing
up." I think your anger is unjustified, both toward your system's
vendor and toward me. Maybe mellow out a little.
5:17 p.m.
The link you refer to
talks about the 2 bytes past byte 255, they they are
bytes 256 and 257.
But I already indicated the 466 bytes are null... in another usb drive I
tested,
thus no boot signature - and yet, bios hung forever because that disk
was 2nd
in boot order after cd/dvd drive, and before internal HD.
So, the laptop's BIOS is executing what? A good code for moving from disk
to disk until it finds the bootable drive in the boot sequence specified?
Clearly in this case - it does not do so.
And yet, you insist it is not a flaw.
On 06/30/2015 03:47 PM, Gordon Messmer wrote:
On 06/30/2015 02:28 PM, jd1008 wrote:
> 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.
The boot signature is at bytes 511 and 512, and you indicated that it
is present:
https://lists.fedoraproject.org/pipermail/users/2015-June/462295.html
Those bytes indicate to BIOS that the disk contains boot code. I
tested wiping those bytes and verified that SeaBIOS, at least, will
not attempt to run the boot sector of a disk after they are wiped.
> 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!!
Computers are just machines that execute instructions. They don't
reason. They don't make decisions. Their design may not always be
the one you like, but that's not the same as being "buggy".
I'm trying to reasonably explain and demonstrate that you can predict
and control the computer's behavior, while you rant about Dell
"f***ing up." I think your anger is unjustified, both toward your
system's vendor and toward me. Maybe mellow out a little.
5:19 p.m.
On 06/30/2015 03:17 PM, jd1008 wrote:
The link you refer to
talks about the 2 bytes past byte 255, they they are
bytes 256 and 257.
No, you set the block size to 2, so you are seeking (2 * 255) or 512
bytes into the disk.
But I already indicated the 466 bytes are null... in another usb
drive I
tested,
thus no boot signature - and yet, bios hung forever because that disk
was 2nd
in boot order after cd/dvd drive, and before internal HD.
So, the laptop's BIOS is executing what? A good code for moving from disk
to disk until it finds the bootable drive in the boot sequence specified?
Clearly in this case - it does not do so.
And yet, you insist it is not a flaw.
On 06/30/2015 03:47 PM, Gordon Messmer wrote:
> On 06/30/2015 02:28 PM, jd1008 wrote:
>> 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.
>
> The boot signature is at bytes 511 and 512, and you indicated that it
> is present:
> https://lists.fedoraproject.org/pipermail/users/2015-June/462295.html
>
> Those bytes indicate to BIOS that the disk contains boot code. I
> tested wiping those bytes and verified that SeaBIOS, at least, will
> not attempt to run the boot sector of a disk after they are wiped.
>
>> 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!!
>
> Computers are just machines that execute instructions. They don't
> reason. They don't make decisions. Their design may not always be
> the one you like, but that's not the same as being "buggy".
>
> I'm trying to reasonably explain and demonstrate that you can predict
> and control the computer's behavior, while you rant about Dell
> "f***ing up." I think your anger is unjustified, both toward your
> system's vendor and toward me. Maybe mellow out a little.
--
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- If at first you don't succeed, quit. No sense being a damned fool! -
----------------------------------------------------------------------
5:20 p.m.
On 06/30/2015 03:19 PM, Rick Stevens wrote:
On 06/30/2015 03:17 PM, jd1008 wrote:
> The link you refer to
> talks about the 2 bytes past byte 255, they they are
> bytes 256 and 257.
No, you set the block size to 2, so you are seeking (2 * 255) or 512
bytes into the disk.
Grrr! 2 * 255 = 510 bytes into the disk, so you were looking at bytes
510 and 511 (the last two bytes in the first sector).
> But I already indicated the 466 bytes are null... in another usb drive I
> tested,
> thus no boot signature - and yet, bios hung forever because that disk
> was 2nd
> in boot order after cd/dvd drive, and before internal HD.
>
> So, the laptop's BIOS is executing what? A good code for moving from disk
> to disk until it finds the bootable drive in the boot sequence specified?
> Clearly in this case - it does not do so.
> And yet, you insist it is not a flaw.
>
>
> On 06/30/2015 03:47 PM, Gordon Messmer wrote:
>> On 06/30/2015 02:28 PM, jd1008 wrote:
>>> 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.
>>
>> The boot signature is at bytes 511 and 512, and you indicated that it
>> is present:
>> https://lists.fedoraproject.org/pipermail/users/2015-June/462295.html
>>
>> Those bytes indicate to BIOS that the disk contains boot code. I
>> tested wiping those bytes and verified that SeaBIOS, at least, will
>> not attempt to run the boot sector of a disk after they are wiped.
>>
>>> 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!!
>>
>> Computers are just machines that execute instructions. They don't
>> reason. They don't make decisions. Their design may not always be
>> the one you like, but that's not the same as being "buggy".
>>
>> I'm trying to reasonably explain and demonstrate that you can predict
>> and control the computer's behavior, while you rant about Dell
>> "f***ing up." I think your anger is unjustified, both toward your
>> system's vendor and toward me. Maybe mellow out a little.
>
--
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Is that a buffer overflow or are you just happy to see me? -
----------------------------------------------------------------------
5:32 p.m.
Here is what happened after the 2 bytes at offset 511 and 512 were null'ed:
fdisk /dev/sdb
Welcome to fdisk (util-linux 2.24.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x2c945747.
Command (m for help): p
Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x2c945747
So, you see, those 2 bytes must have also been encoded to contain
something about the partitions.
So, with this kind of change, it destroys the partition table.
On 06/30/2015 04:19 PM, Rick Stevens wrote:
On 06/30/2015 03:17 PM, jd1008 wrote:
> The link you refer to
> talks about the 2 bytes past byte 255, they they are
> bytes 256 and 257.
No, you set the block size to 2, so you are seeking (2 * 255) or 512
bytes into the disk.
> But I already indicated the 466 bytes are null... in another usb drive I
> tested,
> thus no boot signature - and yet, bios hung forever because that disk
> was 2nd
> in boot order after cd/dvd drive, and before internal HD.
>
> So, the laptop's BIOS is executing what? A good code for moving from
> disk
> to disk until it finds the bootable drive in the boot sequence
> specified?
> Clearly in this case - it does not do so.
> And yet, you insist it is not a flaw.
>
>
> On 06/30/2015 03:47 PM, Gordon Messmer wrote:
>> On 06/30/2015 02:28 PM, jd1008 wrote:
>>> 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.
>>
>> The boot signature is at bytes 511 and 512, and you indicated that it
>> is present:
>> https://lists.fedoraproject.org/pipermail/users/2015-June/462295.html
>>
>> Those bytes indicate to BIOS that the disk contains boot code. I
>> tested wiping those bytes and verified that SeaBIOS, at least, will
>> not attempt to run the boot sector of a disk after they are wiped.
>>
>>> 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!!
>>
>> Computers are just machines that execute instructions. They don't
>> reason. They don't make decisions. Their design may not always be
>> the one you like, but that's not the same as being "buggy".
>>
>> I'm trying to reasonably explain and demonstrate that you can predict
>> and control the computer's behavior, while you rant about Dell
>> "f***ing up." I think your anger is unjustified, both toward your
>> system's vendor and toward me. Maybe mellow out a little.
>
5:36 p.m.
On Tue, Jun 30, 2015 at 4:32 PM, jd1008 <jd1008(a)gmail.com> wrote:
Here is what happened after the 2 bytes at offset 511 and 512 were
null'ed:
fdisk /dev/sdb
Welcome to fdisk (util-linux 2.24.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x2c945747.
Command (m for help): p
Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
Disklabel type: dos
Disk identifier: 0x2c945747
So, you see, those 2 bytes must have also been encoded to contain
something about the partitions.
So, with this kind of change, it destroys the partition table.
It invalidates it not destroys it. If you restore the signature, the
partition table is valid again and will work.
You really shouldn't use dd for these sorts of things, it's dangerous.
This is what wipefs is for. It also has a backup facility that makes
it easy to reverse mistakes.
http://man7.org/linux/man-pages/man8/wipefs.8.html
--
Chris Murphy
5:41 p.m.
On 06/30/2015 04:36 PM, Chris Murphy wrote:
On Tue, Jun 30, 2015 at 4:32 PM, jd1008 <jd1008(a)gmail.com>
wrote:
> Here is what happened after the 2 bytes at offset 511 and 512 were null'ed:
>
> fdisk /dev/sdb
>
> Welcome to fdisk (util-linux 2.24.2).
> Changes will remain in memory only, until you decide to write them.
> Be careful before using the write command.
>
> Device does not contain a recognized partition table.
>
> Created a new DOS disklabel with disk identifier 0x2c945747.
>
> Command (m for help): p
>
> Disk /dev/sdb: 1.8 TiB, 2000398933504 bytes, 3907029167 sectors
> Units: sectors of 1 * 512 = 512 bytes
> Sector size (logical/physical): 512 bytes / 4096 bytes
> I/O size (minimum/optimal): 4096 bytes / 33553920 bytes
> Disklabel type: dos
> Disk identifier: 0x2c945747
>
>
> So, you see, those 2 bytes must have also been encoded to contain
> something about the partitions.
>
> So, with this kind of change, it destroys the partition table.
It invalidates it not destroys it. If you restore the signature, the
partition table is valid again and will work.
You really shouldn't use dd for these sorts of things, it's dangerous.
This is what wipefs is for. It also has a backup facility that makes
it easy to reverse mistakes.
http://man7.org/linux/man-pages/man8/wipefs.8.html
So, it begs the question:
Can I create a disk with msdos partitioning scheme,
none of the partitions marked as bootable, and have bios
quickly skip over it to the next device in the boot sequence?
5:44 p.m.
On Tue, Jun 30, 2015 at 4:41 PM, jd1008 <jd1008(a)gmail.com> wrote:
So, it begs the question:
Can I create a disk with msdos partitioning scheme,
none of the partitions marked as bootable, and have bios
quickly skip over it to the next device in the boot sequence?
If you partition the disk you want skipped with parted and friends
(ill advised for reason I previously mentioned), then you need to
remove the bootload jump code it writes to LBA 0, by zeroing the first
440 bytes as I and others previously described.
If you partition with fdisk there is no code to erase it will just be
skipped. However, fdisk will not erase existing code. So this only
applies going forward. Same for gdisk. And same for their variants.
--
Chris Murphy
6:02 p.m.
On 06/30/2015 03:41 PM, jd1008 wrote:
So, it begs the question:
(that's not what "begs the question" means)
Can I create a disk with msdos partitioning scheme,
none of the partitions marked as bootable, and have bios
quickly skip over it to the next device in the boot sequence?
So far it looks like the answer is "no" or "it depends on your BIOS."
Both SeaBIOS and your Dell BIOS, based on what we've seen, will attempt
to use the boot sector of a disk with a valid MBR, even when the boot
sector is all zeros. That's consistent with all of the documentation I
can find. It's possible that other BIOS might skip an all-zero boot
sector, but we don't have any documentation of which systems behave that
way.
However, also based on testing, it seems that if you used GPT for your
partitions, then BIOS would skip over the drive during the boot
process. So, maybe that's a solution? The only reasons I can think of
to use MBR are a) you have an operating system that can't read GPT and
b) you need to boot from the drive under BIOS. I don't think either of
those apply to you.
6:10 p.m.
On Tue, Jun 30, 2015 at 5:02 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
On 06/30/2015 03:41 PM, jd1008 wrote:
>
> So, it begs the question:
(that's not what "begs the question" means)
Yes. It's an accusation.
> Can I create a disk with msdos partitioning scheme,
> none of the partitions marked as bootable, and have bios
> quickly skip over it to the next device in the boot sequence?
So far it looks like the answer is "no" or "it depends on your
BIOS."
Both SeaBIOS and your Dell BIOS, based on what we've seen, will attempt to
use the boot sector of a disk with a valid MBR, even when the boot sector is
all zeros. That's consistent with all of the documentation I can find.
It's possible that other BIOS might skip an all-zero boot sector, but we
don't have any documentation of which systems behave that way.
That seems to be true.
However, also based on testing, it seems that if you used GPT for
your
partitions, then BIOS would skip over the drive during the boot process.
No because every GPT creator also creates a PMBR which includes the
MBR boot signature that you're telling us causes (some) BIOS's to use
the entire MBR and then hang if it has nowhere to go.
So, maybe that's a solution? The only reasons I can think of to
use MBR are
a) you have an operating system that can't read GPT and b) you need to boot
from the drive under BIOS. I don't think either of those apply to you.
If you have such a BIOS, the work around is to not partition it either
MBR or GPT. If it needs partitioning, use LVM on the whole block
device. It has a signature the BIOS won't know about.
--
Chris Murphy
6:13 p.m.
Yet another possibility is to GPT partition the disk and then zero LBA
0 (the PMBR). Now to any MBR only utility, it will appear to be a
blank drive and hence dangerously unprotected. But, being lazy I won't
go look for this, I don't think the UEFI spec requires a PMBR on GPT
disks, it can just have GPT only structures. But the PMBR is what all
utilities use and will recreate if removed and the partition map is
altered. So you're probably better off just using LVM if Linux only.
If mixed platform, and you have to partition, then you have to change
the BIOS boot order. Use the one time boot order change menu when you
want to boot off an external, otherwise leave the first device as the
internal drive.
Chris Murphy
6:13 p.m.
On 06/30/2015 05:10 PM, Chris Murphy wrote:
On Tue, Jun 30, 2015 at 5:02 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
> On 06/30/2015 03:41 PM, jd1008 wrote:
>> So, it begs the question:
>
> (that's not what "begs the question" means)
Yes. It's an accusation.
>> Can I create a disk with msdos partitioning scheme,
>> none of the partitions marked as bootable, and have bios
>> quickly skip over it to the next device in the boot sequence?
>
> So far it looks like the answer is "no" or "it depends on your
BIOS."
>
> Both SeaBIOS and your Dell BIOS, based on what we've seen, will attempt to
> use the boot sector of a disk with a valid MBR, even when the boot sector is
> all zeros. That's consistent with all of the documentation I can find.
> It's possible that other BIOS might skip an all-zero boot sector, but we
> don't have any documentation of which systems behave that way.
That seems to be true.
> However, also based on testing, it seems that if you used GPT for your
> partitions, then BIOS would skip over the drive during the boot process.
No because every GPT creator also creates a PMBR which includes the
MBR boot signature that you're telling us causes (some) BIOS's to use
the entire MBR and then hang if it has nowhere to go.
> So, maybe that's a solution? The only reasons I can think of to use MBR are
> a) you have an operating system that can't read GPT and b) you need to boot
> from the drive under BIOS. I don't think either of those apply to you.
If you have such a BIOS, the work around is to not partition it either
MBR or GPT. If it needs partitioning, use LVM on the whole block
device. It has a signature the BIOS won't know about.
OMG!!!
LVM!!!
The other OS will most certainly NOT be able to make use
of that drive :) :)
6:22 p.m.
On Tue, Jun 30, 2015 at 5:13 PM, jd1008 <jd1008(a)gmail.com> wrote:
OMG!!!
LVM!!!
The other OS will most certainly NOT be able to make use
of that drive :) :)
OK so you have two options.
-Change the BIOS boot order.
- Use GPT and after making all changes either zero out LBA 0 or
otherwise invalidate the MBR's signature.
--
Chris Murphy
6:26 p.m.
UEFI spec 2.4.0 suggests the PMBR is optional.
5.2.3
"A Protective MBR may be located at LBA 0 (i.e. the first logical
block) of the disk if it is using the GPT disk layout. The Protective
MBR precedes the GUID Partition Table Header to maintain compatibility
with existing tools that do not understand GPT partition structures."
Also as a matter if trivia, the UEFI spec defines the boot code region
of the PMBR as 440 bytes. Table 15. Naturally GRUB's code length
differs from the UEFI spec.
Chris Murphy
6:35 p.m.
On 06/30/2015 04:10 PM, Chris Murphy wrote:
> However, also based on testing, it seems that if you used GPT for
your
> >partitions, then BIOS would skip over the drive during the boot process.
No because every GPT creator also creates a PMBR which includes the
MBR boot signature that you're telling us causes (some) BIOS's to use
the entire MBR and then hang if it has nowhere to go.
I see. Thanks for the correction, Chris. This whole conversation has
been educational. :)
6:11 p.m.
On 06/30/2015 05:02 PM, Gordon Messmer wrote:
On 06/30/2015 03:41 PM, jd1008 wrote:
> So, it begs the question:
(that's not what "begs the question" means)
For my case it does cause
me to ask : The conundrum of my situation
does indeed lead me to ask that question.
If you think it does not mean that - then please enlighten everyone
as to what it means :) :)
> Can I create a disk with msdos partitioning scheme,
> none of the partitions marked as bootable, and have bios
> quickly skip over it to the next device in the boot sequence?
So far it looks like the answer is "no" or "it depends on your
BIOS."
Both SeaBIOS and your Dell BIOS, based on what we've seen, will
attempt to use the boot sector of a disk with a valid MBR, even when
the boot sector is all zeros. That's consistent with all of the
documentation I can find. It's possible that other BIOS might skip an
all-zero boot sector, but we don't have any documentation of which
systems behave that way.
However, also based on testing, it seems that if you used GPT for your
partitions, then BIOS would skip over the drive during the boot
process. So, maybe that's a solution? The only reasons I can think
of to use MBR are a) you have an operating system that can't read GPT
and b) you need to boot from the drive under BIOS. I don't think
either of those apply to you.
Since my internal drive is dual boot, I do need to
boot an OS that does not
recognize GPT :(
So, if I use GPT, then, bios will skip over it if it comes before the
internal boot disk?
I will test that on a usb disk.
6:13 p.m.
On Tue, 2015-06-30 at 17:11 -0600, jd1008 wrote:
>> So, it begs the question:
>
> (that's not what "begs the question" means)
For my case it does cause me to ask : The conundrum of my situation
does indeed lead me to ask that question.
If you think it does not mean that - then please enlighten everyone
as to what it means :) :)
https://en.wikipedia.org/wiki/Begging_the_question
poc
6:28 p.m.
On 06/30/2015 05:13 PM, Patrick O'Callaghan wrote:
On Tue, 2015-06-30 at 17:11 -0600, jd1008 wrote:
>>> So, it begs the question:
>> (that's not what "begs the question" means)
> For my case it does cause me to ask : The conundrum of my situation
> does indeed lead me to ask that question.
> If you think it does not mean that - then please enlighten everyone
> as to what it means :) :)
https://en.wikipedia.org/wiki/Begging_the_question
poc
:)
My use of it was aimed against BIOS and not against the respondent :)
If BIOS will not skip over unbootable drives, and it supposedly is written
to skip over non-bootable drives - yet it does not in the situation I
present,
then that exposes the fallacy of bios skipping over non bootable drives.
Then it is made apparent by the respondents that I cannot create
non-bootable
partitions in a drive using fdisk or even parted - and have bios skip over
such drives within a boot sequence.
So in effect the partitioning scheme may be at fault to encode a boot
signature where no boot code is present, nor any partition marked as
bootable.
LVM was mentioned as a possible way to avoid this.
But the other OS cannot use LVM.
I wonder if BIOS manufacturer's are reading this list and taking note :) :)
6:37 p.m.
On Tue, Jun 30, 2015 at 5:28 PM, jd1008 <jd1008(a)gmail.com> wrote:
I wonder if BIOS manufacturer's are reading this list and taking
note :) :)
They have and they say to upgrade to UEFI.
This is a very long thread just to arrive at the conclusion that BIOS
behavior isn't ideal for your use case. The expectation is that you
set the BIOS boot order literally with the order of devices you boot
from most often so that less often is the need to use the one time
boot selection menu.
If you want to skip the USB disk usually, then make the internal drive
default. Simple. I don't know why you don't do that.
--
Chris Murphy
6:31 p.m.
On 06/30/2015 04:13 PM, Patrick O'Callaghan wrote:
On Tue, 2015-06-30 at 17:11 -0600, jd1008 wrote:
>>> So, it begs the question:
>> (that's not what "begs the question" means)
> For my case it does cause me to ask : The conundrum of my situation
> does indeed lead me to ask that question.
> If you think it does not mean that - then please enlighten everyone
> as to what it means :) :)
https://en.wikipedia.org/wiki/Begging_the_question
*nod*
The phrase "begs the question" refers to a logical fallacy. In this
context, the question was not "begged," it was "raised."
6:43 p.m.
On 06/30/2015 05:38 PM, Gordon Messmer wrote:
On 06/30/2015 04:11 PM, jd1008 wrote:
> Since my internal drive is dual boot, I do need to boot an OS that
> does not
> recognize GPT :(
What OS are you booting that won't read GPT?
It is an OS that existed before
GPT .... I still use it
because it has purchased SW that is too expensive to replace
with versions for more modern OS.
.... `nough said :) :)
6:45 p.m.
On Tue, Jun 30, 2015 at 5:43 PM, jd1008 <jd1008(a)gmail.com> wrote:
> What OS are you booting that won't read GPT?
It is an OS that existed before GPT .... I still use it
because it has purchased SW that is too expensive to replace
with versions for more modern OS.
.... `nough said :) :)
Full circle. Now you know that you will just have to keep on doing
what you've been doing: use the one time boot menu, or change the BIOS
boot order.
--
Chris Murphy
6:32 p.m.
On 06/30/2015 03:41 PM, jd1008 wrote:
So, it begs the question:
No it doesn't, it asks the question. Begging the question means
something entirely different
(https://en.wikipedia.org/wiki/Begging_the_question) and the fact that
many people misuse it that way doesn't change the meaning.
5:56 p.m.
On 06/30/2015 03:32 PM, jd1008 wrote:
So, with this kind of change, it destroys the partition table.
So it does. :(
Well, that's disappointing. Educational, but disappointing.
I missed that in testing because the bootable media I was using wrote
both an MBR and GPT labels to the USB drive. After invalidating the
MBR, the GPT still described the location of the partition.
6:01 p.m.
On 06/30/2015 04:56 PM, Gordon Messmer wrote:
On 06/30/2015 03:32 PM, jd1008 wrote:
> So, with this kind of change, it destroys the partition table.
So it does. :(
Well, that's disappointing. Educational, but disappointing.
I missed that in testing because the bootable media I was using wrote
both an MBR and GPT labels to the USB drive. After invalidating the
MBR, the GPT still described the location of the partition.
So, how can I proceed with a brand new drive,
dd /dev/zero into the first ... say 4K bytes, partition
it with fdisk, do not mark any partition bootable, so
that bios will skip over it ?
6:26 p.m.
On 06/30/2015 04:01 PM, jd1008 wrote:
So, how can I proceed with a brand new drive,
dd /dev/zero into the first ... say 4K bytes, partition
it with fdisk, do not mark any partition bootable, so
that bios will skip over it ?
Based on testing, it looks like any use of MBR will cause your BIOS to
pass control to the boot sector on the drive.
So you could dd 512 bytes of /dev/zero to the drive, or use "wipefs -a
/dev/sdX", then use parted to "mktable gpt" and set up partitions.
Assuming that you need to access the drive from a non-Linux system. If
it's Linux-only, then you have additional options like making the whole
drive an LVM PV, as Chris pointed out.
6:33 p.m.
On Tue, Jun 30, 2015 at 5:26 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
So you could dd 512 bytes of /dev/zero to the drive, or use
"wipefs -a
/dev/sdX", then use parted to "mktable gpt" and set up partitions.
That will not work. Parted replaces the PMBR in such a case. So does gdisk.
wipefs -a after parted or gdisk will cause both PMBR and GPT primary
and backup headers to be invalidated. So to wipe or invalidate the
PMBR has to be done with dd.
--
Chris Murphy
6:38 p.m.
On 06/30/2015 05:33 PM, Chris Murphy wrote:
On Tue, Jun 30, 2015 at 5:26 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
> So you could dd 512 bytes of /dev/zero to the drive, or use "wipefs -a
> /dev/sdX", then use parted to "mktable gpt" and set up partitions.
That will not work. Parted replaces the PMBR in such a case. So does gdisk.
wipefs -a after parted or gdisk will cause both PMBR and GPT primary
and backup headers to be invalidated. So to wipe or invalidate the
PMBR has to be done with dd.
OK, so after I partition with parted, I clobber the first 512 byte sector
with zeros, then the drive will retain partitioning info?
6:42 p.m.
On Tue, Jun 30, 2015 at 5:38 PM, jd1008 <jd1008(a)gmail.com> wrote:
On 06/30/2015 05:33 PM, Chris Murphy wrote:
>
> On Tue, Jun 30, 2015 at 5:26 PM, Gordon Messmer
> <gordon.messmer(a)gmail.com> wrote:
>
>> So you could dd 512 bytes of /dev/zero to the drive, or use "wipefs -a
>> /dev/sdX", then use parted to "mktable gpt" and set up
partitions.
>
> That will not work. Parted replaces the PMBR in such a case. So does
> gdisk.
>
> wipefs -a after parted or gdisk will cause both PMBR and GPT primary
> and backup headers to be invalidated. So to wipe or invalidate the
> PMBR has to be done with dd.
>
>
OK, so after I partition with parted, I clobber the first 512 byte sector
with zeros, then the drive will retain partitioning info?
GPT partitioning info, yes. If you're using an OS that doesn't know
what GPT is (?) then you have just two options remaining which is BIOS
boot order or the one time boot menu.
--
Chris Murphy
6:45 p.m.
On 06/30/2015 05:42 PM, Chris Murphy wrote:
On Tue, Jun 30, 2015 at 5:38 PM, jd1008 <jd1008(a)gmail.com>
wrote:
>
> On 06/30/2015 05:33 PM, Chris Murphy wrote:
>> On Tue, Jun 30, 2015 at 5:26 PM, Gordon Messmer
>> <gordon.messmer(a)gmail.com> wrote:
>>
>>> So you could dd 512 bytes of /dev/zero to the drive, or use "wipefs -a
>>> /dev/sdX", then use parted to "mktable gpt" and set up
partitions.
>> That will not work. Parted replaces the PMBR in such a case. So does
>> gdisk.
>>
>> wipefs -a after parted or gdisk will cause both PMBR and GPT primary
>> and backup headers to be invalidated. So to wipe or invalidate the
>> PMBR has to be done with dd.
>>
>>
> OK, so after I partition with parted, I clobber the first 512 byte sector
> with zeros, then the drive will retain partitioning info?
GPT partitioning info, yes. If you're using an OS that doesn't know
what GPT is (?) then you have just two options remaining which is BIOS
boot order or the one time boot menu.
Sigh!!!!
Thanx!
6:59 p.m.
Actually, another option is to put the legacy OS into a VM where it
can then inherit some of the features of Linux, including LVM support.
Then you can LVM this external drive instead of partitioning it, and
then make an LV (or two or three or whatever) to use as backing for
the VM, and then those VMs will see each LV as a drive, which you can
partition and format with that legacy OS's tools however you want. Or
use qcow2. Lots of options.
7:04 p.m.
On 06/30/2015 05:59 PM, Chris Murphy wrote:
Actually, another option is to put the legacy OS into a VM where it
can then inherit some of the features of Linux, including LVM support.
Then you can LVM this external drive instead of partitioning it, and
then make an LV (or two or three or whatever) to use as backing for
the VM, and then those VMs will see each LV as a drive, which you can
partition and format with that legacy OS's tools however you want. Or
use qcow2. Lots of options.
Very interesting. Very worth trying out.
Thanx!!
11:33 p.m.
On 06/30/2015 06:04 PM, jd1008 wrote:
On 06/30/2015 05:59 PM, Chris Murphy wrote:
> Actually, another option is to put the legacy OS into a VM where it
> can then inherit some of the features of Linux, including LVM support.
> Then you can LVM this external drive instead of partitioning it, and
> then make an LV (or two or three or whatever) to use as backing for
> the VM, and then those VMs will see each LV as a drive, which you can
> partition and format with that legacy OS's tools however you want. Or
> use qcow2. Lots of options.
Very interesting. Very worth trying out.
Thanx!!
This being an MSDOS partition you're talking about, there is a concept
in the Windows world known as an active partition. I don't know if it is
germane to this discussion, so I haven't raised it until now.
Microsoft's CLI took for manipulating disk partitions is a called
diskpart. The online documentation for diskpart says this about active
partitions:
active
On basic disks, marks the partition with focus as active. This informs
the basic input/output system (BIOS) or Extensible Firmware Interface
(EFI) that the partition or volume is a valid system partition or system
volume
Only partitions can be marked as active.
Important
DiskPart verifies only that the partition is capable of containing an
operating system's startup files. DiskPart does not check the contents
of the partition. If you mistakenly mark a partition as "active" and it
does not contain the operating system's startup files, your computer
might not start.
I have no idea about the mechanics of active partitions (i.e., which
bits get flipped to make a partition "active") It may be what you have
been discussing all along, but I thought I but this on the table. Seems
to me that if you mark a partition as not active, the BIOS will not try
to boot from it.
Or not.
Ignorance is my superpower
RBM
--
------------------------------------------------------------
7:14 p.m.
On Tue, Jun 30, 2015 at 5:59 PM, Chris Murphy <lists(a)colorremedies.com> wrote:
Actually, another option is to put the legacy OS into a VM where it
can then inherit some of the features of Linux, including LVM support.
Then you can LVM this external drive instead of partitioning it, and
then make an LV (or two or three or whatever) to use as backing for
the VM, and then those VMs will see each LV as a drive, which you can
partition and format with that legacy OS's tools however you want. Or
use qcow2. Lots of options.
Plus as a legacy OS, it's reasonable to assume it has unpatched
security vulnerability that will never be fixed. It's not fore sure
safer to run it in a VM, it depends on the configuration of course,
but you have the ability to better isolate it than if it's running
baremetal.
--
Chris Murphy
4:14 p.m.
On 2015-06-30 19:01, jd1008 wrote:
So, how can I proceed with a brand new drive,
dd /dev/zero into the first ... say 4K bytes, partition
it with fdisk, do not mark any partition bootable, so
that bios will skip over it ?
Don't know why no one's mentioned this, but... you could always just
install an actual bootloader on the drive that boots from the device
from which you really want to boot. (I think you can do this with grub...)
Of course, plugging that drive into any other computer might make for an
interesting experience :-).
--
Matthew
4:39 p.m.
On 07/01/2015 03:14 PM, Matthew Woehlke wrote:
On 2015-06-30 19:01, jd1008 wrote:
> So, how can I proceed with a brand new drive,
> dd /dev/zero into the first ... say 4K bytes, partition
> it with fdisk, do not mark any partition bootable, so
> that bios will skip over it ?
Don't know why no one's mentioned this, but... you could always just
install an actual bootloader on the drive that boots from the device
from which you really want to boot. (I think you can do this with grub...)
Of course, plugging that drive into any other computer might make for an
interesting experience :-).
I am sorry - but ...
the design and implementation of the traditional
(msdos) scheme and ( from what I understand so far
from all the respondents), even gpt, effectively render
the disk to have a signature which BIOS interprets
as a valid partition table AND as bootable, and thus
hangs there looking for what does not exist.
Why the design mixed 2 different things into 1, I have
no idea. But AFAIAC, it sucks and blows atthe same time.
Theoretically, supose I want my PC to have 2 identical drives,
partitioned identically, both bootable.
Say the boot order is cd-rom, drive A, then drive B.
CD-rom is empty, bios moves on to drive A. Somehow
drive A's boot code is corrupt (say somehow all nulled).
PC will never move on to drive B.
So, instead of fixing the issue, we invent new, complex
schemes that require even more complex SW like VM's,
LVM's, .... etc etc.. to solve a problem created by a very
silly error: partitioned means bootable as far as BIOS
is concerned. At least, that is what I have come to understand
and experience (when I removed the boot signature bytes).
5:32 p.m.
On Wed, Jul 1, 2015 at 3:39 PM, jd1008 <jd1008(a)gmail.com> wrote:
On 07/01/2015 03:14 PM, Matthew Woehlke wrote:
>
> On 2015-06-30 19:01, jd1008 wrote:
>>
>> So, how can I proceed with a brand new drive,
>> dd /dev/zero into the first ... say 4K bytes, partition
>> it with fdisk, do not mark any partition bootable, so
>> that bios will skip over it ?
>
> Don't know why no one's mentioned this, but... you could always just
> install an actual bootloader on the drive that boots from the device
> from which you really want to boot. (I think you can do this with grub...)
>
> Of course, plugging that drive into any other computer might make for an
> interesting experience :-).
>
I am sorry - but ...
the design and implementation of the traditional
(msdos) scheme and ( from what I understand so far
from all the respondents), even gpt, effectively render
the disk to have a signature which BIOS interprets
as a valid partition table AND as bootable, and thus
hangs there looking for what does not exist.
Why the design mixed 2 different things into 1, I have
no idea. But AFAIAC, it sucks and blows atthe same time.
Well, MBR stands for master boot record. It stands to reason, in the
epoch in which it and BIOS were invented, that you'd only use MBR if
you want to boot a system.
Once computers and drives got cheap enough, and in particular drives
got big enough, is when the mortal user with a budget usurped MBR to
do only partitioning.
--
Chris Murphy
5:37 p.m.
On 07/01/2015 04:32 PM, Chris Murphy wrote:
On Wed, Jul 1, 2015 at 3:39 PM, jd1008 <jd1008(a)gmail.com>
wrote:
>
> On 07/01/2015 03:14 PM, Matthew Woehlke wrote:
>> On 2015-06-30 19:01, jd1008 wrote:
>>> So, how can I proceed with a brand new drive,
>>> dd /dev/zero into the first ... say 4K bytes, partition
>>> it with fdisk, do not mark any partition bootable, so
>>> that bios will skip over it ?
>> Don't know why no one's mentioned this, but... you could always just
>> install an actual bootloader on the drive that boots from the device
>> from which you really want to boot. (I think you can do this with grub...)
>>
>> Of course, plugging that drive into any other computer might make for an
>> interesting experience :-).
>>
> I am sorry - but ...
> the design and implementation of the traditional
> (msdos) scheme and ( from what I understand so far
> from all the respondents), even gpt, effectively render
> the disk to have a signature which BIOS interprets
> as a valid partition table AND as bootable, and thus
> hangs there looking for what does not exist.
>
> Why the design mixed 2 different things into 1, I have
> no idea. But AFAIAC, it sucks and blows atthe same time.
Well, MBR stands for master boot record. It stands to reason, in the
epoch in which it and BIOS were invented, that you'd only use MBR if
you want to boot a system.
Once computers and drives got cheap enough, and in particular drives
got big enough, is when the mortal user with a budget usurped MBR to
do only partitioning.
So, let me ask a simple question.
Technically (I mean programatically), how difficult is it to
fix both BIOS and fdisk so that unless a partition is marked
as bootable, the partition table will not contain the boot signature
and BIOS will still accept the partitioning scheme, but
move on to the next drive in the boot order?
Thanx.
6:36 p.m.
On Wed, Jul 1, 2015 at 4:37 PM, jd1008 <jd1008(a)gmail.com> wrote:
So, let me ask a simple question.
Technically (I mean programatically), how difficult is it to
fix both BIOS and fdisk so that unless a partition is marked
as bootable, the partition table will not contain the boot signature
and BIOS will still accept the partitioning scheme, but
move on to the next drive in the boot order?
The problem isn't with fdisk. If there's a problem it's that this BIOS
instance isn't smart enough to qualify the MBR it received, fail it
for $REASONS, and then ask for the MBR from the next device in
sequence.
Answers in no particular order, sorta tongue in cheek, being the
deviloper's advocate (pun intended):
- Learn assembly, get hired to a company that OEMs firmware, fix and
advocate pushing it to users. (i.e. I think this is hard to do and
management would probably say no it's not worth the money resources
for this.)
- We have already done exactly this, it's called UEFI.
- We have already done exactly this, it's called coreboot, maybe your
system can use that? (Actually, I've never used coreboot, I don't know
that it will qualify an MBR and do a fallback as described.)
--
Chris Murphy
6:43 p.m.
On 07/01/2015 05:36 PM, Chris Murphy wrote:
On Wed, Jul 1, 2015 at 4:37 PM, jd1008 <jd1008(a)gmail.com>
wrote:
> So, let me ask a simple question.
> Technically (I mean programatically), how difficult is it to
> fix both BIOS and fdisk so that unless a partition is marked
> as bootable, the partition table will not contain the boot signature
> and BIOS will still accept the partitioning scheme, but
> move on to the next drive in the boot order?
The problem isn't with fdisk. If there's a problem it's that this BIOS
instance isn't smart enough to qualify the MBR it received, fail it
for $REASONS, and then ask for the MBR from the next device in
sequence.
Answers in no particular order, sorta tongue in cheek, being the
deviloper's advocate (pun intended):
- Learn assembly, get hired to a company that OEMs firmware, fix and
advocate pushing it to users. (i.e. I think this is hard to do and
management would probably say no it's not worth the money resources
for this.)
- We have already done exactly this, it's called UEFI.
- We have already done exactly this, it's called coreboot, maybe your
system can use that? (Actually, I've never used coreboot, I don't know
that it will qualify an MBR and do a fallback as described.)
If I had a standalone
tool on a bootable CD to use
to save current BIOS, flash one that could do the
right sequencing, and if it did not work, I would then use
the standalone tool to restore the saved BIOS.
I know of no such tool that would work on the Dell E6500 series laptops.
One almost needs to be able to pull out existing rom,
insert the rom of the bios you suggest, and try it.
11:56 a.m.
On 07/01/2015 02:39 PM, jd1008 wrote:
On 07/01/2015 03:14 PM, Matthew Woehlke wrote:
> On 2015-06-30 19:01, jd1008 wrote:
>> So, how can I proceed with a brand new drive,
>> dd /dev/zero into the first ... say 4K bytes, partition
>> it with fdisk, do not mark any partition bootable, so
>> that bios will skip over it ?
> Don't know why no one's mentioned this, but... you could always just
> install an actual bootloader on the drive that boots from the device
> from which you really want to boot. (I think you can do this with
> grub...)
>
> Of course, plugging that drive into any other computer might make for an
> interesting experience :-).
>
I am sorry - but ...
the design and implementation of the traditional
(msdos) scheme and ( from what I understand so far
from all the respondents), even gpt, effectively render
the disk to have a signature which BIOS interprets
as a valid partition table AND as bootable, and thus
hangs there looking for what does not exist.
Why the design mixed 2 different things into 1, I have
no idea. But AFAIAC, it sucks and blows atthe same time.
Theoretically, supose I want my PC to have 2 identical drives,
partitioned identically, both bootable.
Say the boot order is cd-rom, drive A, then drive B.
CD-rom is empty, bios moves on to drive A. Somehow
drive A's boot code is corrupt (say somehow all nulled).
PC will never move on to drive B.
So, instead of fixing the issue, we invent new, complex
schemes that require even more complex SW like VM's,
LVM's, .... etc etc.. to solve a problem created by a very
silly error: partitioned means bootable as far as BIOS
is concerned. At least, that is what I have come to understand
and experience (when I removed the boot signature bytes).
Simply nulling bytes 510 and 511 of the first sector (getting rid
of the boot signature) should make the BIOS ignore the drive. fdisk
will complain that the partition table is invalid because of the
invalid boot signature, but that's all. The rest of the drive should
be functional and usable--just not bootable.
Tagging a partition as "bootable" only affects Microsoft OSes. The
boot loader itself doesn't care. What that boot loader loads and
hands control to--THAT might care about the bootable flag. The Linux
kernel ignores it.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- Animal testing is futile. They always get nervous and give the -
- wrong answers -
----------------------------------------------------------------------
12:07 p.m.
On 07/02/2015 10:56 AM, Rick Stevens wrote:
On 07/01/2015 02:39 PM, jd1008 wrote:
>
>
> On 07/01/2015 03:14 PM, Matthew Woehlke wrote:
>> On 2015-06-30 19:01, jd1008 wrote:
>>> So, how can I proceed with a brand new drive,
>>> dd /dev/zero into the first ... say 4K bytes, partition
>>> it with fdisk, do not mark any partition bootable, so
>>> that bios will skip over it ?
>> Don't know why no one's mentioned this, but... you could always just
>> install an actual bootloader on the drive that boots from the device
>> from which you really want to boot. (I think you can do this with
>> grub...)
>>
>> Of course, plugging that drive into any other computer might make
>> for an
>> interesting experience :-).
>>
> I am sorry - but ...
> the design and implementation of the traditional
> (msdos) scheme and ( from what I understand so far
> from all the respondents), even gpt, effectively render
> the disk to have a signature which BIOS interprets
> as a valid partition table AND as bootable, and thus
> hangs there looking for what does not exist.
>
> Why the design mixed 2 different things into 1, I have
> no idea. But AFAIAC, it sucks and blows atthe same time.
>
> Theoretically, supose I want my PC to have 2 identical drives,
> partitioned identically, both bootable.
> Say the boot order is cd-rom, drive A, then drive B.
> CD-rom is empty, bios moves on to drive A. Somehow
> drive A's boot code is corrupt (say somehow all nulled).
> PC will never move on to drive B.
>
> So, instead of fixing the issue, we invent new, complex
> schemes that require even more complex SW like VM's,
> LVM's, .... etc etc.. to solve a problem created by a very
> silly error: partitioned means bootable as far as BIOS
> is concerned. At least, that is what I have come to understand
> and experience (when I removed the boot signature bytes).
Simply nulling bytes 510 and 511 of the first sector (getting rid
of the boot signature) should make the BIOS ignore the drive. fdisk
will complain that the partition table is invalid because of the
invalid boot signature, but that's all. The rest of the drive should
be functional and usable--just not bootable.
Tagging a partition as "bootable" only affects Microsoft OSes. The
boot loader itself doesn't care. What that boot loader loads and
hands control to--THAT might care about the bootable flag. The Linux
kernel ignores it.
Will try and get back to you.
1:02 p.m.
On Thu, Jul 2, 2015 at 10:56 AM, Rick Stevens <ricks(a)alldigital.com> wrote:
Simply nulling bytes 510 and 511 of the first sector (getting rid
of the boot signature) should make the BIOS ignore the drive.
That signature applies to the entire MBR, including the partition
scheme. The signature is not a "boot me" signature.
GRUB probably shouldn't honor that MBR as valid, including its
partition scheme. I don't know if it does or not. The kernel won't,
and therefore won't see the partitions, and neither will libblkid.
fdisk
will complain that the partition table is invalid because of the
invalid boot signature, but that's all. The rest of the drive should
be functional and usable--just not bootable.
This is not correct.
Tagging a partition as "bootable" only affects Microsoft OSes.
This is not completely correct. It depends on what boot code is in the
MBR. GRUB boot.img doesn't use the active bit. But parted's code does,
as does syslinux/extlinux.
--
Chris Murphy
2:27 p.m.
On 07/02/2015 12:02 PM, Chris Murphy wrote:
On Thu, Jul 2, 2015 at 10:56 AM, Rick Stevens
<ricks(a)alldigital.com> wrote:
> Simply nulling bytes 510 and 511 of the first sector (getting rid
> of the boot signature) should make the BIOS ignore the drive.
That signature applies to the entire MBR, including the partition
scheme. The signature is not a "boot me" signature.
GRUB probably shouldn't honor that MBR as valid, including its
partition scheme. I don't know if it does or not. The kernel won't,
and therefore won't see the partitions, and neither will libblkid.
fdisk
> will complain that the partition table is invalid because of the
> invalid boot signature, but that's all. The rest of the drive should
> be functional and usable--just not bootable.
This is not correct.
> Tagging a partition as "bootable" only affects Microsoft OSes.
This is not completely correct. It depends on what boot code is in the
MBR. GRUB boot.img doesn't use the active bit. But parted's code does,
as does syslinux/extlinux.
What a convoluted frickin' mess!!
2:33 p.m.
On Thu, Jul 2, 2015 at 1:27 PM, jd1008 <jd1008(a)gmail.com> wrote:
On 07/02/2015 12:02 PM, Chris Murphy wrote:
>
> On Thu, Jul 2, 2015 at 10:56 AM, Rick Stevens <ricks(a)alldigital.com>
> wrote:
>
>> Simply nulling bytes 510 and 511 of the first sector (getting rid
>> of the boot signature) should make the BIOS ignore the drive.
>
> That signature applies to the entire MBR, including the partition
> scheme. The signature is not a "boot me" signature.
>
> GRUB probably shouldn't honor that MBR as valid, including its
> partition scheme. I don't know if it does or not. The kernel won't,
> and therefore won't see the partitions, and neither will libblkid.
>
>
>
> fdisk
>>
>> will complain that the partition table is invalid because of the
>> invalid boot signature, but that's all. The rest of the drive should
>> be functional and usable--just not bootable.
>
> This is not correct.
>
>
>> Tagging a partition as "bootable" only affects Microsoft OSes.
>
> This is not completely correct. It depends on what boot code is in the
> MBR. GRUB boot.img doesn't use the active bit. But parted's code does,
> as does syslinux/extlinux.
>
>
What a convoluted frickin' mess!!
And it will always be that way, frozen in the time in which it was invented.
And hence there's UEFI. So try reading the UEFI spec. It's vastly more
complex, with tons more bugs in the implementations, but the spec
itself is not difficult to follow (although it's nearly 2300 pages
long so that might make it difficult, just not difficult to follow -
it's fairly well organized and hey at least it's documented unlike
BIOS).
--
Chris Murphy
3:15 p.m.
On 07/02/2015 12:02 PM, Chris Murphy wrote:
On Thu, Jul 2, 2015 at 10:56 AM, Rick Stevens
<ricks(a)alldigital.com> wrote:
> Simply nulling bytes 510 and 511 of the first sector (getting rid
> of the boot signature) should make the BIOS ignore the drive.
That signature applies to the entire MBR, including the partition
scheme. The signature is not a "boot me" signature.
GRUB probably shouldn't honor that MBR as valid, including its
partition scheme. I don't know if it does or not. The kernel won't,
and therefore won't see the partitions, and neither will libblkid.
fdisk
> will complain that the partition table is invalid because of the
> invalid boot signature, but that's all. The rest of the drive should
> be functional and usable--just not bootable.
This is not correct.
> Tagging a partition as "bootable" only affects Microsoft OSes.
This is not completely correct. It depends on what boot code is in the
MBR. GRUB boot.img doesn't use the active bit. But parted's code does,
as does syslinux/extlinux.
I confirm 2 things:
1. the drive is indeed skipped
2. linux cannot see any partitions, so nothing gets mounted.
5:44 p.m.
On 06/30/2015 03:17 PM, jd1008 wrote:
The link you refer to
talks about the 2 bytes past byte 255, they they are
bytes 256 and 257.
No, they're the two byte block at the 255th block of two bytes.
https://en.wikipedia.org/wiki/Master_boot_record
Again, bytes 0-446 are boot code. Bytes 256 and 257 are not special
locations, they fall within the boot sector. Bytes 511 and 512 (or,
bytes at offset 510 and 511) are the boot signature. When present, that
signature indicates that a boot sector is present and can be used.
Testing indicates that if the signature is present, BIOS will load that
sector into memory and continue execution of the code that it contains.
Control will not return to BIOS.
But I already indicated the 466 bytes are null...
Doesn't matter. The documentation doesn't say that the contents of the
446 bytes are tested. nul bytes are valid opcodes in x86.
So, the laptop's BIOS is executing what?
Whatever it finds in the first disk that has a valid boot signature.
Once it finds a disk with a signature, it passes execution to the boot
sector and does not continue searching.
5:47 p.m.
On Tue, Jun 30, 2015 at 4:44 PM, Gordon Messmer
<gordon.messmer(a)gmail.com> wrote:
On 06/30/2015 03:17 PM, jd1008 wrote:
>
> The link you refer to
> talks about the 2 bytes past byte 255, they they are
> bytes 256 and 257.
No, they're the two byte block at the 255th block of two bytes.
https://en.wikipedia.org/wiki/Master_boot_record
Again, bytes 0-446 are boot code. Bytes 256 and 257 are not special
locations, they fall within the boot sector. Bytes 511 and 512 (or, bytes
at offset 510 and 511) are the boot signature. When present, that signature
indicates that a boot sector is present and can be used. Testing indicates
that if the signature is present, BIOS will load that sector into memory and
continue execution of the code that it contains. Control will not return to
BIOS.
> But I already indicated the 466 bytes are null...
Doesn't matter. The documentation doesn't say that the contents of the 446
bytes are tested. nul bytes are valid opcodes in x86.
It's possible this is BIOS specific. In the case I've tested, it's
actually faux BIOS in the form of an EFI CSM. If the first 440 bytes
are zeros, it doesn't consider that device bootable, and thus it's
skipped. But I don't recall SeaBIOS or vbox's BIOS behavior, even
though I've gotten bit by this confusion many times...
--
Chris Murphy
5:54 p.m.
I just set Vbox boot order to HD > CD/DVD. And added a new blank VDI
for the HD, and a Fedora 22 Live CD ISO for the CD. And it boots from
the CD. So the HD is clearly skipped.
If I partition the HD with fdisk with a single partition and no boot
flag, I get the same result. So clearly this BIOS is also
ignoring/skipping the HD when bootloader code in the first 440 bytes
is absent but otherwise has a valid signature and partition
information.
If I partition a new blank VDI with parted, boot hangs indefinitely
with no error message.
Chris Murphy
5:59 p.m.
On 06/30/2015 04:54 PM, Chris Murphy wrote:
I just set Vbox boot order to HD > CD/DVD. And added a new blank
VDI
for the HD, and a Fedora 22 Live CD ISO for the CD. And it boots from
the CD. So the HD is clearly skipped.
If I partition the HD with fdisk with a single partition and no boot
flag, I get the same result. So clearly this BIOS is also
ignoring/skipping the HD when bootloader code in the first 440 bytes
is absent but otherwise has a valid signature and partition
information.
If I partition a new blank VDI with parted, boot hangs indefinitely
with no error message.
Chris Murphy
Well, clearly we are comparing the behaviors of 2 very different
bioses.
5:04 p.m.
New subject: Strange booting problem - Off list
Hi Rick,
Re: my /dev/sdb:
dd if=/dev/sdb bs=2 count=1 skip=255 2>/dev/null | od -x
0000000 aa55
0000002
If these are the bytes that indicate a boot signature,
can they be "null'ed" safely??
Thanx.
5:32 p.m.
New subject: Strange booting problem - Off list
On 06/30/2015 03:04 PM, jd1008 wrote:
dd if=/dev/sdb bs=2 count=1 skip=255 2>/dev/null | od -x
0000000 aa55
If these are the bytes that indicate a boot signature,
can they be "null'ed" safely??
Doing so worked for me, when testing under SeaBIOS.
dd if=/dev/zero bs=2 count=1 seek=255 of=/dev/sdb
5:35 p.m.
New subject: Strange booting problem - Off list
On 06/30/2015 04:32 PM, Gordon Messmer wrote:
On 06/30/2015 03:04 PM, jd1008 wrote:
> dd if=/dev/sdb bs=2 count=1 skip=255 2>/dev/null | od -x
> 0000000 aa55
>
> If these are the bytes that indicate a boot signature,
> can they be "null'ed" safely??
Doing so worked for me, when testing under SeaBIOS.
dd if=/dev/zero bs=2 count=1 seek=255 of=/dev/sdb
Well, as I just replied, nulling
those 2 bytes wipes out
partitioning info.
6:46 p.m.
On 06/26/2015 04: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.
My bad, the table starts in the third LBA (LBA2). LBA0 is the MBR,
LBA1 is the GPT header, and the partition table starts at LBA2. As an
aside, EFI specifies that there will be at least 128 partition entries,
so this will occupy at least 16K (16,384) bytes.
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.
----------------------------------------------------------------------
- Rick Stevens, Systems Engineer, AllDigital ricks(a)alldigital.com -
- AIM/Skype: therps2 ICQ: 226437340 Yahoo: origrps2 -
- -
- When all else fails, try reading the instructions. -
----------------------------------------------------------------------
7:43 p.m.
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.
Are 466 null bytes also treated as boot
code?
7:08 a.m.
On Wed, 2015-06-24 at 18:36 -0600, jd1008 wrote:
OK, so how long before bios times out and move on
to the internal HD? The usb drive, which is
NOT bootable, has no booter installed, and
neither one of it's partitions are bootable:
Some BIOSs will not do that.
I have one PC that cannot be booted if there's a USB drive (of any kind)
plugged in, despite the BIOS being set to boot from the HDD first.
I had another PC that cannot be secured. You can set BIOS passwords,
and save the BIOS to only boot from the HDD. But *before* the BIOS is a
wide-open boot menu that cannot be locked down, so someone could easily
bypass your security measures to boot from some other drive.
Some manufactures are just crap at programming their motherboards. And
if they weren't closed source, we could do something about it.
Yes, I'm aware that there are open source BIOSs, but you can't just
replace the BIOS on *any* motherboard that you happen to have.
--
tim@localhost ~]$ uname -rsvp
Linux 3.19.8-100.fc20.i686 #1 SMP Tue May 12 17:42:35 UTC 2015 i686
All mail to my mailbox is automatically deleted, there is no point trying
to privately email me, I will only read messages posted to the public lists.
George Orwell's '1984' was supposed to be a warning against tyranny, not
a set of instructions for supposedly democratic governments.
3221
days inactive
3229
days old
89 comments
11 participants
participants (11)
-
Chris Murphy -
Gordon Messmer -
JD -
Joe Zeff -
Matthew Woehlke -
Patrick O'Callaghan -
Ralf Corsepius -
Rick Stevens -
Ronal B Morse -
Tim -
Tod Merley