Bug 124038
| Summary: | Upgrades From Fedora Core 1 to Fedora Core 2 In Dual Boot Situation Renders Second Drive Unbootable | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Bob Cochran <cochranb> |
| Component: | anaconda | Assignee: | Jeremy Katz <katzj> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 2 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-05-24 02:35:35 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: | |||
I think all is well now. I forgot to change the /kernel line in my grub stanza for /dev/hdb from /kernel vmlinuz-2.4.22-1.2188.nptl ro root=LABEL=/ acpi=on nogui to /kernel vmlinuz-2.4.22-1.2188.nptl ro root=LABEL=/1 acpi=on nogui when I did this, hdb booted into Fedora Core 1 very nicely and all is well. I do not now think I had data loss, this seems a case of a missing partition label in the grub stanza. But I still think grub shouldn't trash my existing grub.conf stanzas if there is a dual-boot situation. Why not just add an appropriate stanza for the new kernel instead? To me specifying 'upgrade' on the bootloader means upgrading the executable binaries to a new version, not overlaying the config file(s). I would have been okay if only a new grub.conf stanza was added. And there seems no reason from a new options standpoint to completely wipe out an existing grub.conf. So this bug can be downgraded from a serious bug to something lesser. The kernel got upgraded and thus the binary was no longer there and thus the reference to it got removed from the grub.conf. This is the expected behavior. If your grub line for the second drive had been correct to begin with, then it wouldn't have gotten removed. Jeremy -- I disagree with this statement: "If your grub line for the second drive had been correct to begin with, then it wouldn't have gotten removed." My grub line for the second drive had existed since I installed it, and was indeed correct to begin with. I've been dual booting two different Fedora Core 1 implementations for months before upgrading to Fedora Core 2. It originally did reference 'root-LABEL=/1'. When I upgraded Fedora Core 2, all the grub lines for the second drive were trashed. That forced me to manually type one stanza for that drive, which didn't reference the second drive correctly (no LABEL=/1). I corrected that after realizing my error. Grub was wrong to delete grub.conf stanzas for my second drive. It does indeed do that and I see no reason for the behavior. You might be able to justify deleting the stanzas for the drive being upgraded to the new Fedora release, but never for a second or nth drive that was not updated and might have a different OS on it. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Description of problem: This is an upgrade of a system containing two installations of Fedora Core 1, each on its own hard drive. The machine is a Dell Dimension XPS T550, 256 Mb RAM. /dev/hda has Fedora Core 1. /dev/hdb has Fedora Core 1. The goal is to upgrade /dev/hda to Fedora Core 2. When the upgrade of hda completed, I first booted into Fedora Core 2, which had some small problems but went okay. The Grub stanza for my Fedora Core 1 installation was entirely missing. In fact every grub stanza for the system on /dev/hdb (Grub's 'hd1') except one was missing, and so I added the proper entry again and rebooted. I selected my Fedora Core 1 installation, and could not at all boot into it. What seemed to happen is that it complained about missing elements in /lib/modules/2.4.22-1.2188.nptl. Kudzu came up and stated: the following network card has been removed from your system. Lite-On| LNE100TX I selected the "do nothing" action. Kudzu then stated that an AT Translated Set 2 keyboard had been removed from my system. I selected the "do nothing" action again. When the boot into Fedora Core 1 completes, the X server refuses to start. I am presented with a console prompt: Fedora Core release 2 (Tettnang) Kernel 2.4.22-1.2188.nptl on an i686 bobc login: and I cannot login to the user account I have set up on that particular Fedora Core 1 system. E.g. somehow the attempt to boot Fedora Core 1 failed, so the system booted the Core 1 kernel and referenced Fedora Core 2 executables on /dev/hda. I have not been able to fix this yet -- have not had the time to research it well. Version-Release number of selected component (if applicable): How reproducible: Didn't try Steps to Reproduce: 1. Fedora Core 1 is installed on two separate hard drives on the same machine. One system is /dev/hda and the other is /dev/hdb. 2. Launch Fedore Core 2 installer from CD#1 using the foolowing string: linux askmethod vnc vncconnect=thatother.host.onyournetwork 3. follow the prompts, pointing the installer at the NFS directory to use for the ISOs and getting connected to the vnc client. 4. Select upgrade 5. When asked what to do about the grub bootloader, select upgrade the bootloader. 6. The upgrade completes with extreme slowness, almost 3 hours in my case. 7. Following the upgrade, attempt to boot into the Fedora Core 2 system. This will succeed with some problems. 8. After booting into the Fedora Core 2 system, reboot and try to boot into the Fedora Core 1 system on /deb/hdb. Actual Results: You can no longer boot into Fedora Core 1 on /dev/hdb in this scenario. Expected Results: I should have been able to boot Fedora Core 2 on /dev/hda and the existing, untouched Fedora Core 1 system on /dev/hdb. Additional info: I wonder if the upgrade process is trashing stuff on /dev/hdb's /boot partition and in /lib/modules? I haven't investigated enough to be sure.