FS#10061 - [mkinitcpio] mkinitcpio hangs on autodetect

Attached to Project: Arch Linux
Opened by Graziano Giuliani (Graziano) - Wednesday, 02 April 2008, 07:15 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 27 February 2011, 11:35 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Aaron Griffin (phrakture)
Thomas Bächler (brain0)
Roman Kyrylych (Romashka)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No

Details

Description:

mkinitcpio hangs on autodetect step with kernel 2.6.24.4-1 on one of my machine. kernel upgrade with pacman fails and no init image is generated (possible kernel panic if reboot is made).

Additional info:

mkinitcpio 0.5.18-1
kernel26 2.6.24.4-1

Workaround is editing mkinitcpio.conf, take away the autodetect, perform a pacman -Sf kernel26, use fallback image to boot.

* config and/or log files etc.

lsmod output:

ipv6 295112 14
i915 27136 2
drm 92840 3 i915
parport_pc 40296 1
ppdev 8840 0
lp 11844 0
parport 37516 3 parport_pc,ppdev,lp
pcspkr 3584 0
psmouse 42652 0
serio_raw 6788 0
video 19348 0
output 4096 1 video
uhci_hcd 25504 0
ehci_hcd 36620 0
intel_agp 27040 1
sg 32024 0
thermal 16032 0
processor 33688 1 thermal
fan 5000 0
evdev 11776 4
button 8224 0
battery 13320 0
ac 5896 0
snd_hda_intel 374568 0
snd_hwdep 9096 1 snd_hda_intel
snd_seq_oss 33408 0
snd_seq_midi_event 7936 1 snd_seq_oss
snd_seq 55936 4 snd_seq_oss,snd_seq_midi_event
snd_seq_device 7956 2 snd_seq_oss,snd_seq
snd_pcm_oss 42400 0
snd_pcm 82312 2 snd_hda_intel,snd_pcm_oss
snd_timer 22536 2 snd_seq,snd_pcm
snd_page_alloc 9232 2 snd_hda_intel,snd_pcm
snd_mixer_oss 17024 1 snd_pcm_oss
snd 57320 9 snd_hda_intel,snd_hwdep,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_pcm,snd_timer,snd_mixer_oss
soundcore 8096 1 snd
tg3 118148 0
rtc_cmos 9016 0
rtc_core 18828 1 rtc_cmos
rtc_lib 3584 1 rtc_core
usbcore 148272 3 uhci_hcd,ehci_hcd
jfs 175312 2
sd_mod 25216 4
sr_mod 16932 8
cdrom 37672 1 sr_mod
pata_acpi 6784 0
ata_piix 19204 4
ata_generic 6916 0
libata 153392 3 pata_acpi,ata_piix,ata_generic

mkinitcpio.conf:

MODULES="ata_generic ata_piix jfs"
BINARIES=""
FILES=""
HOOKS="base udev autodetect pata scsi sata keymap filesystems"

Steps to reproduce:

pacman -Sf kernel26
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 27 February 2011, 11:35 GMT
Reason for closing:  Fixed
Additional comments about closing:  Now it is _really_ fixed. Closing.
Comment by Graziano Giuliani (Graziano) - Wednesday, 02 April 2008, 07:46 GMT
Update !

Yep, I have two machines (same hardware), one fails and the other not, with just one difference:

machine A with autodetect hang has made a kernel upgrade 2.6.24.2 -> 2.6.24.3 but NO reboot (2.6.24.2 kernel running).
machine B without hang on mkinitcpio at kernel update to 2.6.24.4 has kernel 2.6.24.3 running.

So the problem seems to be triggered by a missing reboot after kernel upgrade.

Note that after reboot, pacman -Sf kernel26 works OK on machine A either. Some changes in /proc or /sys filesystems may cause this?
I thinks this "bug" can be closed, may keep it here just for reference if someone else find it.
Comment by Holger Jorra (Trac3R) - Thursday, 03 April 2008, 23:08 GMT
This bug is related to IDE devices. Using fallback kernel is no sollution since /etc/mkinitcpio.d/kernel26-fallback.conf has been deleted during the update.

See the following thread in the forums:
http://bbs.archlinux.org/viewtopic.php?id=46035
Comment by Graziano Giuliani (Graziano) - Thursday, 03 April 2008, 23:26 GMT
Not sure about IDE.

I have only ATA devices here (Intel chipset, by the way the HW is HP dc5700 desktop), and remember I had no problem on upgrading from 2.6.24.3 to 2.6.24.4 on the SAME HW.

The ONLY diference here I have that one machine (fail) is running 2.6.24.2 and the other (ok) 2.6.24.3, all the other variables (HW, packages, package versions) being the same.

AND the upgrade process does NOT COMPLETE at all on kernel26 (hang on autodetect).

