[opensuse] Trying to understand booting GPT disk with BIOS (not UEFI) situation
Hi, I did a virtual install under vmplayer, but on real hard disk of 1.8 TiB (2 TB). It has to run as root to have access to the disk. The "bios" screen seems to be bios type, I do not see entries that would hint at uefi. The relevant settings in the vmx file are, I think, these: #!/usr/local/bin/vmware .encoding = "UTF-8" config.version = "8" virtualHW.version = "12" According to <http://www.serverwatch.com/server-tutorials/enabling-uefi-on-virtual-machines.html>, to set the bios type to uefi, we need to add this entry: firmware = "efi" and it is not there, so it is BIOS. The disk I partitioned externally with gparted from scratch, creating first a pure GPT table with some partitions. Then I booted Leap 42.1 install media on vmlayer to install it, using full disk device. And it boots, but I don't understand how. O:-) This is the partition table: linux-leap421-r:~ # fdisk -l /dev/sda Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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: gpt Disk identifier: 4C81D390-4C41-.... Device Start End Sectors Size Type /dev/sda1 30722048 61442047 30720000 14.7G Linux swap /dev/sda2 2048 30722047 30720000 14.7G Microsoft basic data /dev/sda3 61442048 163842047 102400000 48.8G Microsoft basic data /dev/sda4 163842048 163862527 20480 10M BIOS boot /dev/sda5 163862528 266262527 102400000 48.8G Microsoft basic data Partition table entries are not in disk order. linux-leap421-r:~ # I used "Boot Info Script 0.72" (https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript) to obtain information on the boot process. Notice that there is no partition marked as boot, and that there is a "BIOS boot" partition, very small. The MBR has this: => Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/sda. sda2 is ext4, contains the root of the system, and grub2 is installed on its boot sector, which looks for core.img at a certain sector. That's normal. sda4: File system: BIOS Boot partition Boot sector type: - Boot sector info: Not much info about it. Another view of the partition table: Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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 Partition Boot Start Sector End Sector # of Sectors Id System /dev/sda1 1 3,907,029,167 3,907,029,167 ee GPT GUID Partition Table detected. Partition Start Sector End Sector # of Sectors System /dev/sda1 30,722,048 61,442,047 30,720,000 Swap partition (Linux) /dev/sda2 2,048 30,722,047 30,720,000 Data partition (Windows/Linux) /dev/sda3 61,442,048 163,842,047 102,400,000 Data partition (Windows/Linux) /dev/sda4 163,842,048 163,862,527 20,480 BIOS Boot partition /dev/sda5 163,862,528 266,262,527 102,400,000 Data partition (Windows/Linux) Now, what I don't understand is, how is BIOS booting this disk. Obviously it has to read the MBR, and this boots sda2. How does it know it has to boot this partition? There is no boot mark, so either it is hardcoded, or the information is in sda4, the "BIOS Boot partition". What is its role? I have not been able to mount sda4, its filesystem is not recognized. What controls it? Probably it is done by "Syslinux GPTMBR", but that's just a guess. I assume that there is not enough space in the MBR, less than 512 bytes, to control booting of a GPT disk (in bios mode), so what it does is boot another partition by location on disk (sector addressing), the "BIOS Boot partition". This method of booting is unknown to me, but I'm interested because it allows me to upgrade the hard disks of my classic BIOS machines to bigger hard disks. And of course, with GPT disks I can install as many operating systems I want to boot without "tricks", so it is nice. But I'd like to know more about it. RTFM pointers appreciated ;-) P.S., unrelated: I had to resend this using another mail provider, my normal one refused: <2.6> 2016-02-02 15:49:14 Telcontar postfix 6949 - - Untrusted TLS connection established to smtp.telefonica.net[86.109.99.70]:25: TLSv1 with cipher RC4-SHA (128/128 bits) <2.6> 2016-02-02 15:49:14 Telcontar postfix 6949 - - 0F376609BF: to=<opensuse@opensuse.org>, relay=smtp.telefonica.net[86.109.99.70]:25, delay=0.82, delays=0.07/0.13/0.43/0.18, dsn=5.0.0, status=bounced (host smtp.telefonica.net[86.109.99.70] said: 522 SPAM messages are not accepted (in reply to end of DATA command)) <2.6> 2016-02-02 15:49:14 Telcontar postfix 6943 - - EF8F760D0A: message-id=<20160202144914.EF8F760D0A@Telcontar.valinor> <2.6> 2016-02-02 15:49:15 Telcontar postfix 6950 - - 0F376609BF: sender non-delivery notification: EF8F760D0A <2.6> 2016-02-02 15:49:15 Telcontar postfix 3566 - - EF8F760D0A: from=<>, size=7692, nrcpt=1 (queue active) <2.6> 2016-02-02 15:49:15 Telcontar postfix 3566 - - 0F376609BF: removed And I got no bounce message :-/ -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
Read in the link "GPT and protective MBR". http://www.system-rescue-cd.org/Sysresccd-Partitioning-EN-The-new-GPT-disk-l... Op 02-02-16 16:36, Carlos E. R. schreef:
Hi,
I did a virtual install under vmplayer, but on real hard disk of 1.8 TiB (2 TB). It has to run as root to have access to the disk.
The "bios" screen seems to be bios type, I do not see entries that would hint at uefi. The relevant settings in the vmx file are, I think, these:
#!/usr/local/bin/vmware .encoding = "UTF-8" config.version = "8" virtualHW.version = "12"
According to <http://www.serverwatch.com/server-tutorials/enabling-uefi-on-virtual-machines.html>, to set the bios type to uefi, we need to add this entry:
firmware = "efi"
and it is not there, so it is BIOS.
The disk I partitioned externally with gparted from scratch, creating first a pure GPT table with some partitions. Then I booted Leap 42.1 install media on vmlayer to install it, using full disk device. And it boots, but I don't understand how. O:-)
This is the partition table:
linux-leap421-r:~ # fdisk -l /dev/sda
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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: gpt Disk identifier: 4C81D390-4C41-....
Device Start End Sectors Size Type /dev/sda1 30722048 61442047 30720000 14.7G Linux swap /dev/sda2 2048 30722047 30720000 14.7G Microsoft basic data /dev/sda3 61442048 163842047 102400000 48.8G Microsoft basic data /dev/sda4 163842048 163862527 20480 10M BIOS boot /dev/sda5 163862528 266262527 102400000 48.8G Microsoft basic data
Partition table entries are not in disk order.
linux-leap421-r:~ #
I used "Boot Info Script 0.72" (https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript) to obtain information on the boot process.
Notice that there is no partition marked as boot, and that there is a "BIOS boot" partition, very small.
The MBR has this:
=> Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/sda.
sda2 is ext4, contains the root of the system, and grub2 is installed on its boot sector, which looks for core.img at a certain sector. That's normal.
sda4:
File system: BIOS Boot partition Boot sector type: - Boot sector info:
Not much info about it.
Another view of the partition table:
Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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
Partition Boot Start Sector End Sector # of Sectors Id System
/dev/sda1 1 3,907,029,167 3,907,029,167 ee GPT
GUID Partition Table detected.
Partition Start Sector End Sector # of Sectors System /dev/sda1 30,722,048 61,442,047 30,720,000 Swap partition (Linux) /dev/sda2 2,048 30,722,047 30,720,000 Data partition (Windows/Linux) /dev/sda3 61,442,048 163,842,047 102,400,000 Data partition (Windows/Linux) /dev/sda4 163,842,048 163,862,527 20,480 BIOS Boot partition /dev/sda5 163,862,528 266,262,527 102,400,000 Data partition (Windows/Linux)
Now, what I don't understand is, how is BIOS booting this disk. Obviously it has to read the MBR, and this boots sda2. How does it know it has to boot this partition? There is no boot mark, so either it is hardcoded, or the information is in sda4, the "BIOS Boot partition". What is its role?
I have not been able to mount sda4, its filesystem is not recognized. What controls it? Probably it is done by "Syslinux GPTMBR", but that's just a guess.
I assume that there is not enough space in the MBR, less than 512 bytes, to control booting of a GPT disk (in bios mode), so what it does is boot another partition by location on disk (sector addressing), the "BIOS Boot partition".
This method of booting is unknown to me, but I'm interested because it allows me to upgrade the hard disks of my classic BIOS machines to bigger hard disks. And of course, with GPT disks I can install as many operating systems I want to boot without "tricks", so it is nice.
But I'd like to know more about it. RTFM pointers appreciated ;-)
P.S., unrelated: I had to resend this using another mail provider, my normal one refused:
<2.6> 2016-02-02 15:49:14 Telcontar postfix 6949 - - Untrusted TLS connection established to smtp.telefonica.net[86.109.99.70]:25: TLSv1 with cipher RC4-SHA (128/128 bits) <2.6> 2016-02-02 15:49:14 Telcontar postfix 6949 - - 0F376609BF: to=<opensuse@opensuse.org>, relay=smtp.telefonica.net[86.109.99.70]:25, delay=0.82, delays=0.07/0.13/0.43/0.18, dsn=5.0.0, status=bounced (host smtp.telefonica.net[86.109.99.70] said: 522 SPAM messages are not accepted (in reply to end of DATA command)) <2.6> 2016-02-02 15:49:14 Telcontar postfix 6943 - - EF8F760D0A: message-id=<20160202144914.EF8F760D0A@Telcontar.valinor> <2.6> 2016-02-02 15:49:15 Telcontar postfix 6950 - - 0F376609BF: sender non-delivery notification: EF8F760D0A <2.6> 2016-02-02 15:49:15 Telcontar postfix 3566 - - EF8F760D0A: from=<>, size=7692, nrcpt=1 (queue active) <2.6> 2016-02-02 15:49:15 Telcontar postfix 3566 - - 0F376609BF: removed
And I got no bounce message :-/
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 2016-02-02 17:25, Hans de Faber wrote:
Read in the link "GPT and protective MBR". http://www.system-rescue-cd.org/Sysresccd-Partitioning-EN-The-new-GPT-disk-l...
Thanks! That explains the situation. And using "parted" as the article does gives an important bit of information that fdisk doesn't: the "Flags" column. One partition has "legacy_boot". linux-leap421-r:~ # parted /dev/sda print Model: ATA VMware Virtual S (scsi) Disk /dev/sda: 2000GB Sector size (logical/physical): 512B/512B Partition Table: gpt Disk Flags: Number Start End Size File system Name Flags 2 1049kB 15.7GB 15.7GB ext4 legacy_boot 1 15.7GB 31.5GB 15.7GB linux-swap(v1) 3 31.5GB 83.9GB 52.4GB reiserfs 4 83.9GB 83.9GB 10.5MB primary bios_grub 5 83.9GB 136GB 52.4GB reiserfs linux-leap421-r:~ # fdisk -l /dev/sda Disk /dev/sda: 1.8 TiB, 2000398934016 bytes, 3907029168 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: gpt Disk identifier: 4C81D390-4C41-... Device Start End Sectors Size Type /dev/sda1 30722048 61442047 30720000 14.7G Linux swap /dev/sda2 2048 30722047 30720000 14.7G Microsoft basic data /dev/sda3 61442048 163842047 102400000 48.8G Microsoft basic data /dev/sda4 163842048 163862527 20480 10M BIOS boot /dev/sda5 163862528 266262527 102400000 48.8G Microsoft basic data Partition table entries are not in disk order. linux-leap421-r:~ # -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
02.02.2016 18:36, Carlos E. R. пишет:
I used "Boot Info Script 0.72" (https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript) to obtain information on the boot process.
Could you send me privately RESULTS.txt and GPT table (first 32K of disk)?
Notice that there is no partition marked as boot, and that there is a "BIOS boot" partition, very small.
The MBR has this:
=> Syslinux GPTMBR (4.04-5.01) is installed in the MBR of /dev/sda.
...
Now, what I don't understand is, how is BIOS booting this disk. Obviously it has to read the MBR, and this boots sda2. How does it know it has to boot this partition?
If "it" means BIOS, it does not know anything. It loads the first sector and jumps to it. Now gptmbr code of Syslinux looks for GPT partition that has "legacy BIOS bootable" attribute and jumps to it. You can see flags using gdisk `i' command (display detailed partition information). Leacy BIOS bootable is bit 2. This changed relatively recently (6 years ago :); before gptmbr had boot partition GUID encoded.
Notice that there is no partition marked as boot, and that there is a "BIOS boot" partition, very small.
This is irrelevant in your case but may help if you decide to install GRUB2 in MBR. P.S. of course not every BIOS is equal and there are known cases when BIOS won't jump to boot code unless it sees legacy MBR active partition. And of course there are firmwares that go amok when they see PMBR with Active flag ...
On 2016-02-02 18:51, Andrei Borzenkov wrote:
02.02.2016 18:36, Carlos E. R. пишет:
I used "Boot Info Script 0.72" (https://github.com/arvidjaar/bootinfoscript/raw/master/bootinfoscript) to obtain information on the boot process.
Could you send me privately RESULTS.txt and GPT table (first 32K of disk)?
Sure, thanks :-)
Now, what I don't understand is, how is BIOS booting this disk. Obviously it has to read the MBR, and this boots sda2. How does it know it has to boot this partition?
If "it" means BIOS, it does not know anything. It loads the first sector and jumps to it.
Well, no, I meant the machine, the computer, the system, all :-) At the time I wrote the question I had little idea who did the choice. The thing is, fdisk does not display by default the flags of the GPT partition; thus I did not see the "legacy BIOS bootable", but "parted /dev/sda print" displays that info.
Notice that there is no partition marked as boot, and that there is a "BIOS boot" partition, very small.
This is irrelevant in your case but may help if you decide to install GRUB2 in MBR.
No, I don't think I will do that. I prefer to leave Syslinux there. Changing which partition has the "legacy BIOS bootable", I can change which system boots, very easy. Then if grub is in a partition, it does not need a corresponding "BIOS boot". Good. I was starting to have nightmares caused by installing a dozen systems, each with its own "BIOS boot" partition, LOL!
P.S. of course not every BIOS is equal and there are known cases when BIOS won't jump to boot code unless it sees legacy MBR active partition. And of course there are firmwares that go amok when they see PMBR with Active flag ...
Argh. This test has been done with vmware player, so it is whatever BIOS vmware emulates. One day, soon I hope, I will attempt to boot the host computer with that hard disk. I hope it responds well, because it is real BIOS, not UEFI (made more than six years ago). If it doesn't, I will have to reformat the disk with traditional partition table. -- Cheers / Saludos, Carlos E. R. (from 13.1 x86_64 "Bottle" at Telcontar)
02.02.2016 23:48, Carlos E. R. пишет:
The thing is, fdisk does not display by default the flags of the GPT partition; thus I did not see the "legacy BIOS bootable", but "parted /dev/sda print" displays that info.
For the record - I update bootinfoscript to display partition attributes.
participants (4)
-
Andrei Borzenkov -
Carlos E. R. -
Carlos E. R. -
Hans de Faber