Kommendes Update auf FreeBSD 13

Status
Für weitere Antworten geschlossen.
Ah, jetzt. ja. Also ist ein Boot Environment = / ?
Immer wieder faszinierend, was alles mit ZFS geht. Auf die Möglichkeit von clonen und mounten von / wäre ich im Leben nicht gekommen.
 
Ganz einfach: Das sind Boot Environments. ZFS oder besser gesagt das bectl Tool (ist baugleich zu beadm, aber seit einiger Zeit im Basisystem enthalten) klont das Dataset, auf dem / liegt. Anschließend wird das neue Dataset gemountet und das darin liegende System aktualisiert. Danach wird es aktiviert und man rebootet ins neue System.
Ich hoffe immer noch, dass das mal jemand in freebsd-update einbaut. HardenedBSD hat das seit Jahren drin: hbsd-update -b <MeinNeuesBE> macht all diese Schritte automatisch. Nach einem Neustart ist man automatisch im neuen Boot Environment <MeinNeuesBE>.
 
Ich hoffe immer noch, dass das mal jemand in freebsd-update einbaut. HardenedBSD hat das seit Jahren drin: hbsd-update -b <MeinNeuesBE> macht all diese Schritte automatisch. Nach einem Neustart ist man automatisch im neuen Boot Environment <MeinNeuesBE>.
Wie halt bei Solaris? :-)

Das Problem mit dem zpool upgrade hat man aber auch unter Solaris. Da ist ein Kollege mal böse auf die Nase gefallen. Solaris auf ein neues SRU gehoben, vorschnell den Pool hochgehoben und natürlich in einen Bug gerannt... War zum Glück nur ne Testkiste :-)
 
Schade, das FreeBSD 13-Release verschiebt sich um mindestens eine Woche (Build: 02.04., Announcement: 06.04.) [1]. Statt dessen gibt es jetzt noch einen RC4 [2]. Wobei Glen Barber offenbar etwas wichtiges dazwischen gekommen ist, so dass sich der Termin noch weiter verzögern könnte... [3]

[1] https://docs.freebsd.org/cgi/getmsg.cgi?fetch=102429+0+current/freebsd-current
[2] https://www.freebsd.org/releases/13.0R/schedule/
[3] https://docs.freebsd.org/cgi/getmsg.cgi?fetch=222412+0+current/freebsd-current
 
Eigentlich ist es nur so zu erklären, dass Netgate den Kram um jeden Preis in 13.0 haben wollte und es wider besseren Wissens durchgepeitscht wurde. Auf FreeBSD-Seite wiederum keiner so genau hingeschaut, weil Netgates Beiträge bisher Hand und Fuß hatten, außerdem mehrere erfahrene Entwickler unten drunter standen.
Das scheint mir aber ein gravierendes Problem zu sein. Zwischen OpenBSD (wo ich kaum Einfluss von Unternehmen vermute) und Linux (wo es sehr viel z.T. konkurrierende Unternehmen gibt), scheint mir "Core-Team winkt alles von einem Unternehmen durch" die schlechteste Lösung.
Selbst sehr viel unwichtigere Projekte an denen ich gearbeitet habe, haben einen besseren Code-review Prozess. Und dass sich security@ nicht einschaltet bei einem Projekt, dass ja offensichtlicht für einen Major Stakeholder so wichtig ist, verstehe ich auch nicht.

Vor ein paar Jahren gab es einen Talk auf dem Congress zu Vulnerabilities in BSD-Code. Die Anzahl der entdeckten Probleme fand ich wenig aussagekräftig, aber es kam auch raus, dass OpenBSD alle reporteten Probleme innerhalb von 14 Tage gefixt hat, NetBSD alle Probleme innerhalb von zwei Tagen und bei FreeBSD nach fünf Monaten noch 27/30 ungefixt waren: https://media.ccc.de/v/34c3-8968-are_all_bsds_created_equally#t=2742

Das sind natürlich alles nur Ausschnitte (und ich finde FreeBSD wegen vieler Dinge super), aber für mich sind das alles Indizien, dass die Strukturen und Prozesse sehr problembehaftet sind.

Ich hoffe immer noch, dass das mal jemand in freebsd-update einbaut. HardenedBSD hat das seit Jahren drin: hbsd-update -b <MeinNeuesBE> macht all diese Schritte automatisch. Nach einem Neustart ist man automatisch im neuen Boot Environment <MeinNeuesBE>.
Ja, das wünsche ich mir auch. Es gibt so viel gute Dinge, aber sie scheinen einfach nicht "verdrahtet" zu sein. Warum kann FreeBSD update nicht einfach das System hochziehen und mir beim nächsten Start im Bootloader einen Eintrag anzeigen [boot into last version].
Warum kann pkg upgrade nach einem upgrade nicht sagen "Your previous state has been saved and can be restored via pkg rollback for the next seven days". Oder sowas. Das ist sind alles Features, die man bei FreeBSD einfach(er) machen könnte, weil man eben eine base hat und Tools wissen, dass es andere Tools gibt.
 
FreeBSDs größter Vor- und Nachteil im Vergleich zu anderen Projekten war schon immer, dass es demokratisch ist. Demokratische Strukturen helfen dem menschlichen Miteinander sehr. Ich habe in genügend Open Source Projekten und professionellen Projekten gearbeitet um sagen zu können, dass FreeBSDs Entwickler- und Nutzercommunity deutlich freundlicher, weltoffener und auch technisch kompetenter als die meisten anderen Gemeinschaften oder Teams im weiteren Feld der Softwareentiwicklung ist. ich würde sogar soweit gehen und sagen, dass die demokratische Organisation der Hauptgrund ist, dass FreeBSD sich als einziges freies Betriebssystem-Projekt einigermaßen gegen Linux behaupten konnte. Gäbe es einen (wohlwollenden) Diktator, der durch seine Interessen den Kurs des Projekts direkt oder indirekt vorgibt, wäre FreeBSD schon vor langer Zeit zu einem Betriebssystem für eine sehr kleine Nische im Bereich dieser Interessen geworden. Wenn überhaupt.

Aber Demokratie macht das Finden eines gemeinsamen Wegs und die notwendige Koordination um diesen zu erreichen auch schwer. Weil es eben niemanden gibt, der sagt wie es gemacht wird und mit der Faust auf den Tisch haut, wenn jemand aus der Reihe tanzt. FreeBSD hat dann auch ein recht starkes Wir-Gefühl in Sachen "Wir sind FreeBSD", aber nur ein schwach ausgeprägtes Wir-Gefühl in Sachen "Unser Ziel ist XXX". Das Ziel definiert sich jeder Entwickler oder die hinter dem Entwickler stehenden Kräfte selbst. core@ sieht sich dann auch eher als eine koordinierende Instanz, als denn ein Gremium, was den Kurs des Projekts vorgibt oder sogar irgendwelche Regeln durchsetzt.

Oder anders gesagt: freebsd-update integriert nicht mit Boot Environments, weil es einfach niemand eingebaut hat. Genauso ist das durchaus vorhandene zfsnap pkg-Plugin niemals im pkg-Paket oder wenigstens einem eigenen Port gelandet. Es war anscheinend nie wichtig genug. Ich will mich da selbst gar nicht ausnehmen, ich hätte die Arbeit ja machen können, anstatt zfsnap vor pkg upgrade manuell aufzurufen.

