I can't help with the why, but I may have a 'fix'.I had similar issues with a mixed ATA/SCSI system. The BIOS and Grub would see the controllers and disks in one order, the kernel in a different order.
I fixed my problem by using the disk label based identification feature. This works for fstab and should work for your boot loader. Since I use 'grub' the following description uses that, but I think LILO allows the same sort of use.
You will need to change the fstab to replace the device name (/dev/hda1, for example) with a LABEL= directive (as in LABEL=/usr). For booting, edit the grub menu.lst file 'kernel' line from 'root=/dev/hda1' (or whatever it actually is) to 'root=LABEL=/...' (more on this below).
Use the appropriate disk labeling tool (/sbin/e2label for ext2/ext3, for example) to be sure there's a label on the disk partition(s). You can also see partition labels in the output of 'cfdisk'. Partitions created during a Debian install generally have default labels automatically created that match the mount point (at least with etch, it's been too long since I did a sarge install to remember).
One problem (I believe) with the defaults is the one used for the root device. Since the label is set equal to the mount point, the default root device label is a slash (/), which is the only really reserved character so far as file names and paths are concerned, since the system uses it as the name separator in a path (you can't create a file with the name '/').
This feature works by creating links in /dev/disk/by-label, from the label name to the disk actually created. Since the label is a fixed value, referencing the disk by the label will always get you to the right disk, no matter what hd?? name gets created.
When I first set this up, looking in /dev/disk/by-label, with the default labeling, there was no name or link for the root device, and my boot continued to fail. I changed the label to '/root' (I booted from a rescue CD, so I could write to the root partition), which then allows a valid name to be created, and everything was (and is) fine.
I hope this helps solve your boot problem. Bob Adam Rosi-Kessel wrote:
Kevin Mark wrote:I recently upgrade a perfectly functional sarge laptop to etch. It has one standard internal IDE hard drive. Now, about half the time it boots up as hda, and the other half the time it boots up as hde. After the initramfs stage, if the drive is identified as hde, it fails to boot unless I create a symlink from /dev/hde2 to /dev/hda2. There seems to be no rhyme or reason to why the same drive sometimes appears as hda and sometimes as hde.Love the blog(webloyalty and u-haul).Thanks -- seems my "consumer protection" entries get the most mileage. :)And could you provide more hardware details? Does this happend with any live cd's, if you tried any?The machine is an HP Omnibook 500 (circa 2000-2001). I haven't tried any live CDs since the laptop doesn't have a CD drive currently, although I could install one if it would help troubleshoot. I suspect it's something particular to the set of packages in Etch. I'd like to somehow isolate whether it's a package or the kernel. Interestingly, the error only pops up after the RAM disk stage, so apparently GRUB sees the disk correctly (/dev/hda2). I've posted relevant configuration information here: http://adam.rosi-kessel.org/bugs/hda_bootup_problem The syslog there is an example where the only drive has originally recognized as hda, but later in the boot up sequence it became hde, and thus I needed to ln -s /dev/hde2 /dev/hda2 from the ramdisk init shell in order to complete booting. I look forward to any suggestions. Adam
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature