nach squeez-update probleme beim booten von uuid

[xray]

hallo zusammen,

ich hab ein upgrade von lenny auf squeeze (soweit erfolgreich) durchgeführt. nach ein paar erfolgreichen neustarts blieb er dann aber beim hochfahren stehen, weil er nicht das richtige root-device gemountet hat.

kurz meine "normale" disk-config:

onboard-controller:
- sda (root)
- sdb (data1)

promise-sata 300 controller
- sdc (data2)
- sde (data3)

manchmal vertauscht er nun die reihenfolge, welcher controler zuerst geladen wird und somit
läd er dann auch mal sdc als root partition und startet dann das system nicht mehr.

um den fehler zu beseitigen wollte ich alles auf uuid umstellen aber hier findet er nicht das device bzw. die uuid für die root partition.

wenn das system im recovery mode oben ist, sieht es wie folgt aus:

blkid
/dev/sdb1: UUID="cc9d3724-0822-4466-a32f-f44316a3f237" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdc1: UUID="5cf06521-08f5-4d63-90c5-dc8a8ef117d4" SEC_TYPE="ext2" TYPE="ext3"
/dev/sdd1: UUID="13478092-0fea-4519-ba3b-40e9c6df00b5" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda1: UUID="c5f698e5-fdbe-42ec-941c-240a92674472" SEC_TYPE="ext2" TYPE="ext3"
/dev/sda5: UUID="f1cf099e-3043-4829-b350-366ecfd97a70" TYPE="swap"


ll /dev/disk/by-uuid/
total 0
drwxr-xr-x 2 root root 120 Mar 27 03:03 .
drwxr-xr-x 5 root root 100 Mar 27 03:03 ..
lrwxrwxrwx 1 root root 10 Mar 27 03:03 13478092-0fea-4519-ba3b-40e9c6df00b5 -> ../../sdd1
lrwxrwxrwx 1 root root 10 Mar 27 03:03 5cf06521-08f5-4d63-90c5-dc8a8ef117d4 -> ../../sdc1
lrwxrwxrwx 1 root root 10 Mar 27 03:03 cc9d3724-0822-4466-a32f-f44316a3f237 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Mar 27 03:03 f1cf099e-3043-4829-b350-366ecfd97a70 -> ../../sda5

... hier fehlt die uuid für sda1 ...

wenn der boot schief geht, lande ich ja in dieser abgespeckten umgebung (mir fällt der name gerade nicht ein) - naja wenn ich dort
ls -la /dev/disk/by-uuid absetzte sieht es genauso aus - es fehlt die uuid für sda1 bzw. sdc1 obwohl diese unter /dev existieren.
wenn ich in dieser umgebung blkid eingebe steht dort, wo ich eigentlich die uuid für sda1 erwarte "jmicron_raid_member" ... oder sowas ähnliches.

kann mir jemand an dieser stelle weiter helfen ?

Code: Alles auswählen

### BEGIN /etc/grub.d/10_linux ###
menuentry 'Debian GNU/Linux, with Linux 2.6.32-5-686' --class debian --class gnu-linux --class gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set c5f698e5-fdbe-42ec-941c-240a92674472
        echo    'Loading Linux 2.6.32-5-686 ...'
        linux   /boot/vmlinuz-2.6.32-5-686 root=UUID=c5f698e5-fdbe-42ec-941c-240a92674472 ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-2.6.32-5-686
}

mit dieser config steigt er mir aus -> Alert /dev/disk/by-uuid/c5f698e5-fdbe-42ec-941c-240a92674472 does not exist.

zur zeit lade ich mein system mit folgender config und altem kernel:

Code: Alles auswählen

menuentry 'Debian GNU/Linux, with Linux 2.6.26-2-686' --class debian --class gnu-linux --class gnu --class os {
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy
        echo    'Loading Linux 2.6.26-2-686 ...'
        linux   /boot/vmlinuz-2.6.26-2-686 root=/dev/sda1 ro  quiet
        echo    'Loading initial ramdisk ...'
        initrd  /boot/initrd.img-2.6.26-2-686
}

[micros]

Hallo,
ich hatte ein ähnliches Problem mit 5 Festplatten am onboard-Controller. Die Gerätebezeichnungen funtionierten immer, die uuids nicht beim Kaltstart, sondern erst nach einiger Zeit.
Da weitere unverständliche Fehler sich häuften, habe ich 3 Festplatten abgehängt. Seit 4 Wochen funktioniert wieder alles mit 2 Festplatten, auch die uuids. Ob es am Controller oder am Bios lag, ist noch unklar.
Gruß micros

