News Fedora Upgrade: FedUp und Systemd verursachen schweren Fehler

[Zedar]

Ich fände das schon interessant. Als ich noch Ubuntu nutzte bin ich auch in den ersten Tagen zur Beta gewechselt, manchmal schon noch zu Alpha-Zeiten. Mit einem chroot ist grub schnell neu installiert (auch die Pakete sauber eingespielt), trotzdem ist das ärgerlich und IMHO eine Nachricht wert.

Außerdem denke ich, das fethom schon als Linux Redakteur den Anspruch hat auch Nachrichten zu bringen die etwas tiefer gehen und andere Distributionen als Linux Mint behandeln. Das ist ja auch interessant weil evtl. auch andere Distributionen betroffen sein könnten die auf die dieselben daemons setzen. Da ist es evtl. einfacher nur das betroffene Programm nicht zu aktualisieren als die Probleme mit einem chroot zu lösen.

 

[blackiwid]

Naja es ist vielleicht deshalb interessant weil Fedora quasi die Leitdistro ist, 99% (uebertreib ein wenig) der Linux-Entwickler werden von Redhat bezahlt alles wird zuerst in fedora getestet dann kopieren sichs die anderen distros

Von daher ist obwohl Fedora wohl nicht sooo viele Nutzer hat es mit die spannenste Distro

Und immerhin wird nicht wie bei Phoronix, alle 2 Tage eine News generiert wo es als negativ dar gestellt wird das sich die Distri verspaetet, auch wenn Redhat keine Timebased Releases macht sondern feature-based, von daher ist hier eine verspaetung der irgendwann mal geplanten Releases auch nicht so dramatisch.

Klar man koennte auch incht mal ein geplantes Datum veroeffentlichen, wie vielleicht bei Debian, aber im Grunde haben sie auch die Politik its done when its done.

Ja und ueber Archlinux kann man ja auch wenig berichten, da es keine Releases gibt und auch nicht viel spannendes passiert, es wird halt immer sobald eine Software als stabile version veroeffentlicht wird 2 Sekunden spaeter ein Paket bereit gestellt, von Betas in der Regel dafuer konsequent nicht. Was will man da fuer News drueber schreiben

 

[allli84]

Also wer eine alpha-Version von Linux einsetzt, sollte wohl durchaus in der Lage sein, GRUB neu zu installieren, bzw. Xorg neu aufzusetzen. Ist ja nicht für den Endverbraucher gedacht, da muss man sich auch auf sowas einstellen und ein bisschen basteln bei Bedarf.

 

[Sennox]

..
Arch ist aktueller und (viel) stabiler. So ein Unfug wie das hier würde bei Arch nie passieren. ^^

Nich?
Ich erinner mich wie mir vor ein oder zwei Jahren eine Arch Installation starb obwohl ich ganz routiniert den eigenen Updater genutzt habe.

Was passiert ist?
Arch hatte irgendwas am Aufruf der LVM geändert respektive an der LVM selber.
Diese Änderung wurde aber nicht im Boot eingepflegt, so war das LVM offiziell "nicht konsistent" obwohl im Endeffekt nur eine Konfigurationszeile angepasst werden musste weil ein neuerer/anderer Aufruf nötig war.

Ja unschön, ja sowas passiert und nein, davon kann sich keine Distri wirklich freisprechen.

Sowas sollte einfach nicht passieren wenn man Standardupdates über den hauseigenen Standardweg einspielt.

Oh und +1 für Octavia

 

[Tuxman]

Toll, dieses systemd!

n.b.: Arch Linux überlebte bei mir in einer VM genau zwei Monate lang, erst dieses Jahr, trotz minimaler Eingriffe meinerseits. Wenn Frickler ihre Frickelei als weniger fricklig bezeichnen...

 

[fuyuhasugu]

Ich glaube, du hast die Problematik nicht ganz verstanden

Ich würde eher sagen, Du hast den Inhalt meines Posts überhaupt nicht verstanden. Der bezog sich nämlich ganz allgmein auf Erhöhung der Komplexität durch Zusammenfassung vieler Funktionen in nur einem Programm. und in diesem fall betraf es halt systemd.

