Bug 78854 - Kernel passes control to another kernel
Kernel passes control to another kernel
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: installer (Show other bugs)
8.0
i586 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-12-02 00:34 EST by udippel
Modified: 2007-04-18 12:48 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-10-04 23:01:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description udippel 2002-12-02 00:34:00 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
Funny and weird:
When booting to Psyche (2.4.18-18.8), it boots fine.
I had to extract data from a harddisk that also happened to contain a 7.2
updated to kernel version 2.4.18-17. So I added that hd as /dev/hdc.
When booting Psyche, the kernel passes the control somehow to hdc and I end up
with an unusable 7.2 and unsuccesful efforts to finish loading that 2.4.18-17
kernel from hdc. No way to boot to 8.0 or 2.4.18-18 !!!
I tried jumpering that second hd to /dev/hdd; but same result. As soon as I
remove that second hd, the systems boots nicely to /dev/hda3 without any
problem. Shutdown, add that slave hd and once again: boot the correct kernel,
which - after finding the other system and kernel, passes on to that secondary
hd to finish booting. 
I did try a grub boot floppy, I did try a (mkbootdisk) floppy; no avail:
As soon as this kernel finds the other hd, it passes control to that system.
Finally, I had to dig out another 7.1/7.2 harddisk with 2.4.10-kernel. That one
did do the job: boot 2.4.10 and finish booting 2.4.10, starting the system,
etc.; so that I could mount those partitions on hdc and extract the data.

splashimage=(hd0,2)/boot/grub/splash.xpm.gz
title Red Hat Linux (2.4.18-18.8.0)
        root (hd0,2)
        kernel /boot/vmlinuz-2.4.18-18.8.0 ro root=LABEL=/
        initrd /boot/initrd-2.4.18-18.8.0.img

is the grub config. I consider this a bug. As I said, booting from grub
boot-floppy or RH-bootdisk make no change.
The system must finish booting to what the admin asks to boot and not be
entitled to finish booting something else the kernel happens to find during boot.

Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. add harddisk containing another system
2. boot to installed system
3.
	

Actual Results:  Kernel passes boot to other system

Expected Results:  Boot to installed system as directed

Additional info:
Comment 1 Alan Cox 2003-06-05 09:05:44 EDT
This is a labelling thing. The default file system to mount is the one labelled
"ROOT". You had two and so it guessed wrongly when it was trying to track which
one to use. Really the installer ought to generate ROOT_[something] to avoid this
Comment 2 udippel 2003-06-05 09:51:12 EDT
Fine. This is what I thought. Should play in the lottery: It has *always* been
the other harddisk - no kidding ! - If it had been 50 / 50, I'd consider it fun.
But it is 0 / 100. 
Had been a very bad idea overall to replace /dev/partition with labels !!

A suggestion: make kernel use the one harddisk from which it /boot-ed as
default; not the other one.

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