Nedostatek místa na disku "boot"

Fedora (28) hlásí při startu nedostatek místa na disku “boot”. (Zbývá 8,7mb). Jak ho uvolnit/Co s tím?

Otázkou je, co tam je. Výstup tohoto příkazu z terminálu by nám mohl pomoci:

ls -ll /boot

Díky za rychlou odpověď… tu je výpis.

[xxxxx@thinkpad-x250 ~]$ ls -ll /boot
celkem 181930
-rw-r--r--. 1 root root   194526 20. úno  2018 config-4.15.4-300.fc27.x86_64
-rw-r--r--. 1 root root   196156 20. srp 18.12 config-4.17.17-100.fc27.x86_64
-rw-r--r--. 1 root root   196172 24. srp 18.02 config-4.17.19-200.fc28.x86_64
drwx------. 5 root root    16384  1. led  1970 efi
-rw-r--r--. 1 root root   184380 28. čen 16.55 elf-memtest86+-5.01
drwxr-xr-x. 2 root root     3072  2. zář 09.35 extlinux
drwx------. 3 root root     1024  2. zář 09.41 grub2
-rw-------. 1 root root 70031146 17. úno  2018 initramfs-0-rescue-4703715c593443b2a5f035bb987149ce.img
-rw-------. 1 root root 23046678 24. úno  2018 initramfs-4.15.4-300.fc27.x86_64.img
-rw-------. 1 root root 23073382  2. zář 09.08 initramfs-4.17.17-100.fc27.x86_64.img
-rw-------. 1 root root 24423336  2. zář 09.50 initramfs-4.17.19-200.fc28.x86_64.img
drwxr-xr-x. 3 root root     1024  2. zář 09.41 loader
drwx------. 2 root root    12288 17. úno  2018 lost+found
-rw-r--r--. 1 root root   182704 28. čen 16.55 memtest86+-5.01
-rw-------. 1 root root  3775451 20. úno  2018 System.map-4.15.4-300.fc27.x86_64
-rw-------. 1 root root  4025450 20. srp 18.12 System.map-4.17.17-100.fc27.x86_64
-rw-------. 1 root root  4106352 24. srp 18.02 System.map-4.17.19-200.fc28.x86_64
-rwxr-xr-x. 1 root root  7475288 17. úno  2018 vmlinuz-0-rescue-4703715c593443b2a5f035bb987149ce
-rwxr-xr-x. 1 root root  8208568 20. úno  2018 vmlinuz-4.15.4-300.fc27.x86_64
-rwxr-xr-x. 1 root root  8560920 20. srp 18.12 vmlinuz-4.17.17-100.fc27.x86_64
-rwxr-xr-x. 1 root root  8548632 24. srp 18.03 vmlinuz-4.17.19-200.fc28.x86_64
drwxr-xr-x. 3 root root     1024  5. lis  2017 520f44320ac640c68996d2e055036d31
[stereoid@thinkpad-x250 ~]$ 

To nevypadá nijak neobvykle, já mám toto:

total 190004
-rw-r--r--. 1 root root   198030 Oct 21 01:37 config-4.18.16-300.fc29.x86_64
-rw-r--r--. 1 root root   198030 Nov  5 19:16 config-4.18.17-300.fc29.x86_64
-rw-r--r--. 1 root root   198030 Nov 12 04:32 config-4.18.18-300.fc29.x86_64
drwx------. 4 root root     4096 Jan  1  1970 efi
-rw-r--r--. 1 root root   184380 Jul 20 17:12 elf-memtest86+-5.01
drwxr-xr-x. 2 root root     4096 Apr 25  2018 extlinux
drwx------. 3 root root     4096 Oct 31 10:54 grub2
-rw-------. 1 root root 73443963 Sep  3 13:10 initramfs-0-rescue-db1e6a8aae5d4ba5b274cf02033faf56.img
-rw-------. 1 root root 24556950 Oct 31 11:04 initramfs-4.18.16-300.fc29.x86_64.img
-rw-------. 1 root root 24471697 Nov 12 06:16 initramfs-4.18.17-300.fc29.x86_64.img
-rw-------. 1 root root 24579431 Nov 15 15:28 initramfs-4.18.18-300.fc29.x86_64.img
drwxr-xr-x. 3 root root     4096 Apr 25  2018 loader
drwx------. 2 root root    16384 Sep  3 19:06 lost+found
-rw-r--r--. 1 root root   182704 Jul 20 17:12 memtest86+-5.01
-rw-------. 1 root root  4114131 Oct 21 01:37 System.map-4.18.16-300.fc29.x86_64
-rw-------. 1 root root  4114143 Nov  5 19:16 System.map-4.18.17-300.fc29.x86_64
-rw-------. 1 root root  4113681 Nov 12 04:32 System.map-4.18.18-300.fc29.x86_64
-rwxr-xr-x. 1 root root  8286392 Sep  3 13:10 vmlinuz-0-rescue-db1e6a8aae5d4ba5b274cf02033faf56
-rwxr-xr-x. 1 root root  8618168 Oct 21 01:38 vmlinuz-4.18.16-300.fc29.x86_64
-rwxr-xr-x. 1 root root  8614072 Nov  5 19:17 vmlinuz-4.18.17-300.fc29.x86_64
-rwxr-xr-x. 1 root root  8614072 Nov 12 04:34 vmlinuz-4.18.18-300.fc29.x86_64

