wheezy kirkwood / u-boot / raid1 und lvm

09/04/2014 - 02:20 von Stefan Eberhardt | Report spam
Hallo,
ich knobele an einem Problem mit einem QNAP-NAS, welches ich mit wheezy
geflasht habe. Das Teil funktioniert mit u-boot. Die initramfs liegt
damit im Flash-Speicher und es gibt kein Grub und keinen Bootsektor.

Die Einrichtung erfolgte mit 2 Festplatten als RAID1 und LVM.
Also es existiert md0 auf dem ein PV mit entsprecenden LVs angelegt
wurde. Alles aus dem Debian-Installer heraus.
Als Festplatten wurde zunàchst eine 750Gb und eine 1TB Platte verwendet.
Die Partitionen sind als msdos angelegt. Auf der 1TB Platte wurde
nàtürlich die identische 750Gb Part. angelegt.
Hier die Ausgaben von sfdisk:

root@IDUN1:~# sfdisk -d /dev/sda
# partition table of /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size65145344, Id=fd
/dev/sda2 : start= 0, size= 0, Id= 0
/dev/sda3 : start= 0, size= 0, Id= 0
/dev/sda4 : start= 0, size= 0, Id= 0
root@IDUN1:~# sfdisk -d /dev/sdb
# partition table of /dev/sdb
unit: sectors

/dev/sdb1 : start= 2048, size65145344, Id=fd
/dev/sdb2 : start= 0, size= 0, Id= 0
/dev/sdb3 : start= 0, size= 0, Id= 0
/dev/sdb4 : start= 0, size= 0, Id= 0

Die nàchsten Versuche sind durchaus erfolgreich verlaufen.
1) Auschalten -> sdb entfernen -> booten -> funktioniert -> alles wieder
syncen -> prima
2) Auschalten -> sda entfernen -> booten -> funktioniert -> alles
wieder syncen -> prima

Das raid1 làsst sich problemlos wieder herstellen und alles ist wie gedacht.

Nun der nàchste Test. Apparat gestoppt und sdb (die 1TB Platte) entfernt
und durch eine 750Gb ersetzt -> wieder gebootet (von sda) und die sdb
initialisiert. Dazu wie folgt:

dd if=/dev/zero of=/dev/sdb bsQ2 count=0
sfdisk -d /dev/sda | sfdisk /dev/sdb

Nun das Raid wieder gebaut:
mdadm --manage /dev/md0 --add /dev/sdb1

Funktioniert alles prima und raid ist wieder i.O.

Nun der boot-test mit fehlender sda und alles ist futsch :-(

Es ist nicht möglich von der sdb zu booten. Der Bootvorgang bleibt
einfach stecken. Da am QNAP weder Bildschirm noch Console vorhanden sind
ist auch keine Fehleranalyse möglich. Ich gehe davon aus das /boot nicht
gefunden wird, da bei spàterer Kontrolle keinerlei log-Meldungen
vorhanden sind und es denke ich überhaupt nie bis zum Kernel gekommen ist.
Habe alles probiert was mir dazu einfàllt:
1) update-initramfs -u
2) sdb zu sda gemacht indem der Slot getauscht wurde
3) die Erzeugung von sdb wiederholt um zufàllige Fehler auszuschließen
4) die UUID des arrays mit der in der mdadm.conf verglichen -> stimmt
5) die Raid-Ausgaben mdadm -E /dev/sda1 und /dev/sdb1 angeschaut ->
sieht für mich total o.K. aus
6) lange darüber nachgedacht
7) in dem Bereich udev und LVM gesucht -> mmmmh -> keine Auffàlligkeiten
wie spezielle rules oder so -> habe aber auch nicht den totalen
Überblick wonach ich eigentlich suche
8) stundenlang gegoogelt
9) nochmal nachgedacht
10) knapp vor Nase voll

Wenn ich wieder die ürsprüngliche 1TB Platte als sdb benutze,
funktioniert alles wie eingangs beschrieben. Es kann doch eigentlich nur
sein, dass irgendwo der Platentyp hinterlegt wird und demzufolge von der
Ersatzplatte kein boot erfolgreich wird.
Wo muß ich suchen? So hilft mir das Raid noch nicht wirklich.
Achso - es ist eine QNAP TS421 und Debian kirkwood mit Kernel
root@IDUN1:~# uname -r
3.2.0-4-kirkwood

Hat jemand eine Tip?

Gruß
Stefan


Zum AUSTRAGEN schicken Sie eine Mail an debian-user-german-REQUEST@lists.debian.org
mit dem Subject "unsubscribe". Probleme? Mail an listmaster@lists.debian.org (engl)
Archive: https://lists.debian.org/0MGj8j-1WlAbT4ATZ-00DYwE@mail.gmx.com
 

Lesen sie die antworten

#1 Uwe Kleine-König
09/04/2014 - 17:00 | Warnen spam
On 04/09/2014 02:17 AM, Stefan Eberhardt wrote:
Hat jemand eine Tip?


http://www.cyrius.com/debian/kirkwo...19/serial/

oder network console.

Liebe Grüße
Uwe


Zum AUSTRAGEN schicken Sie eine Mail an
mit dem Subject "unsubscribe". Probleme? Mail an (engl)
Archive: https://lists.debian.org/

Ähnliche fragen