Summary: | sys-fs/udev-168-r1 breaks dmcrypt | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mark <mark.morschhaeuser> |
Component: | [OLD] Core system | Assignee: | udev maintainers <udev-bugs> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | bj.rn, bjlockie, bug, denys.duchier, eugene.shalygin, hilco.wijbenga, laborer2008, nikoli, pawel.tomkiel, realnc, retired_user, rzubaly, stefano, tomas |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 361349 | ||
Bug Blocks: | 367949 |
Description
Mark
2011-05-02 08:17:00 UTC
I confirm this. This started happening with 168-r1, it was not an issue before. I confirm this too. I did not create /run directory, it just fallback to /dev/.udev and X is still working properly. That error message at startup is annoying. *** This bug has been confirmed by popular vote. *** Yeah, this message is annoying. before udev did fall back to /dev/.udev, and did not announce this. So do we want to downgrade that message to be just info or warning, as we do not want to force baselayout into creating /run if it is not strictly necessary. Still udev support needs to be improved, as some scripts have /dev/.udev hardcoded that must be replaced by $(udevadm info --run). @baselayout: What are the plans about supporting /run directory in baselayout and openrc? I saw openrc-git contains code to mount a tmpfs to /run if it exists. So all udev scripts need to work with /run instead and udev also needs to work with an udev database coming from udev out of an initramfs. (there is a new command in udevadm: # udevadm info --cleanup-db that is to clean the database from udev of initramfs. commit introducing it: http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=9ead662791b5e59a95b6c5a9351d661cb61d76bb udevadm: info --cleanup-db Most of the udev database from initramfs should be deleted before starting udev in the real root. udevadm: info --cleanup-db deletes all database entries in /run/udev. Events that processed IMPORT{db}, or mark devices explicitely as persistent, will be excluded. *** Bug 365843 has been marked as a duplicate of this bug. *** Just to get it working for now I changed rc of baselayout 1 like this: $ sudo nano -w /sbin/rc ... # Actually start setting up /dev now if [[ ${udev} == "yes" ]] ; then mount tmpfs /run -t tmpfs -o size=40m start_addon udev ... After reboot udevd is using the new place to store its database: $ udevadm info --run /run/udev (In reply to comment #7) > Just to get it working for now I changed rc of baselayout 1 like this: > $ sudo nano -w /sbin/rc > ... > # Actually start setting up /dev now > if [[ ${udev} == "yes" ]] ; then > mount tmpfs /run -t tmpfs -o size=40m > start_addon udev > ... > > After reboot udevd is using the new place to store its database: > $ udevadm info --run > /run/udev "To get it working"? It does work as before, it just prints this annoying warning. I meant to get it working in the new path, sorry :), not necessary at all My system does not have a /run directory and anyways after the upgrade I have broken X input devices. Booting into single mode, restarting udev and then starting xdm does not solve the problem for me. #10: Do "emerge x11-drivers/xf86-input-evdev x11-drivers/xf86-input-keyboard x11-drivers/xf86-input-mouse x11-drivers/xf86-video-fbdev x11-drivers/xf86-video-glint x11-drivers/xf86-video-nv x11-drivers/xf86-video-vesa" I suggest you to run: emerge -av $(qlist -I -C x11-driver) Don't do that. (In reply to comment #12) > I suggest you to run: > emerge -av $(qlist -I -C x11-driver) It should be "-a1v", not "-av". I'd prefer to have them in world set. I now removed that warning message, so the boot looks nicer. Er, wouldn't it be more correct to have a /run tmpfs mounted at boot? (In reply to comment #17) > Er, wouldn't it be more correct to have a /run tmpfs mounted at boot? Even if upstream decides that run is the better way, udev on gentoo should not print ugly errors on boot screen, if it is working fine. And I think it will take some time until we get a stable openrc that unconditionally mounts /run. So the removal of this warning is not related to adding /run support. I don't know whether this is caused by the changes in udev-168-r2, but as soon as I do have a /run/udev directory, X input devices do not work until I remove it. I removed this directory manually, but after updating to 168-r2 it was there again, and after the next reboot I had a X login screen with no working input devices. Which is not really good. The only possibilities then are to either reboot in interactive mode, reboot in single user mode or hope that Magic SysRQ is in kernel and SyrRQ+R works. So, if there is any logic that creates this directory in r2: Please do not do this until this bug is solved in a clean matter, as it might leave people, as me, with a non-working X after a reboot. Kind regards, Christian udevd creates and uses /run/udev as soon as /run does exist. And the only place in gentoo I have seen that uses /run is some code in openrc that is not yet in any released version. But there should be no code that does create /run itself, so when it does not exist it should not auto-appear. I split these two issues into two bugs. This bug #365679 for the dmcrypt issue and bug #367949 for the X11 issue This should be fixed with current versions. Try at least udev-196-r1 and up-to-date lvm2 and cryptsetup. Reopen the bug if the issue persists. Thanks! |