Red Hat Bugzilla – Bug 504570
Graphical installer installs boot record in both MBR and boot partition
Last modified: 2013-01-13 09:15:42 EST
Description of problem:
When we choose to install boot record in boot partition, the boot record gets installed in both places: MBR and in boot partition
Version-Release number of selected component (if applicable):
F11 PR, RC1, RC2 , RC3, RC4
Every attempt to install it on boot partition
Steps to Reproduce:
2.Default partition options with shrinking Vista partition to make room for F11
3.Choose install GRUB to boot partition
Boot record gets installed in both places. Third party MBR whipped.
Boot record installed in boot partition. Third party MBR should remain instact.
Hardware used HP Pavilion dv5-1150ew notebook. Fresh new.
Vista partitions left to make machine dual-boot with Vista's MBR chainloading the GRUB ( due to problems with booting GRUB on this hardware - https://bugzilla.redhat.com/show_bug.cgi?id=503180 ). Vistas MBR gets whipped every time. Tested with more than 5 times during installation of above mentioned F11 versions.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.
More information and reason for this action is here:
Same behaviour experienced when installing on a Dell Precision 380.
When selecting to install GRUB on the first sector of the boot partition, the contract implied by the installer is that GRUB will *not* be installed in the MBR. This has always been the behaviour in the past. This contract is broken by the Fedora-11-x86_64-DVD.iso installer, with potentially damaging and unpredictable results.
The same bahaviour with the x86 version. Very sad and annoying. :-(
I can't reproduce the issue. Isn't your boot partition md raid 1 device? We know about this case - anaconda is installing grub in MBRs of drives holding members of the array. Can you please attach
files so that we can see better what's going on?
No(In reply to comment #4)
> I can't reproduce the issue. Isn't your boot partition md raid 1 device? We
> know about this case - anaconda is installing grub in MBRs of drives holding
> members of the array.
No, none of the partitions on the disk is configured raid device. This is notebook internal hdd with untoched Windows recovery partition, shrinked Windows system partition ( to make room for Fedora ) and default install linux partitition layout.
At the BIOS level hdd controller is working as general SATA device.
> Can you please attach
> files so that we can see better what's going on?
Machine is not avaible to me at the moment. I will post logs in two weeks.
Created attachment 358390 [details]
Anaconda install logs
The requested logs for my case. Same problem, but installed with kickstart and option "bootloader --location=partition", on disk with one existing Ntfs partition and no Raid. Fedora 11 x86, packages include updates until Aug 15th.
Created attachment 358442 [details]
Anaconda logs fixed
Sorry, accidentally got the files from wrong machine before. These are the right ones. Anaconda overwrote Windows MBR even if kickstart specifies "partition".
auth --useshadow --enablemd5
# System bootloader configuration
# Partition clearing information
# Use graphical install
# Firewall configuration
# Run the Setup Agent on first boot
# System keyboard
# System language
# Use NFS installation media
nfs --server=10.58.130.3 --dir=/data2/kickfedora11
# Network information
network --bootproto=dhcp --device=eth0 --onboot=on
# Reboot after installation
rootpw --iscrypted CENSORED
# SELinux configuration
# System timezone
# Install OS instead of upgrade
# X Window System configuration information
xconfig --defaultdesktop=GNOME --depth=24 --resolution=1024x768 --startxonboot
part / --fstype ext3 --size=10000 --grow --maxsize=15000
part swap --size=1024 --grow --maxsize=1024
Created attachment 361340 [details]
zipped logs requested from laptop referenced in bug opening message
At last I got the laptop referenced in bug opening message. So I'm sending requested logs anaconda.log, anaconda.syslog, storage.log and program.log. This logs are from installation described in bug opening message.
Hope this help
*** Bug 538271 has been marked as a duplicate of this bug. ***
In my case (Bug 538271), anaconda deactivated NTLDR partition.
As a result none of the bootloaders could be reached, because I use NTLDR to call GRUB.
Analysing the attached logs (esp program.log), it seems that grub only gets installed into the bootsector of the partition, as requested.
What probably leads you to think otherwise, is the new F-11 and F-12 behavior that we change the active / bootable flag to the partition holding grub.
Further evaluation of this issue has lead to the conclusion that
the removal of the active flag from an existing partition indeed is unwanted
So I've just changed this, and for F-13 we will no longer do that, see:
*** This bug has been marked as a duplicate of bug 533658 ***