[OpenBSD -current] Ein Filesystem bald voll?

[Marcel Logen]

Ich mache gelegentlich (ca. alle zwei bis vier Wochen) ein System-
upgrade ("sysupgrade -s") meines OpenBSD -current.

Kürzlich sah ich, daß eine Partition auf meiner SSD wohl langsam
volläuft, nämlich sd0f:

| t20# df -k
| Filesystem 1K-blocks Used Avail Capacity Mounted on
| /dev/sd0a 1028878 324614 652822 34% /
| /dev/sd0l 140799164 17273896 116485312 13% /home
| /dev/sd0d 4125406 40 3919096 1% /tmp
| /dev/sd0f 2061054 1764934 193068 91% /usr
| /dev/sd0g 1028878 433448 543988 45% /usr/X11R6
| /dev/sd0h 20636942 10138924 9466172 52% /usr/local
| /dev/sd0k 6189758 2 5880270 1% /usr/obj
| /dev/sd0j 2061054 1180320 777682 61% /usr/src
| /dev/sd0e 27407100 37106 25999640 1% /var

Daraufhin habe ich mal überprüft, welche Verzeichnisse denn re-
lativ voll sind. Das sind vor allem /usr/share und /usr/lib:

| t20# du -h -d 1 /usr/
| 423M /usr/X11R6
| 9.7G /usr/local
| 2.0K /usr/obj
| 1.1G /usr/src
| 613M /usr/lib
| 248M /usr/bin
| 1.9M /usr/games
| 48.9M /usr/include
| 52.5M /usr/libdata
| 3.1M /usr/libexec
| 612K /usr/mdec
| 18.9M /usr/sbin
| 733M /usr/share
| 2.0K /usr/xobj
| 12.9G /usr/
| t20#

| t20# pwd
| /usr/share/relink/kernel/GENERIC.MP

| t20# ls -1 *.o | wc -l
| 2202

Frage: Können die .o-Dateien gefahrlos gelöscht werden? Oder
werden die etwa im laufenden Betrieb gebraucht?

Vermutlich aber werden die beim nächsten Upgrade alle wieder
neu erzeugt ...

Das ist der Rest in GENERIC.MP:

| t20# ls -l *[!o]
| -rw-r----- 1 root wheel 220086 Mar 6 17:20 Makefile
| -rwxrwx--- 1 root wheel 25091075 Mar 8 02:42 bsd
| -rw-rw---- 1 root wheel 634 Mar 8 02:41 gap.link
| -rw-r----- 1 root wheel 4482 Mar 6 17:31 ld.script
| -rw-rw---- 1 root wheel 28408 Mar 8 02:41 lorder
| -rw-r----- 1 root wheel 1150 Mar 6 17:20 makegap.sh
| -rwxrwx--- 1 root wheel 168391048 Mar 8 02:42 newbsd.gdb
| -rw-r--r-- 1 root wheel 495 Mar 8 02:42 relink.log

Da sticht vor allem newbsd.gdb ins Auge. Weg damit?

In /usr/lib finden sich offenbar verschiedene (alte) Versionen
der gleichen Libs, hier am Beispiel "libtls":

| t20# pwd
| /usr/lib

