Kommendes Update auf FreeBSD 13

Status
Für weitere Antworten geschlossen.

Photor

Well-Known Member
Hallo Forum,

demnächst steht ja das Update von FreeBSD 12.2 auf 13 an. Das letzte mal, dass ich ein FreeBSD Major-Update gemacht habe, war zu Zeiten von FBSD 7. Ich denke, es wird eine (gute) Anleitung geben.

Weshalb ich trotzdem hier frage, ist, dass ich bei der Neu-Installation ZFS als Filesystem gewählt habe - das ist neu für mich. Wenn ich es richtig verstanden habe, kann ich mit ZFS einen Snapshot machen, den ich im Zweifelsfall (AKA fehlgeschlagenes Upgrade) wieder aktivieren kann. Ist das so? Und wie muss ich das machen, um es sicher zu machen?

Ciao,
Photor
 
Du kannst das System mit zfs snap snapshotten und mit zfs rollback später auf den Stand des Snapshots zurückkehren. Aber wenn du frisch auf ZFS installiert hast, unterstützt dein System Boot Environment. Sprich du kannst die aktuelle Installation klonen, den Klon updaten und wenn was Schief geht, bootest du ins alte System zurück. Das Stichwort dafür ist seit 12.0 bectl im Basisystem, davor war es beadm aus dem Ports. In meinen Leseeichen habe ich noch: https://vermaden.files.wordpress.com/2018/11/nluug-zfs-boot-environments-reloaded-2018-11-15.pdf Ist aber etwas wirr, fürchte ich.
 
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.

Ciao,
Photor
 
Aus Neugierde und wegen dieser Beiträge:

habe ich heute mal einen Update auf die 13.0-BETA2 gemacht und oben wurde ja schon grundsätzlich zur Vorbereitung was gesagt.
Nun möchte ich aus meiner Erfahrung berichten:
Der Update war aus 12.2-RELEASE-p3 erfolgt.
Es gab nur bei zwei Dateien eine Nachfrage, ob das Mergen so in Ordnung sei. Das waren /etc/login.conf und /etc/ntp.conf. Für mich waren die Änderungen in Ordnung und sie wurden auch ohne Zutun gemerged.
Die ntp.conf erhielt offenbar neue Server-Einträge. Weil ich nur beim Booten einmal die Zeit synce, war mir das egal.
Neu ist und es wird darauf hingewiesen, dass nicht mehr die /etc/motd gilt und entsprechend gelöscht wird, sondern nun /var/run/motd genommen wird. Für mich bedeutet das, dass ich meine bisherige motd zunächst mal gespeichert habe und später nachsehen werde, ob ich sie wieder herstellen werde.
Weil ich irgendwo gelesen habe, dass nun powerd den powerd++ wieder erstezen kann, habe ich das in der rc.conf angepasst.

Der Wechsel zu 13 stellt einen großen Release-Wechsel dar, also mit Bruch der ABI und demzufolge Neubau aller installierten Pakete. Da ich nur Pakete benutze, ging das recht flott (habe ja nun auch endlich schnelles Internet) und dabei wurden 45 Pakete deinstalliert, die ich nicht sehen konnte, weil der Buffer auf meiner Konsole nicht ausreichend war. Ich hätte mich vielleicht besser remote aufschalten sollen. Naja, Schwund ist immer.
Es fehlt nun Opera (sicherlich noch mehr, aber der sticht ins Auge). Es gibt noch (wieder?) linux-opera als Paket, aber das wollte ich zunächst nicht nehmen. Stattdessen gibt es nun (wieder) chromium als Paket (und funktioniert sogar).

Zumindest auf diesem PC mit nvidia GraKa war das also kein Problem bisher.
Ich frage mich aber, ob angesichts der doch vielen Änderungen nicht vielleicht eine Neuinstallation angesagt ist. So habe ich doch viele Settings aus Bequemlichkeit einfach übernommen und das geht ja auch. Dann sieht man viele neue Sachen vielleicht nicht und denkt gar nicht darüber nach und womöglich verpasst man dann etwas.

Ein wenig erstaunt bin ich, dass es keinen Hinweis auf einen zpool upgrade gab. Ich dachte, dass mit 13 auch eine neue ZFS-Version käme?
 
