Alte Bibliotheken entfernen?

C

CrimsonKing

Guest
Ich aktualisiere mein OpenBSD mit ein paar Skripts, die locker dieser Anleitung folgen. Dabei bleiben natürlich "alte" Versionen von Bibliotheken erhalten. Kann ich die irgendwie halbwegs sicher entfernen?
 
Wenn Du "pkg_add -ui" benutzt wie im Beispiel werden nicht mehr benötigte Bibliotheken eigentlich entfernt.
Mit "pkg_delete -a" kannst Du ebenfalls ungenutzte "Dependencies" entfernen, sofern sie ursprünglich automatisch installiert wurden. Aber Vorsicht, wenn beim Upgrade was schief gelaufen ist, speziell wenn nach dem Update/Upgrade "part"-Packages existieren, kannst Du dir damit auch dein System endgültig zerschießen. (Bzw. alle installierten Anwendungen entfernen, das Basissystem sollte erhalten bleiben)
 
Hm, ich nutze pkg_add -u. - Ich habe un /usr/lib eine Vielzahl an libc-Versionen und dachte, da sind vielleicht ein paar "alte" dabei. Werden also doch alle noch benutzt? Wusste ich nicht.

pkg_delete -a löscht einiges. Interessant. Danke!
 
Alte Systemlibs werden bei Updates nicht automatisch entfernt, das musst du manuell erledigen. Was genau du entfernen kannst, steht in der FAQ (current, http://www.openbsd.org/faq/current.html) bzw in den upgrade-Hinweisen für stable-releases (http://www.openbsd.org/faq/upgrade55.html). Dein upgrade-prozess ist irgendwie kompliziert, zumindest für einen desktop; du kannst auch bsd.rd vom Server nach / downladen und beim Start mit "boot /bsd.rd" booten und upgraden ;)
 
Dafür brauch' ich aber trotzdem die aktuellen Pakete, gewinne also höchstens beim Entpacken etwas Zeit (und das lässt sich ja supi automatisieren). :)

Ich habe "Following -CURRENT" auf meiner Beobachtungsliste, wusste aber nicht, dass das auch "veraltete" Linker-Bibliotheken behandelt.
 
Nun ja; wo genau liegt der Vorteil gegenüber "automatisch runterladen, entpacken, reboot, Nach-Reboot-Script (sysmerge, pkg_add, pkg_delete), fertig"?

(Wobei ich noch rausfinden muss, wieso "reboot" nicht mehr geht, wenn base55.tgz automatisch entpackt ist...)
 
Das entpackt einen neuen kernel mitsamt neuem userland, während der alte kernel noch läuft. Ich bin mir nicht zu 100% sicher, aber ich meine, dass es zu Problemen im Userland kommen kann, falls sich grundlegende Dinge im Kernel geändert haben (vielleicht hängt dein reboot-Problem damit zusammen?). Wenn du mittels des ramdisk-kernels updatest, umgehst du dieses Problem.
 
Hm, ich hatte noch nie Probleme damit - also vor heute. ;)

Kann man den Reboot in bsd.rd irgendwie automatisieren? Ich bin faul. :D
 
Vielleicht, wenn du den neuen bsd.rd in /bsd kopierst? Der kernel sollte ja schon im RAM liegen. Hab ich selbst aber noch nie probiert ;)
 
Dann müsst' ich aber trotzdem rebooten, bevor ich das mache, richtig?
 
Hm, was meinst du? Du musst zweimal rebooten: einmal das laufende System, nachdem du die neuen Dateien runtergeladen hast (lässt sich wahrsch. automatisieren, s.o.) und dann einmal am Ende des Installers (lässt sich wohl nicht automatisieren).
 
Seit die bsd.rd gegen sha256.sig verifiziert, kannst du den Schritt "neue Dateien vor dem Update runterladen" überspringen (ausgenommen etc55.tgz und xetc55.tgz und evtl. sha256.sig - die brauchst Du weiterhin für sysmerge). Die "alte" bsd.rd" lädt alle benötigten Dateien aus dem snapshot-Verzeichnis runter incl. der "neuen bsd.rd" und verifiziert sie.
 
Das stimmt, mein script speichert aber zusätzlich die letzten 2 zurückliegenden snapshots (falls ein downgrade erforderlich sein sollte, z.B. um zu gucken wann ein bug zum ersten mal aufgetaucht ist) und läd nur Dateien runter, deren hash sich zum letzten vorhandenen snapshot geändert hat (oft werden ja die X-sets länger nicht neu gebaut, während es fast täglich einen neuen kernel gibt). Man erfährt auch direkt, ob der letzte snapshot immer noch der aktuelle ist, ohne sich die Dateien auf dem ftp-server genauer angucken zu müssen :)
 
Hm, was meinst du? Du musst zweimal rebooten: einmal das laufende System, nachdem du die neuen Dateien runtergeladen hast (lässt sich wahrsch. automatisieren, s.o.) und dann einmal am Ende des Installers (lässt sich wohl nicht automatisieren).

Dann ist der Kernel aber nicht mehr im RAM.
 
Ich dachte an folgendes:

