After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"

Looks like a problem caused by the AppArmor protection of CUPS. Can you attach your /var/log/syslog and also the output of the "dmesg" command? To deactivate the protection you can run "sudo aa-complain cupsd". Are you able to print then? To reactivate the protection, run "sudo aa-enforce cupsd".

Pitti, any chance to fix this for Gutsy?

I cannot say without getting the syslog.

I'll send it later tonight when I am back home from work.

2007/10/15, Martin Pitt <email address hidden>:
> I cannot say without getting the syslog.
>
> ** Changed in: cupsys (Ubuntu)
> Target: ubuntu-7.10 => None
>
> --
> After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"
> https://bugs.launchpad.net/bugs/152537
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Pietro Piutti
---------------------------------------------------------------------
CCNA - MCP - MCSA
Network Technician, Systems Engineering Group
United Nations International Computing Centre
United Nations Logistics Base, Brindisi, Italy
---------------------------------------------------------------------
http://www.linkedin.com/in/pietropiutti

2007/10/14, Till Kamppeter <email address hidden>:
> Looks like a problem caused by the AppArmor protection of CUPS. Can you
> attach your /var/log/syslog and also the output of the "dmesg" command?
> To deactivate the protection you can run "sudo aa-complain cupsd". Are
> you able to print then? To reactivate the protection, run "sudo aa-
> enforce cupsd".

Till, seems that you were right.

Today I updated Gutsy with the latest patches, without changing
anything in the AppArmor settings. Tried to print, but it failed
again, same error. I attach syslog and dmesg outputs as generated
after unsuccesful print attempts.

Then I followed Till's suggestion and set AppArmor to compain mode:
print jobs completed successfully afterwards.

I then reactivated the protection with aa-enforce, tried to print
again expecting the print job to fail, but they worked instead!

Hope you now have enough info to understand what happened and possibly
fix the issue.

--
Pietro Piutti
---------------------------------------------------------------------
CCNA - MCP - MCSA
Network Technician, Systems Engineering Group
United Nations International Computing Centre
United Nations Logistics Base, Brindisi, Italy
---------------------------------------------------------------------
http://www.linkedin.com/in/pietropiutti

[ 0.000000] Linux version 2.6.22-14-generic (buildd@vernadsky) (gcc version 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Wed Oct 10 06:00:47 GMT 2007 (Ubuntu 2.6.22-14.43-generic)
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
[ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
[ 0.000000] BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
[ 0.000000] BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
[ 0.000000] 127MB HIGHMEM available.
[ 0.000000] 896MB LOWMEM available.
[ 0.000000] found SMP MP-table at 000f5b70
[ 0.000000] Entering add_active_range(0, 0, 262128) 0 entries of 256 used
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] Normal 4096 -> 229376
[ 0.000000] HighMem 229376 -> 262128
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 262128
[ 0.000000] On node 0 totalpages: 262128
[ 0.000000] DMA zone: 32 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 4064 pages, LIFO batch:0
[ 0.000000] Normal zone: 1760 pages used for memmap
[ 0.000000] Normal zone: 223520 pages, LIFO batch:31
[ 0.000000] HighMem zone: 255 pages used for memmap
[ 0.000000] HighMem zone: 32497 pages, LIFO batch:7
[ 0.000000] DMI 2.2 present.
[ 0.000000] ACPI: RSDP signature @ 0xC00F7700 checksum 0
[ 0.000000] ACPI: RSDP 000F7700, 0014 (r0 IntelR)
[ 0.000000] ACPI: RSDT 3FFF3000, 002C (r1 IntelR AWRDACPI 42302E31 AWRD 0)
...

More info on the problem: after a reboot of the system the problem persist.
To make it print, it is necessary to issue the aa-compain cupsys after
each restart of the PC.

Many thanks for your efforts, looking forward to test the fixed bug!

2007/10/15, Till Kamppeter <email address hidden>:
> ** Changed in: cupsys (Ubuntu)
> Target: None => gutsy-updates
>
> --
> After update from Feisty to Gutsy RC, print jobs fail: "/usr/lib/cups/backend/mfp failed"
> https://bugs.launchpad.net/bugs/152537
> You received this bug notification because you are a direct subscriber
> of the bug.
>

--
Pietro Piutti
---------------------------------------------------------------------
CCNA - MCP - MCSA
Network Technician, Systems Engineering Group
United Nations International Computing Centre
United Nations Logistics Base, Brindisi, Italy
---------------------------------------------------------------------
http://www.linkedin.com/in/pietropiutti

2007/10/16, Pietro Piutti <email address hidden>:
> More info on the problem: after a reboot of the system the problem persist.
> To make it print, it is necessary to issue the aa-compain cupsys after
> each restart of the PC.
>
> Many thanks for your efforts, looking forward to test the fixed bug!

Sorry for bothering you again, but I just noticed another problem,
which I think it's related. That printer was shared on the network
through Samba:

[printers]
comment = All Printers
path = /var/spool/samba
browseable = yes
writable = no
guest ok = no
public = no
printable = yes
share modes = no
locking = no

I just noticed that both my Mac and Windows box cannot see it anymore
(while I can still happily browse the shared folders on the same Gutsy
box). Could it still be related to CUPS?

--
Pietro Piutti
---------------------------------------------------------------------
CCNA - MCP - MCSA
Network Technician, Systems Engineering Group
United Nations International Computing Centre
United Nations Logistics Base, Brindisi, Italy
---------------------------------------------------------------------
http://www.linkedin.com/in/pietropiutti

I confirm the problem with AppArmor. I am using a Canon Pixma MP460 with the drivers of the MP160. It worked on Feisty but it didn't anymore on Gutsy and I had no error message. I ran "sudo aa-complain cupsd" and now it works fine, even after rebooting.

I have the AppArmor problem with my HP LJ 1012 printer. The aa-complain cupsys freed up the printer. I had no trouble with samba visibility during the time that the printer was shown as stopped (and shown stopped by samba as well as the gnome printer manager. )

FWIW, upon gutsy installation, I couldn't make the printer work until I fetched hplip 2.7.10 from http://hplip.sourceforge.net/ . On the other hand, I didn't know about this aa issue until my 1012 stopped apparently on its own. So it is conceivable that the mere act of installing a new hplip had the effect of resetting aa.

I have a Compaq TC1100 tablet running Gutsy and a Dell Precision M90 running Gutsy. My printer is a HP Deskjet 460 connected via bluetooth, but I can only print from the tablet. The Dell will only print if I use the 'sudo aa-complain cupsd' method. The Dell is running 64 bit whereas the tablet is 32 bit. I haven't checked but I'm guessing the hplip is not as up-to-date on the 64 bit Ubuntu.

The HPLIP is exactly the same on 32-bit and 64-bit. The problem is perhaps a 64-bit only bug in AppArmor which prevents AppArmor from doing its protection job on 64-bit.

phenest, the Bluetooth issue is bug 147800.

Fixed in bzr head.

cupsys (1.3.4-1ubuntu3) hardy; urgency=low

  * debian/local/apparmor-profile:
    - Allow rw access to /dev/parport* and ro access to
      /proc/sys/dev/parport/**, so that parallel port printer detection works.
    - Allow unconfined execution of the bluetooth backend. AppArmor currently
      forbids creation of bluetooth sockets without providing a profile option
      to allow it (see bug #172534). (LP: #147800)
    - Permit reading /etc/pnm2ppa.conf. (LP: #155530)
    - Disable AA profile for Samsung's MFP driver, since it needs very high
      and unknown privileges and is a third-party driver which we cannot
      control. (LP: #152537)

 -- Martin Pitt <email address hidden> Wed, 28 Nov 2007 12:05:30 +0100

The 32 and 64 bit DO have different versions of HPLIP. 32 has 2.7.10, and 64 has 2.7.7. I downloaded and installed the latest version for the 64 bit, and the problem has vanished. Blue tooth was not the problem.

To get HPLIP 2.7.10 onto your 64-bit box, did you do an update of the official Ubuntu packages (automatic update by clicking the notification icon/using command "sudo apt-get dist-upgrade" or manual update of only HPLIP with Synaptic or apt-get) or did you some kind of unofficial update (upstream packages from HP, rebuild of Hardy packages)?

It would be a severe failure of the release management if the official releases on two different platforms are of two different versions, as our build server usually builds packages for all platforms once a new source package is uploaded. And the package maintainer gets notified if the build server fails on a particular platform.

Hi,

Till Kamppeter [2007-11-29 17:45 -0000]:
> It would be a severe failure of the release management if the official
> releases on two different platforms are of two different versions, as
> our build server usually builds packages for all platforms once a new
> source package is uploaded. And the package maintainer gets notified if
> the build server fails on a particular platform.

Indeed, and we additionally have tools which check the archive for
consistency and report such cases. We would not release in this state.

Indeed all hplip packages are in sync in 7.10:

     hplip | 2.7.7.dfsg.1-0ubuntu5 | gutsy | source, amd64, i386, powerpc
     hplip | 2.7.7.dfsg.1-0ubuntu5.1 | gutsy-proposed | source, amd64, i386, powerpc

I do not know where 2.7.10 came from, that's only in hardy. Please
check your package sources if you have something like automatix or
other third-party sources.

Martin

Proposed debdiff for Gutsy on https://bugs.launchpad.net/ubuntu/+source/cupsys/+bug/147800/comments/17.

Accepted into gutsy-proposed. Please test this version and give some feedback here. Thank you!

 cupsys (1.3.2-1ubuntu7.2) gutsy-proposed; urgency=low
 .
   * debian/local/apparmor-profile:
     - Allow rw access to /dev/parport* and ro access to
       /proc/sys/dev/parport/**, so that parallel port printer detection works.
     - Allow bluetooth socket creation to unbreak the bluetooth backend.
       (LP: #147800)
     - Permit reading /etc/pnm2ppa.conf. (LP: #155530)
     - Only restrict backends which are shipped by cupsys itself (or known
       packages like cups-pdf). All other backends remain unrestricted, since we
       cannot predict which privileges they need. (LP: #152537)

A lot of people got this problem apparently. Can anyone please give this some testing and give some feedback here? Without this, it cannot be moved to -updates.

Dear Martin,

In reply to your request for feedback...

I have a local network with Gutsy installed on all machines and the latest Avahi patches installed on all machines. I use vanilla cupsd.conf files on all machines, on the server I have allowed sharing of published printers and the printer is published. On the clients I have allowed browsing for shared printers.

When I start the server machine in the morning followed by the client machines, the clients do not see the shared printer at all. Shared folders does work.

If I go to a terminal session and restart cups, the clients see the printer and I can print from the client with no problem. ie to get the shared printing working I have to do a manual restart of cups. This indicates that the config files are correct, but that there is some problem in the start up of the machine that makes the server printer unavailable.

I hope this helps; please contact me for further info if required, as this is a very frustrating bug.

Thank you

Hilary

Here is the cupsd.conf files from the server machine. It is the std file a provided with no changes.

LogLevel warning
SystemGroup lpadmin
# Allow remote access
Port 631
Listen /var/run/cups/cups.sock
# Share local printers on the local network.
Browsing On
BrowseOrder allow,deny
BrowseAddress @LOCAL
DefaultAuthType Basic
<Location />
  # Allow shared printing...
  Order allow,deny
  Allow @LOCAL
</Location>
<Location /admin>
  # Restrict access to the admin pages...
  Order allow,deny
  Allow localhost
</Location>
<Location /admin/conf>
  AuthType Default
  Require user @SYSTEM
  # Restrict access to the configuration files...
  Order allow,deny
  Allow localhost
</Location>
<Policy default>
  <Limit Send-Document Send-URI Hold-Job Release-Job Restart-Job Purge-Jobs Set-Job-Attributes Create-Job-Subscription Renew-Subscription Cancel-Subscription Get-Notifications Reprocess-Job Cancel-Current-Job Suspend-Current-Job Resume-Job CUPS-Move-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit CUPS-Add-Modify-Printer CUPS-Delete-Printer CUPS-Add-Modify-Class CUPS-Delete-Class CUPS-Set-Default>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Pause-Printer Resume-Printer Enable-Printer Disable-Printer Pause-Printer-After-Current-Job Hold-New-Jobs Release-Held-New-Jobs Deactivate-Printer Activate-Printer Restart-Printer Shutdown-Printer Startup-Printer Promote-Job Schedule-Job-After CUPS-Accept-Jobs CUPS-Reject-Jobs>
    AuthType Default
    Require user @SYSTEM
    Order deny,allow
  </Limit>
  <Limit Cancel-Job CUPS-Authenticate-Job>
    Require user @OWNER @SYSTEM
    Order deny,allow
  </Limit>
  <Limit All>
    Order deny,allow
  </Limit>
</Policy>

Hilary, this sounds like a different bug. We are going to fix that, too, but before we need to verify the fix of this bug so that the current -proposed package can go into -updates. Do you have a printer which was previously affected by this bug? ("/usr/lib/cups/backend/mfp failed")

Martin,

Thank you for your reply.

No I do not have the error "/usr/lib/cups/backend/mfp failed", Sorry about that.

If my problem is s different one, could you point me to the relevant bug, so that I can watch that thread? Thank you.

Hilary

This has been superseded by a security update. Please remerge. Gutsy debdiff from 1.3.2-1ubuntu7.1 attached...

Good Morning Martin,

Well, well...

I thought you should know that when I started up the office machines this morning printing on the client machines worked a breeze. I am at a loss to know why, since the only change I have made was to install the updates for this bug ("/usr/lib/cups/backend/mfp failed") and after that update printing did not work as I described above.

Would you have an explanation for this behaviour?

I have now applied the security updates, as mentioned by Kees, which updates CUPS to 1.3.2-1ubuntu7.3, restarted the machines. Printing works correctly.

Hilary

Hilary, I think bug 173470 was the one you described. However, if it works now, so much the better. That bug might just be a race condition, though, so the next time you start the print server it might again not work any more.

Hilary, BTW, the avahi side of bug 173470 is already in gutsy-proposed, so if you installed -proposed as well and it works now, then please give a comment there to track verification. Thank you!

I reapplied the fixes from comment 18 to Kees' security update and uploaded it to gutsy-proposed. Please test and give feedback here. Thank you!

Copied to gutsy-updates to get the fixes in for the other four bugs in this SRU. We know that the new version is not any worse wrt. this bug, and we strongly believe that this bug is fixed now. Please reopen if you still have problems with the new version.

Just installed version 7.3, but still getting the error message in cups. My printer is a samsung SCX-4200.
Syslog says

Jan 25 23:42:02 pau rmmod: FATAL: can't open /proc/modules: Permission denied
Jan 25 23:42:02 pau last message repeated 3 times
Jan 25 23:42:02 pau kernel: [50150.932000] audit(1201300922.560:62): type=1503 operation="sysctl" requested_mask="r" denied_mask="r" name="/proc/sys/kernel/osrelease" pid=16891 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.936000] audit(1201300922.560:63): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/modules" pid=16895 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.940000] audit(1201300922.560:64): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/modules" pid=16897 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.940000] audit(1201300922.560:65): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/modules" pid=16899 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.944000] audit(1201300922.560:66): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/proc/modules" pid=16901 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.948000] audit(1201300922.560:67): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.conf" pid=16903 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.948000] audit(1201300922.560:68): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.d/" pid=16903 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.948000] audit(1201300922.560:69): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.d/" pid=16903 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.948000] audit(1201300922.560:70): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/lib/modules/2.6.22-14-generic/modules.dep" pid=16903 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.952000] audit(1201300922.560:71): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.conf" pid=16905 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.952000] audit(1201300922.560:72): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.d/" pid=16905 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.952000] audit(1201300922.560:73): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.d/" pid=16905 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.952000] audit(1201300922.560:74): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/lib/modules/2.6.22-14-generic/modules.dep" pid=16905 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.956000] audit(1201300922.560:75): type=1503 operation="inode_permission" requested_mask="r" denied_mask="r" name="/etc/modprobe.conf" pid=16907 profile="/usr/sbin/cupsd"
Jan 25 23:42:02 pau kernel: [50150.956000] audit(1...

MarcoPau, 7.3 does not have the fix. Can you please upgrade again (should pull in version 7.5, unless you disabled gutsy-updates)?

Martin, I actually had 7.5 but tried to downgrade to 7.3 as it seemed to be the right version for the fix. In both cases, anyway, I get the error in localhost:631. The syslog is different (reupgraded to 7.5 meanwhile):

Jan 28 16:29:27 pau rmmod: ERROR: Module ppdev does not exist in /proc/modules
Jan 28 16:29:28 pau kernel: [21931.384000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Jan 28 16:29:28 pau kernel: [21931.552000] lp0: using parport0 (interrupt-driven).
Jan 28 16:29:28 pau rmmod: ERROR: Module ppdev does not exist in /proc/modules
Jan 28 16:29:28 pau kernel: [21931.760000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Jan 28 16:29:28 pau kernel: [21931.952000] lp0: using parport0 (interrupt-driven).

Ah, if that was the complete syslog, then the patch indeed seems to
have helped a bit. Now that seems to be the fault of the actual mfp
backend you installed.

It might help to do 'sudo modprobe ppdev' perhaps, but I can only
guess.

Nothing changes, unfortunately...

Reopening for gutsy, but no fix known yet for the subsequent problem.

Can you please try to print something, and immediately afterwards attach /var/log/cups/error_log and /var/log/syslog?

This is cups error_log:

E [29/Jan/2008:09:49:08 +0000] PID 5924 (/usr/lib/cups/backend/mfp) stopped with status 2!

Syslog is exactly what I posted before, as it was already copied after printing:

Jan 29 10:49:08 pau kernel: [ 630.856000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Jan 29 10:49:08 pau kernel: [ 631.040000] lp0: using parport0 (interrupt-driven).
Jan 29 10:49:08 pau rmmod: ERROR: Module ppdev does not exist in /proc/modules
Jan 29 10:49:08 pau kernel: [ 631.128000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Jan 29 10:49:08 pau kernel: [ 631.268000] lp0: using parport0 (interrupt-driven).

There's a post around that says to rmmod ehci_hci for this printer and motherboard chipset (nforce), in order to make it work with usb 1.1, as there seems to be a problem with 2.0. I'm gonna try that, even thou it can't really be a solution for me, using a usb wifi adapter (unless we can make it work without that module).

Ciao

Tried removing ehci_hcd, but no differences.

Noticed that cups/error_log is always one hour behind...

Any news for me? :-(

If it helps, I get these messages in /var/log/cups/error_log when adding a new printer thru the samsung driver configurator.

E [02/Feb/2008:20:48:16 +0000] [cups-driverd] Unable to open PPD directory "/opt/share/ppd": No such file or directory
E [02/Feb/2008:20:48:16 +0000] [cups-driverd] Unable to write "/var/cache/cups/ppds.dat" - Permission denied
E [02/Feb/2008:20:48:29 +0000] CUPS-Add-Modify-Printer: Unauthorized
E [02/Feb/2008:20:48:29 +0000] CUPS-Add-Modify-Printer: Unauthorized
E [02/Feb/2008:20:48:29 +0000] copy_model: empty PPD file!
E [02/Feb/2008:20:48:29 +0000] CUPS-Add-Modify-Printer: Unauthorized
E [02/Feb/2008:20:48:29 +0000] CUPS-Set-Default: Unauthorized

I'm posting error_log again after activating the debug option in cups. Hope there's some useful info in it:

D [04/Feb/2008:00:42:15 +0000] cupsdReadClient: 18 POST /admin HTTP/1.1
D [04/Feb/2008:00:42:15 +0000] cupsdAuthorize: No authentication data provided.
D [04/Feb/2008:00:42:15 +0000] [CGI] /usr/lib/cups/cgi-bin/admin.cgi started - PID = 21625
I [04/Feb/2008:00:42:15 +0000] Started "/usr/lib/cups/cgi-bin/admin.cgi" (pid=21625)
D [04/Feb/2008:00:42:15 +0000] cupsdSendCommand: 18 file=19
D [04/Feb/2008:00:42:15 +0000] [CGI] admin.cgi started...
D [04/Feb/2008:00:42:15 +0000] [CGI] http=0x80790d0
D [04/Feb/2008:00:42:15 +0000] cupsdAcceptClient: 14 from localhost (Domain)
D [04/Feb/2008:00:42:15 +0000] [CGI] op="config-server"...
D [04/Feb/2008:00:42:15 +0000] [CGI] DefaultAuthType Basic
D [04/Feb/2008:00:42:15 +0000] cupsdReadClient: 14 PUT /admin/conf/cupsd.conf HTTP/1.1
D [04/Feb/2008:00:42:15 +0000] cupsdAuthorize: No authentication data provided.
D [04/Feb/2008:00:42:15 +0000] cupsdIsAuthorized: username=""
D [04/Feb/2008:00:42:15 +0000] cupsdSendError: 14 code=401 (Unauthorized)
D [04/Feb/2008:00:42:15 +0000] cupsdSendHeader: WWW-Authenticate: Basic realm="CUPS"
D [04/Feb/2008:00:42:15 +0000] cupsdCloseClient: 14
D [04/Feb/2008:00:42:15 +0000] [CGI] cgi_passwd(prompt="Password per lp su localhost? ") called!
D [04/Feb/2008:00:42:15 +0000] cupsdSendError: 18 code=401 (Unauthorized)
D [04/Feb/2008:00:42:15 +0000] cupsdSendHeader: WWW-Authenticate: Basic realm="CUPS"
D [04/Feb/2008:00:42:15 +0000] cupsdCloseClient: 18
D [04/Feb/2008:00:42:15 +0000] cupsdReadClient: 9 POST /admin HTTP/1.1
D [04/Feb/2008:00:42:15 +0000] cupsdAuthorize: Authorized as marcopau using Basic
D [04/Feb/2008:00:42:15 +0000] [CGI] /usr/lib/cups/cgi-bin/admin.cgi started - PID = 21626
I [04/Feb/2008:00:42:15 +0000] Started "/usr/lib/cups/cgi-bin/admin.cgi" (pid=21626)
D [04/Feb/2008:00:42:15 +0000] cupsdSendCommand: 9 file=18
D [04/Feb/2008:00:42:15 +0000] PID 21625 (/usr/lib/cups/cgi-bin/admin.cgi) exited with no errors.
D [04/Feb/2008:00:42:15 +0000] [CGI] admin.cgi started...
D [04/Feb/2008:00:42:15 +0000] [CGI] http=0x80790d0
D [04/Feb/2008:00:42:15 +0000] [CGI] op="config-server"...
D [04/Feb/2008:00:42:15 +0000] [CGI] DefaultAuthType Basic
D [04/Feb/2008:00:42:15 +0000] cupsdAcceptClient: 14 from localhost (Domain)
D [04/Feb/2008:00:42:15 +0000] cupsdReadClient: 14 PUT /admin/conf/cupsd.conf HTTP/1.1
D [04/Feb/2008:00:42:15 +0000] cupsdAuthorize: No authentication data provided.
D [04/Feb/2008:00:42:15 +0000] cupsdIsAuthorized: username=""
D [04/Feb/2008:00:42:15 +0000] cupsdSendError: 14 code=401 (Unauthorized)
D [04/Feb/2008:00:42:15 +0000] cupsdSendHeader: WWW-Authenticate: Basic realm="CUPS"
D [04/Feb/2008:00:42:15 +0000] cupsdCloseClient: 14
D [04/Feb/2008:00:42:15 +0000] cupsdAcceptClient: 14 from localhost (Domain)
D [04/Feb/2008:00:42:15 +0000] cupsdReadClient: 14 PUT /admin/conf/cupsd.conf HTTP/1.1
D [04/Feb/2008:00:42:15 +0000] cupsdAuthorize: Authorized as marcopau using Local
D [04/Feb/2008:00:42:15 +0000] cupsdIsAuthorized: username="marcopau"
I [04/Feb/2008:00:42:15 +0000] Installing config file "/etc/cups/cupsd.conf"...
D [04/Feb/2008:00:42:15...

If setting the apparmor profile to complain mode still makes it work, then there must be still some kernel messages about denied actions. Your recent debug log (thanks for that) has

  [Job 93] Unable to open MFP port device file!: Input/output error

But does not say which or where. It's a bit weird, since the current apparmor profile runs unknown backends (like mfp) without any restrictions.

Can you please do the following:
 * Start from a clean boot
 * Try to print something
 * Attach /var/log/kern.log here

Thank you!

Feb 4 08:21:00 pau kernel: [ 679.372000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Feb 4 08:21:01 pau kernel: [ 679.584000] lp0: using parport0 (interrupt-driven).
Feb 4 08:21:01 pau kernel: [ 679.740000] parport0: PC-style at 0x378, irq 7 [PCSPP,TRISTATE]
Feb 4 08:21:01 pau kernel: [ 679.876000] lp0: using parport0 (interrupt-driven).

Pretty much like syslog...

Hm. Can you still confirm that "sudo aa-complain cupsd" makes your printer work?

It actually never did.

Marco: Ah, then you seem to have a completely different problem. Maybe you need to update that 'mfp' driver? (wherever it came from); it's not shipped by Ubuntu, so we cannot do anything about it if it is broken.

Pietro, you reported the bug originally. Does it work for you now?

Well yeah, but it was working perfectly untill I updated to gutsy, and nobody else complains beside people here... Don't really know where to go :-/

I was opening usbview when it gave this error:

cannot open the file /proc/bus/usb/devices
Verify that you have USB compiled into your kernel, have the USB core modules loaded, and have the usbdevs filesystem mounted.

From lsmod: usbcore 138632 6 usblp,ndiswrapper,usbhid,ehci_hcd,ohci_hcd
From mount: udev on /dev type tmpfs (rw,mode=0755)

MarcoPau: usbview is broken at the moment, see bug 156085. It is plausible that the mfp driver has the same problem and hasn't been updated for /dev/bus/usb/. Maybe a newer version is available which will work with current Linux distros?

I mark this as invalid, since it affects software which is not shipped in Ubuntu and is unrelated to cups. The original report was about problems in the AppArmor profile, which have been fixed in Gutsy and Hardy.