In article <[EMAIL PROTECTED]>, Andrew Sackville-West wrote: > > On Fri, Nov 02, 2007 at 03:33:06PM -0700, [EMAIL PROTECTED] wrote: >> In article <[EMAIL PROTECTED]>, Johannes Wiedersich wrote: >> > Cameron L. Spitzer wrote: [ when I upgraded Etch to Lenny, device names changed and the Lenny kernel wouldn't boot, but the Etch kernel still worked. ]
>> > If I understand correctly, you upgraded the kernel and the new kernel >> > would not boot. Then it would be a kernel bug. [cls:] >> My friend in Los Angeles tried to install Ubuntu for a friend, >> and got stuck "waiting for root file system" in the middle of >> a fresh install from CD. When he booted his trusty Knoppix CD >> it revealed the root file system was just fine. I suspect udev >> device names are less persistent than we have assumed they are. > yeah, this is probably *not* a kernel bug but more likely either a > udev bug or initramsf-tools bug. Something got changed there in the > device naming and that's not really the kernel's fault, so far as I > know.=20 > > BTW, were you able to boot through the busybox? I didn't have to try. The Etch kernel+initrd still worked. As soon as the system was up I changed /etc/fstab and grub/menu.lst to use volume labels which make the Lenny kernel+initrd work too. > I've had to learn my > way around that having just reconfigured my laptop. The critical item > is the contents of $ROOT. The value of $ROOT gets set by the kernel > command line and if it doesn't match, then you have trouble. If you > change that to the appropriate value you can then 'exit' busybox and > the boot will carry on. I didn't know that. If I hadn't had a working option in GRUB I would have tried editing the kernel command line next. I've also rescued Debian by booting Knoppix, mounting stuff, and running a chroot shell. > Once you're up and running, then rebuil the > initrd's. I actually tried that before going to volume labels. Rebuilding the initrd puts the same old /etc/fstab in the new initrd image. That doesn't get you past the udev hang. I guess a more sophisticated update-initrd would alert you to the difference between the current mtab and the /etc/fstab contents. It wouldn't know whether the difference was intended, so it would have to ask what to do. And if I'd put a new device-names fstab in the Etch initrd then my Etch kernel wouldn't have worked any more. Come to think of it, I only learned about volume labels a few months ago, solving a similar problem. I installed an Etch web server on /dev/hde (a drive on an add-in ATA interface card), in a test machine that already had an Etch workstation on /dev/hda. And when I launched the hde kernel with GRUB it booted the workstation instead! I fiddled around with the udev rules but they were so poorly documented I wasn't confident I could upgrade the machine remotely. I've been using Debian for a long time. It's just *weird* to see anything broken like that. Cameron -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]