FS#18810 - [mkinitcpio] Kernel doesnt recognize hard disk (probably after some upgrades)

Attached to Project: Arch Linux
Opened by Ivan (finarfin) - Tuesday, 23 March 2010, 22:58 GMT
Last edited by Tom Gundersen (tomegun) - Saturday, 18 June 2011, 19:45 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture i686
Severity High
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 7
Private No

Details

Description:
After last upgrades my pc doesn't want to boot.
It stops with the following error message:
Root device `/dev/disk/by/uuid/2ae0fc55-a2e9-4c9d-92d6-47caadd72ec4` doesn't exist. Attempting to create it
ERROR: unable to deterime major/minor number of root device `/dev/disk/by/uuid/2ae0fc55-a2e9-4c9d-92d6-47caadd72ec4`
You are being dropped to a recovery shell.
Type exit to try and continue booting
...


The hardware hasn't changed (no upgrade or modifications to configuration)


Additional info:
* package version(s)
kernel26 2.6.32.10-1
kernel26-firmware 2.6.32.10-1
udev-151-3

* config
Pentium 3 800mhz
IDE interface: VIA Technologiess VT82C586A
2 ide hd: 1. 13gb with 2 ext2 partition the first point to /boot the second to /
2. 80gb with 2 partition the first is a FAT32 partition and the second a ReiserFS partition that point to /home


Steps to reproduce:
N/A

In order to solve that problem I tried to:
-downgrade udev to version 151.2
-downgrade the kernel
but nothing changed.
This task depends upon

Closed by  Tom Gundersen (tomegun)
Saturday, 18 June 2011, 19:45 GMT
Reason for closing:  Works for me
Additional comments about closing:  Works with the newer kernel.
Comment by Rorschach (Rorschach) - Friday, 26 March 2010, 14:41 GMT
hmm the path /dev/disk/by/uuid doesn't exists, at least on my machine the path is /dev/disk/by-uuid. But I think I read some days ago a similar bugreport (can't find it now), related to a missing blkid while creating the ramdisk. Could you check if you have blkid installed and can recreate the ramdisk? blkid is part of util-linux-ng .
Comment by Ivan (finarfin) - Sunday, 28 March 2010, 10:21 GMT
Yeah the path in error message was .../disk/by-uuid (i wrote it badly :P)
Second i have blkid installed and the output is:

/dev/sda1: UUID="71d4505b-91a4-410c-ac6a-cb065d395c00" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda2: UUID="2ae0fc55-a2e9-4c9d-92d6-47caadd72ec4" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: TYPE="swap" UUID="30c067ce-cf08-4bd6-901a-9647022b1b3e"
/dev/sdb1: LABEL="LINUXREALM" UUID="D8D3-32C9" TYPE="vfat"
/dev/sdb2: UUID="6c5330d4-8476-4ec0-8099-1c8e73724a21" TYPE="reiserfs"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/sdc1: LABEL="Transcend" UUID="3088-08C6" TYPE="vfat"

So the uuuid of the root partition is correct.
Comment by nitmd (nitmd) - Friday, 02 April 2010, 17:29 GMT
I have run into this issue as well. A downgrade of udev as above did not fix it, haven't tried downgrading the kernel. Did try a chroot to the existing system from a live cd to make sure all appeared well with the drive, it seems to be ok. I did a complete pacman upgrade to see if that helped, no such luck.
Comment by Ivan (finarfin) - Saturday, 03 April 2010, 13:44 GMT
I also tried the following:
- pacman -Syu
- pacman -S base

with no luck.
Comment by David Bluecame (david.bluecame) - Saturday, 03 April 2010, 16:06 GMT
try to add "rootdelay=20" this to the kernel line in /boot/grub/menu.lst

kernel /boot/vmlinuz26 root=(bla bla bla) rootdelay=20

Maybe the new kernel takes more time to recognize the root device and this rootdelay can help you.

If it does not help, I have to say that I'm still at 2.6.31 because versions 2.6.32 and 2.6.33 get stuck when detecting my usb hard disk at boot, during rc.sysinit process. Maybe both problems are related somehow.

Best regards! David.
Comment by nitmd (nitmd) - Sunday, 04 April 2010, 02:21 GMT
I added the rootdelay=20 to the kernel line, it did wait 20 seconds but then gave the same error and dropped to the prompt.

