FS#10534 - [2.6.25.4-1] Failing to create root device - jfs and ata_piix system
Attached to Project:
Arch Linux
Opened by Ray Rashif (schivmeister) - Thursday, 29 May 2008, 15:51 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 06 January 2009, 08:26 GMT
Opened by Ray Rashif (schivmeister) - Thursday, 29 May 2008, 15:51 GMT
Last edited by Tobias Powalowski (tpowa) - Tuesday, 06 January 2009, 08:26 GMT
|
Details
Issue:
I've been using the stock kernel ever since I hopped on to Arch (sometime around 2.6.{19,20}), so this can't be a user-related problem, although I surmise the apparently "more" modular nature of .25 has the answer to this one somewhere. The base modules needed _were_ (< 2.6.25) the following: ahci ata_piix sd_mod jfs But now they don't work. So I tried the default hooks and fallback kernel hoping udev and autodetect will do their jobs but to no avail. I don't see what other module could warrant a priority here for root on a /dev/sda6, which is SATA-I (1.5GB/s, Intel ICH7) with JFS. Am now back on previous stock .24 kernel. Looking at the official (upstream) kernel changelog didn't bring to light anything significant, but there were ata_piix issues reported for release candidates and maybe the first stable release earlier. Changing hda/sda schemes don't do anything either, contrary to similar problems reported elsewhere. Fix: Nothing concrete yet. Loading all known disk/storage modules which are detected by tools like hwd and hwdetect before the boot hooks is the first step at troubleshooting, which unfortunately fails. |
This task depends upon
Could this possibly be the issue where some parts of the early-userspace chain are not updated when it rebuilds the image? Could you try rerunning "mkinitcpio -p kernel26" ?
Notice that I already tested 2.6.25 on three machines with reiserfs, ext3 and xfs and I experienced no problems, that's why I think this could be the reason.
A removal of mkinitcpio, coreutils, initscripts and reinstallation of all 3 did it (all at once, so I'm not sure which of them is the real deal). It may have been a user-related problem after all, because I can't seem to be able to reproduce this behaviour.
Thomas, do you agree? If so, then I will begin looking into a fix for this, as it's more serious than I first thought
BTW, upgrade to kernel 2.6.25.4 fixed the boot problem.
* Run mkinitcpio -vp kernel26. If there are errors, it's mostly due to typos in mkinitcpio.conf or in-kernel module changes. When there is no error, use the fallback image. Since this image uses all known modules, you eliminate module issues and possibly it'll end up as an upstream bug.
* Make sure you're using the new *.preset and *.kver in mkinitcpio.d, they're probably in *.pacnew extension. Merge if needed, but take note that the new syntax/method is different. Fallback confs are no longer used; image is generated with mkinitcpio.conf but without autodetect (all storage-related modules will be included).
* If you use a different /boot layout or build your own kernel26, please do not forget that very fact. Images are generated and placed in /boot by default, so edit the new *.preset. Remember that System.map26 and vmlinuz26 will ALWAYS end up in /boot because they're provided by kernel26, so you will have to move them to your desired location manually. Delete all kernel26-related files and reinstall kernel26 to ensure you do not have the old files (or at least make sure bootloader is pointing to the new ones).
Since the way I solved it was to uninstall-reinstall mkinitcpio, coreutils and initscripts, it doesn't relate to those of you for whom the solution is not so simple. For this, it's either mkinitcpio or coreutils that did the trick. If it was coreutils, the problem may have been a missing/broken executable, which can be attributed to things like hardware failure, cancelling installations midway, hard freezes etc.
Aaron, are you keeping this open? If so, I'll try a few different scenarios, especially installation order, and see if a reproduction is possible. I do say that this appears to be a user (my) problem in the end, though.