# udev update killed my system - HELP please :-(

## MitsukiP

Hello,

i have a very big problem. 

I made a update hours ago and there was this new udev-update (mask was removed). I read the info message about problems with /usr/ on a different parition and because of that i created a initrd-file with dracut. I don't use genkernel because i compiled all my kernel by myself.

But i can't boot with the initrd file, i only see this error:

```
dracut Warning: Unable to process initqueue"

dracut Warning: Unable to process initqueue"

dracut Warning "/dev/md3" does not exist

dracut Warning "/dev/md3" does not exist

Dropping to debug shell.

```

Then i tried it with my standard kernel, now i can see many error messages and missing files. Then i only see my root Paritition with many empty mountpoints. Funny, and i can't access any parition because mdraid/lvs is not working  :Sad: 

How can I fix this? I'm using Gentoo for many years now, but that's the first time i'm stuck. I have no idea what i should do now.

I can't emerge a old udev-version, i can't fix the initrd-file, i can't to anything  :Sad: 

I already read https://forums.gentoo.org/viewtopic-t-901206-highlight-udev.html but didn't really help. There was no line with "initramfs=" in my config, i added a initramfs="no" but still the same problem. udev was already in the sysinit runlevel.

Btw, I have /var/ /usr/ /home/ ... on different partitions.

Thanks

Stuck by NeddySeagoon

----------

## BillWho

MitsukiP,

My system fried last evening.   :Crying or Very sad: 

I'm not sure if this will work for you, but what I did as a temporary fix is mask =x11-drivers/xf86-input-evdev-2.7.0 and =x11-base/xorg-server-1.12.0 then rebuild x11-drivers

```
emerge -av $(qlist -IC x11-drivers) 
```

Hope this helps you    :Wink: 

----------

## MitsukiP

I think my problem is bigger, i can't access my hard disks atm and not sure why, because my system don't detect the raid and the lvm  :Sad: 

----------

## MitsukiP

Hello again, 

i chrooted my system, masked >=sys-fs/udev-181, emerged it and tried to restart my system.

First i just saw a kernel panic, because my /mnt/md3 is now a /mnt/md122 and my /mnt/md3 is now /mnt/md127 (why?)

I changed the entries in /etc/fstab and /boot/grub/grub.conf and the system is booting. But now with many new errors.

```
Starting udev ...

Populating /dev with existing devices through uevents ...

Waiting for uvents to be processed ...

udev[xxx]: failed to execute '/sbin/modprobe' ....

```

I see dozens of missing modprobe-messages, my network is not working, no env-vars, no modules loaded...

But why? After the boot /sbin/modprobe is there and working.

Now my system is broke and i have no glue what i should do now  :Sad: 

I just want my old pre-emerge system back, everything was working fine for years, and now it's broke...

Thanks

----------

## ppurka

Just some questions for you to think about:  :Smile: 

1. Did you update your configs in /etc after the downgrade?

2. Did you try to get your system to the state before this latest upgrade? For this look at the output of genlop, for example:

```
genlop -l -u --date 2 days ago
```

Then revert all the packages to their versions before the breakage, and then update the configs in your /etc.

----------

## BillWho

MitsukiP,

Don't know about the mdraid/lvs mounting but I had a message after the update about DEVTMPFS_MOUNT having to be set! Could that be it?

Good luck   :Wink: 

----------

## NeddySeagoon

This problem arisies now because udev tries to run binaries and scripts located in /usr before /usr is mounted.

/var is a lesser problem, udev tries to restore your mixer settings from /var before its mounted too.

Until udev-181, there was some code that tolerated this and tried to redo items that failed the first time.

The immediate solution is to mask udev-181 until you have time to sort out the mess.

When you miss that opportunity the fallback is to boot a livedCD/USB/DVD ... chroot into your broken install and downgrade udev to a version less than 181, so you have the fallback code once more.  This is not a long term soloution. Its just a get you going so you can migrate in your own time.

I've been there and been bitten too.  Now all of my raid minor numbers have been scrambeld by booting with SystemRescueCD too.

If you want to make an initrd by hand, looks sane, it does not include raid and lvm2 supprt but if you have an initrd for that already, it looks like its easy to include.

