Hide Forgot
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:
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.