LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   udev update killed all HDD dev nodes (https://www.linuxquestions.org/questions/linux-software-2/udev-update-killed-all-hdd-dev-nodes-823266/)

MALDATA 07-31-2010 02:17 PM

udev update killed all HDD dev nodes
 
Hi all

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.

Thanks

David the H. 08-01-2010 03:43 AM

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.

MALDATA 08-01-2010 12:10 PM

Hi David,

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

Code:

UUID=e33e6ec6-c91a-469c-ba5c-44274c777064        /boot        ext3        defaults,noatime        1 2
UUID=7f988de1-2236-4094-9e9f-ae9b8d5672d3        none        swap        sw        0 0
UUID=d8dd70b9-378e-4ae0-b761-66797533e617        /        ext3        defaults,noatime        0 0
UUID=828deb74-2a8b-4770-bd9e-c939b785b5e3        /var/ftp        ext2        defaults,noatime        0 0

#/dev/hda1        /boot        ext3        defaults,noatime        1 2
#/dev/hda2        none        swap        sw        0 0
#/dev/hda3        /        ext3        defaults,noatime        0 0
#/dev/hdb2        /var/ftp        ext2        defaults,noatime        0 0
/dev/cdrom            /mnt/cdrom      auto            noauto,ro      0 0

So, /dev/hda1 or UUID=e33e... is my boot partition. Obviously it works during boot, but is not mounted and is not seen in /dev.

/dev/hdb2 or UUID=828d... is my ftp data partition. It is not mounted and is not seen in /dev.

/dev/hda3 or UUID=d8dd... is my root partition. I can see files and directories in here (except the two directories above), but is not seen in /dev.

Hopefully that makes it a little more clear why I'm so confused...

Thanks!

David the H. 08-01-2010 01:15 PM

Well, that boggles me then. I have no idea what it could be, other than some problem with udev or its rules. Can you try returning to a previous version of it?

Also, what does cat /proc/partitions say? And where do the symlinks in /dev/disk/by-uuid/ point to, if anything?

Perhaps you're simply never leaving the initial ramdisk and you're only seeing the rescue shell or something like that.

MALDATA 08-01-2010 04:32 PM

Well THAT'S weird...

Code:

$ cat /proc/partitions
major minor  #blocks  name

  3        0  39082680 hda
  3        1    257008 hda1
  3        2    506047 hda2
  3        3  38315025 hda3
  3      64  244198584 hdb
  3      65    530113 hdb1
  3      66  243665887 hdb2

But there's no /dev/disk directory at all. In fact, for the sake of completeness:

Code:

$ ls /dev
bus                null    tty11  tty25  tty39  tty52  tty9            vcs6
char                port    tty12  tty26  tty4  tty53  ttyS0          vcsa
console            psaux  tty13  tty27  tty40  tty54  ttyS1          vcsa1
cpu_dma_latency    ptmx    tty14  tty28  tty41  tty55  ttyS2          vcsa12
etherd              pts    tty15  tty29  tty42  tty56  ttyS3          vcsa2
fd                  random  tty16  tty3  tty43  tty57  urandom        vcsa3
full                rtc    tty17  tty30  tty44  tty58  usbdev1.1_ep00  vcsa4
initctl            shm    tty18  tty31  tty45  tty59  usbdev1.1_ep81  vcsa5
input              stderr  tty19  tty32  tty46  tty6  vcs            vcsa6
kmem                stdin  tty2  tty33  tty47  tty60  vcs1            zero
kmsg                stdout  tty20  tty34  tty48  tty61  vcs12
log                tty    tty21  tty35  tty49  tty62  vcs2
mem                tty0    tty22  tty36  tty5  tty63  vcs3
network_latency    tty1    tty23  tty37  tty50  tty7  vcs4
network_throughput  tty10  tty24  tty38  tty51  tty8  vcs5

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.

Let me know if you think of anything.

Thanks

syg00 08-01-2010 06:01 PM

Sounds like you're attempting to still use the old PATA support - it's gone and udev won't build the nodes. Move up to libata. Check the gentoo site forums.

MALDATA 08-01-2010 11:05 PM

I think you guys are onto something. libata was the missing piece of my google searches, I think. I hit this:

http://bugs.gentoo.org/show_bug.cgi?id=302173

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.

Thanks

MALDATA 08-07-2010 02:26 PM

Alright, I think I finally got it fixed.

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.

Thanks everyone.


All times are GMT -5. The time now is 10:09 AM.