Hint raid assembly and lvm starting goes in the init script at 

```
# ====================== start doing stuff
```

As a hand made initrd puts everything under your control and allows you to understand whats happening, its the least worst way ahead.

I use ~ARCH everywhere, because of that, I have buildpkg set in my FEATURES so for me the downgrade was mask udev-181 

```
emerge -K udev
```

and fix grub.conf after I found out the hard way the my raid minor numbers had been trashed.

----------

## Thistled

Now udev-181 has disappeared from the tree, and udev-182 is hard masked.   :Surprised: 

Are the Gentoo peeps sensing lots of users are about to break their systems?   :Rolling Eyes: 

I have masked udev-181 and above until some sort of documentation or wiki / walkthrough appears on the internet.

I would advise other Gentoo users (whom like myself) who are not up to speed with the whole concept of all things Gentoo, to do the same.

Had a little dabble today trying to update to udev-181, and experienced warnings about removing "module-init-tools" and lots of file collisions with regards to udev rules.

So not going anywhere on this system until it's all settled down. I don't have /usr on a separate partition either, so I presumed the upgrade would be quite inncocent. But no go for me.   :Confused: 

Edit: So the on-line package database says [M] but portage says it is [~], but, nonetheless, udev-181 has gone.

----------

## Naib

yup I just got bit by this.

I just modprobe my nic driver, brought up eth0 and emerge the older version without the need to boot of a liveCD

I also do not have /usr partition so was VERY surprised when this bit me

----------

## Thistled

I didn't get past the upgrade of udev (or to be precise the udev-init-scripts part of it) because of this:

```
Detected file collision(s):

   /lib/udev/net.sh

   /lib/udev/write_root_link_rule

   /lib/udev/rules.d/90-network.rules

   /lib/udev/rules.d/40-gentoo.rules

Searching all installed packages for file collisions...

Press Ctrl-C to Stop

sys-fs/udev-171-r5

   /lib/udev/net.sh

   /lib/udev/rules.d/40-gentoo.rules

   /lib/udev/rules.d/90-network.rules

   /lib/udev/write_root_link_rule

Package 'sys-fs/udev-init-scripts-9' NOT merged due to file

collisions. If necessary, refer to your elog messages for the whole

content of the above message.

```

So in a situation like this, should I just unmerge udev BEFORE beginning the upgrade process?

And would that not be a dangerous thing to do? Removing udev and module-init-tools?

----------

## albright

 *Quote:*   

> So in a situation like this, should I just unmerge udev BEFORE beginning the upgrade process? 

 

the udev situation right now seems to be a total c***-up but

I think unmerging udev would be suicide

----------

## Jaglover

I just moved those files away to avoid collision (and deleted later).

What I really didn't like there were some warnings printed about missing kernel features (fatal), yet emerge carried on with udev upgrade.

----------

## gorkypl

 *Jaglover wrote:*   

> 
> 
> What I really didn't like there were some warnings printed about missing kernel features (fatal), yet emerge carried on with udev upgrade.

 

It was discussed way back in 2005 IIRC.

User should not be forced to upgrade kernel before upgrading udev - instead, everyone is expected to read the postinst messages, especially warnings.

Furthermore, breaking udev build process with missing kernel features detected would not save you in situation where you have built a new kernel but forgot to move it into /boot, so still attention is needed.

----------

## HMC

I was also bitten by this one... chrooted in from a rescue cd, issues with lvm and crypt use flags (saw them on the original update. but were still correct, but different behaviour the second time around), fixed a couple of small issues around the USE flags (particularly static), rebuilt packages, paid attention to output notes, rebuilt the kernel with the correct options (note in there somewhere about the initramfs too) and genkernel (also updated - check the config), updated the init and conf files before rebooting (important- forgot that the first time) and it worked.

I don't really remember too much about the details - it has been done.

The next system that I did was a little hardened netbook and it went off without any issues - it was just a little more work than usual. Likewise the update to udev-182 and beyond (currently r2) went smoothly.

Then a couple of servers...

I reckon that I got bitten the first time because I was lazy and half assed on the update and wouldn't have been bitten if I had followed the notes in the output that the devs are so good to provide (which was ultimately used to fix it) and paid a little attention to the details. I didn't think that there was a bug there and I didn't even bother checking bugzilla or the forums. I put it down to idiot error.