Ich dachte, dass mit 13 auch eine neue ZFS-Version käme?
Ja und eigentlich müsste zpool upgrade auf einiges an neuen Features aktivieren. zfs upgrade ist aber tatsächlich nicht nötig. Weil nur das Pool-Format erweitert wurde, aber nicht das Dataset-Format.
 
Das binary upgrade von 12.2-p3 auf 13.0-BETA2 (weil ich einfach nicht mehr auf das Release warten wollte wegen der Nutzung von drm-kmod) und heute nochmal auf BETA3 lief bei mir auch reibungslos. Das Einzige, woran ich mich als Unterschied zu vorhergehenden Upgrades erinnere, ist das oben bereits erwähnte mit motd.

zpool zeigt mir auf jeden Fall neue Features an
 
Ja und eigentlich müsste zpool upgrade auf einiges an neuen Features aktivieren. zfs upgrade ist aber tatsächlich nicht nötig. Weil nur das Pool-Format erweitert wurde, aber nicht das Dataset-Format.
ja, so war das auch. Weil ich das zuvor gelesen hatte, machte ich das upgrade auch. Vielleicht schadet es nicht, das eh nach jedem größeren update zu machen.
und heute nochmal auf BETA3
dito. An diesem Rechner kein Problem und läuft bisher sehr gut.

Was mich wieder zu meinem alten Problem bringt, dass ich als unbedarfter Endanwender nicht in einer Mailing-Liste eingetragen bin und deshalb nur nebenher erfahre, wenn es neue Versionen gibt. Das ist normalerweise auch OK, ich hechele nicht hinter her und kann auch mit alten Versionen leben.
freebsd-update kann man (afaik) nicht dazu auffordern, verfügbare Versionen auszugeben.
Gibt es da andere Möglichkeiten?
War nicht auch mal die Rede von einem FreeBSD-Tool für binäre-System-Updates?
 
Vielleicht schadet es nicht, das eh nach jedem größeren update zu machen.
Wobei es sinnvoll sein kann abzuwarten und es zeitnah nur dann zu machen, wenn man die neuen Features wirklich braucht.
Schließlich muss man (insbesondere in der BETA-Phase) damit rechnen das man doch noch auf irgendwelche Show-Stopper trifft und dann (zumindest temporär) wieder Downgraden muss und das geht mit nem aktualisierten ZFS eher nicht so gut.
 
Kleine Warnung an alle, die schon auf 13 umsteigen wollen: Schaut einmal gut hin, ob schon alle Ports, die Ihr benötigt auf 13 funktionieren!

Gerade im Quarterly Repo fehlen einige (wichtige) Packages. Ich habe z.B. eine Jail erstmal auf 12.2 belassen, weil es kein MariaDB-Server gibt (egal welche Version). Baut nicht. Ich stellte auch fest, dass es security/rkhunter nicht gibt, weil sysutils/lsof nicht baut. Ich hab's selbst versucht, bricht ab.

Das alles betrifft vor allem (nur?) das Quarterly Repo und ich vermute, dass einige Maintainer einfach warten, bis das 2. Qurtal da ist und einige Probleme löst. Denn FreeBSD 13 ist ja noch nicht raus, warum soll man dafür die Ports des 1. Quartals noch anpassen... ?!
 
ob schon alle Ports, die Ihr benötigt auf 13 funktionieren!

Gerade im Quarterly Repo fehlen einige (wichtige) Packages.
Über was redest Du jetzt? Ports oder Packages. Entscheide Dich mal. :-)

Das alles betrifft vor allem (nur?) das Quarterly Repo
Naja. Quarterly ist da eh eher uninteressant. Wenn schon, dann latest. Über alles andere braucht man (in Hinblick auf FreeBSD 13) gar nicht ernsthaft nachzudenken.
 
@Andy_m4 Ich dachte, der Zusammenhang ist klar: Die Ports sind ja für alle Versionen dieselben. Also sind sie da. Aber die aus der Quarterly Branch bauen z.T. nicht auf FreeBSD 13. Dann gibt es eben keine Packages - egal ob im offiziellen Quarterly Repo oder im mit Poudriere gebauten eigenen Repo...

Diesen Zusammenhang zwischen Ports und Packges siehst Du ja auch im "Portsfallout", den freshports.org eigentlich korrekter als "pkg-fallout" verlinkt (hinter dem "radioaktiv"-Icon).
 
