Der Fehler klingt für mich recht abenteuerlich. Ich weiß, das DNF relativ neu ist, aber im Jahr 2016 würde ich so gravierende Fehler von einer Paketverwaltung nicht mehr erwarten - offenbar ist man als Fedora-User tatsächlich prinzipiell Beta-Tester.
Red Hat hätte statt einer Neuentwicklung eines RPM-zentrierten Paketmanagers natürlich auch auf Zypper/libzypp setzen können - ich hatte damit unter openSUSE bisher Null Probleme (nutze es seit 13.1). In Kombination mit BTRFS für / und dem Snapper-Tool kann man damit übrigens auch in alte Installationsstände booten, falls mal etwas schief geht - Snapper legt bei jeder Paketinstallation einen Snapshot an und meldet diesen an Grub. Habe das nur mal interessehalber ausprobiert, funktioniert aber (wie der Rollback einer Installation) gut.
Der Fehler klingt für mich recht abenteuerlich. Ich weiß, das DNF relativ neu ist, aber im Jahr 2016 würde ich so gravierende Fehler von einer Paketverwaltung nicht mehr erwarten [...]
Soweit ich mich bisher belesen habe, scheint das Problem überhaupt nicht bei dnf oder RPM zu liegen. Wie ja bekannt ist, wird ein laufendes dnf sofort terminiert, wenn z.B. das verwendete Terminal oder X (resp. Wayland) crashed.
Bei Verwendung von X ist der Stack natürlich viel größer, damit auch die Wahrscheinlichkeit von Bugs (bzw. da die Hardware mehr gefordert wird, auch die Wahrscheinlichkeit, dass sich defekte Hardware auswirkt). Eine Textkonsole braucht (fast) nur den Kernel.
Es gibt ja auch mehrere Kommentare, die besagen, dass ein DNF-Update fast nie ein Problem ist - außer, wenn es eben vorkommt. Und wenn der Paketmanager mitten in seiner Arbeit gekillt wird, ist das fast immer ein Problem (mit etwas Glück betrifft es eben keine essentiellen Pakete).
(Ich mache ja auch seit Fedora Core 2 meine Updates immer in der graphischen Oberfläche und hatte auch noch nie Probleme.)
Vermutlich wäre ein Ansatz zur Lösung (wenn man keine Reboot-Updates haben will), dass die DNF-Transaktion abgekoppelt in einem Hintergrundprozess durchgeführt wird, der von einem eventuellen Absturz der Anzeige nicht betroffen ist ("Client/Server").
In Kombination mit BTRFS für / und dem Snapper-Tool kann man damit übrigens auch in alte Installationsstände booten, falls mal etwas schief geht - Snapper legt bei jeder Paketinstallation einen Snapshot an und meldet diesen an Grub.
Mir ist nicht ganz klar, wie Snapshots (außerhalb von einfachen Fällen) helfen sollen.
Szenario: - Der Update-Vorgang wird in der Mitte hart unterbrochen. - Als Anwender arbeite ich während des Updates weiter, es werden also weiterhin Daten (z.B. in Datenbanken geschrieben).
Entweder wird ein Rollback also mit einem Verlust and Nutzerdaten einhergehen oder der Snapshot umfasst nicht die ganze Platte (womit dann ein Rollback u.U. auch nicht hilft).
Damit Snapshots in der Mehrzahl der Fälle helfen können, muss sich wirklich alle Software an viele (implizite) Vorgaben halten (wo werden z.B. Programmdaten abgelegt, wann werden Datenformat-Upgrades gemacht), man braucht eine geeignete Partitionierung usw. Da bin ich ein bisschen skeptisch, ob diese Einschränkungen den ganzen Aufwand wert sind.
Szenario: - Der Update-Vorgang wird in der Mitte hart unterbrochen. - Als Anwender arbeite ich während des Updates weiter, es werden also weiterhin Daten (z.B. in Datenbanken geschrieben).
Es wäre möglich, diesen Fall abzudecken. Konkret hängt dies natürlich auch davon ab, wo die verwendeten Programme ihre Daten speichern - so wie du geschrieben hast.
Zur Erläuterung: Die empfohlene Installationsvoreinstellung ist diese: - / wird als separate Partion mit BTRFS, Subvolumes und Snapshots erstellt - /home wird als separate Partition mit XFS (keine Snapshots) erstellt
Snapshots werden mittels Snapper automatisiert VOR Beginn eines Updateprozesses und NACH dessen Beenden erstellt.
Somit wäre in Deinem Szenario alles sauber, sofern die Datenbanken unter /home liegen - das wird durch das Rollback nicht beeinträchtigt. Dagegen ist es möglich, in den Snapshot VOR dem missglückten Upgrade zu booten, das System ist also zu 100% lauffähig, nur eben auf dem alten Stand.
Der Fehler hat mit DNF recht wenig zu tun, wenn dir die GUI und damit dein Terminal wegbricht dann eben auch DNF das da drinnen läuft - Das ist jetzt nichts wahnsinnig neues
Deswegen ist man halt auch einigermassen dämlich wenn man das Systemupdate nicht in einer screen Session fährt der es wurscht ist ob es dir den Desktop in den Abgrund reisst _____________________________
Anyways, der Verfasser des Artikels sollte sich besser informieren und nicht nur Überschriften lesen dann hätte er im Laufe der Diskussion auch gemerkt was genau los ist und dass systemd-229-16 https://bugzilla.redhat.com/show_bug.cgi?id=1378974 fixen sollte
Gemäss deutschsprachigem Wikiepedia steht «DNF» für: · den mathematischen Begriff Disjunktive Normalform · den Sportbegriff Did not finish („nicht ins Ziel gekommen“) · das Computerspiel Duke Nukem Forever · Did Not Find, ein Logtype beim Geocaching · Do not fly, Zeit nach einem Tauchgang während der der Taucher nicht höher als 400 m über den Tauchplatz aufsteigen sollte. · Deutschnationale Front, siehe Deutschnationale Volkspartei · Deutsch-Norwegische Freundschaftsgesellschaft e.V., siehe Deutsch- Norwegische Freundschaftsgesellschaft · Dynamic without fins, eine Disziplin des Apnoetauchens · das Paketmanagement-System DNF (Dandified Yum)
Wie wäre es, jeweils bei der ersten Erwähnung die Kurzdefinition mitzugeben?
Wie wäre es einfach mal selber nachzudenken und zu schauen anstatt alles vorgekaut zu bekommen?
Dass die Zielgruppe des Artikels Fedora-User sind ist ganz oben klar ersichtlich, selbige sollten wohl wissen was DNF ist und wenn nicht wirds Zeit sich mal etwas mit dem OS das man benutzt auseinander zu setzen
Natürlich darfst du ihn lesen aber du darfst nicht erwarten dass jeder Artikel mit den Basics worum es geht beginnt - Warum? Weil es witzlos ist jeden Artikel mit 20 Seiten Erklärungen zu starten "Was ist ein Computer? Was ist Linux...." Ist dein Fucking Google defekt oder was?
Blödsinnige Trollerwei - Ja, Redhat folgt nicht immer nur, Redhat führt die Entwicklung in vielen Bereichen an, seit vielen Jahren und die anderen folgen
Du nicht? Schön für dich! Interessiert nur keine Sau
Bei dem Vorgang werden die zu aktualisierenden Pakete im Hintergrund heruntergeladen, das eigentliche Update findet nach einem Neustart vor dem Hochfahren des Systems statt.
Oh nein, wie bei Windows! Wie ich es hasse, wenn mir der Rechner vorschreibt, ob ihn grade benutzen darf.
Du musst explizit "Updates herunterladen und Rechner neustarten" anklicken. Ich installiere ansonsten Updates immer über dnf update, noch nie Probleme gehabt - NOCH NIE! Und ich verwende DNF seit es in Fedora integriert ist (okay, so lange ist das noch nicht :)) auf der Arbeit, also einer Workstation mit der min. 8 Stunden am Tag gearbeitet wird.
Meine beiden Kollegen - ebenfalls Fedora - haben dieses Problem auch nicht (dafür andere, aber nicht mit DNF).
"Wie ich es hasse, wenn mir der Rechner vorschreibt, ob ihn grade benutzen darf" - Ernsthaft? Du bist ein Trottel Würde er dir das vorschreiben gäbe es das Problem um das es geht das nur sehr wenige betrifft nicht!
Was ist mit euch ganzen Schissern die ihr Fedora offenbar nicht benutzt aber den Mund aufreissen müsst über Dinge die hir nicht kennt?
Der Fehler klingt für mich recht abenteuerlich. Ich weiß, das DNF relativ neu ist, aber im Jahr 2016 würde ich so gravierende Fehler von einer Paketverwaltung nicht mehr erwarten - offenbar ist man als Fedora-User tatsächlich prinzipiell Beta-Tester.
Red Hat hätte statt einer Neuentwicklung eines RPM-zentrierten Paketmanagers natürlich auch auf Zypper/libzypp setzen können - ich hatte damit unter openSUSE bisher Null Probleme (nutze es seit 13.1). In Kombination mit BTRFS für / und dem Snapper-Tool kann man damit übrigens auch in alte Installationsstände booten, falls mal etwas schief geht - Snapper legt bei jeder Paketinstallation einen Snapshot an und meldet diesen an Grub. Habe das nur mal interessehalber ausprobiert, funktioniert aber (wie der Rollback einer Installation) gut.
Soweit ich mich bisher belesen habe, scheint das Problem überhaupt nicht bei dnf oder RPM zu liegen. Wie ja bekannt ist, wird ein laufendes dnf sofort terminiert, wenn z.B. das verwendete Terminal oder X (resp. Wayland) crashed.
Bei Verwendung von X ist der Stack natürlich viel größer, damit auch die Wahrscheinlichkeit von Bugs (bzw. da die Hardware mehr gefordert wird, auch die Wahrscheinlichkeit, dass sich defekte Hardware auswirkt). Eine Textkonsole braucht (fast) nur den Kernel.
Es gibt ja auch mehrere Kommentare, die besagen, dass ein DNF-Update fast nie ein Problem ist - außer, wenn es eben vorkommt. Und wenn der Paketmanager mitten in seiner Arbeit gekillt wird, ist das fast immer ein Problem (mit etwas Glück betrifft es eben keine essentiellen Pakete).
(Ich mache ja auch seit Fedora Core 2 meine Updates immer in der graphischen Oberfläche und hatte auch noch nie Probleme.)
Vermutlich wäre ein Ansatz zur Lösung (wenn man keine Reboot-Updates haben will), dass die DNF-Transaktion abgekoppelt in einem Hintergrundprozess durchgeführt wird, der von einem eventuellen Absturz der Anzeige nicht betroffen ist ("Client/Server").
Mir ist nicht ganz klar, wie Snapshots (außerhalb von einfachen Fällen) helfen sollen.
Szenario:
- Der Update-Vorgang wird in der Mitte hart unterbrochen.
- Als Anwender arbeite ich während des Updates weiter, es werden also weiterhin Daten (z.B. in Datenbanken geschrieben).
Entweder wird ein Rollback also mit einem Verlust and Nutzerdaten einhergehen oder der Snapshot umfasst nicht die ganze Platte (womit dann ein Rollback u.U. auch nicht hilft).
Damit Snapshots in der Mehrzahl der Fälle helfen können, muss sich wirklich alle Software an viele (implizite) Vorgaben halten (wo werden z.B. Programmdaten abgelegt, wann werden Datenformat-Upgrades gemacht), man braucht eine geeignete Partitionierung usw. Da bin ich ein bisschen skeptisch, ob diese Einschränkungen den ganzen Aufwand wert sind.
Zur Erläuterung: Die empfohlene Installationsvoreinstellung ist diese:
- / wird als separate Partion mit BTRFS, Subvolumes und Snapshots erstellt
- /home wird als separate Partition mit XFS (keine Snapshots) erstellt
Snapshots werden mittels Snapper automatisiert VOR Beginn eines Updateprozesses und NACH dessen Beenden erstellt.
Somit wäre in Deinem Szenario alles sauber, sofern die Datenbanken unter /home liegen - das wird durch das Rollback nicht beeinträchtigt.
Dagegen ist es möglich, in den Snapshot VOR dem missglückten Upgrade zu booten, das System ist also zu 100% lauffähig, nur eben auf dem alten Stand.
Der Fehler hat mit DNF recht wenig zu tun, wenn dir die GUI und damit dein Terminal wegbricht dann eben auch DNF das da drinnen läuft - Das ist jetzt nichts wahnsinnig neues
Deswegen ist man halt auch einigermassen dämlich wenn man das Systemupdate nicht in einer screen Session fährt der es wurscht ist ob es dir den Desktop in den Abgrund reisst
_____________________________
Anyways, der Verfasser des Artikels sollte sich besser informieren und nicht nur Überschriften lesen dann hätte er im Laufe der Diskussion auch gemerkt was genau los ist und dass systemd-229-16 https://bugzilla.redhat.com/show_bug.cgi?id=1378974 fixen sollte
dazuzuschreiben um was es sich bei DNF handelt. In diesem Fall handelt es sich wohl um einen Paketmanager.
:up:
Genau das wollte ich auch schreiben.
Loebliche Recherche und Berichterstattung. Aber kein Wort davon was DNF ueberhaupt ist.
Fuer mich ist DNF noch immer "Duke Nukem Forever"
Echt jetzt? Für wen ergibt sich aus dem Kontext nicht was DNF ist? Und warum ist jemand die Zielgruppe des Artikels der Fedora nicht kennt?
Gemäss deutschsprachigem Wikiepedia steht «DNF» für:
· den mathematischen Begriff Disjunktive Normalform
· den Sportbegriff Did not finish („nicht ins Ziel gekommen“)
· das Computerspiel Duke Nukem Forever
· Did Not Find, ein Logtype beim Geocaching
· Do not fly, Zeit nach einem Tauchgang während der der Taucher nicht
höher als 400 m über den Tauchplatz aufsteigen sollte.
· Deutschnationale Front, siehe Deutschnationale Volkspartei
· Deutsch-Norwegische Freundschaftsgesellschaft e.V., siehe Deutsch-
Norwegische Freundschaftsgesellschaft
· Dynamic without fins, eine Disziplin des Apnoetauchens
· das Paketmanagement-System DNF (Dandified Yum)
Wie wäre es, jeweils bei der ersten Erwähnung die Kurzdefinition mitzugeben?
Wie wäre es einfach mal selber nachzudenken und zu schauen anstatt alles vorgekaut zu bekommen?
Dass die Zielgruppe des Artikels Fedora-User sind ist ganz oben klar ersichtlich, selbige sollten wohl wissen was DNF ist und wenn nicht wirds Zeit sich mal etwas mit dem OS das man benutzt auseinander zu setzen
es ist unsauberer Stil und so schreckt man Interessierte ab
@ Verflucht:
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 06. Okt 2016 um 17:03.Ziemlich einseitig, Deine Ansichstsweise. Oder, da ich kein Fedora-user bin, darf und sollte mich der Beitrag nicht lesen?
Natürlich darfst du ihn lesen aber du darfst nicht erwarten dass jeder Artikel mit den Basics worum es geht beginnt - Warum? Weil es witzlos ist jeden Artikel mit 20 Seiten Erklärungen zu starten "Was ist ein Computer? Was ist Linux...." Ist dein Fucking Google defekt oder was?
Hmmm, ich dachte bisher, DNF stehe für "Do Not Fuck".
Do not follow (DNF).
Da impliziert somit auch Fedora, systemd und udev, also letztlich auch RH.
Blödsinnige Trollerwei - Ja, Redhat folgt nicht immer nur, Redhat führt die Entwicklung in vielen Bereichen an, seit vielen Jahren und die anderen folgen
Du nicht?
Schön für dich!
Interessiert nur keine Sau
Oh nein, wie bei Windows! Wie ich es hasse, wenn mir der Rechner vorschreibt, ob ihn grade benutzen darf.
Es ist nur EINE Möglichkeit, die Fedora bietet. Informiere Dich lieber, bevor Du loswimmerst.
Du musst explizit "Updates herunterladen und Rechner neustarten" anklicken. Ich installiere ansonsten Updates immer über dnf update, noch nie Probleme gehabt - NOCH NIE! Und ich verwende DNF seit es in Fedora integriert ist (okay, so lange ist das noch nicht :)) auf der Arbeit, also einer Workstation mit der min. 8 Stunden am Tag gearbeitet wird.
Meine beiden Kollegen - ebenfalls Fedora - haben dieses Problem auch nicht (dafür andere, aber nicht mit DNF).
"Wie ich es hasse, wenn mir der Rechner vorschreibt, ob ihn grade benutzen darf" - Ernsthaft? Du bist ein Trottel Würde er dir das vorschreiben gäbe es das Problem um das es geht das nur sehr wenige betrifft nicht!
Was ist mit euch ganzen Schissern die ihr Fedora offenbar nicht benutzt aber den Mund aufreissen müsst über Dinge die hir nicht kennt?