Package system broken, update failed, keyboard failed on boot, root partition full

Bug #1333386 reported by markling
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
update-manager (Ubuntu)
Invalid
Undecided
Unassigned

Bug Description

Repeated failure of xubuntu/ubuntu updates repeatedly causes my system to crash severely.

I recently had to reinstall my operating system after a failed update. I may now have to do it again.

The cause is this perennial problem of the root partition getting full up within weeks of a fresh install. The o/s is not able to administer its partitions properly. This is a severely obstructive problem.

Most recently:

15 June 2014 -> routine updates to Xubutnu 14.04 (Ubuntu 'Trusty' LTS).

The update crashed with the following message:

"The package system is broken. If you are using 3rd party repositories then disable them since they are a common source of problems. Now run the following command in a terminal: sudo apt-get install -f"

I had standard repository options enabled for Canonical Partners and independent providers. I unticked these and ran the command. It said:

"""
The following packages have unmet dependencies:

linux-signed-image3.13.0-29-generic
Depends:
linux-image-3.13.0-29-generic (=3.13.0-29.53)
but 3.13.0-29.53 is installed
Depends:
linux-image-extra-3.13.0-29-generic (=3.13.0-29.53)
but is not installed
linux-signed-image-generic
Depends:
linux-firmware
"""

The operation rendered my computer unusable.

On restarting my machine, my keyboard didn't work at the encryption password prompt. I tried some obvious ways to get round this but without success. (E.g. I tried booting from the most recent CD I had to hand (Ubuntu 12.10). Booted okay but it did not recognize any of my encryption passwords so I could not get at my data).

The keyboard worked during Bios startup. I could use it to operate my boot menus. It just froze when the o/s loaded. It is most important as a user that I stress this point: I *eventually* found out that I could opt to load a different kernel and thus gained access to my computer.

I booted using the 3.13.0-24-generic option instead of the 3.13.0-29-generic option my o/s wanted to load as default.

But this did not solve the o/s problem.

I tried looking in Synaptic (a tool I must confess does not get used because I am not an administrator, I am a user and Synatpic is out of my comfort zone).

Synaptic said:

"You have two broken packages on your system. Use Broken filter to locate them".

I did this. Synaptic showed my two broken packages:

linux-signed-image-3.13.0-29.generic
installed version: 3.13.0-29.53

linux-signed-image-generic
installed version: 3.13.0-29.35

Thinking it was time to file a bug report (and contemplating whether switching back to Windows was the lesser horror or whether I should just accept that I must reinstall linux every few weeks), I ran the Software Center - I remembered that the Software Center had an option that displayed update history and I reckoned this might be useful info for a bug report.

Software Updater said on starting:

"New software cannot be installed because there's a problem with the software currently installed".

It gave two options: <cancel> <repair>

It is interesting to note here that the only point when the system offered to repair the broken update was not when it happened, nor after restart when its failures became apparent, but after a prolonged, distressful attempt to rescue lost data and a chance invocation of the Software Center.

This presupposes that your system isn't broken. Because if it was then you wouldn't be able to run the Software Center, unless you happened to know that you can rescue a system by loading an old kernel image. Assuming you had not in your amateur struggles with linux's prohibitively thorny bugs not deleted all your old kernel images, your only chance of knowing this as a mere user is after years of hair-wrenching trial and error: because there is nothing inherently instructive, guiding or instinctual about linux that would lead a user to this knowledge.

I clicked <repair>.

The repair failed. Software Center said:

"The new software couldn't be installed because there is a problem with the software currently installed.. Do you want to repair the problem now?"

It gave two options: <cancel> <repair>

Its error output read as follows:

