Arch Linux

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#24913 - [mkinitcpio] 0.6.15-1: Unable to determine major/minor number of root device

Attached to Project: Arch Linux
Opened by Stefan Förster (HotblackDesiato) - Monday, 27 June 2011, 20:49 GMT
Last edited by Thomas Bächler (brain0) - Thursday, 30 June 2011, 09:53 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Thomas Bächler (brain0)
Dave Reisner (falconindy)
Architecture i686
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No



The initial ram disk created with mkinitcpio (version 0.6.15-1) for my vanilla kernel is unable to load most of the modules. As a result, the device /dev/sda is not created and I get the error message "Unable to determine major/minor number of root device ...".

I have googled already for this error message and tried several additional hooks in /etc/mkinitcpio.conf, but to no avail. I have made sure that all the modules that the stock arch kernel loads are present in my kernel.

I have ruled out the kernel configuration, since I have been able to create an initial ram disk with dracut and besides an ACPI error it boots the my kernel. It is the same kernel configuration that I had used before on this machine with Ubuntu.

With the -v option I can see that the modules of my kernel are found and installed into the initrd. The sile size is 1.8MB and thus a bit larger than the initrd supplied by Arch Linux (1.6MB).

Additional info:
* package version(s)
machine: IBM ThinkPad T23
package version: 0.6.15-1

* config and/or log files etc.
mkinitcpio.conf as attached

Steps to reproduce:
1. compile vanilla kernel
2. mkinitcpio -v -k -g initrd- -s mkinitcpio-filelist.txt >mkinitcpio.txt
3. add an entry in menu.lst and reboot
This task depends upon

Closed by  Thomas Bächler (brain0)
Thursday, 30 June 2011, 09:53 GMT
Reason for closing:  Not a bug
Additional comments about closing:  Choose IDE or libata, stick with one, configure mkinitcpio to reflect your choice ('ide' or 'pata' hook, respectively). We recommend pata.
Comment by Thomas Bächler (brain0) - Tuesday, 28 June 2011, 11:13 GMT
I can't see anything obvious that is wrong here.

1) Please supply the kernel command line from the bootloader.
2) Make a "screenshot" (digital photo) of the screen - alternatively, give a detailed description of what happens before the error.
3) In the recovery shell, check with 'lsmod' if the required modules are in fact missing. Also check with 'ps' that udev is running. If a module is missing, try loading it manually, wait for a second and check whether booting continues after a logout.
Comment by Dave Reisner (falconindy) - Tuesday, 28 June 2011, 12:16 GMT
Does an image created without autodetect work?
Comment by Stefan Förster (HotblackDesiato) - Tuesday, 28 June 2011, 20:16 GMT
Hallo Thomas and Dave,

1) the kernel command is as follows:
kernel /vmlinuz- root=/dev/disk/by-uuid/6e858210-9646-429a-8978-6355dde473af ro acpi_sleep=S3_bios nolapic acpi=on nls=utf8

2) I have attached two screenshot; the first screenshot also shows the output of lsmod and as you can see, only the modules uhci_hcd and usbcore are loaded. The second one shows the KernelPanic message that I get when I CTRL-D three times...

3) There are three instances of udevd running. I manually modloaded every module of the mkinitcio-filelist.txt (scsi_mod, libata, pata_acpi, ata_piix, sd_mod, cdrom, sr_mod, usb-libusual, usb-storage, jfs) and then exited the shell with CTRL-D. It did not boot, went into a new shell. I repeated this two times and finally produced a Kernel Panic.

4) Without autodetect I get the same result (but initrd is larger).

Beste Grüße, Stefan
Comment by Thomas Bächler (brain0) - Tuesday, 28 June 2011, 20:59 GMT
This doesn't make much sense - loading the modules should have some effect, unless the hardware does not exist. Is your hard drive connected on USB or SATA? Can you also attach your kernel configuration? Can you compare the contents of /dev before and after manually loading the modules?
Comment by Stefan Förster (HotblackDesiato) - Wednesday, 29 June 2011, 19:45 GMT
I can assure you that the hardware does exist. I currently work on this notebook with the standard Arch kernel. This is what hwinfo knows about it:
[stefan@stefan2 ~]$ hwinfo --disk
18: IDE 00.0: 10600 Disk
[Created at block.245]
Unique ID: 3OOL.3wHCGv7MFZD
Parent ID: 3p2J.S8SXm40iUR7
SysFS ID: /class/block/sda
SysFS BusID: 0:0:0:0
SysFS Device Link: /devices/pci0000:00/0000:00:1f.1/host0/target0:0:0/0:0:0:0
Hardware Class: disk
Model: "FUJITSU MHT2060A"
Vendor: "FUJITSU"
Device: "MHT2060A"
Revision: "006C"
Driver: "ata_piix", "sd"
Driver Modules: "ata_piix"
Device File: /dev/sda
Device Files: /dev/sda, /dev/disk/by-id/ata-FUJITSU_MHT2060AS_NP1GT4925775, /dev/disk/by-id/scsi-SATA_FUJITSU_MHT2060_NP1GT4925775, /dev/disk/by-path/pci-0000:00:1f.1-scsi-0:0:0:0
Device Number: block 8:0-8:15
BIOS id: 0x80
Drive status: no medium
Config Status: cfg=new, avail=yes, need=no, active=unknown
Attached to: #9 (IDE interface)

