Results 1 to 10 of 91

Thread: Linux (Ubuntu, etc)

Threaded View

Previous Post Previous Post   Next Post Next Post
  1. #11
    Subaru Unimpreza SportWagon's Avatar
    Join Date
    Jan 2014
    Location
    The Real Grand Valley, Ontario, Canada
    Posts
    1,418
    Well. that's probably because what I thought had happened had not happened.

    Ubuntu likes to designate a too-small dedicated /boot partition which it then fills with kernels. (Or at one point it started doing this, in any case).

    So it can quite quickly get a system to the state where there is no room for new kernels, even though there's plenty of room for updates, causing needless effective wastage of space (and an inability to apply new updates) as the kernel updates artificially exhaust the space on the small dedicated /boot partition.

    But it looks like that actually was not the problem in this case.

    54G should be enough room for lots of kernel updates.

    Code:
    sportwagon@ubuntu:~$ df -h /boot /
    Filesystem                 Size  Used Avail Use% Mounted on
    /dev/sda1                  134M   68M   57M  55% /boot
    /dev/mapper/CAC_VG-CAC_LV   38G   11G   26G  30% /
    sportwagon@ubuntu:~$
    And now, after a kernel update has been applied...
    Code:
    sportwagon@ubuntu:~$ df -h /boot /
    Filesystem                 Size  Used Avail Use% Mounted on
    /dev/sda1                  134M   97M   28M  79% /boot
    /dev/mapper/CAC_VG-CAC_LV   38G   11G   25G  31% /
    sportwagon@ubuntu:~$
    Note that /boot says "79%" (with 3 alternate kernels).
    One more (new/alternate kernel) would fill that partition up, breaking the update partway through. This has happened to me on this system.

    Sigh...
    Code:
    sportwagon@ubuntu:~$ sudo apt-get autoremove
    [sudo] password for sportwagon: 
    Reading package lists... Done
    Building dependency tree       
    Reading state information... Done
    The following packages will be REMOVED:
      linux-headers-3.13.0-77 linux-headers-3.13.0-77-generic
      linux-image-3.13.0-77-generic linux-image-extra-3.13.0-77-generic
    0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
    After this operation, 271 MB disk space will be freed.
    Do you want to continue? [Y/n] y
    (Reading database ... 116716 files and directories currently installed.)
    Removing linux-headers-3.13.0-77-generic (3.13.0-77.121) ...
    Removing linux-headers-3.13.0-77 (3.13.0-77.121) ...
    Removing linux-image-extra-3.13.0-77-generic (3.13.0-77.121) ...
    run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
    run-parts: executing /etc/kernel/postinst.d/initramfs-tools 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
    update-initramfs: Generating /boot/initrd.img-3.13.0-77-generic
    run-parts: executing /etc/kernel/postinst.d/update-notifier 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
    run-parts: executing /etc/kernel/postinst.d/zz-update-grub 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
    Generating grub configuration file ...
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-3.13.0-83-generic
    Found initrd image: /boot/initrd.img-3.13.0-83-generic
    Found linux image: /boot/vmlinuz-3.13.0-79-generic
    Found initrd image: /boot/initrd.img-3.13.0-79-generic
    Found linux image: /boot/vmlinuz-3.13.0-77-generic
    Found initrd image: /boot/initrd.img-3.13.0-77-generic
    Found memtest86+ image: /memtest86+.elf
    Found memtest86+ image: /memtest86+.bin
    done
    Removing linux-image-3.13.0-77-generic (3.13.0-77.121) ...
    Examining /etc/kernel/postrm.d .
    run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
    update-initramfs: Deleting /boot/initrd.img-3.13.0-77-generic
    run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.13.0-77-generic /boot/vmlinuz-3.13.0-77-generic
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-3.13.0-83-generic
    Found initrd image: /boot/initrd.img-3.13.0-83-generic
    Found linux image: /boot/vmlinuz-3.13.0-79-generic
    Found initrd image: /boot/initrd.img-3.13.0-79-generic
    Found memtest86+ image: /memtest86+.elf
    Found memtest86+ image: /memtest86+.bin
    done
    sportwagon@ubuntu:~$ df -h /boot /
    Filesystem                 Size  Used Avail Use% Mounted on
    /dev/sda1                  134M   68M   57M  55% /boot
    /dev/mapper/CAC_VG-CAC_LV   38G   11G   26G  30% /
    sportwagon@ubuntu:~$ 
    sportwagon@ubuntu:~$ sync
    sportwagon@ubuntu:~$ sync
    sportwagon@ubuntu:~$ sync
    sportwagon@ubuntu:~$ sudo reboot
    In summary, you are not exhibiting the problem I referred to.
    Though my cloud server (above) still is.

    It's not impossible that they changed the default filesystem layout between the two times you did your installation.

    The reason for creating the condition is to arrange that your kernels can be on a bootable filesystem while most of your software and other files (root filesystem) is on a spiffy new filesystem from which you cannot boot. For most users the spiffiiness of the new filesystem does not justify the inconvenience in applying updates. (Though, in reality, you only very rarely need more than one backup version of kernel, so the encouraged "good housekeeping" is overall not a bad thing).
    Last edited by SportWagon; March 15th, 2016 at 06:15 AM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •