FS#12374 - [mkinitcpio] initcpio produces faulty non-fallback image

Attached to Project: Arch Linux
Opened by Eric Barrat (nowahn) - Sunday, 07 December 2008, 15:10 GMT
Last edited by Thomas Bächler (brain0) - Sunday, 07 June 2009, 12:33 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Architecture i686
Severity High
Priority Normal
Reported Version None
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



symptoms :
- kernel panic when booting on the non-fallback image
- boot OK when booting on fallback image

this bug occurs in rare but accurate situations :
- root filesystem needs a module to get mounted (reiserfs in my case)
- all such filesystems are on devices witch names include "fd"
("/dev/mapper/nvidia_bafgafdap#" in my case because it is on a raid array)

reason and fix we could found out (thanks tuxce for your help) :
- my partitions are discarded as floppy disks by the "autodetect" hook when looking for filesystems because their names include "fd"
- editing "/lib/initcpio/install/autodetect" line 16 by changing "... grep -v -e loop -e ram -e fd..." with "... grep -v -e /loop -e /ram -e /fd..." fixes this bug
(needs to rebuild the boot image with mkinitcpio after this edit)

related topics on forums :
- original topic on the French forum :
- topic with a summary on the English forum :

strange things about this bug :
- I have another small base archlinux on my system (only the base group + the dmraid package)
- this system was installed on November 18th
- this system was never upgraded
- this system produced a working non-fallback boot image during installation
- this system produces non-working non-fallback boot image today
(bug bug occured on Novembre 30th because the boot images wheres rebuild because of a kernel upgrade)

possibly related bugs :
every strange and rare boot bug on systems with "exotic" hard disk configuration
(where "fd" can be included on device names)
Additional info:
* package version(s)
* config and/or log files etc.

Steps to reproduce:
This task depends upon

Closed by  Thomas Bächler (brain0)
Sunday, 07 June 2009, 12:33 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in git
Comment by Gavin Bisesi (Daenyth) - Sunday, 07 December 2008, 18:21 GMT
Might this be related to  FS#11757 
Comment by Thomas Bächler (brain0) - Sunday, 07 December 2008, 18:38 GMT
I never liked the grepping in this case, it was only a matter of time until such a bug appeared. Will look at it soon.
Comment by Eric Barrat (nowahn) - Monday, 08 December 2008, 12:46 GMT
correction :
forget the paragraph "strange things about this bug"
(I had another old hard disk plugged with a reiserfs partition to transfer my old data)
Comment by Aaron Griffin (phrakture) - Monday, 08 December 2008, 23:38 GMT
@Thomas: Agreed, but I can't think of a better way than grep.
Comment by Eric Barrat (nowahn) - Friday, 12 December 2008, 20:58 GMT
could this bug be the main cause of the dmraid downgrade ?
see this topic