F17 installation over F16 fails with MBR boot drive

[Don3]

Hello -

I'm trying to install Fedora 17 over a working F16 installation -- ie, a fresh install, not an upgrade -- using the "netinst" minimal boot ISO. The drive containing /boot and / is a Plextor SSD formatted as MS-DOS/MBR. I wanted to preserve the F16 layout, so in the installer's custom partitioning screen I didn't make any size changes -- I only selected existing partitions on which to install /boot, /, /var, /home, etc. When attempting to leave this screen, I got an error:

Partitioning Errors
The partitioning scheme you requested caused the following critical errors.

you have not created a bootloader stage1 target device
sda1 must have one of the following disklabel types: gpt

This seems an odd message to me because AFAIK disklabels belong to entire disks, not to individual partitions. But my real question is why the installer seems to be treating this as a GPT disk when it's formatted as MBR. Adding "nogpt" to the installer boot command had no effect.

As a bit of history, the main board is an Intel DP35DP with a broken BIOS which, among other things, can no longer be switched out of UEFI boot mode. However, after a fair bit of pain trying to install F16 with this drive formatted as GPT a few months ago, I ended up wiping the drive and re-formatting it as MBR. It turned out that, although the broken BIOS fails to boot from GPT discs in UEFI mode, it has no problem booting from MBR disks, and (as far as I remember) the F16 installer did not exhibit the above-mentioned error.

FWIW the SSD is partitioned as follows:

# fdisk -lu /dev/sda
Disk /dev/sda: 64.0 GB, 64023257088 bytes
255 heads, 63 sectors/track, 7783 cylinders, total 125045424 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
Disk identifier: 0x000934b0

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *         256      786431      393088   83  Linux
/dev/sda2          786432    63700991    31457280   83  Linux
/dev/sda3        63700992   125042687    30670848   83  Linux
/dev/sda4       125042688   125045423        1368   83  Linux

There are also 2 1-TB HDDs in the system in a (MD) RAID-1 set, and the RAID device is an LVM physical volume, but I don't think that's relevant to the problem here.

Thanks for any ideas...
- Don

[george_toolan]

Fedora 17 is somewhat stupid. Apparently it insists on an UEFI install with a GPT if you can't boot your computer in BIOS compatibility mode.

[DBelton]

It looks to me like it still has the backup GPT at the end of the drive.

have you tried using gdisk and zap the GPT info?

[Don3]

Thanks very much for the replies.

Apparently this BIOS is somewhat un-typical, even before it started having more serious problems (settings not sticking) a few months ago. Rather than being primarily UEFI with a BIOS compatibility option, it's kind of a transitional thing that's rather more like a regular old BIOS with an option to enable UEFI boot. From my previous experience trying to install F16 using a GPT-formatted drive, we discovered that with UEFI boot enabled, it can't really boot from GPT discs (which seems particularly ironic, being an Intel BIOS and all), and that once I had enabled the UEFI boot option, I couldn't to disable it. At that point I had pretty much accepted that I'd be buying a new main-board, but it was saved by the discovery that even when the UEFI boot option is enabled, it's still capable of booting from MBR discs.

Good thought about the backup GPT. When I switched from GPT to MBR during the F16 installation, I had wiped the beginning and the end of the drive using dd, so I was pretty sure I didn't have that issue. I was just about to double-check that, but then...

...this morning a small detail came back to me that I had forgotten from the F16 experience, which I'll re-cap here in case it helps anyone in a similar situation:

The Fedora install CD (or DVD) starts up in two different ways, seemingly dependent on when in the boot process the BIOS discovers it. If I load the CD before the Intel splash screen appears, or possibly when it's first up, I get a menu with a night sky background and only one entry : Fedora 16. But if I wait to insert the CD until just after the splash screen clears, I first get an "interesting" menu from the BIOS (see footnote [4] here; selecting '1', I get a text-mode boot menu that has more options, including "troubleshooting".

It turns out that if the CD is discovered early in the boot process, the BIOS puts itself into EFI mode and the installer expects the drive to have a GPT layout (even if it it's formatted as MBR), whereas if the CD is discovered later, the BIOS does not enable EFI features and the installer is happy with the MBR-type layout. This seems like an installer bug to me, but at least I have a work-around : just wait until the BIOS splash screen clears to load the CD.

With that, I was able to finish the installation successfully.

Thanks again!

[DBelton]

Very interesting. Great information to know about!

It does seem a little odd that it works that way, so possibly it is an anaconda bug (which hopefully will be taken care of with the rewrite to anaconda that is slated to hit F18)

Edit:
Think about this a minute, it probably isn't a anaconda bug, since it appears that it's the firmware actually switching to uEFI mode and not anaconda. By the time it gets to anaconda, the system is in uEFI mode, so anaconda expects things to be correct for a uEFI install.

There may be some checks they could put into anaconda, but overall, I'm not sure if this could actually be fixed at the anaconda level.

[Don3]

Think about this a minute, it probably isn't a anaconda bug, since it appears that it's the firmware actually switching to uEFI mode and not anaconda. By the time it gets to anaconda, the system is in uEFI mode, so anaconda expects things to be correct for a uEFI install.

Good point, and since I haven't tried to dig into the anaconda code, I don't have an informed opinion. But I wanted to raise the question because I think I'm seeing two more-or-less independent variables here: the BIOS mode (legacy BIOS or [U]EFI), and the disklabel type on the boot disc (GPT, MBR, Sun, etc). The BIOS on my board is happy to boot MBR-formatted discs when it's in UEFI mode, which is maybe not a "normal" use case. I'm guessing that Anaconda might be basing its decision about whether to require a BIOS boot partition on the current (install-time) BIOS mode, rather than the disklabel type, which seems wrong. But as I say I'm just guessing...