# [Kernel 3.5.7] /sbin/udevd missing following updates

## Schol-R-LEA

I have a Gentoo Linux installation on a dual-booting Intel i7 quad core system (running amd64 mode) which I had sadly neglected for some time, which had been running kernel 3.0.6 and GNOME 2.3 IIRC. I had recently decided to update both the kernel and the version of Gnome to 3.5.7 and 3.2, respectively. After solving numerous conflicts through manual updates and revdep-rebuild, repeatedly reconfiguring and rebuilding the kernel, and adding an initramfs file to /boot, I was able to get most of the issues resolved. 

Unfortunately, one issue remains: on boot-up, udevd is missing, and in fact the only udev* file in /sbin is udevadm. I have repeatedly emerged udev, and run both repdev-rebuild and dispatch-conf afterwards. I have rebooted into a liveDVD, and after chrooting back into the system, have done the same there, but to no change. 

I do have multiple different partitions, including a separate /usr partition (hence the initramfs setup), but /sbin is in my root partition. I am currently mixing stable and development files in order to get Gnome to install. The version of udev in question is 195.

Any constructive advice on this matter would be appreciated. Please let me know if there is any further information that would be useful.

----------

## BillWho

Schol-R-LEA,

Start with making sure these are set:

```
CONFIG_DEVTMPFS=y

CONFIG_DEVTMPFS_MOUNT=y

```

----------

## Schol-R-LEA

OK, I checked those, and they are set correctly. I even rebuilt the kernel again to make sure I didn't overlook any steps before, but there is no change.

----------

## The Doctor

 *Schol-R-LEA wrote:*   

> ....adding an initramfs file to /boot,....

 

How? Did you roll your own or use a tool? If there is improper cleanup, that will kill the init process.

----------

## Schol-R-LEA

I rolled my own, but for the boot script from an example in the tutorial on the subject which I had been reading (with sitable changes to the device references).

----------

## The Doctor

Can you post it? It would be nice to at least eliminate it as the source of your problem.

I also rolled my own and found that the documentation I was following was lacking in a few key details.

----------

## Schol-R-LEA

Certainly. The wiki page I got it from was http://en.gentoo-wiki.com/wiki/Initramfs, if that helps any.

```
#!/bin/busybox sh

# Mount the /proc and /sys filesystems.

mount -t proc none /proc

mount -t sysfs none /sys

# Do your stuff here.

echo "This script mounts rootfs and boots it up, nothing more!"

# Mount the root filesystem.

mount -o ro /dev/sda8 /mnt/root

# Clean up.

umount /proc

umount /sys

# Boot the real thing.

exec switch_root /mnt/root /sbin/init

```

In retrospect, it is clear that this set of directions was inadequate. I have found another tutorial, which seems to cover the matter in greater detail, but I am hesitant to restart the process with it.

----------

## Schol-R-LEA

As an update, I did eventually break down and start applying the other tutorial, but while it does seem to be an imporivement in some senses, it is failling outright at the part where it is supposed to run the file system check.

----------

## The Doctor

OK, I see the problem. You have a separate /usr, but that script only mounts /. You need to add the line 

```
mount -o ro /dev/<usr> /mnt/root/usr
```

 after you mount root but before you clean up. Basically, your initramfs currently does nothing the kernel would not do on its own.

The script you posted is fine. It will do what you want, you just need to tell it to do it. You don't need to go crazy in the script unless you want to.

EDIT: if you don't want to bother with an initramfs, sys-apps/busybox has an option that will take care of mounting /usr before udev starts. You just need to set the -sep-usr flag and it should do the trick.

----------

## Schol-R-LEA

I have what now seems to be a working initramfs script, but the problem with udevd persists. I no longer think this is a boot issue, but an portage issue. The file for the daemon simply isn't getting generated, for some reason.

----------

## The Doctor

I suppose this is a silly question, but you are running comparable versions of udev-init-scripts, kmod, and udev right? that is to say, all three come from the unstable branch?

----------

## Schol-R-LEA

They all should be, yes. I'll re-emerge kmod to make certain.

----------

## gerard27

Install udev-171-r8 and mask anything higher.

You then won't need an initram.

Gerard.

----------

## Schol-R-LEA

Yes, well initramfs is definitely working now, yet the udev problem persists. I ended up going in the other direction - compiling almost everything, including the kernel, from the Unstable branch - but the problem hasn't changed. I'm seriously tempted to do a clean reinstall - wipe everything except my /home partition - but I am certain I'll learn a lot more if I can manage to fix the problem in situ, as it were.

EDIT: I ran across a this post that claimed that udevd is no longer in /sbin, but instead in  /lib/udev, and that revdep-rebuild should have updated any references to it (assuming the updates all exist). I've checked /lib/udev, and udevd isn't there. Does anyone know anything about this?

----------

## The Doctor

Before you do anything too radical, I would recommend that you go completely unstable. Mixing stable and unstable is generally a bad idea, and if you are mostly on the unstable branch then you system should be more stable by completely switching. If you are lucky, this is just a problem with mixing branches and will go away, if you are lucky.

Unfortunately, I don't have anything more relevant to suggest. I will say this: in the the past month I have had the only issue I have ever had on unstable, and all it required was a minor downgrade as the OS was still bootable. I have been running on the unstable branch for over a year.

----------

## Schol-R-LEA

Alas, I fear it is too late for any other solution; after upgrading the whole system, I ran emerge --depclean, and after that somehow GCC started failing. I don't see much choice other than to re-install at this stage.

----------

## cach0rr0

 *Schol-R-LEA wrote:*   

> Alas, I fear it is too late for any other solution; after upgrading the whole system, I ran emerge --depclean, and after that somehow GCC started failing. I don't see much choice other than to re-install at this stage.

 

balancing act. there's always a way to rebuild, even if it means having to fish things out of the tinderbox

tinderbox should be able to fulfill the role of fixing your toolchain; --depclean can be a bitch sometimes, I *always* pretend it, then unmerge items one by one. 

there's also the option of scrapping udev altogether in favor of mdev from busybox. The viability of which is entirely dependent upon your setup - the nuking of udev can be easy, but as time goes on i keep finding piddly things that need it (my reaction is always, "screw you, im not using udev, you just got unmerged!"). There's also the udev fork that may fit the bill. 

Food for thought, may well still be quicker/easier to just reinstall.

----------

## Wallsandfences

I have exactly the same problem (/sbin/udevd does not exist and udev can't start) with the funky exception that it *is* a fresh, (but unstable) install.

Did you sort your issue out?

Did it work to downgrad udev?

Rüdiger

----------

## Wallsandfences

udev-init-scripts17-r1 is blocking the downgrade, can I safely unmerge and re-emerge it?

----------

## cach0rr0

 *Wallsandfences wrote:*   

> udev-init-scripts17-r1 is blocking the downgrade, can I safely unmerge and re-emerge it?

 

yes, but, dont reboot. 

if you do, youll be having a bit of fun with your livecd and chrooting.

----------