Die Frage ob Code Review oder kein Core Review, die in den letzten Tagen außerhalb des Projekts viel diskutiert wird, geht in die gleiche Richtung. Es ist leicht verpflichtende Code Reviews zu fordern und gäbe es einen Diktator, könnte der sie einfach verlangen. Wobei der Diktator sich dann immer noch darauf verlassen muss, dass die Reviews auch sinnvoll durchgeführt wurden und nicht einfach eine nervende pro-forma Geschichte sind. Wenn ich mit die Bugdichte in den Mainline- und Stable-Zweigen eines anderen Btriebssystemprojekts so anschaue, ist es zumindest gewagt, von verpflichtenden Reviews und schönen "Signed of by"-Zeilen automatisch auf hochqualitativen Code zu schließen. Das FreeBSD Projekt überlässt die Frage, ob Reviews verlangt werden sollen, dann auch den einzelnen Entwicklern beziehungsweise den Maintainern der jeweiligen Subsysteme. Meist klappt das wunderbar, die meisten Commits in kritischen Bereichen durchlaufen ein Review. Hier ist es eben schief gegangen und nun muss (und wird) man einen Schritt zurücktreten, analysieren wo der Fehler lag, diskutieren und damit wird sich sicher eine Lösung für die Zukunft entwickeln.

Darüber hinaus sehen wir hier mal wieder das Internet und seinen Mob in voller Fahrt. Niemand streitet ab, dass die Wireguard-Sache Kacke gelaufen ist und das es Konsequenzen haben muss und wird. Aber Matt Macy als einen kranken Psychopathen oder ahnungslosen Spinner darzustellen und öffentlich hinzurichten, geht gar nicht. Was seine Fehler vor fast 15 Jahren betrifft, ist er verurteilt worden, ins Gefängnis gegangen und hat seine Strage verbüßt. Damit ist in dem im Moment viel zitierten Rechtsstaat die Sache vergeben und vergessen. Auf technischer Seite war er wesentlich an dem Epochs-Projekt beteiligt und hat u.a. den Netzwerkstack von klassischen Locks auf Epochs portiert. Lockfreie Synchronisation in hochparallelisierten Umgebungen ist verdammt hart, das bekommt kein Aufschneider hin. Und er war eine der armen Seelen die drei stark divergierte ZFS-Zweige zu OpenZFS gemerget haben. Das bedeutete die Zusammenarbeit mit drei Upstreams, was ein gewisses Maß sozialer Kompetenz benötigt. Weder Ars Technica mit ihren sehr negativen Unterton, noch die meisten Außenstehenden gestehe ihm das zu, aber könnte es nicht einfach sein, dass er die Wahrheit sagt? Das ihm die Sache zwischen der bescheidenen wirtschaftlichen Situation im Corona gebeutelten USA der späten Trump-Ära, seinen eigenen Corona-Erkrankung, persönlichen Problemen und einer toxischen Umgebung über den Kopf gewachsen ist.
 
Also, wenn das Release kurze Zeit später erscheint - das ist doch kaum entscheidend, oder? Schade, wenn was fehlt, aber besser so als "krumme Steine" verbauen. Ich werde trotzdem den Upgrade machen und 13.0-RC1 läuft super auf meinem Laptop... :)
 
ah. nun verstehe ich dann etwas besser, wieso beim letzten Update if_wg(4) gelöscht worden ist.
nicht, dass ich es vermissen würde oder überhaupt bemerkt hätte.
Deshalb möchte ich das mal etwas herunter brechen.

Offenbar gab es diesmal etwas Chaos in der Entwicklung und wir sind das ja als FreeBSD-Nutzer eher nicht gewohnt. Aber dieses Chaos hat bei mir, als Endanwender, keinerlei Spuren hinterlassen, selbst innerhalb des doch eher empfindlichen Pre-Release Bereiches. Alle Beta und RC Versionen konnte ich bisher locker updaten und weiter als Unterbau für meinen Desktop auf unterschiedlichen PCs nutzen.

Hätte es nicht diese merkwürdigen, also aus meiner Sicht merkwürdigen Diskussionen und Kommentare gegeben, hätte ich von einem Chaos in der Entwicklung gar nichts bemerkt.
Und das bitte ich dann mal mit anderen Systemen zu vergleichen!

