[OT] schiefgelaufene Upgrades
Hallo,
Früher tm konnte man ein Debian System noch "gefahrlos upgraden" beim Upgrade auf wheezy flog mir so einiges um die Ohren (aptitude dist-upgrade).
Eine kleine Leidensgeschichte und ein paar Erfahrungen der letzten Monate mit meinen Debian Systemen:
Upgrade auf wheezy eines Rootservers:
1x NIC: Realtek 8110S/8169S
Kernel: 3.2.0-4-686-pae
(in der sources.list war non-free wegen treibern eingetragen, leider hatte ich deb-src Zeilen vergessen)
Realtek Netzwerktreiber fliegen raus, nach dem Upgrade kein Remotzugriff mehr:
Freundlicherweise schliesst Provider (Hetzner) Remote Console für Direktzugriff an: kostenfreies Zeitlimit 3h ...
Stundenlanges gesuche liefert einen wiki Eintrag und viele User die wohl dasselbe Problem hatten (debianforum usw.)
die Lösungen treffen bei mir aber wohl nicht/nur teilweise zu
Beispiel:
aptitude install build-essentials`uname -r` firmware-realtek
-> haha aptitude install geht nicht weil kein netzwerk verfügbar ist ...
Switchen zwischen Rescue System und (offline) root-Server:
(Download firmware-realtek (non-free) und inst. per
dpkg -i firmware-realtek)
lsmod:
r8169 41830 0
mii 12595 1 r8169
Blacklisten des Moduls und manuelles laden r8169 funktioniert
aber eth0 ist trotzdem nicht verfügbar.
/etc/network/interfaces
auto eth0
iface eth0 inet static
address xxx.xx.xxx.xxx.
... auch ok, alles richtig gesetzt.
ifup eth0
schlägt fehl ...
Versuch: Direkt bei Realtek Taiwan downgeloadeter Treiber und per rescue System übertragen lässt sich nicht kompilieren, Meldungen Pfadfehler usw. evtl. Buildsystem nicht komplett, was auch immer.
vielleicht endgültige Lösung (warten wir das nächste Kernelupgrade ab):
-> udev Regeln angepasst
/etc/udev/rules.d/70-persistent-net.rules:
# PCI device 0x10ec:/sys/devices/pci0000:00/0000:00:0d.0 (r8169)
SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:16:17:xx:xx:xx",
ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1"
eth1 in eth0 geändert
ifup eth0
Zugriff per ssh ok.
Warum zum Teufel wird die nic einfach automagisch auf eth1 umgebogen, ist es nicht möglich bei möglicherweise zu erwartenden
Fehlern mit fehlenden Netzwerktreibern usw. Warnmeldungen auszugeben?
Als User würde es mich auch freuen wenn die Treiber opensource sind und nicht aus non-free etc. kommen,
aber wichtiger ist mir dass sie generell gut funktionieren hauptsächlich bei so essentiellen Dingen wie
Netzwerkkarten ohne die man ziemlich doof aussieht.
Realtek ist wohl da auch nicht gerade ein leuchtendes Vorbild.
Rootserver:
An alle die vielleicht ähnliche Probleme haben hatten:
1. screen benutzen
2. laufende ssh Sitzung erst zumachen wenn eine 2. ssh Sitzung wirklich sicher aufgebaut werden kann
3. Reboot nur durchführen wenn man sich ziemlich sicher ist daß man danach auch wieder aufs System kommt
---
Desktop-Systeme:
(wheezy upgrade afair von etch)
icedove -> Font Fehler nach irgend einem Upgrade.
Mails werden in der Vorschau richtig angezeigt sobald man scrollt verschwimmt alles zu einem "Buchstabenbrei" irgend ein Font fehlt nach 2-3h aufgegeben oder ist nicht richtig registriert, naja kann man ja auch ausdrucken und dann angucken.
---
Treiberupgrade nvidia 3D Treiber
(Geforce Karte), mal funktioniert der xserver start nicht mehr usw.
-> nein die freien Treiber will ich nicht, weil Sie noch schlechter performen und weil es bei den "proprietären wenigstens meistens funktioniert" und ich garantiert keine Windows, $Apple Lizenz/Geräte kaufe nur um mal ein paar Stunden zu daddeln ...
ATI/AMD kauf ich nicht mehr, da war es noch schlimmer mit dem Drecks fglrx Treiber ...
Mit systemd fang ich jetzt erst gar nicht an ist mir als "Anwender" prinzipiell egal ob Init V, upstart, systemd: Hauptsache es funktioniert ...
Manchmal kommt es mir so vor als ob die Softwarequalität in letzter Zeit eher wieder abnimmt.
Da freu ich mich doch richtig aufs nächste dist-upgrade ;-)
Um nicht nur zu schimpfen würde ich auch gerne testen sofern die "Hürden fürs testen" nicht zu hoch sind.
Reply to: