0

I am under Ubuntu 16.04 and my boot partition got full (I couldn't upgrade), so I began to follow answers in some previous questions on what to do. Basically, I used 

~$ sudo apt-get purge linux-image-4.13.0-36

to give it a try, this asked me also to remove dependecies (if I remember correctly) and I frantically accepted. Right after that, I thought about what is the worst case scenario, and after reading

How to restore a system after accidentally removing all kernels?

I got scared as what I would have to go through if it does not boot again if I did something wrong... So the question is basically : how to be sure that everything is still in place to boot without any issue?

If that can help, the following is returned : 

~$ uname -r
4.13.0-43-generic
~$ ls /boot
abi-4.13.0-36-generic         retpoline-4.13.0-36-generic
abi-4.13.0-37-generic         retpoline-4.13.0-37-generic
abi-4.13.0-38-generic         retpoline-4.13.0-38-generic
abi-4.13.0-39-generic         retpoline-4.13.0-39-generic
abi-4.13.0-41-generic         retpoline-4.13.0-41-generic
abi-4.13.0-43-generic         retpoline-4.13.0-43-generic
config-4.13.0-36-generic      System.map-4.13.0-36-generic
config-4.13.0-37-generic      System.map-4.13.0-37-generic
config-4.13.0-38-generic      System.map-4.13.0-38-generic
config-4.13.0-39-generic      System.map-4.13.0-39-generic
config-4.13.0-41-generic      System.map-4.13.0-41-generic
config-4.13.0-43-generic      System.map-4.13.0-43-generic
efi   (in blue)                        vmlinuz-4.13.0-36-generic
grub  (in blue)                        vmlinuz-4.13.0-36-generic.efi.signed
initrd.img-4.13.0-36-generic  vmlinuz-4.13.0-37-generic
initrd.img-4.13.0-37-generic  vmlinuz-4.13.0-37-generic.efi.signed
initrd.img-4.13.0-38-generic  vmlinuz-4.13.0-38-generic
initrd.img-4.13.0-39-generic  vmlinuz-4.13.0-38-generic.efi.signed
initrd.img-4.13.0-41-generic  vmlinuz-4.13.0-39-generic
initrd.img-4.13.0-43-generic  vmlinuz-4.13.0-39-generic.efi.signed
lost+found (in blue)                    vmlinuz-4.13.0-41-generic
memtest86+.bin                vmlinuz-4.13.0-41-generic.efi.signed
memtest86+.elf                vmlinuz-4.13.0-43-generic
memtest86+_multiboot.bin      vmlinuz-4.13.0-43-generic.efi.signed

To avoid any nasty surprise, at the moment I am just closing the top of my laptop which put it in standby mode without shutting it down, but it may become a bit annoying to do that over a long period.

Many thanks!

User20180531
  • 1
  • linux-image packages don't place any config files in /etc, so --remove and --purge do exactly the same thing. Be sure you are using the correct removal flag for your intent when you remove packages that do have files in /etc/. – user535733 May 31 '18 at 17:32
  • You seemed to have used apt to remove an old kernel and it's dependencies. So far, so good. Did it work? Were there errors? (those are important - we need to see those) Is your ls /boot from before or after trying apt? – user535733 May 31 '18 at 17:35
  • What happens if you try sudo apt autoremove? – user535733 May 31 '18 at 17:36
  • The ls /boot is from now. I did not worry at first so can not reproduce the messages that were returned. I could try the sudo apt autoremove but to be sure : would it be problematic to run it if I have installed a new version but have not restarted my computer yet? (this is basically why I had to do this : I could not restart my computer with the installations taking place) – User20180531 May 31 '18 at 17:41
  • Using autoremove means you only keep -43 and -41 on the 4.13.0-xx kernel chain. But to answer your question you look safe right now. – WinEunuuchs2Unix May 31 '18 at 17:46
  • "would it be problematic to run it if I have installed a new version but have not restarted my computer yet?" - Let's rephrase that: It's unwise to remove the currently running kernel regardless of whether it's old or new. Autoremove won't remove the currently-running kernel (it checks), nor the newest two kernels (just in case). Since you seem to already be running the newest kernel that you have, it's a purely hypothetical question. If you are worried, then backup your data before trying it. – user535733 May 31 '18 at 18:05
  • Autoremove (and apt) may fail if your /boot is too full, in which case see https://askubuntu.com/questions/89710 – user535733 May 31 '18 at 18:10
  • Many thanks for the clarifications! I'll backup everything before trying that. – User20180531 May 31 '18 at 19:40
  • For information, 'sudo apt autoremove' perfectly worked, many thanks! – User20180531 Jun 17 '18 at 14:57

0 Answers0