Hide Forgot
Description of problem: # LANG=C package-cleanup -y --verbose --oldkernels --count=1 Loading "auto-update-debuginfo" plugin Not loading "blacklist" plugin, as it is disabled Loading "langpacks" plugin Loading "refresh-packagekit" plugin Not loading "whiteout" plugin, as it is disabled Adding en to language list Config time: 0.015 rpmdb time: 0.000 Setting up Package Sacks Found 10 installed debuginfo package(s) Enabling fedora-debuginfo: Fedora 16 - x86_64 - Debug Enabling rpmfusion-nonfree-debuginfo: RPM Fusion for Fedora 16 - Nonfree - Debug Enabling livna-debuginfo: rpm.livna.org for 16 - x86_64 - Debug Enabling rpmfusion-free-updates-debuginfo: RPM Fusion for Fedora 16 - Free - Updates Debug Enabling rpmfusion-free-debuginfo: RPM Fusion for Fedora 16 - Free - Debug Enabling updates-debuginfo: Fedora 16 - x86_64 - Updates - Debug Enabling rpmfusion-nonfree-updates-debuginfo: RPM Fusion for Fedora 16 - Nonfree - Updates Debug pkgsack time: 0.177 --> Running transaction check ---> Package kernel.x86_64 0:3.1.0-0.rc10.git0.1.fc16 will be erased Checking deps for kernel.x86_64 0:3.1.0-0.rc10.git0.1.fc16 - e ---> Package kernel.x86_64 0:3.1.0-1.fc16 will be erased Checking deps for kernel.x86_64 0:3.1.0-1.fc16 - e --> Finished Dependency Resolution Dependency Process ending Depsolve time: 1.177 Dependencies Resolved ==================================================================================================================================== Package Arch Version Repository Size ==================================================================================================================================== Removing: kernel x86_64 3.1.0-0.rc10.git0.1.fc16 @anaconda-0 111 M kernel x86_64 3.1.0-1.fc16 @fedora 111 M Transaction Summary ==================================================================================================================================== Remove 2 Packages Installed size: 221 M Downloading Packages: Member: kernel.x86_64 0:3.1.0-0.rc10.git0.1.fc16 - e Removing Package kernel-3.1.0-0.rc10.git0.1.fc16.x86_64 Member: kernel.x86_64 0:3.1.0-1.fc16 - e Removing Package kernel-3.1.0-1.fc16.x86_64 Running Transaction Check Transaction Check time: 0.033 Running Transaction Test Transaction Test Succeeded Transaction Test time: 0.065 Running Transaction Error in PREUN scriptlet in rpm package kernel Error in PREUN scriptlet in rpm package kernel Warning: scriptlet or other non-fatal errors occurred during transaction. kernel-3.1.0-0.rc10.git0.1.fc16.x86_64 was supposed to be removed but is not! kernel-3.1.0-1.fc16.x86_64 was supposed to be removed but is not! VerifyTransaction time: 0.051 Transaction time: 0.495 Failed: kernel.x86_64 0:3.1.0-0.rc10.git0.1.fc16 kernel.x86_64 0:3.1.0-1.fc16 Complete! Additional info: Kernel-devel also threw errors, but got uninstalled in the end: Usuwanie : 1:kmod-nvidia-3.1.0-0.rc10.git0.1.fc16.x86_64-285.05.09-1.fc16.1.x86_64 1/6 Usuwanie : 1:kmod-nvidia-3.1.0-1.fc16.x86_64-285.05.09-1.fc16.2.x86_64 2/6 Error in PREUN scriptlet in rpm package kernel Error in PREUN scriptlet in rpm package kernel Usuwanie : kernel-devel.x86_64 3/6 /var/tmp/rpm-tmp.yhkLMg: /sbin/new-kernel-pkg: /bin/bash: zły interpreter: Brak dostępu błąd: Skrypt %preun(kernel-3.1.0-1.fc16.x86_64) nie powiódł się, stan wyjścia 126 błąd: kernel-3.1.0-1.fc16.x86_64: usunięcie nie powiodło się /var/tmp/rpm-tmp.bXTZ6D: /sbin/new-kernel-pkg: /bin/bash: zły interpreter: Brak dostępu błąd: Skrypt %preun(kernel-3.1.0-0.rc10.git0.1.fc16.x86_64) nie powiódł się, stan wyjścia 126 błąd: kernel-3.1.0-0.rc10.git0.1.fc16.x86_64: usunięcie nie powiodło się Usuwanie : kernel-devel.x86_64 4/6 kernel-3.1.0-0.rc10.git0.1.fc16.x86_64 was supposed to be removed but is not! kernel-3.1.0-1.fc16.x86_64 was supposed to be removed but is not! The Polish text says /bin/bash: bad interpreter: Access denied (...) exit status 126.
This is what I found in /var/log/messages: Nov 2 18:36:18 snowball2 yum[4699]: Erased: 1:kmod-nvidia-3.1.0-0.rc10.git0.1.fc16.x86_64-285.05.09-1.fc16.1.x86_64 Nov 2 18:36:18 snowball2 kernel: [ 6239.798203] type=1401 audit(1320255378.926:4): security_compute_sid: invalid context unconfined_u:unconfined_r:depmod_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:depmod_exec_t:s0 tclass=process Nov 2 18:36:19 snowball2 yum[4699]: Erased: 1:kmod-nvidia-3.1.0-1.fc16.x86_64-285.05.09-1.fc16.2.x86_64 Nov 2 18:36:19 snowball2 kernel: [ 6240.192469] type=1401 audit(1320255379.321:5): security_compute_sid: invalid context unconfined_u:unconfined_r:depmod_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:depmod_exec_t:s0 tclass=process Nov 2 18:36:19 snowball2 kernel: [ 6240.496549] type=1401 audit(1320255379.625:6): security_compute_sid: invalid context unconfined_u:unconfined_r:bootloader_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bootloader_exec_t:s0 tclass=process Nov 2 18:36:19 snowball2 kernel: [ 6240.546532] type=1401 audit(1320255379.675:7): security_compute_sid: invalid context unconfined_u:unconfined_r:bootloader_t:s0-s0:c0.c1023 for scontext=unconfined_u:unconfined_r:rpm_script_t:s0-s0:c0.c1023 tcontext=system_u:object_r:bootloader_exec_t:s0 tclass=process Nov 2 18:36:23 snowball2 yum[4699]: Erased: kernel-devel Nov 2 18:36:23 snowball2 yum[4699]: kernel-devel: ts_done name in te is kernel should be kernel-devel Nov 2 18:36:29 snowball2 yum[4699]: Erased: kernel-devel Nov 2 18:36:29 snowball2 yum[4699]: kernel-devel: ts_done name in te is kernel should be kernel-devel
this is probably a problem with kmod-nvidia vs selinux.
I'll run a full relabel and see if it goes away.
yum -y update to get latest selinux-policy restorecon -R -v /sbin # ls -lZ /sbin/new-kernel-pkg -rwxr-xr-x. root root system_u:object_r:bin_t:s0 /sbin/new-kernel-pkg Make sure it looks like this, There was a labeling problem where this file as labeled bootloader_exec_t.
I needed to update to selinux-policy-3.10.0-51.fc16.noarch from testing to fix this problem. Console is still not error-free though: Test transakcji został ukończony powodzeniem Wykonywanie transakcji Usuwanie : kernel.x86_64 1/2 /sbin/new-kernel-pkg: line 277: /sbin/grubby: Brak dostępu /sbin/new-kernel-pkg: line 284: /sbin/grubby: Brak dostępu Usuwanie : kernel.x86_64 2/2 /sbin/new-kernel-pkg: line 277: /sbin/grubby: Brak dostępu /sbin/new-kernel-pkg: line 284: /sbin/grubby: Brak dostępu Again sorry for Polish. The errors say /sbin/grubby: Access denied. I ran package-cleanup via sudo, and there are no denials in the log.
To add more info, old kernels are still in /boot/grub2/grub.cfg even though the kernel rpms are gone.
Can you run "/sbin/grubby --help"? Have you done a full relabeling? How? Do "yum reinstall grubby" make any difference?
$ sudo /sbin/grubby --help [sudo] password for julas: Usage: grubby [OPTION...] --add-kernel=kernel-path add an entry for the specified kernel --add-multiboot=STRING add an entry for the specified multiboot kernel --args=args default arguments for the new kernel or new arguments for kernel being updated --mbargs=STRING default arguments for the new multiboot kernel or new arguments for multiboot kernel being updated --bad-image-okay don't sanity check images in boot entries (for testing only) --boot-filesystem=bootfs filestystem which contains /boot directory (for testing only) --bootloader-probe check if lilo is installed on lilo.conf boot sector -c, --config-file=path path to grub config file to update ("-" for stdin) --copy-default use the default boot entry as a template for the new entry being added; if the default is not a linux image, or if the kernel referenced by the default image does not exist, the first linux entry whose kernel does exist is used as the template --default-kernel display the path of the default kernel --elilo configure elilo bootloader --extlinux configure extlinux bootloader (from syslinux) --grub configure grub bootloader --grub2 configure grub2 bootloader --info=kernel-path display boot information for specified kernel --initrd=initrd-path initrd image for the new kernel -i, --extra-initrd=initrd-path auxilliary initrd image for things other than the new kernel --lilo configure lilo bootloader --make-default make the newly added entry the default boot entry -o, --output-file=path path to output updated config file ("-" for stdout) --remove-args=STRING remove kernel arguments --remove-mbargs=STRING remove multiboot kernel arguments --remove-kernel=kernel-path remove all entries for the specified kernel --remove-multiboot=STRING remove all entries for the specified multiboot kernel --set-default=kernel-path make the first entry referencing the specified kernel the default --silo configure silo bootloader --title=entry-title title to use for the new kernel entry --update-kernel=kernel-path updated information for the specified kernel -v, --version print the version of this program and exit --yaboot configure yaboot bootloader --zipl configure zipl bootloader Help options: -?, --help Show this help message --usage Display brief usage message I have actually done a full relabeling (which I mentioned in comment 3) by activating it in system-config-selinux. The label on /sbin/grubby is as follows: $ ls -lZ /sbin/grubby -rwxr-xr-x. root root system_u:object_r:bootloader_exec_t:s0 /sbin/grubby rpm -V grubby shows no issues.
Dan, I assume /usr/bin/package-cleanup should be system_u:object_r:rpm_exec_t:s0 too?
Yes good point. Fixed in selinux-policy-3.10.0-54.fc16
Looking at the changelog, it seems like the fix did not make it into this build: http://koji.fedoraproject.org/koji/buildinfo?buildID=272301
/me starts thinking: How about /usr/bin/debuginfo-install and /usr/bin/yum-builddep ? These issues have apparently not been noticed in other ways, so it seems to me like access to rpm_var_lib_t is less restricted than it should be?
Well you are running as unconfined_t most likely so it would not be a problem. Only time this ends up in a problem is if a rpm runs post install scripts.
I would like to retract comment 11 - the fix is in there, this problem is really fixed in selinux-policy-3.10.0-54.fc16.
selinux-policy-3.10.0-55.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/selinux-policy-3.10.0-55.fc16
selinux-policy-3.10.0-55.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.