Root major/minor (Cannot boot)

janvaletin · 2011-11-13 22:06:49

Howdy!

I ran pacman -Syu last night before shutting down, and now my computer will not boot my Arch partition (in my Windows partition right now).

I get the same errors as seen in this post ,

:: Loading Initramfs
:: Starting udevd...
done.
Waiting 10 seconds for device /dev/sda3 ...
ERROR: Unable to determine major/minor number of root device '/dev/sda3'.

How would I go about fixing this? I have an Arch install CD, but I'm not sure how I would use it in this case.

MONVMENTVM · 2011-11-14 15:38:01

I had the same problem till now, but finally managed to fix it.

Boot your arch CD, mount your arch linux partition, access your /etc/mkinitcpio.conf file and post it here because I suspect it's probably the same issue.

janvaletin · 2011-11-15 18:08:58

# vim:set ft=sh
# MODULES
# The following modules are loaded before any boot hooks are
# run.  Advanced users may wish to specify all system modules
# in this array.  For instance:
#     MODULES="piix ide_disk reiserfs"
MODULES=""

# BINARIES
# This setting includes any additional binaries a given user may
# wish into the CPIO image.  This is run first, so it may be used to
# override the actual binaries used in a given hook.
# (Existing files are NOT overwritten if already added)
# BINARIES are dependency parsed, so you may safely ignore libraries
BINARIES=""

# FILES
# This setting is similar to BINARIES above, however, files are added
# as-is and are not parsed in any way.  This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options
# like so:
#    FILES="/etc/modprobe.d/modprobe.conf"
FILES=""

# HOOKS
# This is the most important setting in this file.  The HOOKS control the
# modules and scripts added to the image, and what happens at boot time.
# Order is important, and it is recommended that you do not change the
# order in which HOOKS are added.  Run 'mkinitcpio -H <hook name>' for
# help on a given hook.
# 'base' is _required_ unless you know precisely what you are doing.
# 'udev' is _required_ in order to automatically load modules
# 'filesystems' is _required_ unless you specify your fs modules in MODULES
# Examples:
##   This setup specifies all modules in the MODULES setting above.
##   No raid, lvm2, or encrypted root is needed.
#    HOOKS="base"
#
##   This setup will autodetect all modules for your system and should
##   work as a sane default
#    HOOKS="base udev autodetect pata scsi sata filesystems"
#
##   This is identical to the above, except the old ide subsystem is
##   used for IDE devices instead of the new pata subsystem.
#    HOOKS="base udev autodetect ide scsi sata filesystems"
#
##   This setup will generate a 'full' image which supports most systems.
##   No autodetection is done.
#    HOOKS="base udev pata scsi sata usb filesystems"
#
##   This setup assembles a pata mdadm array with an encrypted root FS.
##   Note: See 'mkinitcpio -H mdadm' for more information on raid devices.
#    HOOKS="base udev pata mdadm encrypt filesystems"
#
##   This setup loads an lvm2 volume group on a usb device.
#    HOOKS="base udev usb lvm2 filesystems"
HOOKS="base udev autodetect pata scsi sata filesystems usbinput"

# COMPRESSION
# Use this to compress the initramfs image. With kernels earlier than
# 2.6.30, only gzip is supported, which is also the default. Newer kernels
# support gzip, bzip2 and lzma. Kernels 2.6.38 and later support xz
# compression.
#COMPRESSION="gzip"
#COMPRESSION="bzip2"
#COMPRESSION="lzma"
#COMPRESSION="xz"
#COMPRESSION="lzop"

# COMPRESSION_OPTIONS
# Additional options for the compressor
#COMPRESSION_OPTIONS=""

MONVMENTVM · 2011-11-15 23:28:43

OK... what you could do is when grub starts up to get into editor mode (press 'E') and edit the kernel line and add disablehooks=autodetect to it. I'm not sure if this works but give it a try. The other way would be to boot again with the live CD, chroot into your current setup, delete the autodetect hook from the mkinitcpio.conf and then rebuilding with "mkinitcpio -p" (but I guess my first tip would produce the same effect).

But seeing that there was a new kernel released today I'd try this if disablehooks=autodetect didn't work:
Boot with your live cd and chroot into your current setup. then simply update your system and check if your system boots again.

good luck pal!

stryder · 2011-11-16 00:48:00

Disabling the autodetect hook in mkinitcpio gives you the same image as the fallback image. So to try what monvmentvm suggests, just try to boot using the fallback image. If it works then run mkinitcpio -p again (or update your system again).

slughappy1 · 2011-11-16 20:36:47

Sadly adding the 'disablehooks=autodetect' to the kernel line didn't do anything for me, I still get the same error. I am going to try to chroot and hopefully that will help.

