Systempartition umziehen (GPT + Lilo)

[Meillo]

Hoi,

bisher sah das System so aus:

- 10 GB IDE HDD mit Debian stable drauf
- 2x 320 GB SATA RAID1 mit Daten

Ich will nun das System und die Daten umziehen auf:

- 2x 3 TB SATA RAID1 (Eine Systempartition, eine Datenpartition)

Die Daten sind kein Problem; eigentlich geht es nur um das System.

Die kritischen Punkte sind GPT (das fuer die 3 TB noetig ist) und dass ich weiterhin Lilo verwenden will (sofern irgendwie moeglich).

Das RAID kann erstmal aussen vor bleiben. Ich wuerde der Einfachheit halber erstmal alles auf einer Platte einrichten und mich ganz am Ende um das RAID kuemmern.

Getan habe ich bislang:

- Auf der neuen Platte mit parted(8) eine GPT und eine Partition (10 GB) angelegt.
- Mit dd(1) die alte Systempartition auf die neue Platte kopiert.
- Lilo dort neu installiert. (Da kamen Warnings. Die muss ich leider nochmal separat raus suchen.)

Dann habe ich die alte Platte abgehaengt und geschaut ob er bootet. Lilo hat gestartet, ist aber mit ``L 99 99 99 99 usw.'' haengen geblieben.

Ich weiss nun nicht recht an was es liegt. Im Netz findet man nur allerlei Schwammiges zur Frage, ob Lilo mit GPT zurecht kommt.


Hat von euch schon jemand Erfahrungen mit sowas gesammelt? Hat jemand Lilo mit GPT am Laufen? Und: Ist mein grundsaetzliches Vorgehen passend? Was gaebe es sonst fuer Wege?

[NAB]

(nein, keine praktische Erfahrung mit Lilo)

Eine GPT ist für 3TB-Platten nicht zwingend, solange du mit der Partitionierung etwas flexibel bist:
http://www.heise.de/ct/hotline/FAQ-3-TB ... 83299.html

Und zumindest Slackware ist der Meinung, dass Lilo mit GPT laufen sollte:
http://docs.slackware.com/howtos:slackw ... thout_uefi

Ich vermute, Lilo kommt durcheinander, wenn der Protective MBR der GPT größer als 2TB ist, weil sowas eigentlich nicht vorgesehen ist. Gemäß Slackware-How-To musst du dann in der /etc/lilo.conf nachhelfen.

Wurde das Mainboard auch ausgetauscht?

[habakug]

Hallo!

Der Error-Code "L 99 .." bedeutet laut Manpage [1]:

Errors 99 and 9A usually mean the map file (-m or map=) is not readable, likely because LILO was not re-run after some system change, or there is a geometry mis-match between what LILO used (lilo -v3 to display) and what is actually being used by the BIOS (one of the lilo diagnostic disks, available in the source distribution, may be needed to diagnose this problem).

Vielleicht reicht es "lilo" auf dem System auszuführen (chroot).

Gruss, habakug

[1] http://linux.die.net/man/8/lilo

[Meillo]

Wurde das Mainboard auch ausgetauscht?