Not saying it is like this for everyone... but it certainly was me.

----------

## Etal

 *Jaglover wrote:*   

> What I really didn't like there were some warnings printed about missing kernel features (fatal), yet emerge carried on with udev upgrade.

 

It was actually done like that originally, but then reverted. From the ChangeLog:

 *ChangeLog wrote:*   

>   19 Mar 2012; William Hubbs <williamh@g.o> udev-181.ebuild, udev-9999.ebuild:
> 
>   Revert making the CONFIG_DEVTMPFS check fatal. Checking for kernel config
> 
>   options cannot be fatal because it breaks build hosts. See
> ...

 .

----------

## manny15

I just recovered my broken system. I thought I paid attention to the emerge output and took care of things, but I must have missed something. 

When I rebooted after the upgrade something about a missing kernel config displayed on the screen, then some other error, and then the screen went blank. The monitor alerted me there wasn't a signal coming from the PC.

Once I was able to access /var/log/rc.log I found I was missing CONFIG_DEVTMPFS=y. I'm guessing the other missing config is CONFIG_DEVTMPFS_MOUNT=y.

I learned a long time ago, from a failed upgrade like this one, to do a backup first. My rootfs is on an LVM2 volume. Since I still had the snapshot read-only volume I had backed up from, I booted from a Gentoo LiveCD, formatted the rootfs, and cp --archive'ed from the backup read-only volume to the brand new rootfs volume. I didn't have to use the actual backup tarball. I rebooted and now I'm back pre-disaster. I'll try the upgrade again later.

----------

## hunky

I'm dead right now.. actually booted into rescuesystemcd. I had a trilogy of errors that cause my trouble. First was I had set portage (emerge) warnings to be emailed to me using an smtp username that was deactivated recently without me realizing it - so I wasn't getting emailed any warnings. Next thing was during the emerge world I got a fail on coreutils. I resumed the emerge but that seems to erase any previous warnings when emerge finishes. So no warnings in the shell. I did update all conf files. Third error was before I started the emerge, on an emerge -avuND @world, before I hit yes, I did see a warning about the upgrade to udev-182 (I'm on unstable) but it seemed to apply only if you had /usr on its own partition. Since I have  /boot, /, /home, /swap, I didn't think to worry about it. That was third error.

Now when booting (which doesn't complete) I see udev errors during boot but they go by too fast to read - it is obviously not finding some things. Not sure what to do next - will try manny15's ideas on kernel config. I just looked in the emerge log and see: ERROR: setup

  CONFIG_DEVTMPFS:	 is not set when it should be.

WARN: setup

So looks like I will chroot in and rebuild the kernel. Also remove the 70-persistent-net.rules (or whatever it is named) as I saw errors on network when booting.

off to chroot now.  /jd

[edit] ok - that worked. Enabled the CONFIG_DEVTMPFS and ...DEVTMPFS_MOUNT. When booting saw some errors about the udev rules beginning with the number 10 - have to look into that. Hopefully back in the saddle.  /jd

----------

## FizzyWidget

How would i update my initramfs to deal with the change to udev and everything having to be on /

here is my initramfs

```
#!/bin/sh 

mount -t proc proc /proc 

mount -t sysfs sysfs /sys 

mount -t devtmpfs devtmpfs /dev 

#for a french azerty keyboard 

loadkmap < /etc/kmap-fr 

rescue() { 

   echo "Dropping to rescue shell" >&2 

   /bin/sh </dev/tty1 >/dev/tty1 2>&1 

} 

/bin/cryptsetup luksOpen /dev/sda2 vault || rescue 

/bin/lvm pvscan || rescue 

/bin/lvm vgscan || rescue 

/bin/lvm vgchange -ay vg || rescue 

mount -r /dev/mapper/vg-root /newroot || rescue 

CMDLINE=`cat /proc/cmdline` 

umount /dev 

umount /sys 

umount /proc 

exec /bin/busybox switch_root /newroot /sbin/init ${CMDLINE}
```

i tried adding mount -t ext4 /dev/mapper/vg-usr but that didnt work, should i do as most people seem to have suggested in various paces and mask the 1.8.x series?

----------

## steveL

 *MitsukiP wrote:*   

> I already read https://forums.gentoo.org/viewtopic-t-901206-highlight-udev.html but didn't really help. There was no line with "initramfs=" in my config, i added a initramfs="no" but still the same problem. udev was already in the sysinit runlevel.
> 
> 

 

Er if you're going to use that solution, you need to patch two udev initscripts (/etc/init.d/udev-mount and /etc/init.d/udev) as outlined in the topic, to do something with the new parameter. (And udev has to move to boot runlevel, with udev-mount and sysfs added to sysinit- they are normally depended on by udev so start automatically in that runlevel.) Note that I haven't tested this against udev-181+, as I'm on stable; it's likely that the patch would need to change for a newer version.

edit: remove link to earlymounts initscript as it seems to be dead.Last edited by steveL on Fri Nov 09, 2012 9:10 pm; edited 1 time in total

----------

## DaveDay

About a year ago my wife's Windows XP machine that she uses for medical transcription  broke and, having a couple spare dual processor boxes lying about, to save time I just gave her my workstation and transferred her hard drive to it and off she went.  I transferred my Gentoo drives to a slightly older and less powerful box and we have been carrying on like that ever since.  

Well we were given a new machine this week and so we put her drive in the new box and she is quite happy, and I get my original workstation back.  Sounded good.

Except that now my Gentoo disks won't boot on my original workstation that I had Gentoo on for several years before.

It did indeed turn out that I was hit by the CONFIG_DEVTMPFS issue but that was only a small part of it.  I used a rescue CD and rebuilt the kernel with CONFIG_DEVTMPFS and the "CONFIG_MOUNT_DEVTMPFS (or similar, don't have it handy) but the problem remained.

I took all the cards (USB, NVidia video, SB Audigy, Enet) out and activated the motherboard equivalents to shake up the HW boot environment some, but the behavior remained.

The machine stops booting just after the "Populating /dev by uevents" message.  

Getting desperate, I decided to just reinstall from the March 2012 minimal install disk and low and behold........it behaves exactly the same way!  So I tried MythBuntu's latest CD ........ they can't boot that machine either.   Puppy Linux did boot just fine and it has been a life saver, allowing me to get to the internet and google around for ideas.

So, realizing that it is at least in part a HW issue, I put everything back in  the older Dual processor  and I am more or less back in business.  I have a remaining locking issue that is stopping LVM2 from coming up and Apache2 is complaining about a configuration issue with PHP but I am guessing those are just the usual day to day adventures you get from running ~x86.

So, beware, there are apparently some hardware gotchas out there that will completely hose udev.  I went back to udev 171 and still had the issue.  Earlier than that and I started getting dependency problems and I didn't want to go down that road right now so I stopped at 171.  I have no idea what the issue is but hopefully the devs will figure out how to just spit out a warning and leave something unconfigured rather than allowing the machine to just freeze.

So far the only solution I found was switching to another box.

Cheers,

Dave

----------

## gorkypl

 *DaveDay wrote:*   

>  I have a remaining locking issue that is stopping LVM2 from coming up 

 

I can help you with this one, probably. Just set locking_dir = "/dev/shm/lvm" in /etc/lvm.conf

https://bugs.gentoo.org/show_bug.cgi?id=409921

No idea about the problem with udev however...

----------

## thorbenk

Hello all,

I have /usr on an LVM volume and am running ~amd64. After the upgrade to udev-182, I built a initramfs with dracut, which did not work however. I could not boot my system anymore.

For the time being, I just want to downgrade to a working udev again.

I chrooted into the system and downgraded udev and dependencies to the following packages:

udev 171-r5

consolekit 0.4.5-r2

usbutils 005

pciutils 3.1.9-r1

Still, I get the same error on boot, that /usr is not there. What could possibly be still wrong?

Any help would be tremendously appreciated!

Thanks,

Thorben

----------

## sDoky

Hi, I have upgraded to udev-181-r2 with testing pciutils and usbutils. After doing so I was completely unable to connect to any wireless network. I have intel agn in my thinkpad t420. Downgrade does not help. The issue still remains. I have reverted everything the help of genlop. And also I have updated all the config files.

```
[   29.961228] br0: no IPv6 routers present

[   31.213676] wlan0: authenticate with 02:1b:b1:02:80:cf (try 1)

[   31.216911] wlan0: authenticated

[   31.217904] wlan0: associate with 02:1b:b1:02:80:cf (try 1)

[   31.222691] wlan0: RX AssocResp from 02:1b:b1:02:80:cf (capab=0x421 status=0 aid=1)

[   31.222694] wlan0: associated

[   31.228837] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready

[   31.244962] wlan0: deauthenticating from 02:1b:b1:02:80:cf by local choice (reason=3)

[   31.253455] cfg80211: All devices are disconnected, going to restore regulatory settings

[   31.253461] cfg80211: Restoring regulatory settings

[   31.253472] cfg80211: Calling CRDA to update world regulatory domain

[   35.391933] wlan0: authenticate with 5c:da:d4:76:20:58 (try 1)

[   35.394690] wlan0: authenticated

[   35.395708] wlan0: associate with 5c:da:d4:76:20:58 (try 1)

[   35.398412] wlan0: RX AssocResp from 5c:da:d4:76:20:58 (capab=0x411 status=0 aid=1)

[   35.398417] wlan0: associated

[   35.437614] wlan0: deauthenticating from 5c:da:d4:76:20:58 by local choice (reason=3)

[   35.476196] cfg80211: All devices are disconnected, going to restore regulatory settings

[   35.476204] cfg80211: Restoring regulatory settings

[   35.476219] cfg80211: Calling CRDA to update world regulatory domain

[   42.458096] wlan0: authenticate with 00:12:0e:51:fc:97 (try 1)

[   42.657380] wlan0: authenticate with 00:12:0e:51:fc:97 (try 2)

[   42.660229] wlan0: authenticated

[   42.660475] wlan0: associate with 00:12:0e:51:fc:97 (try 1)

[   42.860075] wlan0: associate with 00:12:0e:51:fc:97 (try 2)

[   42.862638] wlan0: RX AssocResp from 00:12:0e:51:fc:97 (capab=0x401 status=0 aid=5)

[   42.862643] wlan0: associated

[   42.862646] wlan0: invalid AID value 0x5; bits 15:14 not set

[   42.884499] wlan0: deauthenticating from 00:12:0e:51:fc:97 by local choice (reason=3)

[   42.903129] cfg80211: All devices are disconnected, going to restore regulatory settings

[   42.903137] cfg80211: Restoring regulatory settings

[   42.903145] cfg80211: Calling CRDA to update world regulatory domain

[   49.397765] wlan0: authenticate with 00:1b:b1:02:80:f4 (try 1)

[   49.402537] wlan0: authenticated

[   49.402762] wlan0: associate with 00:1b:b1:02:80:f4 (try 1)

[   49.415144] wlan0: RX AssocResp from 00:1b:b1:02:80:f4 (capab=0x421 status=0 aid=1)

[   49.415148] wlan0: associated

[   49.438922] wlan0: deauthenticating from 00:1b:b1:02:80:f4 by local choice (reason=3)

[   49.449379] cfg80211: All devices are disconnected, going to restore regulatory settings

[   49.449386] cfg80211: Restoring regulatory settings

[   49.449393] cfg80211: Calling CRDA to update world regulatory domain

[  159.487260] wlan0: authenticate with 5c:da:d4:76:20:58 (try 1)

[  159.489108] wlan0: authenticated

[  159.490605] wlan0: associate with 5c:da:d4:76:20:58 (try 1)

[  159.493362] wlan0: RX AssocResp from 5c:da:d4:76:20:58 (capab=0x411 status=0 aid=1)

[  159.493365] wlan0: associated

[  159.538204] wlan0: deauthenticating from 5c:da:d4:76:20:58 by local choice (reason=3)

[  159.561769] cfg80211: All devices are disconnected, going to restore regulatory settings

[  159.561775] cfg80211: Restoring regulatory settings

[  159.561785] cfg80211: Calling CRDA to update world regulatory domain
```

Can you please point me the correct direction?

----------

## thorbenk

 *thorbenk wrote:*   

> Hello all,
> 
> I have /usr on an LVM volume and am running ~amd64. After the upgrade to udev-182, I built a initramfs with dracut, which did not work however. I could not boot my system anymore.
> 
> For the time being, I just want to downgrade to a working udev again.
> ...

 

So, the problem seems to have been an unrelated update of lvm2, see bug https://bugs.gentoo.org/show_bug.cgi?id=409921

Once I reverted to the previous version, I got my computer to boot again.

----------

## steveL

If you are using lvm, I very much recommend using /dev/mapper/vg-lv in your /etc/fstab rather than /dev/vg/lv. The /dev/mapper/vg-lv links are made by lvm. BTW you need CONFIG_DEVTMPFS for this, but it's required now for udev; CONFIG_DEVTMPFS_MOUNT is also useful, should you ever need to boot into a rescue shell (it means /dev will automatically be mounted by the kernel, which means the /dev/mapper links will be available however you start your machine.)

If you check /etc/init.d/udev in the populate_dev() function, you'll see the following comment:

```

# we can speed up booting under these conditions:

#  * using devtmpfs so kernel creates device nodes for us

#  * only using kernel created device nodes at boot

# (in /etc/fstab and elsewhere)

```

/dev/mapper, and directories below it, are lvm-created nodes, which need device-mapper built into kernel, if lvm is not started in an initramfs.

edit: lvm creates nodes, not kernel.Last edited by steveL on Mon Jun 11, 2012 9:23 pm; edited 1 time in total

----------

## audiodef

Good, this isn't just me. Someone decided it would be fun to drop a bomb down the pipe. 

You have to boot in with sysresccd or some such, chroot, and configure your kernel to enable devtmpfs. Make sure you etc-update or dispatch-conf, too. 

Well, this is one possible way. I had three machines fire-bombed by this udev party-killer, and that's how I fixed it. 

Note: just enable devtmpfs. Don't enable the keep-mounted or whatever option just under that.

----------

## steveL

 *audiodef wrote:*   

> Note: just enable devtmpfs. Don't enable the keep-mounted or whatever option just under that.

 

That does work fine, since udev-mount (which is needed by udev in sysinit) mounts /dev from devtmpfs if it can; but it'll also work fine with CONFIG_DEVTMPFS_MOUNT (you just get an ok message saying /dev is already mounted.)

Having it enabled just makes things easier when you have a problem booting and start a rescue shell/ single-user mode, especially if you have lvm partitions, since they will now be accessible under their kernel names. (And if you have them listed under those in /etc/fstab then they can easily be mounted with mount -a.)

=======

Summary:

=======

If you have /usr and/or /var on a separate partition (including lvm) and you don't currently have an initramfs, then your options are:

1) The supported route: Setup an initramfs.

2) Use a couple of patches to openrc initscripts to make udev start after localmount.