I also labeled the disk and changed the kernel line to reflect the device at /dev/by-label/Arch_Linux, but that did not change anything either.
Comment by Kyle Bond (ultdev) - Friday, 09 April 2010, 21:18 GMT
http://wiki.archlinux.org/index.php/Mkinitcpio#mkinitcpio_hangs_on_.27autodetect.27_during_kernel_upgrade
I had the same problem; removing autodetect from my HOOKS line in /etc/mkinitcpio.conf and running "mkinitcpio -p kernel26" produced a working image for me.
Comment by Ivan (finarfin) - Saturday, 10 April 2010, 09:09 GMT
I tried your workaround, bur removing autodetect cause my kernel hang after loading all devices, because it mount all of them read-only, and kernel cannot write to them.
Comment by Ray Clancy (lilsirecho) - Saturday, 10 April 2010, 18:31 GMT
Also affects x86_64 kernel 33 upgrade having same error message. Ran fsck on all partitions..still get error message as noted by i686 responders
Comment by Kyle Bond (ultdev) - Saturday, 10 April 2010, 18:40 GMT
I can also confirm having this bug on my x86_64 system.

IVan: try changing your drive's entry in grub's "menu.lst" and mount entry in "/etc/fstab" from "ro" to "rw" and see if that helps.
Comment by Matthew Gyurgyik (pyther) - Saturday, 10 April 2010, 19:08 GMT
It seems like the proper sata/ide controller isn't being autodetected. Does the fallback initrd image work?
Comment by Ray Clancy (lilsirecho) - Saturday, 10 April 2010, 23:11 GMT
Same problem with fallback...............
Comment by Matthew Gyurgyik (pyther) - Saturday, 10 April 2010, 23:21 GMT
In the recovery shell can you access and mount your drives by their /dev entry example /dev/sda1? Is it just the uuids that are missing / not being generated? If you can mount them using the standard device name (/dev/sda1) maybe you can try to add your sata/ide controllers module to the MODULES="" in mkinitcpio.conf and regenerate the config.
Comment by nitmd (nitmd) - Sunday, 11 April 2010, 01:45 GMT
At least for me, I have no keyboard input available at all when dropped to the shell. Have tried deleting autodetect, that did not help; fallback image does not work either. Cannot access by /dev/sda1 etc. Have not tried changing ro to rw, not sure if that is safe to do so I need to research it more.
Comment by Ray Clancy (lilsirecho) - Sunday, 11 April 2010, 06:09 GMT
My keybd is dead also .....USB
Comment by Ray Clancy (lilsirecho) - Sunday, 11 April 2010, 06:10 GMT
Why is this FS# assigned to no one?
Comment by Ivan (finarfin) - Sunday, 11 April 2010, 09:21 GMT
in my case, i cannot access to any hd. In /dev i cannot find any sd* or hd* partition.

Comment by Ivan (finarfin) - Monday, 12 April 2010, 13:15 GMT
@ultdev:
i tried to use the rw option, both in fstab and in menu.lst, it no help.
Comment by Peter Foster (pF) - Monday, 12 April 2010, 18:05 GMT
Problem suddenly occurred on reboot, Sunday. I do a "-Syu" every day.

All disks fsck ok. "/" is ext4.

Changed disk reference from by-uuid to /dev/sda6 in menu.lst; no help.

USB keyboard unresponsive: have to power-cycle to regain control.

Fallback kernel does not work.
Comment by nitmd (nitmd) - Monday, 12 April 2010, 18:36 GMT
I dug around in the stuff my wife keeps trying to get me to throw away and found a ps2 keyboard, swapped that out for my usb keyboard and now I have input ability when dropped to the recovery shell. I dug around there and did a ls of the /dev directory from the recovery shell, my boot drive does not show up under the sd* versions or under the by-uuid versions. There also appears to be one data drive missing from the by-uuid list, but I was in a hurry and didn't have time to check that out fully. The root disk is labeled, but I forgot to check that, will do so later today.

So while the drive is detected in the initial system bootup, at some point it seems to "go away".
Comment by Peter Foster (pF) - Monday, 12 April 2010, 19:55 GMT
My Arch Linux system is well and truly b0rked. Thank God for Windows.

Three days with no solution, nor even the vaguest hint of one.

