Bug 1249112

Created attachment 1058063 [details]
grub2 src.rpm

Created attachment 1058064 [details]
os-prober src.rpm

Created attachment 1058067 [details]
patch for os-prober

Created attachment 1058068 [details]
patch for Grub2

Now it creates menu entries like these.

For UFS partitions:

FreeBSD (10.0-RELEASE) (on /dev/sdb1)
NetBSD amd/6.1.5 (on /dev/sdc1)

For ZFS partitions. Linux core doesn't mount ZFS partitions and Grub2 can't recognize it therefore os-prober creates a menu entry for a disk.

Boot Manager FreeBSD (on /dev/sdd)

And for MS:

Windows 10 (loader) (on /dev/sde1)

I dual-boot Windows and Fedora 22 on a non-UEFI system. I recently upgraded from Windows 7 to Windows 10. Grub continues to boot Windows 10 correctly, but it incorrectly detects it as Windows 7 and names it so in the generated menu file. I replaced the following file:

/usr/libexec/os-probes/mounted/20microsoft

With the one from os-prober 1.68 (copied directly from the source package) and it now detects Windows 10 properly giving it that name.

Related bug?

https://bugzilla.redhat.com/show_bug.cgi?id=1249112

(In reply to Ricardo Garcia from comment #6)
> Related bug?
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1249112

Sorry, I meant this one:

https://bugzilla.redhat.com/show_bug.cgi?id=1267779

Hi!
Thank you for your bug report and patches.

Yes, the Window 10 problem will be solved by updating to 1.68.

About the other changes, you've changed Linux detection considerably. What do you mean by "Now It uses creation time of release files."?

Also, seems that you've added BSD detection. so, the current os-prober doesn't detect BSD OSes at all?

Have you tried to provide these significant changes to upstream os-prober project?

> About the other changes, you've changed Linux detection considerably. What do you mean by "Now It uses creation time of release files."?

I noticed two things.

1) 90linux-distro keeps abandoning distro names. Also a legacy script. Modern distros have to use os-release. To keep the list requires useless efforts. For example nobody uses Meego now.

elif [ -e "$dir/etc/meego-release" ]; then
    short="MeeGo"
    long="$(head -1 "$dir/etc/meego-release")"

2) Creation time of release files. Simple idea. For Fedora It looks like this.

$cd /etc
$ls -lt *release

-rw-r--r--. 1 root root 31 May 19 10:27 fedora-release
lrwxrwxrwx. 1 root root 21 May 19 10:27 os-release -> ../usr/lib/os-release
lrwxrwxrwx. 1 root root 14 May 19 10:27 redhat-release -> fedora-release
lrwxrwxrwx. 1 root root 14 May 19 10:27 system-release -> fedora-release

31 May 19 10:27 fedora-release <- We can ignore soft links. It's Fedora because It's the latest created file.

Usually distro makers don't change creation dates of original release files, if they derive a distro. It can be changed, but usually these files contain the same title.



> Also, seems that you've added BSD detection. so, the current os-prober doesn't detect BSD OSes at all?

Yes. It does not detect them at all.


It was simple with UFS. Linux can mount this filesystem. Grub2 works correctly with this filesystem too.

mount -t ufs -o ro,ufstype=ufs2 /dev/hda8 /mnt/freebsd/


I thought for a long time what to do with ZFS volumes. I'm not sure that It's a good idea to use disk loader.


> Have you tried to provide these significant changes to upstream os-prober project?

Not yet. Some changes have to be made in Grub2. Chainloader doesn't work with GPT. As I remember I'd got messages about bad signatues.

case ${BOOT} in
kfreebsd) loader="kfreebsd /boot/loader";;
knetbsd) loader="knetbsd /netbsd";;
kopenbsd) loader="kopenbsd /bsd";;
*) loader="chainloader +1";;
esac

Mistyping. Bad signatures.

Also, there's is an error at existing 40lsb.
...
release=$(lsb_field "$file" DISTRIB_RELEASE)
if [ -z "$release" ]; then
    release=$(lsb_field "$file" DISTRIB_CODENAME)
fi
description=$(lsb_field "$file" DISTRIB_DESCRIPTION)
if [ -z "$description" ]; then
    description=$(lsb_field "$file" DISTRIB_CODENAME)
fi
... and etc

http://linux.die.net/man/1/lsb_release

Quote: "The required line style is: Distributor release x.x (Codename)"



And now os-prober doesn't support os-release.
http://www.freedesktop.org/software/systemd/man/os-release.html

Mageia as a complicated example.

$cd /etc
$ls -lt *release

-rw-r--r-- 1 root root  37 Jun  5 16:25 mageia-release
lrwxrwxrwx 1 root root  14 Jun  5 16:25 mandrakelinux-release -> mageia-release
lrwxrwxrwx 1 root root  14 Jun  5 16:25 mandrake-release -> mageia-release
lrwxrwxrwx 1 root root  14 Jun  5 16:25 mandriva-release -> mageia-release
lrwxrwxrwx 1 root root  21 Jun  5 16:25 os-release -> ../usr/lib/os-release
lrwxrwxrwx 1 root root  14 Jun  5 16:25 redhat-release -> mageia-release
lrwxrwxrwx 1 root root  14 Jun  5 16:25 release -> mageia-release
-rw-r--r-- 1 root root 111 May 31 17:07 lsb-release

Usually the latest contains the title of a distro. There are only two exceptions. Debian and Ubuntu use os-release. I think it can be omitted.

Script sequence:
1) 35linux-release
2) 40lsb
3) 90linux-distro

$ls *release
lsb-release os-release

$ls *version
debian-version

$cat debian-version
jessie/sid

Supporting os-release is good, but supporting older OSes should remain for awhile. And I think we cannot assume that everybody uses systemd/os-prober (at least, Gentoo seems to be an example). 

I'll try to review the patches, specially the BSD related part soon. However, it would be much better if they are proposed (and hopefully merged) upstream, since such patches make maintaining the package much harder. 
Unfortunately, upstream seems to hardly accept *subtle* patches. But you might be lucky!

Some notes about this report:
1. Windows 10 detection is already fixed
2. Please dedicate this bug to BSD fix with a BSD specific patch, and create a separate bug for linux release detection. Or, at least please provide separate patches for these two in this report so that I can review separately.
3. For Grub2 changes, please open a separate bug against grub2, since it should be handled by grub2 maintainer(s) and I can't do anything about it.

Fedora 22 changed to end-of-life (EOL) status on 2016-07-19. Fedora 22 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I have the problem with this that my os is not working properly so what can I do for this please help me. If anyone facing an error with window 10 and wants to solve them than you can easily take help from this site http://www.msofficetechnicalsupportnumbers.com/blog/playback-devices-in-skype/