ja ich weiß, du willst nur trollen und SystemD bashen

Und dann meinst Du auch noch zu "wissen" (sic!), was meine Intention ist.

 

[anonymous_user]

Ich würde eher sagen, Du hast den Inhalt meines Posts überhaupt nicht verstanden. Der bezog sich nämlich ganz allgmein auf Erhöhung der Komplexität durch Zusammenfassung vieler Funktionen in nur einem Programm. und in diesem fall betraf es halt systemd.

Was schon wieder Falsch ist. Wenn man schon Sinnlos auf systemd schimpft sollte man es wenigstens kennen. systemd ist erstens mal nicht "ein Programm", sondern ein Paket aus einem Modular aufgebauten Init System, was aus vielen verschiedenen Daemons und Utilities besteht. Konkret systemd ist nur ein teil davon.

Die aussage, zu trollen war daher schon korrekt. Das ist die immer und immer wieder gleich Falsche aussage von Diversen leuten sobald man irgendwo systemd liest. Das man anfängt "init" systeme zu haten kann ich beim besten willen nicht nachvollziehen. Und wie man eine Emotionale Beziehung dazu aufbauen kann. (Abgesehen von den Entwickler die selbst dran arbeiten)

Übrigens liegt der fehler hier weder speziell bei FedUp noch bei systemd. Es treffen halt 2 Pakete aufeinander, die mit gewollten (Sinnvollen) Funktionen ein System unbootbar machen können. Davon ab ist Fedora momentan Alpha(?), genau für solche fälle ist sowas, um genau solche Fehler festzustellen

 

[Tuxman]

Wäre systemd "nur" ein Initsystem und kein Megalith, der sich durch sämtliche OSI-Schichten frisst und dort im Weg rumliegt, würde es niemanden stören.

 

[anonymous_user]

Ja, und zufälligerweise störts nur die Leute die systemd nie benutzt haben, und die angeblichen "nachteile" nur aus den Mythenhaften "Fuck systemd" Artikeln kennen

Wenn man dann mal doch in der Realtität angekommen ist, sieht man wie u.a. mein Jolla Smartphone erstaunlicherweise mit dem "OSI Fressendem Megalith" systemd zurechtkommt, das vermutlich schnellst Bootende Smartphone ist, und sehr Flüssiges Arbeitstempo vorweist. Mit 1Gb Ram und Cortex-A9 Dualcore Prozessor.

Aber gut, wenn die Weltanschauung von manchen hier ist das die ganzen Distris die sich für systemd entschieden haben von nichts ne ahnung haben, und ihr die absoluten Leuchten seid, die angebliche systemd unzulänglichkeiten nur mit Artikeln die nur aus "fuck systemd shit!!11!" bestehen belegen, kann ich gut damit Leben. Ein leichtes schmunzeln kann ich mir dabei aber nicht verkneifen Über die sich selbst betitelten "Veteranen der UNIX-Administration"

 

[Tuxman]

Genau: Wer ein Problem damit hat, dass ein immer größer werdende Softwareklotz als SPoF einen Großteil der essenziellen Systemkomponenten zu ersetzen im Begriff ist und dabei als Kollateralschaden mal eben die Verwaltung von /tmp und den wichtigsten Systemlogs verunmöglicht, der hat einfach nur keine Ahnung. Sooo 80er!!1

 

[Zehkul]

Was passiert ist?
Arch hatte irgendwas am Aufruf der LVM geändert respektive an der LVM selber.
Diese Änderung wurde aber nicht im Boot eingepflegt, so war das LVM offiziell "nicht konsistent" obwohl im Endeffekt nur eine Konfigurationszeile angepasst werden musste weil ein neuerer/anderer Aufruf nötig war.

Das stand aber doch ziemlich sicher auf archlinux.org, oder? Manuell herumpfuschen zu müssen, ist bei Arch eben die Regel, nicht die Ausnahme, deshalb ist es natürlich auch etwas unfair, die Stabilität zu vergleichen bei einer Distribution, die geplant „kaputtgeht“ und man eh von Hand ranmuss.

 

[confuso]