Comment by Matthew Gyurgyik (pyther) - Monday, 12 April 2010, 21:43 GMT
Have you attempted to add your sata/ide module to MODULES=() in mkinitcpio.conf and then run mkinitcpio? It seems as if your sata/ide controller module is not being included in the initrd or there was a major breakage in the kernel update (unlikely).
Comment by nitmd (nitmd) - Monday, 12 April 2010, 23:22 GMT
I just removed the pata module and substituted the ide module in my mkinitcpio.conf, rebuilt, and it booted. There is no autodetect either. All appears to be operating normally.
Comment by nitmd (nitmd) - Tuesday, 13 April 2010, 01:08 GMT
Sorry, sloppy editing and thinking. I substituted ide for pata in the hooks line, and had no autodetect in that line.
Comment by Ivan (finarfin) - Tuesday, 13 April 2010, 11:21 GMT
I tried removing substituting pata with ide, and no luck (but now i have errors only about a readonly filesystem):(
(i hate UDEV :) the old system in my opinion was better :D)
Now i try with autodetect...
Comment by nitmd (nitmd) - Tuesday, 13 April 2010, 13:02 GMT
Do you have keyboard input when dropped to the shell? If so, is your boot drive in your /dev when there?
Comment by Ivan (finarfin) - Tuesday, 13 April 2010, 15:38 GMT
ntlmd: yes, yes my keyboard work.

But when kernel drop me into emergency shell, /dev contain only tty* and few other things, but there is nothing that refer to a drive.
But when i boot from arch install cd i can mount them and chroot inside them :(
I tried also adding autodetect to mkinitcpio.conf but the problem is still there.
The only difference is when i remove autodetect, and kernel start booting, but it block when it try to write on various logs into / because it says that the device is read-only.
I also tried to modify in grub/menu.lst ro with rw. No luck.

Comment by Peter Foster (pF) - Tuesday, 13 April 2010, 16:35 GMT
"Comment by Kyle Bond (ultdev) - Friday, 09 April 2010, 21:18 GMT

http://wiki.archlinux.org/index.php/Mkinitcpio#mkinitcpio_hangs_on_.27autodetect.27_during_kernel_upgrade

I had the same problem; removing autodetect from my HOOKS line in /etc/mkinitcpio.conf and running "mkinitcpio -p kernel26" produced a working image for me."

We victims of this bug have no keyboard interaction to enable us to enter commands.
Comment by Matthew Gyurgyik (pyther) - Tuesday, 13 April 2010, 16:41 GMT
1) Figure out what sata/ide module you motherboard/chipset uses for example my board uses the pata_atiixp module. Then add it to MODULES=() so it reads MODULES=(pata_atiixp) in /etc/mkinitcpio.conf. Regenerate the initrd image by running mkinitcpio -p kernel26. For some reason autodetect is not detecting your sata/ide controller, thus the kernel can't access you drives.

2) A bug should be filed in regards to not being able to use a usb keyboard in busybox. I had the same thing happen to me. I simply plugged in a PS2 keyboard, however this may not be a valid solution for some (those who lack a ps2 port)
Comment by Matthew Gyurgyik (pyther) - Tuesday, 13 April 2010, 16:43 GMT
3) A new bug should be open stating that the mkinitcpio autodetect hook is not detecting the needed sata/ide controller module
Comment by nitmd (nitmd) - Tuesday, 13 April 2010, 17:14 GMT
Ivan, what motherboard do you have? I think the module is via82cxxx
Comment by Ivan (finarfin) - Tuesday, 13 April 2010, 20:29 GMT
i did several tries, the result is in the photo attacched.
1. in mkinitcpio i put in modules: piix via82cxxx and in hooks removed autodetect and replaced pata with ide. The file is: DSC04586p.JPG
2. in mkiniticpio modules: via82cxx and hooks like 1 but with autodetect, result is in DSC04586p.JPG

In both cases no success.
Next try:
module: via82cxxx hooks use pata instead of ide.
Comment by Ivan (finarfin) - Tuesday, 13 April 2010, 20:44 GMT
and guess the result?
Success? Noooo
Another fail...

