It is appstream, fix is:

  cd /tmp && mkdir asfix
  cd asfix
  wget https://launchpad.net/ubuntu/+archive/primary/+files/appstream_0.9.4-1ubuntu1_amd64.deb
  wget https://launchpad.net/ubuntu/+archive/primary/+files/libappstream3_0.9.4-1ubuntu1_amd64.deb
  sudo dpkg -i libappstream3*.deb
  sudo dpkg -i appstream*.deb

Can confirm, this fixed it. However, now gotta do the same thing on all the grandma's and neighbors' laptops .. fml ..

Symptoms: apt-get update hangs, and the appstreamcli process is using 100% CPU.

Fix described here: https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/157...

Here comes the expected complaint: Ubuntu is supposed to be the user friendly distro, right?

It seems an unfair thing to say until you experience it, or your loved one does. My SO uses gnome-ubuntu, and I am at a loss to explain why firefox crashes multiple times a week on her PC. On my gentoo box? I think the browser hasn't crashed randomly in...months? And I am on ~arch at least for firefox so they are the same version afaik.

Gentoo doesn't have as many devoted, paid testers from what I understand as Canonical does, so how is their stability relatively worse?

I actually put Arch on my SOs laptop, because I knew that Ubuntu would probably break in some way in a couple of months. But I'd probably go with openSUSE if I needed to reinstall GNU/Linux (the community has put a lot of work into stability as well as having up to date software).

Does arch have something like Software in their gnome 3? My SO isn't as into tech stuff and I wanted it to be easier for them to install stuff without having to google or know apt/emerge/pacman

Yes, it is possible to use package management GUIs in Arch. https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#...

Yeah, there's front-ends for pacman. They're usually ... okay. The only issue is that you usually need to install stuff from the AUR (which won't ever get updated by default unless your GUI supports yaourt).

The main problem that I have with unattended Ubuntu for family is that eventually /boot fills-up with old kernels and updates start to fail.

I don't believe they have resolved this despite having been a problem for years.

How necessary is it to have a separate /boot partition these days though? I have one because my root is LUKS-encrypted, but I think Grub could handle booting from an unencrypted ext4 root. I guess it would still fill up eventually, but maybe not before a re-install for other reasons.

Grub can actually handle booting from an encrypted ext4 root as well, no /boot needed. You do end up entering the password twice by default, but that can be dealt with by using a key file.

Lots of blog posts out there with instructions to convert existing installations, for example http://dustymabe.com/2015/07/06/encrypting-more-boot-joins-t...

On UEFI systems, the /boot partition needs to be FAT32. So there's that. :P

The UEFI system partition is mounted at /boot/efi. /boot itself can be a regular filesystem, or part of the root filesystem if you have no unusual requirements.

Depends what bootloader you use. Gummiboot (thus systemd-boot) can't handle having the EFI loader and the kernels on different partitions (thus having /boot and /boot/efi separate has questionable benefits). Not to mention that full disk encryption causes problems with /boot.

That isn't necessarily a problem; Debian handles this by means of a kernel postinst hook that copies the newly-installed kernel from its installed location in /boot to /boot/efi/EFI/DEBIAN (or wherever gummiboot expects to find the kernel, I can't remember off the top of my head).

That systemd refuses to support anything other then EFI at /boot puts it into opposition with existing practice (as seen in Debian, Ubuntu, Fedora and SUSE).

I would expect all of those to fall in line with systemd soon enough...

    sudo crontab -e 

and put this :

    0 5 * * 1 apt-get -y -q autoremove 1>/dev/null

I have it on our servers so we avoid get filled with junk on /boot

For maintainability, you might want to consider using /etc/crontab or /etc/cron.d or /etc/cron.daily to store this instead of the root user cron. Especially on servers.

Editorialized title?

Is it not accurate? Turns out updates had been broken for me too for a while because of this problem.

Given that the original title "Refresh hangs indefinitely, appstreamcli using 100% CPU" wouldn't probably have made the front page, yes, I'd say it has been editorialised for added sensationalism, like "failing all over the world"

For me, that is not accurate. If OP wanted to give a bit more context other than the original title, they could have changed it without adding the sensationalist part, for example, "Ubuntu bug breaks apt-get update" or similar.

This afternoon, without applying any of the workaround fixes, I somehow was able to apt update and upgrade appstream. Did they somehow make a server-side fix?

This is why you wait for a service pack or point release before using a new version of an OS.

Doesn't help much. Ubuntu-14.04 LTS had a similar problem last week where network manager crashes and you can't get to the network to fix it.

FFS, we are not going to beat Windows by recreating it!