I have kernel 2.6.25 and I upgraded from udev 141 to 145 and it was the end of the world. Boot didn't work, network devices didn't load and partitions couldn't be mounted. Had to go back to udev 141. Guess 145 required a higher kernel version! This is unacceptable behaviour. udev 145 should check if the current kernel version is compatible with it. Otherwise a warning should be issued and the emerge fails. Problem initially referred to in http://forums.gentoo.org/viewtopic-p-5931436.html Reproducible: Always
Somehow I doubt udev ever really cared about backward compatibility with older kernels. And technically, 145 in its README claims that 2.6.25 (with some added conditions) IS the minimum requirement.
(In reply to comment #1) > Somehow I doubt udev ever really cared about backward compatibility > with older kernels. > And technically, 145 in its README claims that 2.6.25 > (with some added conditions) IS the minimum requirement. > Well, my gentoo-sources-2.6.25 didn't work. Besides not working, screwed up my boot. An issue like this in the system part of portage would warrant in my opinion at least an emerge notice! Nobody reads the README file of portage packages!
(In reply to comment #2) An issue like this in the system part of portage would warrant in my > opinion at least an emerge notice! Nobody reads the README file of portage > packages! > Even if they do, it is a catch-22 situation as the README file cannot be read until the package is installed and by then it could be too late - and in the case of udev I think it would be as the ebuild restarts udev to use the new one immediately. To be fair, the udev-145 ebuild does check to make sure you are running at least kernel 2.6.25
(In reply to comment #3) > (In reply to comment #2) > An issue like this in the system part of portage would warrant in my > > opinion at least an emerge notice! Nobody reads the README file of portage > > packages! > > > > Even if they do, it is a catch-22 situation as the README file cannot be read > until the package is installed and by then it could be too late - and in the > case of udev I think it would be as the ebuild restarts udev to use the new one > immediately. > > To be fair, the udev-145 ebuild does check to make sure you are running at > least kernel 2.6.25 > Hummm, then that's not enough because I surely have 2.6.25 and it surely broke. Anyway, I think the point is. Maybe we could just add a warning after the package emerges or something even if the compatibility cannot be checked in full.
Could you check those additional requirements, as it may be similar to bug 281338 ? If so, some kernel config checks will need to be added.
(In reply to comment #5) > Could you check those additional requirements, > as it may be similar to bug 281338 ? > If so, some kernel config checks will need to be added. > Checked the bug. Truth is, it seems that I have inotify in my kernel: $ sudo zcat /proc/config.gz | grep INOTIFY Password: CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y Have no idea what's missing. Something else is missing from the kernel! Something that might help is that with udev 145, when I call udevd from the command line it fails by saying that it's missing signalfd(). Something confusing though is that I think signalfd is enabled in my config: $ sudo zcat /proc/config.gz | grep SIGNALFD CONFIG_SIGNALFD=y Maybe there's something else missing!
> To be fair, the udev-145 ebuild does check to make sure you are running at > least kernel 2.6.25 > This check in the ebuild may not be working properly. udev-145 installed properly but my box was running 2.6.24-r8. On reboot, udev reported itself as not being compatible with my kernel and no input devices worked - had to boot a live CD and chroot in to downgrade to 141-r1.
I have kernel gentoo-sources-2.6.26-r4, and udev-145 failed like this for me too. Note that I have sys-libs/glibc-2.10.1, which is what installs /usr/include/sys/signalfd.h. The kernel source version of that file may not matter, if the glibc version of it is intended to be used with one from and older version fo the kernel. Maybe sys-kernel/linux-headers needs to update /usr/include/linux/signalfd.h to a version after kernel 2.6.24. BTW, Debian has a bug which appears similar: https://bugs.launchpad.net/ubuntu-on-ec2/+bug/397187
I tried updating my kernel config to match what the packaged README says I should be using, but I still can't use udev-145. I couldn't detect any difference. The main symptom is that /dev is missing most of its devices.
(In reply to comment #9) > I tried updating my kernel config to match what the packaged README says I > should be using, but I still can't use udev-145. I couldn't detect any > difference. The main symptom is that /dev is missing most of its devices. Please attach your kernel config file.
I saw the same symptoms as the original reporter. udev-mount failed, which caused a cascading set of failures, especially since /usr and /var couldn't mount (life without /usr is tough). Was able to umount udev, which gave me the generic /dev on disk, which was enough to get me gimping along well enough to downgrade udev to 141-r1. All is well after that. Now I know you're thinking "you just repeated his story, thanks for nothing". But this was on gentoo-sources-2.6.26-r4. I wonder where the *working* kernels start.
Created attachment 203073 [details] .config for problem kernel here's a kernel config for gentoo-sources-2.6.26-r4 failing with udev-145
(In reply to comment #12) > > here's a kernel config for gentoo-sources-2.6.26-r4 failing with udev-145 > > CONFIG_SYSFS_DEPRECATED=y > CONFIG_SYSFS_DEPRECATED_V2=y Please try with these two disabled. I suggest you try to emerge udev in a running system. If it fails to restart (= it does not run after update), then just downgrade before rebooting. So you keep a running system.
*** Bug 281881 has been marked as a duplicate of this bug. ***
I identified one problem here, but cannot be sure it is your bug. What does udevd print when it fails? Is it "error getting signalfd"? What this bug also missis is your "emerge --info". In case of signalfd error I found some failing case: Using a glibc versions supporting signalfd4 syscall and compiled against linux-headers-2.6.27 or newer. Then glibc will use the new signalfd4 syscall and does NOT fallback to the signalfd syscall introduced with kernel 2.6.25. int signalfd (int fd, const sigset_t *mask, int flags) { #ifdef __NR_signalfd4 return INLINE_SYSCALL (signalfd4, 4, fd, mask, _NSIG / 8, flags); #else /* The old system call has no flag parameter which is bad. So we have to wait until we have to support to pass additional values to the kernel (sys_indirect) before implementing setting flags like O_NONBLOCK etc. */ if (flags != 0) { __set_errno (EINVAL); return -1; } # ifdef __NR_signalfd return INLINE_SYSCALL (signalfd, 3, fd, mask, _NSIG / 8); # else __set_errno (ENOSYS); return -1; # endif #endif } So one easy solution is to change kernel requirement to kernel 2.6.27.
@toolchain: It seems debian has patched glibc so that signalfd calls signalfd4 and falls back to old signalfd syscall. http://lists.debian.org/debian-glibc/2009/07/msg00324.html
Debian hasnt done anything but take the patch from upstream http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aa7492d20e5a2cef54dab7b41f534048b3eca479
Do you plan to add this compat-patch to glibc, or will this not be done, as 2.6.25 is old and 2.6.30 is already marked stable? Well, it would be nice if there was an easy way to determine the linux-headers version glibc was compiled against. Calling /lib/libc.so.6 here prints the kernel that was used at that time, but not the linux-headers. Is the kernel even affecting glibc build process? GNU C Library stable release version 2.10.1, by Roland McGrath et al. Copyright (C) 2009 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.3.3. Compiled on a Linux >>2.6.29-tuxonice-r2<< system on 2009-05-26. Available extensions: C stubs add-on version 2.1.2 crypt add-on version 2.1 by Michael Glad and others Gentoo patchset 1 GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B For bug reporting instructions, please see: <http://www.gnu.org/software/libc/bugs.html>.
(In reply to comment #0) > I have kernel 2.6.25 and I upgraded from udev 141 to 145 and it was the end of > the world. Boot didn't work, network devices didn't load and partitions > couldn't be mounted. Had to go back to udev 141. Guess 145 required a higher > kernel version! > > This is unacceptable behaviour. udev 145 should check if the current kernel > version is compatible with it. Otherwise a warning should be issued and the > emerge fails. > > Problem initially referred to in > http://forums.gentoo.org/viewtopic-p-5931436.html > > Reproducible: Always > Just want to confirm this is still a problem I just completed a world upgrade and now can not boot since udev was upgraded. I agree a warning should be issued and the emerge should have failed.
The new stable udev is now udev-146-r1 and I've experienced this bug. I masked it and am now running udev-141 without problems. My kernel is 2.6.25-r9. $ grep CONFIG_SYSFS /boot/config CONFIG_SYSFS_DEPRECATED=y CONFIG_SYSFS_DEPRECATED_V2=y CONFIG_SYSFS=y I didn't try rebuild my kernel with CONFIG_SYSFS_DEPRECATED=n as reverting to udev-141 fixed my system.
this is not only a package issue but a gentoo system issue, the whole booting is screwed up, no network available, no loop device to mount /usr/portage (i use /usr/portage.img) unless i mknod manually. i can rescue myself, but what about other users? please mask it asap before you figure our a perfect solution
I also face the problem with udev-146-r1 and kernel 2.6.25-r7. a chroot from a LiveCD and masking the package versions above udev-141 + emerge udev fix the problem for me.
same problem with sys-fs/udev-146-r1 on x86 I'm running a 2.6.26-gentoo-r4 kernel with the following config zgrep SYSFS /proc/config.gz # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_ACPI_SYSFS_POWER=y CONFIG_SYSFS=y udevd dies right after starting with error getting signalfd I use sys-libs/glibc-2.9_p20081201-r2 and sys-kernel/linux-headers-2.6.27-r2 considering comment #15 I think this might be a bug of the sys-kernel/linux-headers ebuild. Is it sensible to use more recent kernel headers than the current kernel? May be sys-kernel/linux-headers should check the version of the running kernel or the /usr/src/linux link to ensure that it doesn't provide interfaces that are not really available. sys-fs/udev-146-r1 emits a warning during postinst FATAL: udev died, please check your kernel is new enough and configured correctly for udev-146. Please have a look at this before rebooting. If in doubt, please downgrade udev back to your old version but this might easily fly by unseen in a larger upgrade. As it is VERY HARD for an unexperienced user to recover the system if he does the reboot, I think the merge should fail at this point to force the user to acknowledge the warning. If udev does not start during the next boot due to this problem, there won't be any device files for the hard disks, which makes it cumbersome to even mount the portage tree if it is on a separate partition, thus downgrading to a working udev is not trivial. Without udev setting up the network interfaces looking for help online is also not easy. Booting from a live CD and chrooting to the installed system is probably the easiest way to downgrade udev [if a live CD is at hand...]. Actually I think that not even a failing merge is enough to account for the troubles that might follow. I think >=udev-145 should try to check the versions of sys-kernel/linux-headers and the current kernel to avoid the situation completely. udev could also depend on more recent kernels as suggested in comment 15 or be marked as testing instead of stable until this issue is resolved. All in all I think some action should be taken ASAP to avoid having people render their systems useless.
I have the same issue here. I've got multiple Gentoo servers installed with the 2008.0 LiveCD, when I did an emerge -Du world, it updated udev and downloaded the new gentoo-sources (because udev needed that updated kernel). Although nobody told me to "update the kernel or die", so I've just rebooted it to see if it's ok and bump, server down, telling me that my kernel is too old. Portage should NOT install the new udev version if the kernel that's been used is not supported by the newest udev. Because if he does, this happens and leaves your server unusable. The only solution I've found was to boot with a LiveCD, chroot to my gentoo installation, build an updated kernel and then reboot.
the patch in question is in glibc-2.11, and the likely hood of another glibc-2.10 patchset is pretty low plus, newer linux-headers are stabilizing, so i think things are fixing themselves at this point ...
glibc 2.13 is stable