[clug] Ubuntu jerkiness
Rodney Peters
rodneyp at iinet.net.au
Wed Dec 11 04:02:17 UTC 2019
On 2019-12-11 10:13, Elena Williams via linux wrote:
> As a rule I don't like being identifiable when asking technical questions,
> but you know, we're trying to get better as people and I just posted a
> lengthy and probably pretty basic question to StackOverflowUbutnut and it
> occured to me that I actually have fellow Linux users in my environs so
> would be remiss not ask you guys also.
>
> Any advice on this matter is appreciated, it's probably just an Ubutnut
> thing and something I try not to waste any time thinking about unless (like
> now) it's shoved in my face.
>
> https://askubuntu.com/questions/1195289/not-enough-free-disk-space-when-upgrading-prevention
>
> ---
>
> The error introduced in the following question has been driving me nuts
> since at least 2014: Not enough free disk space when upgrading
> <https://askubuntu.com/questions/298487/not-enough-free-disk-space-when-upgrading>
>
> Error:
>
> The upgrade needs a total of x M free space on disk `/boot`.
> Please free at least an additional y M of disk space on `/boot`.
> Empty your trash and remove temporary packages of former installations
> using `sudo apt-get clean`.
>
> So to be clear: this is a different question -- I can clean up old images
> (though it's a tedious annoying waste of time, a range of ways (none of
> which are awesome) is presented here:
> https://linoxide.com/booting/remove-old-kernel-versions-boot-menu/).
>
> Back in the old days I used to do partitioning myself so I felt like I
> deserved it and it annoyed me but I was fussy about my partitions.
>
> With my latest brand new from scratch main installation the partitions were
> created automagically as default by the wizard. I do my best to act like a
> "normal" pure user and go with the Ubuntu flow. I do regular updates. I
> haven't had the dreaded /boot is full error in ages.
>
> Suddenly now I'm getting it again, through (what I think is) no fault of my
> own.
> ------------------------------
>
> *My question is*:
>
> Is this the expected Ubuntu life-cycle workflow?
>
> Is it just me or is it that you'll have an installation and then after a
> while it'll start throwing this error and you'll have to manually go
> through and play purge lotto with old kernels?
>
> Of course if you don't resolve this error you can't run updates any more
> (as /boot is full).
>
> Maybe this is just something I personally am doing wrong or is this just
> something that will happen to any installation over time?
>
> Is there some maintenance routine I'm missing that will obviate this
> situation?
>
> This is irritating and importantly time-wasting for *me* -- but the risk is
> that Ubuntu is not suitable for "non technical" users (teaching my old Dad
> to cherry-pick out redundant kernel versions yeah-nah).
>
> It is a terrifying idea that the nett effect may be that if by using all
> the defaults an "average" user will just stop receiving updates after a
> while.
> ------------------------------
>
> Note: running sudo apt-clean clean returns no output for me.
>
> My current output of dpkg -l | grep linux-image (after running apt clean
> and apt --purge autoremove):
>
> rc linux-image-4.15.0-13-generic 4.15.0-13.14
> amd64 Linux kernel image for version 4.15.0 on
> 64 bit x86 SMP
> rc linux-image-4.15.0-23-generic 4.15.0-23.25
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-29-generic 4.15.0-29.31
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-30-generic 4.15.0-30.32
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-32-generic 4.15.0-32.35
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-33-generic 4.15.0-33.36
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-34-generic 4.15.0-34.37
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-36-generic 4.15.0-36.39
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-38-generic 4.15.0-38.41
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-39-generic 4.15.0-39.42
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-42-generic 4.15.0-42.45
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-43-generic 4.15.0-43.46
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-44-generic 4.15.0-44.47
> amd64 Signed kernel image generic
> rc linux-image-4.15.0-45-generic 4.15.0-45.48
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-15-generic 4.18.0-15.16
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-16-generic 4.18.0-16.17
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-17-generic 4.18.0-17.18
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-18-generic 4.18.0-18.19
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-20-generic 4.18.0-20.21
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-21-generic 4.18.0-21.22
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-22-generic 4.18.0-22.23
> amd64 Signed kernel image generic
> rc linux-image-4.18.0-25-generic 4.18.0-25.26
> amd64 Signed kernel image generic
> rc linux-image-5.0.0-25-generic 5.0.0-25.26
> amd64 Signed kernel image generic
> rc linux-image-5.0.0-27-generic 5.0.0-27.28
> amd64 Signed kernel image generic
> rc linux-image-5.0.0-29-generic 5.0.0-29.31
> amd64 Signed kernel image generic
> rc linux-image-5.0.0-31-generic 5.0.0-31.33
> amd64 Signed kernel image generic
> rc linux-image-5.0.0-32-generic 5.0.0-32.34
> amd64 Signed kernel image generic
> ii linux-image-5.0.0-36-generic 5.0.0-36.39
> amd64 Signed kernel image generic
> ii linux-image-5.0.0-37-generic 5.0.0-37.40
> amd64 Signed kernel image generic
> rc linux-image-extra-4.15.0-13-generic 4.15.0-13.14
> amd64 Linux kernel extra modules for version
> 4.15.0 on 64 bit x86 SMP
> ii linux-image-generic 5.0.0.37.39
> amd64 Generic Linux kernel image
I'm not an Ubuntu fan, but use it, under sufferance, in KDE Neon. I
keep the latter mainly as a starting point for newbies. It runs 18.04
LTS - for longevity.
I see that it has retained 8 kernels after only a couple of months
usage, not withstanding the presence of the
etc/kernel/postinst.d/apt-auto-removal file. Not a major problem for me
- I installed to btrfs, which is my standard practice for SSD and that
did not create a separate boot partition.
It does appear that the kernels you have date from the 18.04 era.
Perhaps upgrade to 19.04, although that might lose LTS ?
Rod
More information about the linux
mailing list