It looks like cups need a versioned depend on quantal's apparmor as
well, or else you can get into the state where apparmor is precise, and
cups is quantal. This happened after an upgrade failed for other reasons
and I tried to continue the installs.
** Also affects: cups (Ubuntu)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to cups in Ubuntu.
https://bugs.launchpad.net/bugs/1058356
Title:
fails to install when kernel does not provide block_suspend capability
Status in “cups” package in Ubuntu:
New
Status in “upstart” package in Ubuntu:
Fix Released
Status in “cups” source package in Quantal:
New
Status in “upstart” source package in Quantal:
Fix Released
Bug description:
[IMPACT]
* Some users upgrading from 12.04 LTS to 12.10 have encountered upgrade
errors because
apparmor_parser fails to load new policy on an old kernel. Specifically,
the
block_suspend capability is new in the 12.10 kernel and does not exist in
the
12.04 LTS kernel. On upgrade, the cups upstart job calls
/lib/init/apparmor-profile-load from upstart, which in turn calls
apparmor_parser.
apparmor_parser can exit with error on upgrades causing the upstart job to
fail.
[TESTCASE]
* Regular upgrades using do-release-upgrade or update-manager don't seem to
be affected,
so it is best to:
- obtain the apparmor profile from the 12.10 cups package[1], copy it to
/etc/apparmor.d/usr.sbin.cupsd and then perform 'sudo stop cups ; sudo
start cups'.
If the bug is not fixed, you will see 'start: Job failed to start'. If
it is
fixed, you will see 'cups start/running, process ####'.
[1]http://bazaar.launchpad.net/~ubuntu-
branches/ubuntu/quantal/cups/quantal/view/head:/debian/local/apparmor-
profile
[Regression Potential]
* The regression potential is extremely low. The only change is adding '||
exit 0' to a
shell script.
[Other Info]
* This has been discussed with the security team, the release team and
foundations and
we all agree this is the best fix at this time.
* On upgrades, upstart is unpacked very early (much earlier than cups), so
the new
/lib/init/apparmor-profile-load should be in place before the upstart job
is used
* apparmor_parser failure will not remove the old profile when it faces this
error
condition, so the program will not go unconfined
Previous report:
On our Jenkins builds we're getting a failure to install the cups package.
This seems to be because the apparmor profile looks for suspend capability but
the virtualized builders do not have it. Here seems to be the relevant log:
AppArmor parser error for /etc/apparmor.d/usr.sbin.cupsd in
/etc/apparmor.d/usr.sbin.cupsd at line 24: Invalid capability block_suspend.
start: Job failed to start
invoke-rc.d: initscript cups, action "start" failed.
dpkg: error processing cups (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
cups
E: Sub-process /usr/bin/dpkg returned an error code (1)
Full log: https://jenkins.qa.ubuntu.com/job/indicator-session-
ci/label=quantal/16/console
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cups/+bug/1058356/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : [email protected]
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
