Created attachment 564040 [details] mbr after performing a f17 alpha tc2 install Description of problem: When installing with custom partitioning and selecting to install the bootloader in the root partition, after reboot the firmware will not find anything in the mbr. A manual grub reinstall is requiered to restore boot capabilities. Anaconda was kind enough to not delete the disk's partitions. :-) Version-Release number of selected component (if applicable): F17aTC2, KDE-LiveCD Actual results: unbotable system for ANY os installed on the system Expected results: Additional info: Please make sure this does not get to the alpha...
Created attachment 564041 [details] /var/log/anaconda after install anaconda.ifcfg.log anaconda.log anaconda.program.log anaconda.storage.log
Please attach log files as individual, uncompressed attachments. Doing anything else prevents us from searching bugzilla in the future. Thanks.
Created attachment 564487 [details] anaconda log
Created attachment 564488 [details] anaconda program
Created attachment 564490 [details] anaconda storage
Created attachment 564491 [details] anaconda if
I downgraded systemd but no effect. Once in xorg failsafe, individual (ad hoc definition: program that seems to not to use some service or librarie) programs do work at normal speed. For example glxgears worked, but firefox exhibited the slowness.
Sorry, please ignore my previous post, it is for another bugreport.
grub2 doesn't support installing to a partition. You need to install it to the mbr. Anaconda shouldn't allow this to happen.
> grub2 doesn't support installing to a partition. > You need to install it to the mbr. > Anaconda shouldn't allow this to happen. That is correct, that is why i choose it, to see how f17 handled it. Maybe the option should not be anymore (as long as grub2 is the bootloader to be installed). Or maybe some method for that option to be grayed out. But in this case it was selectable so i tested it. But even if the option is not suposed to be used, it actually touched the mbr. the expected behaviour is to either install grub2 in the root partition or fail and display an error message. In no way should this option lead to any codepath that can write the mbr. (in fact, not even read it, because the caption of the option clearly says that any actions will be performed over the root partition).
Since you need custom partitioning in order to hit this bug, I don't think it's alpha blocker [1] material. Final, maybe. Alpha, no. -1 alpha blocker -1 alpha NTH [1] http://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
bcl: erm, grub2 does allow installing to a partition, they just don't recommend it. we actually specifically added code in anaconda to pass the --force parameter which is required when installing grub2 to a partition. From pyanaconda/bootloader.py: def install(self): # XXX will installing to multiple drives work as expected with GRUBv2? for (stage1dev, stage2dev) in self.install_targets: args = ["--no-floppy", self.grub_device_name(stage1dev)] if stage1dev == stage2dev: # This is hopefully a temporary hack. GRUB2 currently refuses # to install to a partition's boot block without --force. args.insert(0, '--force') I agree with Tim that this isn't Alpha blocking as it's outside the default install parameters that are all we support for Alpha. I'm +/-0 on NTH, since it would be nice for this to work, I guess. The initial description worries me somewhat as it implies anaconda somehow wipes whatever was previously in the MBR when this happens. If that's true, it may be a bigger issue. We should test and check that. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
> The initial description worries me somewhat as it implies > anaconda somehow wipes whatever was previously in the MBR > when this happens. If that's true, it may be a bigger > issue. We should test and check that. After reboot i was forced to boot sysrescuecd and install grub again. So, yes, it wiped the mbr instead of reporting that grub2 failed to install. Sadly, i am still being hit by "Bug 795050" on that system, so i don't know if i will be able to try reinstalling with rc4 (wich is currently being downloaded). I think this slould not reach release. I only installed one system, it is F15 + Other OS + F17a + OpenSuse. So it is still grub_legacy based. The mbr wiped contained generic code put by opensuse.
I just tested and cannot reproduce the result. I installed F16 with grub2 in the MBR (/dev/vda), then installed F17 and told it to install grub2 to the root partition of the F17 system (/dev/vda5). On reboot, it correctly loads F16's grub2 from the MBR - I see the F16 kernels and can boot to F16 just fine. So I'm definitely not reproducing the 'MBR wipe' scenario. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I also find that if I add a chainloader entry to F16's grub2.cfg, I can properly chainload the F17 install - showing that installation of grub2 to the root partition of the F17 install worked correctly. I can't see anything in your logs which shows either a failure installing grub2 to the root partition or that would result in the previous MBR being wiped. Are you totally sure anaconda caused this? I really can't get something similar to happen. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
-1 alpha blocker, -1 NTH, as it's outside the criteria for alpha, but am with adam on the "let's make sure it's not an MBR wipe" testing, or seeing if anyone can duplicate the problem here.
Seems I can reproduce this using RC4 (kde live x86_64). guess I'll try again using mbr (default) this time.
rex: please, if it's not too late, take a copy of all the anaconda logs from your reproducer before 'trying again'... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
reartes' MBR looks like it has NetBSD's bootloader in it, based on the strings: http://wiki.netbsd.org/how_netbsd_boots_on_x86/ -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'm wondering if the cause of this is the change we implemented to mark the protective MBR as active. I do see: 21:06:13,516 DEBUG storage: Set pmbr_boot on parted.Disk instance -- type: gpt primaryPartitionCount: 7 lastPartitionNumber: 7 maxPrimaryPartitionCount: 128 partitions: [<parted.partition.Partition object at 0x27c1050>, <parted.partition.Partition object at 0x27c13d0>, <parted.partition.Partition object at 0x27c1150>, <parted.partition.Partition object at 0x27c1590>, <parted.partition.Partition object at 0x27c1710>, <parted.partition.Partition object at 0x27c1890>, <parted.partition.Partition object at 0x27c1a10>] device: <parted.device.Device object at 0x27b5450> PedDisk: <_ped.Disk object at 0x27c3e18> in reartes' storage.log. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
For the record: rex's case seems to have been user error, he chose to install the bootloader to the first partition on a system which had no pre-existing bootloader in the MBR, and that config is simply non-bootable by definition, anaconda did nothing wrong there. So we can discard rex's case, we have reartes' case and also jreznik's case - https://bugzilla.redhat.com/show_bug.cgi?id=796261 - to look into. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
So I just did an openSUSE 12.1 install, told it to install its bootloader to the MBR, and it installs a regular grub-legacy, definitely does not look like reartes' attachment - https://bugzilla.redhat.com/attachment.cgi?id=564040 - at all. Of note is that openSUSE doesn't appear to default to installing a bootloader to the MBR, at least if your disk already contains one, it defaults to installing bootloader to its root / boot partition. So I rather think Reartes didn't have grub in the MBR at all, and what was there didn't come from openSUSE. but it's hard to be sure. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
now I tested installing F17 Alpha RC4 from 'DVD' (this is all in a KVM) alongside the openSUSE install, telling it to put the bootloader on root partition not MBR: install succeeded with no errors, system reboots to openSUSE as expected.
My original MBR prior to F17 A rc2 install contained "generic code", that was put there by opensuse because i installed opensuse's grub on that root partition. I do not use nor have installed recently any BSD flavour. I only tested/installed F17 KDE LiveCDs I tested again with the rc2 (the only one i can boot due another bug) and i could not reproduce the bug. Note: the MBR contains grub1 installed from systemrescuecd. So it is not exactly the same test case. I will later try to reproduce it reinstalling opensuse in the same way and re-doing the rc2 install, probably in the weekend, just to be sure. The most important part is that is not as widespread as i initially thought and that is a good thing. regarding comment #20: * the boot disk is an ssd with a MBR partition scheme, there are four more data disks, they are all GPT partitioned.
I'm not quite sure what SUSE means by 'generic code'. You have to have *some* kind of a bootloader in the MBR in order to, well, boot. What you attached certainly *looks* like the bootloader netbsd uses, judging from the strings. It certainly isn't grub. My vote on this is -1 blocker as we have no other reports of it, and I couldn't reproduce either with an install alongside F16 or an install alongside openSUSE. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
We have -3 blocker votes and this seems to be related to some non-standard setups that are outside of the alpha release criteria [1] if there is indeed a bug here. Rejecting as Alpha Blocker. [1] http://fedoraproject.org/wiki/Fedora_17_Alpha_Release_Criteria
-- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Is this still a problem with F17 final?
I am not able to test for this bug at the moment, since my setup changed completely and cannot be changed. The best course of action might be to close the bug-report (since F17 was released) and hope for the best.