current - release - stable: bin immer noch unsicher

[pit234a]

Also, laßt es mich mal so zu beschreiben:
Wenn ich ein gutes System am Laufen habe, fahre ich nur selten noch Updates, es sei denn, dies wird nötig, weil ich etwas Neues brauche. Vor einigen Wochen ließ ich mir ein Free-BSD 7.0 BETA2 bauen. Und zwar, aus einem Bootonly und mit angepasstem Kernel und zahlreichen Programmen, X11, KDE, OpenOffice und noch viel mehr. In mein ENVIRONMENT nahm ich dies:
ftp://ftp.freebsd.ch/pub/FreeBSD/ports/amd64/packages-7-current/Latest/

Seither habe ich gelegentliche Updates laufen lassen, einige Male portupgrade -a.
Wie ist dies denn nun eigentlich?
Dieses current wurde ja inzwischen BETA3, BETA4 und nun wohl RC1, oder? Bedeutet dies, daß mein System nun eigentlich dem letzten Stand, also dem aktuellen entspricht, also gar kein BETA2 mehr darstellt, sondern eine RC1?
Sollte ich nun zu release in meinem ENVIRONMENT wechseln, statt current, weil ich auf der entsprechenden Seite sehe, dass dort neuere Einträge vorhanden sind?
Und was ist eigentlich mit meinem Kernel? Kann ich den bedenkenlos beibehalten, also in der angepaßten Version, oder braucht der auch eine Auffrischung und muss ich den dann wieder neu bauen lassen?

Wenn ich nun mein System fleißig mit portupgrade aktuell halte, brauche ich dann diese Prozeduren mit make world und buildkernel dann, wenn ich eine neure Version, also etwa einen Wechsel von 6 nach 7 machen will, aber innerhalb einer Version eigentlich gar nicht? Trotz Wiki habe ich die nämlich noch nicht verstanden, bzw, falsch verstanden, denn sie funktionierten nicht bei mir, als ich mal einen Kernel updaten wollte.

Sicher können eure Belehrungen mich weiter bringen, als die bisherige Lektüre.

 

[Yamagi]

Also:
FreeBSD hat - anders als Linux - das System das Paketmanagement klar getrennt. Einmal haben wir das System, dies ist das, was du bekommst, wenn du die "minimal" Option beim Installieren wählst. Es besteht aus dem Kernel und einem mehr oder minder POSIX-Konformen Userland und lebt in / und /usr. Konfuguriert wird es in /etc.
Dann haben wir die Ports, das Paketmanagement. Dies hat mit dem System an sich nichts zu tun, der Portsbaum lebt in /usr/ports und (fast) alles was du über sie installierst landet in /usr/local. Konfiguriert werden über die Ports installierte Dinge in /usr/local/etc.

Nun zu deiner Frage. Das System ist also von den Ports entkoppelt. Das System kennt Versionen. -CURRENT ist die Entwicklerversion. Alle 3 bis 4 Jahre wird aus dieser eine neuer Zweig ausgekoppelt, aus denen die Releases hervorgehen. Dies ist -STABLE. -STABLE, da die Abi stabil ist. Dies bedeutet, dass du jedes Paket was unter einem 6.x gebaut wurde auch unter jedem anderen 6.x nutzen kannst. Nun wird etwas jedes dreiviertel Jahr -STABLE erst zu -PRERELEASE, dann -BETA1, -BETA2, -BETA3... Dies sind nur Namen und haben nichts mit dem Zweig, in welchem du bist, zu tun. Um weniger zu verwirren sagt man daher auch oftmals nicht, dass man 7.0-BETA1 oder 7.0-BETA2 nutzt, man sagt, man nutze RELENG_7. Da RELENG_7 der aktuelle -STABLE Zweig ist.
Nach dem die Betas durch sind, entkoppelt man wieder. Man nimmt RELENG_7 und legt einen neuen Zweig aus diesem heraus an, der das kommende Release beinhaltet. dies ist dann RELENG_7_0. Aus diesem Zweig kommen erst die Release Candidates, aktuell also RC1. Auch RC2 wird aus diesem kommen. Schließlich wird dieser Zweig zu 7.0-RELEASE. Hiernach werden in den Zweig RELENG_7_0 nur noch Sicherheitslücken geflickt werden. RELENG_7 wird dann 7.0-STABLE heißen und auf 7.1 zulaufen, welches irgendwann in ferner Zukunft wieder einen eigene Zweig RELENG_7_1 darstellen wird.

Ports kennen keine Zweige und Zeitpunkte. Wenn du ein 7.0-BETA1 hast und die Ports vom Dezember installiert hast, hast du ein 7.0-BETA1. Wenn du jetzt am 20. Januar deine Ports aktualisierst, hast du ein 7.0-BETA1 mit den Ports vom 20. Januar. Du kannst genauso gut ein 6.3-RELEASE mit Ports vom 20. Januar haben oder ein 5.5-BETA2. Ports haben mit den Versionen des Basissystems nichts zu tun.

Nun kommt - zur Verwirrung - die Einschränkung: Bevor ein -RELEASE kommt, werden die Ports einige Wochen eingefrohren, um Probleme zu beseitigen. Am Ende dieser Frostperiode, werden die Ports getagt. Dieser Tag ist nur ein Schild, eine Name und nicht mehr. Er sagt nur aus "Dies ist der Portstree, aus dem wir die Pakete gebaut haben, die 7.0-RELEASE beiligen". Die kannst den Portstree mit dem Schild "7.0" auch auf deinem 5.5-BETA2 verwenden. Es ist nur ein Name, genauso wie "Ports vom 25. Januar".

Das zieht nun natürlich nach sich, dass du Buildworld und Buildkernel immer dann machen musst, wenn du dein System (nicht die Ports) aktualisieren möchtest. Also wenn du auf RC1 möchtest, wirst du dies tun müssen. Ebenso, wenn du irgendwann auf 7.1 gehen wirst. Du musst es aber nicht machen, um deine Ports zu aktualisieren. Dadurch änderst du an der Version deines Systems nichts.

Ach ja, wenn du schon -BETA2 hast, kannst du mit dem beiligenden freebsd-update ein Binärupgrade auf -RC1 machen

 

[pit234a]

Da danke ich mal ausdrücklich, gut, daß ich gefragt habe!
Alles verstanden habe ich aber noch nicht, muß ich wohl wieder fragen und vor allem, nochmal lesen.

Zunächst dies, zum Test, ob ich verstanden habe: dieses Konzept, dass Kernel und UNIX als einheitliches System kommen und zusammen Free-BSD sind, hat auch seine Vorteile. Dass dies so ist, bedeutet für mich aber auch, daß ich gar nicht recht abschätzen kann, was da nun eigentlich in einer neueren Version für Vorteile enthalten sein könnten. Derzeit bekomme ich das SATA-DVD-Laufwerk nicht zum Laufen, irgendwo habe ich gelesen, bei Free-BSD 8 sei das möglich. Ich kann also nicht einen Kernel-Patch finden oder einen neueren Kernel, den ich meinem UNIX unterstelle, sondern muß einen Versionswechsel durchführen.
Andererseits gibt es wohl kaum einen Grund, jemals einen Versionswechsel herbeizuführen, wenn alle Hardware sauber erkannt und angesprochen wird. Wenigstens, für solche grafisch fixierten Menschen wie mich, die also eh jede Menge GUIs und Fenstermanager einsetzen, sich nie wirklich auf der Kommandozeile austoben. Das erscheint mir schon sehr vernünftig so. Trotzdem gibt es auch einige Probleme mit Programmen, die nun nicht laufen und auf früheren Versionen von BSD funktionieren. Es muss sich also irgendwas im System verändert haben, das diese Programme nicht mögen. Entweder müssten sie ganz umgeschrieben werden oder die Ports dann doch für die neuere Version angepaßt oder die neue Version in einer späteren Entwicklung dann wieder der alten angepaßt werden, was ja dann am ehesten zutreffen wird, wenn ich das alles recht deute.

Also, am Besten schlafe ich vielleicht nochmal drüber.
Ah,

Ach ja, wenn du schon -BETA2 hast, kannst du mit dem beiligenden freebsd-update ein Binärupgrade auf -RC1 machen

wo ist denn das beigepackt?

 

[keydex]

wo ist denn das beigepackt?

# freebsd-update fetch && install

 

[Yamagi]