3) Use sys-apps/eudev

Potentially the list of required partitions could include /opt if third-party drivers or support scripts are installed there (or directories are read or written to by the same.)

----------

## dustfinger

Hi,

I have /usr on its own partition. I have been so busy that I have been dealing with this udev issue by simply not rebooting my system - LOL! I finally got around to setting up initramfs to mount /usr early. To do this I chose to follow The Gentoo Wiki - Early_Userspace_Mounting. When I rebooted I was presented with an error that was similar to:

```
803 on /mnt/root failed
```

It also complained that the file or directory did not exist. Eek! Well, this error dropped me to the rescue shell thank goodness. So I mounted root manually and also mounted /usr and /boot. This gave me:

```
/mnt/root

/mnt/root/usr

/mnt/root/boot
```

I then chroot /mnt/root (Note that the chroot is necessary for the repackaging of the image to work) and edited the /usr/src/initramfs/init provided in the wiki mentioned above. There is a function in that script called uuidlabel_root. I commented out everything in that function and replaced it with an explicit mount to my root. This happens to be:

```
mount -o ro /dev/sda5 /mnt/root
```

I don't really understand why the fancy method which detects the correct device node for root was failing, but an explicit mount for my particular system got me up and running. After making that change I followed the instructions to re-package the image on boot and then rebooted my system. I am happy once again.

