[Top][All Lists]

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

Re: Two GRUB setup can boot one each of two installs, but not theother,

From: Michael Evans
Subject: Re: Two GRUB setup can boot one each of two installs, but not theother, why?
Date: Fri, 18 Dec 2009 17:53:09 -0800

On Fri, Dec 18, 2009 at 1:10 PM,  <address@hidden> wrote:
> -----Original message-----
> From: Michael Evans address@hidden
> Date: Fri, 18 Dec 2009 14:53:20 -0500
> To: Yavuz Onder address@hidden
> Subject: Re: Two GRUB setup can boot one each of two installs, but not 
> theother, why?
>> On Thu, Dec 17, 2009 at 3:49 PM, Yavuz Onder <address@hidden> wrote:
>> > Michael Evans wrote:
>> >>
>> >> On Thu, Dec 17, 2009 at 5:27 AM,  <address@hidden> wrote:
>> >>
>> >>>
>> >>> Hi,
>> >>>
>> >>> I have a very strange GRUB problem, that got me totally stumped.
>> >>> [my info removed for brevity]
>> >>
>> >> Your problem is most likely caused by an over-helpful BIOS which is
>> >> re-mapping physical devices so that whichever device is selected as
>> >> the 'boot' device is setup as the 0th BIOS drive.
>> >>
>> >> In this case for one of the two grub installs you must refer to the
>> >> drive your Linux installs are on by some other name; very likely by
>> >> using a custom file to specify that (hd1) is actually
>> >> /dev/whatever.
>> >>
>> >> Thus one drive would be installed as normal.
>> >> The other drive would be setup (manual grub install) with a device-map
>> >> file.
>> >>
>> >> Since the device-map file would re-define the hard drives the actual
>> >> grub.conf file can be the same for both installs.
>> >>
>> >>
>> >
>> > Thanks, but I am not using any disk drive spec at all, but only UUIDs.
>> >
>> > I am pretty much forced to work with UUIDs as I frequently add extra disks
>> > and (hdn,m) format always poses a moving target.
>> >
>> > Can you suggest a work around with UUIDs left in picture? Where is that
>> > "device-map file"? Will removing it help?
>> >
>> > I can get rid of one of the MBRs happily if the remaining one would work.
>> Your KERNELs are using UUIDs.  In order to _load_ grub and the
>> kernel/initrd grub needs to know what _BIOS_ drive to use.  It may be
>> worth noting that given your setup (linux on the secondary drive)
>> probably the one with the BIOS drives out of your desired order is the
>> only one that boots for you.  In that case you'd also need to use the
>> file to specify the proper order of the drives before
>> switching to it.
> O.K. I think I am seeing why my scheme is not working. I thought that, in a 
> given stanza "uuid" command line is a full replacement for "root (hdm,n)" 
> line. Apparently it is not. It is like "uuid command works, as long as it is 
> the uuid of the partition where this menu.lst resides. If not we'll just 
> ignore it and default it to
> the partition where this menu.lst resides".
> I expected (dreamed?) that GRUB would visit all disk partition and make an 
> index of diskId vs UUID. This way it would have known where to find 
> kernel/initrd of the stanza. That would make "uuid" command useful. This is 
> what I expected to be in place, but what I now realize is not part of GRUB 
> legacy. Is it part of GRUB2?
> I think the only option left to me, is chainloading two grubs into each 
> other, hoping that it will work, cross fingers.
> I conclude that GRUB cannot handle well systems with multiple disk drives 
> where user adds removes disks often. As the (hdm,n) spec of a given disk may 
> (likely will) change. Is GRUB2 better in this respect? Or is it also 
> dependent on BIOS disk numbering?
> Thanks for enlightening me.

Still incorrect:

Grub 0.9* (ala grub legacy) does not use uuid AT ALL.    Grub 0.9*
operates entirely with BIOS commands.  Literally hd(N,x) where N is a
bios drive, and x addresses a partition.  Very often it determines the
block-location of a resource it wants at (grub shell setup) install
time, and directly gets those blocks from the bios-device in question.

Grub 1.9* (ala grub2) doesn't mention uuid anywhere in the online documentation.

It seems that in both cases, UUID is __ONLY__ used AFTER your kernel
and initramfs/initrd are loaded.

It _MAY_ be that grub2 supports UUID in the configuration file and is
smart enough to map that back to a device, but if your device ordering
is not going to be the same later then you will likely still have the
requirement to somehow (I have not yet needed to do that with grub2,
so do not know) manually specify what the devices will be when

reply via email to

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