Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#72275 - [linux] [linux-lts] [linux-zen] [linux-hardened] Consider removing mutable modules.*

Attached to Project: Arch Linux
Opened by Emil (xexaxo) - Tuesday, 28 September 2021, 22:03 GMT
Last edited by Andreas Radke (AndyRTR) - Wednesday, 29 September 2021, 05:04 GMT
Task Type Bug Report
Category Kernel
Status Assigned
Assigned To Andreas Radke (AndyRTR)
Jan Alexander Steffens (heftig)
Levente Polyak (anthraxx)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

Description:

Currently the linux packages, ship the immutable and _mutable_ modules.* files alongside them.
As such running pacman's package check complains about modification time mismatch.

AFAICT this happens since the depmod hook is executed as the package is installed.
Running the hook in itself is the right thing to do IMHO, yet I don't see any value in shipping the mutable files.

The attached trivial patch fixes the problem for me. It is against the linux package - the kernel I use 99% of the time.
Happy to provide more patches if needed.


Additional info:
* package version(s)

linux 5.14.8-arch1-1
linux-lts 5.10.69-1
linux-zen 5.14.8.zen1-1
linux-hardened 5.14.8.hardened1-1


Steps to reproduce:
- install any of the four kernel packages - for example linux
- verity the package integrity - pacman -Qkk linux
- observe nearly a dozen warnings

warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.alias (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.alias.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.builtin.alias.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.builtin.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.dep (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.dep.bin (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.devname (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.softdep (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.symbols (Modification time mismatch)
warning: linux: /usr/lib/modules/5.14.8-arch1-1/modules.symbols.bin (Modification time mismatch)

This task depends upon

Comment by Emil (xexaxo) - Tuesday, 28 September 2021, 22:06 GMT
Hmm just noticed the dkms hooks have this match:
`Target = usr/lib/modules/*/modules.alias`

Perhaps that one should be updated to:
`Target = usr/lib/modules/*/modules.builtin`
Comment by Levente Polyak (anthraxx) - Wednesday, 29 September 2021, 07:53 GMT
having modified time mismatch is fine. if we do not package those files and uninstall one of the kernels we will leave files back cluttering the root file system with untracked files.
Comment by Jan Alexander Steffens (heftig) - Wednesday, 29 September 2021, 10:30 GMT
I guess we could package them empty to save some package size?
Comment by Emil (xexaxo) - Wednesday, 29 September 2021, 14:56 GMT
Good point about the untracked files. My initial inclination is that the depmod hook should be garbage collecting those, since it's the one creating them.
Will polish my pacman hook knowledge and propose a concrete patch in the coming days.

Don't think it's worth leaving them empty, since a) they're really small ~5MiB and b) this will flag a "File is modified" warnings by pacman which are more important.
Comment by Levente Polyak (anthraxx) - Wednesday, 29 September 2021, 15:02 GMT
I don't think those are really important. You can't rely on pacman notified changes to classify them as "bugs" or problems. We are also using tmpfiles with sysusers massively that changes files reported by the pacman.
Comment by Emil (xexaxo) - Wednesday, 29 September 2021, 18:41 GMT
So basically you're saying that I should not be looking at `pacman -Qkk`? Keep in mind I recently added support to validate the checksum of installed files.

AFAICT I'm not the only developer (kernel or otherwise) to regularly hack my Arch install, and since the package manager is smart I heed it's advice to pick the pieces.

I get your point that this is minor, but don't shrug it off. Especially not since pacman had to disable the ownership warnings few years ago.

[1] https://gitlab.archlinux.org/pacman/pacman/-/commit/ba869597fb64f1101012df4b0d834ed5eced0b7c
Comment by Levente Polyak (anthraxx) - Thursday, 30 September 2021, 08:24 GMT
The ownership warnings are still in place and report changes:

https://gitlab.archlinux.org/pacman/pacman/-/blob/HEAD/src/pacman/check.c#L78-104

I'm not shrugging it off and I'm not saying you shouldn't run that command :) What I tried to say is that you cannot blindly rely on the output. There are packages with UID/GID, Permissions or potentially other warnings that will break if they are blindly "fixed/reverted". What i tried to say is that the context of the file and the type of a warning is important.

Loading...