13

My installed (local or obsolete) category is filling up because Canonical lately has been pushing out updates and then pulling them back. It's happened with two kernels in the recent past and it happened again with cups this morning. I've been using Ubuntu for about three years now and I do not remember this happening as often as it has this year.

So, how to rationally deal with this?

I thought about only installing updates once per week, but that would not protect against grabbing that bad update that they pushed out right before I checked that week.

Is a good strategy to only install updates on the weekend? It seems that system updates are not often pushed out on weekends. I suppose they could push a bad update on Friday afternoon and pull it on Monday morning.

Or, somehow not install updates until they have been pushed out for a certain time period - like two days? Is there an automated way to do that?

Edit: One of the affected systems runs Lubuntu 16.04 with the linux-generic kernel, the other runs Lubuntu 16.04 with the linux-generic-hwe-16.04 kernel. Both were affected by a cups version 2.13-4ubuntu0.2 update that was pushed out and then pulled back on March 27th, 2017. The linux-generic machine received a kernel update version 4.4.0.67.12 that was subsequently pulled back. This update also orphaned snapd version 2.23.1 The linux-generic-hwe-16.04 machine received a kernel version 4.8.0.42.14 that was then orphaned.

Robert Riedl
  • 4,351
Organic Marble
  • 23,641
  • 15
  • 70
  • 122
  • 2
    Thanks for clarifying the version. I was wondering if you were dealing with an LTS version, whereas the intermediate versions (to me) are mainly for testing with lots of changes that might make it into the LTS. As far as the LTS versions that I focus on, I haven't been observant enough to notice outstanding mistakes. I regularly update. I notice minor problems from time to time which apparently the developers are constantly dealing with. You might consider focusing on the Security updates for a secure system and allowing the daily changes to be dealt with by the more daring. – L. D. James Mar 27 '17 at 17:29
  • 1
    @fkraiem yes, I've seen two recent kernel releases get pulled back shortly after I was notified that they were available. Funny enough, I decided to do the updates later, and when I came back, they were gone! – heynnema Mar 27 '17 at 21:32
  • I used turn off Windows automatic updates partly because of your recent experiences in Ubuntu. I've noticed lately updates seem to be daily. Maybe I should shut mine off as I have no bugs now. – WinEunuuchs2Unix Mar 27 '17 at 22:03
  • Are they skipping essential portons of StableReleaseUpdates more frequently, especially for core packaged? AFAIK that hasn't been announced, and bringing up the discussion at the ubuntu-devel mailing list would be a proper measure to take. – Gunnar Hjalmarsson Mar 27 '17 at 23:58

3 Answers3

2

The drastic alternative is to switch to Debian Stable, rather than any *buntu or derivative thereof, because Debian Stable has been through its full QA process, whereas Ubuntu is derived from Debian Testing, which has some way to go before it becomes Stable.

Almost all knowledge is directly transferable, but Debian will not give you all the latest cosmetic "bells and whistles". However, it has more packages in its repository...

I switched to Debian, in my case with KDE, coming from Kubuntu, about 5 years ago, having had similar problems. But it comes down to personal choice.

tiger99
  • 21
  • 1
    That's good information. I ended up dealing with it by setting up my own local mirror which essentially downloads all the updates daily. My home LAN pc's get their updates from the local mirror but only on command, not automatically. So if anything looks scary, I can sit on it for a few days if I want to. – Organic Marble Mar 15 '19 at 21:54
  • That is a very good solution to the problem. Many business networks are set up to do the same with Windows updates, for similar reasons! – tiger99 Mar 17 '19 at 09:31
0

Roll back a package update to an older version

If you have the version number, or the target release, apt-get supports choosing a particular version or target release.

  1. Install aptitude

    sudo apt-get install aptitude

  2. Show old versions of the package.

    aptitude versions <package-name> | less # use less to display only the top of the list of versions

  3. Roll back the selected package to an older version.

    sudo apt-get -t=<target release> install <package-name>  # target release is old version

  4. Uninstall the bad update of the selected package.

    sudo apt-get -t=<target release> remove <package-name> # target release is new version

  5. Prevent the rolled back package version from being automatically updated using apt-mark hold. apt-mark hold is used to mark a package as held back, which will prevent the package from being automatically installed, upgraded or removed.

    sudo apt-mark hold <package-name>

Roll back a kernel update to an older version

