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 Toolybird (Toolybird) - Tuesday, 02 May 2023, 21:56 GMT
Opened by Emil (xexaxo) - Tuesday, 28 September 2021, 22:03 GMT
Last edited by Toolybird (Toolybird) - Tuesday, 02 May 2023, 21:56 GMT
|
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
Closed by Toolybird (Toolybird)
Tuesday, 02 May 2023, 21:56 GMT
Reason for closing: Fixed
Additional comments about closing: "The mutable files are no longer in our linux packages."
Tuesday, 02 May 2023, 21:56 GMT
Reason for closing: Fixed
Additional comments about closing: "The mutable files are no longer in our linux packages."
`Target = usr/lib/modules/*/modules.alias`
Perhaps that one should be updated to:
`Target = usr/lib/modules/*/modules.builtin`
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.
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
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.
The kmod.patch, drop "Operation = Remove" from the existing hook (+ minor cleanup) and adds depmod-remove.hook, doing the cleanup.
Thus as follow-up the linux packages - linux, linux-lts, etc - can apply a patch like linux.patch so they no longer own the mutable modules.foo files.
Both patches are based on `asp checkout` and the core packages. Happy to respin them in other shapes or forms.
Thanks o/
How can I help with anything to get them (or variation thereof) merged?
I'll take a look when I can find the time.
IMHO having the script do both generation and removal is fairly ambiguous and a recipe for disaster. There's a reason we don't keep the rubbing alcohol amongst the drinking water bottles :-P
Looking at the proposed change and I'm not sure ... seems like it will do the wrong thing by mistake.
Say if the user has renamed the vmlinux file (debugging something) and an out of tree kernel module gets updated. I might be reading it wrong, but to me it seems like all `modules.*` will be removed - generated and the ones from the kernel package.
What makes it worse is the removal is not displayed in the pacman log, the system is borked and depmod cannot regenerate the mutable files since the critical modules.builtin, modules.order etc are gone.
Mind you, I'm not 100% sure with my analysis so feel free to correct me.
But with your code the situation is even worse. Your remove hook will remove all modules.* files when any module package gets removed, no prior screwing around required.
pacman -S vhba-module
(2/2) Updating module dependencies...
pacman -R vhba-module
(1/1) Removing module dependencies...
pacman -S vhba-module
(2/2) Updating module dependencies...
depmod: WARNING: could not open modules.order at /lib/modules/5.17.1-arch1-1: No such file or directory
depmod: WARNING: could not open modules.builtin at /lib/modules/5.17.1-arch1-1: No such file or directory
Edit: the patch is still broken... Might need to rethink the approach.
This is what I intend to apply to linux: https://paste.xinu.at/dZ2Nl8/
- original depmod hook is unchanged - it must be called even on Remove operation
- renamed the removal hook (modules-remove) - triggers on ...pkgbase aka linux-foo package removal
Tested permutations of the following:
- pacman -Syu linux linux-lts - depmod triggers, regenerates mutable files
- pacman -S vhba-module - depmod triggers, regenerates mutable files
- pacman -R vhba-module - depmod triggers, regenerates mutable files
- pacman -R linux-lts - modules-remove triggers, removes the mutable files
We can ignore the trivial issues like misleading hook message and rmdir workaround (since it's ran post transaction).
Looking at the kernel patch - as-it it will result a warning and will break dkms (unless s/alias/builtin/ is applied)
Warning: 'make modules_install' requires $DEPMOD. Please install it.
This is probably in the kmod package.
When the linux patch (you linked) gets applied, the modules.alias will not be owned by anyone. Since the target is effectively missing, the hook won't be executed.