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čenoZá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 MShrnutí 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 transactionInvalid 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.
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.
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.