Ich glaube nicht, dass wir uns in diesem Punkt verstehen. Ich finde den Prober toll. Der findet halt alles, was ansatzweise nach Betriebssytem aussieht. Mein Rekord waren ca. 50 Kernel (das Ding hat wirklich alle meine lange vergessenen oder verdrängen Sicherheitskopien auf meinem damals neuen LVM-Datengrab gefunden). Kein gefundener Eintrag war ohne Anpassung lauffähig. Wie Du geschrieben hast - shit in, shit out. Daraus aber ein stabiles System zur automatischen Pflege von Starteinträgen zu machen, finde ich ein wenig verfehlt. Wenn ich mich recht erinnere gab es früher mal so was wie supergrubdisk. Das hat auch Kernel gefunden und Systeme gestartet. Und es hat seine Gründe, dass es nicht als Standard eingebaut wurde.
Du sprichst die Lernkurve an. Meine war mit dem direkten Wechsel von Ubuntu zu Arch recht steil. Das habe ich auch bewusst so gewollt, Gentoo habe ich nur aus einem Grund nicht genommen - ich und wirklich nur ich entscheide, wann ich was kompiliere und wann nicht. In dem Moment ist auch die Einschätzung, was Frickelei ist, eine persönliche. Konfiguration über Prober ist Gefrickel und wird es immer bleiben. Mit dem Prober nach einer Installation zu suchen und dann bei Gefallen einen wartbaren Eintrag in Dateiform in /etc/grub.d daraus zu machen, ist Linux. Noch besser, es ist KISS. KISS bedeutet aber nicht zwangsläufig, das ein System nach KISS den ganzen Tag mit Dir kuschelt. Einfachheit als Prinzip ist halt wirklich nur dann einfach, wenn man es geschafft hat, diese Abstraktionsebene zu erreichen, in der es einfach wird. Und das kann verdammt schwer werden
Dass dieser Ansatz nicht unbedingt anfängertauglich ist, versteht sich von selbst. Das Argument mit den Multiboot und Anfängern führt sich selbst ad absurdum, diese Tatsache ist am besten in uu.de zu sehen. Welches Werkzeug will man Usern in die Hände geben, um Multiboot zu warten, wenn die Lernbereitschaft nicht mal für
ein stabiles Single-System ausreicht. Manchmal ist Linux wirklich gut dazu geeignet, User vor sich selbst zu schützen. Was für den aktuellen Wissenstand einfach zu kompliziert ist, geht halt nicht. Das mag frustrierend sein, wenn man genau das, was man in dem Moment braucht, nicht kann. Wenn man es aber wirklich braucht, kann man das lernen und danach auch sicher anwenden, ohne sich in den Fuss zu schießen.
Da das aber allen so geht, ist es gerecht. Wie man z.B. in meinen Beiträgen zu BKL sieht, war ich mit der Entscheidung, BKL aus dem aptosid-Kernel zu nehmen, nicht wirklich einverstanden. Da ich diesen Zustand so nicht akzeptieren konnte, habe ich das halt als Chance genommen, mich mit dem Thema Kernelbau ein wenig auseinanderzusetzen. Stand so oder so auf der ToDo-Liste. Nur der Zeitpunkt war echt mistig. Das war aber ein Problem, das ich durch einen einfachen Rechnerneustart gelöst habe. In der Zeit, bis mein Kernel fertig war, hab ich halt Arch und Ubuntu genutzt (und wieder mal gemerkt, warum ich mir aptosid als debianoid ausgesucht habe).
Noch einen Hinweis zu Deinem Problem mit Grub. Das debian BTS ist dafür den denkbar schlechteste Ort. Der Bugtracker von Grub wäre dafür wesentlich besser geeignet. Dort wirst Du dann sehen, dass Du mit Deinem Problem nicht allein bist.
http://savannah.gnu.org/bugs/?group=grub Ein Problem mit Grub ist nicht notwendigerweise ein Problem von debian. debian macht aus sich in freier Wildbahn entwickelnden Programmen ein relativ handzahmes Gesamtkunstwerk. Fehler in den Paketen sollen nicht durch debian behoben werden, die Buben haben mit dem Paketieren und der Pflege des Gesamtsystems genug zu tun. So was gehört in den Upstream und wird, wenn es ein neuer und wichtiger Fehler ist, dort auch entsprechend priorisiert werden. Nach der Bearbeitung im Up fließen die Änderungen automatisch wieder zurück an debian und alle Distributionen, die Grub nutzen. Allerdings glaube ich in diesem speziellen Fall nicht an eine baldige Änderung. Und da das in allen Distributionen so gehandhabt wird, bleibt es dann wohl erst mal beim eigenen funktionierenden Workaround, bis die Sache generell gegessen ist. Alternativen gibt es in solch einem Fall keine.
Und doch, man wird sich um Deinen Bugreport kümmern, wenn er von der Wichtigkeit an der Reihe ist. Wahrscheinlicher ist allerdings, dass er nie bearbeitet wird. Das ist deshalb wahrscheinlich, weil durch die Änderugen an generelleren Sachen sich der von Dir gemeldete Fehler von selbst lösen wird, sobald übergeordnete Fehler (oder die übergeordnete unausgereifte Implementation) gefixt sind.