Ich dachte, der Zusammenhang ist klar:
Eher nicht wenn Du immer die Begriffe Ports und Packages fröhlich durcheinander wirfst.
Vielleicht solltest Du ganz konkret sagen, wovon Du redest und nicht nur Andeutungen machen wo sich der Leser dann zusammenreimen muss, was Du nun meinst.
Immerhin wurde es inzwischen klarer.
 
Ja und eigentlich müsste zpool upgrade auf einiges an neuen Features aktivieren. zfs upgrade ist aber tatsächlich nicht nötig. Weil nur das Pool-Format erweitert wurde, aber nicht das Dataset-Format.
JFYI Nach einem zpool upgrade gibt es kein zurück mehr auf FreeBSD 12 (falls ihr mit bectl was angelegt habt)
 
Das Wireguard-Drama hat es inzwischen bis zu Ars Technica geschafft: https://arstechnica.com/gadgets/202...on-its-way-to-freebsd-and-the-pfsense-router/ Mal schauen, ob die schützenswerte deutsche IT-Presse es kopiert. Ich verstehe nur nicht, wieso sich ein alter Hase wie Scott Long so unprofessionell verhält. Er sollte wissen, dass man solche Differenzen nicht in der Öffentlichkeit klärt.

Edit: Als positiv denkender Mensch warte ich mit dem Umschreiben der schon seit 14 Tagen fertigen BSDForen News zu 13.0 noch, bis es wirklich aus 13.0 rausgeflogen ist. Aber ich denke nicht mehr, dass 13.0 mit Wireguard im Kernel kommen wird.
 
... there were 40,000 lines of optimized crypto implementations pulled out of the Linux kernel compat module but not really wired up correctly, and mangled beyond repair with mazes of Linux→FreeBSD ifdefs. I wound up replacing this with an 1,800 line file, crypto.c, containing all of the cryptographic primitives needed to implement WireGuard.
Einfach nur krank was hier alles schief geht.

 
Ich finde die Sache obskur. Geschrieben wurde der originale Code von Scott Long, importiert von Matt Macy und danach von Peter Grehan übernommen. Das sind alles drei erfahrene Entwickler, die solche Anfängerfehler nicht machen. Während des Reviews - https://reviews.freebsd.org/D26137 - wurden keine grundsätzlichen Bedenken geäußert. security@ wurde anscheinend gar nicht gefragt, hat sich aber auch nicht von sich aus geäußert. Und obwohl es zu vielen, wesentlich weniger kritischen Commits konstruktive Diskussionen gibt, dauerte es hier über 3 Monate, bis die Bombe platzte. Die Diskussion beim Commit - https://lists.freebsd.org/pipermail/svn-src-all/2020-November/205906.html - sprach die Probleme nicht mal an. Die Bombe kam wohl erst, nachdem sich pfSense-Nutzer irgendwo im Wireguard-Projekt mit Bugs gemeldet haben.
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.
 
Edit: Als positiv denkender Mensch warte ich mit dem Umschreiben der schon seit 14 Tagen fertigen BSDForen News zu 13.0 noch, bis es wirklich aus 13.0 rausgeflogen ist.
Laut der freebsd-hackers-Liste ist es raus.
WG soll als Port mit weniger Zeitdruck und mehr "Augen" weiterentwickelt werden, die haben wohl selbst gemerkt, dass das alles ein wenig überstürzt war.

Rob
 
hi

witzig ,bei openbsd ist wireguard recht schmerzlos implementiert worden.

und , wie es scheint, stressfrei zu laufen.

verstehe ichnicht warum dasbei freebsd icht auch so funktionieren kann.

holger
 
Mal wieder ein wenig zu FreeBSD 13.
Ich habe von 12.2 auf 13-RC1 nach dieser Methode gewechselt, ohne Probleme, ohne Neustarts.
Ich verstehe zwar nicht, was und wie ZFS das macht, aber das ist schon cool...
 
Danke für den Link, liest sich sehr interessant. Evtl. ist RC2 auch schon per freebsd-update verfügbar, die ISO-Dateien etc. können bereits heruntergeladen werden.
 
Ich verstehe zwar nicht, was und wie ZFS das macht, aber das ist schon cool...
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. Geht etwas schief, kann man ins alte System zurückbooten, da es auf dem alten Dataset noch vorhanden ist. Sobald man ein zpool upgrade macht, ist der Weg zurück allerdings versperrt, da der FreeBSD 12.x Kernel den OpenZFS-Pool nicht lesen kann.
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben