grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Some ideas about new features of grub


From: Robert Millan
Subject: Re: Some ideas about new features of grub
Date: Sat, 11 Jul 2009 20:27:08 +0200
User-agent: Mutt/1.5.18 (2008-05-17)

On Sat, Jul 11, 2009 at 02:53:13PM +0800, Bean wrote:
> On Sat, Jul 11, 2009 at 5:27 AM, BandiPat<address@hidden> wrote:
> > Actually Zenwalk provides os-prober as well.  The gentleman that provides
> > the installer of our Grub2 uses os-prober to detect all OS's installed, so
> > they may be added to the original grub.cfg.  Works very well, although not
> > perfect, but we are pretty pleased with the results thus far.
> >
> > We also do not have to run any of the Grub2 programs after installing new
> > kernels.  The developer of our installer patched Grub2 for Zenwalk, so that
> > no changes were necessary after kernel updates.  He tried to offer this to
> > you guys as well earlier, but got little response, so we use it for Zenwalk
> > exclusively at the moment.
> 
> Hi,
> 
> IIRC, os-prober is a collection of shell script to detect os, but grub
> already have them in util/grub.d.

They have a different purpose.  The other grub.d scripts are targeted at
generating the _native_ boot setup.  os-prober is meant for the rest.

Our own scripts for native boot setup are more robust than the os-prober
approach.  For example, they can determine if Linux will support UUIDs
by checking for /dev/by-uuid nodes, etc.

> Another problem is the drive number. It's impossible to decide bios
> drive number from inside linux, so we can't insert the correct
> drivemap command required to boot DOS/Windows from secondary drive.
> This information must be gathered at boot time.

This is not a problem anymore.  grub-mkconfig uses UUIDs in its default
setup, and avoids hardcoding BIOS drive numbers.  In the very weird
situations in which this is not possible, it aborts install rather than
hardcoding a drive number.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]