You are not logged in.
Pages: 1
When I boot my system there is a +/- 80% chance that the boot process stops at the message: "Loading UDev uevents... [busy]". This is not a big issue, because I can just reset the computer and try again. But it is annoying. When loading UDev uevents is successful (20% chance) everything works fine.
This problem started just a few days ago. I have a new SATA-II harddisk installed and I have moved some partitions to this new harddisk. I've build a new kernel (I compile the kernel myself) with SATA and SCSI capabilities built in. Like I've said above, when the boot process is successful, everything works fine.
Is there a solution for this?
Offline
I have this issue also. I think it does have to do with custom kernels as I'm running 2.6.18-emission2. The only thing I can think of is that the initramfs(or whatever it's called) image which I think houses some udev component(I think it's klibc-udev thingy ), doubt that should stop/pause/freeze it though. I could be wrong
Offline
I have this issue also. I think it does have to do with custom kernels as I'm running 2.6.18-emission2. The only thing I can think of is that the initramfs(or whatever it's called) image which I think houses some udev component(I think it's klibc-udev thingy ), doubt that should stop/pause/freeze it though. I could be wrong
Before the new harddisk I've already used a self-compiled kernel 2.6.18-ck1... and I didn't have this problem then. This problem started after the new harddisk and some changes in the kernel config to make the kernel work with SATA and SCSI.
Another thing, my /usr/* path is not on the boot partition... is that a problem? Are there any binaries or libraries that is needed to load the UDev uevent that are in the /usr path?
Offline
Maybe I solved the problem:
I had 'noatime' as a mount option in my /etc/fstab for the root partition.
After removing this option loading UDev uevent never stops.
was:
/dev/hda2 / ext3 defaults,commit=10,data=writeback,noatime 0 1
changed to:
/dev/hda2 / ext3 defaults,commit=10,data=writeback 0 1
Hope this helps for you too.
Offline
Nope the problem is back again.
Now I have changed the /etc/start_udev script. Loading udev uevent doesn't hang anymore, but I don't know if the change has other effects.
/etc/start_udev after the change:
function wait_for_queue() {
loop=20
while ! [ "$loop" -gt 0 -a -d /dev/.udev/queue ]; do
sleep 0.1;
loop=$(($loop - 1))
[ $loop = 0 ] && break
done
/sbin/udevsettle
}
I've add the '[ $loop = 0 ...' line
Offline
I also had this problem as well -- what is the cause? I made the change to my start_udev, and now it gets past the uevents error. Now I have problems booting into the system (see http://bbs.archlinux.org/viewtopic.php?p=216611 ), but I don't see why this udev uevents even occurred after working fine until recently (I think somewhere along the pacman -Syu, udev got upgraded?)...
Offline
Long shot - try loading then saving your BIOS failsafe settings,
Offline
Long shot - try loading then saving your BIOS failsafe settings,
Thanks, but what do you mean by "saving" the settings? I've gotten the BIOS to boot in "default failsafe mode" if that's what you mean but no help...
Offline
but what do you mean by "saving" the settings?
Just that the BIOS should ask if you want to save any changes (and you do).
Offline
2 out of 3 reboots it hangs at 'Loading UDev uevents' on my system. This problem started after I i did a clean install with the latest 2007.05 iso. I never had this problem with Voodoo before.
Offline
i had this problem and discoveres that it worked fine if i removed a usb camera.. do you have usb devices plugged in?
Last edited by hacosta (2007-05-21 20:25:28)
Offline
Only a usb mouse.
Offline
I have this problem, with about 80% boot failure at "loading udev uevents", on a clean installation from Archlinux-x86_64-2007.08-Don't-Panic.current.iso. No dual boot, no fancy hardware: 1 SATA harddisk, 1 SATA optical drive. No USB devices.
Since this is the first machine I ever built myself I'm open to the possibility that I broke an important wire somewhere. Still, I'd like to be sure that that is the problem. Is there a way to find out?
I have experimented with mkinitcpio.conf by
1. getting a list of all loaded modules via mkinitcpio -m
2. adding them to the MODULES list in rc.conf
3. removing udev from the HOOKS defined in rc.conf
4. recompile the kernel image using mkinitcpio -p kernel26
However, this did not make a difference, since (if I read it correctly) rc.sysinit will call udev_start even if udev is not in HOOKS.
I've noticed that there are a number of print outs in the udev_start script that never make it to the boot screen, and I've also not found them in any log file. Is there a way to see them? I'd like to know if the problem is in udevsettle or in udevtrigger.
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
I've had this issue before: http://bbs.archlinux.org/viewtopic.php?id=34227
My laptop works wonderfully with the following kernel parameters added to the grub bootline:
acpi=force pci=nobios pci=assign-busses pci=conf1
Without them, it hangs on as you all have described.
Hope this helps.
Offline
I also had this problem a while back and just the pci=conf1 fixed it. I did a bunch of searching trying to figure out what exactly pci=conf1 really does, but found nothing specific. other than it bypasses the bios when assigning irq etc.. I think ?
-- archlinux 是一个极好的 linux。
Offline
Thanks for the reply, but this did not help. I tried both suggestions.
On the positive side I think I can rule out a hardware fault: I installed ubuntu as a second OS, and that boots without any problems. I also disconnected my optical drive (physically, by taking the SATA cable out of the motherboard), and again this didn't make a difference.
Any ideas on how to figure out if udevtrigger or udevsettle are to blame?
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
Not to attempt to keep trying something that doesn't work, but...
Give pci=conf2 a shot. You may get a kernel panic (like me), or it could help.
As for debugging, you could do a little printf debugging with the following functions in /etc/start_udev:
function trigger_device_events() {
/sbin/udevtrigger
}
function wait_for_queue() {
# loop=20
# while ! [ "$loop" -gt 0 -a -d /dev/.udev/queue ]; do
# sleep 0.1;
# loop=$(($loop - 1))
# done
/sbin/udevsettle
}
That would at least narrow down where the problem is coming from.
After that, you'd need the source to udevtrigger and / or udevsettle.
Offline
pci=conf2 did indeed result in a kernel panic - my first!
Trying to debug "solved" the problem, however: after one of many reboots fsck reported a corrupted block and I had to wipe the disk with DBAN before I could even format it.
However, after reinstallation the problem has disappeared - at least for now. Could be because this time I used the simplest possible partition scheme for a Linux/Linux dual boot (3 primary partitions: 1. swap, 2. ubuntu root, 3. arch root), could be because of something else. In any case Arch is booting and running well.
Thanks for all your help!
Last edited by grey (2007-09-14 21:05:58)
Good ideas do not need lots of lies told about them in order to gain public acceptance.
Offline
You could comment out the wait_for_queue call but that will randomly give a file mount error unless the timer is set at the kernel line. This should give about a 30% increase in speed. Also, I am convinced that the error begins at the first procedure of start_udev. There is an unnecessary loop but I am not sure now to fix. Another option would be to call the file system outside of startudev.
Offline
Pages: 1