I ran into a bug that I wanted to see if anyone else has seen or might have information about.
I had an existing disk with windows(XP) on it. I bought a new, larger disk that I wanted to install linux on, and copy my windows to in a larger partition. I'd then use the older, smaller and slower disk as a scratch partition. I started by physically installing the new drive at at SCSI id 0. I moved the old drive from the 0 position to position #3 -- at least that's what the controller says during the boot process. What happened upon running the 10.3 install DVD was that for some reason, it called the old disk (scsi-id3) /dev/sda and the new disk (at scsi-id0) /dev/sdb. This was the first sign of "weirdness". Finished the install and it rebooted -- and the reboot failed -- 10.3 had installed grub on the 2nd hard disk (the one it named "sda") and setup the boot params for the previous windows partition to boot from partition "sda2" (1st partition was a Dell utility partition). Linux, it setup to boot from /dev/sdb. After trying to boot a few times in different ways, I discovered it had placed no boot-record on the 1st scsi disk (the one that it had called "sdb" for some reason). Using a one-time boot-menu option (F12), I could tell it what device to boot from. If I manually told it to boot from the 2nd SCSI drive, I would see a GRUB error message about a failure in stage 2.5 (I think). But it was obvious what had happened, SuSE mixed up the order of the scsi disks and put the MBR on the 2nd SCSI drive. Attempting to change the boot order to make the 2nd drive be given preference for booting didn't work -- since the 2nd drive was still the 2nd SCSI device, that SuSE had incorrectly thought was sda. I tried repairing it through linux, but grub is a bit more confused than lilo and doesn't readily provide the means necessary to remap (reverse) the BIOS order -- a trivial operation in lilo, but something beyond my current knowledge in Grub. Fortunately, the Windows system disk has the ability to repair messed up boot params and it was able to write the MBR to the correct physical device (SCSI-disk-0) and bootup normally. I expect I'll rerun the suse install (or at least the boot-record writing) after I take out the 2nd-SCSI device so Suse won't get confused and try to write the MBR to what was effectively "/dev/sdd". Don't know why the suse10.3 mixed up the order of the disks, but it probably related to the new "udev" feature of disassociating logical and physical device ordering. I'm thinking that maybe it shouldn't disassociate the device ordering when trying to install on a fresh hard disk, since it certainly doesn't seem to work correctly...:-(. Anyone know why the SUSE 10.3 install process might feel it necessary to create a logical order "opposite" the physical order (and thus confuse itself)? Clearly this isn't a desirable outcome...sigh... Linda -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