Code:
Download bsd.rd
sudo mv /bsd /obsd
sudo mv ~/bsd.rd /bsd
sudo reboot # direkt in bsd.rd

Es wird direkt in bsd.rd gebootet, nach dem update muss man aus dem installer allerdings manuell rebooten. Ich denke man kann es nicht einfacher haben, sofern man per bsd.rd updaten will.
 
Oder man spart sich diesen Umweg und arbeitet mit tar ... :D

Ernsthaft: Deine Lösung könnte gehen. Werde ich beim nächsten Snapshot-Update mal ausprobieren, wenn ich's nicht vergesse. :)
 
Tar geht natürlich auch ;) Im von dir verlinkten blogpost steht noch:

Copy your desired kernel to the root directory. I’m using the multiprocessor kernel. Also save a copy of your current reboot command.

Mir persönlich wäre das zu viel Aufwand immer aufzupassen, ob was an dem Verfahren angepasst werden muss. Aber ich probier mal, direkt in bsd.rd zu booten.
 
Ich kann meinen Beitrag nicht mehr editieren, wollte aber noch sagen, dass der Weg über bsd.rd der offizielle ist (wird auch benutzt, wenn man releases per CD updated).
 
Mir persönlich wäre das zu viel Aufwand immer aufzupassen, ob was an dem Verfahren angepasst werden muss.

Nur die Versionsnummer, oder?

Ich bin ja ein "Neu-OpenBSD'ler" und mach' das erst "seit" 5.5 mit, aber sämtliche Snapshot-Updates haben bisher so funktioniert. Möglicherweise habe ich aber irgendwas übersehen.

(Mir persönlich ist es zu viel Aufwand, mich für ein Update von 5.5 auf 5.5 :D jedes Mal durch ein Installationsprogramm zu "klicken".)
 
Vor nicht allzu langer Zeit (während 5.4-current) war die Umstellung auf 64-bit time_t, bei der du dir dein System mit dieser Methode vom Feinsten zerschossen hättest. Nicht alles, was einfacher ist, ergibt auch Sinn. Das ist kein unterstützer Upgradepfad vom OpenBSD-Projekt, was du spätestens dann merkst, dass sich auf der Mailingliste oder hier kein Mensch für dein Problem interessiert. Wenn du das Update automatisieren willst, dann gibt es dafür autoinstall(8), wobei dafür aber bisher noch eine zweite Maschine benötigt wird, die als DHCP/TFTP/HTTP-Server fungiert.
 
Zugegebenermaßen kommt sowas nicht allzu oft vor, aber das sind die Dinge die dann Aufmerksamkeit erfordern, ob denn noch alles im script so stimmt und angewendet werden kann. Lies dir am besten mal die Anleitung zum update von 5.4 auf 5.5 durch, da steht was man alles per Hand machen muss (und dass es nicht der empfohlene Weg ist): http://www.openbsd.org/faq/upgrade55.html#upgrade. Es ist möglich, aber deutlich fehleranfälliger als ein update per bsd.rd und nicht supported.
 
Stimmt schon, das kommt selten vor, aber es kommt halt vor. Fairerweise muss man auch sagen, dass dieser Fall schon ein krasser war und jeder, unabhängig vom Upgradepfad, Nacharbeiten zu erledigen hatte. Denke aber, Crimson hätte sich da mit dieser Methode erstrecht keinen Gefallen getan.
Ich finde das Upgrade per bsd.rd hingegen richtig entspannend. Ich weiß, da läuft alles im RAM, die Platten wurden gesynct und fsck'd, die Sets verifiziert und installiert, alles ohne, dass mein eigentliches System währenddessen läuft. Benutze auch so ein Script, dass die Dateien vorher loker aktualisiert und habe erst vorgestern gedacht, dass die ganze Prozedur inkl. sysmerge mittlerweile so schnell läuft, dass der Spaß schon zu Ende ist, bevor er überhaupt richtig angefangen hat.
 
Die "alte" bsd.rd" lädt alle benötigten Dateien aus dem snapshot-Verzeichnis runter incl. der "neuen bsd.rd" und verifiziert sie.
Ich habe das bis vor ein paar Monaten auch noch so gehandhabt, bis ich den Fall auf einem Laptop hatte (länger kein Upgrade), dass die (veraltete) bsd.rd _nur_ die neue bsd.rd geladen hat und einen Reboot mit der neuen bsd.rd erforderte. Oder ist das mittlerweile anders? Zwei Reboots waren dann sogar mir zu nervig, daher bin ich dazu übergegangen, diese auch direkt lokal zu aktualisieren.
 
Ich hab dafür ein Skript erstellt, dass die nötigen Dateien runterläd, die checksums prüft und dann nach / kopiert, sodass du nur von /bsd.rd booten und updaten musst (von 'disk'): https://bitbucket.org/drm00/bin/src...522fe9636a4aee6/update_snapshot.sh?at=default

Ich hab' dein Skript (die aktuelle Version) heute mal getestet. Funktioniert. Vielleicht wäre aber eine Statusmitteilung zwischendrin noch gut, damit der Benutzer weiß, was es gerade tut. :)
 
Zurück
Oben