udev 151.1
in [Slackware]
|
Prev: 64 bit question
Next: removing emacs
From: Stuart Winter on 5 Mar 2010 11:55 > least for me on 64-current. Booting to it into an initrd-based kernel > with sata and pata support built into the initrd drops you to the > maintenance prompt saying that /dev/sda1 isn't available. Logging in > shows that /dev/sd* is missing completely. booting to the stock 2.6.33 > kernel works fine. Reverting back to udev-141 works, so something is > definitely up with udev-151. Well, I'm reading it and I've been having the exact same problem with one of the ARM platforms for Slackware ARM -- which uses an initrd; only I thought it was an ARM problem. I'm glad it's not! If you use udev in your initrd, and add "/bin/sh" just before the mount commands that move /dev into the real location and so on, you can ls /dev and see that udev has created the entries for /dev/sda* So far I can't find what is wrong with udev when it gets run from the OS proper. but Pat's aware of the issue now. -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org
From: Andy on 5 Mar 2010 19:09 Stuart Winter wrote: >> least for me on 64-current. Booting to it into an initrd-based kernel >> with sata and pata support built into the initrd drops you to the >> maintenance prompt saying that /dev/sda1 isn't available. Logging in >> shows that /dev/sd* is missing completely. booting to the stock 2.6.33 >> kernel works fine. Reverting back to udev-141 works, so something is >> definitely up with udev-151. > > Well, I'm reading it and I've been having the exact same problem with > one of the ARM platforms for Slackware ARM -- which uses an initrd; > only I thought it was an ARM problem. I'm glad it's not! > > If you use udev in your initrd, and add "/bin/sh" just before > the mount commands that move /dev into the real location and so on, > you can ls /dev and see that udev has created the entries for /dev/sda* > > So far I can't find what is wrong with udev when it gets run from > the OS proper. > > but Pat's aware of the issue now. > Downgrading udev-151 to udev-141 also fixes the issue with loading the nvidia binary driver using modprobe (insmod worked for some reason). Andy
From: Robby Workman on 6 Mar 2010 00:35 On 2010-03-05, Randy <zaphod812(a)yahoo.com> wrote: > Guess I should have mentioned that I compiled everything I use in to my > kernel (2.6.31.6) I don't suppose Pat reads this board anymore, think he may > have years ago. I'll consider this as bug report filed. Consider this as "NOTABUG" I'm sorry that your custom kernel doesn't work on our system, but we simply don't have time to troubleshoot that. -RW
From: Robby Workman on 6 Mar 2010 00:37 On 2010-03-05, A Guy Called Tyketto <tyketto(a)sbcglobal.net.invalid> wrote: > > Randy <zaphod812(a)yahoo.com> wrote: >> Anyone else having problems with the new udev 151-1 in the latest updates >> in Slack32. System did not boot and had to downgrade to to 141-3 from >> Slack32 13.0. > > Confirmed. Slackware64-current for me. > > Robby, if you're reading this, run this back up the flagpole to > PV so he at least has some insight. udev-151 is somewhat broken, at > least for me on 64-current. Booting to it into an initrd-based kernel > with sata and pata support built into the initrd drops you to the > maintenance prompt saying that /dev/sda1 isn't available. Logging in > shows that /dev/sd* is missing completely. booting to the stock 2.6.33 > kernel works fine. Reverting back to udev-141 works, so something is > definitely up with udev-151. As with the previous post, it sounds like you're saying *our* kernel works but yours doesn't. If that's the case, I'm genuinely sorry, but we don't have time (at least not now) to troubleshoot that. Compare the kernel configs using the 'diffconfig' script in $kernelsource/scripts/ - that should be a good starting point. -RW
From: A Guy Called Tyketto on 6 Mar 2010 02:47
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robby Workman <newsgroups(a)rlworkman.net> wrote: > On 2010-03-05, A Guy Called Tyketto <tyketto(a)sbcglobal.net.invalid> wrote: >> >> Robby, if you're reading this, run this back up the flagpole to >> PV so he at least has some insight. udev-151 is somewhat broken, at >> least for me on 64-current. Booting to it into an initrd-based kernel >> with sata and pata support built into the initrd drops you to the >> maintenance prompt saying that /dev/sda1 isn't available. Logging in >> shows that /dev/sd* is missing completely. booting to the stock 2.6.33 >> kernel works fine. Reverting back to udev-141 works, so something is >> definitely up with udev-151. > > > As with the previous post, it sounds like you're saying *our* > kernel works but yours doesn't. If that's the case, I'm > genuinely sorry, but we don't have time (at least not now) to > troubleshoot that. Compare the kernel configs using the > 'diffconfig' script in $kernelsource/scripts/ - that should be > a good starting point. This is exactly *not* what I am saying. Looking through the diffconfig, both the stock kernel and my custom kernel both have CONFIG_SCSI=y. The only difference is that the stock kernel has CONFIG_BLK_DEV_SD=y whereas I have CONFIG_BLK_DEV_SD=m. The sd_mod built from this is then put directly into the initrd via mkinitrd, whereas you have a monolithic kernel. Somewhere along the way, the newest build of udev does not load that module at boot time, where the previous build does. IIRC, both Slamd64 10.* and Slackware 10.2 had the same problem when migrating from udev-072 to udev-081, and reverting back to 072 was the only thing that fixed it, and those were with monolithic kernels. Plus, I find it quite odd that a kernel that boots fine with software around it suddenly doesn't when the particular package that creates the devices doesn't create it anymore. That would mean that either the kernel is bung (which it wouldn't boot at all both pre and post updates), or the older udev was broken, shouldn't have worked at all, and the new update fixes it properly, or the older one works, and the newer one is broken. Seeing that I've used the same .config since 2.6.7, I kinda doubt it's the kernel, whether custom or stock. BL. - -- Brad Littlejohn | Email: tyketto(a)sbcglobal.net Unix Systems Administrator, | tyketto(a)ozemail.com.au Web + NewsMaster, BOFH.. Smeghead! :) | http://www.wizard.com/~tyketto PGP: 1024D/E319F0BF 6980 AAD6 7329 E9E6 D569 F620 C819 199A E319 F0BF -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLkgiHyBkZmuMZ8L8RAn8PAKDYZIo0LewRcnp1qv2SpG/aQgkd9gCg890j 6SpgxwZS4gRKl80I2emagAU= =CwLU -----END PGP SIGNATURE----- |