Naja, es ist die alte Frage, was man machen möchte. Alles ein Paket wie Linux es macht oder monolitisch wie FreeBSD oder Windows. Jetztendlich hat beides seine Vorteile. ALles ein Paket erlaubt mehr Eingriffe seitens des Nutzers in die verwendeten Versionen und man kann eher entscheiden was man brauch oder was man nicht möchte. Man kann aber auch schnell in die Versionsfalle laufen. Du aktualisiert Paket A und haust dabei Abhängigkeiten auf C und D durch... Jetztendlich kann man diese Diskussion ob der monolitische Ansatz oder ob alles ein Pakt ist besser sei endlos führen.
Aber es stimmt, du musst bei FreeBSD ein Systemupdate machen, wenn du Änderungen am Kernel möchtest. Außer du extrahierst die Änderung und fügst sie manuell wieder in dein vorhandenes System ein. Das ist aber Gefrickel und sollte nicht gemacht werden, außer es geht nichts anders.

Was die Ports betrifft, ist es so eine Sache. Eigentlich unterstützen die Ports alle FreeBSD-Versionen, die auch vom Sicherheitsteam gewartet werden. Das sind im Moment:
- 5.5
- 6.2
- 6.3
Als Nebeneffekt der stabilen ABI laufen die Ports aber auf allen Versionen des Zweiges, also gibt es aktuelle Ports für 5.0 bis 7.0-RC1. Wenn jetzt im Mai aber 5.5 das Ende seines Lebens erreicht, stirbt damit die Unterstützung für FreeBSD 5.x und alle werden alte Versionen nehmen müssen oder aktualisieren.
Das ist die Theorie. In der Praxis werden ältere Zweige deutlich schlechter unterstützt als aktuelle. So knallte es in letzter Zeit unter 5.x gerne mal, wo 6.x sauber lief. Dies liegt daran, dass viele Maintainer der Ports - imo Verständlicherweise - nicht mehr so viel Energie invetsieren.

 

[Yamagi]

So, nun zu den anderen beiden Fragen:

- S-ATA Laufwerke die keine Festplatten waren, hatten unter den Betas noch Probleme. Dies soll im RC1 behoben worden sein. Ob es stimmt kann ich mangels Hardware nicht sagen.

- Das Binärupdate müsste mit

freebsd-update -r 7.0-RC1 fetch
freebsd-update -r 7.0-RC1 upgrade

gehen. Ich habe es jetzt aber nur aus dem Gedächnis geschrieben und noch nie selbst gemacht, also vielleicht noch ein wenig dazu googlen

 

[pit234a]

Ich danke mal wieder für die gezeigten Lösungsansätze und einhergehenden Erklärungen. Leider bin ich derzeit so belastet wie üblich und kann mich meines eigenen Problems nicht wirklich widmen.

# freebsd-update fetch && install
macht was, doch das kann wohl nicht ein kompleter update zu neuer Release-Version sein? Das geht so schnell... uname -a zeigt auch keinen Wechsel an.

http://www.freebsd.org/cgi/man.cgi?...ktion=8&apropos=0&manpath=FreeBSD+7.0-RELEASE
erklärt die Option -r, allerdings gilt die nicht bei mir, da wird -r einfach verweigert.
Deshalb versuchte ich in der /etc/freebsd-update.conf den Server zu verändern, da stand etwas, wie update.free-bsd oder ähnlich und ich setzte da mal
ServerName ftp://ftp.freebsd.ch/pub/FreeBSD/releases/amd64/7.0-RC1
und das verweigert sich auch, ebenfalls mit leichten Änderungen dieses Server-Namens. Doch ich denke, das es mit der passenden Adresse hier was werden könnte?

Für Hilfe bin ich dankbar.

 

[mousaka]

# freebsd-update fetch && install
macht was, doch das kann wohl nicht ein kompleter update zu neuer Release-Version sein? Das geht so schnell... uname -a zeigt auch keinen Wechsel an.

Lies mal im Blog von Colin Percival, da steht wie du freebsd-update verwenden kannst um ein Upgrade deines Systems durchzuführen.
Die man-Page zu freebsd-update hilft sicher auch weiter.
Merkwürdigerweis sind die Optionen -r und upgrade nur in 7.0 vorhanden, eigentlich sollten sie auch in den man-Pages zu 6.3 enthalten sein.

mousaka

 

[pit234a]

etwas ähnliches habe ich dazu auch schon gefunden und es läuft scheinbar darauf hinaus, daß ich dieses script nutzen muß, das dort erwähnt wird.
Stattdessen erhielt ich nämlich diese Medlung, als ich den Port bauen lassen wollte:
===> freebsd-update not installed, skipping
===> freebsd-update-1.6_2 is now contained in the base system.
*** Error code 1

