udev 151.1
in [Slackware]
|
Prev: 64 bit question
Next: removing emacs
From: Stuart Winter on 6 Mar 2010 04:46 On Sat, 6 Mar 2010 07:47:26 +0000 (UTC), tyketto(a)sbcglobal.net.invalid wrote: > 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. Are you including udev in the initrd - using mkinitrd -u ? or letting it use busybox's built in "mdev" ? If you include udev into your initrd, then adjust the initrd script: cd /boot mkdir t cd t zcat ../initrd.gz | cpio -di ## (or whatever the initrd is called) vi init Go to the bottom of this file: apply this patch: --- init.orig 2010-03-06 08:41:46.823362275 +0000 +++ init 2010-03-06 08:41:59.641349155 +0000 @@ -282,6 +282,8 @@ pkill udevd fi +/bin/sh + unset ERR mount -o move /proc /mnt/proc mount -o move /sys /mnt/sys find . | cpio -o -H newc | gzip -9fv > /boot/initrd.gz ## again use the real name Then reboot. It'll drop you into a busybox ash shell immediately before switching to the OS. If you then look in /dev, you'll probably find your sda* block devices. At least on ARM this worked - the same udev 151 in the initrd worked fine; just once the OS booted, it only populated /dev with a very small number of entries. So far for ARM I've: - tried the previous 2.6.32 kernel with the new udev: fail - tried 2.6.33 with the new udev: fail What I've now done is re-based the kernel config for the platform with troubles on another ARM platform which works. Now 2.6.33 and udev 151 work as they should. Question: - why does udev in the initrd work fine with the same kernel that will then fail when the OS boots and runs the OS copy of udev (even though it's the same udev -- mkinitrd copies udev off the running OS) Unfortunately my ARM kernel configs were quite different so I don't know what the difference is that fixes the problem. -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org
From: Stuart Winter on 6 Mar 2010 04:52 On 06 Mar 2010 09:46:41 GMT, not.a.real.address(a)interlude.org.uk wrote: > - why does udev in the initrd work fine with the same kernel that will then > fail when the OS boots and runs the OS copy of udev (even though it's > the same udev -- mkinitrd copies udev off the running OS) > > Unfortunately my ARM kernel configs were quite different so I don't know what > the difference is that fixes the problem. For this ARM platform, the udev 151 docs say: - Udev will not work with the CONFIG_SYSFS_DEPRECATED* option. Which is what I had configured. However, I still don't know why it worked in the initrd when the kernel had this configured. But I'd suggest reading the udev 151 README file to check if your kernel doesn't conflict with the requirements: Requirements: - Version 2.6.27 of the Linux kernel with sysfs, procfs, signalfd, inotify, unix domain sockets, networking and hotplug enabled: CONFIG_HOTPLUG=y CONFIG_UEVENT_HELPER_PATH="" CONFIG_NET=y CONFIG_UNIX=y CONFIG_SYSFS=y CONFIG_SYSFS_DEPRECATED*=n CONFIG_PROC_FS=y CONFIG_TMPFS=y CONFIG_INOTIFY_USER=y CONFIG_SIGNALFD=y CONFIG_TMPFS_POSIX_ACL=y (user ACLs for device nodes) CONFIG_BLK_DEV_BSG=y (SCSI devices) -- Stuart Winter www.slackware.com/~mozes Slackware for ARM: www.armedslack.org
From: Andy on 6 Mar 2010 10:32 Stuart Winter wrote: > On 06 Mar 2010 09:46:41 GMT, not.a.real.address(a)interlude.org.uk wrote: > >> - why does udev in the initrd work fine with the same kernel that will >> then >> fail when the OS boots and runs the OS copy of udev (even though it's >> the same udev -- mkinitrd copies udev off the running OS) >> >> Unfortunately my ARM kernel configs were quite different so I don't know >> what the difference is that fixes the problem. > > For this ARM platform, the udev 151 docs say: > - Udev will not work with the CONFIG_SYSFS_DEPRECATED* option. > > Which is what I had configured. However, I still don't know why it worked > in the initrd when the kernel had this configured. > > But I'd suggest reading the udev 151 README file to check if your kernel > doesn't conflict with the requirements: > Requirements: > - Version 2.6.27 of the Linux kernel with sysfs, procfs, signalfd, > inotify, > unix domain sockets, networking and hotplug enabled: > CONFIG_HOTPLUG=y > CONFIG_UEVENT_HELPER_PATH="" > CONFIG_NET=y > CONFIG_UNIX=y > CONFIG_SYSFS=y > CONFIG_SYSFS_DEPRECATED*=n > CONFIG_PROC_FS=y > CONFIG_TMPFS=y > CONFIG_INOTIFY_USER=y > CONFIG_SIGNALFD=y > CONFIG_TMPFS_POSIX_ACL=y (user ACLs for device nodes) > CONFIG_BLK_DEV_BSG=y (SCSI devices) I set CONFIG_SYSFS_DEPRECATED_V2=n, recompiled, re-installed udev-151 and now it reboots fine. The binary nvidia drivers loads now too. The kernel help for this option kinda rambles, but now that I know the solution I can see what it is trying to say. I knew there would be a simple fix once some people who grok the kernel esoterica more than I got involved. Thanks, Andy
From: Randy on 6 Mar 2010 13:29 Robby Workman wrote: > 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 Yes you are correct, and thanks for all of your work Robby, I know you have been here for years. Removing CONFIG_SYSFS_DEPRECATED and a recompile fixes all problems for me. I had just been using the same kernel config for so long that I assumed the issue was with udev. Maybe a small warning in the ChangeLog might be warranted, as you can see I am not the only one that is going to have issues with this. Best of luck, Randy.
From: Robby Workman on 7 Mar 2010 02:32
On 2010-03-06, Randy <zaphod812(a)yahoo.com> wrote: > Robby Workman wrote: > >> 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. >> > > Yes you are correct, and thanks for all of your work Robby, I know you have > been here for years. Removing CONFIG_SYSFS_DEPRECATED and a recompile fixes > all problems for me. I had just been using the same kernel config for so > long that I assumed the issue was with udev. Maybe a small warning in the > ChangeLog might be warranted, as you can see I am not the only one that is > going to have issues with this. Yes, this is perhaps worth a word of caution in our docs, but just so we're clear: we didn't intentionally "not mention" that. It's quite obvious now (especially to me, since I did much of the early behind the scenes work on the chain of stuff related to and including udev-149+), but we (the team) honestly didn't know why this was happening for the past few days. Once Stuart figured it out, it hit me like a ton of bricks, but I'd honestly not thought it would be an issue for us. We've not had that CONFIG_SYSFS_DEPRECATED option set in our default kernels *ever* at all, so I guess I'd just kicked that bit of memory off to the back of my head. -RW |