Bug 995777

Summary: os-prober fails to detect other Linux systems (again!)
Product: [Fedora] Fedora Reporter: D. Hugh Redelmeier <hugh>
Component: os-proberAssignee: Hedayat Vatankhah <hedayatv>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: hedayatv
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-23 09:15:37 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
log corresponding the experiments outlined in #2 none

Description D. Hugh Redelmeier 2013-08-11 01:31:14 UTC 
Description of problem:
When I use grub2-mkconfig to build a new grub configuration, it skips the Ubuntu partition


Version-Release number of selected component (if applicable):
os-prober-1.58-3.fc19.x86_64


How reproducible:
Always for me

Steps to Reproduce:
1. prepare your system with an F19 and Ubuntu installation
2. run grub2-mkconfig on Fedora

Actual results:
No mention of the Ubuntu partition in the new config file

Expected results:
The config file should have a menu entry to boot Ubuntu.

Additional info:
This bug is known to upstream (debian), and there is a fix.
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685159>

Ubuntu also has this bug <https://bugs.launchpad.net/ubuntu/+source/os-prober/+bug/1038093>

Almost the same symptom, with different causes, appears in other BZ entries, but they are not the same.  Here are a couple:
  
<https://bugzilla.redhat.com/show_bug.cgi?id=882568>
(In that report, I mentioned the Ubuntu report I referred to above!).

<https://bugzilla.redhat.com/show_bug.cgi?id=948024>

Workaround:
If you mount the other Linux partitions, os-prober finds them!

  mount -o ro /dev/sda8 /mnt
  grub2-mkconfig -o tempfile
  umount /dev/sda8


(Incidental problem with workaround: I don't want to have my Ubuntu partition labelled by Fedora's SELinux.  So I tried 
  mount -o 'ro,context="system_u:object_r:removable_t"' /dev/sda8 /mnt
but that fails.  dmesg says that the failure is because the filesystem needs recovery:
[13554.197659] EXT4-fs (sda8): INFO: recovery required on readonly filesystem
[13554.197669] EXT4-fs (sda8): write access unavailable, cannot proceed
but fsck says it is fine and if I drop the context= part of the mount, it proceeds.  Puzzling to me. I don't understand context= so I copied this from mount(1))
Comment 1 Hedayat Vatankhah 2013-08-11 08:05:02 UTC 
The bug is certainly NOT the debian bug, which is already fixed in os-prober 1.57.

Please provide the os-prober output in syslog when Ubuntu partition is NOT‌ mounted.
Comment 2 D. Hugh Redelmeier 2013-08-13 04:38:32 UTC 
Hedayat:

Sorry for jumping to a conclusion.  I looked at the debian report and saw that the detect-lib-in-usr.patch in message 15 hadn't been applied to the Fedora 19 code.  I guess that wasn't the fix actually adopted by debian (and thus Fedora).

In any case, the misbehaviour is real, on my system.  But a bit mysterious to reproduce.

As explained above, mounting the ubuntu partition allowed os-prober to see it.  But then it would continue seeing it after I unmounted.

So I tried some more experiments to follow up on your query.  I added a new partition and installed a fresh Ubuntu 13.04 to reproduce the initial conditions.  And then ran os-prober.  Wow: it didn't see either Ubuntu partition.  So I'm not clear what's going on.

Here's what os-prober says about the two partitions it doesn't like (from /var/log/messages):
Aug 12 16:17:07 redcherry-mimosa-com hugh: os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sda8
Aug 12 16:17:07 redcherry-mimosa-com kernel: [21007.009653] EXT4-fs (sda8): INFO: recovery required on readonly filesystem
Aug 12 16:17:07 redcherry-mimosa-com kernel: [21007.009663] EXT4-fs (sda8): write access unavailable, cannot proceed
Aug 12 16:17:07 redcherry-mimosa-com hugh: os-prober: debug: running /usr/libexec/os-probes/50mounted-tests on /dev/sda9
Aug 12 16:17:07 redcherry-mimosa-com kernel: [21007.094037] EXT4-fs (sda9): INFO: recovery required on readonly filesystem
Aug 12 16:17:07 redcherry-mimosa-com kernel: [21007.094047] EXT4-fs (sda9): write access unavailable, cannot proceed

Why does Fedora think these cleanly-unmounted-by-Ubuntu partitions need recovery?  That seems to be the crux of the matter.

My best guess why the first Ubuntu again stopped being recognized is that, since the previous (working) os-probe, I had actually booted that Ubuntu.

As far as I could tell, neither Ubuntu partition got SELinux labelling applied.  So this isn't a reappearance of https://bugzilla.redhat.com/show_bug.cgi?id=882568
Comment 3 D. Hugh Redelmeier 2013-08-13 04:41:53 UTC 
Created attachment 785964 [details]
log corresponding the experiments outlined in #2

includes slightly tricky way of grabbing entries added to /var/log/messages
Comment 4 D. Hugh Redelmeier 2013-10-23 05:18:20 UTC 
I've just had this happen again:


- booted; with fedora's grub2 selected ubuntu 13.04

- in ubuntu 13.04: applied updates, "restarted" as required

- in fedora's grub2, new ubuntu kernel is not yet available, so booted to Fedora19

- did a grub2-mkconfig but no ubuntu options appeared in the resulting config file.

- did an fsck from F19 on Ubuntu root partition.  A few errors were fixed.

- grub2-mkconfig NOW creates fine config file

Hypothesis: Ubuntu doesn't always do a clean shutdown.  So: this isn't a Fedora bug.
Comment 5 Hedayat Vatankhah 2013-11-23 09:15:37 UTC 
I agree. The problem is that some kind of recovery is required for partitions. it seems that the recovery CAN be done automatically on mount IF mounted read-write. But, os-prober mounts partitions read-only (it is logical), and so mount cannot proceed. IMHO, mounting partitions read-write is a bad approach, so I'll mark this bug as NOTABUG.

Thanks for your help in detecting the cause of the problem.