Looks like you'll have to free up space and complete that installation, either by temporarily moving files off of the /boot partition, or by expanding it. What do you get from "dpkg -l | grep linux-image" ?
Looks like you'll have to free up space and complete that installation, either by temporarily moving files off of the /boot partition, or by expanding it. What do you get from "dpkg -l | grep linux-image" ?
brian@brian-HP-SpectreXT-Pro-13-b000-PC:~$ dpkg -l | grep linux-image
ii linux-image-4.10.0-28-generic 4.10.0-28.32~16.04.2 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-32-generic 4.10.0-32.36~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-33-generic 4.10.0-33.37~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-35-generic 4.10.0-35.39~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-37-generic 4.10.0-37.41~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-38-generic 4.10.0-38.42~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-40-generic 4.10.0-40.44~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
ii linux-image-4.10.0-42-generic 4.10.0-42.46~16.04.1 amd64 Linux kernel image for version 4.10.0 on 64 bit x86 SMP
iF linux-image-4.13.0-26-generic 4.13.0-26.29~16.04.2 amd64 Linux kernel image for version 4.13.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-28-generic 4.10.0-28.32~16.04.2 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-32-generic 4.10.0-32.36~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-33-generic 4.10.0-33.37~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-35-generic 4.10.0-35.39~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-37-generic 4.10.0-37.41~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-38-generic 4.10.0-38.42~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
ii linux-image-extra-4.10.0-40-generic 4.10.0-40.44~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
iF linux-image-extra-4.10.0-42-generic 4.10.0-42.46~16.04.1 amd64 Linux kernel extra modules for version 4.10.0 on 64 bit x86 SMP
iU linux-image-extra-4.13.0-26-generic 4.13.0-26.29~16.04.2 amd64 Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
rH linux-image-extra-4.13.0-32-generic 4.13.0-32.35~16.04.1 amd64 Linux kernel extra modules for version 4.13.0 on 64 bit x86 SMP
brian@brian-HP-SpectreXT-Pro-13-b000-PC:~$
Yikes!
I wondered about manually moving files, but honestly I wouldn't know how to start doing that.
Today was my Mr. Mom day, so I haven't had much time to look into this.
OK so the good news is that you have plenty of old kernels to delete, this should be easy, you may not even need to move files manually! You're running 4.10.0-42, anything with other version numbers is fair game for deletion.
To get a full picture of all your kernel packages, also do "dpkg -l | grep linux-headers"
So I'd recommend you start with "sudo apt-get remove linux-image-4.10.0-40-generic" (Edit: Start with the newest ones you're not using since files related to these are most likely to be on /boot), if that works then the hard part is done, clear out the corresponding header and extra packages for the same version, then clear out all of the other old ones and you should be able to fix your broken packages.
The removal may fail due to the complete lack of free space though. In that case, you'll need to manually move some files off your /boot partition temporarily. The easiest thing for you to move, with me giving you advice remotely, is actually one of the most dangerous things to move, your initrd image (/boot/initrd.img-kernelversionhere-generic) (Edit: If you have more than one, in which case it's a very safe thing to do, move the one with the oldest version number). You can think of this as Linux's starter solenoid, it can run but can't boot without it. It's a single relatively big file that's easy to find and it's regenerated with kernel or bootloader upgrades. Move that, try again, and do your upgrades. When they're done you should see a new initrd file in its place (assuming you have only one), in which case you can delete the one you moved.
Once the problem is fixed we'll have to look into limiting the number of kernel versions that are kept.
Ok, the removal did fail with the same error message.
So I went here:
And tried to move the oldest one, then I got a permission error. WTF? I checked my permissions and am listed as admin on this thing.
brian@brian-HP-SpectreXT-Pro-13-b000-PC:/boot$ mv /boot/initrd.img-4.10.0-28-generic ~/desktop
mv: cannot remove '/boot/initrd.img-4.10.0-28-generic': Permission denied
brian@brian-HP-SpectreXT-Pro-13-b000-PC:/boot$
More than likely I'm not doing it correctly...
You almost did it correctly, you should've run "sudo mv /boot/initrd.img-4.10.0-28-generic ~/desktop". You need root permissions to do anything in the /boot directory.
Um, duh on my part- lol!
You are the MAN!
The extraneous "intrids" were all moved to ~/Desktop, and "sudo apt-get remove linux-image-4.10.0-40-generic" completed successfully. The last part may not have been necessary, but it felt good to do.
This brought the /boot/ disk usage down from 100% to 39%.
"sudo apt-get update" and "sudo apt-get upgrade" finally completed with only one error, which didn't surprise me too much:
After all that I restarted the computer and all is well.
I can't tell you how much I appreciate your help!
If you are willing to offer advice on how I can be a responsible Linux user from now on, I am all ears.
OK, you're not out of the woods yet, now you have to uninstall all or at least most of the old kernels, or /boot could refill with the next upgrade.
Edit: No need to move files back since you only moved initrds.
Later I'll try to find a way to limit the number of old kernels. I've found a way to purge them all at once but that's not ideal.
OK try this: "sudo apt-get install byobu" and then "sudo purge-old-kernels --help"
Success x2.
I am so down with Super Cow Powers.
Next, make a file with the contents
#! /bin/sh
purge-old-kernels --keep 3
And use root privileges to copy it to /etc/cron.weekly/prune-kernels, then do "sudo chmod 755 /etc/cron.daily/prune-kernels" to give the script the proper permissions. Now your computer will try to clear out all but the 3 newest kernel versions once per week, which should be plenty enough to prevent another partition-filling buildup.
(What you're actually saving space with is the initrd and other boot files for each kernel, rather than the kernel packages themselves)
Following your advice, I wonder if I stumbled onto part of the reason the kernels weren't being pruned in the first place.
My as-found directory showed /etc/cron.weekly. There was no /prune-kernels. The same is true for /etc/cron.daily, there was no /prune-kernels.
Unless I was supposed to create those sub directories?
I was able to create the file and then copy it into /etc/cron.weekly. But the command "sudo chmod 755 /etc/cron.daily/prune-kernels" didn't work (of course) because of the sub-directory not being there.
So should I create those sub directories? Or maybe try "sudo chmod 755/etc/cron.daily"? I wonder if that would even work because the file isn't there...
I am late to the party. The only thing I can add is that when a process is stuck because a file doesn't exist you can create an empty file using the touch command. It creates an empty file that can be deleted by the process.
To find out more you can "touch --help", or the better way is "man touch"
paranoid_android said:Following your advice, I wonder if I stumbled onto part of the reason the kernels weren't being pruned in the first place.
My as-found directory showed /etc/cron.weekly. There was no /prune-kernels. The same is true for /etc/cron.daily, there was no /prune-kernels.
Unless I was supposed to create those sub directories?
I was able to create the file and then copy it into /etc/cron.weekly. But the command "sudo chmod 755 /etc/cron.daily/prune-kernels" didn't work (of course) because of the sub-directory not being there.
So should I create those sub directories? Or maybe try "sudo chmod 755/etc/cron.daily"? I wonder if that would even work because the file isn't there...
Not a sub-directory, a file. prune-kernels is the name of the new script file (no extension) and you put it in /etc/cron.weekly
Ok, I got that far. :-)
I'm glad it seems to be working out for you. Sorry I couldn't get over there to help you out.
You'll need to log in to post.
