Re: /boot is vol .. (en niet met kernels)
Winfried Tilanus schreef op zo 10-10-2021 om 15:19 [+0200]: > On 10-10-2021 10:41, Gijs Hillenius wrote: > > > Even gegrepd in de term.log van apt... sinds Maart heb ik bij > > iedere nieuwe kernel: > > Het is mij wel eens opgevallen dat mkinitramfs tijdens het proces > meer ruimte gebruikt dan er uiteindelijk nodig is. Heb het nooit > verder onderzocht, maar na een tijdje klooien /boot vergroot... In /etc/initramfs-tools/initramfs.conf kun je in plaats van de standaard "MODULES=most", "MODULES=dep" opgeven. Standaard is de initramfs-image bij mij zo'n 38 MiB, met "MODULES=dep" is daar nog maar 9 MiB van over Let op dat omdat niet alle modules in initramfs zitten, sommige bootproblemen lastiger te debuggen zijn omdat je niet al je hardware kunt aanspreken vanuit een shell in initramfs. Ook kán het zijn dat je installatie niet gelijk werkt als je de schijf in een andere machine stopt (maar AHCI en NVMe zijn zo standaard dat de modules hiervoor altijd wel aanwezig zullen zijn; ik denk niet dat dat een heel groot probleem is?) -Martijn
Re: /boot is vol .. (en niet met kernels)
On 10-10-2021 10:41, Gijs Hillenius wrote: Hoi, >> Dan zou je mogen verwachten dat het past > > Inderdaad, het verbaast mij (ook): > > Even gegrepd in de term.log van apt... sinds Maart heb ik bij iedere > nieuwe kernel: Het is mij wel eens opgevallen dat mkinitramfs tijdens het proces meer ruimte gebruikt dan er uiteindelijk nodig is. Heb het nooit verder onderzocht, maar na een tijdje klooien /boot vergroot... groet, Winfried -- vanishing in a puff of logic +31.6.23303960 xmpp:winfr...@tilanus.com
Re: /boot is vol .. (en niet met kernels)
Goedenmorgen! [...] Snip! Ik vergiste me: >> >> df -h: >> , >> | /dev/nvme0n1p2 237M 101M 124M 45% /boot >> | /dev/nvme0n1p1 511M 4.7M 507M 1% /boot/ef >> ` >> >> Wat is de beste aanpak? >> >> 1) Kan ik die efi partitie opschonen? Zit het vol met "firmware >> updates"? >> >> ls /boot/efi/EFI/debian/ >> BOOTX64.CSV fbx64.efi fw fwupdx64.efi grub.cfg grubx64.efi >> mmx64.efi shimx64.efi > > Daar herken ik niet de 'Het zit vol met "firmware updates"' Ik las df output (weer eens) verkeerd: /boot/efi is 1% vol. Dus dat is het probleem niet. En de nieuwe firmware update lukte me (nu 20 minuten terug) wel. [...] Snip! > > Ander ding, hier aan deze kant van het Internet: > > |$ ls -lh /boot/ > |totaal 124M > |-rw-r--r-- 1 root root 231K 2 mrt 2021 config-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 231K 27 mrt 2021 config-5.10.0-5-amd64 > |drwxr-xr-x 5 root root 1,0K 1 apr 2021 grub > |-rw-r--r-- 1 root root 55M 15 mrt 2021 initrd.img-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 55M 1 apr 2021 initrd.img-5.10.0-5-amd64 > |drwx-- 2 root root 12K 30 mrt 2015 lost+found > |-rw-r--r-- 1 root root 83 2 mrt 2021 System.map-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 83 27 mrt 2021 System.map-5.10.0-5-amd64 > |-rw-r--r-- 1 root root 6,5M 2 mrt 2021 vmlinuz-5.10.0-4-amd64 > |-rw-r--r-- 1 root root 6,6M 27 mrt 2021 vmlinuz-5.10.0-5-amd64 > > Een volgende kernel zal iets van 55M+7M+0,3M, 63M diskruimte claimen. > > En als je weet hebt van >> | /dev/nvme0n1p2 237M 101M 124M 45% /boot > Dan zou je mogen verwachten dat het past Inderdaad, het verbaast mij (ook): Even gegrepd in de term.log van apt... sinds Maart heb ik bij iedere nieuwe kernel: , | processing triggers for initramfs-tools (0.139) ... | update-initramfs: Generating /boot/initrd.img-5.10.0-4-amd64 | cat: write error: No space left on device | update-initramfs: failed for /boot/initrd.img-5.10.0-4-amd64 with 1. | ESC[1mdpkg:ESC[0m error processing package initramfs-tools (--configure): | installed initramfs-tools package post-installation script subprocess returned error exit status 1 | Errors were encountered while processing: | initramfs-tools ` deze is van 2021-10-04: , | update-initramfs: Generating /boot/initrd.img-5.14.0-2-amd64 | | gzip: stdout: No space left on device | E: mkinitramfs failure gzip 1 | update-initramfs: failed for /boot/initrd.img-5.14.0-2-amd64 with 1. | ESC[1mdpkg:ESC[0m error processing package initramfs-tools (--configure): ` Ik kijk nog wel even verder Dank! G
Re: /boot is vol .. (en niet met kernels)
On Sun, Oct 10, 2021 at 08:58:06AM +0200, Gijs Hillenius wrote: > Hoi! > > Mijn Debian unstable workstation (een nieuwe machine geïnstalleerd met > Debian unstable ergens in December 2019) heeft een te krappe boot > partitie. > > Bij updates kan ik nog slechts één kernel installeren (de 'running > kernel' moet er dan eerst af). En firmware updaten, dat wil ie nu niet > meer. > > df -h: > , > | /dev/nvme0n1p2 237M 101M 124M 45% /boot > | /dev/nvme0n1p1 511M 4.7M 507M 1% /boot/ef > ` > > Wat is de beste aanpak? > > 1) Kan ik die efi partitie opschonen? Zit het vol met "firmware > updates"? > > ls /boot/efi/EFI/debian/ > BOOTX64.CSV fbx64.efifw fwupdx64.efi grub.cfg grubx64.efi > mmx64.efi shimx64.efi Daar herken ik niet de 'Het zit vol met "firmware updates"' Oh, goede morgen, ik zie nu dat openingsvragen Kan ik die partitie opschonen? Zit het vol met "firmware updates"? eigenlijk suggestieve vragen zijn. > 2) Opstarten vanaf Debian rescue en dan de root partitie / > (/dev/mapper/inauditus--vg-root) verkleinen, en daarmee /boot vergroten? Mijn inziens gaat dat niet vliegen. Uit de gecensureerde output van `df -h` maak ik op dat /boot geen logical volume is. Dus het resize voordeel van LVM is op /boot niet van toepassing. Ik heb niet paraat of "boot loaders" LVM begrijpen. /boot op een gewone partitie i.p.v. logical volume is een veilige keuze. > 3) De root partitie / verkleinen en en nieuwe partitie aanwijzen als > /boot, spullen overzetten? Beschouw dat traject in de categorie "voetreis van Hoek van Holland naar Valdivostok" Nog een keer > df -h: > , > | /dev/nvme0n1p2 237M 101M 124M 45% /boot > | /dev/nvme0n1p1 511M 4.7M 507M 1% /boot/ef > ` Daar zie ik meer rangeermogelijkheden. Hou wel `grub-install` in gedachten. > dank voor tips Wat volgt is een noodoplossing: sudo su -# Ja, "vangnet" is weg cd /boot df . # nulmeting cat > initrd[TAB] # de `initrd...` is nu 0 bytes groot df . # meting die laat zien dat er ruimte apt install linux-image # installeer nieuwe kernel exit # wordt weer jezelf Zelf beslissen hoe hoog de nood is. Ander ding, hier aan deze kant van het Internet: |$ ls -lh /boot/ |totaal 124M |-rw-r--r-- 1 root root 231K 2 mrt 2021 config-5.10.0-4-amd64 |-rw-r--r-- 1 root root 231K 27 mrt 2021 config-5.10.0-5-amd64 |drwxr-xr-x 5 root root 1,0K 1 apr 2021 grub |-rw-r--r-- 1 root root 55M 15 mrt 2021 initrd.img-5.10.0-4-amd64 |-rw-r--r-- 1 root root 55M 1 apr 2021 initrd.img-5.10.0-5-amd64 |drwx-- 2 root root 12K 30 mrt 2015 lost+found |-rw-r--r-- 1 root root 83 2 mrt 2021 System.map-5.10.0-4-amd64 |-rw-r--r-- 1 root root 83 27 mrt 2021 System.map-5.10.0-5-amd64 |-rw-r--r-- 1 root root 6,5M 2 mrt 2021 vmlinuz-5.10.0-4-amd64 |-rw-r--r-- 1 root root 6,6M 27 mrt 2021 vmlinuz-5.10.0-5-amd64 Een volgende kernel zal iets van 55M+7M+0,3M, 63M diskruimte claimen. En als je weet hebt van > | /dev/nvme0n1p2 237M 101M 124M 45% /boot Dan zou je mogen verwachten dat het past. Groeten Geert Stappers Verzoek: Gebruik de derde Reply-knop. 1: Reply 2: Reply-to-all 3: Reply-to-list -- Silence is hard to parse
/boot is vol .. (en niet met kernels)
Hoi! Mijn Debian unstable workstation (een nieuwe machine geïnstalleerd met Debian unstable ergens in December 2019) heeft een te krappe boot partitie. Bij updates kan ik nog slechts één kernel installeren (de 'running kernel' moet er dan eerst af). En firmware updaten, dat wil ie nu niet meer. df -h: , | /dev/nvme0n1p2 237M 101M 124M 45% /boot | /dev/nvme0n1p1 511M 4.7M 507M 1% /boot/ef ` Wat is de beste aanpak? 1) Kan ik die efi partitie opschonen? Zit het vol met "firmware updates"? ls /boot/efi/EFI/debian/ BOOTX64.CSV fbx64.efi fw fwupdx64.efi grub.cfg grubx64.efi mmx64.efi shimx64.efi 2) Opstarten vanaf Debian rescue en dan de root partitie / (/dev/mapper/inauditus--vg-root) verkleinen, en daarmee /boot vergroten? 3) De root partitie / verkleinen en en nieuwe partitie aanwijzen als /boot, spullen overzetten? dank voor tips G
