Bug 124038 - Upgrades From Fedora Core 1 to Fedora Core 2 In Dual Boot Situation Renders Second Drive Unbootable
Summary: Upgrades From Fedora Core 1 to Fedora Core 2 In Dual Boot Situation Renders S...
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda   
(Show other bugs)
Version: 2
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-05-23 03:51 UTC by Bob Cochran
Modified: 2007-11-30 22:10 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-05-24 02:35:35 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Bob Cochran 2004-05-23 03:51:15 UTC
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|

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
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.

Comment 1 Bob Cochran 2004-05-23 05:36:41 UTC
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


/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. 

Comment 2 Jeremy Katz 2004-05-24 02:35:35 UTC
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.

Comment 3 Bob Cochran 2004-05-24 03:28:15 UTC
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. 

Note You need to log in before you can comment on or make changes to this bug.