d-u über GUI

[ayla]

Hi,

war da nicht auch das Problem daß, wenn bestimmte Sachen schief gehen -frag mich jetzt bitte niemand was genau, ich erinnere mich nur daß da mal irgendwas im Forum zur Sprache kam- und noch kein reboot durchgeführt wurde, es noch möglich war das System wieder zu reparieren aber nach einem reboot das schwierig, bzw für den nicht sehr versierten Nutzer so gut wie nicht möglich war? Irgendwas mit dpkg oder apt?

Falls ich mich da richtig erinnere finde ich daß "init 3" nicht soo schwierig ist wenn es sicherer ist.

Gruß
ayla

[ralul]

@ayla, ja für schief gehende DUs müsste man ein Notstartsystem - iso-Live-rescue - haben, oder ein Btrfs-snapshot feature, mit dem man den Vortagesstand wiederherstellen kann.

[holgerw]

Hallo,

im Zusammenghang mit Aktualisierungen unter X gab es früher Diskussionen, damit meine ich nicht diese hier, in denen das als schlimmes Horrorszenario dargestellt wurde. Dabei beschränkte sich mancher nicht nur auf Debian. Aber das unterstellt dann, dass etwa die Distributoren von openSUSE in Kauf nehmen, dass Anwender ihr System zerlegen können. Ich lese ja schon einige Zeit auch zu openSUSE, dass bei einem DU unter X ein System halb geschrottet wurde, habe ich noch nirgendwo gelesen.

Auch größere Deaktualisierungen gehen übrigens ohne Schwierigkeiten. Unter laufendem KDE 4.7 habe ich bei drei PCs auf KDE 4.6 deaktualisiert.

Wenn das unter Debian Sid brisant ist, werte ich das nicht als schlecht, dann ist das eine Eigenart von Sid. Ich nutze Debian Sid und openSUSE, daher interessiert mich hier: Was läuft unter dem Nürnberger Linux anders, dass es dort offenbar nicht brisant ist? Und von statischer Distribution kann man bei meinem openSUSE nicht mehr sprechen, schon über das extra KDE Repo kommen häufig große Mengen neuer Versionen, und die lasse ich immer unter laufendem KDE durchführen.

Viele Grüße,
 Holger

[bluelupo]

Hallo,
[...]
Wenn das unter Debian Sid brisant ist, werte ich das nicht als schlecht, dann ist das eine Eigenart von Sid. Ich nutze Debian Sid und openSUSE, daher interessiert mich hier: Was läuft unter dem Nürnberger Linux anders, dass es dort offenbar nicht brisant ist? Und von statischer Distribution kann man bei meinem openSUSE nicht mehr sprechen, schon über das extra KDE Repo kommen häufig große Mengen neuer Versionen, und die lasse ich immer unter laufendem KDE durchführen.

Viele Grüße,
 Holger

Hi Holger,
das sehe ich für Fedora genauso (vor kurzem gestestet) wenn man den Entwicklerzweig (Rawhide) nutzt. Dort kommen laufend neue Versionen herein, die mit GUI KpackageKit im laufenden Betrieb upgedatet werden.

