Linux - SoftwareThis forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
I built a little ftp server out of an ancient (Pentium II) machine and threw Gentoo on it. It ran fine for about a week, then I got a udev update.
After applying the update and rebooting, GRUB was broken (when the computer turned on, it just printed the word "GRUB" to the screen a billion times and never stopped). I booted back into the live CD, reinstalled grub, and that seemed to work fine...
However, once the machine boots now, it can't find any /dev/hd* nodes. Oddly, it DOES boot successfully (though it throws errors about the missing drives) and sees all of the root partition (but not my separate boot partition or my ftp data partition).
Anyone have any ideas about how this got so broken and how to fix it?
This had to have something to do with udev, and I'm not especially familiar with it. Ordinarily I'd just reinstall the OS, but since the machine is so old it took forever to do all the compiling for the Gentoo installation and I'd like to avoid that if possible.
Please show us the output of fdisk -l (run as root), and the contents of your /etc/fstab file. And be sure to make it clear which drive is which. Probably you just need to update the fstab entries.
One change that's been going creeping the system recently is that the kernel drivers have been changed so that all drives are created as sd*, and hd* is deprecated. Also, many distros now use uuids or labels in fstab to mount important system partitions, so that changes in the /dev entries don't impact them, but this isn't always true of non-system disks. I'm guessing that this might be what happened to you.
My Debian systems had to go through the change a few months ago, but they provided a helpful script to automatically modify my fstab and a warning to check it afterwards.
I forgot to point out before that fdisk -l returns nothing at all...
I've run into the hd*/sd* problem before, but since this machine is so old, I didn't think that was the issue. Also, when I had those problems with other machines, they wouldn't boot until I made those changes to GRUB and fstab.
Even if that were the case, /dev/sd* would at least EXIST (they don't in this case). What boggles my mind is that GRUB's real_root is pointing at /dev/hda1, and that works fine. Like I said, with everything pointing at hd*, the machine still manages to boot somehow, but my non-root partitions aren't recognized and all my /dev/hd* are gone.
Note also that when the problem first started, my fstab lines were all UUID based, so it shouldn't matter if it was hd* or sd*. For the record though, my fstab (with the /dev versions commented out) is
I can't still be in a ramdisk because I don't have one. I compiled the kernel myself, and Gentoo doesn't use ramdisks unless you compile your kernel using its own scripts (genkernel), which I didn't do.
which sounds a LOT like what's happening to me (my update crossed over udev 150). Previously, when I had transitioned to libata it happened automatically, but in this case, the kernel was not configured for it for some reason.
It's recompiling now... will probably have to run overnight, but I'll let you know how it goes.
syg00 was right, for some reason the kernel wasn't configured for libata (I assumed it would be by default... but that's what happens when you assume).
Once my new kernel was compiled, I had to change everything to sd*, but for some reason I also had to change the grub boot line from real_root=/dev/sda3 to root=/dev/sda3. I don't know why that should have anything to do with it, but it kernel panicked until I changed that, more or less for lack of other options.