Arch Linux

Does the fallback image have any effect or different result?

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" ?

I don't know if it's related, but I have a similar virtual machine (same chipset and filesystem) and I experienced a boot failure with 2.6.25. Turns out I didn't look carefully at pacman's output: it was failing on the keymap hook while creating the initcpio, so the one I had contained 2.6.24 modules. Same went for the fallback image. After removing the offending hook the image was correctly created and I could boot again.

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.

Solved. I noticed that mkinitcpio wasn't generating System.map and vmlinuz; emptied out /boot and reinstalled kernel26; only the images were there together with kconfig. A verbose run didn't show any problem with either the default or fallback, so it isn't like bardo's case above.

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.

Oops..I actually meant "mkinitcpio wasn't generating the images" and "only System.map and vmlinuz along with the older kernel's kconfig" =/

Hm, I think this is related to the bug Thomas and I talked about that has to do with install order when the kernel is bumped along with the kilbc* packages, and mkinitcpio is not upgraded.

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

I guess I have a similar problem. I upgraded my kernel today to 2.6.25.3-2 and I can't get into my arch anymore. The problem is that /dev/sda* devices are missing and the root fs (ext3) can't be mounted. I have Asus P5B mb with ICH7 sata chipset. I didn't notice any errors during the kernel26 installation.

I've noticed that there is already kernel26-2.6.25.4-1 in core, but it did not get upgraded to using pacman -Su even though I can clearly see /var/lib/pacman/sync/core/kernel26-2.6.25.4-1 directory. Instead pacman -Su did offer me upgrade to kernel26-2.6.25.3-2. That package was not even in the sync db. Duh.

BTW, upgrade to kernel 2.6.25.4 fixed the boot problem.

Whoops, sorry for confusion. I have patched custom build of kernel26-2.6.25.3-2 in my personal repository. I completely forgot about it.

There are a few similar cases which actually have no relation to each other. A checklist:

* 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.

Does this still happen with kernel 2.6.27.7?

Nope. In fact, ever since my last comment I could never reproduce this (unfortunately or fortunately). Didn't request closure as I haven't had a conclusion myself.