"""
installArchives() failed: (Reading database ...
(Reading database ... 5%
(Reading database ... 10%
(Reading database ... 15%
(Reading database ... 20%
(Reading database ... 25%
(Reading database ... 30%
(Reading database ... 35%
(Reading database ... 40%
(Reading database ... 45%
(Reading database ... 50%
(Reading database ... 55%
(Reading database ... 60%
(Reading database ... 65%
(Reading database ... 70%
(Reading database ... 75%
(Reading database ... 80%
(Reading database ... 85%
(Reading database ... 90%
(Reading database ... 95%
(Reading database ... 100%
(Reading database ... 274586 files and directories currently installed.)
Preparing to unpack .../linux-image-extra-3.13.0-29-generic_3.13.0-29.53_amd64.deb ...
Unpacking linux-image-extra-3.13.0-29-generic (3.13.0-29.53) ...
dpkg: error processing archive /var/cache/apt/archives/linux-image-extra-3.13.0-29-generic_3.13.0-29.53_amd64.deb (--unpack):
 cannot copy extracted data for './lib/modules/3.13.0-29-generic/kernel/drivers/media/usb/cx231xx/cx231xx.ko' to '/lib/modules/3.13.0-29-generic/kernel/drivers/media/usb/cx231xx/cx231xx.ko.dpkg-new': failed to write (No space left on device)
No apport report written because the error message indicates a disk full error
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Examining /etc/kernel/postrm.d .
run-parts: executing /etc/kernel/postrm.d/initramfs-tools 3.13.0-29-generic /boot/vmlinuz-3.13.0-29-generic
run-parts: executing /etc/kernel/postrm.d/zz-update-grub 3.13.0-29-generic /boot/vmlinuz-3.13.0-29-generic
Preparing to unpack .../linux-firmware_1.127.2_all.deb ...
Unpacking linux-firmware (1.127.2) ...
dpkg: error processing archive /var/cache/apt/archives/linux-firmware_1.127.2_all.deb (--unpack):No apport report written because the error message indicates a disk full error

 cannot copy extracted data for './lib/firmware/rtlwifi/rtl8188eufw.bin' to '/lib/firmware/rtlwifi/rtl8188eufw.bin.dpkg-new': failed to write (No space left on device)
dpkg-deb: error: subprocess paste was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/linux-image-extra-3.13.0-29-generic_3.13.0-29.53_amd64.deb
 /var/cache/apt/archives/linux-firmware_1.127.2_all.deb
Error in function:
dpkg: dependency problems prevent configuration of linux-signed-image-generic:
 linux-signed-image-generic depends on linux-firmware; however:
  Package linux-firmware is not installed.

dpkg: error processing package linux-signed-image-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-signed-generic:
 linux-signed-generic depends on linux-signed-image-generic (= 3.13.0.29.35); however:
  Package linux-signed-image-generic is not configured yet.

dpkg: error processing package linux-signed-generic (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of linux-signed-image-3.13.0-29-generic:
 linux-signed-image-3.13.0-29-generic depends on linux-image-extra-3.13.0-29-generic (= 3.13.0-29.53); however:
  Package linux-image-extra-3.13.0-29-generic is not installed.
"""

If you happen to be either paid, nerd or fool enough to look closely at this output you might discern that the problem was a disk full problem. (E.g. "failed to write (No space left on device)").

If you have been using linux for any amount of time (and incredibly - are still using it), you might recognize in this the recurring nightmare that is the root or boot partition getting full of refuse.

It seems the nightmare has just got worse. For all the wails of pain. For all the bug reports and appeals for help. It has got worse.

The innumerable how-to-fix posts you will find for this bug typically lead to the discovery of a huge pile of trash that the o/s has left the user to clean up - in the form of old kernel images and their associated refuse. Really, an o/s that lets its trash pile up till it breaks the system and puts the user back in hell, again and again and again - it's a curse.

It all becomes a bit too much. You get sort of punch drunk as a user. The last time this error occurred, I looked up for the fix again, and came across some post on an official Ubuntu forum with a command to automate the process. I giddily typed it in. And it broke my system. I had urgent work deadlines. It is quicker to reinstall the o/s from scratch than to try and resolve the problem in forum hell.

But this wasn't the problem this time.

I probably will just reinstall the o/s. But for the sake of a bug report, I tried to find out more about it.

It was not a boot full problem, as is often reported:

$ df -h /boot
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 236M 71M 153M 32% /boot

It was a root full problem:

# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/Bonzo--vg-root 314M 287M 6.8M 98% /

But there's nothing in my root to that uses as much as this reported 278M. Only 64M is in use, according to a listing:

-rw-r--r-- 1 root root 1.2M May 3 01:30 abi-3.13.0-24-generic
-rw-r--r-- 1 root root 1.2M Jun 4 22:57 abi-3.13.0-29-generic
-rw-r--r-- 1 root root 162K May 3 01:30 config-3.13.0-24-generic
-rw-r--r-- 1 root root 162K Jun 4 22:57 config-3.13.0-29-generic
drwxr-xr-x 5 root root 1.0K Jun 15 19:18 grub
-rw-r--r-- 1 root root 25M May 17 01:02 initrd.img-3.13.0-24-generic
-rw-r--r-- 1 root root 13M Jun 15 19:18 initrd.img-3.13.0-29-generic
drwx------ 2 root root 12K May 6 20:33 lost+found
-rw-r--r-- 1 root root 173K Mar 12 12:31 memtest86+.bin
-rw-r--r-- 1 root root 174K Mar 12 12:31 memtest86+.elf
-rw-r--r-- 1 root root 175K Mar 12 12:31 memtest86+_multiboot.bin
-rw------- 1 root root 3.3M May 3 01:30 System.map-3.13.0-24-generic
-rw------- 1 root root 3.3M Jun 4 22:57 System.map-3.13.0-29-generic
-rw------- 1 root root 5.6M May 3 01:30 vmlinuz-3.13.0-24-generic
-rw------- 1 root root 5.6M May 6 20:50 vmlinuz-3.13.0-24-generic.efi.signed
-rw------- 1 root root 5.6M Jun 4 22:57 vmlinuz-3.13.0-29-generic

