| Summary: | udev Timeout is too short | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Dave Hodgins <davidwhodgins> |
| Component: | RPM Packages | Assignee: | Colin Guthrie <mageia> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | critical | ||
| Priority: | Normal | CC: | dmorganec, doktor5000, etiennedau-site, filip.komar, mageia, mageia, oliver.bgr, pterjan, thierry.vignaud |
| Version: | Cauldron | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | udev | CVE: | |
| Status comment: | |||
| Bug Depends on: | |||
| Bug Blocks: | 4298 | ||
| Attachments: |
Fix the udev timeout setting
Screenshot showing timeout errors in VB |
||
|
Description
Dave Hodgins
2011-11-11 02:03:41 CET
Hi, thanks for reporting this bug. As there is no maintainer for this package, I add the 4 most committers, feel free to assign to the right people. CC:
(none) =>
dmorganec, mageia, pterjan, thierry.vignaud (In reply to comment #0) > > With Mageia 1 kde live cd, it takes about 15 minutes from selecting boot > to a usable desktop, under vb, on my single core i586 system. I am adding > the divider=10 kernel option. Well, here it does not take as long, testing on an core2duo p7450 under x86_64 in virtualbox with only 512mb ram assigned. Maybe more like 3 minutes. Would be interesting what causes this, no udev issue here ... Are you testing from cauldron or mga1 host? CC:
(none) =>
doktor5000 I'm using a Mageia 1 host, running the server kernel, with most services shutdown while virtualbox is running. Running a mageia 1 live kde under virtualbox is slow, but usable. Running an alpha 1 live cd under virtualbox won't boot due to the udev timeouts. How much RAM have you assigned to this virtualbox and what processor is that exactly? I'll also test gnome live cd and kernel-server to try to reproduce. The host has 2GB of ram. I've given the vb guest 768MB of ram. I have a single core i686 cpu which lshw shows as Intel(R) Celeron(R) CPU 2.40GHz The bios date is 03/18/2005 Fyi. I managed to boot the live kde iso once using the parameters divider=10 noacpi nolapic Repeating the same test a short time later fails with the udev timeouts. This bug still applies with todays updated pre-release alpha 1 iso images. This bug still applies in Mageia 2 alpha 2. Is there any way to override the udev timeout? I'm experiencing boot problems and udev timeouts as well in vbox with alpha2 pre release, but only with vbox. It's running like a charm on real hardware and in kvm. CC:
(none) =>
oliver.bgr The default is 180 seconds, but dracut is overriding it to 30 seconds. Source RPM:
udev-173-3.mga2.src.rpm =>
dracut Created attachment 1219 [details]
Fix the udev timeout setting
(In reply to comment #11) > The default is 180 seconds, but dracut is overriding it to 30 seconds. (In reply to comment #12) > Created attachment 1219 [details] > Fix the udev timeout setting Thanks, added dracut maintainer CC:
(none) =>
mageia Hmmm, I'm not sure about this... I don't think blindly setting the timeout higher is the right solution here. I think we need to find out *why* specifically this is needed and then do more to work out the correct way to fix it. If you have to increase the udev timeout here (especially beyond the default of 180) then something else is probably to blame and this just masks the issue. (In reply to comment #14) > Hmmm, I'm not sure about this... I don't think blindly setting the timeout > higher is the right solution here. I think we need to find out *why* > specifically this is needed and then do more to work out the correct way to fix > it. The reason it's timing out, is because I'm using a 6 year old single core i586 system, and running under VirtualBox. In that environment, I can run xp, or knoppix, or (once I get it installed, mageia 1). It's slow, but usable. Creating arbitrary timeouts for udev, without providing a method for the user to override it changes the system from slow, but usable, to completely non working. With Mageia 1, I have to use "startx VirtualBox", from run level 3, in order to get mkinitrd to run in less than the 10 minute timeout arbitrarily imposed by /usr/lib/libDrakX/run_program.pm. Using the "startx VirtualBox", the mkinitrd takes about 8 minutes. If I run it under kde, with my browser open on the host, it takes 18 minutes. Now, with the Magiea 2 alpha iso's, I cannot boot, because of the arbitrary limit imposed on udev, by dracut. I picked 300, instead of just removing the timeout, and letting it default to 180, as I don't know yet, how long is long enough. Ideally, whatever timeout is picked (if any), it should be over-ride-able with a kernel option.
Filip Komar
2012-01-13 07:42:17 CET
CC:
(none) =>
filip.komar
Manuel Hiebel
2012-02-06 14:47:03 CET
Blocks:
(none) =>
4298 Created attachment 1953 [details]
Screenshot showing timeout errors in VB
This bug still applies to the beta 3 pre-release iso images.
Hi, I can see the need for this right enough, but the previous example you gave would only set the timeout inside plymouth module. In actual fact udevadm settle is called from several places. I have a patch for udev which sets the default timeout, but there are still several places in dracut where it's called with a 30s timeout. I'd be tempted to suggest the timeout argument is just removed in dracut and we let the default values be used. I'll ask with Harald and Kay Status:
NEW =>
ASSIGNED I spoke to Kay and he said he was happy to accept a patch that allowed this to be set on the kernel command line. This time out trumps any provided on the command line. Just add "udev.settle-timeout=nnnn" to the kernel command line (value is in seconds). If you could test that it works and does what you need to (remember to rebuild your initrd first!) then I'll make sure it gets committed upstream. Are you referring to the timeout settings in dracut, systemd, or udev
itself?
The timeout shown in attachment 1953 [details] appears to be coming from the
systemd call to udev settle, but /lib/systemd/system/udev-settle.service
doesn't specify a timeout, so it looks like udev now defaults to 10
seconds, rather then the 120 specified in the man page.
I'll take a look at the udev source, and see if I can figure out what
needs to be changed.
Ignore comment 9. I see from the udev source that you've added the patch to udev. As it's booting the live cd under virtualbox, I'll try to rebuild the iso with the updated udev, but beta 3 may be ready sooner, as I've never rebuilt an iso before. Ahh yeah, sorry, that wasn't clear. Also I cocked it up. I didn't actually apply the patch to the udev package. I need to take it for a test run first but if it works OK, then I'll push it as udev-181-7. Source RPM:
dracut =>
udev Looks like it's resolved. Starting the live cd with udev.settle-timeout=180 divider=10 gets to the point where syslog shows startup finished in 19m 53s. I still get the x server crashing, and no getty terminals with which to get more info, but that's another bug. The udev timeouts are gone. Ooops. Forgot to close. Status:
ASSIGNED =>
RESOLVED |