During compilation of the 4.10.1 kernel the following occurs:
limnaios@ubuntu:/usr/src/linux-4.10.1$ sudo make install sh ./arch/x86/boot/install.sh 4.10.1 arch/x86/boot/bzImage \ System.map "/boot" run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.10.1 /boot/vmlinuz-4.10.1 run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.10.1 /boot/vmlinuz-4.10.1 update-initramfs: Generating /boot/initrd.img-4.10.1 W: Possible missing firmware /lib/firmware/i915/kbl_dmc_ver1_01.bin for module i915 W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915 W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915 gzip: stdout: No space left on device E: mkinitramfs failure cpio 141 gzip 1 update-initramfs: failed for /boot/initrd.img-4.10.1 with 1. run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 arch/x86/boot/Makefile:191: recipe for target 'install' failed make[1]: *** [install] Error 1 arch/x86/Makefile:254: recipe for target 'install' failed make: *** [install] Error 2 limnaios@ubuntu:/usr/src/linux-4.10.1$ However, when I use the df -h command I get:
limnaios@ubuntu:/usr/src/linux-4.10.1$ df -h Filesystem Size Used Avail Use% Mounted on udev 3.8G 0 3.8G 0% /dev tmpfs 767M 8.9M 758M 2% /run /dev/mapper/ubuntu--vg-root 213G 34G 168G 17% / tmpfs 3.8G 4.0K 3.8G 1% /dev/shm tmpfs 5.0M 0 5.0M 0% /run/lock tmpfs 3.8G 0 3.8G 0% /sys/fs/cgroup /dev/sda1 236M 75M 150M 34% /boot cgmfs 100K 0 100K 0% /run/cgmanager/fs tmpfs 767M 0 767M 0% /run/user/1002 limnaios@ubuntu:/usr/src/linux-4.10.1$ So, why do I get the message that /boot has no space, even though it's up to 34%?
Update:
df -i returns
Filesystem Inodes IUsed IFree IUse% Mounted on udev 976431 545 975886 1% /dev tmpfs 981097 710 980387 1% /run /dev/mapper/ubuntu--vg-root 14139392 280316 13859076 2% / tmpfs 981097 2 981095 1% /dev/shm tmpfs 981097 4 981093 1% /run/lock tmpfs 981097 17 981080 1% /sys/fs/cgroup /dev/sda1 62248 308 61940 1% /boot cgmfs 981097 13 981084 1% /run/cgmanager/fs tmpfs 981097 4 981093 1% /run/user/1002 while ls -alh /boot/ returns
total 66M drwxr-xr-x 4 root root 1.0K Mar 2 09:49 . drwxr-xr-x 22 root root 4.0K Jan 3 12:09 .. -rw-r--r-- 1 root root 199K Mar 2 09:48 config-4.10.1 -rw-r--r-- 1 root root 199K Mar 2 09:41 config-4.10.1.old -rw-r--r-- 1 root root 196K Mar 1 11:13 config-4.9.13-typoramadspace drwxr-xr-x 5 root root 1.0K Mar 1 17:06 grub -rw-r--r-- 1 root root 33M Mar 1 14:20 initrd.img-4.9.13-typoramadspace drwx------ 2 root root 12K Jun 9 2016 lost+found -rw-r--r-- 1 root root 179K Jan 28 2016 memtest86+.bin -rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+.elf -rw-r--r-- 1 root root 181K Jan 28 2016 memtest86+_multiboot.bin -rw-r--r-- 1 root root 3.5M Mar 2 09:48 System.map-4.10.1 -rw-r--r-- 1 root root 3.5M Mar 2 09:41 System.map-4.10.1.old -rw------- 1 root root 3.9M Mar 1 13:55 System.map-4.9.13-typoramadspace -rw-r--r-- 1 root root 6.8M Mar 2 09:48 vmlinuz-4.10.1 -rw-r--r-- 1 root root 6.8M Mar 2 09:41 vmlinuz-4.10.1.old -rw------- 1 root root 6.8M Mar 1 13:55 vmlinuz-4.9.13-typoramadspace and dpkg -l | grep linux-image returns
ii linux-image-4.9.13-typoramadspace 1 amd64 Linux kernel binary image for version 4.9.13-typoramadspace
df -ialsols -alh /boot/pleasedpkg -l | grep linux-imageandls -lah /bootplease. Your initrd may be too large, or your kernel is statically linked instead of using module in/lib/modules? My 4.9.0 stock Stretch install uses up 34MB in /boot, but then it is a VM without firmware blobs in initrd. As things it is, your /boot is clearly small to have more one version of the kernel+initrd there. If you only have one version installed, and it is already using around 65MB (75MB - grub), it is easy to understand a new, bigger version wont fit in a 150MB partition. Is the previous version compiled too?watch -n1 df -h /bootin a different window (orclear; while :; do tput home; date; echo; df -h /boot; sleep 1; doneif you don't havewatchinstalled.). You will probably see the available disk space shrink to zero... at which point you need to consider either enlarging/boot(typically tricky) or carving a bigger partition out of the disk from somewhere.