This is really just an FYI to anyone following that wiki.

By the way, how will we be informed when udev is fixed. I will want to get rid of this initramfs hack once it is no longer required.

Sincerely,

dustfinger.

----------

## DaggyStyle

 *dustfinger wrote:*   

> Hi,
> 
> I have /usr on its own partition. I have been so busy that I have been dealing with this udev issue by simply not rebooting my system - LOL! I finally got around to setting up initramfs to mount /usr early. To do this I chose to follow The Gentoo Wiki - Early_Userspace_Mounting. When I rebooted I was presented with an error that was similar to:
> 
> ```
> ...

 

using latest stable udev-197, /usr on separate partition, no initramfs and system boots.

----------

## chris972

My OpenVZ Kernel doesn't contain DEVTMPFS option, so, what can I do plz ?

----------

## dustfinger

Hi chris972,

According to DaggyStyle the latest stable version of udev is no longer affected by this issue. You no longer need to mount the /usr partition early using initramfs. I have not tried to remove my initramfs yet, nor have I looked at the bug reports to see exactly when the fix was made for udev. I am just so darn busy all of the time  :Razz: 

Best of luck!

Sincerely,

dustfinger.

----------

## chris972

Well... My english is not very good but i'll try to explain.

I haven't /usr separate, but i have an openvz kernel. And openvz kernel doesn't have DEVTMPSFS option.

So, I can't update udev.

For the moment, this works, but how long ?

What will I have to do when udev update will be required to maintain all my system ?

Have I to forget openvz ?

This situation is not good at all.

----------

## SamuliSuominen

 *chris972 wrote:*   

> Well... My english is not very good but i'll try to explain.
> 
> I haven't /usr separate, but i have an openvz kernel. And openvz kernel doesn't have DEVTMPSFS option.
> 
> So, I can't update udev.
> ...

 

How do you mean? The release of 2.6.32:

http://lwn.net/Articles/364927/

Says:

"Linus has released 2.6.32 on the usual "right after LWN publishes its weekly edition" schedule. Some of the more significant features in 2.6.32 include devtmpfs"

And when I look at latest openvz-sources in tree, it says:

sys-kernel/openvz-sources-2.6.32.72.10

Then I extracted the source tarball and grepped though the source tree, and DEVTMPFS is mentioned dozens of times.

And when I look at latest required kernel of the udev-197-r8 ebuild:

2.6.32

If you can't use the oldest stable series from http://www.kernel.org/ then you have much bigger problems than just udev.

----------

## chris972

I don't understand all what you mean, my english is really too bad, but, I'm certain openvz doesn't contain devtmpfs, and a lot of users are not happy with that.

You should look openvz kernel sources better :

```
# grep -A2 "config DEVTMPFS" ./drivers/base/Kconfig

