Ubuntu-Forum & Kubuntu-Forum | www.Ubuntu-Forum.de

Die genannte Aktualisierung lief ohne äußerlich erkennbare Fehler durch. Nach dem 1. Neustart passierte folgendes (Ausgabe auf dem Bildschirm - von mir hoffentlich fehlerfrei abgeschrieben und wieder eingetippt):
...
Begin: Running /scripts/local-top ...
Done.
libudev: udev_monitor_new_from_netlink: error getting socket: Invalid argument.
[13.105268] wait-for-root [869]: segfault at 00000030 eip b77cbf2b esp bfe61890 error 4
segmentation fault
Gave up waiting for root device. Common problems:
...

ALERT! /dev/disk/by-uuid/75c86e83-b2ae-4e1c-9f78-6a4489687a07 does not exist. Dropping to a shell!
...

Insbesondere die letzte Zeile irritiert mich weil ich nicht verstehe, ob das eine Diagnose oder nur eine Vermutung ist, was die Ursache des erstgenannten Segmentation Fault ist.
In der gestarteten Shell habe ich noch dmesg aufgerufen und erhielt als letzte Zeile der Ausgabe:
.
Mit den UUIDs gab es übrigens wirklich Probleme, denn ich mußte die Root-Partition vergrößern, um Platz für die beinahe 2000 Aktualisierungspakete zu schaffen. Dadurch haben sich 2 UUIDs geändert. Das kann aber nicht die Fehlerursache sein, denn immerhin ist das alte System nach dieser Aktion ohne Murren gestartet - und ohne daß ich die neuen UUIDs irgendwo eingetragen habe.
Von einem Rettungssystem aus habe ich im neuen System /etc/fstab und /boot/grub/menu.lst überprüft und, wo erforderlich, angepaßt. Die richtigen UUIDs habe ich mit blkid aus dem Rettungssystem heraus emittelt. Der Fehler läßt sich davon nicht beindrucken und erscheint unverändert.
Ich tappe im Dunkeln und wäre für Erleuchtung sehr dankbar.

Zitat von »leseratte«

Kommst Du noch in den recovery mode rein? Wenn ja, kannst Du ein reinstall von initramfs-tools probieren:

	Quellcode
1	apt-get install --reinstall initramfs-tools

Ja; der recovery mode stürzt beim Booten allerdings haargenauso ab, wie der Betriebsmodus. Da er aber in eine Shell des Systems auf der ramdisk geht, kann und werde ich deinen Vorschlag ausprobieren.

Zitat von »leseratte«

Ist denn das UUID Problem noch aktuell? Aus dem letzten Absatz meine ich herauszulesen, dass ebbi97a das schon behoben hat und nun noch der segfault stört!

Ich weiß nicht, was der wirkliche Fehler ist; die Meldungen sind für mich semantisch unverständlich. Die UUIDs habe ich vorbeugend verbessert ohne zu wissen, ob sie mit dem Fehler zu tun haben.

Zitat von »floogy«

Was sagen sudo blkid und sudo fdisk -l ?

Und existiert UUID 75c86e83-b2ae-4e1c-9f78-6a4489687a07 ?

Suche diese mal mit rgrepunter /boot /dev und /etc .

Zum upgrade bitte auch das hier lesen:
https://help.ubuntu.com/community/LucidU…o%2010.04%20LTS

Im wesentlichen sagen blkid und fdisk das Erwartete: die besagte Partition existiert (ich werde das morgen nocheinmal sorgfältig durchprüfen, wenn ich ausgeschlafen habe).
Dein erster Verweis hat allerdings Überraschendes (und Relevantes) ergeben:

Zitat

5. At the end of the upgrade process you will be required to restart the server in order to boot into the new kernel. If you do not have access to the console of the system you are upgrading, you may need to edit /boot/grub/menu.lst and change the default boot kernel to the newly installed 10.04 kernel. If this step is not performed your server may attempt to boot into the 8.04 LTS kernel and will hang.

In der /boot/grub/menu.lst steht insofern Blödsinn, als der neue Kernel vergessen worden ist; da stehen nur 3 alte drin. Zwar verwende ich nicht die Server-Version von Ubuntu, aber der Hinweis gilt möglicherweise für die Desktop-Version genauso.

Zitat von »Tronic69«

Zitat von »ebbi97a«

Zitat

In der /boot/grub/menu.lst steht insofern Blödsinn, als der neue Kernel vergessen worden ist; da stehen nur 3 alte drin. Zwar verwende ich nicht die Server-Version von Ubuntu, aber der Hinweis gilt möglicherweise für die Desktop-Version genauso.

Ich hatte letzte Woche auch ein ähnliches, aber nicht ganz so gravierendes Problem beim Upgrade von 9.04 auf 9.10 (s. hier).

Aus irgendeinem Grund wird nach der Installation eines neuen Kernels die menu.list nicht automatisch aktualisiert und daher bootetet das System nicht. Es versucht vermutlich mit einem alten Kernel zu booten, der nicht mehr zum neuen System passt.