| t20# ls -l libtls*
| -r--r--r-- 1 root bin 450586 Mar 6 17:09 libtls.a
| -r--r--r-- 1 root bin 368232 Jun 1 2019 libtls.so.19.6
| -r--r--r-- 1 root bin 334368 Oct 12 2019 libtls.so.19.7
| -r--r--r-- 1 root bin 336640 Oct 25 2019 libtls.so.20.0
| -r--r--r-- 1 root bin 337464 Jan 9 2021 libtls.so.20.1
| -r--r--r-- 1 root bin 340992 Mar 28 2021 libtls.so.20.2
| -r--r--r-- 1 root bin 340992 Apr 19 2021 libtls.so.20.3
| -r--r--r-- 1 root bin 329040 Aug 24 2021 libtls.so.21.0
| -r--r--r-- 1 root bin 329280 Oct 7 2021 libtls.so.22.0
| -r--r--r-- 1 root bin 246200 Jan 12 2022 libtls.so.23.0
| -r--r--r-- 1 root bin 228000 Jan 21 2022 libtls.so.24.0
| -r--r--r-- 1 root bin 249696 Mar 23 2022 libtls.so.24.1
| -r--r--r-- 1 root bin 249216 Jun 30 2022 libtls.so.25.0
| -r--r--r-- 1 root bin 249200 Sep 8 17:21 libtls.so.25.1
| -r--r--r-- 1 root bin 249224 Nov 6 20:32 libtls.so.26.0
| -r--r--r-- 1 root bin 249224 Mar 6 17:09 libtls.so.26.1
| -r--r--r-- 1 root bin 414152 Mar 6 17:09 libtls_p.a
| t20#

Kann ich da einfach die alten Versionen löschen und jeweils die
neueste stehen lassen?

Oder sind die 91 % Füllstand kein Problem, weil da eh nicht viel
dazukommt? (Ich weiß leider nicht, wie sich der Füllstand entwik-
kelt hat.)

TIA
Marcel 1q9tm (1910710)
--
╭──────╮ ╭──────────╮ ╭───╮ ╭────╮ ╭──╮ ╭─╮ ╭─╮ │
╯ ╭───╯ ╭───╯ │ ╰─╮ ╰───╯ │ ╭─╯ │ │ │ │ ╰────╯
╭─╯ ╭─╮ ╭─╮ ╭─╯ ╰────╮ ╰─────╮ ╭─╯ │ ╰─╯ ╰──╯
╰───╯ ╰──╯ ╰─╯ ╰────────╯ ╰───╯ 0c11f2

[Christian Weisgerber]

On 2023-03-08, Marcel Logen <33320000...@ybtra.de> wrote:

> Ich mache gelegentlich (ca. alle zwei bis vier Wochen) ein System-
> upgrade ("sysupgrade -s") meines OpenBSD -current.

Ich empfehle dir sysclean (ports/sysutils/sysclean).

>| t20# df -k
>| Filesystem 1K-blocks Used Avail Capacity Mounted on

>| /dev/sd0f 2061054 1764934 193068 91% /usr

Im Vergleich dazu ein geputztes System:

$ df -k /usr

Filesystem 1K-blocks Used Avail Capacity Mounted on

/dev/sd1f 3044462 1345014 1547226 47% /usr

Naja, sooo viel Müll hat sich bei dir auch nicht angesammelt.

>| /usr/share/relink/kernel/GENERIC.MP

Das ist das Relinking-Kit für den Kernel. Bei jedem Systemstart
wird daraus ein Kernel mit zufälliger Reihenfolge der Objektdateien
neu gelinkt und installiert, damit er dann beim nächsten Reboot
verwendet wird. D.h. nach jedem Reboot ist der Kernelcode im Speicher
anders angeordnet. Das Ausnutzen von Sicherheitslücken durch
Anspringen bekannter Adressen wird dadurch erschwert.

> In /usr/lib finden sich offenbar verschiedene (alte) Versionen
> der gleichen Libs, hier am Beispiel "libtls":

> [...]

> Kann ich da einfach die alten Versionen löschen und jeweils die
> neueste stehen lassen?

Ja, solange du nicht selbst gebauten Code (außerhalb von Ports/Packages)
irgendwo rumliegen hast, der noch gegen die alten Bibliotheken
gelinkt ist.

> Oder sind die 91 % Füllstand kein Problem, weil da eh nicht viel
> dazukommt? (Ich weiß leider nicht, wie sich der Füllstand entwik-
> kelt hat.)

Sprunghaft. Meistens tut sich da nicht viel. Selten gibt es dann
wieder einen Sprung, weil irgendwas Großes neu hinzugekommen ist.