Ich würde eher sagen, Du hast den Inhalt meines Posts überhaupt nicht verstanden. Der bezog sich nämlich ganz allgmein auf Erhöhung der Komplexität durch Zusammenfassung vieler Funktionen in nur einem Programm. und in diesem fall betraf es halt systemd.

Ja, sag ich doch, sinnloses systemd bashing. anonymous_user hat sich ja schon detalliert geäußert, das spare ich mir dann mal.

Genau: Wer ein Problem damit hat, dass ein immer größer werdende Softwareklotz als SPoF einen Großteil der essenziellen Systemkomponenten zu ersetzen im Begriff ist und dabei als Kollateralschaden mal eben die Verwaltung von /tmp und den wichtigsten Systemlogs verunmöglicht, der hat einfach nur keine Ahnung. Sooo 80er!!1

Man kann es auch so sehen: Wenn systemd wirklich ein so großes Problem darstellt, werden sich problemlos genügend kompetente Entwickler finden lassen, die eine Alternative dazu entwickeln (eine bessere, als uselessd oder wie der Fork hieß). Ich kann nur sagen: Als Anwender empfinde ich Systemd als sehr komfortabel, aber wenn es was anderes, besseres gibt, benutze ich halt das.

 

[Tuxman]

Was stört dich an uselessd?

 

[confuso]

Naja gut, zugegebener Maßen benutze ich es nicht und habe auch nicht den tiefen Einblick in das System und habe deswegen vielleicht den Satz schlecht gewählt. Wirkte für mich immer als trotzige Notlösung, indem nur die Abhängigkeiten entfernt wurden. Wenn die Kritik an Systemd schon so umfassend ist, scheint das für mich eine sehr halbherzige Lösung zu sein. Es ist ja "nur" ein Fork und keine eigenständige Entwicklung, d.h. das meiste ist am Ende doch Systemd

 

[Wander]

Was stört dich an uselessd?

Keine Ahnung was confuso daran stoert, aber ich persoenlich habe dadurch keinen Vorteil eher im Gegenteil, ich mag das journal, ich mag logind und viele andere Bestandteile von systemd. Und gluecklicherweise sehen das zumindest bisher auch alle fuer mich relevanten Distributoren und Entwickler so.

Abgesehen davon ist uselessd bestimmt fuer viele andere Menschen interessant und ich freue mich fuer jeden der damit gluecklich ist/wird.

 

[RangnaR]

Mit dem nachäffen von Windows Eigenheiten in die Krise gefahren. Ich fasse es nicht.

Windows ist kaputt und unfähig genug, damit die meistens Updates von Treibern, Browsern oder Gerümpel einen Neustart benötigen, weil der Uralt-Kernel von Windows dann erst mit bekommt, dass sich etwas geändert hat.

Solange ich bei Linux keinen neuen Kernel installiere, brauche ich in der Regel keinen Neustart. Und das Linux-Kernel Design ist auch schon uralt und von vor-vor-gestern. Also weshalb baut Fedora für Linux nun die absonderlich rückständige Eigenschaft nach, dass Updates nach einem Neustart eingespielt werden? Was soll diese Vorgehensweise? Wieso Neu Startet, wenn man es nicht braucht? Und weshalb erst Sicherheitsupdates nutzen, obwohl die schon tagelang auf der Festplatte liegen, wenn man zu einem Neustart kommt? Das ist in meinen Augen ziemlich pervers.

Dass dann zudem noch in den Boot-Prozess massiv eingegriffen wird, läßt mich nochmals fassungslos zurück. Auch unter Linux verlieren Festplatten Daten. Und wenn es ein Paket ist, das tief in den Abhängigkeiten-Ast liegt, dann funktioniert eben das Update zum Beispiel der GUI zur Boot-Zeit nicht. Interaktion mit dem Admin: Fehlanzeige. Ansonsten leicht zu beheben.

Fehlt nur noch, das Linux das hirnrissige Windows System übernimmt, und Datei-Arten nach den letzten 3 Zeichen des Dateinamens bestimmt. Das irrste, dümmste und das System mit der größten Einfalt, das ich mir vorstellen kann.

 

[Tuxman]

