Created attachment 655771 [details] "ausearch -m avc -ts recent" output Description of problem: On this computer, I have multiple OSes: Windows Vista, Ubuntu 12.04, Fedora 16, and Fedora 18 Beta. Fedora 18 Beta has control of the boot loader. When it was installed, F18 correctly built a /boot/grub2/grub.cfg with entries for the other OSes. After I upgraded Ubuntu, I needed to update F18's grub.cfg to reflect the new kernel Ubuntu kernel. (I think that it is a grave mistake that the grub.cfg doesn't just reference each other system's /boot/grub2/grub.cfg, but that is a different bug.) I built the new grub.cfg with grub2-mkconfig. It failed to include anything for Ubuntu. The reason is that the Ubuntu partition is not labelled (in the SELinux sense) and SELinux blocked os-prober when it tried to access the partition. I've attached the output of "ausearch -m avc -ts recent" Work around: do "setenforce 0" before the grub2-mkconfig and "setencforce 1" afterwards. I would like to thank Dominick Grift for his help in #fedora-selinux. Version-Release number of selected component (if applicable): os-prober-1.56-1.fc18.x86_64 How reproducible: always Steps to Reproduce: 1.on a system with a Linux distro on an unlabelled partition, run grub2-mkconfig Actual results: the resulting grub.cfg will not have entries for that distro Expected results: the resulting grub.cfg should have entries for that distro Additional info: I don't know how to fix this without either turning off SE enforcement (scary) or SE-labelling a partition that really has no business being labelled.
Restorecon -R -v -F /var/lib/os-prober/mount
in IRC, Dominick Grift says: "if you realy really dont want to label it then you can mount it with the context= or rootcontext= mount option." If that works for os-prober then this sounds like a good solution. Why I don't like the "Restorecon -R -v -F /var/lib/os-prober/mount" solution: 1) this partition does not "belong" to Fedora so mucking with it for Fedora seems wrong-headed. 2) Who should do this relabelling? Surely not os-prober since it should only read from the partition, not write to it. Surely not the user directly: why should she have to know about this arcane stuff (first mounting, then labelling, then unmounting: sheesh). 3) Why is it that Fedora would have to interfere with a Linux partition but not a Windows partition?
It is perhaps interesting that Ubuntu has a bug with the effect that it won't add grub menu entries for Fedora partitions. Although the effects are similar, the causes are quite different. <https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1038093>
(In reply to comment #2) > in IRC, Dominick Grift says: > > "if you realy really dont want to label it then you can mount it with the > context= or rootcontext= mount option." > > If that works for os-prober then this sounds like a good solution. > > Why I don't like the "Restorecon -R -v -F /var/lib/os-prober/mount" solution: > > 1) this partition does not "belong" to Fedora so mucking with it for Fedora > seems wrong-headed. If you mount it in Fedora then it belongs to Fedora > 2) Who should do this relabelling? Surely not os-prober since it should > only read from the partition, not write to it. Surely not the user > directly: why should she have to know about this arcane stuff (first > mounting, then labelling, then unmounting: sheesh). The system administrator/Owner should do the relabeling > 3) Why is it that Fedora would have to interfere with a Linux partition but > not a Windows partition? Windows partitions do not support extended attributes
@Dominick Grift comment 4: I (as a typical user) don't want Fedora to mount Ubuntu's partition. I do want it to create a correct and usable grub.cnf entry for Ubuntu. How it does it should not be my concern. It is an implementation detail that os-prober seems to need to mount the Ubuntu partition. Requiring a typical user to know that the Ubuntu partion needs to be SD-labelled and to know how to do that and to remember to do so seems really wrong. But letting os-prober do the SE-labelling behind the user's back is also pretty dubious. If os-prober can use context= or rootcontext= to avoid this, that would be a great solution. What would the downside be? (Pure guess: os-prober doesn't currently know about SE at all and upstream might not want to change that.)
Does this error happen in Fedora 17 and before, or it is a new restriction in Fedora 18? A context option can be added to os-prober to see if it works. I wonder which context should be used. Anyway, you can add a context option to "mount -o ro" command in the following files: /usr/libexec/linux-boot-probes/50mounted-tests /usr/libexec/os-probes/50mounted-tests /usr/share/os-prober/common.sh A context option should be added, for example (the context is just an example): mount -o ro,'context="system_u:object_r:tmp_t:s0",noexec'
I have a similar problem to D. Hugh Redelmeier , the originator of this bug report. When I installed F18, I could not include Ubuntu in the grub.cfg. I mounted all the partitions and grub2-mkconfig was able to pick up Ubuntu. Today I ran yum update -y , a new kernel was installed and on the reboot, ubuntu was omitted. mounting all the partitions did not work. I have three distributions Fedora17, ubuntu, Fedora18, and sometimes two others, as I write code in C and test the code with each distribution. With my little script lines setenforce 0 grub2-mkconfig >/tmp/grub.cfg setenforce 1 I have a small permanent solution. I go to /tmp first is to handle the case I change my mind while grub2-mkconfig is executing. By so doing, I will not have a partial /boot/grub2/grub.cfg Interestingly, on my second hardware box, the mbr points to Debian wheezy, and DW does not illustrate this problem.
@Hedayat Vatankhah #6: "Does this error happen in Fedora 17 and before, or it is a new restriction in Fedora 18?" I don't know. My machine is (1) no longer hooked up, and (2) never had Fedora 17. Before I installed Fedora 18 beta, Fedora 15 managed booting. I don't remember having this problem but I don't remember the whole story. I had F15 boot the bootloader of each of the other operating systems it booted (Win Vista, Fedora 16, Ubuntu 9.x). This is a very good way of working because it lets each OS do its own bootloader options. One problem is that each grub2 wants to own the MBR and space after it, so without strong coercion (--force to place on partition boot records), they won't co-exist.
I am confused now and this issue might actually be related to: http://lists.fedoraproject.org/pipermail/devel/2012-December/174761.html
Here is my config. Disk1 empty, msdos formatted and waiting for full disk install of F18 Disk2 Fedora 17, Ubuntu All distros 32bit. I install F18. It creates a grub.cfg without F17, but includes Ubuntu. I use yum to run all the updates to F18 I do a grub2-mkconfig and now I obtain all distrows, as I should and as I saw it with F17 or Ubuntu. even with new kernel in F17, when I reran the F18 grub2-mkconfig, it picked up the changes. Is the I386DVD created 11 Dec, far behind the grub2-mkconfig of F18, or is the context different? If I can help, please let me know, If there is a nightly build more current than the DVD, I can download it to test it.
(In reply to comment #10) Don't spam. It is clear that your problem is not related to this bug. I've already told you that this is another bug (bug #825236). Anyway, can anybody verify if comment #9 is related to this problem? That can be the issue.
Reply to Comment 8. It does work correctly with Fedora 17 on a system which has F18, Windows and Ubuntu
With Fedora 18 DVD, the problem is apparent. With the application of all updates, as of January 20th, the problem appears resolved.
Thank you for letting me know that the bug is fixed.