package linux-headers-4.10.0-22-generic 4.10.0-22.24 failed to install/upgrade: unable to open '/usr/src/linux-headers-4.10.0-22-generic/include/config/dw/dmac/core.h.dpkg-new': Operation not permitted

[Tim Passingham]

I was trying to install 4.10.0-22 to fix #1674838 on the one system I have that had a problem with the previous kernels.

I assume the systme has collected enough info to help identify and resolve this.

I have tried an apt clean update and install -f.

ProblemType: Package
DistroRelease: Ubuntu 17.04
Package: linux-headers-4.10.0-22-generic 4.10.0-22.24
ProcVersionSignature: Ubuntu 4.8.0-51.54-generic 4.8.17
Uname: Linux 4.8.0-51-generic x86_64
ApportVersion: 2.20.4-0ubuntu4.1
AptOrdering:
 linux-headers-4.10.0-22:amd64: Install
 linux-headers-4.10.0-22-generic:amd64: Install
 NULL: ConfigurePending
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: chris 5035 F.... pulseaudio
 /dev/snd/controlC1: chris 5035 F.... pulseaudio
Date: Tue Jun 6 15:18:46 2017
DuplicateSignature:
 package:linux-headers-4.10.0-22-generic:4.10.0-22.24
 Unpacking linux-headers-4.10.0-22 (4.10.0-22.24) ...
 dpkg: error processing archive /var/cache/apt/archives/linux-headers-4.10.0-22_4.10.0-22.24_all.deb (--unpack):
  unable to open '/usr/src/linux-headers-4.10.0-22/include/linux/mfd/pcf50633/gpio.h.dpkg-new': Operation not permitted
ErrorMessage: unable to open '/usr/src/linux-headers-4.10.0-22-generic/include/config/dw/dmac/core.h.dpkg-new': Operation not permitted
HibernationDevice: RESUME=UUID=50434c81-1f67-4a34-87f1-d6f98ec7e702
InstallationDate: Installed on 2015-05-05 (763 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140416.2)
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
MachineType: Dell Inc. Inspiron 620s
ProcFB: 0 radeondrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.8.0-51-generic root=UUID=d38419e7-b512-4620-8c5a-ed3d539ab325 ro quiet splash vt.handoff=7
PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon.
RelatedPackageVersions: grub-pc 2.02~beta3-4ubuntu2
RfKill:

SourcePackage: linux
Title: package linux-headers-4.10.0-22-generic 4.10.0-22.24 failed to install/upgrade: unable to open '/usr/src/linux-headers-4.10.0-22-generic/include/config/dw/dmac/core.h.dpkg-new': Operation not permitted
UpgradeStatus: Upgraded to zesty on 2017-05-03 (33 days ago)
dmi.bios.date: 07/27/2011
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A02
dmi.board.name: 0GDG8Y
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 3
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: 00
dmi.modalias: dmi:bvnDellInc.:bvrA02:bd07/27/2011:svnDellInc.:pnInspiron620s:pvr00:rvnDellInc.:rn0GDG8Y:rvrA00:cvnDellInc.:ct3:cvr00:
dmi.product.name: Inspiron 620s
dmi.product.version: 00
dmi.sys.vendor: Dell Inc.

[Brad Figg (brad-figg)]

This change was made by a bot.

[Tim Passingham (tim-8aw3u04umo)]

Each time I retry reinstalling from clean I get a slightly different error, all on files in /usr/src...

[Seth Forshee (sforshee)]

That's indeed strange. One thing I see some have reported causing this is anivirus software, so if you are running any try stopping it and installing again.

Did you have these kernel packages installed already from when they were still in -proposed? If so (for future reference) there wasn't any reason to reinstall them, the package files after it is promoted to -updates are the exact same files that were in -proposed.

[Tim Passingham (tim-8aw3u04umo)]

I tried installing from proposed a week to 2 back, had the same problem, and decided not to pursue it until the kernel was released as stable.

I'm running AV, but the same as on my other 3 systems, none of which crashed for the bug, and none of which had installation problems. I will try without AV and post here if it helps, but it seems to me there is something about this moderately old Dell that the new kernel files don't like.

[Tim Passingham (tim-8aw3u04umo)]

Seth - you are a star - thank you so much. I would never have guessed that an AV system (Sophos) could, without reporting any virus detection or other issue, prevent installation on one system whilst the same version does not prevent it on another. Suffice to say that disabling on-access scanning for the duration of installation fixed the problem.

Very weird indeed.

So, as a matter of protocol, do I close this as 'not a bug' or is that up to someone from ubuntu?

[Seth Forshee (sforshee)]

Glad that worked. I'll close the bug for you.

[Tim Passingham (tim-8aw3u04umo)]

To those not running Sophos - this will be meaningless, so please ignore!

However, to anyone using Sophos and seeing this report, I discovered that the problem only occurred on one of my systems because that was the only system not running Talpa - the better 'on access' scanning tool. It was running fanotify (the default) instead (because I didn't have the linux headers for the older kernel I had reinstalled).