Description of problem: 1. regular ext2 partitions are used for /boot 2. There are two separate btrfs storage pools created each with a F18 system installed. 3. Doing grub2-mkconfig usually locates all of the bootable systems and adds entries for them in grub.cfg ... at least this is the way it works with regular partitions and LVs. Version-Release number of selected component (if applicable): F18-beta How reproducible: yes Steps to Reproduce: 1.Install a system on a btrfs volume. 2.Install a new, separate systems on a second btrfs volume 3.run grub2-mkconfig Actual results: grub.cfg only for the running system Expected results: entry(ies) for the running system and an special entry for the other system Additional info: This was done using qemu-kvm.
please post the output of 'os-prober'.
Created attachment 667344 [details] output of grub2 abd other commands There are two instances of F18 installed into a single qemu/kvm/libvirt virtual system. Both systems use swap on vda2. The "A" instance has vda1, regular partition, ext2, /boot; vda5, btrfs, subvols root and home. The "B" instance has vda3, regular partition, ext2, /boot; vdb2, btrfs, subvols root2 and home2. Currently, I am using grub2 installed into the boot partition and a simple addition of chainloader +1 to "40_custom". The next attachment is the output (console and syslog) from runnins "os-probe"
Created attachment 667345 [details] os-prober output
1. Thank you for the report 2. It is usually advised to attach logs as plain-text. 3. Currently, os-prober doesn't have any code for handling btrfs partitions specifically. I should investigate further to see what is actually needed in this case. If you can help in this regard, it is really appreciated since I don't have any BTRFS partitions currently. For example, can you tell me what steps you should exactly take to mount the / partition of the other installation in one of your F18 installations?
As far as the gzipped log file ... I got used to gzipping them after a couple of times when I needed to add some large log files. Btrfs is "not your father's filesystem" and needs to be looked at very differently. It is not like lvm where a logical volume looks like another partition. A BTRFS volume/storage-pool is not usually mounted. Instead, subvolumes are mounted (they look a bit like a directory). My hunch is that it will be a long time before btrfs is supported. Now, with btrfs in a manner like lvm, the /boot partition (and swap) partitions must be regular partitions. If os-prober could do its job with just access to those /boot partitions and the grub2 files on them. On a BTRFS system, the vmlinuz line includes something like: root=UUID=<uuid-number> rootflags=subvol=root Unless you are awash in hardware, I suggest using a virtual machine for testing. Currently, I am installing grub2 in the /boot partition rather than the MBR and using "chainloader +1" on the system that boots from MBR. This works although I heard some mumbling that grub2 discourages partition installation.
No, os-prober doesn't generate its list of Linux OSes based on /boot/ partition, but it first finds an / partition for them and then parses their corresponding grub config file in /boot. So, os-prober needs to be able to mount root filesystem on a btrfs volume/subvolume.
OK, if I understand correctly (no a given), os-prober shuffles through all of the partitions on a system looking for a root partition [what do you use to determine that?]. Then you use that to locate /boot is it is separate partition or just look in the boot directory and then down to the grub.conf file. If you want, I can run through what I believe needs to be done but I am a novice with respect to btrfs and you would be better off contacting one of the btrfs developers. BTW, from all of the messages in syslog, I assume that os-prober is looking for other systems such as windows and not just linux. My suggestion: put a message in the F18 release notes that says grub2/os-prober does not currently support booting multiple btrfs installed systems on the same hardware. That, and queue something up for F19 or F20 at the earliest.
Yes, this is how os-prober detects "Linux OS"es (it looks for /lib/ld-*.so or /lib/ld-linux.so.2, I don't remember exactly which one). I never said that os-prober detects Linux systems only, I was talking about how it detects Linux OSes. Other OSes are found differently. About BTRFS, what is needed in os-prober is just these: 1. how can we get a list of all btrfs volumes/subvolumes 2. how to mount them. I don't know how we should propose new notes on release notes. However, since it is "normal" and it is not supported by os-prober everywhere (except if some patches are already created by other distros), probably there is no need to put it in the release notes.
Created attachment 667844 [details] A patch from Ubuntu's os-prober which is supposed to fix btrfs subvolume detection problem Would you please apply this patch (or apply the changes to 50mounted-tests files /usr/libexec/linux-boot-probes/50mounted-tests and /usr/libexec/os-probes/50mounted-tests) to see if it fixes the problem?
I am not sure what to expect. The updated os-prober still worked but it did not "see" the second btrfs volume with the second installed system (both on the same virtual system). I can boot the second system using chainloader +1 to the /boot partition with grub2 installed into the partition.
I have been looking into os-prober and that btrfs oatch ... it fixes nothing! To give you some reference: 1. the btrfs volume/storage-pool is similar to LVM's Volume Group and 2. the btrfs subvolume is similar to LVM's Logical Volume Unfortunately, there is no easy way to determine what the btrfs subvolumes are. 1. "btrfs fi show" will list the btrfs volumes on a system (mounted or not). 2. "mount -t btrfs <partition-id> <mount-point-1>" 3. "btrfs su list <mount-point-1>' will give you the subvolumes on btrfs-volume 4. "mount -t btrfs -o subvol=<btrfs-subvol-name> <partition-id> <mount-point-2>" <parition-id> is often the UUID for this btrfs storage pool but could also be the label or the first partition of the btrfs storage-pool or it could be the first disk of a btrfs storage pool If you do an "ls" on the mounts btrfs-volume, you can see what looks like one or more directories ... these are the subvolume but I would not recommend accessing them as simple directories. For os-prober to support btrfs is going to require a lot more of a patch. I have added the btrfs-progs maintainer as a CC. He is more likely to provide good info.
Thank you for the response. I should admit that I was going to sleep when I found and posted the patch, so I didn't look at it to see if it is really solving the problem. Sorry again. And thank you for the summary about btrfs volumes and subvolumes. I will try to find some examples and their outputs to see how the actual outputs are and what should be done. Providing some examples here might be helpful too. (Unfortunately, I can't try to experiment with real/virtual installation for a while as I'm struggling with my probably-failing-soon hard disk :P).
OK, I found something and this might just be a patch which does the "heavy lifting" -- https://gitorious.org/chakra-packages/platform/commit/9db6375e08aaa2db019570ad7dd4c62842e36d9a?format=diff I am working on this but you may get there before me. Try doing a "wget" with the above URL. I am not familiar with "gitorious" and their way of doing things does not seem like a regular git repository.
Upon further examination of this patch, it is as useful as the other one! I sense a significant lack of understanding of btrfs volume/subvolume ... thing LVM VG and LV.
... "think" LVM VG and LV.
Before you start work on a patch, please contact me -- I am working on a patch and part 1 is mostly complete (os-prober mostly works). linux-boot-prober will be more difficult and there will likely be some patches needed to grub2 also. If anyone reading this has a comment/suggestion, any help appreciated.
About the patch in chakra, yes it is almost the same as the ubuntu one, and does the same thing. And about your work: thank you! That is great. It would take some time for me to start working on a patch, but reviewing a patch is much easier. I'm waiting for your patch.
Created attachment 670472 [details] add BTRFS support to os-prober and linux-boot-prober Here is my first attempt.
Thanks. I'll try to have a look and also send it upstream soon. Meanwhile, any enhancements are appreciated. ;)
I am going to let a little time pass and then review the code again. I believe that it is doing what I wanted it to do. It turns out the changes needed to grub2 are not significant ... a few lines of code need to added/changed in grub2's 30_os_prober shell script. Oh, and grub2 has a small problem in 10_linux and 20_linux_xen with btrfs filesystem for root if the filesystem is on more than one partition. Although the patch to grub2 is small, the grub2 RPM is a bit of puzzle as to how additional patches are added ... first time I have seen git used inside of an rpm.
Created attachment 672110 [details] patch to grub2 which uses the new os-prober btrfs support Here is the patch for grub2 also. As far as I can tell with the testing I have done, os-prober is working as I intended. However, I am having second thoughts about the whole grub2-multiboot issue and may be leaning toward a "grub2 partition" with a specialized grub.cfg file which includes the cfg files from the various boot partitions and just suppressing os-prober.
Thank you Gene, however please open a separate bug against grub2 and post the patch there, since this bug is specific to os-prober which is separate from grub2, and I cannot do anything about a grub2 patch. And grub2 guys also prefer to have a new approach to multi-boot which you can discuss with them. However, you should consider that not all systems use Grub, so you still need a way to detect "other OSes".
I am having lots of second thoughts about os-prober, etc. and grub2's use of it in multi-boot situations. I have submitted a bugzilla report on the "enhanced" os-prober: https://bugzilla.redhat.com/show_bug.cgi?id=890987 There are a couple of "old sayings" that may be appropriate: 1. If it hurts, don't do that 2. KISS -- keep it simple ... Basically, I believe that the better/simpler way is to not use os-prober for "large" multi boot systems. Instead, have a "grub boot director partition" with the grub files and a simple grub.cfg -- this would be pointed to by the grub2-install for the MBR. The grub.cfg file would contain some simple menuentry statements with reference the configfile for each system. The multiboot systems would also have GRUB_DISABLE_OS_PROBER=true specified to keep their menus simple. I am doing more testing and putting together a suggested patch for Fedora's grub2. I will be submitting an RFE when I get everything together.
Why not have os-prober look in each btrfs subvolume for /etc/fstab? Maybe such a search takes a long time? Perhaps some assumptions can be made. If a subvol doesn't contain etc, then it won't contain fstab, so move on to the next subvol. If fstab is found, it will provide a means to assemble the available subvolumes, or even a combination of subvols and non Btrfs volumes. The problem with fstab alone is that the subvol= option may not use an absolute path, in which case it could be ambiguous what subvol the fstab is referring to. Further complicating this is if subvols are renamed or moved, everything breaks, and as such I think subvol= is inherently fragile. So I wonder about the effort (how much work, and what priority) to get GRUB2 to understand subvolid. Ideally, btrfs.mod would be able to do this, so core.img can directly resolve a prefix based on subvolid, and a grub.cfg that includes one. But still better than nothing is if os-prober can resolve subvolid in fstab into an absolute path, and bake the absolute path into core.img when grub-install is called, and into grub.cfg when grub-mkconfig is called. Thing is, that doesn't work longer term for UEFI and secure boot where the grub.efi can't be expected to be overwritten each time since it's signed. So I still think btrfs.mod needs to know subvolid to avoid fragility.
If you take a look at the os-prober code, it "looks" at each partition, LV, and (with my patch) btrfs subvolume to see if it is a "known" system type and, if it is, it examines /etc/fstab to see if /boot is separate or part of the root filesystem. Info is then passed back to the caller. Try running os-prober on a system and you will get the idea of what it does. As far as grub2 understanding btrfs subvolumes, it is not clear if it does or does not. There are comments in the changelogs that imply it does. There are also the zfs changes which also might be applicable. I do not have a good enough btrfs knowledge to understand what grub2 should or should not be doing. I also do not understand just what code changes were made to support btrfs. Grub2 does not use git and I have come to appreciate just how useful git logs and being able to deconstruct things can really help understanding things..
Further testing shows that the patch needs more work ... it is not handling /boot on btrfs
Created attachment 676324 [details] updates patch adding btrfs support The patch has been rebased for: https://bugzilla.redhat.com/show_bug.cgi?id=893997 https://bugzilla.redhat.com/show_bug.cgi?id=893472 This updated patch now supports not only "/" (root) being on btrfs but also /boot as a separate subvolume. Also supported is when /boot is on the root subvolume. This should now cover all cases. An updated grub2 is still required to exploit then enhancements.
Thanks again for your patch. I have a question about this patch: does unpatched grub2-mkconfig still work after applying this patch if running on a system with btrfs volumes? Or a patched grub2 is needed? (Can I apply this patch to os-prober packages right now (even if grub2 is not updated), or I should wait for grub2's patch to be applied first?) Also, I saw that you've changed some 'exit 0's to 'exit 1'. This isn't related to this bug, right? Looks like to be a general bug fix rather than being related to btrfs fix.
Unpatched grub2 will continue to work. In fact, it will also continue to work if a patched grub2 has an unpatched os-prober. The "old" os-prober returned a colon-separated list of 4 parameters for each system detected. The patched os-prober adds 3 parameters (colon separated): the string "btrfs", UUID=, and subvol=<name> The patched grub2 will pass this new information to (the patched) linux-boot-prober Yes, the "exit 1"s were added when I got tired of seeing messages about "success" and no such thing happened. And, this helped to debug what I was doing.
os-prober-1.57-1.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/os-prober-1.57-1.fc17
os-prober-1.57-1.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/os-prober-1.57-1.fc18
Package os-prober-1.57-1.fc17: * should fix your issue, * was pushed to the Fedora 17 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.57-1.fc17' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-1840/os-prober-1.57-1.fc17 then log in and leave karma (feedback).
Actually, I am not running Fedora 18 and the update works fine. Since os-prober-1.57 is staged fro F17 and F18, I have ping'ed upstream grub2 as well as Fedora to add the little patches to take advantage of updated os-prober.
os-prober-1.57-2.fc17 has been submitted as an update for Fedora 17. https://admin.fedoraproject.org/updates/os-prober-1.57-2.fc17
os-prober-1.57-2.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/os-prober-1.57-2.fc18
Please also see bug #906847, which IMHO should be applied to upstream patch too.
os-prober-1.57-2.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
os-prober-1.57-2.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
I have two btrfs partitions with three subvolumes each (On /dev/sda1 is a Fedora 21 install, on /dev/sda2 is a Fedora rawhide install.): /dev/sda1 with subvolumes @, @home, @scripts /dev/sda2 with subvolumes @, @home, @scripts On /dev/sda1 is the more recent installation, the grub entry only lists entries for that one. Therefore the following outputs are from this system on /dev/sda1. Running os-prober gives me: /dev/sda2:Fedora release 22 (Rawhide):Fedora:linux:btrfs:UUID=9e57818e-9306-42db-b861-868d35c1ab61:subvol=@ which is entirely correct as far as I understand (correct release, correct UUID, correct subvolume) Running grub2-mkconfig gives me: Generating grub configuration file ... # # DO NOT EDIT THIS FILE # # It is automatically generated by grub2-mkconfig using templates # from /etc/grub.d and settings from /etc/default/grub # ### BEGIN /etc/grub.d/00_header ### set pager=1 if [ -s $prefix/grubenv ]; then load_env fi if [ "${next_entry}" ] ; then set default="${next_entry}" set next_entry= save_env next_entry set boot_once=true else set default="${saved_entry}" fi if [ x"${feature_menuentry_id}" = xy ]; then menuentry_id_option="--id" else menuentry_id_option="" fi export menuentry_id_option if [ "${prev_saved_entry}" ]; then set saved_entry="${prev_saved_entry}" save_env saved_entry set prev_saved_entry= save_env prev_saved_entry set boot_once=true fi function savedefault { if [ -z "${boot_once}" ]; then saved_entry="${chosen}" save_env saved_entry fi } function load_video { if [ x$feature_all_video_module = xy ]; then insmod all_video else insmod efi_gop insmod efi_uga insmod ieee1275_fb insmod vbe insmod vga insmod video_bochs insmod video_cirrus fi } terminal_output console if [ x$feature_timeout_style = xy ] ; then set timeout_style=menu set timeout=5 # Fallback normal timeout code in case the timeout_style feature is # unavailable. else set timeout=5 fi ### END /etc/grub.d/00_header ### ### BEGIN /etc/grub.d/10_linux ### Found linux image: /boot/vmlinuz-3.16.3-302.fc21.x86_64 Found initrd image: /boot/initramfs-3.16.3-302.fc21.x86_64.img Warning: Please don't use old title `Fedora, with Linux 3.16.3-302.fc21.x86_64' for GRUB_DEFAULT, use `Advanced options for Fedora>Fedora, with Linux 3.16.3-302.fc21.x86_64' (for versions before 2.00) or `gnulinux-advanced-9280e56d-f6c7-4d45-8550-d97acfdfe9e8>gnulinux-3.16.3-302.fc21.x86_64-advanced-9280e56d-f6c7-4d45-8550-d97acfdfe9e8' (for 2.00 or later) menuentry 'Fedora, with Linux 3.16.3-302.fc21.x86_64' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-3.16.3-302.fc21.x86_64-advanced-9280e56d-f6c7-4d45-8550-d97acfdfe9e8' { load_video set gfxpayload=keep insmod gzio insmod part_msdos insmod btrfs set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 9280e56d-f6c7-4d45-8550-d97acfdfe9e8 else search --no-floppy --fs-uuid --set=root 9280e56d-f6c7-4d45-8550-d97acfdfe9e8 fi linux16 /@/boot/vmlinuz-3.16.3-302.fc21.x86_64 root=UUID=9280e56d-f6c7-4d45-8550-d97acfdfe9e8 ro rootflags=subvol=@ rhgb quiet initrd16 /@/boot/initramfs-3.16.3-302.fc21.x86_64.img } Found linux image: /boot/vmlinuz-0-rescue-9a2019d898654c96ab362a9e919a8ef3 Found initrd image: /boot/initramfs-0-rescue-9a2019d898654c96ab362a9e919a8ef3.img menuentry 'Fedora, with Linux 0-rescue-9a2019d898654c96ab362a9e919a8ef3' --class fedora --class gnu-linux --class gnu --class os --unrestricted $menuentry_id_option 'gnulinux-0-rescue-9a2019d898654c96ab362a9e919a8ef3-advanced-9280e56d-f6c7-4d45-8550-d97acfdfe9e8' { load_video insmod gzio insmod part_msdos insmod btrfs set root='hd0,msdos1' if [ x$feature_platform_search_hint = xy ]; then search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 --hint='hd0,msdos1' 9280e56d-f6c7-4d45-8550-d97acfdfe9e8 else search --no-floppy --fs-uuid --set=root 9280e56d-f6c7-4d45-8550-d97acfdfe9e8 fi linux16 /@/boot/vmlinuz-0-rescue-9a2019d898654c96ab362a9e919a8ef3 root=UUID=9280e56d-f6c7-4d45-8550-d97acfdfe9e8 ro rootflags=subvol=@ rhgb quiet initrd16 /@/boot/initramfs-0-rescue-9a2019d898654c96ab362a9e919a8ef3.img } if [ "x$default" = 'Fedora, with Linux 3.16.3-302.fc21.x86_64' ]; then default='Advanced options for Fedora>Fedora, with Linux 3.16.3-302.fc21.x86_64'; fi; ### END /etc/grub.d/10_linux ### ### BEGIN /etc/grub.d/20_linux_xen ### ### END /etc/grub.d/20_linux_xen ### ### BEGIN /etc/grub.d/20_ppc_terminfo ### ### END /etc/grub.d/20_ppc_terminfo ### ### BEGIN /etc/grub.d/30_os-prober ### Found Fedora release 22 (Rawhide) on /dev/sda2 ### END /etc/grub.d/30_os-prober ### ### BEGIN /etc/grub.d/40_custom ### # This file provides an easy way to add custom menu entries. Simply type the # menu entries you want to add after this comment. Be careful not to change # the 'exec tail' line above. ### END /etc/grub.d/40_custom ### ### BEGIN /etc/grub.d/41_custom ### if [ -f ${config_directory}/custom.cfg ]; then source ${config_directory}/custom.cfg elif [ -z "${config_directory}" -a -f $prefix/custom.cfg ]; then source $prefix/custom.cfg; fi ### END /etc/grub.d/41_custom ### done So it seems grub2-mkconfig does not use the information to generate a boot entry, despite stating "Found Fedora release 22 (Rawhide) on /dev/sda2". I have tested this with both, Fedora branched (21) and Fedora rawhide. The installations were done using kickstart, the partitioning part looked like this: part btrfs.01 --size=5000 --grow --asprimary btrfs none --label=fedora btrfs.01 btrfs / --subvol --name=@ LABEL=fedora btrfs /home --subvol --name=@home LABEL=fedora btrfs /opt/scripts --subvol --name=@scripts LABEL=fedora Can someone help me debug this issue? I would be pleased to provide as much information as needed.
This looks to be a grub2 bug rather than os-prober bug. But maybe Gene can help with this. Anyway, you should probably create a new bug against grub2 for it.
Hedayat, Thanks for your reply, I'll do some additional testing, then open a new bug. I hope in the meanwhile Gene Czarcinski has time to look into that or leave a comment, since I could not find an IRC nick I could ping.
You have been bit by a problem known to me that involves both os-prober and grub2. See RHBZ #1108296 and RHBZ #1108344 With F21 and grub2-2.02, Fedora changes to using "linux16" instead of "linux" and "initrd16" instead of "initrd" regardless of the system type (x86 or x86_64), Well, /etc/grub.d/30_os-prober does not know how to handle that and needs some additional info from os-prober. Neither of my suggested patches have currently been accepted. So, what do you do now? "It hurts ... don't do that" I have pretty much given up on 30_os-prober and os-prober. Instead I use simple menuentry definitions in /etc/grub.d/40_custom From the infomation you provided it appears that your system has the rootfs on subvol=@ with /boot as a simple directory on the rootfs. With grub2-2.02 and F21 this works. However, you are going to be bit in the rear end by grubby! See rhbz #1094489 I have an updated grubby package available at http://czarc.org ... grubby maintainer has the updates "in queue" for processing. Ignoring the grubby update (you can; simply run grub2-mkconfig after every kernel update) or with my updated package installed, you can: 1. Add GRUB_DISABLE_OS_PROBER=true to /etc/defaults/grub 2. On the system on sda1 which appears to be the one where grub2-install was run, add the following to the end of /etc/grub.d/40_custom menuentry "Fedora 22 (rawhide) onj sda2" { configfile (hd0,msdos2)/@/boot/grub2/grub.cfg } I have also submitted a patch to anaconda to implement not updating the MBR but still creaing all of the grub2 configuration files. This is useful for these multiboot situations. Otherwise, last one installed has to have the 40_custom to bootup the other systems. Yes, with this you get two grub2 prompts ... live with it. If you have any questions, email me directly.
linux16/initrd16 is not used on UEFI, where linuxefi/initrdefi are used instead and causes similar confusion where only Fedora kernels get those grub commands, while other Linux kernels get linux/initrd commands which then don't work. See bug 964828.
Gene, Hedayat, there is a significant difference between that last patch by gene here and the one pushed in to fedora. Gene's patch: https://bugzilla.redhat.com/attachment.cgi?id=676324 Pushed patch: http://pkgs.fedoraproject.org/cgit/os-prober.git/plain/os-prober-btrfsfix.patch?h=f17 Now comparing manually, the pushed patch is missing the attached section, what is the rationale for this, especially since gene proposed his patch for upstream inclusion?
Created attachment 1026442 [details] missing diff section in pushed patch
One of the big function the pushed patch is missing is "linux_mount_boot", which is called in the pushed patch "linux_mount_boot $partition $tmpmnt". Sorry for asking on a closed bug, but I am trying to get a clean and up to date diff for other distros.
Okay seems, that function is in that patch: http://pkgs.fedoraproject.org/cgit/os-prober.git/plain/os-prober-bootpart-name-fix.patch?h=f18 So the whole patch is simplified right? So today this patch can be found in the following patchs: os-prober-mounted-partitions-fix.patch os-prober-btrfsfix.patch os-prober-bootpart-name-fix.patch ... or am I missing something? What happened though to the part that fixed handling /boot on a separate logical volume? (Talking about this patch proposed in the debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=os-prober-fix-lvboot-1.01.patch;att=3;msg=10;bug=688336)
To be honest, I don't remember the details right now and I should dig into git history for that, but I feel that our bootpart-name-fix patch eliminates the need for that part.
Okay, thanks, I would appreciate if you could answer me the following questions, so I could update the upstream bug report, maybe upstream cares by now? (Apart from that, a fresh release cylce started) 1.) What patches are involved in fixing this bug? From my research and testing I have found: os-prober-mounted-partitions-fix.patch os-prober-btrfsfix.patch os-prober-bootpart-name-fix.patch 2.) What happened to the part that fixed handling /boot on a separate logical volume? (Talking about this patch proposed in the debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?filename=os-prober-fix-lvboot-1.01.patch;att=3;msg=10;bug=688336) This seems to have been included in Gene's original patch. Is there a reason this is not included in Fedora's os-prober? The patch still applies and works here without problems, though I did not have the opportunity yet to test, what exactly it fixes. For your information: The patch set introduces one bug, not existent in upstream os-prober, first mentioned here: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=688336#35 I can confirm that bug and I can also confirm the given patch works (though I am not working on fedora right now, but another distro.)