Windows ist kaputt und unfähig genug, damit die meistens Updates von Treibern, Browsern oder Gerümpel einen Neustart benötigen, weil der Uralt-Kernel von Windows dann erst mit bekommt, dass sich etwas geändert hat.

Treiber: Ja, weil es Kernelmodule sind. Unter Linsux wirst du da auch große Probleme haben, einen quasi "neu kompilierten" Kernel ohne Neustart zu benutzen. Uralt!!1!

Browser: Quark.

Gerümpel: Wat?

 

[fuyuhasugu]

Ja, sag ich doch, sinnloses systemd bashing. anonymous_user hat sich ja schon detalliert geäußert

anonymous_user? Ich sehe keine Kommentare eines Nutzers mit diesem Namen. Und nur weil Du jemand eine andere Meinung als Du hat , ist das noch lange kein Bashing. Das ist ein Gedanke, dem nur des Denkens unfähige Trolle verfallen.

Man kann es auch so sehen: Wenn systemd wirklich ein so großes Problem darstellt, werden sich problemlos genügend kompetente Entwickler finden

Wie bei so vielen anderen Projekten auch, die immer mal wieder bei Null anfangen. Weil Ressourcen, dazu zählen auch Entwickler, auch so unbegrenzt vorhanden sind. Und weil Entwickler wie in diesem Fall mal wieder besser zu wissen meinen, was für die Administrationsarbeit gut ist und was niciht. Demnächst kommen die Admins und mäkeln am C-Code rum. Das wird ein Heidenspaß.

 

[confuso]

anonymous_user? Ich sehe keine Kommentare eines Nutzers mit diesem Namen.

Ehm ja, spiegelt anscheinend dein Leseverständnis wider, wenn du ihn nicht findest. Denn:

Und nur weil Du jemand eine andere Meinung als Du hat , ist das noch lange kein Bashing. Das ist ein Gedanke, dem nur des Denkens unfähige Trolle verfallen.

... mein Kommentar beruhte ja darauf, dass ich der Meinung bin, dass du nicht verstanden hast, wo die in der News geschilderte Problematik liegt und dass das kein Fehler von systemd ist.

Wie bei so vielen anderen Projekten auch, die immer mal wieder bei Null anfangen. Weil Ressourcen, dazu zählen auch Entwickler, auch so unbegrenzt vorhanden sind. Und weil Entwickler wie in diesem Fall mal wieder besser zu wissen meinen, was für die Administrationsarbeit gut ist und was niciht. Demnächst kommen die Admins und mäkeln am C-Code rum. Das wird ein Heidenspaß.

Wenn es wirklich so elementar ist und systemd so schlecht, wird man die Ressourcen dafür freischaufeln müssen. Denn die bisherigen init-Systeme sind allesamt (upstart mal ausgenommen) hochgradig veraltet.

 

[MountWalker]

... Also weshalb baut Fedora für Linux nun die absonderlich rückständige Eigenschaft nach, dass Updates nach einem Neustart eingespielt werden? ...

Macht es nicht, hier geht es um das Auswechseln der Distribution (19 oder 20 gegen 21) mittels FedUp, nicht um bloße Paketaktualisierungen - und dabei wird selbstverständlich auch der Kernel geändert, weil ja eben der Kernel eine Teilmenge von "alles" ist. Auch mit Fedora 21 ändert sich nichts daran, dass ich nach yum update nur die Software neustarten muss, die Bestandteile enthält, die bei yum update aktualisiert wurden. Wenn man das mal macht ist es imho aber bei keiner Distro verkehrt, irgendwann mal neuzustarten, weil bei 300 Paketaktualisierungen auch gerne mal Bestandteile von Software aktualisiert wurden, die einem nicht als Bestandteile von Software XY bewusst sind. Das ist vermutlich auch der Grund, warum das Gnome-Tool "Software" (im Gegensatz zu yum) oft zu einem Neustart auffordert.

P.S.
Urpm in alten Mandrakelinux (und vermutlich dessen Nachfolgern) war immer schlau genug, sobald Abhängigkeiten oder Abhängigkeitsabhängigkeiten von der verwendeten Desktop-Umgebung aktualisiert wurden, zu einem Neustart eben jener durch Ausloggen und Wiedereinloggen aufzufordern.