lilsirecho · 2011-11-16 22:15:21

Perhaps the procedure outlined in this post will get you back up and running:

https://bbs.archlinux.org/viewtopic.php?id=129562

It worked for fatum......

slughappy1 · 2011-11-17 06:35:00

lilsirecho wrote:

Perhaps the procedure outlined in this post will get you back up and running:
https://bbs.archlinux.org/viewtopic.php?id=129562
It worked for fatum......

That worked. I used chroot to get into my Arch setup, downgraded the linux package, and then replace my mirrorlist with the newest one I got off the website. After that I was able to run pacman -Syyu and now everything is now working again! Thanks.

Can you tell me what the problem was do you think? Was it that the package was incorrectly downloaded, or was the package in the mirror bad, or something else?

Last edited by slughappy1 (2011-11-17 06:35:17)

falconindy · 2011-11-17 16:13:50

I think its much more likely that the initramfs didn't generate properly after installation of the kernel the first time around. I've seen this before, but I have no idea how to reproduce it (or what the underlying issue might be). The symptom is that the initramfs is created successfully, but without any modules (you can check it with lsinitcpio). Recreating it manually after pacman installs the kernel package results in a properly made image.

No offense, but the idea that a mirrorlist, somehow "broken" or even missing would affect your ability to boot is fairly absurd. Prior to pacman 4, packages are checked via md5sum to ensure that a download succeeded -- if there was a hiccup in the download or a corrupted transmission, pacman would have aborted the upgrade entirely.

lilsirecho · 2011-11-17 16:16:06

My take on this is the mirror thing. When first upgrading packages, it is possible that the old mirrorlist is operative.

Therefore it is necessary to remove the kernel so as to force it to use mkinitcpio upon next ..Syu.

In the process used by fatum, the system needs to resync with ...-Syy , fix the mirrorlist and then re-download the kernel which forces a new mkinitcpio by default.

Have no other explanation except the weird things that happen if the mirrors are not up to date.

It may be that the mirrors cannot be upgraded until reboot and that is when things hang.

Complete re-do before loading the kernel seems to involve only the mirrors.

Perhaps the mirrorlist can be modded before any upgrade of the kernel.

This would call for --ignoring the kernel upgrade, when the packages are installed, upgrade the mirrorlist and then install the kernel after the reboot.

Probably i am fulla____!

lilsirecho · 2011-11-25 03:31:30

Recent upgrade to linux3.1.2-1 caused no boot again from raid0 boot devices.

In spite of having uuid setup in grub kernel, I added ...after ro...root=/dev/md0.

This allowed the system to boot in raid0. This is unheard of AFAICT since the uuid is supposed to rule the system!!!

I am pleased it works but dunno why.................

vennen · 2011-11-25 06:33:18

Same problem after upgrading to linux3.1.2-1 today - it tells that root device is found /dev/sda3, but swearing at /sbin/init and not boot. Goes to ramfs/
Howether, in menu.lst is used /dev/sda3 instead UUID.

I can boot with fallback image, BUT when I removed autodetect from mkinitcpio.conf and generate new image it still doesnt want to boot from particlar image.

[UPDATE] Everything became OK when I had added in menu.lst this: rootfstype=ext4

Last edited by vennen (2011-11-25 15:51:01)

murali · 2011-12-03 14:01:28

Hi,

I'm facing the same problem after last night's upgrade. I went through this post as well as few others and added rootfstype but didn't work. Some other post mentioned to downgrade to old kernel and use new mirrorlist and run pacman -Syu again but i don't even get any command prompt for doing that. On booting up the machine it says "Waiting for 10 seconds", then "unable to determine major minor version", dropping to a recovery shell and then "Job access can't be turned off" and gives a very limited shell which has nothing. So i can't downgrade or run pacman again. I tried booting with fallback img as well but didn't work

The last old kernel that i've is linux-3.1.4-1-i686.pkg.tar.xz and i think the new kernel post upgrade was linux-3.1.7-1-i686.pkg.tar.xz

This is how grub entry looks like for Arch (I'm using another Linux OS's bootloader with Arch configured in it)

menuentry "Arch Linux (on /dev/sda5)" {
insmod part_msdos
insmod ext2
set root='(hd0,msdos5)'
#search --no-floppy --fs-uuid --set ed099b0d-70b7-4cc3-b623-87d030045e47
linux /boot/vmlinuz-linux root=/dev/sda5 rootfstype=ext4
initrd /boot/initramfs-linux-fallback.img
}

Any help/pointer would be highly appreciated.

Mavirick · 2011-12-03 18:53:55

Try taking a look at this and modifying your grub entry: https://bugs.archlinux.org/task/27385

murali · 2011-12-04 03:44:34

