"md5sums differ" message seems to indicate an install problem

Bug #1614215 reported by Mike Robinson
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
AppArmor
Invalid
Undecided
Unassigned
Ubuntu GNOME
Invalid
Undecided
Unassigned
apparmor (Ubuntu)
Fix Released
Low
Tyler Hicks
Xenial
Fix Released
Low
Tyler Hicks
Yakkety
Fix Released
Low
Tyler Hicks

Bug Description

[Impact]
Confusing output from a diff command executed during the apparmor update process leaves users concerned about the state of their system.

[Test Case]
1. Make sure that apparmor 2.10.95-0ubuntu2 from the -release pocket is installed

2. Update to the apparmor package in -proposed

3. Look at the output during the update process to verify that the following message is *not* printed:

  Files /var/lib/dpkg/info/apparmor.md5sums and /var/lib/apparmor/profiles/.apparmor.md5sums differ

[Regression Potential]
Considered to be extremely low. The change is a one-liner that pipes the stdout of diff command to /dev/null (the -q option of diff is not sufficient).

[Original description]

Upon applying the latest Ubuntu routine-update, I observed these messages:

Setting up apparmor (2.10.95-0ubuntu2.2) ...
Installing new version of config file /etc/apparmor.d/abstractions/dbus-session-strict ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Skipping profile in /etc/apparmor.d/disable: usr.sbin.apache2
Skipping profile in /etc/apparmor.d/disable: usr.sbin.rsyslogd
Files /var/lib/dpkg/info/apparmor.md5sums and /var/lib/apparmor/profiles/.apparmor.md5sums differ

"The reason why I am filing a bug report" is the LAST line. I presume that if md5sums do not agree, something was probably done improperly in preparing this particular software-update blast.

However, in-passing, I would also point out line #3, about "start and stop actions no longer supported." That seems to me to be something (of much less importance, obviously) that might have been overlooked. (I've seen =that= message for some time now.)

ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: apparmor 2.10.95-0ubuntu2.2
ProcVersionSignature: Ubuntu 4.4.0-34.53-generic 4.4.15
Uname: Linux 4.4.0-34-generic x86_64
ApportVersion: 2.20.1-0ubuntu2.1
Architecture: amd64
Date: Wed Aug 17 14:22:55 2016
InstallationDate: Installed on 2016-03-02 (168 days ago)
InstallationMedia: Ubuntu-Server 15.10 "Wily Werewolf" - Release amd64 (20151021)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcKernelCmdline: BOOT_IMAGE=/vmlinuz-4.4.0-34-generic root=/dev/mapper/hostname--vg-root ro
SourcePackage: apparmor
Syslog:
 Aug 10 10:36:07 IntersignVM dbus[1638]: [system] AppArmor D-Bus mediation is enabled
 Aug 11 13:10:08 IntersignVM dbus[1655]: [system] AppArmor D-Bus mediation is enabled
 Aug 16 08:40:24 IntersignVM dbus[1693]: [system] AppArmor D-Bus mediation is enabled
 Aug 17 13:58:37 IntersignVM dbus[1657]: [system] AppArmor D-Bus mediation is enabled
UpgradeStatus: Upgraded to xenial on 2016-05-11 (98 days ago)

Revision history for this message
Mike Robinson (miker-d) wrote :
Revision history for this message
Dominic Raferd (dominic-timedicer) wrote :

Agree with OP on both points, but also note that when I check the two supposedly different files afterwards they are in fact identical except for timestamp:

$ sudo diff /var/lib/dpkg/info/apparmor.md5sums /var/lib/apparmor/profiles/.apparmor.md5sums; echo $?
0

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in apparmor (Ubuntu):
status: New → Confirmed
Revision history for this message
Wise Melon (wise-melon-deactivatedaccount) wrote :

I also experienced this issue, first on an Ubuntu GNOME 16.10 VM, now on my Ubuntu GNOME 16.04.1 installation. In my case the files also appear identical.

Changed in apparmor:
status: New → Confirmed
Changed in ubuntu-gnome:
status: New → Confirmed
tags: added: yakkety
Changed in apparmor (Ubuntu):
importance: Undecided → High
Revision history for this message
dino99 (9d9) wrote :

Unpacking apparmor-easyprof-ubuntu (16.10.2) over (16.10.1) ...
Setting up apparmor-easyprof-ubuntu (16.10.2) ...
(may take a while)
Files /var/lib/dpkg/info/apparmor-easyprof-ubuntu.md5sums and /var/lib/apparmor/profiles/.apparmor-easyprof-ubuntu.md5sums differ

Revision history for this message
Tyler Hicks (tyhicks) wrote :

That message is harmless but admittedly confusing. It is coming from a call out to `diff` to see if we need to update debsums files that we save off for packaging purposes. I'll quiet the output from diff and may possibly print a less scary message or I may just not print anything.

Revision history for this message
Tyler Hicks (tyhicks) wrote :

This is a bug in the packaging and doesn't affect the upstream AppArmor project.

Changed in apparmor:
status: Confirmed → Invalid
Revision history for this message
Tyler Hicks (tyhicks) wrote :

The fix will be in the apparmor package. Marking the Ubuntu GNOME task as invalid.

Changed in ubuntu-gnome:
status: Confirmed → Invalid
Changed in apparmor (Ubuntu):
status: Confirmed → In Progress
importance: High → Low
assignee: nobody → Tyler Hicks (tyhicks)
Tyler Hicks (tyhicks)
Changed in apparmor (Ubuntu Xenial):
assignee: nobody → Tyler Hicks (tyhicks)
importance: Undecided → Low
status: New → In Progress
description: updated
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10.95-4ubuntu4

---------------
apparmor (2.10.95-4ubuntu4) yakkety; urgency=medium

  * debian/patches/allow-access-to-ibus-socket.patch: Adjust the ibus
    abstraction to allow access to the abstract UNIX domain socket location
    used in Ubuntu. (LP: #1580463)
  * debian/lib/apparmor/functions: Quiet the "Files ... and ... differ"
    output, during the update process, which was printed by diff. This message
    left users concerned since it mentioned md5sums files without being clear
    about what was happening. (LP: #1614215)

 -- Tyler Hicks <email address hidden> Fri, 26 Aug 2016 13:33:46 -0500

Changed in apparmor (Ubuntu Yakkety):
status: In Progress → Fix Released
Revision history for this message
Chris J Arges (arges) wrote : Please test proposed package

Hello Mike, or anyone else affected,

Accepted apparmor into xenial-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2.3 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Changed in apparmor (Ubuntu Xenial):
status: In Progress → Fix Committed
tags: added: verification-needed
Revision history for this message
Tyler Hicks (tyhicks) wrote :

I've completed the AppArmor test plan:

  https://wiki.ubuntu.com/Process/Merges/TestPlans/AppArmor

I've also manually verified the AppArmor portion of this SRU.

tags: added: verification-done
removed: verification-needed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package apparmor - 2.10.95-0ubuntu2.5

---------------
apparmor (2.10.95-0ubuntu2.5) xenial; urgency=medium

  * debian/lib/apparmor/functions, debian/apparmor.init,
    debian/apparmor.service, debian/apparmor.upstart,
    debian/lib/apparmor/profile-load: Adjust the checks that previously kept
    AppArmor policy from being loaded while booting a container. Now we
    attempt to load policy if we're in a LXD or LXC managed container that is
    using profile stacking inside of a policy namespace. (LP: #1628285)
  * Fix regression tests for stacking so that the kernel SRU process is not
    interrupted by failing tests whenever the AppArmor stacking features are
    backported from the 16.10 kernel or when the 16.04 LTS Enablement Stack
    receives a 4.8 or newer kernel
    - debian/patches/r3509-tests-fix-exec_stack-errors-1.patch: Fix the
      exec_stack.sh test when running on 4.8 or newer kernels (LP: #1628745)
    - debian/patches/r3558-tests-fix-exec_stack-errors-2.patch: Adjust the
      exec_stack.sh fix mentioned above to more accurately test kernels older
      than 4.8 (LP: #1630069)
    - debian/patches/allow-stacking-tests-to-use-system.patch: Apply this
      patch earlier in the series, as to match when it was committed upstream,
      so that the above two patches can be cherry-picked from lp:apparmor

 -- Tyler Hicks <email address hidden> Fri, 07 Oct 2016 05:21:44 +0000

Changed in apparmor (Ubuntu Xenial):
status: Fix Committed → Fix Released
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.