While trying to boot the alpha gnome live cd under virtualbox, it fails. 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. With the alpha gnome cd, it takes about 30 minutes to get to the point where it starts the acpid daemon, during which there are thousands of messages of udev timeouts, and udev killing things like modprobe, etc. After about 1 hour, the screen switches to graphical mode, with the mouse cursor shown. After 30 minutes with no keyboard (host+f12 etc) working, or mouse cursor movement, I shutdown the vb. Please increase the timeout. I'd like something like 900 seconds.
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.
*** Bug 3524 has been marked as a duplicate of this bug. ***
CC: (none) => etiennedau-site
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.
CC: (none) => filip.komar
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 => ASSIGNEDAssignee: bugsquad => mageia
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 => RESOLVEDResolution: (none) => FIXED