http://bugzilla.suse.com/show_bug.cgi?id=845589 Michael Friesenegger changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(mfriesenegger@sus |needinfo?(arvidjaar@gmail.c |e.com) |om) --- Comment #22 from Michael Friesenegger --- (In reply to Andrei Borzenkov from comment #15)

Please run os-prober and attach /var/log/messages (or just everything during os-prober run, but full file is simpler).

I have attached os-prober.out.* which are the screen output of os-prober. I have also attached messages.osprober.* which are the just the os-prober output written to messages. The *.orig files are using the 40grub2 file from factory while the *.fix files are using the patch I provided in Comment #14. There are no significant differences between the *.orig files and the *.fix files when looking at the output created by /usr/bin/os-prober.

Unfortunately patch is not correct and likely works just by side effect.

Here is how I believe grub2-mkconfig and the components of the os-prober package work together for a linux partition: grub2-mkconfig (run this on the command line) | |-- os-prober (called to identify the partitions also identifies if a partition is of type btrfs) | |-- linux-boot-prober (called to probe any linux partition identified by os-prober) | |-- 50mounted-tests (called to cycle through possible linux bootloader types) | |- 40grub |- 40grub2 |- 50lilo |- 90fallback | |-------| | | (grub2-mkconfig writes the grub.cfg based on "result:" entries) I know this flow is not exact. I modified 40grub2 because it does not write a "result:" entry for /dev/sda3 on my system. Please compare the attached messages.grub2.orig and messages.grub2.fix to see that the 40grub2 patch will print the "result:" needed by grub2-mkconfig to write the grub.cfg entries for /dev/sda3.

There are two cases

a) when os-prober checks top level subvolume. This is probably your case and the case I can reproduce. It is easy to fix

My patch does not change /usr/bin/os-prober so I am unclear about this case.

b) when /boot is real subvolume. Here we potentially have to deal with both old grub2 (names relative to implicit default subvolume) and new grub2 (names are full paths from btrfs root including subvolume). I do not think we are going to hit this often so I'd like to fix a) and think what can be done for b), unless you can suggest patch :)

I understand this case. I have not tested this case but am willing if you agree. -- You are receiving this mail because: You are on the CC list for the bug.