• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

freebsd-update und /src/sys

ed1949

Well-Known Member
Themenstarter #1
Hallo,

nachdem ich beim Upgrade von 10.1 auf 10.2 schon wieder kein Update der src/sys Information hinbekommen habe, wollte ich mal fragen, was die Voraussetzungen sind, damit das funktioniert. Ich möchte in /usr/src/ nur das haben, was ich benötige, damit die Kernel Sourcen aktuelle bleiben. Der Kernel ist Custom, das System Binary und so sollte das auch bleiben.

Das steht in der freebsd-update.conf:
Code:
Components src/base src/sys world/base
Das bring der Upgrade Aufruf:
Code:
The following components of FreeBSD seem to be installed:
world/base
Und so sieht /usr/src/ aus:
Code:
# la /usr/src/
total 500
drwxr-xr-x  5 root  wheel  512 Nov 14  2014 .
drwxr-xr-x  14 root  wheel  512 Nov 14  2014 ..
-rw-r--r--  1 root  wheel  6198 Nov 11  2014 COPYRIGHT
-rw-r--r--  1 root  wheel  741 Nov 11  2014 LOCKS
-rw-r--r--  1 root  wheel  6329 Nov 11  2014 MAINTAINERS
-rw-r--r--  1 root  wheel  19509 Nov 11  2014 Makefile
-rw-r--r--  1 root  wheel  62642 Nov 11  2014 Makefile.inc1
-rw-r--r--  1 root  wheel  287030 Nov 11  2014 ObsoleteFiles.inc
-rw-r--r--  1 root  wheel  3174 Nov 11  2014 README
-rw-r--r--  1 root  wheel  89197 Nov 11  2014 UPDATING
drwxr-xr-x  25 root  wheel  2048 Nov 11  2014 etc
drwxr-xr-x  14 root  wheel  512 Nov 11  2014 release
drwxr-xr-x  57 root  wheel  1024 Nov 11  2014 sys
 

pit234a

Well-Known Member
#2
neuere Versionen von freebsd-update kenne ich zwar nicht, aber eigentlich ist das nur als Tool für die Erneuerung des Basis-Systems mit Standard Kernel gedacht.
Es ist ja eine Art Binär-Update des Basis-Systems und da stelle ich mir einen eigenen Kernel nicht einfach zu realisieren vor, weil dafür ja binär keine Vorlagen existieren und ich mir nicht vorstellen kann, dass der Kernel in einzelne Sektionen beliebig zerpflückt und dann individuell zusammen gestellt werden kann.
Deshalb denke ich mir, dass diese Probleme durch den nicht-GENERIC verursacht sein können. Falls ich dich richtig verstanden habe.
Mit einem eigenen Kernel muss man die Sourcen manuell abholen und jeweils von Hand diesen neu bauen. Bei FreeBSD bedeutet das ja bei einer neuen Version nicht nur den Kernel, sondern auch das Basis-System neu zu bauen. Es gibt ja nicht eines alleine. Für mich war das Grund genug, keinen eigenen Kernel mehr zu verwenden und ich sehe darin auch keinerlei Nachteile.
 

ed1949

Well-Known Member
Themenstarter #3
Ich halte es auf dem Server für einen Vorteil, wenn der Kernel genau den Leistungsumfang hat, den der Server benötigt. Zusätzliche Angriffspunkte durch Kernel Module können dann nicht entstehen. Ausserdem fehlt im Standard-Kernel ALTQ. Damit funktioniert mit GENERIC meine PF Konfiguration nicht vollständig.

Gibt es Alternativ ein SVN/CVS/GIT/... womit man nur den oben angegebenen Umfang der Sourcen passend zum entsprechenden Release-Stand aktuell halten kann?
 

zuglufttier

Well-Known Member
#4
Wenn du freebsd-update verwenden möchtest, solltest du auch den GENERIC Kernel verwenden. Sonst musst du eben einfach das Userland und Kernel von Hand bauen, das ist ja im Handbuch gut beschrieben. Dann ziehst du dir einfach hin und wieder mal aktuellen Quellen und gut ist, siehe hier: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html

Wenn du mit PF nicht gerade QOS machen willst, kannst du auch ohne Probleme den GENERIC Kernel benutzen.
 

pit234a

