[Arch] Booten van raid 0 lukt opeens niet meer

[Crakie]

Mijn Arch-installatie op een software raid0-array functioneerde enkele maanden prima. Maar vandaag kreeg ik vlak na het laden van de ramdisk een kernel panic. Ik dacht: dan zal de raid0 wel naar z'n grootje zijn, maar vanuit Ubuntu en de Arch installatie cd kan ik hem prima assemblen (met mdadm) en mounten. Ik heb vervolgens een nieuwe ramimage gemaakt door in Arch te chrooten en mkinitcpio te runnen. Dat gaf geen errors. Maar na Grub aangepast te hebben om die image te booten, krijg ik nog altijd een kernel panic. De error is:

code:

Cannot open root device md4(9,4)

en vervolgens de gebruikelijke attempt to kill init dingen.

Iemand een idee hoe zo'n array opeens niet meer werkt? En hoe ik dit zonder reinstall kan oplossen?

relevante info:

- mkinitcpio.conf

code:

# 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

code:

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

- Output mdadm -D --scan:

code:

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

- Relevant deel van Grub:

code:

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

- De output van fdisk -l wisselt. Ik heb vier drives, maar disk 1 krijgt op dag a bijvoorbeeld /dev/sda toegewezen en na een boot op dag b /dev/sdd. Ubuntu lijkt er geen last van te hebben. Arch misschien wel? Is er misschien een bios setting die dat voorkomt?

[Verwijderd]

Ik heb vier drives, maar disk 1 krijgt op dag a bijvoorbeeld /dev/sda toegewezen en na een boot op dag b /dev/sdd. Ubuntu lijkt er geen last van te hebben. Arch misschien wel? Is er misschien een bios setting die dat voorkomt?

Daar moet haast het probleem wel liggen, lijkt mij. Dit is ook echt raar zeg, zoiets hoor ik voor het eerst. Weet je zeker dat /dev/sda en /dev/sdb tijdens de boot wel echt (fysiek dus ook) je schijven uit je RAID set zijn?

[Crakie]

Daar moet haast het probleem wel liggen, lijkt mij. Dit is ook echt raar zeg, zoiets hoor ik voor het eerst. Weet je zeker dat /dev/sda en /dev/sdb tijdens de boot wel echt (fysiek dus ook) je schijven uit je RAID set zijn?

Nee, dat weet ik dus inderdaad niet. Moet wel iets met mijn Abit AB9 Pro mobo te maken hebben, lijkt me. Maar ik weet dat hoe de assignment ook is, de twee schijven waarop de raidpartities staan altijd opeenvolgend zijn (nou ja, ik heb nooit anders gezien iig). Er zijn dus niet zo veel combinaties (/dev/sda7 + sdb7, sdb7 + sdc7, sdc7 + sdd7) en die heb ik allemaal doorlopen. Je raadt het al: dat werkt niet. Het probleem is (denk ik) dat zodra ik die parameters wijzig, de informatie niet meer strookt met de info in de ramimage.

Wel raar dat Ubuntu er geen last van heeft.