Fragen zu Upgrade Sarge -> Etch

[tsibi]

Hallo zusammen,

ich betreibe noch einen Server mit Debian Sarge. Diesen möchte ich in zwei Schritten zu Lenny upgraden. Allerdings weiß ich nicht so recht, wie ich mich auf dieses Upgrade gut vorbereiten kann.

1. Der Kernel von 2.4.x auf 2.6.x: Ich kann schon unter Sarge einen 2.6er Kernel installieren. Doch müssen die root-Device-Angaben in der menu.lst auf /dev/hda1 oder /dev/sda1 zeigen? Hätte jetzt intuitiv sd gesagt. Wenn der Neustart im RZ schief geht, muss ich die Rescue-Konsole oder etas anderes verwenden.

2. Upgrade von MySQL4 auf 5 und UTF8-Unterstützung: Werden die vorhandenen Datenbanken und Zugriffsberechtigungen automatisch migriert und wenn nein, wie muss ich hier vorgehen? Reicht es, bei heruntergefahrenem MySQL-Server alle DB-Verzeichnisse zu sichern oder muss ich zusätzlich ein MySQLDump erstellen?

Für Hinweise zur richtigen Upgrade-Strategie wäre ich sehr dankbar.

VG Simon

[rendegast]

zu 1.

müssen die root-Device-Angaben in der menu.lst auf /dev/hda1 oder /dev/sda1 zeigen?

Käme auf den Chipsatz an resp. den dann verwendeten Treiber. Du kannst das Problem mit den Optionen 'root=LABEL=...' oder 'root=UUID=...' umgehen.
Wenn das der grub von sarge noch nicht kann, dann installiere schon den aus etch oder lenny.

muss ich die Rescue-Konsole oder etas anderes verwenden.

Ein Konsolenzugang? Prima, da kannst Du die kernel-Anweisung doch in der grub-shell korrigieren.
Es gibt auch noch einen 'failsafe'-Mechanismus in grub selbst, aber auch dafür müßte IMO ein Reboot ausgelöst werden.


zu 2.
http://dev.mysql.com/doc/refman/5.0/en/upgrade.html

[tsibi]

Hallo rendegast,

danke für deine Antwort. Ich glaube, dass ich die Rescue-Konsole nicht bedienen kann, da diese evtl. auf VNC oder etwas ähnlichem basiert. Das kann ich mit meinem Screenreader nicht auslesen. Notfalls kann ich aber ein Rescue-System booten, dass ich dann via SSH erreichen kann. Aber ich werde das mit dem richtigen menu.lst Format wohl ausprobieren müssen und hoffen, dass ich den Server dann wieder via SSH erreichen kann.

Zu MySQL: ich weiß nicht, ob ich die Upgrade-Hinweise richtig verstanden habe. Soll man wirklich vor dem upgrade die Daten via mysqldump exportieren und nach dem Upgrade wieder einspielen? Oder ist das nur als Sicherheitsmaßnahme empfohlen? Denn auch bei Mysqldump kann es ja z. B. durch Zeichensatzänderungen zu Problemem kommen. Daher würde ich mich ungern darauf verlassen müssen. Das Sichern der reinen DB-Files gestaltet sich da einfacher.

Wäre für weitere Hinweise dankbar, da ich aus dem UPgrade-Dokument nicht wirklich schlauer wurde, was ich nun konkret machen muss.

[rendegast]

Ich verstehe es so:

CHECK TABLE or REPAIR TABLE
mysqldump
Upgrade
Reload the dump file
mysql_upgrade

(Spricht aber nicht aus eigener Erfahrung)

Aber ich werde das mit dem richtigen menu.lst Format wohl ausprobieren müssen

Probier das aber vorher zuhause aus.
Die Beschreibung auf gnu.org hört sich ja gut an, bei mir lag dann wohl ein Bedienungsfehler vor,
oder ich habe es nicht im dafür gedachten Szenario durchgespielt.

[tsibi]

Hallo Rendegast,

das mit dem MySQL-Update kommt mir noch etwas komisch vor. Warum erst ein Dump erstellen, den man später einspielt und dann das Upgrade-Script starten? Ich werde wohl den MySQL-Server herunterfahren und die DB-Files sichern. Vielleicht geht das ja doch alles gut oder ich bekomme hier noch genaue Infos zum Upgrade.

Das mit den LABELS bei Grub ist ja eine tolle Sache. Habe das auf meinem Lenny-System hier ausprobiert: Label vergeben mit

Code: Alles auswählen

e2label /dev/sda6 debian

Und in der menu.lst steht folgender Boot-Eintrag:

Code: Alles auswählen

title		Debian GNU/Linux, kernel 2.6.26-1-686
root		(hd0,5)
kernel	/boot/vmlinuz-2.6.26-1-686 root=LABEL=debian ro quiet
initrd	/boot/initrd.img-2.6.26-1-686

Beim reboot wurde Lenny ohne Probleme gebootet. Ich habe gelesen, dass ich LABEL auch in der /etc/fstab verwenden kann, was ich noch nicht aktualisiert habe.

VG Simon

[rendegast]

Warum erst ein Dump erstellen, den man später einspielt und dann das Upgrade-Script starten?

http://dev.mysql.com/doc/refman/5.0/en/ ... m-4-1.html :

Note particularly any changes that are marked Known issue or Incompatible change. These incompatibilities with earlier versions of MySQL may require your attention before you upgrade.

Our aim is to avoid these changes, but occasionally they are necessary to correct problems that would be worse than an incompatibility between releases. If any upgrade issue applicable to your installation involves an incompatibility that requires special handling, follow the instructions given in the incompatibility description.

So stehts da, hängt von den Inkompatibilitäten ab.

Often this will involve a dump and reload, or use of a statement such as CHECK TABLE or REPAIR TABLE.

das "oder" hab ich überlesen.

A dump and reload is done like this:
*Dump the affected tables with mysqldump before upgrading
*Reload the dump file (for example, with mysql) to recreate the tables after upgrading

Any procedure that involves REPAIR TABLE with the USE_FRM option must be done before upgrading. Use of this statement with a version of MySQL different from the one used to create the table (that is, using it after upgrading) may damage the table.

Ende des Zitats

Aber ich habe keinen Einblick in SQL,
ich gebe hier nur die Upgrade-Hinweise nach meinem Verständnis wieder!
Sonst meldet sich hier ja keiner.

LABEL auch in der /etc/fstab verwenden

Yepp, dort war das scheinbar schon immer so,
in update-grub ist es "erst" ab Nov 2004 (changelog.DEBIAN).