Inzwischen räumt der Installer auch viel selbst weg:

# We are committed to installing new files. Attempt to cope with
# potential space shortage in /usr by deleting a few versioned
# areas which will be replaced from the new sets
if [[ $MODE == upgrade ]]; then
if isin base$VERSION.tgz $_get_sets; then
rm -f /mnt/usr/share/relink/usr/lib/*
rm -rf /mnt/usr/lib/libLLVM.so.[012].0
rm -rf /mnt/usr/libdata/perl5
fi
if isin comp$VERSION.tgz $_get_sets; then
rm -rf /mnt/usr/lib/{gcc-lib,clang}
rm -rf /mnt/usr/bin/{gcc,g++}
rm -rf /mnt/usr/include/g++
fi
rm -rf /mnt/var/syspatch/*
fi

(/usr/src/distrib/miniroot/install.sub)

--
Christian "naddy" Weisgerber na...@mips.inka.de

[Marcel Logen]

Christian Weisgerber in de.comp.os.unix.bsd:

>On 2023-03-08, Marcel Logen <33320000...@ybtra.de> wrote:

>Ich empfehle dir sysclean (ports/sysutils/sysclean).

Kann man dieses Perl-Script auch direkt nutzen oder installieren,
ohne den gesamten ports tree herunterladen zu müssen?

Ich hatte gemäß den Angaben aus

<https://cvsweb.openbsd.org/ports/sysutils/sysclean/Makefile?rev=1.25&content-type=text/x-cvsweb-markup>

bei

<https://github.com/semarie/sysclean/releases/download/3.2/>

geschaut, da kam aber nur ein 404. Bei

<https://github.com/semarie/sysclean/releases/tag/3.2>

wurde ich dann aber fündig und konnte die tar.gz-Datei downloaden.
Sie hat die in

<https://cvsweb.openbsd.org/cgi-bin/cvsweb/ports/sysutils/sysclean/distinfo?rev=1.21&content-type=text/x-cvsweb-markup>

angegebene SHA256-Summe und Größe.

>Naja, sooo viel Müll hat sich bei dir auch nicht angesammelt.

Stimmt, so gesehen. Aber ich habe halt nur ca. 2 GB zur Verfügung.

>>| /usr/share/relink/kernel/GENERIC.MP
>
>Das ist das Relinking-Kit für den Kernel. Bei jedem Systemstart
>wird daraus ein Kernel mit zufälliger Reihenfolge der Objektdateien
>neu gelinkt und installiert, damit er dann beim nächsten Reboot
>verwendet wird. D.h. nach jedem Reboot ist der Kernelcode im Speicher
>anders angeordnet. Das Ausnutzen von Sicherheitslücken durch
>Anspringen bekannter Adressen wird dadurch erschwert.

Ja, das dürfte für die Boot-Meldung "reordering libraries" ver-
antwortlich sein (hatte ich vor längerer Zeit mal recherchiert).

Ich vermute, die Datei "lorder" wird beim Systemstart sozusagen
jeweils neu 'ge-shuf-t' (obwohl ich kein "shuf" hier habe).

>> In /usr/lib finden sich offenbar verschiedene (alte) Versionen
>> der gleichen Libs, hier am Beispiel "libtls":
>> [...]
>> Kann ich da einfach die alten Versionen löschen und jeweils die
>> neueste stehen lassen?
>
>Ja, solange du nicht selbst gebauten Code (außerhalb von Ports/Packages)
>irgendwo rumliegen hast, der noch gegen die alten Bibliotheken
>gelinkt ist.

OK, da müßte ich also aufpassen. Ich habe aber eigentlich nur ein
selbstkompiliertes Programm, nämlich den von mir genutzten News-
reader flnews. Vermutlich kann ich da mit "ldd" sehen, welche li-
braries benutzt werden.

Marcel 1rjmp (1953497)
--
╭─────╮ ╭──╮ ╭──╮ ╭──────╮ ╭────────╮ ╭─
╮ ╰─╮ │ │ ╰─╮ ╭───╯ ╰───╮ ╰───╮ ╰──╮ ╰─────╮ ╰────╯
╰─╮ ╰─╮ │ │ ╭─╯ │ ╭─────╯ ╭─╮ ╰─╮ │ ╭──╮ │
╰────╯ ╰──────────╯ ╰─────╯ ╰───────╯ ╰────╯ ╰───╯ ╰─╯ b6c6de

[Marcel Logen]

Marcel Logen in de.comp.os.unix.bsd:

>Christian Weisgerber in de.comp.os.unix.bsd:
>>On 2023-03-08, Marcel Logen <33320000...@ybtra.de> wrote:

>>>| /usr/share/relink/kernel/GENERIC.MP
>>
>>Das ist das Relinking-Kit für den Kernel. Bei jedem Systemstart
>>wird daraus ein Kernel mit zufälliger Reihenfolge der Objektdateien
>>neu gelinkt und installiert, damit er dann beim nächsten Reboot
>>verwendet wird. D.h. nach jedem Reboot ist der Kernelcode im Speicher
>>anders angeordnet. Das Ausnutzen von Sicherheitslücken durch
>>Anspringen bekannter Adressen wird dadurch erschwert.
>
>Ja, das dürfte für die Boot-Meldung "reordering libraries" ver-
>antwortlich sein (hatte ich vor längerer Zeit mal recherchiert).
>
>Ich vermute, die Datei "lorder" wird beim Systemstart sozusagen
>jeweils neu 'ge-shuf-t' (obwohl ich kein "shuf" hier habe).

Shufflen kann man wohl (mehr oder weniger) auch mit "sort -R",
wie ich gerade las.

Ingrid 1s85o (1974456)
--
╭───╮ ╭────╮ ╭─────────╮ ╭──────────╮ ╭─╮
│ ╰─────╯ ╭─╯ ╰───╮ ╭─╯ ╭─╮ ╰──────╮ ╰─╮ ╭─╮ │ │ ╭──╮
╯ ╭────╯ ╭──────╯ ╰──╮ │ ╰──╮ ╭───╮ │ ╭──╯ │ ╰─╯ │ │ │
╰──────╯ 61dbb8 ╰──╯ ╰─────╯ ╰─╯ ╰────╯ ╰──╯ ╰──

[Christian Weisgerber]

On 2023-03-09, Marcel Logen <33320000...@ybtra.de> wrote:

>>Ich empfehle dir sysclean (ports/sysutils/sysclean).
>
> Kann man dieses Perl-Script auch direkt nutzen oder installieren,
> ohne den gesamten ports tree herunterladen zu müssen?

# pkg_add sysclean

Da ist dann auch eine Man-Page dabei. Aber ja, das Skript kann man
auch einfach so direkt verwenden.

>>>| /usr/share/relink/kernel/GENERIC.MP
>>
>>Das ist das Relinking-Kit für den Kernel.
>

> Ja, das dürfte für die Boot-Meldung "reordering libraries" ver-
> antwortlich sein (hatte ich vor längerer Zeit mal recherchiert).

Nee, das geht an syslog, weil es im Hintergrund gestartet wird und
dann irgendwann fertig wird. In /var/log/messages findest du dann
"reorder_kernel: kernel relinking done".

Das "reordering libraries" ist aber in der Tat ein vergleichbarer
Mechanismus für einige ausgewählte Teile vom Userland. Ursprünglich
geschah das stumm, aber da es auf laaangsamen Maschinen einen
Augenblick dauern kann, wurde die Meldung eingefügt.

> OK, da müßte ich also aufpassen. Ich habe aber eigentlich nur ein
> selbstkompiliertes Programm, nämlich den von mir genutzten News-
> reader flnews. Vermutlich kann ich da mit "ldd" sehen, welche li-
> braries benutzt werden.

Genau.

[Marcel Logen]

Christian Weisgerber in de.comp.os.unix.bsd:

>On 2023-03-09, Marcel Logen <33320000...@ybtra.de> wrote:

>>>Ich empfehle dir sysclean (ports/sysutils/sysclean).
>>
>> Kann man dieses Perl-Script auch direkt nutzen oder installieren,
>> ohne den gesamten ports tree herunterladen zu müssen?
>
># pkg_add sysclean

Grmpf! Ja, danke. Damit hatte ich nicht gerechnet, weil Du oben
"ports" erwähntest. Das wollte ich mir ersparen (habe es vor Jah-
ren mal ausprobiert, kam mir aber irgendwie 'sperrig' und auf-
gebläht vor).

>Da ist dann auch eine Man-Page dabei. Aber ja, das Skript kann man
>auch einfach so direkt verwenden.

Die man page hatte ich auch in dem ausgepackten tar.gz file ge-
funden.

>>>>| /usr/share/relink/kernel/GENERIC.MP
>>>
>>>Das ist das Relinking-Kit für den Kernel.
>>
>> Ja, das dürfte für die Boot-Meldung "reordering libraries" ver-
>> antwortlich sein (hatte ich vor längerer Zeit mal recherchiert).
>
>Nee, das geht an syslog, weil es im Hintergrund gestartet wird und
>dann irgendwann fertig wird. In /var/log/messages findest du dann
>"reorder_kernel: kernel relinking done".
>
>Das "reordering libraries" ist aber in der Tat ein vergleichbarer
>Mechanismus für einige ausgewählte Teile vom Userland. Ursprünglich
>geschah das stumm, aber da es auf laaangsamen Maschinen einen
>Augenblick dauern kann, wurde die Meldung eingefügt.

Ja, auf einem früheren Rechner von mir hat das immer seine Zeit
gebraucht, aber jetzt stört es mich eigentlich nicht mehr. Inzwi-
schen lautet die Meldung BTW nur noch "reordering: ..."

Marcel 1sijh (1985137)
--
╭─────╮ ╭───╮ ╭─────────────╮ ╭──╮
╮ ╭──╮ ╰──╮ ╰─╯ ╰──────╮ ╰─────────╮ ╰─────╯ │
│ │ ╰──╮ │ ╰─╮ ╭─────╮ ╰─╮ ╰─╮ ╭──────╮
╰─╯ ╰──╯ ╰──╯ ╰────╯ ╰───╯849822╰───╮

[Marcel Logen]

Christian Weisgerber in de.comp.os.unix.bsd:

>On 2023-03-08, Marcel Logen <33320000...@ybtra.de> wrote:

>> Ich mache gelegentlich (ca. alle zwei bis vier Wochen) ein System-
>> upgrade ("sysupgrade -s") meines OpenBSD -current.
>
>Ich empfehle dir sysclean (ports/sysutils/sysclean).
>
>>| t20# df -k
>>| Filesystem 1K-blocks Used Avail Capacity Mounted on
>>| /dev/sd0f 2061054 1764934 193068 91% /usr

[...]

>> Oder sind die 91 % Füllstand kein Problem, weil da eh nicht viel
>> dazukommt? (Ich weiß leider nicht, wie sich der Füllstand entwik-
>> kelt hat.)
>
>Sprunghaft. Meistens tut sich da nicht viel. Selten gibt es dann
>wieder einen Sprung, weil irgendwas Großes neu hinzugekommen ist.
>
>Inzwischen räumt der Installer auch viel selbst weg:

Heute habe ich wieder ein "sysupgrade -s" gemacht. [1]

Jetzt ist der Füllstand bei 82 %, ohne daß ich sysclean benutzt
hätte. Immerhin.

[1] Es gab dabei eine zehnminütige Pause nach der Meldung "Fetching
updated firmware" (IIRC). Nach dem Reboot dann:

| [...]firmware.openbsd.org/firmware/7.3/SHA256.sig (timed out)

und

| [...]ftp.openbsd.org/pub/OpenBSD/syspatch/7.3/amd64/SHA256.sig
404 [...]

Beim anschließenden, von mir manuell durchgeführten "fw_update -a"
gab es keine Probleme (allerdings auch keine upgedateten Files).

Mich wundert ein wenig, daß da die Rede von "syspatch" ist. Ich
dachte, das seien Patches für -stable. Aber egal, es scheint al-
les zu funktionieren.

Marcel 2g3t3 (2625443)
--
│ ╭─╮ ╭───╮ ╭──╮ ╭─╮ ╭─╮ ╭──────╮
│ ╭───╯ │ ╭─╯ ╰─╯ ╰─╯ │ ╭─╯ │ ╰─╮ ╭─╯
│ ╭────╯ ╭──╯ │ │ ╭──╯ │ ╭─╮ ╭─╯ ╰───╮ ╭──
╰──────────╯ ╰────╯ ╰──╯ ╰──╯ ╰─╯ cc3034 ╰───╯

[Marcel Logen]

Christian Weisgerber in de.comp.os.unix.bsd:

>On 2023-03-08, Marcel Logen <33320000...@ybtra.de> wrote:

>> Ich mache gelegentlich (ca. alle zwei bis vier Wochen) ein System-
>> upgrade ("sysupgrade -s") meines OpenBSD -current.
>
>Ich empfehle dir sysclean (ports/sysutils/sysclean).
>
>>| t20# df -k
>>| Filesystem 1K-blocks Used Avail Capacity Mounted on
>>| /dev/sd0f 2061054 1764934 193068 91% /usr

[...]

>> Oder sind die 91 % Füllstand kein Problem, weil da eh nicht viel
>> dazukommt? (Ich weiß leider nicht, wie sich der Füllstand entwik-
>> kelt hat.)
>
>Sprunghaft. Meistens tut sich da nicht viel. Selten gibt es dann
>wieder einen Sprung, weil irgendwas Großes neu hinzugekommen ist.
>
>Inzwischen räumt der Installer auch viel selbst weg:

Heute habe ich wieder ein "sysupgrade -s" gemacht. [1]

Jetzt ist der Füllstand bei 82 %, ohne daß ich sysclean benutzt
hätte. Immerhin.

[1] Es gab dabei eine zehnminütige Pause nach der Meldung "Fetching
updated firmware" (IIRC). Nach dem Reboot dann:

| [...]firmware.openbsd.org/firmware/7.3/SHA256.sig (timed out)

und

| [...]ftp.openbsd.org/pub/OpenBSD/syspatch/7.3/amd64/SHA256.sig
404 [...]

Beim anschließenden, von mir manuell durchgeführten "fw_update -a"
gab es keine Probleme (allerdings auch keine upgedateten Files).

Mich wundert ein wenig, daß da die Rede von "syspatch" ist. Ich
dachte, das seien Patches für -stable. Aber egal, es scheint al-
les zu funktionieren.

| t20$ head -n 1 /etc/motd
| OpenBSD 7.3 (GENERIC.MP) #1123: Tue Mar 21 07:11:25 MDT 2023
| t20$

Wurde mir da evtl. - trotz -s - ein release untergejubelt?

Marcel 2g44i (2625682)

[supersedes]
--
╭─╮ ╭──╮ ╭────────╮ ╭─╮ ╭─╮ ╭────────╮ ╭──╮ ╭────╮
│ ╰─╯ ╰─╮ ╰─────╮ │ ╭─╯ ╰───╯ │ ╰───╮ ╭─╯ │ ╰──╮ │ ╭─╯
│ │ ╭─╮ ╭──╯ │ ╰──╮ ╭───╯ ╭───╯ │ ╭───╯ ╭──╯ │ ╰──╮
│ ╰──╯ ╰─╯ ╰─────╯ ╰──────╯ ╰─────╯b11e71╰────╯ ╰─╮

[Christian Weisgerber]

On 2023-03-23, Marcel Logen <33320000...@ybtra.de> wrote:

>| OpenBSD 7.3 (GENERIC.MP) #1123: Tue Mar 21 07:11:25 MDT 2023
>

> Wurde mir da evtl. - trotz -s - ein release untergejubelt?

Nein, die nächste Release, 7.3, steht unmittelbar bevor und kurz
davor wird bei den Snapshots das "-current" rausgenommen, damit
sich alles schon wie die echte Release verhält.

Wenn du da Packages installieren willst, nicht vergessen "-Dsnap"
anzugeben, sonst sucht pkg_add in einem noch nicht existierenden
Verzeichnis /7.3.

> [1] Es gab dabei eine zehnminütige Pause nach der Meldung "Fetching
> updated firmware" (IIRC). Nach dem Reboot dann:
>
> | [...]firmware.openbsd.org/firmware/7.3/SHA256.sig (timed out)

Irgendein Netzproblem.

> | [...]ftp.openbsd.org/pub/OpenBSD/syspatch/7.3/amd64/SHA256.sig
> 404 [...]

>
> Mich wundert ein wenig, daß da die Rede von "syspatch" ist. Ich
> dachte, das seien Patches für -stable.

Wie gesagt, der Snapshot verhält sich jetzt schon wie die Release.
/syspatch/7.3 existiert aber noch nicht auf den Mirrorn.

[Marcel Logen]

Christian Weisgerber in de.comp.os.unix.bsd:

>On 2023-03-23, Marcel Logen <33320000...@ybtra.de> wrote:

>>| OpenBSD 7.3 (GENERIC.MP) #1123: Tue Mar 21 07:11:25 MDT 2023
>>
>> Wurde mir da evtl. - trotz -s - ein release untergejubelt?
>
>Nein, die nächste Release, 7.3, steht unmittelbar bevor und kurz
>davor wird bei den Snapshots das "-current" rausgenommen, damit
>sich alles schon wie die echte Release verhält.
>
>Wenn du da Packages installieren willst, nicht vergessen "-Dsnap"
>anzugeben, sonst sucht pkg_add in einem noch nicht existierenden
>Verzeichnis /7.3.

Ich installiere fast nie irgend etwas Neues, sondern mache nach dem
sysupgrade immer nur ein "pkg_add -u". Das lief AFAIR ohne große Be-
sonderheiten durch.

[...]

>> Mich wundert ein wenig, daß da die Rede von "syspatch" ist. Ich
>> dachte, das seien Patches für -stable.
>
>Wie gesagt, der Snapshot verhält sich jetzt schon wie die Release.

Danke, aber mir erschließt sich der Sinn dahinter noch nicht.

Ich will doch gar kein release bekommen, sonst hätte ich ja -r bei
"sysupgrade" angegeben.

>/syspatch/7.3 existiert aber noch nicht auf den Mirrorn.

Kann das Befragen von .../syspatch/ da nicht sogar Durcheinander ver-
ursachen, wenn es denn existiert?

Marcel 2ifap (2702681)
--
╭──────╮ ╭────╮ ╭───╮ ╭─────────────╮ ╭──────
─╮ ╰───╮ ╰─────╯ ╭─╯ ╭─╮ ╰─╮ │ ╰───╮ ╰─╮ ╰───╮
╰──╮ ╭──╮ ╰─╮ ╭───╯ │ ╰─╮ │ ╰────╮ │ │ ╭─╮ ╭─╮ ╭─╯
╰─╯ ╰────╯ ╰───────╯ ╰──╯ ╰─╯ 5d89f1 ╰─╯ ╰──╯ ╰─╯