Updating udev, mkinitcpio, linux, initscripts breaks boot

AustinC · 2012-01-22 20:06:28

Hello world, new Arch user here.

I've installed from 2011.08.19-core-x86_64 disc.

After running pacman -Sf filesystem and pacman -Syu, my system would stall during the boot process with "Starting udev" as the last line of output.

I've reinstalled, but this time configured pacman to ignore the udev package. Now pacman -Syu doesn't break anything, but pacman -Qu shows the following 4 packages are out of date:

initscripts 2011.07.3-1
linux 3.0.3-1
mkinitcpio 0.7.2-1
udev 173-3

I'd like to bring these packages up to date, but I don't know how to troubleshoot the problem or recover my system when they do break things. Can anyone help me out here?

meph · 2012-01-22 20:48:30

Update everything. On boot let it hang for 30s, it will proceed with an error but you'll be able to boot.

Then proceed as stated in this thread: https://bbs.archlinux.org/viewtopic.php?id=134012&p=1

Search is your friend Welcome btw

edit: accidentally linked 2nd page of the thread, corrected the link to point to the beginning, to avoid confusion

Last edited by meph (2012-01-22 20:50:40)

AustinC · 2012-01-22 21:16:54

Thanks for the reply, Meph.

Unfortunately, I'm not having the same issue as the linked thread. My boot hangs indefinitely.

meph · 2012-01-22 21:35:33

AustinC wrote:

Thanks for the reply, Meph.
Unfortunately, I'm not having the same issue as the linked thread. My boot hangs indefinitely.

Oh, sorry about that then, thought it was the same issue.

Try to append "acpi=off noapic" to the kernel line in grub and see if it lets you through. It sometimes can be used as a temporary workaround to let you finish booting process and start investigating from there what's causing the problem.

Knowing a bit more about your hardware could also help. Common hardware usually doesn't have any problems with udev, so that could point towards some old or exotic piece of hardware. Any information in this regard could be helpful.

Anyway, sorry I won't be able to reply any more today. I'm sure someone else will help you, I'll check the thread as well tomorrow. I'm sure we'll be able to help more when we get to the bottom of this, so far it's been more or less a spaghetti method

AustinC · 2012-01-22 22:08:50

Some more details on my system:

Intel i5-2500 CPU
Asus P8Z68-V LE motherboard
Nvidia GTX550 Ti GPU
Crucial SSD
Apple USB keyboard
Logitech M315 mouse

syslinux bootloader

rc.conf http://pastebin.com/ss78G0xv
mkinitcpio.conf http://pastebin.com/1fUPJsQ5
fstab http://pastebin.com/2trypn68

veljom · 2012-01-23 09:30:49

Dear all, I have the same problem, after update last Friday, boot now hangs indefinitely. I have Lenovo l420 laptop, with
Intel Core i3-2350M Processor
Intel HD Graphics 3000.

Does anyone how any idea how to solve this issue?

meph · 2012-01-23 11:58:23

A quick reply (without reading through the config files - sorry, no time for that now, will check it out later).

First of all, try to boot with appending "acpi=off noapic" to kernel line in grub. It's been known to help some people to get through the boot process, and even though it's not a solution, getting the system to boot up is a start and might help a lot in figuring out what's really going on. AustinC, no idea how is that done in syslinux, but I'm positive that there is an option to turn acpi off, so you can google it up.

Second, to keep it short, it is possible that the system doesn't actually hang, the 30s timeout is still running, just for multiple devices. I've heard about a case where udev was mistakenly trying to mount dozens or even hundreds of non-existent devices, now multiply that by 30s and you end up with several hours long timeout. This may be a long shot, but perhaps worth checking out. Let it run for a longer period of time, perhaps even overnight if you can. Again, not a solution, just trying to figure out where the problem is.

Last edited by meph (2012-01-23 12:07:52)

falconindy · 2012-01-23 12:02:12

Be aware. There is a reason you no longer see it in rc.conf or the wiki.

http://projects.archlinux.org/initscrip … 4686d64826

meph · 2012-01-23 12:08:38

falconindy wrote:

Be aware. There is a reason you no longer see it in rc.conf or the wiki.
http://projects.archlinux.org/initscrip … 4686d64826

I stand corrected, missed that one. Edited out of the original post.

Is there no way to reduce the timeout now, for debugging purposes? I'm nowhere near a linux box right now, so can't check any config files...

Last edited by meph (2012-01-23 12:12:01)

AustinC · 2012-01-24 01:28:27

I'm able to boot after the full update (udev 178-1 now) by using the 'acpi=off' parameter.

I also noticed that during the shutdown process, shutting down udev [FAIL]s, as well as some unmounting operations [FAIL] but they disappeared so quickly I didn't catch the details.

I'm very grateful to Meph for the help with this, though I wouldn't consider the issue solved. From the looks of the forums these days, it seems like recent udev updates have been especially problematic. For now, I'll just settle for the 'acpi=off' flag and express my appreciation for the devs while I look forward to a bugfix: Thank you devs, this distro resonates with the effort you've put in.

edit: After rebooting with 'acpi=off' once, subsequent boots did not require that parameter! Woohoo.

Last edited by AustinC (2012-01-24 01:52:28)

haidut · 2012-04-24 15:15:20

Hi,

I got the same problem and the acpi=off option lets me boot. Last night I managed to get Fallback to work by blacklisiting mei and my wifi driver but the regular image still did not boot. I am not sure if this helps at all.

Any ideas what to do now?

Thanks!

EDIT: also, getting rid of the acpi=off option on subsequent boots did not fix it for me.

EDIT2: Just confirmed that blacklisting mei and iwlwifi and adding iwlwifi to the MODULES section in rc.conf allows me to boot the fallback wtihout acpi=off. No such luck with the regular image

Last edited by haidut (2012-04-24 15:27:37)

haidut · 2012-04-24 15:52:15

Hi,

After blacklisting mei and iwlwifi and loading iwlwifi from rc.conf I managed to boot fallback. Then in fallback I ran mkinitcpio -M which tells you what modules are autodetected in the regular image and are loaded at boot. I wrote a little script that checks for each of this modules in the output of lsmod while in Fallback. Thus i found that the following modules are not loaded in Fallback but would be loaded in the regular image:

mei
iwlwifi
nouveau (I have nvidia so whatever)
shpchp

After blacklisting shpchp the regular image started booting as well, without acpi=off. Not sure if this makes sense at all but works for me.

EDIT: it seems that I cannot load iwlwifi from rc.conf??? modprobing it works though. Not sure what's going on...

Any way this can be solved without blacklising?

Arch Linux

#1 2012-01-22 20:06:28

Updating udev, mkinitcpio, linux, initscripts breaks boot

#2 2012-01-22 20:48:30

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#3 2012-01-22 21:16:54

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#4 2012-01-22 21:35:33

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#5 2012-01-22 22:08:50

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#6 2012-01-23 09:30:49

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#7 2012-01-23 11:58:23

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#8 2012-01-23 12:02:12

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#9 2012-01-23 12:08:38

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#10 2012-01-24 01:28:27

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#11 2012-04-24 15:15:20

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

#12 2012-04-24 15:52:15

Re: Updating udev, mkinitcpio, linux, initscripts breaks boot

Board footer