FS#24288 - [udev] doesn't create LVM devices
Attached to Project:
Arch Linux
Opened by Alessandro Massignan (ff0000.it) - Sunday, 15 May 2011, 15:03 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 17 May 2011, 18:39 GMT
Opened by Alessandro Massignan (ff0000.it) - Sunday, 15 May 2011, 15:03 GMT
Last edited by Tom Gundersen (tomegun) - Tuesday, 17 May 2011, 18:39 GMT
|
Details
Description:
After last update during init scripts some weird messages began to appear, like: "bootlogd: cannot deduce real console device" and randomly: "fsck.ext3: No such file or directory while try to open /dev/sda3 Possibly non-existent device?" "/dev/sda3" is mounted as '/'. In addition, the init script that processes LVM section doesn't recognize any logical volumes (no relative devices are created under "/dev"). I use a custom kernel with no initrd image (since 4 years ago), in "/etc/rc.conf" USELVM is set to "yes" and i don't use any testing packages (besides a few on AUR, but they're not part of core packages). Additional info: * udev 168-1 * initscripts 2011.05.2-1 [/etc/fstab] /dev/sda2 /boot ext2 noauto,defaults 0 1 /dev/sda3 / ext3 defaults 0 1 /dev/sda5 swap swap defaults 0 0 /dev/sda6 /opt ext3 defaults 0 1 /dev/sda7 /tmp ext3 defaults 0 1 /dev/sda8 /usr ext3 defaults 0 1 /dev/sda9 /var ext3 defaults 0 1 /dev/vgff0000/home /home ext3 defaults 0 1 /dev/vgff0000/data /data ext3 defaults 0 1 Steps to reproduce: "bootlogd" error i can't reproduce it, because i don't know what it is :-) "/dev/sda3" error fired for about 3 times and then init works fine. LVM devices error (non detection) Temporary solution: I downgrade udev 168-1 to 167-2 and "/dev/sda3" and LVM devices creation seem solved. "bootlogd" isn't solved at all. Thoughts: I don't know if it's a bug or if last updates take archlinux to act not so good with my daily habit, you tell me ;-D |
This task depends upon
Closed by Tom Gundersen (tomegun)
Tuesday, 17 May 2011, 18:39 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in udev-168-2
Tuesday, 17 May 2011, 18:39 GMT
Reason for closing: Fixed
Additional comments about closing: Fixed in udev-168-2
bootlogd:
This is a new feature in this version of initscripts, the message means that for some reason it does not work on your system. Just ignore it. For details see "man bootlogd" (the BUGS section).
lvm:
This is a real bug, thanks for reporting!
Please try two things:
1)
After you booted, run
vgchange -ay
manually. Do the devices appear in /dev now? Any error messages?
2)
Could you edit your rc.sysinit to replace
/sbin/udevadm settle --quiet --timeout=${UDEV_TIMEOUT:-30}
with
/sbin/udevadm settle
Does this output anything during boot (if there is a problem at this point your boot might stall for a long time, please wait)?
I've got custom kernel, compiled from source, but it's been working for quite a lot of time without any problems.
1) With udev-168-1 after this message ("bootlogd: cannot deduce real console device") it sais that there's no /dev/sda3, then the root password prompt appears. I can boot into even 5 initlevel, but first i have to manually mount /boot,/home and remount / read-write. But seems that it can't open some serial devices like /dev/tty* - I'm having no terminal name in my bash prompt. All the block devices (/dev/sda*) are present in /dev.
2) right away
@Everyone who sees this problem with a custom kernel:
Could you please let me know what kernel version and attach your .config files? Also, please verify that your kernel satisfies the udev requirements: <http://git.kernel.org/?p=linux/hotplug/udev.git;a=blob;f=README;h=f85637068547d681c6b79686e9add05abf1d44ca;hb=HEAD> (including the required but not strictly needed ones).
@the rest of you: could you try with snigga's rc.sysinit?
Here's my kernel config.
"Could you edit your rc.sysinit to replace
/sbin/udevadm settle --quiet --timeout=${UDEV_TIMEOUT:-30}
with
/sbin/udevadm settle"
And now it's working.
If you don't mind I have a few more things I'd like to ask, just so we know exactly what the problem is (and wether or not it is upstream in udev or in initscripts).
So UDEV_TIMEOUT is not set in your rc.conf. This should not make a difference, but could you try to set UDEV_TIMEOUT=30?
If that does not make a difference I wondered if you could test which one of these that will work and which will not (then I think we will have it narrowed down):
/sbin/udevadm settle --timeout=30
/sbin/udevadm settle --quiet
Thanks so much for taking the time to hunt this down :-)
Anyone else?
i install udev 168-1 but the system is acting in the same way, i try with the following lines:
* /sbin/udevadm settle --timeout=30
* /sbin/udevadm settle --quiet
in /etc/rc.sysinit but it acts as "i udev (randomly) don't want to create the devices you'd
like"... :-|
I attach rc.conf and my .config... Kernel config seems fine but CONFIG_UNIX that i've as
module (@snigga: how is your?).
But I doubt that it's the key...
Could you try with the standard arch kernel to see if it can still be reproduced?
First, i noticed that bootlogd refused to load ("bootlogd: cannot deduce real console device") while the system loaded alright. After spending some time reading man i tried to adppend some options to the kernel
console=tty0, then console=tty1. Neither of it seemed to work, but again i got the message "failed to open the device /dev/sda3" instead. I managed to trigger the behaviour by "playing" with these kernel options and the rc.sysinit file (with the "/sbin/udevadm settle" part) until the system totally refused to boot, giving me the root password maintenance prompt. Then i added a line "sleep=10"
after this part:
/sbin/udevadm settle
fi
---here---
and the system started to load fine. There were no additional info messages though.
revert /etc/rc.sysinit back to original form (with --quiet and --timeout options set) and then i
reboot five times and the logical volumes have been found every time printing out the same notice:
/dev/mapper/vgff0000-home not set up by udev: Falling back to direct node creation.
/dev/mapper/vgff0000-data not set up by udev: Falling back to direct node creation.
The link /dev/vgff0000/home should had been created by udev but it was not found. Falling back to direct link creation.
The link /dev/vgff0000/data should had been created by udev but it was not found. Falling back to direct link creation.
2 logical volume(s) in volume group "vgff0000" now active
so i think the situation is not totally clear, but at least working.
i don't know what to do with bootlogd issue, may kernel option be involved? I have
CONFIG_UNIX98_PTYS=y and CONFIG_LEGACY_PTYS=n.
Thanks :-)
This has not been confirmed, but it looks like "udevadm settle" is somehow broken. If you add the sleep it will allow udev to settle, so that is why the problem is fixed. If you use devtmpfs then udev settles much faster anyway, so that is why only you guys with self-compiled kernels are seeing this problem.
If you are up to the task, I'm sure it would be much appreciated if you were to try compiling udev 168 from git, and see if the problem is fixed by reverting one or both of
commit ead7c62ab7641e150c6d668f939c102a6771ce60
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed Apr 20 02:18:22 2011 +0200
udevadm: settle - kill alarm()
commit a3eca08b19711bf6322e639ca2b2c81d91896a67
Author: Kay Sievers <kay.sievers@vrfy.org>
Date: Wed Apr 13 18:44:28 2011 +0200
udevadm: settle - watch queue file
And the bootlogd still refuses to work. Any ideas?
About bootlogd: try commenting out your /dev/pts line from fstab. If that does not work, please open a separate bug report against initscripts (as it is unrelated and much less critical ;-) ).
i've some work to finish, then (if sleep doesn't fall on me) i give a try to udev-git and pts.
scripts (with a little readapt), commented out devpts in /etc/fstab and rebbot: bootlogd
issues are gone (there's another i don't mention but it belongs to initscripts) and LVM2
vgs are detected and created as devices (still remain the notice "... not set up by udev:
Falling back to direct node creation... blah, blah, blah, ...").
So it seems almost resolved ;-D
Thanks mate!
Thanks a lot!
@tomegun: the issue during init is that mkdir find 2 pre-existent directories ("/tmp/.ICE-unix" and
"/tmp/.X11-unix") so i suppose it lacks of testing their existance or it's missing their deletion.
FS#24279.However, for this issue do we select CONFIG_DEVTMPFS, or CONFIG_DEVTMPFS_MOUNT, or both? Could we haven't to pay attention to messages like these (output of
"vchange" command in activate_vgs() of /etc/rc.d/functions):
/dev/mapper/... not set up by udev: Falling back to direct node creation.
/dev/mapper/... set up by udev: Falling back to direct node creation.
The link /dev/... should had been created by udev but it was not found.
Falling back to direct link creation.
The link /dev/... should had been created by udev but it was not found.
Falling back to direct link creation.
2 logical volume(s) in volume group "..." now active
? Last question: is this a real bug?!? I mean, to solve it we change only
our kernel configuration (going off the rails using a custom kernel instead
of the packaged one), so for what it concerns to me it was my "fault" ;-).
Thanks again for support! :-)
In fact, seems that you can't set CONFIG_DEVTMPFS_MOUNT without CONFIG_DEVTMPFS. I've set both and it works for me, don't know if CONFIG_DEVTMPFS alone is sufficient, haven't tested it.
these are the answers you wanted from the bug
FS#24272. Sorry it took so long, I was unavailable.1. Both
-- /proc/sys/kernel/hotplug
-- /sys/kernel/uevent_helper
are completely empty.
2. I use stock ARCH kernel
3. Replacing
-- /sbin/udevadm settle --quiet --timeout=${UDEV_TIMEOUT:-30}
with
-- /sbin/udevadm settle
made absolutely no difference in boot process or boot messages.
4. ** If you keep everything up to date, except downgrade udev, does that solve the problem? **
Yes, if everything is up to date with downgraded udev (and mkinitcpio, because it requires newest udev) everything works fine.
5. Again, I used and currently am using stock ARCH kernel.
Something I noticed that may or may not be useful: with udev 167 the system waited noticably longer on "waiting for udev events to be processed", like 2 seconds longer. I wonder if that wait period is the cause of USB drive not being recognized, or is it an udev bug like this one...
If the USB problems persist and you want to keep using USB at boot, then I can only suggest trying systemd (from community) as it does not rely on events to settle. There is however nothing we can do in initscripts due to the limitations of its design (it assumes all hardware is there at boot and never changes).
Could anyone still experiencing this (I guess it is only karabaja4 left?) try to see if this package solves the problem: <http://www.pps.jussieu.fr/~teg/udev-168-2-x86_64.pkg.tar.xz>? (I will upload the i686 version soon).
I notice that with this package my udev settle takes noticeably longer, so it is promising.
I have the problem with usbdisk at boot. I'm using i686 system. Waiting for a solution if possible :). Otherwise moving to systemd
The reason it takes longer is that before udev would not wait for the events to finish processing (that was the bug).