Ich schätze das Risiko bei SuSE, Debian oder Fedora nicht unterschiedlich ein, aber Debian (SID) muss meiner Meinung etwas anders machern als SuSE und Fedora bei Aktualisierungen unter einen laufenden X. Ich bin leider kein Spezialist der dies grundlegend beurteilen kann :-(

[hefee]

Der Unterschied zwischen Sid und OpenSuse;fedora etc. ist, das die Matainer von Debian davon ausgehen, das es in der Konsole geschieht und auch das Sid auch mal ein kaputtes System hinterlassen darf. Sid ist der unstable Teil von Debian und wird von den Mantainern nicht empfolhen als System zu installieren

Bei OpenSuse und Fedora gehen die Mantainer davon aus das die Aktualisierung aus X herhaus geschieht, bzw. funktionieren soll -> Mit dieser Masgabe können die Aktualisierungen sorgen, das dies auch klappt.

[bluelupo]

Hi hefee,
okay die logischen Gründe der Maintainer sind mir schon bekannt aber warum sperren sich die Debianer dermaßen gegen eine Vereinfachung eines d-u oder machen die technisch gesehen den Systemupdate gänzlich anders. Eine hundertprozentige Sicherheit gegen kaputte Systeme kann's nicht geben weder bei Fedora, Suse oder Debian.

[agaida]

Update beim Runterfahren: Jo klar, dann vertippst Du Dich oder aber liest nicht, was er updaten will. Und beim nächsten Start bleibt der Rechner stumm.

Weit hergeholt, aber solange die Kiste noch läuft, ist es manchmal so, dass man im Fall der Fälle wirklich weniger Arbeit hat. Und noch was fällt mir in dem Zusammenhang noch ein: Wenn ich die Kiste ausschalte, hat das einen Grund: Ich habe keinerlei Böcke mehr, mich mit dem Ding zu beschäftigen. Mögliche Meldungen treffen dann auf ungefähr diese Aufnahmebereitschaft: Scheiss drauf, Feierabend.

@Bluelupo: Die Buben sind halt ein wenig konservativ. Es ist auch eigentlich egal, dass man stable ohne X aktualisieren soll. Der läuft auf stable-Maschinen meist eh nicht . Und Testing und Sid sind den Buben egal.

[Bequimão]

Hi,

ich habe hier ein Epidemic GNU/Linux, ein brasilianisches Mini-Debian, das auf testing basiert.
http://www.epidemiclinux.org/
Epidemic hat ein graphisches Update-Tool namens eUpgrade. Die aktuelle Version 3.2. ist kurz nach dem Ende des Freeze von squeeze herausgekommen. In dieser Zeit sind zwei Versionssprünge von KDE und mehrfach xserver.xorg hereingekommen. Alles wäre gutgegangen, wenn nicht der Maintainer von libpam0g hart kdm gestoppt und neu gestartet hätte. Dadurch sind dann die Systemaktualierungen reihenweise gecrasht und haben genau das beschriebene Chaos hinterlassen.

Im aktuellen Stand ist libpam0g gefixt, so daß eine direkte Aktualisierung von Null möglich wäre. Nur hat James Benedito, der Chefentwickler, gerade die Anwendung im Repo gesperrt. Das ganze funktioniert deswegen, schätze ich, weil die Programme im Speicher sind und eben nicht von der Platte geladen werden. Es geht ja auch eine Aktualisierung von apt-get selbst. Nach den gängingen Erklärungen müßte ein Upgrade von apt-get selbst in der Textkonsole crashen.

Die Distro läßt sich auf Englisch installieren, und ich bin dabei das ganze ins Deutsche zu übersetzen.
Linux-Forum.de: Epidemic GNU/Linux - Ein ansteckendes Erlebnis

Viele Grüße
Bequimão

[agaida]

Es ist auch gar nichts gegen den Sinn oder Unsinn eines grafischen Wrappers zu sagen, die Erfahrung lehrt aber, dass komplexe Systeme komplexere Fehler erzeugen.

Aus dieser Sicht von DonKult über die "Primitivität" von apt-get muss ich sagen: Der Mann hat recht. Definierte "Blödheit" ist mir an dieser Stelle lieber, das reduzieren der Nutzungsumgebung auf den einfachsten Fall ist auch keine schlechte Idee.

Ich kann mich nicht daran erinnern, jemals X verlassen zu haben, um irgendwas upzudaten, zumindest nicht freiwillig. Selbst meinen geliebten Catalyst ziehe ich im laufenden Betrieb hoch. Dass ich dann doch noch ein wenig "Windows-Jünger" geblieben bin, zeigt sich in einem darauffolgenden sauberen Neustart. Diese Minute nach gravierenden Änderungen sollte schon drin sein.

Eventuelle Reparaturen macht man dann halt wieder in der Konsole oder im Rettungssystem. Man will ja nicht aus der Übung kommen. Vielleicht nicht ganz so provokativ, aber eventuell wahr: Je einfacher und "benutzerfreundlicher" ein Update um die Ecke kommt, desto höher ist die Chance, dass $user den nicht mehr ernst nimmt. Mit teilweise fatalen Folgen.

[reddark]

Also ich hab es mir so eingerichtet:
Auf meiner zweiten Arbeitsfläche startet immer automatisch die konsole .. sie ist so eingerichtet, das sie immer an der selben stelle und die selbe größe hat und für die Optik ist die Umrandung weg (eigendlich das selbe was plasmcron macht, nur gabs da hin&wieder zuviel probleme mit den scriptengines).

so sieht das dann aus (zum vergößern: rechtsklick, grafik anzeigen):



So .. dort mach ich Täglich, stündlich .. wie Lust und laune die update-kontrolle.

Um es einfacher zu machen, arbeite ich mit "aliase" .. also

update = apt-get update && apt-show-versions -u
upgrade = apt-get dist-upgrade -d

Wie mensch sieht, ziehe ich die Packete nur runter, ohne installation.

Und dann hab ich die möglichkeit wann immer ich will das DU durchzuziehen. Da ich meinen rechner aber auch nicht ständig neu starte, passiert das vielleicht alle 3-4 Tage und da mach ich dann ohne X schnell und unkompliziert mein DU auch wieder mittels alias:

disu = apt-get dist-upgrade

Und warum erzähle ich euch das alles?
Weil ich finde das ist genauso einfach und/oder so schnell wie ein evtuelles Upgradetool das die updates mit nachfrage beim runterfahren installieren soll. Nur das ich weiterhin jede kontrolle bei mir hab .....

Nur mal ein Gedanke so in die Runde geworfen ...

[horo]

reddark +1, so ähnlich mach ich's auch, bei mir ist es das Script /usr/local/sbin/agudu (von  apt-get update dist-upgrade):

Code Select Expand


apt-get update
apt-get -d -y dist-upgrade
for HOLD in $(dpkg --get-selections | grep hold | cut -f1); do apt-cache policy $HOLD; done

und zeigt gleich noch (eventuelle) holds an.

Das eigentliche dist-upgrade passiert dann auf der <ALT><CTRL><F1>-Konsole, wenn nur "pipifax" aktualisiert wird bei laufendem X - wenn xserver oder ähnliche Pakete dabei sind, wird per "init 3" X runter und hinterher per "init 5" wieder hochgefahren (ja mein slim bzw. gdm ist nur im Runlevel 5 aktiv).

Ciao, Martin