Bug 504570

Summary: Graphical installer installs boot record in both MBR and boot partition
Product: [Fedora] Fedora Reporter: Marcin <marcin.wolyniak>
Component: anacondaAssignee: Anaconda Maintenance Team <anaconda-maint-list>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: anaconda-maint-list, apodtele, hdegoede, maurizio.antillon, peterwil, rmaximo, rvykydal, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-11-30 05:19:17 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Anaconda install logs
Anaconda logs fixed
zipped logs requested from laptop referenced in bug opening message none

Description Marcin 2009-06-08 05:35:59 EDT
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

How reproducible:
Every attempt to install it on boot partition

Steps to Reproduce:
1.Start Installation
2.Default partition options with shrinking Vista partition to make room for F11
3.Choose install GRUB to boot partition
Actual results:
Boot record gets installed in both places. Third party MBR whipped.

Expected results:
Boot record installed in boot partition. Third party MBR should remain instact.

Additional info:
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.
Comment 1 Bug Zapper 2009-06-09 13:13:05 EDT
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:
Comment 2 Peter Williams 2009-06-19 18:48:15 EDT
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.
Comment 3 Marcin 2009-07-07 04:32:26 EDT
The same bahaviour with the x86 version. Very sad and annoying. :-(
Comment 4 Radek Vykydal 2009-07-30 09:28:46 EDT
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?
Comment 5 Marcin 2009-07-31 04:29:39 EDT
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
> /var/logs/program.log
> /var/logs/storage.log
> /var/logs/anaconda.log
> /var/logs/anaconda.syslog
> 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.

Comment 6 Sugo 2009-08-23 19:30:57 EDT
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.
Comment 7 Sugo 2009-08-24 07:32:07 EDT
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".

Kickstart excerpt:

auth  --useshadow  --enablemd5 
# System bootloader configuration
bootloader --location=partition
# Partition clearing information
clearpart --linux
# Use graphical install
# Firewall configuration
firewall --disabled
# Run the Setup Agent on first boot
firstboot --disable
# System keyboard
keyboard de-latin1-nodeadkeys
# System language
lang de_DE
# Use NFS installation media
nfs --server= --dir=/data2/kickfedora11
# Network information
network --bootproto=dhcp --device=eth0 --onboot=on
# Reboot after installation

#Root password
rootpw --iscrypted CENSORED
# SELinux configuration
selinux --disabled
# System timezone
timezone  Europe/Rome
# 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
Comment 8 Marcin 2009-09-16 13:56:40 EDT
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
Comment 9 Chris Lumens 2009-11-18 09:24:07 EST
*** Bug 538271 has been marked as a duplicate of this bug. ***
Comment 10 Alexei Podtelezhnikov 2009-11-22 08:12:41 EST
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.
Comment 11 Hans de Goede 2009-11-30 05:19:17 EST
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 ***