Thanks for the link, it didnt help me though. I never understood how having "quiet" in the kernel helps fix the issue as it just turns off verbose mode, but if it works for others then maybe there is something to it. I managed to fix the issue however by using chroot wiki, worked without any glitch and now i'm typing this from my arch desktop :-)

Regards.

Mavirick · 2011-12-04 04:58:25

Make sure to explain your solution in order to help others that might come across this thread.

Last edited by Mavirick (2011-12-04 21:03:14)

dlin · 2011-12-04 12:26:49

I"ve the same problem. The error message when boot is:
ERROR: Unable to determine major/minor
number of root device 'Waiting 10 seconds for dev /dev/disk/by-label/arch ...
/dev/disk/by-label/arch'.

My solution is to downgrade mkinitcpio to 0.7.5-1 (0.8.0-1, 0.8.0-2 don't work).
Then, pacman -S linux

I compared the output of different built kernel by following command:

lsinitramfs -a /boot//boot/initramfs-linux.img

Maybe this is the problem.

%diff 0.7.5.log 0.8.0.log
4,5c4,5
< -> Compression ratio: .507
< -> Estimated decompression time: 0.480s
---
> -> Compression ratio: .494 <- mkinitcpio 0.8.0 get worse ratio
> -> Estimated decompression time: 0.508s <- and slower time
26a27
> /sbin/switch_root <- extra two components
28a30
> /bin/mount

murali · 2011-12-04 12:41:57

Followed the instructions listed under "Mounting the device" & "Changing Root" in https://wiki.archlinux.org/index.php/Change_Root

Once i got control over my arch installation from chroot i just did pacman -U /var/cache/pacman/pkg/<prior working linux kernel> (in my case it was linux-3.1.4-1-i686.pkg.tar.xz). However this time i made sure linux image and initramfs has been created properly.

Then followed instructions under "Exiting chroot" and everything was back to normal.

This thread was opened by someone else, is it ok for me to mark it as Solved? i can do that if it's ok.

lilsirecho · 2011-12-04 14:54:02

Perhaps solved is not the correct conclusion...avoided would be more appropo.

The original poster is the only user able to mark this post as solved.

dlin · 2011-12-04 16:21:16

I've test it again.

To solve this problem, there are three workaround methods:
1. add "quiet" to boot linux line.(e.g. /grub/menu.lst)
2. downgrade the mkinitcpio to 0.7.5, and rebuild the kernel
3. downgrade the linux kernel(well, I don't know is it correct?)

I think all are NOT correct method to solve this problem.

Painless · 2011-12-04 21:46:14

I've also encountered this problem on a hosted VPS (Xen). I tried:

Adding "quiet" line to menu.lst - failed
Booting off fallback image - failed
Downgrade mkinitcpio to 0.7.5 and rebuild kernel - failed
Downgrade kernel to 3.0.7 - finally booted

Home machines are okay. I've slapped linux and mkinitcpio into IgnorePkg on the Xen VM for now.

markhadman · 2011-12-05 13:49:01

Those of you having the problem with a garbled root device identifier (ERROR: Unable to determine major/minor number of root device 'Waiting 30 seconds for device /dev/sdb ...) can work around it by adding 'quiet' to the kernel boot line in grub, and fix it by updating to mkinitcpio version 0.8.0-3 (and using it to rebuild your inital ramdisk). This will not fix everyone's problems, only the one described in the first few posts of this bug https://bugs.archlinux.org/task/27385

dlin · 2011-12-05 14:24:55

markhadman wrote:

Those of you having the problem with a garbled root device identifier (ERROR: Unable to determine major/minor number of root device 'Waiting 30 seconds for device /dev/sdb ...) can work around it by adding 'quiet' to the kernel boot line in grub, and fix it by updating to mkinitcpio version 0.8.0-3 (and using it to rebuild your inital ramdisk). This will not fix everyone's problems, only the one described in the first few posts of this bug https://bugs.archlinux.org/task/27385

I've tested the 0.8.0-3 mkinitcpio. It works.

Now, I don't require to put 'quiet' on grub's menu.lst.

JKAbrams · 2011-12-07 06:18:11

Same problem, new twist, sda becomes sdc.

Been plagued by this problem since upgrading my harddrive to a SSD and added a SATA 3 card.

The problem is random, sometimes it boots sometimes it doesn't.
-Rebooting usually fails.
-Cold booting works sometimes, success rate is about one in three (unfortunatly this rate is decreesing)

I made an interesting observation:
I dont remember the exact phrase but when it fails I get the option to try booting anyway by typing 'exit', so I try this. Then it says this will probably fail, and so it does. BUT after doing this I am able to see the contents of /dev/.
I notice that my sda2 (my / partition) is missing, but there is a new partition sdc2 that should not be there. I mount them and realise they have switched places, sda has become sdc! No wonder it does not boot.

In my menu.lst I use this:

root   (hd0,0)
kernel /vmlinuz-linux-ck root=/dev/sda2 ro vga=775

As a possible workaround, I have since changes this to: (but I have not tested if this actually works)

root   (hd0,0)
kernel /vmlinuz-linux-ck root=/dev/disk/by-label/Arch ro vga=775

Here comes the relevant info (-vv)

Hardware:

Asus P5KR Motherborad
Asus U3S6 SATA3/USB3 PCIe card

Disk setup:
U3S6 expansion card:
SATA1: /sda OCZ Agility3 120gb
SATA2: /sdb WD10EAVS 1tb

Motherboard (J-Micron eSATA/PATA controller):
SATA1: /sdc WD10EAVS 1tb
SATA2: /sdd HITACHI HDS722020A 2tb
SATA3: -
SATA4: -

Kernel:

$ uname -a
Linux p182 3.1.2-1-ck #1 SMP PREEMPT Thu Nov 24 15:29:35 CET 2011 x86_64 Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz GenuineIntel GNU/Linux

(-ck linux patchset from AUR, but I also get this issue on the stock kernel as well)

BIOS-settings:

Boot
Hard disk drives (I'm able to change the order here)
1st S0 OCZ
2nd PM WDC
3rd SM Hitachi
4th S1 WDC

Boot Device Priority
1st S0 OCZ
2nd [disabled]

Main
SATA 1 WDC
SATA 2 Hitachi
SATA 3 [not detected]
SATA 4 [not detected]

SATA Configuration
SATA Configuration [Enhanced]
  Configure as [IDE]

Hard disk write protect [Disabled]
SATA Detect Time out [5] (seconds)

Onboard Device Configuration
J-Micron eSATA/PATA Controller [Enabled]
  Controller Mode [IDE]

ASUS Bios
Ver: 0703
Build data: 06/26/08

Using mkinitcpio 0.8.0-3, so this is not the problem with the corrupted variable.

I first thought this is BIOS messing up the devices position, but if so why does it boot grub which is on /dev/sda? Perhaps not a BIOS issue?
The SSD is reported to have booting problems, but then it's said to not show up in bios, which mine always does, it's always found at the SATA controllers boot-screen.

Last edited by JKAbrams (2011-12-07 08:40:52)

Painless · 2011-12-07 20:54:01

@JKAbrams - this doesn't sound like the same problem. Your workaround should work. Have you read the wiki article Persistent block device naming?

Arch Linux

#1 2011-11-13 22:06:49

Root major/minor (Cannot boot)

#2 2011-11-14 15:38:01

Re: Root major/minor (Cannot boot)

#3 2011-11-15 18:08:58

Re: Root major/minor (Cannot boot)

#4 2011-11-15 23:28:43

Re: Root major/minor (Cannot boot)

#5 2011-11-16 00:48:00

Re: Root major/minor (Cannot boot)

#6 2011-11-16 20:36:47

Re: Root major/minor (Cannot boot)

#7 2011-11-16 22:15:21

Re: Root major/minor (Cannot boot)

#8 2011-11-17 06:35:00

Re: Root major/minor (Cannot boot)

#9 2011-11-17 16:13:50

Re: Root major/minor (Cannot boot)

#10 2011-11-17 16:16:06

Re: Root major/minor (Cannot boot)

#11 2011-11-25 03:31:30

Re: Root major/minor (Cannot boot)

#12 2011-11-25 06:33:18

Re: Root major/minor (Cannot boot)

#13 2011-12-03 14:01:28

Re: Root major/minor (Cannot boot)

#14 2011-12-03 18:53:55

Re: Root major/minor (Cannot boot)

#15 2011-12-04 03:44:34

Re: Root major/minor (Cannot boot)

#16 2011-12-04 04:58:25

Re: Root major/minor (Cannot boot)

#17 2011-12-04 12:26:49

Re: Root major/minor (Cannot boot)

#18 2011-12-04 12:41:57

Re: Root major/minor (Cannot boot)

#19 2011-12-04 14:54:02

Re: Root major/minor (Cannot boot)

#20 2011-12-04 16:21:16

Re: Root major/minor (Cannot boot)

#21 2011-12-04 21:46:14

Re: Root major/minor (Cannot boot)

#22 2011-12-05 13:49:01

Re: Root major/minor (Cannot boot)

#23 2011-12-05 14:24:55

Re: Root major/minor (Cannot boot)

#24 2011-12-07 06:18:11

Re: Root major/minor (Cannot boot)

#25 2011-12-07 20:54:01

Re: Root major/minor (Cannot boot)

Board footer