Loading all the modules listed in mkinitcpio-filelist.txt does not show any effect in /dev. Attached are a few photos and the kernel config. Interestingly, when I attach an USB sd card reader, a lot of devices are created for this sd card reader in /dev (see photos).

Comment by Dave Reisner (falconindy) - Wednesday, 29 June 2011, 19:56 GMT
Well this certainly stands out:


We're supposed to support non-devtmpfs configs, but that's probably the key difference between the ARCH kernel and yours. Any particular reason you've chosen to disable this?
Comment by Stefan Förster (HotblackDesiato) - Thursday, 30 June 2011, 07:58 GMT
Hey, you are cool. I don't know why this is not set. I'll try.

I also found another difference. Under my kernel with initrd by dracut the hard drive is not sda but hda:

[stefan@stefan2 ~]$ ls /dev/sd*
ls: Zugriff auf /dev/sd* nicht möglich: Datei oder Verzeichnis nicht gefunden
[stefan@stefan2 ~]$ ls /dev/hd*
/dev/hda /dev/hda1 /dev/hda2 /dev/hda3 /dev/hda4 /dev/hda5 /dev/hda6 /dev/hdc
Comment by Thomas Bächler (brain0) - Thursday, 30 June 2011, 08:55 GMT
I figured out why the ata_piix and sd_mod modules are not being loaded, and why loading them has no effect. And why, with mkinitcpio, your hard drive is not recognized.

Before I start this explanation, this is all due to misconfiguration of your own kernel and/or mkinitcpio, and thus has no place on the bugtracker. Basically, you blamed us for a problem you created, and made us debug it by claiming it was our fault. If you are going to build your own kernel, you better know what you are doing.

Okay, here come the details:

1) There are two subsystems for IDE devices. The old deprecated "IDE" subsystem and the new "libata" subsystem. On Arch, we always recommend the libata subsystem, but the IDE subsystem should still work.
2) You built the IDE subsystem based ide-generic and the piix driver (for your IDE hard drive) hard-wired into your own kernel. That is why loading pata_acpi, ata_generic or ata_piix has no effect: The hardware is already managed by another driver: CONFIG_IDE_GENERIC=y, CONFIG_BLK_DEV_PIIX=y
3) You built the IDE hard drive support as a module: CONFIG_IDE_GD=m
4) You configured mkinitcpio without the 'ide' hook - therefore the ide hard drive support was not built into the image and the necessary driver to create the /dev/hda* devices could not be loaded. (dracut was probably including and loading that module and thus created the 'hda*' devices)

The drivers to support your hard drive properly are there: scsi_mod, libata, ata_piix and sd_mod. They were built into the image by the 'pata' hook. But, as I pointed out in 2), they could not load, as the hard-wired IDE-based piix driver already claimed the hardware.

The recommended solution is to entirely disable the IDE subsystem (CONFIG_IDE=y -> CONFIG_IDE=n) and use libata instead - which is already configured properly in your kernel (CONFIG_SCSI_MOD=m, CONFIG_BLK_DEV_SD=m, CONFIG_ATA=m, CONFIG_ATA_PIIX=m)
Comment by Stefan Förster (HotblackDesiato) - Thursday, 30 June 2011, 09:38 GMT
Thank you very much for your investigation and explanations. Sorry for filing this bug, as it turned out to be a misconfigured kernel only. I have used this kernel configuration for years under Ubuntu, so it did not come to my mind that there would be something wrong with it.

Many thanks !

Comment by Stefan Förster (HotblackDesiato) - Thursday, 30 June 2011, 09:50 GMT
Hey, you are cool. I don't know why this is not set. I'll try.

I also found another difference. Under my kernel with initrd by dracut the hard drive is not sda but hda:

[stefan@stefan2 ~]$ ls /dev/sd*
ls: Zugriff auf /dev/sd* nicht möglich: Datei oder Verzeichnis nicht gefunden
[stefan@stefan2 ~]$ ls /dev/hd*
/dev/hda /dev/hda1 /dev/hda2 /dev/hda3 /dev/hda4 /dev/hda5 /dev/hda6 /dev/hdc