Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 281312 - sys-fs/udev-145: fails with kernel 2.6.25 with newer glibc and older linux headers
Summary: sys-fs/udev-145: fails with kernel 2.6.25 with newer glibc and older linux he...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: High critical (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
: 281881 (view as bug list)
Depends on:
Blocks:
 
Reported: 2009-08-13 11:58 UTC by Paulo J. Matos
Modified: 2012-04-09 19:59 UTC (History)
6 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
.config for problem kernel (config,31.85 KB, text/plain)
2009-09-03 19:14 UTC, Ben Kohler
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paulo J. Matos 2009-08-13 11:58:38 UTC
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
Comment 1 Rafał Mużyło 2009-08-13 12:30:24 UTC
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.
Comment 2 Paulo J. Matos 2009-08-13 12:34:21 UTC
(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!
Comment 3 Graham Murray 2009-08-13 13:33:23 UTC
(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

Comment 4 Paulo J. Matos 2009-08-13 15:22:57 UTC
(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.

Comment 5 Rafał Mużyło 2009-08-13 16:51:40 UTC
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.
Comment 6 Paulo J. Matos 2009-08-14 11:07:00 UTC
(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!
Comment 7 Nick Keiser 2009-08-14 23:53:07 UTC
> 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.
Comment 8 DrChandra the Gentoo Person 2009-08-15 04:59:11 UTC
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
Comment 9 DrChandra the Gentoo Person 2009-08-17 23:41:24 UTC
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.
Comment 10 Matthias Schwarzott gentoo-dev 2009-08-18 08:15:56 UTC
(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.


Comment 11 Ben Kohler gentoo-dev 2009-09-03 19:10:21 UTC
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.
Comment 12 Ben Kohler gentoo-dev 2009-09-03 19:14:09 UTC
Created attachment 203073 [details]
.config for problem kernel

here's a kernel config for gentoo-sources-2.6.26-r4 failing with udev-145
Comment 13 Matthias Schwarzott gentoo-dev 2009-09-03 19:36:25 UTC
(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.
Comment 14 Matthias Schwarzott gentoo-dev 2009-09-05 13:48:44 UTC
*** Bug 281881 has been marked as a duplicate of this bug. ***
Comment 15 Matthias Schwarzott gentoo-dev 2009-09-08 13:07:36 UTC
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.
Comment 16 Matthias Schwarzott gentoo-dev 2009-09-08 13:14:51 UTC
@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
Comment 17 SpanKY gentoo-dev 2009-09-08 17:36:57 UTC
Debian hasnt done anything but take the patch from upstream

http://sourceware.org/git/?p=glibc.git;a=commitdiff;h=aa7492d20e5a2cef54dab7b41f534048b3eca479
Comment 18 Matthias Schwarzott gentoo-dev 2009-09-21 09:27:25 UTC
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>.
Comment 19 Geoff Ellis 2009-11-29 22:44:00 UTC
(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.

Comment 20 Adam Felson 2009-12-08 17:53:22 UTC
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.
Comment 21 Xuefer 2009-12-12 05:09:34 UTC
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
Comment 22 Roland Everaert 2009-12-29 19:11:34 UTC
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.
Comment 23 craven 2010-01-08 21:37:09 UTC
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.
Comment 24 Emiliano Perez 2010-03-02 15:13:04 UTC
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.
Comment 25 SpanKY gentoo-dev 2010-03-07 00:50:42 UTC
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 ...
Comment 26 SpanKY gentoo-dev 2012-04-09 19:59:30 UTC
glibc 2.13 is stable