config DEVTMPFS

        bool "Create a kernel maintained /dev tmpfs (EXPERIMENTAL)"

        depends on HOTPLUG && SHMEM && TMPFS && !VE

--

config DEVTMPFS_MOUNT

        bool "Automount devtmpfs at /dev"

        depends on DEVTMPFS

```

The "!VE" makes all the difference. You CAN'T activate it with openvz, because devels consider OpenVZ can't work with DEVTMPFS.

----------

## SamuliSuominen

 *chris972 wrote:*   

> I don't understand all what you mean, my english is really too bad, but, I'm certain openvz doesn't contain devtmpfs, and a lot of users are not happy with that.
> 
> You should look openvz kernel sources better :
> 
> ```
> ...

 

OK, I stand corrected. I'm afraid your only option is to copy old sys-fs/udev to local overlay then, along with sys-apps/module-init-tools.

The OpenVZ developers need to fork udev if they don't plan in supporting DEVTMPFS. Crazy as it sounds.

----------

## chris972

 *ssuominen wrote:*   

> I'm afraid your only option is to copy old sys-fs/udev to local overlay then, along with sys-apps/module-init-tools.

 

You mean in its actual version that doesn't require devtmpfs, so 171 ?

But, when my gentoo will require udev > 171, what will be my situation ?

 *Quote:*   

> The OpenVZ developers need to fork udev if they don't plan in supporting DEVTMPFS. Crazy as it sounds.

 

Or udev devel to find a solution to not require devtmpfs...

Thanks for your help.

----------

