Für einen Server ist der Unterstützungszeitraum von drei Jahren zu kurz. Das ist IMO ein deutlicher Hinweis darauf, dass Debian Stable keine ausschließliche Serverdistro ist. Auch läuft das Lenny-Squeeze-Update nicht immer hundertprozentig durch.
Ich fände es genial wenn die oldstable noch bis übernächstes stable-release unterstützt würde (wie bei Fedora), also ein old-old-stable das dann ~6 Jahre gepflegt wurde nach letztem stable release. Die Begründung vom Debian-Sec Team ist jedoch verständlich, wartung braucht gewaltig Zeit wenn sie sauber gemacht wird...und nichts anderes bin ich von Debian gewohnt. Vielleicht mal Realeasnotes lesen, dann läufft auch das upgrade...wenn du nur ein update machst ist mir auch alles klar
Danke an alle die beim Debian-projekt mitmacht, ihr setzt die *nix-qualitäts-latte an der sich alle andern messen müssen.
Vielleicht liege ich falsch, aber anscheinend braucht Debian eher Maintainer und Mitstreiter als dass es zuviele davon hätte. IMO ist es eine starke Leistung, als Community zwei Komplettdistros dieses Ausmaßes ein Jahr lang nebeneinander zu betreuen. Pakete wie Iceweasel 3.0.6 (in Form eines Xulrunner-/Firefox etwa in der Version "3.0.33") stechen da besonders hervor. Schatten gibt es natürlich auch: Anscheinend gab es in Lenny kein KDE3-Update mehr seit Mai 2010 und der letzte glibc-Bug (CVE-2009-5029; trotz der Jahreszahl 2009 ist der Bug letztendlich neu) wurde auch nicht gefixt (selbst in Squeeze scheint der Fix noch zu fehlen).
Auch läuft das Lenny-Squeeze-Update nicht immer hundertprozentig durch.
Vor dem Upgrade die dazugehörige Upgrade-Dokumentation lesen, dann klappts auch mit dem Upgrade. Die Release-Informationen zu lesen kann auch nicht schaden.
Ich habe zig Systeme upgegraded, aber bei keinem einzigen ernsthafte Probleme gehabt.
Hier hat es trotzdem nicht richtig geklappt. Bisher war Lenny in einem gemischten IDE/SCSI-System installiert gewesen, im BIOS ist IDE1 (hda) als erste Festplatte eingestellt, danach kommt IDE2 (hdb), dann SCSI1 (sda), usw. Deshalb hatte Lenny Grub auch in den MBR der ersten IDE-Festplatte geschrieben. Nicht so Squeeze. Squeeze installierte Grub2 dämlicherweise in den MBR der ersten SCSI-Festplatte, die es als erste Festplatte im System ansah, obgleich es laut BIOS die dritte Festplatte im System ist. Der Rechner bootete natürlich von der ersten Festplatte, wie im BIOS eingestellt.
Beim Upgrade von Lenny nach Squeeze bleibt doch Grub1 weiterhin erhalten und Grub2 wird nur als Menüpunkt von Grub1 installiert, so dass man es testen kann, bevor man Grub2 übernimmt?
Das weiß ich nicht, (Lenny-)Grub1 bootete jedenfalls nicht. Ich habe dann Squeeze zwar noch einmal installiert. Den Part des Debian-Bootloaders übernimmt jetzt aber nach einigem Herumprobieren eine alte openSUSE. Die Bootreihenfolge der Festplatten im BIOS nicht zu beachten, das ist schon ziemlich schlecht. Was mir noch auffiel: Debians Grub2 lässt sich zwar nach /dev/sda2 installieren, nicht aber dessen Grub1. Hier erhält man dann eine Fehlermeldung, dass die anvisierte Partition nicht existieren würde. Der Onboard-Soundchip funktioniert überdies nur noch mit OSS4 (immerhin) und nouveau hat eine 2D-Performance zum Davonlaufen (der mitgelieferte nv-Treiber ist performanter). Alles in allem ist Squeeze gegenüber Lenny eher ein Rückschritt, es ist anscheinend viel Beta-Software enthalten (u.a. nouveau, Grub2, KDE4, Pcmanfm 0.97). Von mir aus könnte Wheezy schon morgen erscheinen. Schlimmer kann es kaum noch kommen.
Zur Bootloader-Problematik kann ich jetzt keine direkte Aussage machen, alle Systeme welche ich upgegradet habe booten weiterhin korrekt.
Dass Squeeze von etwas durchwachsender Qualität ist, kann ich hingegen bestätigen. Dafür gibt es mehrere Gründe. So ist beispielsweise KDE4 einfach noch zu unfertig (was wurden die Debian-Entwickler damals gescholten, als sie Lenny noch mit KDE3 ausgeliefert hatten, dabei war es die einzig richtige Entscheidung).
X.org wird von Version zu Version verbuggter, aber auch das liegt weniger an den Debian Leuten als am Upstream. So ist beispielsweise der Synaptics-Touchpad-Treiber in Squeeze, den Squeeze-Backports und vermutlich auch weiterhin in Wheezy und SID komplett vermurkst. Die automatische Erkennung der bereitgestellten Funktionen des verbauten Touchpads schlägt oftmals fehl. Auch lässt sich beispielsweise über die Touchpad-Fläche kein linker, mittlerer oder rechter Mausklick anhand der Anzahl der Finger welche auf das Touchpad tippen, mehr einstellen. Nicht einmal durch manuelles editieren der xorg.conf Mithilfe der Synaptics-Manpage ist das mehr möglich.
Ein weiteres Problem scheinen "seltsame Patches" aus der Ubuntu-Welt zu sein, welche in Debian landen da sie vorgeben etwas zu verbessern, gleichzeitig aber andere Fehler verursachen.
Ich habe gerade gestern eine Maschine mit einem ähnlichen Setup wie du auf Squeeze upgedatet (Boot von hda, / etc. auf sda).
Mit scheint jedoch, dass du einen Denkfehler begehst: Linux hat die Bootreihenfolge der Festplatten im BIOS noch nie beachtet. Das einzige, worauf diese Reihenfolge Einfluss hat, ist, von welcher HDD der Bootloader geladen wird. Alles weitere geschieht ohne BIOS. Du hattest bisher also schlicht Glück.
Um Probleme mit der Reihenfolge der HDD-Bezeichnungen zu vermeiden, schlägt das Squeeze-Setup auch vor, bestehende sda/hda-Bezeichnungen durch ihr UUID-Pendant zu ersetzen. So kann es zu keinen Problemen kommen, wenn du mal eine weitere Platte einbaust und sda nun plötzlich sdb ist.
Weiters schlägt dir das Squeeze-Setup, wie 1ras richtig schreibt, zunächst vor, Grub2 erst mal per Chainloader von Grub1 aus zu laden. Später, nach erfolgreichem Reboot, kann man dann per "upgrade-from-grub-legacy" Grub2 installieren. Das wiederum geschieht interaktiv, und man kann in aller Ruhe menügesteuert entscheiden, in welchen MBR oder welche Partition man Grub2 installieren möchte. Nur: wie kann aber dann, wie du sagst, "Squeeze Grub2 dämlicherweise in den MBR der ersten SCSI-Festplatte installiert" haben ohne dein Zutun?
Das Upgrade auf Squeeze ist nämlich nicht ganz trivial, lebenswichtig ist es unter anderem, zuallererst den Kernel und udev manuell upzugraden und zu rebooten.
Ich sehe trotzdem nicht den Hauptfehler bei mir. Wie kann ich denn Squeeze vorschreiben, welche Festplatte es als erste (Boot-)Festplatte anzusehen hat, wenn ich Grub nach der Installation in den MBR von /dev/sda installieren möchte? Wieso sieht Debian überhaupt plötzlich die erste SCSI-Festplatte als /dev/sda an und nicht als /dev/sdc? Wird das durch eine Art "Lotterie" entschieden, je nachdem wie die Anfangsbuchstaben der Festplattenkennzeichnung lauten?
Squeeze ist hier die erste Distro, die das so handhabte, openSUSE 11.1 (mit der neuen sda-Nomenklatur) und Debian Lenny (mit der alten hda-Nomenklatur) installierten den Bootloader immer in den ersten MBR der ersten IDE-Festplatte, nicht in denjenigen der ersten SCSI-Festplatte.
Ich hatte nicht damit gerechnet, dass sich dass einfach so ändern könnte. Außerdem wurde es ja auch nicht angezeigt, /dev/sda ist als Bezeichnung schließlich in beiden Fällen gleich. Dieses Problem existierte bisher also gar nicht.
Und auf Deine Frage: Ich hatte Grub2 zum Abschluss manuell installiert, weil ich mir dachte, dass es eine gute Idee sei, die Kernel der anderen Linuxinstallationen gleich automatisch einbinden zu lassen. Die entsprechenden Lenny-Grubeinträge hatte ich vor dem Upgrade mit UUID-Bezeichnungen versehen. "UUIDs" für MBRs gibt es aber offensichtlich nicht.
Es ist nun so, dass ein im MBR der ersten IDE-Festplatte installierter Debian Squeeze-Grub1 die openSUSE-Installation auf der ersten SCSI-Festplatte mit dem Chainloader-Eintrag für (hd2,1) tatsächlich starten kann, die Squeeze (bei aktiviertem SCSI-Strang) als erste Festplatte des Systems (sda) ansieht. Ich habe das gerade eben nach einem kurzen Ab- und Wiederanschalten des SCSI-Stranges getestet. Ist SCSI aktiviert, will Squeeze wieder in den "falschen" MBR der ersten SCSI-Festplatte installieren.
Wie behebt man diesen Fehler und wie bringt man Debian bei, die erste IDE-Festplatte als erste Festplatte des Systems anzusehen, ausschließlich im Hinblick auf die fehlgeleitete Bootloaderinstallation in den MBR? Schon ein angesteckter USB-Stick könnte vielleicht das ganze System durcheinanderbringen. Ich kann ja einmal ausprobieren, ob Squeeze Grub auch in den MBR eines USB-Sticks zu schreiben bereit ist. So von wegen Grub in den MBR der "ersten Festplatte" schreiben. :-) IMHO ist das ein Bug, und kein "kleiner". Fragt sich nur, in welcher Software.
Nachtrag: Der Fehler ist IMO folgender: Grub2 entscheidet zwar nach der UUID, welche Festplatte er zum Booten benutzen soll, zum Herausfinden des richtigen MBRs richtet sich Grub2 aber nach den /dev/-Pfaden und ignoriert dabei auch noch die festgelegte Bootreihenfolge im BIOS. So kommt es dann zu dem MBR-Durcheinander. Ein entsprechender Hinweis in den Debian-Upgradehinweisen fehlt.
I had an ASUS motherboard that gave me years of grief for the exact same problem. Way back when IDE drives were still called /dev/hd*, it was fine. It was around about the time that IDE drives became /dev/sd* that things started going funny, basically sometimes the IDE drives would be first in the list (/dev/sda, sdb, etc.) and the SATA drives would be next (/dev/sdd, /dev/sde, etc.). Sometimes they'd be the other way around. Personally, I blamed the BIOS, because it also liked changing the boot priority order (i.e. sometimes it would choose to check the first IDE drive for a bootloader, sometimes it would choose to check the first SATA drive for a bootloader).
Bei mir ist es ein Intel-Motherboard, und die ersten beiden IDE-Platten sind immer sda und sdb. Das SATA-Array ist immer sdc. Und so bleibt es auch bei jedem Reboot.
Ich habe nachgeschaut, aufgefallen ist mir nichts. Es handelt sich um ein älteres Intel PIV-Board (845BGL) mit etwas spartanischem Phoenix-Bios. Die Bootreihenfolge ist wie folgt festgelegt: Erste IDE-Festplatte, zweite IDE-Festplatte, erste SCSI-Festplatte, Wechseldatenträger (z.B. USB-Stick).
Das Squeezeupdate hat hier mehrmals auf anderen Rechnern funktioniert (dabei handelte es sich aber nicht um Mischsysteme), nur bei diesem Mischsystem gab es dieses Problem.
openSUSE 11.1 z.B. sieht auch die erste SCSI-Festplatte als erste, installiert den MBR aber trotzdem in die erste IDE-Festplatte. Somit besteht die Gefahr, dass sich je nach Distro und Kernel die Bootreihenfolge automatisch ändert. Ein BIOS-Bug im Zusammenspiel mit Linux kann ich natürlich nicht ausschließen. Manche Linuxdistros erkennen auch nicht, dass der Onboard-Audio-Chip des Mainboards abgeschaltet ist und sprechen dann die eigens installierte Extra-Soundkarte nicht richtig an.
Es ist schade, dass sich Grub2 nicht auch bei der MBR-Installaton ebenfalls an den UUIDs ausrichtet. So könnte man z.B. über die Möglichkeit nachdenken, bei der Installation von / auf der Ex-hda-Festplatte einen Klarnamen wie "Erste Festplatte" zur jeweiligen UUID zuordnen zu lassen und dann dafür sorgen, dass man vor der Grub2-Installation einen Eintrag "Grub2 in den MBR von "Erste Festplatte" installieren" auswählen kann.
Dein Link zeigt ja, dass das Problem tatsächlich auftritt, sowohl bei IDE-SATA- als auch (wie bei mir) bei noch älteren IDE-SCSI-Mischsystemen. Und eine vielleicht nur etwa 95%ige Erfolgsquote reicht bei einem Bootloaderprogramm IMO nicht, weil die Auswirkungen eines "Fehlers" halt so fatal sind.
Das ist ja wirklich eine sehr ärgerliche Sache. Ich werde in nächster Zeit noch ein paar solcher älterer Mischsysteme von Lenny auf Squeeze updaten müssen. Immerhin bin ich nun vorgewarnt, dies wohl besser vor Ort statt wie gewohnt remote zu machen...
Für einen Server ist der Unterstützungszeitraum von drei Jahren zu kurz.
Das ist IMO ein deutlicher Hinweis darauf, dass Debian Stable keine ausschließliche Serverdistro ist.
Auch läuft das Lenny-Squeeze-Update nicht immer hundertprozentig durch.
Ich fände es genial wenn die oldstable noch bis übernächstes stable-release unterstützt würde (wie bei Fedora), also ein old-old-stable das dann ~6 Jahre gepflegt wurde nach letztem stable release. Die Begründung vom Debian-Sec Team ist jedoch verständlich, wartung braucht gewaltig Zeit wenn sie sauber gemacht wird...und nichts anderes bin ich von Debian gewohnt.
Vielleicht mal Realeasnotes lesen, dann läufft auch das upgrade...wenn du nur ein update machst ist mir auch alles klar
Danke an alle die beim Debian-projekt mitmacht, ihr setzt die *nix-qualitäts-latte an der sich alle andern messen müssen.
Vielleicht liege ich falsch, aber anscheinend braucht Debian eher Maintainer und Mitstreiter als dass es zuviele davon hätte.
IMO ist es eine starke Leistung, als Community zwei Komplettdistros dieses Ausmaßes ein Jahr lang nebeneinander zu betreuen.
Pakete wie Iceweasel 3.0.6 (in Form eines Xulrunner-/Firefox etwa in der Version "3.0.33") stechen da besonders hervor.
Schatten gibt es natürlich auch: Anscheinend gab es in Lenny kein KDE3-Update mehr seit Mai 2010 und der letzte glibc-Bug (CVE-2009-5029; trotz der Jahreszahl 2009 ist der Bug letztendlich neu) wurde auch nicht gefixt (selbst in Squeeze scheint der Fix noch zu fehlen).
Vor dem Upgrade die dazugehörige Upgrade-Dokumentation lesen, dann klappts auch mit dem Upgrade. Die Release-Informationen zu lesen kann auch nicht schaden.
Ich habe zig Systeme upgegraded, aber bei keinem einzigen ernsthafte Probleme gehabt.
Hier hat es trotzdem nicht richtig geklappt.
Bisher war Lenny in einem gemischten IDE/SCSI-System installiert gewesen, im BIOS ist IDE1 (hda) als erste Festplatte eingestellt, danach kommt IDE2 (hdb), dann SCSI1 (sda), usw.
Deshalb hatte Lenny Grub auch in den MBR der ersten IDE-Festplatte geschrieben.
Nicht so Squeeze.
Squeeze installierte Grub2 dämlicherweise in den MBR der ersten SCSI-Festplatte, die es als erste Festplatte im System ansah, obgleich es laut BIOS die dritte Festplatte im System ist.
Der Rechner bootete natürlich von der ersten Festplatte, wie im BIOS eingestellt.
Beim Upgrade von Lenny nach Squeeze bleibt doch Grub1 weiterhin erhalten und Grub2 wird nur als Menüpunkt von Grub1 installiert, so dass man es testen kann, bevor man Grub2 übernimmt?
Das weiß ich nicht, (Lenny-)Grub1 bootete jedenfalls nicht.
Ich habe dann Squeeze zwar noch einmal installiert. Den Part des Debian-Bootloaders übernimmt jetzt aber nach einigem Herumprobieren eine alte openSUSE.
Die Bootreihenfolge der Festplatten im BIOS nicht zu beachten, das ist schon ziemlich schlecht.
Was mir noch auffiel: Debians Grub2 lässt sich zwar nach /dev/sda2 installieren, nicht aber dessen Grub1. Hier erhält man dann eine Fehlermeldung, dass die anvisierte Partition nicht existieren würde.
Der Onboard-Soundchip funktioniert überdies nur noch mit OSS4 (immerhin) und nouveau hat eine 2D-Performance zum Davonlaufen (der mitgelieferte nv-Treiber ist performanter). Alles in allem ist Squeeze gegenüber Lenny eher ein Rückschritt, es ist anscheinend viel Beta-Software enthalten (u.a. nouveau, Grub2, KDE4, Pcmanfm 0.97).
Von mir aus könnte Wheezy schon morgen erscheinen.
Schlimmer kann es kaum noch kommen.
Zur Bootloader-Problematik kann ich jetzt keine direkte Aussage machen, alle Systeme welche ich upgegradet habe booten weiterhin korrekt.
Dass Squeeze von etwas durchwachsender Qualität ist, kann ich hingegen bestätigen. Dafür gibt es mehrere Gründe. So ist beispielsweise KDE4 einfach noch zu unfertig (was wurden die Debian-Entwickler damals gescholten, als sie Lenny noch mit KDE3 ausgeliefert hatten, dabei war es die einzig richtige Entscheidung).
X.org wird von Version zu Version verbuggter, aber auch das liegt weniger an den Debian Leuten als am Upstream. So ist beispielsweise der Synaptics-Touchpad-Treiber in Squeeze, den Squeeze-Backports und vermutlich auch weiterhin in Wheezy und SID komplett vermurkst. Die automatische Erkennung der bereitgestellten Funktionen des verbauten Touchpads schlägt oftmals fehl. Auch lässt sich beispielsweise über die Touchpad-Fläche kein linker, mittlerer oder rechter Mausklick anhand der Anzahl der Finger welche auf das Touchpad tippen, mehr einstellen. Nicht einmal durch manuelles editieren der xorg.conf Mithilfe der Synaptics-Manpage ist das mehr möglich.
Ein weiteres Problem scheinen "seltsame Patches" aus der Ubuntu-Welt zu sein, welche in Debian landen da sie vorgeben etwas zu verbessern, gleichzeitig aber andere Fehler verursachen.
Ich habe gerade gestern eine Maschine mit einem ähnlichen Setup wie du auf Squeeze upgedatet (Boot von hda, / etc. auf sda).
Mit scheint jedoch, dass du einen Denkfehler begehst: Linux hat die Bootreihenfolge der Festplatten im BIOS noch nie beachtet. Das einzige, worauf diese Reihenfolge Einfluss hat, ist, von welcher HDD der Bootloader geladen wird. Alles weitere geschieht ohne BIOS. Du hattest bisher also schlicht Glück.
Um Probleme mit der Reihenfolge der HDD-Bezeichnungen zu vermeiden, schlägt das Squeeze-Setup auch vor, bestehende sda/hda-Bezeichnungen durch ihr UUID-Pendant zu ersetzen. So kann es zu keinen Problemen kommen, wenn du mal eine weitere Platte einbaust und sda nun plötzlich sdb ist.
Weiters schlägt dir das Squeeze-Setup, wie 1ras richtig schreibt, zunächst vor, Grub2 erst mal per Chainloader von Grub1 aus zu laden. Später, nach erfolgreichem Reboot, kann man dann per "upgrade-from-grub-legacy" Grub2 installieren. Das wiederum geschieht interaktiv, und man kann in aller Ruhe menügesteuert entscheiden, in welchen MBR oder welche Partition man Grub2 installieren möchte. Nur: wie kann aber dann, wie du sagst, "Squeeze Grub2 dämlicherweise in den MBR der ersten SCSI-Festplatte installiert" haben ohne dein Zutun?
Daher auch von mir nochmal die Frage: Hast du einfach so ein "apt-get dist-upgrade" gemacht oder bist du der Anleitung http://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.de.html gefolgt?
Das Upgrade auf Squeeze ist nämlich nicht ganz trivial, lebenswichtig ist es unter anderem, zuallererst den Kernel und udev manuell upzugraden und zu rebooten.
Ich sehe trotzdem nicht den Hauptfehler bei mir.
Wie kann ich denn Squeeze vorschreiben, welche Festplatte es als erste (Boot-)Festplatte anzusehen hat, wenn ich Grub nach der Installation in den MBR von /dev/sda installieren möchte?
Wieso sieht Debian überhaupt plötzlich die erste SCSI-Festplatte als /dev/sda an und nicht als /dev/sdc?
Wird das durch eine Art "Lotterie" entschieden, je nachdem wie die Anfangsbuchstaben der Festplattenkennzeichnung lauten?
Squeeze ist hier die erste Distro, die das so handhabte, openSUSE 11.1 (mit der neuen sda-Nomenklatur) und Debian Lenny (mit der alten hda-Nomenklatur) installierten den Bootloader immer in den ersten MBR der ersten IDE-Festplatte, nicht in denjenigen der ersten SCSI-Festplatte.
Ich hatte nicht damit gerechnet, dass sich dass einfach so ändern könnte. Außerdem wurde es ja auch nicht angezeigt, /dev/sda ist als Bezeichnung schließlich in beiden Fällen gleich.
Dieses Problem existierte bisher also gar nicht.
Und auf Deine Frage: Ich hatte Grub2 zum Abschluss manuell installiert, weil ich mir dachte, dass es eine gute Idee sei, die Kernel der anderen Linuxinstallationen gleich automatisch einbinden zu lassen. Die entsprechenden Lenny-Grubeinträge hatte ich vor dem Upgrade mit UUID-Bezeichnungen versehen. "UUIDs" für MBRs gibt es aber offensichtlich nicht.
Es ist nun so, dass ein im MBR der ersten IDE-Festplatte installierter Debian Squeeze-Grub1 die openSUSE-Installation auf der ersten SCSI-Festplatte mit dem Chainloader-Eintrag für (hd2,1) tatsächlich starten kann, die Squeeze (bei aktiviertem SCSI-Strang) als erste Festplatte des Systems (sda) ansieht. Ich habe das gerade eben nach einem kurzen Ab- und Wiederanschalten des SCSI-Stranges getestet. Ist SCSI aktiviert, will Squeeze wieder in den "falschen" MBR der ersten SCSI-Festplatte installieren.
Wie behebt man diesen Fehler und wie bringt man Debian bei, die erste IDE-Festplatte als erste Festplatte des Systems anzusehen, ausschließlich im Hinblick auf die fehlgeleitete Bootloaderinstallation in den MBR?
Schon ein angesteckter USB-Stick könnte vielleicht das ganze System durcheinanderbringen. Ich kann ja einmal ausprobieren, ob Squeeze Grub auch in den MBR eines USB-Sticks zu schreiben bereit ist. So von wegen Grub in den MBR der "ersten Festplatte" schreiben. :-)
IMHO ist das ein Bug, und kein "kleiner". Fragt sich nur, in welcher Software.
Nachtrag:
Der Fehler ist IMO folgender:
Grub2 entscheidet zwar nach der UUID, welche Festplatte er zum Booten benutzen soll, zum Herausfinden des richtigen MBRs richtet sich Grub2 aber nach den /dev/-Pfaden und ignoriert dabei auch noch die festgelegte Bootreihenfolge im BIOS.
So kommt es dann zu dem MBR-Durcheinander.
Ein entsprechender Hinweis in den Debian-Upgradehinweisen fehlt.
Danke für die ausführliche Antwort. Könnte das Problem im BIOS selbst liegen?
Dem hier zB ging es wie dir:
http://forums.debian.net/viewtopic.php?f=7&t=63800
Bei mir ist es ein Intel-Motherboard, und die ersten beiden IDE-Platten sind immer sda und sdb. Das SATA-Array ist immer sdc. Und so bleibt es auch bei jedem Reboot.
Ich habe nachgeschaut, aufgefallen ist mir nichts.
Es handelt sich um ein älteres Intel PIV-Board (845BGL) mit etwas spartanischem Phoenix-Bios. Die Bootreihenfolge ist wie folgt festgelegt: Erste IDE-Festplatte, zweite IDE-Festplatte, erste SCSI-Festplatte, Wechseldatenträger (z.B. USB-Stick).
Das Squeezeupdate hat hier mehrmals auf anderen Rechnern funktioniert (dabei handelte es sich aber nicht um Mischsysteme), nur bei diesem Mischsystem gab es dieses Problem.
openSUSE 11.1 z.B. sieht auch die erste SCSI-Festplatte als erste, installiert den MBR aber trotzdem in die erste IDE-Festplatte.
Somit besteht die Gefahr, dass sich je nach Distro und Kernel die Bootreihenfolge automatisch ändert.
Ein BIOS-Bug im Zusammenspiel mit Linux kann ich natürlich nicht ausschließen. Manche Linuxdistros erkennen auch nicht, dass der Onboard-Audio-Chip des Mainboards abgeschaltet ist und sprechen dann die eigens installierte Extra-Soundkarte nicht richtig an.
Es ist schade, dass sich Grub2 nicht auch bei der MBR-Installaton ebenfalls an den UUIDs ausrichtet. So könnte man z.B. über die Möglichkeit nachdenken, bei der Installation von / auf der Ex-hda-Festplatte einen Klarnamen wie "Erste Festplatte" zur jeweiligen UUID zuordnen zu lassen und dann dafür sorgen, dass man vor der Grub2-Installation einen Eintrag "Grub2 in den MBR von "Erste Festplatte" installieren" auswählen kann.
Dein Link zeigt ja, dass das Problem tatsächlich auftritt, sowohl bei IDE-SATA- als auch (wie bei mir) bei noch älteren IDE-SCSI-Mischsystemen.
Und eine vielleicht nur etwa 95%ige Erfolgsquote reicht bei einem Bootloaderprogramm IMO nicht, weil die Auswirkungen eines "Fehlers" halt so fatal sind.
Das ist ja wirklich eine sehr ärgerliche Sache. Ich werde in nächster Zeit noch ein paar solcher älterer Mischsysteme von Lenny auf Squeeze updaten müssen. Immerhin bin ich nun vorgewarnt, dies wohl besser vor Ort statt wie gewohnt remote zu machen...