Red Hat Bugzilla – Bug 546368
Anaconda grub upgrade changes partition table
Last modified: 2010-12-03 20:50:50 EST
Description of problem:
When upgrading from F11 to F12, when choosing to upgrade grub on the detected partition (the default), anaconda does not only upgrade grub, but changes the partition table, setting the boot flag on that partition too, and clearing it from other partitions.
This is incorrect behaviour. The partition on which grub resides (and is upgraded) does not have to be THE boot partition. For an upgrade with no partition changes, Anaconda can safely assume that the partition table is correct.
This will presumably affect everyone who has multiple operating systems installed, and chain-loading grub. Most notably, it breaks any dual boot with Windows Vista/7 where the boot is through GPT/EFI, and the Windows boot loader chain loads grub. In that case, changing the boot flag for the partition table causes a "No operating system" error that's going to be exceedingly hard for end users to identify the correct cause and fix for (boot a live CD, and use parted, fdisk or cfdisk to change back the boot flag to the correct partition).
*** This bug has been marked as a duplicate of bug 533658 ***
While certainly related, and the fix for 533658 will also fix this bug for when there is an MSDOS partition table, it doesn't address the exact problem seen here.
The result of the fix to 533658 for a non-MSDOS partition table (like my GPT) won't be fixed by this -- in my particular case, it will set the boot flag for hda5, which it shouldn't. The partition table was correct BEFORE the upgrade.
When doing an *upgrade* without the user modifying the partition table, Anaconda shouldn't modify the partition table at all. Whether it's an MSDOS partition table or not.
For new installs, sure. But for upgrades, no.
I certainly that the patch for bug 533658 does exactly what you propose:
- If 'upgrade', don't touch partition flags
- If 'advanced installation of boot loader', don't touch partition flags
- Else 'overwrite MBR by default', it is probably ok to mess with flags because
windows is unreachable anyway
(In reply to comment #2)
> While certainly related, and the fix for 533658 will also fix this bug for when
> there is an MSDOS partition table, it doesn't address the exact problem seen
> The result of the fix to 533658 for a non-MSDOS partition table (like my GPT)
> won't be fixed by this -- in my particular case, it will set the boot flag for
> hda5, which it shouldn't. The partition table was correct BEFORE the upgrade.
> When doing an *upgrade* without the user modifying the partition table,
> Anaconda shouldn't modify the partition table at all. Whether it's an MSDOS
> partition table or not.
> For new installs, sure. But for upgrades, no.
Ah, GPT, ok that is a new one.
So re-reading your original description you write:
"setting the boot flag on that partition too, and clearing it
from other partitions."
That does not happen with GPT tables. Or do you mean that your system
has a disk with a GPT table, and another disk with an msdos table, and Linux
/boot is on that other disk?
Can you please give a detailed description of your exact partition layout (including disklabel (msdos/gpt) type per disk), and how it looked like before the upgrade and how it looked like after the upgrade ?
And also describe the entire boot chain for both windows and Linux, so what does the BIOS initially start, what does that start, etc.
Thanks for looking into this.
No, a single disk only. The system uses InsydeH2O EFI, and uses what I believe is called a hybrid GPT configuration.
Seen from Linux, the partitions are
/dev/sda1 - fdisk can't recognize this partition correctly, and think it extends past the end of the drive
/dev/sda2 - Windows partition
/dev/sda3 - /boot
/dev/sda4 - swap
/dev/sda5 - root
Seen from Vista, the first partition is a hidden and bootable FAT32 partition, which contains the EFI tools and a PE recovery.
When booting, the EFI boot manager loads the Windows boot loader, and if Linux is selected, the Windows boot loader then chain loads grub. This was done to avoid Grub overwriting the EFI boot loader. (Yes, it would be more elegant to add grub.efi directly, but at the point when Linux was first installed, that wasn't available.)
After the Anaconda install, and booting from a DVD to figure out why I got "No operating system", cfdisk said that both sda2 and sda5 were marked as boot. Clearing the one for sda5 cleared both, and resetting it on sda1 made the system operational again.
AFAIK hybrid partition tables are not supported out of the box by anaconda. Did you run gptsync to fixup the msdos table at the beginning of the disk after
running the upgrade ?
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '12'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 12's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 12 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 12 changed to end-of-life (EOL) status on 2010-12-02. Fedora 12 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.