You are not logged in.
Pages: 1
This problem seems to have sprung up from no where. A while ago, back while the Viper Kernel was still being produced, I was using it without a problem for months. All of a sudden, one day I goto boot (I'm assuming after a kernel upgrade) and I come to the following: Before everyone jumps all over, yes I've searched, yes I've tried passing rootfstype=reiserfs, still nothing. The same thing.
Loading root filesystem module...
Attempting to create root device name for '/dev/sda3'
unknown
ERROR: root fs cannot be detected. Try using the rootfstype=kernel parameter
Waiting for device to settle...done
Root device '/dev/sda3' doesn`t exist, attempting to create it
ERROR: Failed to parse block device name for '/dev/sda3'
ERROR: Unable to create/detect root device '/dev/sda3'
Dropping to a recovery shell
NOTE: klibc contains no 'ls' binary
.
.
.
ramfs$
Basically, I found out through messing with it that viperkernel-fallback image worked fine and let me boot into my system. Well, after a while I got sick of booting off the fallback image because obviously, something isn't setup right. I went back to a stock kernel, and it loads fine, no fallback needed.
Tonight, I decided that the error I used to get must have been something related to just Viper patchset, so I tried out another kernel tonight. Bam! Same problem again, only this time fallback image for the new kernel doesn't work, stock still works perfect.
I figure this has to be a problem with mkinitcpio. There's no other explanation. I always compile my file system into the kernel instead of modules, so that shouldn't be a problem either. Arch is the first distro I've used that uses this damn mkinicpio, and I've never liked it, however it's part of the system and I've learned to live with it.
I've tried using the mkinitcpio -M and putting the modules in mkinitcpio.conf, but upon creating the image, it says that all those loaded modules aren't found.
So, I don't know wtf is going on but it's annoying the hell outta me. I don't wanna be stuck with the stock kernel when others are available to be used. I never used to have this problem, why all of a sudden? Thanks for any help. And because I'm sure people will ask, I'll post up my configs.
mkinitcpio.conf
# 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="amd74xx generic sata_nv"
# BINARIES
# This setting includes, into the CPIO image, and additional
# binaries a given user may wish. This is run first, so may
# be used to override the actual binaries used in a given hook.
# (Existing files are NOT overwritten is already added)
# BINARIES are dependancy 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 anyway. This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options,
# like so:
# FILES="/etc/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
# 'modload' may be used in place of 'udev', but is not recommended
# '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 ide scsi sata filesystems"
#
# This setup will generate a 'full' image which supports most systems.
# No autodetection is done.
# HOOKS="base udev ide scsi sata usb filesystems"
#
# This setup assembles an ide raid array with an encrypted root FS.
# Note: See 'mkinitcpio -H raid' for more information on raid devices.
# HOOKS="base udev ide raid encrypt filesystems"
#
# This setup loads an lvm2 volume group on a usb device.
# HOOKS="base udev usb lvm2 filesystems"
#HOOKS="base udev autodetect ide scsi sata keymap filesystems"
HOOKS="base udev autodetect sata keymap filesystems"
menu.conf
timeout 5
default 1
color light-blue/black light-cyan/blue
# boot sections follow
# each is implicitly numbered from 0 in the order of appearance below
#
# TIP: If you want a 1024x768 framebuffer, add "vga=773" to your kernel line.
#
#-*
# (0) Arch Linux -KamiKaze Kernel
title Arch Linux - KamiKaze Kernel Patchset
root (hd0,0)
kernel /vmlinuz26kamikaze root=/dev/sda3 ro
initrd /kernel26kamikaze.img
(0) Arch Linux
title Arch Linux - Stock Kernel
root (hd0,0)
kernel /vmlinuz26 root=/dev/sda3 ro
initrd /kernel26.img
fstab
none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/fd0 /mnt/fl vfat user,noauto 0 0
/dev/sda1 /boot ext2 defaults 0 1
/dev/sda2 swap swap defaults 0 0
/dev/sda3 / reiserfs noatime 0 0
/dev/hda1 /Backup/Media ntfs-3g defaults,rw,nosuid,nodev,noatime,allow_oth 0 0
/dev/sdb1 /Backup/Apps vfat defaults,users,umask=000
/dev/hdb1 /Backup/Misc vfat defaults,users,umask=000
Thanks for any help anyone can offer
Last edited by Acid7711 (2007-08-13 18:29:03)
Offline
Come on! No one has any ideas for this? Google 'ERROR: root fs cannot be detected' and you'll come up with only Arch related topics.
Offline
Perhaps using caps in one case for Kamikaze an lower case in another is related to your difficulty?
Prediction...This year will be a very odd year!
Hard work does not kill people but why risk it: Charlie Mccarthy
A man is not complete until he is married..then..he is finished.
When ALL is lost, what can be found? Even bytes get lonely for a little bit! X-ray confirms Iam spineless!
Offline
try adding 'earlymodules=piix' w/o quotes to your kernel line and see if that helps.
edit: also, i wouldn't remove ide and scsi from hooks. I'm not that familiar with mkinicpio, but i did the same thing for my laptop and ended up with problems.
Last edited by tardo (2007-08-12 05:49:54)
Offline
Too late. I got tired of waiting and wiped everything for a reinstall. I'll see if this fixes the problem.... If not, I'll post back.
Offline
Perhaps using caps in one case for Kamikaze an lower case in another is related to your difficulty?
What are you talking about? The title and commented out line? The kernel boots, it just fails.
try adding 'earlymodules=piix' w/o quotes to your kernel line and see if that helps.
edit: also, i wouldn't remove ide and scsi from hooks. I'm not that familiar with mkinicpio, but i did the same thing for my laptop and ended up with problems.
I didn't do that, that's how it came on my system. I just tried your suggestion, same result. No go.
Lastnight I downloaded the newest ISO and reinstalled everything after a wipe. I'm still having this problem. Am I stuck only using a stock kernel now?
For an update, after the reinstall, this is my new mkinitcpio.conf
# 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="pata_amd ata_generic sata_nv"
# BINARIES
# This setting includes, into the CPIO image, and additional
# binaries a given user may wish. This is run first, so may
# be used to override the actual binaries used in a given hook.
# (Existing files are NOT overwritten is already added)
# BINARIES are dependancy 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 anyway. This is useful for config files.
# Some users may wish to include modprobe.conf for custom module options,
# like so:
# FILES="/etc/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
# 'modload' may be used in place of 'udev', but is not recommended
# '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 ide scsi sata filesystems"
#
# This setup will generate a 'full' image which supports most systems.
# No autodetection is done.
# HOOKS="base udev ide scsi sata usb filesystems"
#
# This setup assembles an ide raid array with an encrypted root FS.
# Note: See 'mkinitcpio -H raid' for more information on raid devices.
# HOOKS="base udev ide raid 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 usbinput keymap filesystems"
Last edited by Acid7711 (2007-08-12 19:51:52)
Offline
I have a same problem as Acid7711. Only difference is that i haven't installed any custom kernels, only upgrade i have made is pacman -Syu. And after that everything worked fine, i got that error after my comp crashed for unknown reason and i tried to boot back to arch.
Offline
Yeah, I don't know what the problem is, but it's been bothering me for weeks, and after wasting entire days of trying different things and recompiling again and again and again, I've given up. Thanks to the overwhelming amount of help, I've since filed a bug report. Maybe they can find some insight into the problem since it seems to be with mkinitcpio.
More and more people are having this problem with stock kernels at install, and no one seems to take notice or care about it......
Last edited by Acid7711 (2007-08-13 07:56:25)
Offline
I am alsoo a arch noob but I had a similar problem and somehow managed to solve it, but I do not remember exactly how :-).
After a failed boot you are dropped in a recovery shell, try this command there:
cat /sys/block/*/dev
If you don't see any line starting with 8: then probably the driver for your disk has not been loaded. BTW what kind of disks are you using? sata?
Last edited by erm67 (2007-08-13 09:37:22)
Offline
I will try it and see what i get. And i'm not using sata, my root partition is on /dev/hda4.
I'm not sure is there line starting with 8 or not, because there are several lines of numbers, but i cant manage to scroll up to see them all.
Last edited by Kampsun (2007-08-13 09:44:31)
Offline
If your root is on /dev/hda4 probably also your error message is different. What does it says exactly? in particular the line:
ERROR: Failed to parse block device name for '/dev/sda3'
cat /sys/block/h*/dev to print all IDE device numbers
and maybe
cat /sys/block/s*/dev to print all SCSI device number in case your PATA disks are recognized as SCSI by libata
Offline
Everything in my error message is same except the '/dev/sda3' it's '/dev/hda4' for me. I will try
cat /sys/block/h*/dev and see what i get.
I got these numbers:
3:0
22:64
Last edited by Kampsun (2007-08-13 11:40:30)
Offline
BTW what kind of disks are you using? sata?
2 sata
2 Ide
and 1 ide dvdrw
Offline
3:0
22:64
3:0 is hda (the whole disk)
hda4 should be 3:4
and 22:64 is hdd (the whole disk) (a cd drive maybe mounted as slave on the second controller?)
so if you only find those 2 in the sys filesystem than probably the kernel cannot recognize your partitions.
Don't you see any error message when the kernel starts?
and cat /sys/block/s*/dev returns 'not found'?
Offline
2 sata
2 Ide
and 1 ide dvdrw
what do the commands return, run after the boot fails?
cat /sys/block/s*/dev
cat /sys/block/h*/dev
Offline
Acid7711 wrote:2 sata
2 Ide
and 1 ide dvdrwwhat do the commands return, run after the boot fails?
cat /sys/block/s*/dev
cat /sys/block/h*/dev
Nothing, I have loop0-6 and Ram0-15 in there. That's it.
Oh well, I'm done with this I guess. I guess I'll compile it without using an initrc image. Thanks for your help.
Offline
Nothing, I have loop0-6 and Ram0-15 in there. That's it.
Or try to find out why the kernel does not load the drivers for your disks At least now you know what to look for ...
I do not know arch enough to help you, anyway the probeblock fails if the device you specified with root=/dev/xxxx does not exists, find a way to make it exist and your problem should be solved.
Last edited by erm67 (2007-08-13 18:57:29)
Offline
Yeah, I've spent weeks messing with this, it's given me a lot of headaches. I think I'm done with it for a while.
Offline
My probably unhelpful theory:
This happens to me every time: the install CD uses sd* device names; the booting system uses hd* names, so I usually get a kernel panic like this the first boot because I always manage to forget to change the names in grub/menu.list and /etc/fstab.
The autodetect initcpio hook somehow has the ability to *prevent* modules from loading, so it might be thinking along the same lines as the install cd (that the drives get to be sd* and we don't need any IDE drivers so block them...), then it tries to load SCSI drivers for the IDE controller, which doesn't work, so no sd* disks...
remove the autodetect hook from your mkinitcpio.conf and put ide_core in the MODULES section. Also make sure you have 'ide' in hooks -- failing that, try adding 'pata' as well.
~Felix.
Offline
This happens to me every time: the install CD uses sd* device names; the booting system uses hd* names, so I usually get a kernel panic like this the first boot because I always manage to forget to change the names in grub/menu.list and /etc/fstab.
Ubuntu, one of the first distro to ship libata/pata (sd* names), solves this problem using UUID for the disks whenever possible, it suggests to use vol_id from the udev distribution (I could not find it in arch) to identify the disks. Anyway ls -l /dev/by-uuid is enough:
ermanno@archlinux:/home/ermanno$ ls -l /dev/disk/by-uuid/
total 0
lrwxrwxrwx 1 root root 10 2007-08-15 10:55 435E-72C7 -> ../../hdb1
lrwxrwxrwx 1 root root 10 2007-08-15 10:55 5A705153705136CB -> ../../hda1
lrwxrwxrwx 1 root root 10 2007-08-15 10:55 6e20254d-1da7-4ee0-8a87-42645016ba05 -> ../../hda7
lrwxrwxrwx 1 root root 10 2007-08-15 10:55 a0bae8c8-d275-4fae-9172-2592366dd9d3 -> ../../hda5
lrwxrwxrwx 1 root root 10 2007-08-15 10:55 b0e4845c-3ad1-40ab-b9e0-25b8bef36a27 -> ../../hda6
and my fstab looks like this:
#
# /etc/fstab: static file system information
#
# <file system> <dir> <type> <options> <dump> <pass>
UUID=6e20254d-1da7-4ee0-8a87-42645016ba05 / ext3 rw,noatime 1 0
UUID=a0bae8c8-d275-4fae-9172-2592366dd9d3 /boot ext2 rw,noauto 0 0
UUID=5A705153705136CB /mnt/winnt ntfs-3g rw,user,utf8,uid=ermanno,noauto 0 0
UUID=435E-72C7 /mnt/archive vfat rw,user,uid=ermanno,noauto 0 0
UUID=b0e4845c-3ad1-40ab-b9e0-25b8bef36a27 swap swap defaults 0 0
none /dev/pts devpts defaults 0 0
none /dev/shm tmpfs defaults 0 0
/dev/cdrom /mnt/cd iso9660 ro,user,noauto,unhide 0 0
/dev/dvd /mnt/dvd udf ro,user,noauto,unhide 0 0
/dev/fd0 /mnt/fl vfat user,noauto 0 0
This way no matter if my disks are called sd* or hd* the fstab is always right.
And in grub:
# (0) Arch Linux libata
title Arch Linux [/boot/vmlinuz26]
root (hd0,4)
kernel /vmlinuz26 root=/dev/disk/by-uuid/6e20254d-1da7-4ee0-8a87-42645016ba05 ro disablemodules=ntfs
initrd /kernel26-fallback.img
# (1) Arch Linux
title Arch Linux [/boot/vmlinuz26]
root (hd0,4)
kernel /vmlinuz26 root=/dev/disk/by-uuid/6e20254d-1da7-4ee0-8a87-42645016ba05 ro disablemodules=ntfs
initrd /kernel26.img
It looks like the old ide drivers in the kernel (/dev/hd*) are going to be abandoned completely and were not updated for months, most probably in a not too far future the disks will be all /dev/sd* and in the transition phase convert everything to uuid style can be helpful.
http://wiki.archlinux.org/index.php/Per … ice_naming
Last edited by erm67 (2007-08-16 07:59:52)
Offline
@erm67
you can use `blkid` to find the UUID's aswell.
\\ archlinux on a XPS M1530 //
Offline
Pages: 1