Also, nachdem @Yamagi das ja auch nochmal gut erklärt hat und wenn ich auf das Ergebnis und meine eigenen Erfahrungen blicke, fühle ich mich doch gerade wegen des Umgangs mit solchen Problemen bei FreeBSD besonders wohl!
Für mich kann ich sagen: so gehört das doch!

Alles gut, alles nur Menschen. Gott sei Dank. ;)
 
i386 ist ja auch rausgeflogen aus FreeBSD 13. Soweit ich weis, sind doch alle neuen CPUs immer noch in der Lage i386 auszuführen. Bei FreeBSD weis ich es nicht, aber unter Debian gibt es popcon das zeigt wieviel das noch im Verhältnis zu amd64 eingesetzt wird. Gibt es so eine Statistik auf für FreeBSD?


EDIT: Nicht ganz weg, aber Tier 2
 
i386 ist ja auch rausgeflogen aus FreeBSD 13
Man muss bei der Geschichte auch ein wenig differenzieren. Nämlich zwischen generellen 32-Bit-Support und überhaupt der Fähigkeit auf einem konkreten 32-Bit-Prozessor (wie halt der angesprochene 80386) zu laufen.
Also wer noch ein System mit nem orginalen 80386 Prozessor hat, hat ohnehin ein Problem. Weil häufig hast Du bei Kompilaten zwar 32-Bit-Code aber die laufen trotzdem nicht auf 80386-Prozessoren, weil die halt für neuere CPUs kompiliert wurden um halt auch die dortigen neuen Features nutzen zu können.

Nicht ganz weg, aber Tier 2
Der heise.de-Artikel deutet ja auch ein wenig an, das i386 nicht völlig auf Tier-2 abrutscht, sondern es eher so eine Art Tier-1,5-Support werden wird. :-)

Soweit ich weis, sind doch alle neuen CPUs immer noch in der Lage i386 auszuführen.
Ja. Im Prinzip können die sogar noch 16-Bit-Code ausführen (also MS-DOS und Co). Wobei bei solchen Sachen auch meist nicht die CPU das Problem ist, sondern das drum herum. So hat halt MS-DOS eben nicht die Treiber, die Du für moderne Hardware brauchst und solche Sachen.

Das Grundproblem ist ja auch, das dann solche alten Sachen dann auch gewartet und getestet werden müssen. Und das lohnt irgendwann nicht mehr, wenn es kaum noch einer nutzt. Dann ist es übrigens auch nicht verkehrt alten Kram irgendwann mal rauszuwerfen. Das ist dann nur Komplexität die Dir nix bringt aber Quelle von Bugs und Sicherheitsproblemen werden kann.
 
Man muss bei FreeBSD/i386 auch immer das Jahr 2038 Problem sehen. Irgendwann wird man die Architektur entweder entsorgen oder die Binärkompatibilität brechen müssen. Beides verträgt sich nicht mit der Vorgabe einer Tier-1 Architektur unbegrenzte Binärkompatibilität zu garantieren.
 
Beim gemeinsamen Analysieren von Performanceproblemen im Zusammenhang mit ZFS (teilweise >10 Sekunden I/O-Stalls und ab an "Bad Filedescriptor" Fehler beim Öffnen von Dateien) in ##bsdforen.de haben wir festgestellt, dass es nicht mehr notwendig ist den ZFS ARC zu begrenzen. Es ist sogar sehr kontraproduktiv.