For today i raise a white flag :)
I finish all ideas :(
my poor pc. And if i try to reinstall Arch?
Comment by Ray Clancy (lilsirecho) - Wednesday, 14 April 2010, 00:37 GMT
Chroot and re-install old kernel...had to force install...did not change the situation...still no uuid error.
Comment by nitmd (nitmd) - Wednesday, 14 April 2010, 01:59 GMT
4581p looks like what I had before replacing pata with ide, sorry, was hoping my solution would cure your problem as well.
Comment by Ray Clancy (lilsirecho) - Wednesday, 14 April 2010, 05:07 GMT
Suspected pacman-cage caused the problem in my system. Used the backup drive (no pacman-cage) to rebuild the main drive with dd. This solved the uuid problem most likely introduced by a change in the pacman db location when pacman-cage was utilized. My system is now running normally. I will attempt next to upgrade the kernel to 33.
Comment by Ray Clancy (lilsirecho) - Wednesday, 14 April 2010, 05:11 GMT
Confirm that I can now download kernel 33 in normal fashion. It originally dragged along a bunch of already installed packages and would not load any package.

This probably confirms the misplaced pacman db due to pacman-cage which no lionger is installed.
Comment by Ivan (finarfin) - Wednesday, 14 April 2010, 10:57 GMT
I'm trying to use kernel 2.6.33, the problem appears with kernel 2.6.32, during all the tests, i tried to keep the OS updated (hoping that some update will resume my system, with no luck).

I'm not using pacman-cage.
Comment by nitmd (nitmd) - Saturday, 17 April 2010, 00:16 GMT
I'm not coming up with any new ideas; not sure why this remains unconfirmed. Without an idea from somebody more knowledgeable, if you don't have data to save, you might try a reinstall. If you do, let us know the result.
Comment by Peter Foster (pF) - Sunday, 25 April 2010, 10:34 GMT
I solved this on my box by:

Booting from the Arch CD.

Chroot'ing as described in the Kernel Panics Wiki.

Changing mkinitcpio.conf as follows:

"
#HOOKS="base udev autodetect pata scsi sata ide filesystems keymap hal"
HOOKS="base udev scsi sata ide filesystems keymap"
"

Running "mkinitcpio -p kernel26"

Rebooting.




Comment by Leonid Isaev (lisaev) - Sunday, 25 April 2010, 22:00 GMT
Do you happen to have a diff between module lists from before and after you removed autodetect and hal?
I mean, there has to be some reason for this problem...

EDIT: what does the hal hook do?
Comment by Peter Foster (pF) - Monday, 26 April 2010, 18:14 GMT
In mkinitcpio.conf, MODULES="" before and after - is this what you mean?

I don't know or remember why I had "hal" in the previous HOOKS. mkinitcpio -p kernel26 during my recovery operation objected to it, so I removed it.

Either those of us suffering this bug caused it ourselves by using an incorrect mkinitcpio.conf (that has sufficed up till now), or the bug lies elsewhere; I am none the wiser, and few seem to care about this bug.

The other concomitant bug - the unresponsiveness of USB keyboards in the recovery console - is yet to be explained.
Comment by Leonid Isaev (lisaev) - Monday, 26 April 2010, 18:24 GMT
@pF
The reason why I asked about modules is that I have Arch on 5 (pretty old) machines and haven't experienced your problem. So, I wondered if was just lucky or some modules are becoming deprecated in the newer kernels...
Regarding the USB keyboards, there is a hook called "usbinput" -- read mknitcpio wiki. It should work...
Comment by Eligio Becerra (masterLoki) - Tuesday, 27 April 2010, 17:08 GMT
Hi, I'm joining to this bug too, I have a vanilla installation (x64, made it yesterday) now I'm running into this too. The funny thing is that I rebooted several times yesterday but only when trying to boot this morning ran into the bug. As a side note I didn't configured my grub.cfg properly and had the windows partition configured to boot in h0,0 (the windows system rescue) instead to h0,1 (Win Vista partition), booted several times and now that I trying to fix this issue, can't boot into Arch. Found this thread in the forum (http://bbs.archlinux.org/viewtopic.php?pid=737538) but is not working. My machine is Vaio laptop and I don't have keyboard issues.
Comment by Leonid Isaev (lisaev) - Tuesday, 27 April 2010, 21:04 GMT
@masterLoki
Confused here -- what was menu.lst, which led to a successfull arch boot? And can you reproduce it, that is boot correctly again?
Comment by Eligio Becerra (masterLoki) - Tuesday, 27 April 2010, 21:19 GMT
@lisaev
Sorry, when talking about grub.cfg, I meant menu.lst. So far I haven't changed anything. Tried to change to root to the proper device (/dev/sda7 in my case) but still not booting. Right now I'm @home so now I have everything I need to do further testing and see if I can get Arch to boot. I'll keep you all informed.
Comment by Peter Foster (pF) - Wednesday, 28 April 2010, 18:27 GMT
I'd totally forget about grub and examine your mkinitcpio.conf file as discussed above.
Comment by Eligio Becerra (masterLoki) - Thursday, 29 April 2010, 01:52 GMT
Hi everyone, apparently my issue is not related to this bug. Since the windows rescue partition booted several times, I suspect this caused my linux partitions to be erased. Since these partitions are located in an extended partition along with a ntfs partition it looks like they were wiped by the rescue utility. I noticed this when booting from an arch CD and checking the disk layout. I made the partition again and reinstalled. Now everything looks fine. Sorry for confusing that with this bug.
Comment by Peter Foster (pF) - Saturday, 01 May 2010, 19:03 GMT
@lisaev:
Thank you for the tip about the "usbinput" hook.
Comment by David Bluecame (david.bluecame) - Saturday, 01 May 2010, 20:44 GMT
In my case, kernel 2.6.31 works fine, but 2.6.32 and latest 2.6.33 don't recognize my USB external drive.

I've been investigating what's happening to me and maybe this could be interesting for the developers:
* In my particular case, I use an old PIII 650MHz laptop with two USB-1 integrated ports, so I installed a PCMCIA card with has the two USB-2 ports I use to connect to the USB drive.
* With 2.6.31 both USB-1 and (over the PCMCIA card) USB-2 ports can be used to connect the USB external drive with no problems.
* With 2.6.32 and 2.6.33, I can connect the USB external drive to any of the USB-1 ports with no problems at all.
* With 2.6.32 and 2.6.33, if I connect the USB drive to one of the PCMCIA card USB-2 ports, when Linux tries to mount it, it just never ends trying to mount it.

There is something more: kernels 2.6.32 and 2.6.33 actually CAN mount the USB drive connected to the USB-2 ports, but ONLY in READ ONLY mode. For example if I use:

mount /dev/sdb6 /media/test -t ext3 -o ro

then it mounts correctly


If I use instead:

mount /dev/sdb6 /media/test -t ext3 -o rw

Then it keeps trying to mount


The same behavior happens even when loading the ramdisk. If the usb drive needs any correction in the filesystem, as the ramdisk tries to mount it in rw mode to correct any problem, it also hangs.


So, something is wrong either with the yenta_socket (PCMCIA module) or the ehci_hcd (USB-2) modules (or maybe another one related to both), when using them to mount the USB drive in read/write mode. I hope this information maybe can be useful for you.

Best regards. David Bluecame.
Comment by lasse leet (rulex) - Monday, 03 May 2010, 08:50 GMT
I've been trying to do what Peter Foster did but when i run mkinitcpio -p kernel26 it says
FATAL: Hook 'udev' can not be found. and fails...
i followed the kernel panic wiki and mounted the necessary stuff. but is there anything else i have to do when udev isnt found?
Comment by lasse leet (rulex) - Monday, 03 May 2010, 09:17 GMT
ooops double post...
Comment by Peter Foster (pF) - Monday, 03 May 2010, 13:57 GMT
@rulex, try removing the udev hook from mkinitcpio.conf and retry mkinitcpio -p kernel26. We are dealing in magic here.
Comment by Matthew Gyurgyik (pyther) - Monday, 03 May 2010, 16:38 GMT
That is terrible advice!

@rulex do you have this file? /lib/initcpio/hooks/udev
/lib/initcpio/hooks/udev is owned by mkinitcpio 0.6.3-1

"udev is the device manager for the Linux 2.6 kernel series. Primarily, it manages device nodes in /dev. It is the successor of devfs and hotplug, which means that it handles the /dev directory and all user space actions when adding/removing devices, including firmware load." Source: Wikipedia

Basically without udev, you'll need to manually load all of your modules.

Therefore, we need to figure out why the udev hook can't be found...
Comment by lasse leet (rulex) - Monday, 03 May 2010, 20:36 GMT
I do not have that file. but i solved it by updating the livecd and then doing the mkinitcpio -p kernel26 on the livecd copying the .img's to my old /boot/
Comment by robb seaton (rps) - Friday, 02 July 2010, 06:24 GMT
Ran into this issue on a fresh install. Remedied by booting into a liveUSB, chrooting into install, reconfiguring mkinitcpio.conf and then running "mkinitcpio -p kernel26". The changes I applied to my mkinitcpio config: added "marvell_pata" to the modules section and I added "ide" and "usb" to the HOOKS section.

I suspect that this bug occurred due to configuring my /etc/fstab with UUIDs, which mkinitcpio then relied on in order to build the ramdisk and detect the drives. However, when the ramdisk was unable to discover a drive, it resulted in dropping to a shell _before_ configuring keyboard support, thus necessitating a hard reboot. Typically, I rely on a separate disk loading the necessary pata_marvell module, which then allows the system to detect and correctly mount the drive. However, in this case, the ramdisk seems to rely on all disks being detected before proceeding. I suspect that the system may have been able to boot if the ramdisk continued, ignoring the UUID errors.
Comment by Leonid Isaev (lisaev) - Friday, 20 August 2010, 15:24 GMT
Status?
Comment by nitmd (nitmd) - Friday, 20 August 2010, 15:45 GMT
My issue has disappeared with a more recent kernel update. I skipped updating the kernel for awhile but finally took the plunge and things worked fine.
Comment by JM (fijam) - Tuesday, 03 May 2011, 10:24 GMT
A variation of the infamous autodetect bug. It seems to have resolved for the commenters. Does the problem persist for anyone else? Otherwise, a possible candidate for closing.

Loading...