Nein. Es ist ein VIA EPIA-SP 8000E. Die SATA-Platten haengen an einem separaten Controller von Promise. Beides ist schon etwas aelter, aber grundsaetzlich scheint es ja zu funktionieren. Lilo wird ja geladen und kommt bis zum `L'.

Der Error-Code "L 99 .." bedeutet laut Manpage [1]:

Errors 99 and 9A usually mean the map file (-m or map=) is not readable, likely because LILO was not re-run after some system change, or there is a geometry mis-match between what LILO used (lilo -v3 to display) and what is actually being used by the BIOS (one of the lilo diagnostic disks, available in the source distribution, may be needed to diagnose this problem).

Vielleicht reicht es "lilo" auf dem System auszuführen (chroot).

Das habe ich getan. Ich habe die alte Systempartion auf die neu erstellte, gleich grosse Partition der neuen Platte kopiert (dd). Dann habe ich sie gemountet, dorthin gechrootet, lilo.conf angepasst und Lilo ausgefuehrt.

Ich muss mir das nochmal in Ruhe anschauen und die konkreten Befehle und Ausgaben rauskopieren. (Vielleicht muss ich mir die lilo.conf auch nochmal genauer anschauen.)

D.h. aber, dass ein grundsaetzliches Vorgehen passend zu sein scheint.


Notfalls lasse ich das 320 GB-RAID halt drin fuer das System und nutze die 3 TB-Platten nur fuer die Daten. Eine solch klare Trennung hat natuerlich auch etwas fuer sich ... aber der Stromverbrauch, der eigentlich unnoetige Verschleiss der zusaetzlichen Platten und die nicht andersweitige Nutzbarkeit sprechen dagegen.

[NAB]

Es ist ein VIA EPIA-SP 8000E. Die SATA-Platten haengen an einem separaten Controller von Promise.

Hast du mal geprüft, ob er wirklich von der Sata-Platte bootet, oder vielleicht heimlich von der IDE-Platte? Und sieht es so aus, als ob der Promise-Controller volle 3TB erkennt?

[Meillo]

Es ist ein VIA EPIA-SP 8000E. Die SATA-Platten haengen an einem separaten Controller von Promise.

Hast du mal geprüft, ob er wirklich von der Sata-Platte bootet, oder vielleicht heimlich von der IDE-Platte?

Ich habe die alte IDE-Systemplatte abgestoepselt und bekomme trotzdem das ``L 99 99 99 99 ....'' angezeigt. Daraus deutet ich, dass er von der neuen Platte bootet. Aber ich kann zur Sicherheit auch die anderen Datenplatten abstoepseln.

Und sieht es so aus, als ob der Promise-Controller volle 3TB erkennt?

Guter Hinweis, das sollte ich bei dessen initialisierung nochmal pruefen ... wobei, wenn ich mich recht erinnere hat parted beim Partitionieren die Platte mit 3TB angezeigt. Das sollte doch genuegen, oder?

Ich hoffe, dass ich mich heute abend wieder der Sache widmen kann.

[NAB]

Und sieht es so aus, als ob der Promise-Controller volle 3TB erkennt?

Guter Hinweis, das sollte ich bei dessen initialisierung nochmal pruefen ... wobei, wenn ich mich recht erinnere hat parted beim Partitionieren die Platte mit 3TB angezeigt. Das sollte doch genuegen, oder?

Nein. Wenn parted läuft, läuft ja schon das Betriebssystem, und das kann durchaus eine andere Meinung über die Festplattengeometrie haben als das BIOS oder der Controller (siehe Link zum Heise-Artikel oben). Und LILO muss sich nach der Geometrie richten, die das BIOS ihm meldet, wird aber nach der Geometrie installiert, die das Betriebssystem sieht. Das könnte für diesen "geometry mis-match" sorgen, den Habakug erwähnt.

Schlimmer noch ... der Promise-Controller könnte die Platte richtig erkennen, aber das BIOS kann mit den großen Zahlen nichts anfangen und würde die Meldung des Controllers falsch deuten ...

Kann das Mainboard von USB booten? Dann wäre ein USB-Stick mit LILO und /boot drauf vielleicht der einfachste Weg (mit "noatime" mounten).

[Meillo]

Und sieht es so aus, als ob der Promise-Controller volle 3TB erkennt?

Guter Hinweis, das sollte ich bei dessen initialisierung nochmal pruefen ... wobei, wenn ich mich recht erinnere hat parted beim Partitionieren die Platte mit 3TB angezeigt. Das sollte doch genuegen, oder?

Nein. Wenn parted läuft, läuft ja schon das Betriebssystem, und das kann durchaus eine andere Meinung über die Festplattengeometrie haben als das BIOS oder der Controller (siehe Link zum Heise-Artikel oben). Und LILO muss sich nach der Geometrie richten, die das BIOS ihm meldet, wird aber nach der Geometrie installiert, die das Betriebssystem sieht. Das könnte für diesen "geometry mis-match" sorgen, den Habakug erwähnt.

Ah! Danke fuer die Erlaeuterung. Ich werde also schauen was der Controller beim Booten ausgibt.

Schlimmer noch ... der Promise-Controller könnte die Platte richtig erkennen, aber das BIOS kann mit den großen Zahlen nichts anfangen und würde die Meldung des Controllers falsch deuten ...

Wie kann ich das rausfinden? Sind die Ausgaben beim Booten, also die Extraausgabe fuer den Controller nach der Mainboardausgabe, denn vom BIOS interpraetiert oder kommen die direkt vom Controller? Wenn dort die Angabe stimmt, bin ich dann auf der sicheren Seite?

Kann das Mainboard von USB booten? Dann wäre ein USB-Stick mit LILO und /boot drauf vielleicht der einfachste Weg (mit "noatime" mounten).

Das ist ein interessanter Vorschlag. Das wuerde dagegen helfen, wenn das BIOS die Geometrie falsch erkennt, die Platten aber ansonsten ganz normal angesprochen werden koennen, oder? Ich habe bisher immer nur daran gedacht, die Systempartition auszulagern, aber du schlaegst vor nur /boot auszulagern. Das ist durchaus interessant. (Die koennte ich ja sogar read-only mounten, dann waere ich ganz auf der sicheren Seite.)

[NAB]

Wie kann ich das rausfinden?

Gar nicht. Wenn's läuft, dann läuft es, und wenn es nicht läuft, dann könnte es an dir liegen oder an dem Bootloader oder an irgendwelchen Firmware/BIOS-Fehlern.

Ich hab hier noch einen alten LSI-Controller liegen, der nur bis 2TB zugelassen ist, und ich hab mich voll gefreut, dass der ne 3TB-Platte korrekt angezeigt hat. Bis ich dann herausbekommen habe, dass er ab 2 TB anfängt, die Platte wieder vom Anfang an zu überschreiben, hat es einige Zeit gedauert. Nach nem Firmware-Update zeigt er die 3 TB Platte jetzt korrekt als 2 TB an und das letzte TB ist nicht zugänglich.

Ich konnte über das "VIA EPIA-SP 8000E" auch nichts herausbekommen ... ich weiß nicht mal, ob der Promise-Controller onboard ist oder eingesteckt. Und prinzipiell würde ich VIA ungefähr so weit vertrauen, wie ich das Board werfen kann. Egal was es anzeigt, es könnte falsch oder richtig sein, und es könnte richtig angezeigt werden, und vom BIOS falsch ausgewertet werden.

(Die koennte ich ja sogar read-only mounten, dann waere ich ganz auf der sicheren Seite.)

Wär blöd bei Kernel-Aktualisierungen ...

Du könntest /boot auf ein Raid1 mit drei Mirrors auslagern ... zwei davon liegen auf den Platten, der dritte auf dem USB-Stick. Wenn der USB-Stick die Grätsche macht, hast du immer noch eine aktuelle Kopie von /boot (und eventuell einen bootbaren Reserve-USB-Stick im Schrank).

Nebenbei ... ich hab ja von Lilo herzlich wenig Ahnung, aber wenn ich das richtig verstehe, hattest du es erst auf einer Partition ohne Raid installiert und jetzt auf einem Raid-Verbund. Da scheint man auch einiges berücksichtigen zu müssen:
http://www.linuxquestions.org/questions ... 175529421/
Selbst das aktuelle Slackware scheint sich nicht auf einem Raid1 installieren zu lassen, sondern verlangt händische Nachbearbeitung der Lilo-Konfiguration per chroot:
http://prithak.blogspot.de/2013/07/inst ... linux.html

[Meillo]

Ich hab hier noch einen alten LSI-Controller liegen, der nur bis 2TB zugelassen ist, und ich hab mich voll gefreut, dass der ne 3TB-Platte korrekt angezeigt hat. Bis ich dann herausbekommen habe, dass er ab 2 TB anfängt, die Platte wieder vom Anfang an zu überschreiben, hat es einige Zeit gedauert.

Das macht ja richtig Lust darauf!
... vielleicht haette ich doch besser 2TB-Platten kaufen sollen.

Ich konnte über das "VIA EPIA-SP 8000E" auch nichts herausbekommen ... ich weiß nicht mal, ob der Promise-Controller onboard ist oder eingesteckt.

Der Controller ist extra, eine PCI-Steckkarte.

(Die koennte ich ja sogar read-only mounten, dann waere ich ganz auf der sicheren Seite.)

Wär blöd bei Kernel-Aktualisierungen ...

Ist doch nicht schlimm. In dem Fall kann man /boot read-write remounten, den Kernel aktualisieren und dann /boot wieder read-only remounten. So oft ist das ja nicht noetig. Da kannst du dann aber natuerlich einwerfern, dass das nicht viel anders als `rw,noatime' ist.

