Arch Linux

Attaching photo of boot up screen and mkinitcpio config file.

It appears that your sata or ide controller isn't being loaded. Do you know what module you need for your controller? If so you might want to post it so you can get some further help.

I have the same problem (I use Intel 945G based mainbord with SATA hdd).

I have never changed mkinitcpio.conf (and everything was ok with prviouses karnels).

Aha... I use arch64.

I believe this bug is a duplicate of #10046 (http://bugs.archlinux.org/task/10046). As I reported there, I have the same problem. I use 32-bits arch (x86), though.

Yeh, I have the same problem too. However I know where is a problem. It is in keymap hooks. If you remove from mkinitcpio.conf and rebuild your initrd image everything is OK, Or you can unset CONSOLEFONT in rc.conf and rebuild initrd image this help me too. I use archiso for rebuild initrd image.

Daniel, that wasn't the case on my system. I removed the keymap hook from mkinitcpio.conf, rebuilt the image, and used KEYMAP="us" in my rc.conf. The problem persisted.

I reinstalled arch and did a full system upgrade. I expected it to become unbootable again, but it didn't (and I do have a keymap hook). Clearly some combination of variables were interacting in some weird way. I still have the borked system around if anyone wants me to try something or get information about it.

Thanks all for help and sorry for the late response, i forgot to pay internet fees for may in my students dorms, so I'm offline now.
Anyway, I removed keymap hook from mkinitcpio.conf, rebuild the image and system boots just fine.

new mkinitcpio version in core fix this problem.
to Miguel: if your system doesn´t boot can you write anything to shell or is complete freezy?

Daniel,

It doesn't freeze; I believe I end up within the initial ram disk. I have a prompt (ramfs> IIRC) and a limited selection of commands (echo, cd, mount, etc... those included in klibc if I'm not mistaken).

I compared the boot messages of working and non-working installs. I think it's clear that the non-working initrd is not loading any disk-related modules. For instance, in the working install I see messages like:

libata version 2.21 loaded
ata_piix 0000:00:1f.2:version 2.11
scsi0: ata_piix
scsi1: ata_piix
ata1: SATA
ata2: PATA

etcetera. In the non-working initrd I don't see _any_ of these messages.

Did you try new mkinitcpio which release yesterday?

Daniel, it still doesn't work :(

I copied the packages mkinitcpio 0.5.18.1-1 and a fresh kernel26 2.6.24.4-1 over to the partition where the non-booting system is installed. I also copied my current (working) system's mkinitcpio.conf. I booted off the live cd, chrooted into the non-booting system, and used pacman -U to update mkinitcpio and kernel26. I moved the just created vmlinuz26 and kernel26.img to /boot (with new names), updated grub's menu, and rebooted. I get the same as before: nothing disk, scsi, sata, etc. related on the boot messages, and I'm dumped to a ramfs$ prompt. The messages I get are:

:: Loading root filesystem module...
Attempting to create root device '/dev/sda8'
ERROR: Failed to parse block device name for '/dev/sda8'
unknown
ERROR: root fs cannot be detected. Try using the rootfstype= kernel parameter.
Waiting for devices to settle...done.

and then it explains the root device doesn't exist, and that it'll drop me to a recovery shell.

The weird thing is that the same machine boots fine after a full reinstall, using the same kernel, the same mkinitcpio.conf file, the same everything as far as I can tell. Could it be that something (kernel headers, libraries, something) is corrupted? Maybe I messed up something beyond repair during my initial recovery attempts.

I also had problems with new kernel (ERROR: Failed to parse block device...etc.). In my case adding raid to HOOKS section helped. It was strange because I don't use raid.

It isn't strange. Because the error is causes by SORT function in mkinitcpio. So if you do some change in mkinitcpio.cong (add/remove something) it can you help.