Follow the same steps as in the preceding section except that you have to follow the additional steps of testing that you still have a kernel version installed that works before uninstalling the broken kernel package. Unfortunately this requires rebooting the system. I'm sorry about the rebooting, because I know this can be bothersome and time-consuming when you are maintaining multiple systems.

aptitude versions <package-name> does not show all currently installed kernel versions, however you can show all currently installed kernel versions with this command:

dpkg-query -W -f='${Package}\n' | grep -f <(ls -1 /boot/vmlinuz* | cut -d- -f2,3)

The results of this command will list the package names of all the non-working kernel packages which should be uninstalled.

After you uninstall the packages that belong to the non-working kernel version, you will get this message:

The link /vmlinuz.old is a damaged link
Removing symbolic link vmlinuz.old 
 you may need to re-run your boot loader[grub]

This message is shown because vmlinuz.old is linked to removed files, so you need to update grub by running this command:

sudo update-grub
karel
  • 114,770
  • 1
    Um, it's a huge pain if you have several systems to maintain, and then have to go back and set them all up to boot from the good kernel. And deal with the restart for the bad kernel, and another restart to get the good kernel. – Organic Marble Mar 27 '17 at 16:25
  • 1
    My family members need to have their computers start up without them having to think about what kernel to use. And, I know how to fix this problem once it happens. I'm looking for a strategy to avoid getting the problem in the first place. I didn't downvote your answer, but it isn't responsive to my question. – Organic Marble Mar 27 '17 at 16:55
  • If you had I would have been angry because you should have commented that you edited your question and then waited a few minutes for me to edit my answer before pulling the trigger, but I'm not angry because revisions are constructive and/or necessary. – karel Mar 27 '17 at 16:58
  • 2
    @OrganicMarble For your children, who may not be the most computer savvy or care to be bothering with thinking about kernel and matters, have you tested configuring their computers for security updates only? Does the same problem happen with that configuration? I can't imagine a circumstance where general updates would be perfect until the mass amounts of computers and environments as been tested after released when it works without problems in the lab. At least your question is showing quick fixes when the problems arise. – L. D. James Mar 27 '17 at 17:40
  • 1
    @L.D.James that is a good suggestion. I do suspect, however, that these kernel updates were security updates. I'm not sure how to go back and check that. – Organic Marble Mar 27 '17 at 17:58
  • 1
    @OrganicMarble You can go back and check by examining the unattended log files (/var/log/unattended-upgrades). I believe the unattended-upgrades package is for security updates. – L. D. James Mar 28 '17 at 01:06
-1

Your best strategy, like any OS, is to check for updates a minimum of once per day.

From a security point of view, it is unrealistic for a single user to run on delayed updates while they are individually tested and prioritised. And an urgent update is always more important than a pulled one.

Therefore, unless you have the time on your hands to investigate every update, the best strategy is to apply the updates as they are released, even if this results in many pulled updates. These can always be cleaned up later.

As a backup strategy, you should always... backup! Backup often, backup everything. Bad updates is one of the reasons for this. This is especially handy if you keep your important documents in the cloud.

EDIT: My answer is based on the assumption that you are a single person with at-home personal computers.

Delorean
  • 10,923
  • 1
    A strategy of "grin and bear it" is not what I'm looking for. – Organic Marble Mar 27 '17 at 16:26
  • @OrganicMarble I never said that. But I assume you are a single user and you're talking about a personal system. Otherwise please expand your question. There's only so much you can do as a single person when it comes to managing updates. I manage large sites with dozens of servers and hundreds of workstations in an organization that's hundreds of times larger than my sites. We all deal with updates in a very complex way that a single person could never do. – Delorean Mar 27 '17 at 16:28
  • Yes, I'm in a corner case, I guess, where we are a Ubuntu-using family with 5 computers, plus I run several virtual machines. So approx. 10 systems I have to manage. Too few to get an automated management system, but enough to make stuff like this super annoying. – Organic Marble Mar 27 '17 at 16:37
  • @OrganicMarble Yeah that makes it hard for a single person to manage. And honestly, the best thing you can do is to just keep updating as often as possible. A quick demo to your family members would probably help when it comes to multiple kernel options popping up. You should only have to show them once or twice. Have you considered a simple script that runs from a cron job to check for multiple kernels? Are multiple kernels the main concern? – Delorean Mar 27 '17 at 17:53