Bij een update van openSUSE 42.3 naar 15.0 en daarna naar 15.1 loopt de installatie halverwege vast op:

(2724/5228) Installing: baekmuk-bitmap-fonts-2.1-lp151.2.1.noarch ……………………………………………….[error]
Installation of baekmuk-bitmap-fonts-2.1-lp151.2.1.noarch failed:
Error: Subprocess failed. Error: RPM failed: installing package baekmuk-bitmap-fonts-2.1-lp151.2.1.noarch needs 7MB on the / filesystem

Abort, retry, ignore? [a/r/i] (a):

Er is nog maar 24,8 Mb vrij op / dus ze is eigenlijk vol.

# df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1900576 0 1900576 0% /dev
tmpfs 1910400 19992 1890408 2% /dev/shm
tmpfs 1910400 1772 1908628 1% /run
tmpfs 1910400 0 1910400 0% /sys/fs/cgroup
/dev/mapper/system-root 30253056 29650716 24820 100% /
/dev/sda1 387456 73618 289314 21% /boot
...

Helaas, dit is een beetje laat, het zou natuurlijk veel beter zijn als de update procedure op voorhand checkt of er genoeg plaats is om het systeem te updaten. Of als euh de gebruiker dit zou checken voordat hij een upgrade doet 😉

update 03/2021: ondertusssen vond ik dit artikel over een Btrfs probleem op de SUSE site.
(punt 3 in een algemeen artikel over System_upgrade)
Waarin ze zeggen: Move /var/cache to a separate subvolume

Nota: Als het root filesysteem niet Btrfs is, of als je upgrade van 15.0 of later, hoef je dit niet te doen.