Stop in /usr/ports/security/freebsd-update.

Deshalb wollte ich dieses im base System enthaltene direkt nutzen und es kann auch aufgerufen werden, kennt eben aber nicht die Option -r, sondern scheint stets nur Patches in die installierte Version einzuspielen. Weil es auf dem Server update.FreeBSD.org nachschaut, den ich allerdings nicht so direkt finden kann, dachte ich, die fehlende Option dadurch zu umgehen, daß ich ein direktes Ziel mit den neuen Sourcen angeben könnte.
Meine 7er ist BETA2 und sie soll damit nun RC1 werden.

 

[pit234a]

habe mir das Script des base-Systems angesehen und dort wird ein Server-Such Verzeichnis gebildet und mit uname -r gesetzt, somit bleiben updates also immer innerhalb der installierten Version.
Nun änderte ich uname -r mal in 7.0-RC1 und das wurde nicht gefunden.
Ich denke aber, mit einem passenden Namen würde das so laufen.

 

[mousaka]

Mach mal langsam und bewahre einen kühlen Kopf.

===> freebsd-update not installed, skipping
===> freebsd-update-1.6_2 is now contained in the base system.
*** Error code 1

Stop in /usr/ports/security/freebsd-update.

Das sagt dir, dass freebsd-update im Basis-System vorhanden ist. Wenn ich richtig liege, ist dies erst seit Versionen 6.x der Fall, darum gibts freebsd-update für 5.x auch noch in den Ports.

Für freebsd-update musst du nicht mit uname -r den Namen wechseln.
An freebsd-update.conf brauchst du in der Regel auch nichts zu ändern.

Eine Einschränkung hat freebsd-update allerdings: Damit lässt sich nur der Standard-Kernel (genannt GENERIC) oder die SMP-Variante davon aktualisieren.
Es werden ja fertig kompilierte Dateien installiert, und bei einem customized Kernel geht das ja nicht, da niemand deine Optionen kennt.

Vor einigen Wochen ließ ich mir ein Free-BSD 7.0 BETA2 bauen. Und zwar, aus einem Bootonly und mit angepasstem Kernel und zahlreichen Programmen, X11, KDE, OpenOffice und noch viel mehr.

Dann wird wohl nichts damit.

Jetzt hast du zwei Varianten:

• Selber kompilieren (make buildworld, ...)
• Den GENERIC-Kernel verwenden und dann updaten.

Nach der zweiten Variante, kannst du trotzdem wieder einen eigenen Kernel verwenden, musst einfach jeweils für ein Update mittels freebsd-update den GENERIC-Kernel verwenden.

Ich persönlich bleibe bei meinem Desktop-Kisten meist gerade bei GENERIC, auch wenn das schon recht unkühl ist.

mousaka

 

[pit234a]

Ja, ich hatte mir vorgestellt, dass einfach neue Quellen geladen würden und dann benutzt werden, wenn ich meinen Kernel neu mache, was ich nämlich ohnehin vorhabe, um noch fehlende Optionen hinzuzunehmen.
Ich könnte auch auf den GENERIC wechseln und dann wieder den neuen bauen, das ist kein Umstand für mich.

Ja, das hatte ich auch verstanden, daß dieses update script nun zum Base-System gehört und also vorhanden ist, nur daß es offensichtlich nicht mit den Beschreibungen der man-Page übereinstimmt. Es existiert kein -r und vielleicht gibt es erst in der RC1 eine Verbesserung, die ich aber halt nicht habe.
Nun habe ich mal das Script unabhängig geladen und will es mir mal ansehen.
Demnächst, nun bin ich noch beschäftigt.

Und make buildworld habe ich wohl noch immer nicht verstanden, ich gebe es zu. Jedenfalls klappte es bei mir nicht. Deshalb gefiel mir die hier genannte Alternative ja auch auf Anhieb, besonders, weil ich ja derzeit nur kleinere Updates mache und keine großen versionssprünge möchte.

 

[mousaka]

Ja, das hatte ich auch verstanden, daß dieses update script nun zum Base-System gehört und also vorhanden ist, nur daß es offensichtlich nicht mit den Beschreibungen der man-Page übereinstimmt. Es existiert kein -r und vielleicht gibt es erst in der RC1 eine Verbesserung, die ich aber halt nicht habe.