Well-Known Member
#5
wahrscheinlich verstehe ich das sowieso nicht wirklich. Aber der Kernel wird bei FreeBSD mit passenden Modulen zusammen ausgeliefert, es gibt keine Module, die dir da irgendjemand unterjubeln könnte. Es gibt sogar eine Prüfung, die beschränkt sich wohl nur auf die Version, aber immerhin. So einfach irgendein Modul unterjubeln und es dann auch noch starten, kann jemand wohl nicht und schon gar nicht von außen. Zudem können ja auch einfach von den vorhanden Modulen jene gelöscht werden, von denen man annimmt, dass man sie niemals brauchen wird. Im Grunde ist das aber eher unnötig, da sie ja eben nicht von sich aus geladen werden.
Den benötigten Modulen muss man letztlich auch vertrauen.
 

ed1949

Well-Known Member
Themenstarter #6
Dann ziehst du dir einfach hin und wieder mal aktuellen Quellen und gut ist, siehe hier: https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/subversion-primer.html

Wenn du mit PF nicht gerade QOS machen willst, kannst du auch ohne Probleme den GENERIC Kernel benutzen.
Ich mache QoS mit PF (option ALTQ).

Wenn ich die Seite richtig verstanden habe, benötige ich für die 10.2 den Subversion Branch /releng/10.2. D.h. die src Einträge in der freebsd-update.conf sind ohne Funktion oder würden diese funktionieren, wenn ich den gesammten src/sys bzw. src/base Baum vorhalte? Falls ja, was gehört in diesem Fall zu src/sys?
 

zuglufttier

Well-Known Member
#7
In jedem Fall solltest du dann überhaupt nicht freebsd-update benutzen! Die Datei freebsd-update.conf kannst du dann ignorieren.

Ich würde so vergehen, um einen aktuellen Stand zu haben:

- /usr/src komplett löschen
- neue Sourcen via SVN nach /usr/src holen
- Kernel und Userland, also was da als World beschrieben wird, komplett neu bauen, siehe https://www.freebsd.org/doc/handbook/makeworld.html

Danach sollte alles auf aktuellem Stand sein. releng/10.2 sollte das sein was du möchtest aber du könntest auch stable verfolgen, je nachdem was dir am liebsten ist.
 

ed1949

Well-Known Member
Themenstarter #8
Das Userland möchte ich auf dem Server auf keinen Fall bauen. Ich überlege gerade, ob es sinnvoll sein könnte die Kernelbuilds und damit die Sourcen vom Server in eine VM zu verlagern und die fertig gebauten Kernel auf den Server zu schieben, wenn man die Kernel-Sourcen nicht vernünftig eigenständig aktuell halten kann. Verursacht halt zusätzliche Arbeit bei der Verwaltung, da der Zugang kompliziert und aufwändig ist.
 

zuglufttier

Well-Known Member
#9
Das würde ich nicht machen, glaube ich... Denn so bekommst du ja einen neuen Kernel aber das Userland bleibt alt. Hm... Wenn du das innerhalb von releng machst, funktioniert das sicherlich aber du bekommst ja keine Sicherheitsupates für den Rest.
 

ed1949

Well-Known Member
Themenstarter #10
Die Updates für das Userland funktionieren aber doch per freebsd-update. Das sollte weiterhin funktionieren, auch wenn ich den Kernel extern baue und nur auf den Server kopiere.
 

ed1949

Well-Known Member
Themenstarter #12
- /usr/src komplett löschen
- neue Sourcen via SVN nach /usr/src holen
Nachdem ich das Thema immer wieder nach hinten geschoben hatte, ist das Fass nun endlich übergelaufen. Ich werde zwar weiterhin freebsd-update und pkg upgrade nutzen, hole mir aber zusätzliche die aktuellen Kernel Quellen:

Code:
#!/bin/sh

set -e

tp=/usr/src

if [ ! -d ${tp}/.svn ]; then
  svnlite co --depth files https://svn.FreeBSD.org/base/releng/10.2 ${tp}
  svnlite up ${tp}/etc
  svnlite up ${tp}/release
  svnlite up ${tp}/sys
else
  svnlite up ${tp}
fi
Ich hoffe ich erwische damit die aktuellen Security Patches für mein Release.
 

ed1949

Well-Known Member
Themenstarter #15
Für die 11.0 mußte ich mein SVN Script erweitern, da nun /usr/src/share/mk/bsd.sys.mk bei Build benötig wird.

Code:
#!/bin/sh

set -e

tp=/usr/src

if [ ! -d ${tp}/.svn ]; then
  svnlite co --depth files https://svn.FreeBSD.org/base/releng/11.0 ${tp}
  svnlite up ${tp}/etc
  svnlite up ${tp}/release
  svnlite up ${tp}/sys
  svnlite up ${tp}/share
else
  svnlite up ${tp}
fi
Außerdem sollte, wenn ich das Handbuch und die Dokumentation richtig verstehe, ein Kernel in /boot/GENERIC/ beim freebsd-update auf den neuesten Stand gebracht werden und mein Custom Kernel erhalten bleiben. Leider wird immer mein Custom Kernel ersetzt und GENERIC bleibt erhalten. Kennt jemand einen Trick, um freebsd-update dazu zu bringen GENERIC statt kernel auf den aktuellen Stand zu bringen?

Hier der Auszug aus meiner /etc/freebsd-update.conf:
Code:
Components world/base kernel
 
#16
Ich hab auch einen custom Kernel. Sobald freebsd-update Handlungsbedarf meldet, passiert vereinfacht bei mir folgendes:
1. /boot/kernel wird gesichert,
2. /boot/kernel.GENERIC nach /boot.kernel
3. Das update gemacht
4. /boot/kernel wieder nach /boot/kernel.GENERIC gesichert
5. Mein custom Kernel neu gebaut. Dank MODULES_OVERRIDE eine Angelegenheit von 3 min---freebsd-update braucht meist länger :)

W
 

ed1949

Well-Known Member
Themenstarter #17
Seit ich das weiss, mache ich das ähnlich und habe meinen kernel immer als Kopie in kernel.saved. Trotzdem könnte es noch einfacher sein, wenn das Handbuch recht hätte:
Only the GENERIC kernel can be automatically updated by freebsd-update. If a custom kernel is installed, it will have to be rebuilt and reinstalled after freebsd-update finishes installing the updates. However, freebsd-update will detect and update the GENERIC kernel if /boot/GENERIC exists, even if it is not the current running kernel of the system.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#18
Das ging früher definitiv. Wenn es nicht mehr funktioniert, ist die Funktion irgendwo auf der Strecke geblieben und schreit nach einem Bugreport. :)
 

Rosendoktor

Well-Known Member
#19
Das Problem hab' ich auch. Ich muss auf allen drei Rechnern mit FreeBSD einen Custom Kernel bauen, aus unterschiedlichen Gründen.

Ein "make install" installiert den Kernel bei mir immer nach /boot/kernel/, eine Möglichkeit dies zu ändern habe ich nicht gefunden. Ein "freebsd-update" fummelt leider auch in /boot/kernel/ herum, kann ich auch nicht beeinflussen.

Also lege ich gleich nach dem "make install" eine Kopie des Custom Kernel in /boot/kernel.custom/ an, der wird von freebsd-update in Ruhe gelassen und ist in der loader.conf als standardmässig zu bootender Kernel eingetragen. Danach kann freebsd-update in /boot/kernel von mir aus machen was es will.

Kann man denn für "make install" (in /usr/src/sys/<arch>/compile/GENERIC/ aufgerufen) oder für freebsd-update nicht irgendwie den Zielpfad ändern?
 
#20
Ich finde diese Idee super. Ich glaub die Variable war KODIR (für make installkernel). Dann könnte man den GENERiC in /boot/Kernel liegenlassen (bzw updaten lassen) und via /boot/loader.conf den CUSTOM laden. .. Schau ich dieser Tage nochmal nach.

w
 
#21
Es hat theoretisch funktioniert:

1. Den Customkernel in der loader.conf eintragen:

% echo 'kernel="kernel.CUSTOM"' | sudo tee -a /boot/loader.conf

Und für's bauen die Parameter KERNCONF und KODIR setzen:

% sudo make kernel KERNCONF=CUSTOM KODIR=/boot/kernel.CUSTOM

Allerdings ist das Problem, dass man dann nicht vergessen darf, vor dem sudo freebsd-update upgrade -r 11.0-RELEASE (in meinem Fall heute) ein sudo nextbook -k kernel && sudo reboot zu setzen, weil sonst das Update nicht vollständig durchläuft (--es scheint, dass freebsd-update in das kernel-Verzeichnis des laufenden Kernels schaut). Wenn der Installer dann auffordert, nach einem Neustart nochmal sudo freebsd-update install einzugeben, ist das gleiche nextboot nochmal fällig (mit dem aktualisierten Kernel), sonst läuft es wieder nicht sauber durch.

Und am Ende will man dann, je nach Höhe des Updates, den Kernel eh nochmal bauen.

Fazit: Ich bleib bei meinem bisherigen Upgrade-Prozess.

Gruß,
W