Auch wenn es ein Cache ist, ist der ARC aber ein integraler Bestandteil von ZFS. Vor allem werden alle Daten erst in den ARC gelesen, bevor sie an den Aufrufer gegeben werden. Und sie werden erst in den ARC kopiert und dann asynchron auf das Speichermedium geschrieben. ZFS braucht also eine gewisse Menge ARC, sowohl in Form von RAM, als auch virtuellen Speicheradressen. Als ZFS on FreeBSD (ZoF) vor weit über 10 Jahren begann, war FreeBSD/i386 mit seinem sehr begrenztem Adressraum aber noch weit verbreitet und auch auf FreeBSD/amd64 hatten viele Maschinen nicht mal 4 Gigabyte RAM. Daher wurde ZoF ARC die ersten Jahre stark darauf optimiert, auch mit sehr kleinen Größen gut klarzukommen, ohne die Performance zu verhageln. Umgekehrt war unter ZoF immer ein großes Problem, dass das Freigeben von Speicher träge war. Wenn bei unbegrenztem ARC eine große Speicheranforderung wie z.B. eine startende VM kam, wurde das System tief in die Swap gedrückt oder es schaute sogar der Out of Memory Killer vorbei. Daher wurde oft und auch von mir empfohlen, den ARC zu begrenzen.
Vor einiger Zeit hat Joyent den ARC für ZFS on Linux (ZoL) komplett überarbeitet. Als man die drei ZFS-Zweige von FreeBSD, Illumos und Linux zu OpenZFS mergte, übernahm man die ARC-Implementierung von ZoL. Die verhält sich deutlich anders als ZoF-Implementierung. Sie kommt augenscheinlich mit einem zu sehr begrenztem ARC nicht wirklich gut klar, aber sie kann Speicher äußerst schnell freigeben. Selbst bei größeren Poudriere-Builds wie llvm9, llvm10 und chromium mit ALLOW_MAKE_JOBS ließ sich das System nicht tiefer in die Swap drücken, stattdessen gab der ARC den benötigten RAM innheralb von Mikrosekunden frei.

Bei Problemen mit OpenZFS kann es also helfen die ARC-Begrenzung rauszunehmen.
 
Beim gemeinsamen Analysieren von Performanceproblemen im Zusammenhang mit ZFS (teilweise >10 Sekunden I/O-Stalls und ab an "Bad Filedescriptor" Fehler beim Öffnen von Dateien) in ##bsdforen.de haben wir festgestellt, dass es nicht mehr notwendig ist den ZFS ARC zu begrenzen. Es ist sogar sehr kontraproduktiv.

Auch wenn es ein Cache ist, ist der ARC aber ein integraler Bestandteil von ZFS. Vor allem werden alle Daten erst in den ARC gelesen, bevor sie an den Aufrufer gegeben werden. Und sie werden erst in den ARC kopiert und dann asynchron auf das Speichermedium geschrieben. ZFS braucht also eine gewisse Menge ARC, sowohl in Form von RAM, als auch virtuellen Speicheradressen. Als ZFS on FreeBSD (ZoF) vor weit über 10 Jahren begann, war FreeBSD/i386 mit seinem sehr begrenztem Adressraum aber noch weit verbreitet und auch auf FreeBSD/amd64 hatten viele Maschinen nicht mal 4 Gigabyte RAM. Daher wurde ZoF ARC die ersten Jahre stark darauf optimiert, auch mit sehr kleinen Größen gut klarzukommen, ohne die Performance zu verhageln. Umgekehrt war unter ZoF immer ein großes Problem, dass das Freigeben von Speicher träge war. Wenn bei unbegrenztem ARC eine große Speicheranforderung wie z.B. eine startende VM kam, wurde das System tief in die Swap gedrückt oder es schaute sogar der Out of Memory Killer vorbei. Daher wurde oft und auch von mir empfohlen, den ARC zu begrenzen.
Vor einiger Zeit hat Joyent den ARC für ZFS on Linux (ZoL) komplett überarbeitet. Als man die drei ZFS-Zweige von FreeBSD, Illumos und Linux zu OpenZFS mergte, übernahm man die ARC-Implementierung von ZoL. Die verhält sich deutlich anders als ZoF-Implementierung. Sie kommt augenscheinlich mit einem zu sehr begrenztem ARC nicht wirklich gut klar, aber sie kann Speicher äußerst schnell freigeben. Selbst bei größeren Poudriere-Builds wie llvm9, llvm10 und chromium mit ALLOW_MAKE_JOBS ließ sich das System nicht tiefer in die Swap drücken, stattdessen gab der ARC den benötigten RAM innheralb von Mikrosekunden frei.

