uname -r und freebsd-update

[peterle]

Mir ist aufgefallen, daß mein Testsystem einen anderen Output für uname -r zeigt als die normalen Systeme.

std# uname -r
8.2-RELEASE-p3

test# uname -r
8.2-RELEASE


Nun mahnt freebsd-update auf test ein upadte auf p4 an, aber nicht auf std.
Welche Einstellung ist denn dafür verantwortlich und was ist vermutlich schief gelaufen?

 

[Yamagi]

Die Sache ist ein wenig dumm... Die Ausgabe von "uname" stammt aus dem Kernel und ist fest in den einkompiliert. Das bedeutet, dass du nur dann die korrekte Ausgabe bekommst, wenn der Kernel die korrekte Version beinhaltet. Nun ändert freebsd-update aber nur die Dateien, die wirklich aktualisiert werden müssen. Mal als Beispiel:
1) Du hast FreeBSD 8.2-RELEASE und ein Loch in /bin/sh.
2) Das Loch wird geschlossen, FreeBSD 8.2-RELEASE-p1 wird dadurch aktuell.
3) freebsd-update erkennt den Patch und aktualisiert /bin/sh auf die aktuelle Version.
4) Du hast nun 8.2-RELEASE-p1, dein "uname" sagt aber weiterhin 8.2-RELEASE da /boot/kernel/kernel nicht aktualisiert wurde.
Ich sage mal ganz ehrlich, dass mich das tierisch nervt. Es müsste eine andere Möglichkeit geben die Systemindentifikation zu ändern als den Kernel neuzubauen. uname kann man z.B. auch eine andere Ausgabe per Umgebungsvariablen unterschieben, also könnte man vielleicht daraus was basteln...

 

[peterle]

Also ich habe defintiv keinen neuen Kernel gebaut. Auf keiner Maschine.
Kann das denn vielleicht mit einem Reboot zusammenhängen?

 

[Wiedmann]

4) Du hast nun 8.2-RELEASE-p1, dein "uname" sagt aber weiterhin 8.2-RELEASE da /boot/kernel/kernel nicht aktualisiert wurde.
Ich sage mal ganz ehrlich, dass mich das tierisch nervt. Es müsste eine andere Möglichkeit geben die Systemindentifikation zu ändern als den Kernel neuzubauen. uname kann man z.B. auch eine andere Ausgabe per Umgebungsvariablen unterschieben, also könnte man vielleicht daraus was basteln...

In die cshrc (analog in profile) könnte man z.B. das reintun:

setenv UNAME_r `cut -f 3 -d '|' /var/db/freebsd-update/tag`-p`cut -f 4 -d '|' /var/db/freebsd-update/tag`

Allerdings muss man auch noch nach jedem "freebsd-update"-Lauf die Rechte für "/var/db/freebsd-update" von 700 auf 755 anpassen.

UNAME_v anzupassen lass ich da außen vor, da man so noch schön sieht wie der Kernel gebaut wurde.

 

[lme]

In die cshrc (analog in profile) könnte man z.B. das reintun:

setenv UNAME_r `cut -f 3 -d '|' /var/db/freebsd-update/tag`-p`cut -f 4 -d '|' /var/db/freebsd-update/tag`

Allerdings muss man auch noch nach jedem "freebsd-update"-Lauf die Rechte für "/var/db/freebsd-update" von 700 auf 755 anpassen.

UNAME_v anzupassen lass ich da außen vor, da man so noch schön sieht wie der Kernel gebaut wurde.

Das funktioniert nur, wenn man mal freebsd-update benutzt hat.

 

[Wiedmann]

Das funktioniert nur, wenn man mal freebsd-update benutzt hat.

Darum geht's hier im Thread (bzw. dem OP) doch?

Über z.B. CVSup aktualisiert hätte man ja auch einen neuen Kernel der gleich z.B. aktuell "-p4" ausgibt. Nur bei "freebsd-update" ist ja das "System" z.B. auf p4, der Kernel wurde dabei aber nicht (binär) aktualisiert und gibt z.B. -p3 oder keinen Patchlevel aus.

 

[peterle]

Darum geht's hier im Thread (bzw. dem OP) doch?

Über z.B. CVSup aktualisiert hätte man ja auch einen neuen Kernel der gleich z.B. aktuell "-p4" ausgibt. Nur bei "freebsd-update" ist ja das "System" z.B. auf p4, der Kernel wurde dabei aber nicht (binär) aktualisiert und gibt z.B. -p3 oder keinen Patchlevel aus.

Was mich eben wundert, da ich eigentlich alles System gleich behandele. Mache ich auf dem Testsystem das Update problemlos, müssen alle dran glauben.
Wieso geben die dann aber unterschiedliches aus?

 

[peterle]

Ei schau mal da ... ein reboot von Test und schon zeigt

test# uname -r
8.2-RELEASE-p3

[Spock]
Interessant
{/Spock]