Ze geven ook de beschrijving hoe je dat moet doen;
– zoek het root filesysteem
– zoek het hoofdsubvolume van alle andere subvolumes, vanaf oepnsuse 15.1 herken je dat aan een @ teken, zoniet kijk naar subvolume ID 5.
– mount het op een tijdelijk mountpunt
– move /mnt/var/cache die al bestaat* naar bv /mnt/var/cache.old (* kan zelfde zijn als /var/cache)
– maak nieuw subvolume bv btrfs subvol create /mnt/var/cache
– move de .old naar de nieuwe locatie of mv /var/cache/* naar de nieuwe /mnt/var/cache
– unmount subvolume van tijdelijk mountpunt
– voeg het nieuwe subvolume /var/cache toe aan /etc/fstab (gebruik een bestaand subvolume als voorbeeld en laat zeker de UUID van het root file systeem hetzelfde; subvolume naam en mountpunt /var/cache.
– mount het nieuwe subvolume zoals voorzien in /etc/fstab (mount /var/cache)
– daarna kan je verder met zypper ref, zypper update..

Op het moment dat ik dat nog niet gevonden had ging ik zo verder:

Ruimte vrijmaken
Ik hoop op de / oude overbodige bestanden te vinden die ik kan verwijderen…

Als ik ga kijken hoe groot de partitie is en waar het gebruik zit:

/tmp bevat maar 10 Mb

Bv in de logs? Die zitten in /var
linuxbox:/var # du -h

1.8G ./cache
...
1.7G ./cache/zypp
...
1.6G ./cache/zypp/packages
...
1.6G ./cache/zypp/packages/repo-oss
...
2.3G ./log/journal
...
2.3G ./log/journal/dc2e43a8d852824c292ab053590bc8e0
...
5.1G .

5 Gig is dus niet groot genoeg meer voor /.

Ik baseer me op dit Cleanup system artikel van openSUSE, waarin ze (als root):
journalctl --vacuum-time=1d
zypper clean
zypper purge-kernels
sudo snapper cleanup number
sudo rm /tmp/* -rf

Eén van de opkuismogelijkheden verklaart misschien ook al de mede-oorzaak van het vollopen van het systeem; de download van packages.

Maar…Hoe kan ik packages weggooien als de installatie nog bezig is? Ik kan kijken in mijn venster van aktiviteit, zien wat voorbij is?

Ik volg eerst even de mogelijkheden van het artikel, misschien zijn er andere mogelijkheden, zoals logs van de database enz.

Journal logs

Opkuisen van de journal logs kan snel vele gigabytes aan diskruimte vrijmaken. Tenzij je iets bepaald moet uitzoeken daaruit, mogen die eigenlijk weg.
En liefst vooral de oudste, bv die voor vandaag:

sudo journalctl --vacuum-time=1d

Er scrolt allerlei voorbij, eindigend in:

001-0005b9f8c7ebb761.journal (40.0M).
Deleted archived journal /var/log/journal/dc2e43a8d852824c292ab053590bc8e0/user-1000@d54c85726fdf498188f558006191cb01-0000000000000615-0005b9f8c9f9204f.journal (16.0M).
Vacuuming done, freed 2.2G of archived journals from /var/log/journal/dc2e43a8d852824c292ab053590bc8e0.

2.2G vrijgemaakt? Ok … checken…

df
Filesystem 1K-blocks Used Available Use% Mounted on
devtmpfs 1900576 0 1900576 0% /dev
tmpfs 1910400 45216 1865184 3% /dev/shm
tmpfs 1910400 1772 1908628 1% /run
tmpfs 1910400 0 1910400 0% /sys/fs/cgroup
/dev/mapper/system-root 30253056 26250384 3424992 89% /
/dev/sda1 387456 73618 289314 21% /boot
/dev/mapper/system-root 30253056 26250384 3424992 89% /var/opt

3.3G vrij, 89% gebruikt, dat ziet er al beter uit.

Naar het andere root terminal venster en verder met de installatie:

Abort, retry, ignore? [a/r/i] (a): r

RPM packages
Andere mogelijkheden:
Opkuisen van de gedownloade rpm packages.
sudo zypper clean

Opkuisen van oude kernels
sudo zypper purge-kernels

En als je een Btrfs bestandssysteem hebt:

sudo snapper cleanup number
Snapper heeft als basisinstellingen hetvolgende:
– Maximum 50% van het root filesysteem gebruiken voor snapshots (van 5 G zou het 2.5G zijn..)
– Minimum 2 en maximum 10 normale snapshots
– Minimum 4 en maximum 10 belangrijke snapshots
Je kan die ook verzetten als je dat nu concludeert:
snapper set-config SPACE_LIMIT=0.2 NUMBER_LIMIT=2-6 NUMBER_LIMIT_IMPORTANT=4

Je kan dat daarna uitvoeren door:

snapper cleanup number

littleblue:/tmp # df -h

Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 8.0K 1.9G 1% /dev
..
/dev/mapper/system-root 29G 26G 2.4G 92% /
/dev/sda1 379M 76M 280M 22% /boot
…

Ik wou drastisch plaats vrijmaken op een machine waar ik toch alles van documenten online heb, dus ik deed:

snapper set-config SPACE_LIMIT=0.2 NUMBER_LIMIT=2-4 NUMBER_LIMIT_IMPORTANT=2

# snapper cleanup number

Dat gaf mij 6G vrij:
# df -h

Filesystem Size Used Avail Use% Mounted on
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 1.8M 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/mapper/system-root 29G 22G 6.8G 76% /
/dev/sda1 379M 76M 280M 22% /boot

De /tmp directory

Mogelijk gevaarlijker is /tmp zelf leegmaken.

sudo rm /tmp/* -rf

Daarin kunnen bestanden zitten die in gebruik zijn door gebruikersprogramma’s, die kunnen crashen of data verliezen. Dus dit kan misschien beter beperkt worden tot oudere files. Het systeem zou er in ieder geval niet door mogen crashen.

Bij de updates op desktops doe ik het nu zo: ik kuis op voorhand op; en ik installeer de desktop widget met de harde-schijfruimte, dan kan je tijdens de installatie perfect volgen wat er gebeurt. En inderdaad, die loopt erg terug … zo’n G tijdens de downloads, en nadien nog een paar gig…(van 6.8 over 5.9 na download verbazingwekkend zichtbaar zakkend tot ..3.7 G..2.2 G..1.1 G..484 M …399 M…229 M..en tijdens de uitvoering van de posttrans scripts tot .. 145 M 106M..99M… 4,7 M.).

Dan eindigt de installatie in:

Problem occurred during or after installation or removal of packages:
Failed to cache rpm database (1).

Waarbij ik niet weet of ze echt gedaan was of onderbroken…

Daarna geeft snapper cleanup number als reaktie:

Config is in use.

Op dat moment is de overblijvende harde schijfruimte weer NUL!
(of eerder 52K).
Als even later de snapper cleanup number toch lukt, heb je zo weer 8 G vrij…

En zypper dup geeft nu “Nothing to do”, dus ik veronderstel dat hij net klaar was.

Reboot!

– – –

Ondertussen hoor ik op Radio Centraal:
“Paul stretch extreme” vermelden…