You are not logged in.

#1 2007-11-03 21:16:52

crakie
Member
Registered: 2007-06-03
Posts: 13

Arch won't boot from raid0 array all of a sudden (kernel panic)

I have Arch installed on a raid0 array. It worked fine until today, when I tried to boot and got a kernel panic right after the initrd image was loaded. I thought the array had broken down, but I can assemble and mount it just fine from Ubuntu or from the Arch install cd. I had a similar issue before in Ubuntu, which I solved by creating a new initrd image. So I went on and chrooted into the Arch installation, checked my config files and succesfully generated a new image with mkinitcpio. After modifying Grub to boot this image, I still get a kernel panic (error message: cannot open root device md4(9,4)).

I don't know if it is relevant or not, but the output of fdisk -l is not always the same (in Ubuntu). I have 4 drives and they tend to get assigned a different /dev/sdx after a boot. So one day disk 1 might get /dev/sda and the next /dev/sdd, for example. Ubuntu doesn't seem to mind, though. Perhaps Arch does? Perhaps there is a bios setting I could change in order to prevent it?

Anyway, I'd like to get rid of the error without reinstalling. Any ideas? Any suggestions to debug this are welcome too, of course.

Offline

#2 2007-11-04 19:57:23

Lone_Wolf
Forum Moderator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,929

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

grub 0.97 (arch default) has problems booting from software raid.

How are your raid partitions setup and are all drives on the same controller ?

Last edited by Lone_Wolf (2007-11-04 19:58:03)


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#3 2007-11-05 22:26:46

crakie
Member
Registered: 2007-06-03
Posts: 13

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

The raid partitions are setup using mdadm from two partitions on two Samsung Spinpoints drives connected to the same JMicron controller on an Abit AB9 Pro motherboard. Yes, I heard the stories about this controller not being all that great, but on my setup the raid performance was quite good. Besides, the Intel ICH8R (also on the Abit) wouldn't work properly.

As for Grub, I do use 0.97 (although I came with Ubuntu Feisty). But since Ubuntu isn't giving any problems, I doubt Grub is the problem.

Offline

#4 2007-11-05 22:44:56

somairotevoli
Member
Registered: 2006-05-23
Posts: 335

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

using grub (GNU GRUB 0.97) myself w/ software raid and have no problems.

Offline

#5 2007-11-06 22:23:49

Lone_Wolf
Forum Moderator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,929

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

please post details on your partition / raid setup.

Iirc Grub doesn't understand sw raid and the partition containing /boot needs to be available without raid functions.
On a raid 1 this is usually solved by putting /boot on all drives.

For a raid 0 /boot is likely accessible from the first drive in the array, but your description suggests the order the drives in the array are seen has changed, possibly caused by a kernel upgrade.


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#6 2007-11-07 19:59:53

crakie
Member
Registered: 2007-06-03
Posts: 13

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

Ah, sorry for the confusion. I DO have a separate /boot, NOT located on the array. I wasn't even aware it was possible to boot from raid 0 directly. So the setup of the Spinpoints is as follows:

/dev/sda6 ext2 /boot
/dev/sdb6 swap
/dev/sda7 + /dev/sdb7 reiserfs / (raid0)

/dev/sda1...5 and /dev/sdab1...5 in use by Ubuntu (boot, swap; /, data and mythtv partitions on raid0)

Now please note, while I designate these drives as /dev/sda and /dev/sdb here, they tend to change designation, for example to /dev/sdb and /dev/sdc (I have an additional two harddrives, both of which do not contain an OS). I do not think it has anything to do with kernel upgrades: if I turn off my computer and reboot the exact same OS, they could be changed (but not necessarily). As said, Ubuntu is not bothered by it, but Arch is. I suspect it has something to do with the designations being specified in mkinitcpio.conf and hence in the ramimage.

Here is some relevant output:

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="generic jmicron ahci ata_piix sata_sil24"

# 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="/etc/mdadm.conf"

# 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 raid autodetect ide scsi sata usbinput keymap filesystems"
md=4,/dev/sda7,/dev/sdb7

- mdadm.conf

ARRAY /dev/md4 level=raid0 num-devices=2 UUID=2af460c3:5f50d74d:c741cfa6:xxx


- Output mdadm -D --scan:

ARRAY /dev/md4 level=raid0 num-devices=2 UUID=2af460c3:5f50d74d:c741cfa6:xxx

- Grub:

Title           Arch
root           (hd0,5)
kernel        /vmlinuz26 root=/dev/md4 ro md=4,/dev/sda7,/dev/sdb7 rootfstype=reiserfs
initrd          /kernel26.img

Offline

#7 2007-11-07 22:51:24

Lone_Wolf
Forum Moderator
From: Netherlands, Europe
Registered: 2005-10-04
Posts: 11,929

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

At first glance i don't see something that could cause your problem, but i do see several things that make the boot process/mkinitrd more complicated than necessary.

- rootfstype on the kernel line in menu.lst is rarely needed and imo a dirty solution.
in my experience problems with rootfstype are usually caused by a misconfiguration in other config files, often mkinitcpio.conf .

Modules :
jmicron / ahci are probably needed to access the spinpoint drives, but i doubt generic / ata_piix / sata_sil24 are needed during boot.
On the other hand udev/autodetect do a great job.

Hooks
you are booting from sata raid drives
-  ide and scsi are probably not needed during boot
-  keymap is only needed if you use a non-us keymap.
- usbinput is only needed when you use an usb device (usually keyboard) that needs to be accessible during the initrd phase.

I recommend this for a test setup :
Grub
Title           Arch
root           (hd0,5)
kernel        /vmlinuz26 root=/dev/md4 ro md=4,/dev/sda7,/dev/sdb7
initrd          /kernel26.img


mkinitcpio.conf

MODULES=""
BINARIES=""
FILES="/etc/mdadm.conf"
HOOKS="base udev autodetect sata raid filesystems"
md=4,/dev/sda7,/dev/sdb7


Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.


(A works at time B)  && (time C > time B ) ≠  (A works at time C)

Online

#8 2007-11-08 02:35:55

somairotevoli
Member
Registered: 2006-05-23
Posts: 335

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

This may have nothing to do w/ it....

When I first set up my system, I choose reiserfs. I was getting the ": cannot open root device" error and after 4 reinstalls I finally decided to just try ext3. Well it worked after that. Not sure if it had to do w/ the filesytem I was choosing or I just got lucky;)

Offline

#9 2007-11-10 12:19:43

crakie
Member
Registered: 2007-06-03
Posts: 13

Re: Arch won't boot from raid0 array all of a sudden (kernel panic)

Thanks, Lone_Wolf, I will give it a shot and report back here with the results.

Offline

Board footer

Powered by FluxBB