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.
title Red Hat Linux (2.4.18-18.8.0)
kernel /boot/vmlinuz-2.4.18-18.8.0 ro root=LABEL=/
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):
Steps to Reproduce:
1. add harddisk containing another system
2. boot to installed system
Actual Results: Kernel passes boot to other system
Expected Results: Boot to installed system as directed
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
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.