Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Graphical installer installs boot record in both MBR and boot partition|
|Product:||[Fedora] Fedora||Reporter:||Marcin <marcin.wolyniak>|
|Component:||anaconda||Assignee:||Anaconda Maintenance Team <anaconda-maint-list>|
|Status:||CLOSED DUPLICATE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||11||CC:||anaconda-maint-list, apodtele, hdegoede, maurizio.antillon, peterwil, rmaximo, rvykydal, vanmeeuwen+fedora|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2009-11-30 05:19:17 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
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 /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?
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. Regards Marcin
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 graphical # 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=10.58.130.3 --dir=/data2/kickfedora11 # Network information network --bootproto=dhcp --device=eth0 --onboot=on # Reboot after installation reboot #Root password rootpw --iscrypted CENSORED # SELinux configuration selinux --disabled # System timezone timezone Europe/Rome # Install OS instead of upgrade install # 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 Marcin
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 behavior. So I've just changed this, and for F-13 we will no longer do that, see: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=0c0559f6f187815521364cb6d5118ad9faf24cc9 *** This bug has been marked as a duplicate of bug 533658 ***