Bug 505836
Summary: | F11 unbootable, incorrect grub install | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andrei Gaponenko <gandr> |
Component: | grub | Assignee: | Peter Jones <pjones> |
Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | low | ||
Version: | 11 | CC: | garrett.mitchener, lkundrak, mal, pjones, rmaximo, vanmeeuwen+fedora |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-06-28 12:59:19 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andrei Gaponenko
2009-06-14 08:12:26 UTC
Can you list the exact steps you took on the bootloader screen, and tell us exactly what your partition layout looks like, so we can attempt to reproduce this? Hi, Here is the information you requested: There is only one hard drive on this laptop, no raid or LVM is used. The partition layout is [root@localhost ~]# sfdisk -d /dev/sda # partition table of /dev/sda unit: sectors /dev/sda1 : start= 63, size= 41254857, Id= 7, bootable /dev/sda2 : start= 41254920, size= 401625, Id=83 /dev/sda3 : start= 41656545, size= 81915435, Id= 5 /dev/sda4 : start=123571980, size=189004725, Id=83 /dev/sda5 : start= 41656608, size= 30716217, Id=83 /dev/sda6 : start= 72372888, size= 30716217, Id=83 /dev/sda7 : start=103089168, size= 10233342, Id=82 /dev/sda8 : start=113322573, size= 10249407, Id=82 All the partitions existed before the F11 installation and were not resized. sda2 is /boot (and was entered as such in the custom partition editor screen during the installation), sda5 was reformatted as ext4 to install F11. I did not write down my exact steps at the bootloader configuration screen, but the whole process seemed straightforward and unambiguous. I did not have a chance to edit or even view grub configuration. The GUI interface initially had an entry for Fedora 11, and a button to "Add" other systems, which IIRC only allowed to specify partition and corresponding boot menu label. More info: I did some tests tonight and I think I found a way to reproduce the problem. Compare these two situations: 1) Plug a USB stick into a laptop port. Power the system up and boot from the built-in hard drive. On the grub menu screen press "c" to get the grub shell. Now grub> geometry (hd0) drive 0x80 ...(printout of built in HD follows) grub> geometry (hd1) drive 0x81 ...(printout of the USB stick pars) 2) Plug a USB stick with systemrescuecd-x86-1.1.7.iso live image into a laptop port. Power the system up and boot from the USB stick. Among the boot options (I think on the "F2" screen) are "boot from the first hard disk" and "boot from the second hard disk". Selecting "boot from the first" boots the same systemrescuecd again. Selecting "boot from the second hard disk" brings up the GRUB menu from the hard drive installation. Pressing "c" we get a grub shell again, but this time we can observe grub> geometry (hd0) drive 0x80 ...(printout of the USB stick pars) grub> geometry (hd1) drive 0x81 ...(printout of built in HD follows) It seems that "hd0" is the initial boot device. Because I installed F11 from a USB stick, like the case (2) above, anaconda saw the "real" hard drive as hd1. While this problem is tricky to solve, it ought to be addressed. An unbootable system is a *bad* screw up for many users. My suggestion is to compare, at the time of installation, the drive number from which anaconda is run with the drive number where GRUB is going to be installed. If the installer's media drive number is smaller than the GRUB target hard drive number, this is clearly suspicious. Once the installation media is removed, the number of the remaining hard drive is likely to change upon reboot. Are there any real life use cases when this check would give a false positive? I don't see any at the moment. An it would catch the case that I had. What to do once the "possible drive renumbering" situation is detected is the next question. At the minimum the user should be warned, and may be given an option of editing the actual grub configuration file. In a text editor, not via the simplistic GUI. One would also want to double check onto what drive GRUB is going to be installed. In simple cases, like most laptop installs, it would be sufficient for a user to assert to the installer that the system has only one hard drive. Then the installer can just write out and use the hardcoded device.map "(hd0) /dev/sda". Regards, Andrei Bug #450143 might be related. I ran into this problem during prior upgrades with the upgrade image on a USB hard drive or CD drive. It looks like GRUB sometimes gets installed with its device numbers confused by the presence of the removable hard drive during installation. Or not. I just upgraded from F10 to F11 from a DVD on a desktop machine with no external drive plugged in, and somehow grub didn't get installed properly. It was easy enough to do it manually because I've been through this before, but seriously, this needs to get fixed. grub.conf was updated fine. There are no errors in /root/upgrade.log or /root/upgrade.log.syslog. I just upgraded my other workstation from F10 to F11 from a DVD. My general setup is: sda (hd0) : first hard drive, grub installed on MBR sdb1 (hd1,0) : second hard drive, 1st partition, /boot where grub's later stages and conf file live built-in card reader with slots for SD, CF, etc. USB hard drive with a couple of partitions The rest of sdb is my linux installation. On one of the logging consoles, right at the end of the upgrade, I caught an error message. It showed that grub was run with the command install --stage2=/boot/grub/stage2 /grub/stage1 d (hd0) /grub/stage2 p (hd1,0)/grub/grub.conf and gave an error about an invalid device. I went to one of the other consoles that has a command line. I ran grub and typed the same command and got the same error. I then tried the commands root (hd1,0) setup (hd0) and it told me it was running install /grub/stage1 d (hd0) (hd0)1+28 p (hd1,0)/grub/stage2 /grub/grub.conf And this worked. My system booted. I don't know enough about grub to know what makes the difference. I'm confused because according to grub's built-in help, the install syntax should be p /grub/grub.conf and the stage2 file ought to be in some other order, probably after the (hd0)1+28. Similar problem here, reproduced twice. 1. Fresh F11 AMDx64 install,multiple (EIDE & SATA) disks present. During installation chose use fedora and fedora-updates repositories. the resulting installation is unbootable. The way to fix - boot from rescue DVD, run grub and execute find /grub/stage1 root (hd1,0) setup (hd0) 2. A laptop with Intel x86 F11 install, single disk. Windows is booted via grub "Other" operating system menu option. In September I turned on the computer and run yum -y update command. The update (hundreds packages) finished successfully. Then the laptop became unbootable. To make it booting again - boot from installation DVD, choose "rescue" run grub and execute grub command listen in item 1. By the way, when using just DVD install (without network repositories with updates during install) the resulting installation boots OK. No problem then. This is just something from updates, what breaks booting. I don't know if this is relevant: I used a DVD to upgrade my workstation from F11 to F12. I happened to have a USB hard drive plugged in (it has a linux partition by the way), and when the install program got to the part about the bootloader, it disabled the option to upgrade the bootloader configuration. It seems that the USB drive was being mapped to /dev/sda, and my two internal hard drives were mapped to /dev/sdb and /dev/sdc and the install program was very confused. Normally, the two internal hard drives are mapped to /dev/sda and /dev/sdb, it boots initially from /dev/sda and the /boot partition is on /dev/sdb. I canceled the upgrade, unplugged the USB hard drive, rebooted, and tried again. This time, the internal hard drives were sda and sdb like normal, and the installer enabled the option to upgrade the bootloader configuration. I used that option and proceeded with the upgrade. The system booted correctly after the upgrade. So I suspect there's some problem with drive identification confusing the part of the upgrade process dealing with grub. I know grub has some uncertainty about how the BIOS identifies hard drives vs. how the linux kernel does it, so maybe that's part of the problem? This was on a Dell Precision 690 with their A05 BIOS. This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. 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 '11'. 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 11'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 11 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 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. |