Bei Problemen mit OpenZFS kann es also helfen die ARC-Begrenzung rauszunehmen.

Das ist ne sehr willkommene Änderung, ich fand es immer sehr unschön den ARC zu begrenzen, auch auf Maschinen mit 16 GB Ram war das tw. nötig wenn man andere Prozesse laufen hat die schnell große Mengen an RAM fressen.

Wie verhält es sich derzeit mit ZoL/FreeBSD aus den Ports auf FreeBSD 12.2? Ist das vergleichbar zu 13.0 was Testabdeckung und Versionsstand betrifft? Ich bin ja immer eher Vorsichtig und warte meist auf die .1 Version beim Majorupgrade wenn ich nicht zwingend die neuen Features brauche.
 
Also, nachdem @Yamagi das ja auch nochmal gut erklärt hat und wenn ich auf das Ergebnis und meine eigenen Erfahrungen blicke, fühle ich mich doch gerade wegen des Umgangs mit solchen Problemen bei FreeBSD besonders wohl!
Für mich kann ich sagen: so gehört das doch!
kann mich dem voll anschliessen: FreeBSD ist weiterhin meine erste Wahl :) :) Und Unstimmigkeiten gibt es überall, auch in den besten Familien. Die Frage ist nur, wie damit umgegagnen wird :) VG Norbert
 
Wie verhält es sich derzeit mit ZoL/FreeBSD aus den Ports auf FreeBSD 12.2? Ist das vergleichbar zu 13.0 was Testabdeckung und Versionsstand betrifft? Ich bin ja immer eher Vorsichtig und warte meist auf die .1 Version beim Majorupgrade wenn ich nicht zwingend die neuen Features brauche.
Ich kann es nicht 100% genau sagen, aber dem Versionsstand nach dürften 13.0 und der openzfs-Port für 12.2 größtenteils gleich sein. 13-STABLE ist inzwischen eine OpenZFS-Version voraus, aber das waren nur Kleinigkeiten.
 
"A small set of updates that we consider blocking the 13.0 release have
been brought to our attention. As such, the 13.0-RELEASE schedule has
been updated to include a fifth release candidate (RC5)."
Quelle

Jetzt also:
RELEASE builds begin 9 April 2021
RELEASE announcement 13 April 2021
 
Etwas OT, aber hat jemand schon mal probiert, FreeBSD/arm64 auf Apples neuen M1 Rechnern virtuell zum Laufen zu bekommen? Bisher kenne ich nur Lösungen mit Linux.
 
Tatsächlich - und (etwas) eher als angekündigt.
Hab gerade mal das Upgrade durchlaufen lassen - keine Probleme, alles funktioniert noch.
Chapeau chapeau!
 
Danke Yamagi,

mit Teil 1 der Antwort wäre ich ja schon zufrieden gewesen (wie ich nach einem schief gelaufenen Update das rollback machen muss, such ich mir noch raus). Aber genau das war der Grund - und Experimentierfreude - ZFS zu probieren.

In Teil 2 werde ich mich auch mal in Ruhe einlesen (Vor- bzw. Nachteile von clone gegenüber snap). Wenn es zu wirr wird, melde ich mich nochmal.
So, es scheint soweit zu sein: FreeBSD 13 ist da und das Upgrade steht also demnächst an. Ich würde es nach dieser Prozedur "Upgrade FreeBSD with ZFS Boot Environments:" (gefunden bei Vermaden) vorgehen. Das entspricht der "Clone"-Variante, richtig?

Oder spricht etwas dagegen?

PS: bei dem Rechner handelt es sich um ein MacBook Pro von 2011 oder 2012 (ich habe die leise Hoffnung, dass WLAN-Karte und die Funktionstasten besser unterstützt werden - aber man wird sehen; der eigentliche Zweck des Rechners ist das Experiment ;) ).

Ciao,
Photor
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben