Hide Forgot
Created attachment 828747 [details] screenshot of s-c-k grubby error When starting up system-config-kdump, it attempts to call grubby to get info about current kernels. That fails because s-c-k calls it with an extra '--' argument and then it dies saying that it doesn't know how to configure my bootloader. See attached screenshot.
Ahh, and fwiw: system-config-kdump-2.0.14-1.fc20.noarch
Thank you for your report. The presence of this error message implies that s-c-k was unable to determine your bootloader. I'm wondering which boot loader are you using? Could you please run the following command to check whether the configuration files are where s-c-k is expecting them? ls -l /boot/grub/grub.conf /boot/efi/EFI/redhat/grub.conf /boot/grub2/grub.cfg /boot/efi/EFI/redhat/grub.cfg /boot/efi/EFI/fedora/grub.cfg /boot/etc/yaboot.conf /boot/efi/EFI/redhat/elilo.conf /etc/zipl.conf /boot/extlinux/extlinux.conf Also, please make sure there are no denials for access vectors involving s-c-k and bootloader configuration files by SELinux.
I'm using grub2 and the config files are in the normal spot. Please look again at the screenshot. The problem is that the tool is running this: grubby -- --info ALL ...instead of: grubby --info ALL
Yes, s-c-kdump is supposed to run grubby --$bootloadertype --info ALL however it seems that bootloader detection fails and empty string is appended to the double dash. This already happened, e.g. in bug #983017. Does your system boot via UEFI? Can you please confirm that this happens with SELinux in permissive mode as well?
No UEFI. Mine's a standard BIOS boot rig. Yes, setting SELinux into permissive mode seems to work around the problem. So I guess this is a policy issue?
Here are the AVC messages too: type=AVC msg=audit(1385477285.036:237): avc: denied { search } for pid=20191 comm="system-config-k" name="grub2" dev="md1" ino=16 scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir type=SYSCALL msg=audit(1385477285.036:237): arch=c000003e syscall=21 success=no exit=-13 a0=199ab00 a1=2 a2=32df3bff88 a3=0 items=0 ppid=20190 pid=20191 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="system-config-k" exe="/usr/bin/python2.7" subj=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1385477285.036:238): avc: denied { search } for pid=20191 comm="system-config-k" name="extlinux" dev="md1" ino=8193 scontext=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir type=SYSCALL msg=audit(1385477285.036:238): arch=c000003e syscall=21 success=no exit=-13 a0=194d490 a1=2 a2=32df3bff88 a3=0 items=0 ppid=20190 pid=20191 auid=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 ses=4294967295 tty=(none) comm="system-config-k" exe="/usr/bin/python2.7" subj=system_u:system_r:kdumpgui_t:s0-s0:c0.c1023 key=(null)
I think syscall=21 means that these were access() calls...
That would make sense, s-c-kdump detects the bootloader by checking access(bootloader_config, W_OK). I tried to reproduce the bug in current F20 but hit what looks like entirely different bug. I'm going to reassign this to selinux-policy - I suppose the maintainers would like to know: 1) version of selinux-policy 2) what does the AVC look like including paths, which you can enable by running # echo "-w /etc/shadow -p w" >> /etc/audit/audit.rules # systemctl restart auditd and then reproducing the bug again. Note: the paths that s-c-kdump checks are listed here: https://git.fedorahosted.org/cgit/system-config-kdump.git/tree/src/system-config-kdump-backend.py#n19
Ahh, I figured out the problem. My /boot filesystem was mislabeled: "/boot/extlinux default label should be boot_t." Sorry for the noise!