Ceci est une ancienne révision du document !
My work normally entails running the daily operations of our Computer Recycling/Refurbishing Project, but I’m also part of our organization’s IT Team, and as such sometimes (very rarely) get called on to solve issues in other parts of the organization. Our organization runs Windows on the desktop for most of the staff, but there are a few areas of the organization where the staff use Linux. Recently, I was asked to solve an issue at one of the locations we use Linux on the desktop. The way the issue was initially described to me sounded like a possible hardware issue - the system would start booting then hang at a black screen.
When I arrived on site, I confirmed that the system was just sitting on a black screen with a non-blinking cursor line in the top left of the screen. The normal behaviour for this machine was to boot to a LightDM login screen for Xubuntu Linux. I tried CTRL+ALT+F1 to switch to a virtual terminal, it didn’t work.
I powered the system down and powered it up again to the same result. I repeated the process this time hitting the TAB key a few times and pressing CTRL+ALT+F1 for the first virtual terminal; this time I successfully brought up a terminal login.
Earlier in the week, I had one of our Computer Recycling clients bring in a laptop where the xserver configuration file had become corrupted. This problem had some similarities to the laptop issue, so I tried:
sudo dpkg-reconfigure xserver-xorg-video-intel
It was when I tried the dpkg-reconfigure command that I got an error about the system being out of space. (Note: if you’re trying this on your system, you’ll want to choose the xserver your graphics card is set for - for example: xserver-xorg-video-nvidia). Running df -h / showed the system actually had about 7GB of space left. The drive on this particular system was really small (40GB) but, with 7GB free, it shouldn’t have been complaining that it was out of space.
Puzzled I decided to try installing gparted (to both check and resize the drive). When I tried installing gparted, I got a message saying that the system couldn’t write to /var/cache. I tried to fix the issue with:
sudo apt-get -f install
It was at this moment that I noticed an inordinate amount of kernel images. This was the eureka moment, literally pages of kernel images had been left on the system. Removing old images was simple (or so I thought):
sudo apt-get autoremove
This would have worked except the system was out of space (on /usr) and broken. In order to free up a bit of space to run the apt-get -f install and apt-get autoremove, I manually removed a couple of the kernel images. I chose images that were neither the oldest nor the newest, and then ran:
sudo rm -rf /usr/src/linux-headers-4.0.3-20-generic
sudo rm -rf /usr/src/linux-headers-4.0.3-20
Note: the two lines above are an example (always be careful removing any part of the system that may be critical).
After manually removing a couple of sets of linux kernel headers, I was able to run:
sudo apt-get autoremove
Removing the old kernel images took nearly 1 hour. As a kernel image is removed, grub2 regenerates the grub2 boot file. Remove an image, regenerate the grub2 boot file, rinse and repeat – until all the extra kernel images were removed. This freed up 14.9GB of drive space on the tiny drive.
I’d previously tried to install gparted and it failed because of the full drive. Now that the drive had more space, I was able to run sudo apt-get -f install to complete the installation. While we have unattended updates that run on this particular machine, those updates had stopped a few days earlier because of the full drive, so I also ran sudo apt-get update && sudo apt-get upgrade to upgrade the system to the latest packages.
On reboot, the machine loaded the LightDM login screen and the staff were able to login to the machine normally.