co vypíše?
df -h /boot

U mě toto:
/dev/sda5 976M 197M 713M 22% /boot

Začal bych promazáním starých kernelů takto:

dnf install yum-utils
package-cleanup --oldkernels --count=2

Ještě líp to bude vidět s Disk Usage Analyzer. Je potřeba ho spustit z terminálu jako root takto:

sudo baobab

Výběrem /boot se pak zobrazí využití disku a co ho zabírá:

df -h /boot vypíše:

/dev/sda10           211M  188M  8,4M  96% /boot

při pokusu o promazání starých kernelů:

[root@thinkpad-x250 stereoid]# package-cleanup --oldkernels --count=2

Yum-utils package has been deprecated, use dnf instead.
See 'man yum2dnf' for more information.

–> Kontrola transakce spuštěna
—> Balíček kernel-core.x86_64 0:4.15.4-300.fc27 bude smazán
–> Zpracování závislostí: kernel-uname-r = 4.15.4-300.fc27.x86_64 pro balíček: kernel-modules-extra-4.15.4-300.fc27.x86_64
–> Zpracování závislostí: kernel-uname-r = 4.15.4-300.fc27.x86_64 pro balíček: kernel-modules-4.15.4-300.fc27.x86_64
–> Kontrola transakce spuštěna
—> Balíček kernel-modules.x86_64 0:4.15.4-300.fc27 bude smazán
—> Balíček kernel-modules-extra.x86_64 0:4.15.4-300.fc27 bude smazán
–> Řešení závislostí dokončeno

Závislosti vyřešeny.

==========================================================================================
Package Arch Verze Repozitář Vel.

Odstraňuje se:
kernel-core x86_64 4.15.4-300.fc27 installed 58 M
Odstranění kvůli závislostem:
kernel-modules x86_64 4.15.4-300.fc27 installed 26 M
kernel-modules-extra x86_64 4.15.4-300.fc27 installed 2.1 M

Shrnutí transakce

Odstranění 1 Balíček (+2 Závislé balíčky)

Nainstalovaná velikost: 86 M
V pořádku [a/N]: a
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction

Invalid version flag: if

To mas bohuzel problem typu “640kB musi stacit kazdemu”. Odinstalovani nepouzivanych jader problem muze docasne vyresit (klidne tam nech jen posledni aktualne pouzivane jadro), ale nevyresi definitivne. Proste v urcitem veku Fedora alokovala na boot treba jen 200MB, jenze dneska ma jeden initramfs desitky MB k tomu jadra, bobtnajici grubefi a je problem. Resenim je partition boot zrusit a vsechno nakopirovat do / (tedy primo do adresare /boot, ktery neni namountovany z extra partition). To vsechno jde pouze za predpokladu, ze pouzivas souborovy system, ktery je v grubu podporovany a je to uz trochu vyssi linuxova. Pokud mas standardni instalaci s LVM, tak si tim, ze to pujde nejsem moc jisty (umi uz grub LVM?) a pak je reseni hodne zavisle na dalsich okolnostech - napr. zda jsi schopen na disku vytvorit boot jinde a vetsi, zda z nej bude mozne bootovat apod. Pokud zadne dalsi znalosti nemas, pak je nejjednodussi zazalohovat a reinstalovat jinym rozdelenim disku.

2 Likes

Nakonec jsem použil pod rootem tenhle příkaz (váš mi nefungoval…):

dnf remove $(dnf repoquery --installonly --latest-limit=-2 -q)

Tim si problem jen odsunul odmazanim starsich jader. Vzhledem k tomu, ze mas zrejme v konfiguraci dnf stale ponechavat dva kernely tak pri dalsich 2 aktualizaich jadra budes mit stejny problem.

1 Like

njn. Bohužel se k reinstalaci jen tak nedostanu dřív jak na jaře, tak aspoň vím, že je potřeba příště vyhradit více místa.