Nebenbei ... ich hab ja von Lilo herzlich wenig Ahnung, aber wenn ich das richtig verstehe, hattest du es erst auf einer Partition ohne Raid installiert und jetzt auf einem Raid-Verbund. Da scheint man auch einiges berücksichtigen zu müssen:
http://www.linuxquestions.org/questions ... 175529421/
Selbst das aktuelle Slackware scheint sich nicht auf einem Raid1 installieren zu lassen, sondern verlangt händische Nachbearbeitung der Lilo-Konfiguration per chroot:
http://prithak.blogspot.de/2013/07/inst ... linux.html

Danke fuer die Links. Diesem Thema werde ich mich annehmen, wenn der Rest laeuft. Ich habe das vor ein paar Jahren schon zweimal eingerichtet, ich weiss nur nicht mehr auswenden ob es mit Lilo war oder mit Grub1.

[NAB]

Der Controller ist extra, eine PCI-Steckkarte.

Dann versuch doch mal herauszukriegen, wie sich der Controller bei Festplatten > 2 TB verhält. Eventuell gibt's nen Firmwareupdate.

Danke fuer die Links. Diesem Thema werde ich mich annehmen, wenn der Rest laeuft.

Ich weiß nicht, ob ich das richtig verstanden habe und ob du das richtig verstanden hast, aber wenn Lilo von einem Raid booten soll, dann scheint extra Handarbeit nötig zu sein. Und dein "System" scheint jetzt auf einem Raid zu liegen. (Nebenbei finde ich für Slackware generell nur Beispiele mit Lilo und Raid, wo /boot auf einer eigenen Partition liegt.)

