Hallo!
Ich denke, es ist sinnvoll, einen Thread anzulegen, in dem Nutzer schnell problematische Updates berichten können.
Es sollte sich hierbei aber schon über um kritischere Themen wie Bootprobleme, Kernel-Crashs, WM-Abstürze oder Probleme mit bestimmter Hardware handelt.
Einer tritt immer zuerst in die Falle und macht das Update. 🐸 Hier können die Anderen so schnell vor einem Update gewarnt werden (ohne dass der Karmic-News Thread überfüllt wird).
Z.B. habe ich gerade ein Update eingespielt, welches ich jetzt bereue: Mit dem heutigen Update funktioniert der p54-WLan-Treiber (wichtig für Ralink-Chip basierende Karten) nicht mehr und stürzt mit "Error -101" ab. Somit kann man nur noch mittels Netzwerkkabel updaten. (Blöde...)
Mal sehen, wann das gefixt wird.
[Sammelthread]: Karmic Update-Warnungen
![]() Anmeldungsdatum: Beiträge: 1066 Wohnort: Bonn |
|
Anmeldungsdatum: Beiträge: 10220 |
Auch Hallo - Targion, im Prinzip eine brauchbare Sache! Nur ich befürchte, dass es auch hier, wie mir unter Jaunty mehrfach passiert ist, so saublöde Kommentare kommen, wie: dann hättest eben nicht unstable nehmen dürfen, oder sinngemäß. Und auch sollte das dann schon detailierter sein, u.a. mit Hinweis auf Ubuntu-Typ und Architektur, in Deinem Fall konkretere Aussage zum Ralink-Chip-Satz und wie das WLan gesetzt ist und was noch ggf. wichtig erscheint (ich hatte keine Probleme mit den Updates der letzten Tage). Denn der Beitrag geht ja weiter und die betroffenen (bzw. nicht tangierten) Maschinen sind jedesmal andere, man kann also nicht den Titel als solches zur Klassifizierung nehmen. Ich erwarte dann nicht einmal Gegenkommentare, außer wenn qualifiziert auf ein bug-report, fix-release oder workaround hingewiesen wird. Mal sehen, wie andere darüber denken. gruß syscon-hh |
![]() Anmeldungsdatum: Beiträge: 12317 Wohnort: /home/flo |
Die Idee an sich ist nicht schlecht, Targion. Darum füllt diesen Thread ruhig. Und off-topic Kommentare, syscon, wie dann hättest eben nicht unstable nehmen dürfen können die Supporter ja verbergen... 😛 Ich habe "leider" noch nichts beizutragen, was aber nicht das Schlechteste sein muss. Hier läuft alles sehr schön. Liebe Grüße, FLO |
Anmeldungsdatum: Beiträge: 10220 |
So heute ist mal so ein Tag - geprüft bei (genervt durch) KDE-4 → packagekit + Zubehör! Betroffen: Server = archive.ubuntu.com (Hauptserver) Desktop= GNOME, KDE-4 CPU = amd64, i386 Pakete = packagekit 0.4.8-0ubuntu1, und weitere Man sollte ein bisschen warten, bis alle Pakete mit dieser Version (0.4.8) auf der Piste sind (qt11 ?? - Abhängigkeiten werden nicht erfüllt, damit bricht kpackagekit mit segfault ab), man kann zwar noch starten, muss aber die restlichen Updates bzw. Reparaturen vorerst im Terminal nachholen sudo apt-get ... bzw. sudo aptitude .... gruß syscon-hh |
(Themenstarter)
![]() Anmeldungsdatum: Beiträge: 1066 Wohnort: Bonn |
Ich kann dazu jetzt entwarnung geben: Es läuft alles wieder! Endlich haben sie sich erbarmt und PackageKit auf die aktuellste Version (0.4.8) aktualisiert. |
Anmeldungsdatum: Beiträge: 10220 |
Erneut ein Problem - 23. Juni 2009, Update grub2 (GNOME, KDE4 getestet) - als Hinweis, ich habe hier eine getrennte Boot-Partition, was ich so auf den ersten Blick aber als Fehlerquelle ausschließe. Nach dem Update und einem Reboot bleibt der Grub2-Bootloader hängen. Ein Vergleich neu gegen alt der /boot/grub/grub.cfg (Backup-Datei) zeigt den Unterschied - neu: ### BEGIN /etc/grub.d/00_header ### .... search --no-floppy --fs-uuid --set 096f72b3-bb76-4320-afa6-9a58986f80fa .... ### END /etc/grub.d/00_header ### dazu der bisherige Eintrag ### BEGIN /etc/grub.d/00_header ### .... search --fs-uuid --set 096f72b3-bb76-4320-afa6-9a58986f80fa .... ### END /etc/grub.d/00_header ### Nachdem ich dieses im rescue-mode rausgenommen hatte, lief es durch. Durch ein update-grub wird der Fehler wieder eingebaut. Neu eingespielt wurde die Datei /etc/grub.d/30_os_prober.dpkg-dist gruß syscon-hh Nachtrag: Der Bootloader meldet: unknown command: --no-floppy ( 391044 ) |
Anmeldungsdatum: Beiträge: 285 |
Der Fehler steht aber in der /boot/grub/grub.cfg. Zumindest hab ich das --no-floppy da gefunden 😉 Nach dem entfernen dieses Befehls, konnte man wieder normal starten. |
![]() Anmeldungsdatum: Beiträge: 87 |
Die Karmic Update-Warnung kommt direkt von Ubuntu Intrepid, sobald Du ein Upgrade machen möchtest. Hier steht explizit, dass Dein System dann evtl. nicht mehr läuft. 😈 Ich sehe diesen Thread als ein wenig problematisch an: jeden Tag kommen im Schnitt 50-100 MB an Updates, und Probleme und Warnungen, die jemand heute hier postet können morgen schon wieder Geschichte sein. Seht das hier nicht als den vielzitierten "hättest nicht updaten dürfen"-Mist an - aber wir sind bei Alpha 2 und damit sind Änderungen täglich, massenweise und kurzlebig... Viele Grüße, Nacktmull |
Anmeldungsdatum: Beiträge: 1449 Wohnort: Waterkant |
Nacktmull schrieb:
Man kann von Intrepid direkt auf karmic updaten? Interessant...
2 Gründe für diesen Thread:
2. Können Probleme auch mal länger anhalten.
Ich sprech mal nur für mich: Keine Panik, mach ich nicht. ☺ Gruß |
![]() Anmeldungsdatum: Beiträge: 87 |
Sorry, mein Fehler, ich habe natürlich von Breezy auf Karmic upgedated. 👍 (vor hier die Fragen kommen: nein, das geht nicht 😉! ) Und ich gebe Dir ja auch recht, jeden Tag basteln ist nicht jedermanns Sache. Vor allem nicht auf nem Produktivsystem (wie bei mir hier). Aber ich konnte es halt nicht lassen 😕 |
Anmeldungsdatum: Beiträge: 285 |
Für alle Inteluser: Es gibt ein Update auf Kernel 2.6.30.10. Mit Standardeinstellungen lässt sich nicht booten. Daher bitte die Bootoption i915.modeset=0 dranhängen. |
Anmeldungsdatum: Beiträge: 10220 |
❗ Nun aber ein ernsthaftes Problem ❗ Das heutige Update (24. Juni, 10:33) mit busybox-initramfs-1.13.3-1ubuntu2 kann dazu führen, dass das System nicht mehr startet - bitte abwarten - 391299-fix ist unterwegs. gruß syscon-hh Workaround (für diejenigen, die dieses nicht lesen woll(t)en), um überhaupt wieder ins System zu kommen: Von hier das passende Paket holen (je nach CPU ändern) und im Livesystem mit chroot einbringen - am Beispiel root = /dev/sda1: ubuntu@ubuntu:~$ sudo mount /dev/sda1 /mnt ubuntu@ubuntu:~$ sudo mount -o bind /dev /mnt/dev ubuntu@ubuntu:~$ sudo mount -o bind /proc /mnt/proc ubuntu@ubuntu:~$ sudo mount -o bind /sys /mnt/sys ubuntu@ubuntu:~$ sudo chroot /mnt dort dann mit dpkg -i *.deb das Paket einbringen und anschließend noch update-initramfs -u nicht vergessen. Entwarnung: Sowohl i386 als auch amd64 getestet - läuft wieder (15:53) |
Anmeldungsdatum: Beiträge: 10220 |
Entwarnung # 2: Grub2 kann jetzt mit --no-floppy umgehen. Das Paket GRand Unified Bootloader_1.96+20090611-1ubuntu2 behebt das Problem grundsätzlich. Damit diese Änderung wirksam werden kann, muss man nach den Update noch sudo grub-install /dev/Meine_Boot_Partition sudo update-grub im Terminal / Konsole eingeben - beim nächsten Starten ist dann die Welt wieder in Ordnung. Nur noch mal ein Hinweis: Die Zählweise unter Grub-Legacy weichen von Grub2 ab. Wird unter Grub-Legacy so gezählt, dass die erste Partition = (hdx,0) bezeichnet wird, so ist das bei Grub2 jetzt (hdx,1)! Nur falls das mal einer von Hand korrigieren muss. gruß syscon-hh |
Anmeldungsdatum: Beiträge: 104 |
Hallo, habe ein anderes Problem. Das system akzeptiert das passwort für die verschlüsselten laufwerke nicht mehr (kernel .30.10). Mit dem älteren geht es ohne probleme, also 30.9), eine idee wie man das beseitigt? ☺ |
Anmeldungsdatum: Beiträge: 10220 |
@Kamikaze321 - mal ins Blaue: Wenn Du einen splash am Laufen hast, beim Grub-Auswahlmenü diesen am Ende der Kernelzeile rausnehmen. @ ALL: Der Fehler als solcher ist noch nicht eingrenzbar (also welches Update / Paket) - ich habe das Paket busybox-initramfs_1.13.3-1ubuntu4 in Verdacht, da ein Downgrade auf die Vorgänger-Version das System mit Splash starten lässt. Nur muss man bei diesem älteren Paket (siehe weiter oben) auch was tun - einen Zusatz in der Kernelzeile: rootdelay=10 oder auch einen noch höheren Wert eintragen. Am einfachsten erscheint mir aber im Moment, auf den Splash-Balken zu verzichten, bis das Problem behoben ist. gruß syscon-hh |