It is also looks like I am not overflowing with the trash that usually causes this problem. There appear to be only two kernel images here. So what on earth has caused the trouble?

I got the listing after following the instructions here:

http://askubuntu.com/questions/266825/what-do-i-do-when-my-root-filesystem-is-full

(Just one of many, many fixes for this bug you will find online if you want to dizzy yourself with trying to find a solution and have nothing better to do, like earn a living).

That bug fixer's suggestions did not apply to my case. It said, for example:

1. I have might have core dumps filling up the disk.

I used its given command to learn that this is not my problem.

2. I might have unnecessary packages filling up my disk:

Following its instructions here just repeated the error I'm trying to correct:

# apt-get autoremove --purge
Reading package lists... Done
Building dependency tree
Reading state information... Done
You might want to run ‘apt-get -f install’ to correct these.
The following packages have unmet dependencies.
 linux-signed-image-3.13.0-29-generic : Depends: linux-image-extra-3.13.0-29-generic (= 3.13.0-29.53) but it is not installed
 linux-signed-image-generic : Depends: linux-firmware but it is not installed
E: Unmet dependencies. Try using -f.

3. It also said I might have outdated kernel packages - but there's only two installed:

# dpkg -l "linux*" |grep ^.i
ii linux-headers-3.13.0-24 3.13.0-24.47 all Header files related to Linux kernel version 3.13.0
ii linux-headers-3.13.0-24-generic 3.13.0-24.47 amd64 Linux kernel headers for version 3.13.0 on 64 bit x86 SMP
ii linux-headers-3.13.0-29 3.13.0-29.53 all Header files related to Linux kernel version 3.13.0
ii linux-headers-3.13.0-29-generic 3.13.0-29.53 amd64 Linux kernel headers for version 3.13.0 on 64 bit x86 SMP
ii linux-headers-generic 3.13.0.29.35 amd64 Generic Linux kernel headers
ii linux-image-3.13.0-24-generic 3.13.0-24.47 amd64 Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii linux-image-3.13.0-29-generic 3.13.0-29.53 amd64 Linux kernel image for version 3.13.0 on 64 bit x86 SMP
ii linux-image-extra-3.13.0-24-generic 3.13.0-24.47 amd64 Linux kernel extra modules for version 3.13.0 on 64 bit x86 SMP
ii linux-libc-dev:amd64 3.13.0-29.53 amd64 Linux Kernel Headers for development
ii linux-signed-image-3.13.0-24-generic 3.13.0-24.47 amd64 Signed kernel image generic
ii linux-sound-base 1.0.25+dfsg-0ubuntu4 all base package for ALSA and OSS sound systems

The problem appears to be partly caused by the Xubuntu installer (and many other linux installers by the look of all the people plagued with this problem). I.e. I used the standard options given by the installer, if I remember correctly. It says, do you want to have encryption, separate partitions and LVM. I tell it, having come to the conclusion after years of using linux that these standard install options are desirable, 'yes, yes and yes'. It has left itself without adequately-sized partitions, and me with a headache and the inglorious task that befalls a user who cares enough, of complaining.

Tags: bugs
Revision history for this message
markling (markling) wrote :

btw, this is not a Thunar bug.

In the box where it asks what package this bug affects, I wrote, 'software-updater'. But Launchpad took it as a Thunar bug all the same. Probably because I was on the page of another Thunar bug when I selected 'report-bug'. I suspect it's also a Grub bug.

Revision history for this message
markling (markling) wrote :

Would someone be kind enough to change this from 'Thunar' bug to 'Software-updater' bug?

I do not appear to have the facility to do this.

affects: thunar (Ubuntu) → update-manager (Ubuntu)
Changed in update-manager (Ubuntu):
status: New → Incomplete
Changed in update-manager (Ubuntu):
status: Incomplete → Opinion
status: Opinion → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.