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.

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

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

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:

Code:

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._________________emerge --quiet redefined | E17 vids: I, II | Now using e from git | e18, e19, and kde4 sucks :-/

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

Code:

# ====================== 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

Code:

emerge -K udev

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

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

Now udev-181 has disappeared from the tree, and udev-182 is hard masked.
Are the Gentoo peeps sensing lots of users are about to break their systems?
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.

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

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_________________The best argument against democracy is a five-minute conversation with the average voter
Great Britain is a republic, with a hereditary president, while the United States is a monarchy with an elective king

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?_________________Whatever you do, do it properly!

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_________________.... there is nothing - absolutely nothing - half so much worth
doing as simply messing about with Linux ...
(apologies to Kenneth Graeme)

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.

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.

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.

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

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?_________________I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch.

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

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.

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.

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:

Code:

# 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