Wenn man nach dem eigentlichen Upgrade und VOR dem danach fälligen Neustart des Systems einmal update-grub ausführt, dann wird die menu.list korrekt angepasst. Wenn Du also noch mit einem alten Kernel booten kannst, dann versuche es doch mal damit update-grub auszuführen.
Die Alternative wäre einfach eine minimale menu.list manuell zu erstellen oder einfach die alte anzupassen auf den neuen Kernel. Im Prinzip müsste es reichen diesen Bereich anzupassen (Auszug von meinem Server):

Das habe ich auch so vor; erst will ich aber erst die vorher diskutierten Überprüfungen durchführen. Habe jetzt schon 4 Tage verloren; da kommt es auf die eine oder andere Stunde auch nicht mehr an.

Zitat von »Fredl«

Zitat von »ebbi97a«

In der /boot/grub/menu.lst steht insofern Blödsinn, als der neue Kernel vergessen worden ist

Das erinnert mich an die Frage des post-install-scripts beim kernel-update. Sinngemäß etwa: "Es gibt eine neue Version der menu.list. Wollen sie die aktuelle behalten oder ersetzen?" Viele sagen da im Reflex "behalten" (ist -glaube ich-, sogar default). Jedenfalls wäre die "neue" nichts anderes als das, was update-grub gerade produziert hat -inklusive neuem kernel in der Liste- und somit wäre "ersetzen" die richtige Antwort gewesen.

Das ist genau der Punkt!
Bei diesen ganzen Fragen im Stil "Wollen Sie die alte Version beibehalten oder lieber die des Paket-Maintainers installieren?" weiß ich nie recht, was ich eigentlich wollen soll. Ich weiß nur, daß ich in der Vergangenheit bei meinen Debian-Systemen (3 Stück) und meinem Ubuntu-System schon öfter mit der "neuen" Version hereingefallen bin: Da waren dann wichtige Einstellungen weg, die ich nirgends notiert hatte und mir erst mühsam wieder erarbeiten mußte. Deswegen habe ich diesmal grundsätzlich bei allen Fragen dieser Art die "alte" Version gelassen. Deine Vermutung trifft also 100%ig zu.
________________________________________________________________________________
Nachtrag von 10:24 MESZ:
Zwischenzeitlich war ich schon einen Schritt weiter, dieser Fortschritt ist allerdings schon wieder zuschanden gegangen.
Nachdem ich /boot/grub/menu.lst und den den neuen Kernel erweitert und den MBR neu erzeugt hatte, konnte ich im abgesicherten Modus starten und kam in ein Textmenü. Vorher huschten allerdings jede Menge Meldungszeilen durch, in denen udev vorkam. Ich konnte mich unter einer meiner Kennungen anmelden, bekam eine Shell und, dadurch übermütig geworden, starte ich neu (mit sudo reboot) und wählte den Normalmodus.
Das hätte ich nicht tun sollen: Beim Wechsel in den graphischen Modus wurde und blieb der Bildschirm dauerhaft schwarz und es ging nur noch Ausschalten per Strom weg. Seitdem komme ich auch nicht mehr in den abgesicherten Modus. Das System muß sich irgendwas gemerkt haben und geht nach zahlreichen Meldungen nahtlos in den schwarzen Bildschirm über.

Das mit dem Segmentation Fault + verwandten Symptomen verbundene Problem ist vermutlich behoben. Für den jetzt bestehenden Fehler (im weiteren Verlauf neu aufgetretenen...) werde ich bei Bedarf ein neues Thema (mittlerweile das dritte zu diesem upgrade-Vorgang ) aufmachen, sobald ich die ähnlich gelagerten Fälle von anderen Leidgeprüften hier im Forum geprüft habe und sie auf meinen Fall nicht zutreffen.
Zwischenzeitlich möchte ich mich bei allen bedanken, die mir bis hierher weitergeholfen haben!

Zitat von »Fredl«

Zitat von »ebbi97a«

Beim Wechsel in den graphischen Modus wurde und blieb der Bildschirm dauerhaft schwarz

Vermutlich ein Grafiktreiber-Problem. Du müsstest aber trotdem mit Alt-Strg-F2 in eine echte Textkonsole kommen, um hier Reparaturen oder zumindest Analysen durchführen zu können.

Nein; es rührt sich gar nichts mehr; es ist alles im Eimer.

Zitat von »Fredl«

@Tronic: Man muss zwischen Grub und Grub2 unterscheiden. Grub2 erzeugt sich das Bootmenü mit Hilfe seiner Hilfsscripte und braucht deshalb keine menu.lst. Deshalb kann update-grub im post-install-hook entfallen. Wenn man natürlich durch Upgrade von einer älteren Version noch Grub drauf hat, fehlt das dann natürlich. Nachgesehen hab ich diesbezüglich aber nicht, ist also nur mein Verdacht.
Der TE hat aber 8.04, wo im post-install noch update-grub enthalten war.

Ich habe definitiv grub(1).

Zitat von »Fredl«

Ansonsten ist es, wie Du richtig feststellst, einen eigenen thread wert.

Die → Fortsetzung.