Created attachment 770104 [details] Description of 3 different OS2 boot loader outputs from a common desktop system Description of problem: I have a 4 disk system onto which are installed multiple operating systems. os-prober fails to detect the second of two operating systems installed, except in the case where the bootloader points to the second system as the second system was installed after the first one. Version-Release number of selected component (if applicable): Fedora 18, Fedora 19 How reproducible: Refer to attached libreoffice document. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Expect to see the operating systems that are bootable listed in os-prober output and hence, in grub.cfg Additional info: Refer to the attached document that I have included.
I currently cut and paste grub.cfg output from different Fedora versions to make a single consolidated grub.cfg. This consolidated output is easy to maintain.
I noted that each fedora version was installed on an non uefi system, using btfrs. When btfrs crashed (it is still flakey in F19), I reinstalled using LVM for file systems. With LVM the missing Fedora distribution was picked up and put into the initial grub. Thus /dev/sda Fedora19 with btfrs /dev/sdd Fedora 19 with lvm was detected by the Fedora 19 on /dev/sda But booting from /dev/sdd the Fedora /dev/sda was not detected. Hope this gets repaired before F20.
After an anaconda install and the reboot, osprober (or grub2) Does not show all other Fedora installations. Similarly, after a kernel upgrade, the same problem is manifested. So, after either a fresh Installation or kernel upgrade, I have to execute grub2-mkconfig. After this extra step, all distributions+windows are included.
What happens after a kernel upgrade?! For a kernel upgrade, just a new entry should be added to grub menu. (it uses grubby). So, on a kernel upgrade, neither os-prober nor grub2-mkconfig is run. If using grub2-mkconfig results in correct grub config, the bug should be related to anaconda. It probably doesn't enable btrfs volumes (like LVM problem in bug #825236) when generating grub.cfg. Is the initial bug report the same? (that you could get correct grub menu when running grub2-mkconfig after installation?)
OK, this is like the problem I was about to bugzilla so I will keep it simple and put it here. Simply put, someone changed the interface in linux-boot-prober and did not do anything for btrfs. [It has been broken since 1.57!] Therefore, the test which looks for the /boot for a BTRFS systems always fails. Does anyone regression test this stuff? Oh wait, it is BTRFS so we just ignore it! I can see what the problem is, now I just have to figure out how to fix it. If your problem does NOT involve running /etc/grub.d/30_os-prober, then please speak up and I will create a new bugzilla report.
Heydayat, I hope you understand this business with the file descriptors because I do not. I tried "fiddling" with the code and could not get anything to work. My "fiddling" consisted of adding some: "((" ... ") 9>&1 | logger 1>&- ) 3>&1 " code around the parts of the BTRFS code that actually does something most of the checks which simple error our I felt could be ignored. This did not have any effect. However, if I (with no code modifications) did the following: sudo grub2-mkconfig -o /boot/grub2/grug.cfg >9xx.9 3>xx.3 a "good" configuration was created with all of the various BTRFS systems listed. If nothing else, this is a good work-around until a fix can be done. Personally I have not been using os-prober that much until recently and I am about to create a BTRFS-only multi-boot system so I really wanted this to work.
Would you please tell me exactly which test fails? Also, please note that BTRFS support is NOT in upstream os-prober at all. So, it is natural that BTRFS support is suboptimal and I don't use BTRFS too. People like YOU can help us to have better BTRFS support.
OK, it appears that os-prober support for BTRFS has been broken since 1.58. The problem is the os-prober-factor-out-logger.patch which, for some reason, only captures the result and logger output of non-btrfs boot processing in linux-boot-prober. Moving the "( (" pair to the front of the file fixes things.
Created attachment 814173 [details] fix for btrfs in linux-boot-prober This patch is an update/replacement to the existing logger patch. While all that should have been necessary is to create an new additional patch updating linux-boot-prober which deleted the "( (" around line 158 and added "( (" near the beginning of the file, for some reason patch just did not like fooling around with the code around line 158. I was able to fix things by redoing the entire patch. Hey, whatever works. For anyone needing a quick fix, just edit /usr/bin/linux-boot-prober and make the change ... works like a charm
It appears there may well be multiple problems and the attached patch only fixes one of them. There are three different possibilities for /boot with respect to a btrfs root system: 1) /boot on a regular partition or logical volume (works), 2) /boot does not exist separately (works) and 3) /boot is a separate btrfs subvol (does not work). Now that linux-boot-prober does work with btrfs, I can look into why it does not handle /boot being a separate btrfs subvolume.
Created attachment 816272 [details] fix 40grub2 to handle /boot on separate btrfs subvol This should round out the fixes for btrfs support.
The two patches I attached have been tested on both Fedora 19 with grub2-2.00-23 and Fedora 20 Beta-TC5 with grub2-2.00-25. The updates are against os-prober-1.58-4.
Unfortunately the logger factoring has an undesireable side effect which is exacerbated by my patch: a whole bumch of junk debug messages are being pushed into syslog marked 40grub debug. One additional item, currently, the patch for os-prober debug defaults to the debug messages being sent to syslog. The DEFAULT should really be that no messages are sent to syslog and that you need to ENABLE DEBUG. Do you want me to file a separated bugzilla report suggesting that?
Thanks again for the report and the patches, I'll try to examine them tonight (sorry for being late, I'm pretty busy and behind schedule) and see if there are excess logging and why. But about logging debug messages by default, this is the default upstream behavior. And, IIRC, there is a bug about it already (maybe closed) where I decided not to change this behavior. You might file a bug upstream, but I'm not going to do it in Fedora (as a patch). Logging debug messages is fine for os-prober, because this tool normally is rarely used (Many might never execute it except in the installation process (by anaconda)).
OK, I will leave logging debug alone. As a matter of fact, anaconda does not use os-prober but grub2 does for its "/etc/grub.d/30_os-prober" when it scans all partitions on all disks to see if there is anything that might be bootable. The patches I have submitted are needed for btrfs to function but a side effect is that 40grub2 produces a lot of trash in syslog. Looking at 40grub2, there are a lot of "log" statements that appear to be for debug purposes. I am going to do a patch which changes those to debug so that it can be controlled by OS_PROBER_DISABLE_DEBUG=1 I will have the patch in later today.
Created attachment 827896 [details] change log to debug in 40grub2 and add DISABLE_DEBUG test to result This proved to be easier to do that I thought it might. The changes to 40grub2 and 40grub as well as add the test to "result in common.sh means that as far as I can test, everything is ver quiet when os-prober is run by grub2. There is some "noise" from the kernel with respect to btrfs but it is minor. This is not doing what I need done. And if OS_PROBER_DISABLE_DEBUG is not specified, syslog is cluttered with messages as usual. If you are wondering why, see bugzilla 864198
Created attachment 827955 [details] minimize debug to syslog: 40grub2, 40grub, common:result, 20macosx more message suppresion
The BTRFS patches will be applied to os-prober. I'm a little skeptical about the last one, but it'll be probably applied too (maybe except the result() change). According to Fedora rules, we should try to not apply non-critical patches to packages and send them upstream. But since os-prober upstream is so unresponsive... I wonder if creating a fork is a good idea.
At least part of that last patch was closing the circle with respect to putting OS_PROBER_DISABLE_DEBUG in charge of sending those debug messages to syslog. Putting it around sending "result" to syslog, not so much. Maybe that should be a separate switch such as OS_PROBER_NO_RESULT_TO_SYSLOG. I am just trying to make the running of of-prober be as quiet as possible. As far as forking os-prober, that might make sense but you might want to talk to 1) grub2 folks and 2) fedora folks first. The grub2 folks because they are the ones using os-prober in this environment and the Fedora folks because they might be the ones to "sponsor" the fork. While I am more than willing and able to help and have the resources to do some development and testing, I am retired and more than a little "long in the tooth" to take on package responsibilities. That said, I have heard rumblings from time to time that the grub2 people (among others) would like to get rid of os-prober. You know, os-prober is not all that bad. Given what it has to do, it does it pretty well. You could re-implement it in python but I am not sure that the implementation would reallyu do things much differently. I am using os-prober on some of my systems but I also use /etc/grub.d/40_custom configurations where I create my own menuentry definitions which sort-of chain-loads to a second system's grub.cfg. This is what I use on most of my multi-boot systems. One alternative to an os-prober is a "simplified" os-prober which automates what I create manually. Since this could be run infrequently, you might even make it interactive and a gui. One big question which I cannot answer is what grub2 plans to do (if anything different).
os-prober in rawhide is still not fixed. The grub2 in rawhide is current and addresses outstanding btrfs problems (the fixes have been upstream for some time but had not made it into Fedora).
os-prober-1.58-5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/os-prober-1.58-5.fc19
os-prober-1.58-5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/os-prober-1.58-5.fc20
needs a little more work ... the patch to eliminate more debug messages (changing "log" to "debug") is missing although the rpm changelog says it is there.
Package os-prober-1.58-5.fc20: * should fix your issue, * was pushed to the Fedora 20 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing os-prober-1.58-5.fc20' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-5611/os-prober-1.58-5.fc20 then log in and leave karma (feedback).
No, that was intentional. The changelog refers to changing debug() function in macosx related file. I've decided to not change log functions to debug as you did for now. I have not yet decided if I should start doing such changes to Fedora os-prober package. Thank you for your feedback and patches. However, the package really does fix this bug!
os-prober-1.58-5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
os-prober-1.58-5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.