ETA fixed -- I had tried too much gentoo upgrade all at once and borked it. Once I followed the proper procedure as documented, the only hiccup was that udev complained about the running kernel number but did compile. I suppose it doesn't understand the Linode kernel name.

I am just starting here, trying to set up a gentoo image. I updated the profile and am trying to remerge system, and world, but first I want to upgrade to baselayout-2.

The problem is udev wants the kernel config. It is looking in /usr/src/linux, which emerge populated with linux-2.6.31-r6. That's nice, but I haven't built a kernel because it boots off the Linode kernel, and I don't want to make up my own config which is unrelated to what actually boots.

First off, this sounds silly, but do I need udev on a Linode image? I suspect so, but I figure I meed to confirm that.

One way to get udev to merge would be to get the config used by the Linode booting kernel (2.6.31.5-x86_64-linode9). Is this available? I don't mind stuffing it into /usr/src/linux and building a kernel to fool udev.

Are there other ways to fool udev, or is there a better solution doing something entirely different?

You can download the sources and configurations used for the Linode-provided kernels - see the response at http://www.linode.com/forums/viewtopic. ... 4036#24036

Alternatively, if it's a 2.6 kernel, /proc/config.gz should provide you with the active configuration, though whether or not that's sufficient for a particular application or tool chain would depend on the specific tool at hand.

-- David

I downloaded the tarball of sources, then made the kernel (but of course can't boot from it and don't want to), and unfortunately, that isn't good enough. It actually dies with two different error messages. One complains about SOCK_CLOEXEC not defined, the other that the kernel is too old. I suppose if SOCK_CLOEXEC is a relatively new feature and my glib, for instance, needs an upgrade, that could explain this.

x86_64-pc-linux-gnu-gcc -c -I. -I.    -march=nocona -Os -pipe -DMAXWIN=100 -DNONETHACK acls.c
libudev/libudev-monitor.c: In function 'udev_monitor_new_from_netlink':
libudev/libudev-monitor.c:199: error: 'SOCK_CLOEXEC' undeclared (first use in this function)
make[2]: *** [libudev/libudev-monitor.lo] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
 * 
 * ERROR: sys-fs/udev-147 failed.
 * Call stack:
 *               ebuild.sh, line   49:  Called src_compile
 *             environment, line 3610:  Called die
 * The specific snippet of code:
 *       emake || die "compiling udev failed"
 *  The die message:
 *   compiling udev failed
 * 
 * If you need support, post the topmost build error, and the call stack if relevant.
 * A complete build log is located at '/var/log/portage/sys-fs:udev-147:20091123-032820.log'.
 * The ebuild environment file is located at '/var/tmp/portage/sys-fs/udev-147/temp/environment'.
 * 

>>> Failed to emerge sys-fs/udev-147, Log file:

>>>  '/var/log/portage/sys-fs:udev-147:20091123-032820.log'

 * Messages for package sys-fs/udev-147:

 * 
 * udev-147 does not support Linux kernel before version 2.6.25!
 * For a reliable udev, use at least kernel 2.6.27
 * 
 * udev cannot be restarted after emerging,
 * as your running kernel version (2.6.31.5-x86_64-linode9) is too old.
 * You really need to use a newer kernel after a reboot!

Other than fiddling with the ebuild itself as a temporary hack, is there some way to get around this?

What version is the kernel sources in /usr/src/linux?

The bug you posted regarding SOCK_CLOEXEC was fixed in around 2.6.28... and the error you posted suggests ebuild thought it had detected an older-than-2.6.25 kernel version in /usr/src/linux.

In a pinch, you could apply a trivial custom modification to the kernel sources if you wish, to assist in getting past that barrier:

http://lists.ofono.org/pipermail/ofono/ ... 00345.html

I had botched the post-install upgrade, trying to do the profile upgrade and everything all in one swell foop. Didn't work so well ... so I have restarted, doing things by the book. It is now doing the emerge system after the profile upgrade, which itself went much better. I will update this when I see how well that works.

Apologies for borking it and asking for help. I ought to know better by now!

Odd ... udev emerges after having upgraded properly, but still claims it cannot restart udev because the kernel is too old. I suppose it doesn't understand the Linode name. I restarted it fine, upgraded gcc, and everything seems to be working. I'll mark this as resolved with some explanation.

It sounds like you are satisfied, but as an alternative you can always run the stock gentoo kernel instead:

http://www.linode.com/wiki/index.php/PV-GRUB
http://library.linode.com/advanced/pv-grub-howto

I will see how annoying it is to emerge udev independently of other packages, to avoid the false failure. Or maybe I can make the ebuild ignore the kernel version check.