<div dir='auto'>Thank you all for all the helpful advice and comments 😊 I think I'll have to get into the habit of running autoremove on a regular basis after downloading and testing a new / updated kernel.<div dir="auto"><br></div><div dir="auto">Many thanks all!</div><div dir="auto"><br></div><div dir="auto">Cheers,</div><div dir="auto">Bill 😊</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 Sep 2019 11:13, Sam Braithwaite via Swlug <swlug@mailman.lug.org.uk> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Hi Bill & Marcus. I also run apt-get autoremove after a kernel upgrade, <br>
although I think if you want to be completely safe you should try <br>
rebooting into the new kernel first, as after you've run autoremove, I <br>
don't think you'll have the option to boot into your old kernel again, <br>
so if you had problems with the new kernel you'd be stuck. (I think this <br>
is in reality quite rare, but I seem to remember I have had problems <br>
with this in the past relating to proprietary graphics drivers - anyone <br>
else know any more about this?)</p>
<p dir="ltr">Sam<br></p>
<p dir="ltr">On 20/09/2019 10:20, Marcus Davage via Swlug wrote:<br>
> Hi Bill. I've been a happy user of Linux Mint for years and years, on <br>
> all my home equipment. I just have a mental note to run autoremove each <br>
> time I'm prompted to upgrade the kernel.<br>
> <br>
> Side note: had an IFA around the other night, who was running Linux Mint <br>
> on his laptop. He emailed me a password encrypted zip file, which <br>
> Archive Manager wouldn't extract. I ended up having to install another <br>
> zip manager and use that. (After unzipping it on my OnePlus phone first!)<br>
> <br>
> Marcus<br>
> <br>
> On Wed, 18 Sep 2019, 12:26 Bill Thomson via Swlug, <br>
> <swlug@mailman.lug.org.uk <mailto:swlug@mailman.lug.org.uk>> wrote:<br>
> <br>
> Thanks Mark, that's useful to know 🙂 I guess I'll just run<br>
> autoremove every so often to keep the /boot partition reasonably clean.<br>
> <br>
> Many thanks,<br>
> <br>
> Bill<br>
> <br>
> On 18 Sep 2019 12:12, Mark Einon via Swlug <swlug@mailman.lug.org.uk<br>
> <mailto:swlug@mailman.lug.org.uk>> wrote:<br>
> <br>
> Be careful doing this!<br>
> <br>
> Not all systems/distros can read all filesystem types prior to<br>
> initrd<br>
> booting (as this is done by the bootloader).<br>
> <br>
> One of the compelling reasons for having a separate /boot is<br>
> that it's<br>
> formatted in a known supported FS, whilst you can have any Linux-<br>
> supporting FS for your main partiton.<br>
> <br>
> Mark<br>
> <br>
> On Wed, 2019-09-18 at 10:10 +0100, Colin Law via Swlug wrote:<br>
> > On Wed, 18 Sep 2019 at 10:04, Bill Thomson via Swlug<br>
> > <swlug@mailman.lug.org.uk <mailto:swlug@mailman.lug.org.uk>><br>
> wrote:<br>
> > > Hi Colin, that seems to have done the trick! I've freed up<br>
> in excess<br>
> > > of 2Gb in the boot directory - thank you!<br>
> > ><br>
> ><br>
> > For future reference I believe it is generally considered<br>
> better not<br>
> > to have a separate partition for /boot as it can give rise to<br>
> this<br>
> > problem. Just put /boot in the main root (/) partition so<br>
> that it<br>
> > will not fill up. If it /boot actually fills up completely<br>
> it can be<br>
> > a big pain to recover as you can't then run autoremove, you<br>
> have to<br>
> > manually remove the old kernels.<br>
> ><br>
> > Colin<br>
> ></p>
<p dir="ltr">___________________________________________
<br>
This email has been scanned by iomartcloud.
<br>
http://www.iomartcloud.com/
<br></p>
<p dir="ltr">-- <br>
Swlug mailing list<br>
Swlug@mailman.lug.org.uk<br>
https://mailman.lug.org.uk/mailman/listinfo/swlug</p>
</blockquote></div><br></div>