For me it is still a missing file hook on /proc or /sys.
Comment by Thomas Bächler (brain0) - Sunday, 11 May 2008, 10:56 GMT
The problem is probably that mkinitcpio does filesystem autodetection - and it tries to access all block devices in /dev to do that. Maybe it hangs on trying to access one of them.
Comment by Tobias Powalowski (tpowa) - Sunday, 12 October 2008, 06:55 GMT
what is the staus of this?
Comment by Tobias Powalowski (tpowa) - Sunday, 24 May 2009, 09:39 GMT
status fixed?
Comment by Thomas Bächler (brain0) - Sunday, 07 June 2009, 12:25 GMT
Not really, and I don't know how to fix it yet (OMG, this bug is old). I was not yet able to reproduce this. Can we get some updated info here, please?
Comment by Tobias Powalowski (tpowa) - Monday, 22 June 2009, 05:10 GMT
no new info provided, how about reopen if it still is an issue?
Comment by Kyle Bassett (ciphercast) - Tuesday, 02 March 2010, 10:00 GMT
I just experienced this bug while upgrading to 2.6.32.9-1. I added the necessary workaround information to the wiki under the 'mkinitcpio' page. I am unsure how to debug my i586+pata system further. Any ideas?
Comment by Thomas Bächler (brain0) - Tuesday, 02 March 2010, 10:07 GMT
Can you please provide the necessary information HERE?
Comment by Karol Błażewicz (karol) - Thursday, 29 April 2010, 23:43 GMT
@Kyle Bassett (ciphercast)
"my i586+pata system"
You mean you run Arch on i586?
Comment by M Johnson (mjohnson) - Saturday, 24 July 2010, 10:25 GMT
I just ran into this bug when updating to kernel26-2.6.34-2 (on x86_64). The workaround worked, but it would be nice if it weren't necessary. (Let me know what information I can provide that might be helpful.)
Comment by Thomas Bächler (brain0) - Saturday, 24 July 2010, 17:17 GMT
Can you run 'mkinitcpio -p kernel26' manually and look in the ps fax output which process it hangs on?
Comment by rafael (rb) - Monday, 30 August 2010, 00:43 GMT
@Thomas Bächler (brain0): I'm having the very same issue. How can I identify that process? I did run 'mkinitcpio -p kernel26' manually, but I'm unsure how to get the process identified with ps fax (sorry, I'm an unexperienced user)
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 30 August 2010, 02:27 GMT
@Rafael: Attach the file here (use attach button): ps afxu > /tmp/ps-afxu.txt
Comment by rafael (rb) - Monday, 30 August 2010, 02:54 GMT
@Gerardo Exequiel Pozzi (djgera): Thanks. Just to clarify, I followed the wiki workaround:
- booted with the fallback kernel
- removed autodetect from HOOKS in mkinitcpio.conf
- force the kernel reinstall with pacman -Sf kernel26
- reboot
- added autodetect from HOOKS in mkinitcpio.conf
- force the kernel reinstall with pacman -Sf kernel26
- reboot
with no succeed. After that the issue still persist. Then I tried with 'mkinitcpio -p kernel26' manually, same fate.

The ps-afxu.txt file was generated after doing those steps (booted with fallback). Is this any good?
   ps-afxu.txt (4.7 KiB)
Comment by Gerardo Exequiel Pozzi (djgera) - Monday, 30 August 2010, 03:22 GMT
OK, most of the steps listed are innecesary. (reinstall kernel to execute mkinitcpio, removing autodetect from conf because is skipped when fallback image is generated, ...)

Anyway the issue here is that running mkinitcpio hangs when parsing autodetect hook. So there is a process executed by autodetect hook that hang (mkinitcpio never end). Acording to your description this does not happen in your system. Right? What is needed here is the output of ps when mkinitcpio hangs on autodetect hook, not in other context.
Comment by rafael (rb) - Monday, 30 August 2010, 03:36 GMT
@Gerardo Exequiel Pozzi (djgera): Thanks. It hangs like you said (when parsed with autodetect) on a 'regular' boot (not with the fallback image), but the system becomes irresponsible. If I boot with the 'regular' image (the one parsed with autodetect) how can I get the output of ps afxu if the system didn't end the boot process? (Honestly, I don't have idea). Just trying to give some feedback here, sorry to have such newbie questions.
Comment by Thomas Bächler (brain0) - Monday, 30 August 2010, 07:42 GMT
Well, you should run the 'ps' command while mkinitcpio is hanging, otherwise it will be useless.
Comment by Glenn Matthys (RedShift) - Monday, 15 November 2010, 11:02 GMT
What's the status of this issue?
Comment by rafael (rb) - Friday, 31 December 2010, 18:59 GMT
Is still happening to me, although I just don't know how to run ps while the mkinitcpio is hanging (it happens before I gain access to a tty). I would like to help to fix this, but my skills are really basic. I'm about to reinstall the system on my laptop, so if there's anything that I can do while installing that could potentially help to fix this issue just let me know.

Loading...