Die Option ist erst mit 7.0 dazugekommen, sollte aber bei BETA1 sicher dabei sein. Wenn du aber von 6.x auf 7 upgraden willst, dann muss man zuerst die neue Version von freebsd-update installieren. Siehe im oben erwähnten Blog unte Major Version updates.

Und make buildworld habe ich wohl noch immer nicht verstanden, ich gebe es zu. Jedenfalls klappte es bei mir nicht. Deshalb gefiel mir die hier genannte Alternative ja auch auf Anhieb, besonders, weil ich ja derzeit nur kleinere Updates mache und keine großen versionssprünge möchte.

Kann es sein, dass dein Update auf -BETA2 nicht wirklich korrekt war und darum z.B. freebsd-update auch nicht die Option -r kennt?
uname -a sollte dir da mehr sagen.

Lies doch im Wiki den Artikel zum make world.

mousaka

 

[pit234a]

habe nun doch mal in das system-unabhängige script geschaut und eindeutig, hier ist die Option -r eingebaut.
Ob ich nun wie im Blog beschrieben vorgehe, oder einfach das System-integrierte update durch das mit -r ersetze, wird vermutlich gleich bleiben.

Derzeit kann ich es eh noch nicht probieren, das System läuft gerade noch mit portupgrade.

 

[pit234a]

Die Option ist erst mit 7.0 dazugekommen, sollte aber bei BETA1 sicher dabei sein. Wenn du aber von 6.x auf 7 upgraden willst, dann muss man zuerst die neue Version von freebsd-update installieren. Siehe im oben erwähnten Blog unte Major Version updates.


Kann es sein, dass dein Update auf -BETA2 nicht wirklich korrekt war und darum z.B. freebsd-update auch nicht die Option -r kennt?
uname -a sollte dir da mehr sagen.

Lies doch im Wiki den Artikel zum make world.

mousaka

nein, dieses System hatte ich neu aus der bootonly als 7-Beta2 installiert und es sollte also in Ordnung sein, ist aber eindeutig an diesem Punkt nicht wie beschrieben. Ich zeige es mal nur kurz in der Einleitung der scripte:
hier aus dem integrierten:
Options:
-b basedir -- Operate on a system mounted at basedir
(default: /)
-d workdir -- Store working files in workdir
(default: /var/db/freebsd-update/)
-f conffile -- Read configuration options from conffile
(default: /etc/freebsd-update.conf)
-k KEY -- Trust an RSA key with SHA256 hash of KEY
-s server -- Server from which to fetch updates
(default: update.FreeBSD.org)
-t address -- Mail output of cron command, if any, to address
(default: root)
Commands:
fetch -- Fetch updates from server
cron -- Sleep rand(3600) seconds, fetch updates, and send an
email if updates were found
install -- Install downloaded updates
rollback -- Uninstall most recently installed updates


und aus dem unabhängigen:
Options:
-b basedir -- Operate on a system mounted at basedir
(default: /)
-d workdir -- Store working files in workdir
(default: /var/db/freebsd-update/)
-f conffile -- Read configuration options from conffile
(default: /etc/freebsd-update.conf)
-k KEY -- Trust an RSA key with SHA256 hash of KEY
-r release -- Target for upgrade (e.g., 6.2-RELEASE)
-s server -- Server from which to fetch updates
(default: update.FreeBSD.org)
-t address -- Mail output of cron command, if any, to address
(default: root)
Commands:
fetch -- Fetch updates from server
cron -- Sleep rand(3600) seconds, fetch updates, and send an
email if updates were found
upgrade -- Fetch upgrades to FreeBSD version specified via -r option
install -- Install downloaded updates or upgrades
rollback -- Uninstall most recently installed updates


das ist eindeutig anders.

 

[mousaka]

Ich habe mich getäuscht. Die Option -r ist erst ab RC1 verfügbar:

If you are running FreeBSD 7.0-RC1 or FreeBSD 6.3-RC1 or later, you should already have this new version of FreeBSD Update installed, so you can skip this step.

Ob ich nun wie im Blog beschrieben vorgehe, oder einfach das System-integrierte update durch das mit -r ersetze, wird vermutlich gleich bleiben.

Bei einem Upgrade wird freebsd-update mit ersetzt (und kennt dann -r), da es ja zum Basis-System gehört. Also kannst du dir den Aufwand sparen, das "system-integrierte" zu akualisieren.

mousaka

 

[Yamagi]

Erst im RC1? Das wusste ich nicht, aber trotzdem Sorry, dass ich euch auf den falschen Weg geschrieben habe