[Meillo]

Der Controller ist extra, eine PCI-Steckkarte.

Dann versuch doch mal herauszukriegen, wie sich der Controller bei Festplatten > 2 TB verhält. Eventuell gibt's nen Firmwareupdate.

Okay.

Ich weiß nicht, ob ich das richtig verstanden habe und ob du das richtig verstanden hast, aber wenn Lilo von einem Raid booten soll, dann scheint extra Handarbeit nötig zu sein. Und dein "System" scheint jetzt auf einem Raid zu liegen. (Nebenbei finde ich für Slackware generell nur Beispiele mit Lilo und Raid, wo /boot auf einer eigenen Partition liegt.)

Im Moment liegt das System (Debian stable) noch auf einer einzelnen IDE-Platte. Als ersten Schritt will ich es auf eine einzelne 3TB-SATA-Platte umziehen. Danach will ich aus der einen SATA-Platte durch Hinzufuegen einer zweiten Platte ein RAID machen.

Mir ist nicht ganz klar, was du mit ``von einem Raid booten'' meinst. Fuer mich ist es okay, wenn er von einer der beiden Partitionen bootet, solange die in Sync sind. (Falls die erste der beiden Platten abraucht, dann muss ich halt in der lilo.conf `sda1' durch `sdb1' ersetzen und lilo neu ausfuehren um das System wiederzuerwecken. RAID1 ist da ja unkompliziert.) Ich denke, dass ich es bisher immer so bei mir umgesetzt habe.


Danke fuer deine viele Muehe, uebrigens.

[NAB]

Danach will ich aus der einen SATA-Platte durch Hinzufuegen einer zweiten Platte ein RAID machen.

Mir ist nicht ganz klar, was du mit ``von einem Raid booten'' meinst.

Und mir ist jetzt nicht mehr klar, was du mit "RAID" meinst. Ich bin bisher von einem Software-Raid ausgegangen, welches du vor der Installation mit mdadm erzeugen müsstest. Das geht auch mit nur einer Platte (bzw. Partition) ... die zweite ist dann "missing", bis sie hinzugefügt wird.

Wenn der Promise-Controller allerdings irgendein Fake-Raid oder gar ein echtes Hardware-Raid ermöglicht, und du das genutzt hast, dann gäbe es noch ganz andere Gründe, warum Lilo scheitern könnte.

[Meillo]

Danach will ich aus der einen SATA-Platte durch Hinzufuegen einer zweiten Platte ein RAID machen.

Mir ist nicht ganz klar, was du mit ``von einem Raid booten'' meinst.

Und mir ist jetzt nicht mehr klar, was du mit "RAID" meinst. Ich bin bisher von einem Software-Raid ausgegangen, welches du vor der Installation mit mdadm erzeugen müsstest. Das geht auch mit nur einer Platte (bzw. Partition) ... die zweite ist dann "missing", bis sie hinzugefügt wird.

Ja, es geht um ein Software-RAID per mdadm. Um aber die Anzahl der moeglichen Problemstellen zu reduzieren beginne ich mit einer einzelnen Platte ohne RAID. Wenn damit alles laeuft, dann fange ich an, das RAID dazuzubauen. So denke ich mir das. Ob das dann einfach so geht, wird sich zeigen. Zumindest macht es das aktuelle Problem etwas weniger komplex. (Zur Not kann ich auch nochmal bei der Ausgangssituation starten und es dann nochmal aber mit RAID bauen ... das aber erst wenn ich weiss, dass es tut, denn wenn es dann nicht tut, ist klar, dass es am RAID liegen muss.)

[NAB]

Ah, nun ist es klar

Stimmt, solange es gar kein Raid gibt, sind natürlich sämtliche Überlegungen zu Problemen von Lilo mit Raid völlig irrelevant.

Es wäre trotzdem einen Versuch wert, /boot auf eine eigene Partition auszulagern. Diese sollte ganz am Anfang der Platte liegen, damit BIOS und Lilo es nur mit kleinen Sektorengrößen zu tun haben.

Es gibt übrigens auch IDE->SD-Karten-Adapter statt USB-Stick ... dann ragt nichts aus dem Gehäuse raus und das Mainboard könnte wie gewohnt von IDE booten.

[Meillo]

Ah, nun ist es klar

Stimmt, solange es gar kein Raid gibt, sind natürlich sämtliche Überlegungen zu Problemen von Lilo mit Raid völlig irrelevant.

Ich haette das wohl besser erstmal gar nicht ins Spiel bringen sollen.

Es wäre trotzdem einen Versuch wert, /boot auf eine eigene Partition auszulagern. Diese sollte ganz am Anfang der Platte liegen, damit BIOS und Lilo es nur mit kleinen Sektorengrößen zu tun haben.

Das gehe ich ja schon insofern an, dass ich eine nur 10GB grosse Systempartition am Anfang der Platte habe. (Der Rest wird dann eine separate Datenpartition.)

Es gibt übrigens auch IDE->SD-Karten-Adapter statt USB-Stick ... dann ragt nichts aus dem Gehäuse raus und das Mainboard könnte wie gewohnt von IDE booten.

Da der Server im Schrank steht ist es recht egal ob was raus ragt. Allerdings ist der Vorschlag trotzdem gut, denn ich habe hier noch einen ganzen Stapel alter SD-Karten rumliegen (0,5 - 2 GB), die koennte ich schon der Reihe nach abnutzen. /boot aendert sich ja nicht so oft, also wuerde ein taegiches Backup gut reichen. Falls eine SD-Karte abraucht, dann beschreibe ich die naechste, stecke sie ein und gut ist ... Das ist durchaus ein interessanter Ansatz ... den ich aber nur brauche, wenn es nicht mit /boot auf der 3TB-SATA-Platte klappt. Oder gibt es irgendwelche Vorteile?

[NAB]

Oder gibt es irgendwelche Vorteile?

Nein, im Gegenteil ...ich würd mich nicht darauf verlassen, dass so ein SD-Karten->IDE-Adapter immer und problemlos funktioniert. Wenn das Mainboard vom USB-Stick bootet, würde ich diese Variante nehmen. (Zumal man für diese Adapter auch ca. 15 Eur hinlegen muss, dafür kriegt man schon drei USB-Sticks)

[Meillo]

So, nach einigen Tagen finde ich nun endlich wieder Zeit um mich dem Problem zu widmen.

Der Controller ist extra, eine PCI-Steckkarte.

Dann versuch doch mal herauszukriegen, wie sich der Controller bei Festplatten > 2 TB verhält. Eventuell gibt's nen Firmwareupdate.

Okay.

Wenn der Computer bootet und seinen Selbsttest macht, dann gibt es eine Anzeige, wo der SATA-Controller von Promise seine Platten sucht. Da zeigt er meine 3T-Platte mit korrekter Groesse (etwa 2900 GB) an.


Inzwischen bin ich einen grossen Schritt weiter. Ich kann nun von der 3T-Platte booten. Das erforderte zwei Aenderungen:

1) Ich musste das Device des root-Filesystems in der /etc/fstab anpassen ... was ja eigentlich klar ist. Deshalb hat er auch die map-Datei nicht gefunden (was der Ausloeser fuer die ``L 99 99 99...''-Meldung war).

Danach bootete der Kernel, ich blieb jedoch haengen als er / mounten wollte.Er hatte es mit /dev/block/8:17 versucht. (Ich glaube, das war die Platte auch mal als die alte Systemplatte noch angeschlossen war.)

2) Ich habe einfach durchgaengig wieder herkoemmliche Pfade (/dev/sda1 & Co.) verwendet, statt diesem nett gemeinten UUID-Kram.

Jetzt laeuft das System.


Ich sehe diesen Zustand aber bislang nur als Prototyp an. Am naechsten freien Abend will ich wieder auf UUIDs umstellen und die anderen Datenplatten wieder anschliessen. Und am Ende muss ich ja noch das RAID1 fuer das System aufsetzen. D.h. dann wohl nochmal alles von vorne, aber inklusive RAID. Wenn ich das durch habe, dann weiss ich wenigstens wie ich es gemacht habe.

Danke schonmal.

Ich halte euch auf dem Laufenden.