Update claims no more space. Inode usage almost full. Manual clean up: missing dep's.

[TheFu]

Passing that resulting URL back here to us, and I will craft up the command to remove them.

Or he could just use the script I posted a link for last week.
I'm lazy, hence the script. It works and won't remove the currently running kernel.

Of course, I haven't read any later posts carefully (just the email notice), if the system isn't booting currently, then using boot-repair may fix it. If not, the boot-repair process will post the current config for us - to craft a grub-update command.

Ok - - so perhaps I haven't been paying enough attention here, but this is running inside a VM? There are many things we can do with that - more options. Which virtualization is being used? Specifics, please.

[Coder68]

It is sitting on an EMC LUN being run by and ESX 5.5 server. I had him restore it today. (The sand-boxed VM is sitting on old hardware.) With the huge medical breach with CHS, I was busy doing other investigations...

I will rerun the steps next week.

Thank you for sticking with me on this. I know it is slow going but I am a single person responsible for a large companies security! Thanks again!

[TheFu]

For out-of-inode issues, create a new vHDD of the size you like, connect both the old (A) and new (B) vHDDs to the same VM, boot off a save-your-butt distro (or live Ubuntu ISO) and move all the data from A to B. If you use fsarchive, the target file system can be grown.

If there is plenty of real space and it is just inodes that are short, use tune2fs or re-allocate the /boot partition with a larger (4x? or 10x?) the number of inodes from the default. Small partitions never seem to get enough inodes - the default estimation calculation used by ext4 was designed for larger partition sizes. Using ext2 (no journal) for /boot isn't a bad idea, though I don't bother on VMs. Personal decision.

[Coder68]

Doing this in the correct order gives me the following error on line 2.

dpkg: warning: there is no installed package matchinglinux-image-3.2.0-43
Same error for each one, 44, 45... 55

The third line ran and appears to be find.

Rebooting.... results in the same error.. even in recovery mode.

VFS: Cannot open root device "sda1" or unknown-block(0,0)

Going back a few kernels allows it to boot.

Now what?

Again, thank you!!!

[Bashing-om]

Coder68; Welp;

Hard to say, a lot of time has past, and things can and do change.
Let's look and see what is:

ls -al /
ls -al /boot
dpkg -l | grep linux-

Fix and remove and see what the status is then.

it is a process

[Coder68]

Here the outputs of ls commands.

[Coder68]

Here are the outputs of dpkg.

Thanks again!

[Bashing-om]

Coder68; shucks !

Can't tell from a screen shot.
The system expects to boot kernel 3.2.0-57 ; (an old one - hummm, why ?), and I can not even tell if that kernel is installed from the screenshot of the output of the 'dpkg' command.

All we know presently is that there exist tons of old kernels that -because of no operating head room - is causing all kinds of problems.

Can you come up with some way to copy and paste the commands outputs , say to a file and transfer the contents back here to the post so the outputs are sensible and formatting is retained ?
What is required at this time is to ascertain what kernel is booting and remove a bunch of these old kernels.
Must keep the kernel that is booting per the symlink in '/'' AND does that link agree with the output of "uname -r" ??
Must keep the kernel that is symlinked as .old in '/'
Must keep the 2 most current kernels ( headers and images)

All the rest need to be gone.

It is as simple as that, but, making it happen - with no head room - may not be so simple.

As templates; you can try something like:

sudo apt-get autoremove linux-image-2.6.32-22-generic linux-image-2.6.32-21-generic
sudo apt-get autoremove linux-headers-2.6.32-22-generic linux-headers-2.6.32-21-generic
##OR maybe and incantation like this may work##
sudo dpkg --purge linux-image-3.2.0-36-generic
sudo dpkg --purge linux-headers-3.2.0-36-generic

Once you have the head room back, then you can see about fixing the remaining kernels and the booting situation.

ain't no step for a stepper

[Coder68]

I will have to physically go to the sandbox and jack into that switch to SSH in. But first I must set it up. I will get back with you soon.

Thanks!

[Coder68]

OK. I finally have got some time starting later this afternoon. I will be able to ssh in to the sandbox as well.

I will give these a try:

sudo apt-get autoremove linux-image-2.6.32-22-generic linux-image-2.6.32-21-generic
sudo apt-get autoremove linux-headers-2.6.32-22-generic linux-headers-2.6.32-21-generic
##OR maybe and incantation like this may work##
sudo dpkg --purge linux-image-3.2.0-36-generic
sudo dpkg --purge linux-headers-3.2.0-36-generic

via SSH and report back. If I cannot fix this by the end of the week, I will have to rebuild it from scratch. The SSL cert is about to expire.

I also need to fix the issue where it will not boot to the most recent kernel. I have to go back several to get it to boot. It needs to auto reboot nightly.