[geloest] mdadm problem nach Kernel upgrade

[synapsenstau]

Moinsen,

ich bin nun letztes Wochennende nach langjähriger Ubuntuzugehörigkeit zu Debian wheezy gewechselt. Die Installation hat soweit geklappt und fast alles lief. Leider musste ich feststellen, das ein geliebtes Programm leider in enier zu alten Version vorlag. Was tun sprach Zeus, die Götter sind besoffen?
Kurz und gut...die Paketquellen auf jessie geändert und das Upgrade gemacht. Das lief auch ohne Probleme durch aber das erwachen kam nach dem nächsten Reboot. mit dem 3.2er Kernel läuft alles wunderbar, aber wenn ich den 3.11er nehme, wird mein Software Raid-1 via mdadm nicht erkannt. Warum???
Ein reinstall des Kernel hat auch keine abhilfe geschaffen.

Was muss ich wo machen, damit es wieder funzt?

[rendegast]

und das Upgrade gemacht.

'*** dist-upgrade' ?

Ein reinstall des Kernel hat auch keine abhilfe geschaffen.

Status?

Code: Alles auswählen

dpkg -l | egrep -v "^ii" 

Dieses Modul ehci-orion existiert so scheinbar nicht in debian.
3rd-Party?

[synapsenstau]

und das Upgrade gemacht.

'*** dist-upgrade' ?

ja

Ein reinstall des Kernel hat auch keine abhilfe geschaffen.

Status?

Code: Alles auswählen

dpkg -l | egrep -v "^ii" 

Dieses Modul ehci-orion existiert so scheinbar nicht in debian.
3rd-Party?

Hier die dpkg Ausgabe:

Code: Alles auswählen

Gewünscht=Unbekannt/Installieren/R=Entfernen/P=Vollständig Löschen/Halten
| Status=Nicht/Installiert/Config/U=Entpackt/halb konFiguriert/
         Halb installiert/Trigger erWartet/Trigger anhängig
|/ Fehler?=(kein)/R=Neuinstallation notwendig (Status, Fehler: GROSS=schlecht)
||/ Name                                  Version                                 Architektur  Beschreibung
+++-=====================================-=======================================-============-=======
rc  kdepim-groupware                      4:4.4.11.1+l10n-3+b1                    amd64        KDE PIM Groupware plugins
rc  libaudit0                             1:1.7.18-1.1                            amd64        Dynamic library for security auditing
rc  libcupsdriver1:amd64                  1.5.3-5+deb7u1                          amd64        Common UNIX Printing System(tm) - Driver library
rc  libescpr1:amd64                       1.1.1-2                                 amd64        printer driver for Epson Inkjet - shared library
rc  libexttextcat0                        3.2.0-2                                 amd64        Language detection library
rc  libgraphite2-2.0.0                    1.1.3-1                                 amd64        Font rendering engine for Complex Scripts -- library
rc  libpackagekit-glib2-14:amd64          0.7.6-3                                 amd64        Library for accessing PackageKit using GLib
rc  libpackagekit-qt2-2:amd64             0.7.6-3                                 amd64        Library for accessing PackageKit using Qt4
rc  libplasmaclock4abi3                   4:4.8.4-6                               amd64        library for Plasma clocks
rc  libreoffice-filter-binfilter          1:3.5.4+dfsg2-0+deb7u2                  amd64        office productivity suite -- legacy filters (e.g. StarOffice 5.2)
rc  libsnmp15                             5.4.3~dfsg-2.7                          amd64        SNMP (Simple Network Management Protocol) library
rc  libtaskmanager4abi3                   4:4.8.4-6                               amd64        library which provides task management facilities
rc  libvlccore5                           1:2.0.6-dmo1                            amd64        base library for VLC and its modules
rc  libxvmcnvidia1:amd64                  304.88-1+deb7u1                         amd64        NVIDIA binary XvMC library
rc  user-setup                            1.48                                    all          Set up initial user and password

Wie ich jetzt selber sehe, gibt es da wohl noch ein paar Probleme, die gelöst werden wollen, aber nichts was aus meiner sicht richtung mdadm / kernel weist.

[rendegast]

Wie sieht denn die mdadm.conf nun aus?

Wird sie so in die initrd übernommen, gegebenfalls mal eine Neuerstellung

Code: Alles auswählen

update-initramfs -u -kall

(Meldungen?)
-> den Zeitstempel prüfen

Code: Alles auswählen

ls -i /boot/init*

Unterscheiden sich die menuentry für die Kernel in /boot/grub/grub.cfg?
(Denke ich eigentlich nicht)

Existieren in /etc/ Dateien *dpkg*, die eventuell angepaßt werden müssen?

Code: Alles auswählen

find /etc -type f | grep dpkg

Ein wenig stört mich auch die Meldung mit dem nichtladbaren Modul microcode.
Hier für einen doch betagten Pentium III (Coppermine):

Code: Alles auswählen

# dmesg | grep -i microcode
[    3.075839] microcode: CPU0 sig=0x68a, pf=0x20, revision=0x4
[    3.360340] platform microcode: firmware: agent loaded intel-ucode/06-08-0a into memory
[    3.747695] microcode: Microcode Update Driver: v2.00 <tigran@aivazian.fsnet.co.uk>, Peter Oruba

(Kernel 3.11 wheezy-backports)

[synapsenstau]

Wie sieht denn die mdadm.conf nun aus?

Code: Alles auswählen

# mdadm.conf
# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, using
# wildcards if desired.
#DEVICE partitions containers

# auto-create devices with Debian standard permissions
CREATE owner=root group=disk mode=0660 auto=yes

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays
ARRAY /dev/md/0 metadata=1.2 UUID=64c3ac64:fb57fa22:7ba44ecf:7079da39 name=ssn:0
ARRAY /dev/md/1 metadata=1.2 UUID=97594743:d1b1bbaf:ae321a8c:8e8e997b name=ssn:1

# This file was auto-generated on Sun, 15 Dec 2013 11:43:13 +0100
# by mkconf 3.2.5-5

Wird sie so in die initrd übernommen, gegebenfalls mal eine Neuerstellung

Code: Alles auswählen

update-initramfs -u -kall

(Meldungen?)

Code: Alles auswählen

update-initramfs: Generating /boot/initrd.img-3.11-2-amd64
update-initramfs: Generating /boot/initrd.img-3.2.0-4-amd64

-> den Zeitstempel prüfen

Code: Alles auswählen

ls -i /boot/init*

Code: Alles auswählen

22 /boot/initrd.img-3.11-2-amd64  21 /boot/initrd.img-3.2.0-4-amd64

Unterscheiden sich die menuentry für die Kernel in /boot/grub/grub.cfg?
(Denke ich eigentlich nicht)

Code: Alles auswählen

menuentry 'Debian GNU/Linux, mit Linux 3.11-2-amd64' --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root b16c22fe-85b9-4a0f-bb32-20a80b74cb22
        echo    'Linux 3.11-2-amd64 wird geladen …'
        linux   /vmlinuz-3.11-2-amd64 root=UUID=d6636fb6-630d-4efa-94d5-c696005c3586 ro nodmraid quiet
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /initrd.img-3.11-2-amd64
}
menuentry 'Debian GNU/Linux, mit Linux 3.11-2-amd64 (Wiederherstellungsmodus)' --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root b16c22fe-85b9-4a0f-bb32-20a80b74cb22
        echo    'Linux 3.11-2-amd64 wird geladen …'
        linux   /vmlinuz-3.11-2-amd64 root=UUID=d6636fb6-630d-4efa-94d5-c696005c3586 ro single nodmraid
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /initrd.img-3.11-2-amd64
}
menuentry 'Debian GNU/Linux, mit Linux 3.2.0-4-amd64' --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root b16c22fe-85b9-4a0f-bb32-20a80b74cb22
        echo    'Linux 3.2.0-4-amd64 wird geladen …'
        linux   /vmlinuz-3.2.0-4-amd64 root=UUID=d6636fb6-630d-4efa-94d5-c696005c3586 ro nodmraid quiet
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /initrd.img-3.2.0-4-amd64
}
menuentry 'Debian GNU/Linux, mit Linux 3.2.0-4-amd64 (Wiederherstellungsmodus)' --class debian --class gnu-linux --class gnu --class os {
        load_video
        insmod gzio
        insmod part_msdos
        insmod ext2
        set root='(hd0,msdos1)'
        search --no-floppy --fs-uuid --set=root b16c22fe-85b9-4a0f-bb32-20a80b74cb22
        echo    'Linux 3.2.0-4-amd64 wird geladen …'
        linux   /vmlinuz-3.2.0-4-amd64 root=UUID=d6636fb6-630d-4efa-94d5-c696005c3586 ro single nodmraid
        echo    'Initiale Ramdisk wird geladen …'
        initrd  /initrd.img-3.2.0-4-amd64
}

Existieren in /etc/ Dateien *dpkg*, die eventuell angepaßt werden müssen?

Code: Alles auswählen

find /etc -type f | grep dpkg

Code: Alles auswählen

/etc/cron.daily/dpkg
/etc/dpkg/dpkg.cfg
/etc/dpkg/origins/debian
/etc/logrotate.d/dpkg
/etc/ca-certificates.conf.dpkg-old
/etc/apt/apt.conf.d/10periodic.dpkg-old

So, werde jetzt neustarten und mich gleich wieder melden. War nen Live edit,

Edit: Habe nun Resettet und es ist alles wie beim alten gelblieben. 3.2er geht, 3.11er selbe Fehlermeldung,

[rendegast]

Mal /etc/default/grub
GRUB_DISABLE_LINUX_UUID=true
-> 'update-grub'
evtl. auch 'update-initramfs -u -kall'

(im Netz was von einem mdadm/udev/initramfs-Bug gelesen (wobei da aber keine Kernel-Abhängigkeit erwähnt wurde)
http://debian.2.n7.nabble.com/linux-ima ... 77067.html)


----------------------------------------------------

Code: Alles auswählen

ls -i /boot/init*

sollte eigentlich ein 'ls -l ....' sein, aber da 'update-initramfs' ohne Meldung durchgelaufen ist,
wurden die initrd wohl auch neu kreiiert.

[synapsenstau]

Mal /etc/default/grub
GRUB_DISABLE_LINUX_UUID=true

gemacht, bei der gelegenheit gleich das nodmraid gelöscht. War bei Ubuntu immer notwendig, da es immer mit aller Gewalt versucht hat mein nicht benutztes Nvidia-Board Fake-Raid zu laden

-> 'update-grub'
evtl. auch 'update-initramfs -u -kall'

Beides zum wiederholten male nach Änderung angewendet.
Hat aber alles kein erfolg gebracht.
Habe auch mal in die /etc/initramfs-tools/modules mal nen raid1 eingetragenn selbige geupdatet.......kein Erfolg,
Busybox:
Ein cat/proc/mdstat hat ein leeres file ergeben
Ein ls /dev/disk/by-uuid hat fehlende md(0/1) devices ergeben. Beide eigentlich raid1, einmal als / und einmal als /home. /boot hat extra, um Problemen vorzubeugen, ne eigene ext4 gekriegt.

(im Netz was von einem mdadm/udev/initramfs-Bug gelesen (wobei da aber keine Kernel-Abhängigkeit erwähnt wurde)
http://debian.2.n7.nabble.com/linux-ima ... 77067.html)

ja, habe auch gehört das mdadm hier und da ein bischen buggy sein soll.
Diesen Bug
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=411172
kenne ich schon von früher. Als das Board neu war, hatte ich mal ne Zeit lang nen Nvidia-Fake-Raid-5 laufen. Das ist aber seit Jahren Geschichte und bezog sich auf nen Fehler in dmraid und einer fehlenden "6" (module dmraid45 und dmraid456)
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718533
finde ich etwas konfus, weil er von nem mischmasch zw. dm-raid und md-raid hat und lt. seiner Aussage nur die "md" version nutzt(en will).
HAbe aber mal nen rootdelay=5 gesetzt.....reboot steht aber noch aus ---> Live-edit

----------------------------------------------------

Code: Alles auswählen

ls -i /boot/init*

sollte eigentlich ein 'ls -l ....' sein, aber da 'update-initramfs' ohne Meldung durchgelaufen ist,
wurden die initrd wohl auch neu kreiiert.

nur zur info:

Code: Alles auswählen

-rw-r--r-- 1 root root 13739511 Dez 17 10:34 /boot/initrd.img-3.11-2-amd64
-rw-r--r-- 1 root root 11630151 Dez 17 10:34 /boot/initrd.img-3.2.0-4-amd64

Ich danke dir aber schon mal für die Ausführliche hilfe.....

[synapsenstau]

Jippyyjeahhhhh, es funzt. Das rootdelay=5 hats gebracht. Ich danke dir für für den hinweis auf die/den Bugreport(s). Ich scheue mich immer sie zu lesen, da mein Englisch nicht das Beste ist.

rendegast

Beweis:

Code: Alles auswählen

uname -r
3.11-2-amd64

Wenn ich mal wieder bock auf ne Reboot Session habe werde ich es vielleicht noch mal verkleiern, aber die 5s machen den Kohl auch nicht fett.