All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gene Czarcinski <gczarcinski@gmail.com>
To: grub-devel@gnu.org
Subject: How should 30_os-prober be working?
Date: Fri, 13 Jun 2014 09:46:31 -0400	[thread overview]
Message-ID: <539B00B7.9090208@gmail.com> (raw)

This deals with 30_os-prober and the os-prober package itself.

In days of old, it was linux and initrd for linux systems (ignoring 
linuxefi and initrdefi).  Fedora 21 is in the process of starting up and 
it brings in grub2-2.02-0.3 and os-prober-1.58-7.  While these updates 
bring in improved support for /boot on btrfs subvols and LVMlvs, they 
also introduce using linux16 instead of linux and initrd16 instead of 
initrd.

This last change breaks 30_os-prober so that no output is produced even 
when appropriate systems are identified.  The problem is that os-prober 
was only recognizing linux/initrd and the grub.cfg had 
linux/16/initrd16.  I have created an update for os-prober which now 
identifies the "type" of linux | linux16 (actually linux*) and initrd | 
initrd16 (actually initrd*) and linux-boot-prober now returns whatever 
linux* and initrd* matches to 30_os-prober.

The question is: what should 30_os-prober do with this information? 
Currently, I simply use the "linux_type" and initrd_type" returned by 
linux-boot-prober (40grub2) as "operation" to be performed?  Is this 
correct?

Another approach would be to force the use of linux16 and initrd16 for 
the menuentry elements.

BTW, since I have your attention, with GRUB_DISABLE_SUBMENU=true 
specified in /etc/default/grub, should 30_os-prober be generating submenus?

Gene


             reply	other threads:[~2014-06-13 13:46 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-13 13:46 Gene Czarcinski [this message]
2014-06-13 14:37 ` How should 30_os-prober be working? Vladimir 'phcoder' Serbinenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539B00B7.9090208@gmail.com \
    --to=gczarcinski@gmail.com \
    --cc=grub-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.