[xray]

den fehler mit den uuid konnte ich soweit eingrenzen.
mein system erkennt die uuid für die root partition nicht sauber - egal in welchem betriebsystemzustand (grub, lenny oder squeeze)

die standard ausgabe ist leicht irreführend, da im cachefile die uuid für die root-partition sauber hinterlegt ist (warum auch immer), wenn
ich aber am cachefile vorbei die informationen abfrage kommt folgende ausgabe:

Code: Alles auswählen

 blkid -p /dev/sda1
/dev/sda1: PTTYPE="dos" VERSION="64.250" TYPE="jmicron_raid_member" USAGE="raid"

Debug

Code: Alles auswählen

BLKID_DEBUG=0xffff blkid -p /dev/sda1
libblkid: debug mask set to 0xffff.
ready for low-probing, offset=0, size=637418041344
chain fullprobe superblocks: DISABLED
chain fullprobe topology: DISABLED
chain fullprobe partitions: ENABLED
--> starting probing loop [PARTS idx=-1]
        buffer read: off=0 len=1024
        reuse buffer: off=0 len=1024
        reuse buffer: off=0 len=1024
        reuse buffer: off=0 len=1024
dos: magic sboff=510, kboff=0
dos: ---> call probefunc()
        reuse buffer: off=0 len=1024
dos: <--- (rc = 0)
assigning PTTYPE [partitions]
<-- leaving probing loop (type=dos) [PARTS idx=3]
chain safeprobe superblocks ENABLED
--> starting probing loop [SUBLKS idx=-1]
[0] linux_raid_member:
        call probefunc()
        buffer read: off=637417947136 len=64
        buffer read: off=637418033152 len=64
        reuse buffer: off=0 len=1024
        buffer read: off=4096 len=64
[1] ddf_raid_member:
        call probefunc()
        buffer read: off=637418040832 len=40
        buffer read: off=637417909760 len=40
[2] isw_raid_member:
        call probefunc()
        buffer read: off=637418040320 len=48
[3] lsi_mega_raid_member:
        call probefunc()
        reuse buffer: off=637418040832 len=40
[4] via_raid_member:
        call probefunc()
        buffer read: off=637418040832 len=51
[5] silicon_medley_raid_member:
        call probefunc()
        buffer read: off=637418040832 len=292
[6] nvidia_raid_member:
        call probefunc()
        reuse buffer: off=637418040320 len=48
[7] promise_fasttrack_raid_member:
        call probefunc()
        buffer read: off=637418009088 len=24
        buffer read: off=637417910784 len=24
        buffer read: off=637417910272 len=24
        reuse buffer: off=637418033152 len=64
        buffer read: off=637417837056 len=24
[8] hpt45x_raid_member:
        call probefunc()
        buffer read: off=637418035712 len=4
[9] hpt37x_raid_member:
        buffer read: off=4096 len=1024
        reuse buffer: off=4096 len=1024
[10] adaptec_raid_member:
        call probefunc()
        buffer read: off=637418040832 len=512
[11] jmicron_raid_member:
        call probefunc()
        reuse buffer: off=637418040832 len=40
assigning VERSION [superblocks]
assigning TYPE [superblocks]
assigning USAGE [superblocks]
<-- leaving probing loop (type=jmicron_raid_member) [SUBLKS idx=11]
chain safeprobe topology DISABLED
chain safeprobe partitions DISABLED
returning PTTYPE value
/dev/sda1: PTTYPE="dos" returning VERSION value
VERSION="64.250" returning TYPE value
TYPE="jmicron_raid_member" returning USAGE value
USAGE="raid"
reseting probing buffers
buffers summary: 68719480059 bytes by -5229111856484974207 read() call(s)

jat jemand eine idee wie ich verhindern kann, dass er die platte als raid-meber erkennt ohne die platte neu zu formatieren ?

[rhHeini]

Mal ne dumme Idee (vielleicht), Du sagst es dauert etwas mit der uuid-Erkennung: verpass Deiner Kernelzeile doch mal einen rootdelay=15 als Option. Vielleicht hilfts. Habe es bei Squeeze aber noch nicht probiert, Etch und Lenny funzt damit.

Mfg rh

[xray]

Ich danke Dir für den Tip, leider funktioniert die UUID-Erkennung für die Root-Partition überhaupt nicht