Triple boot:XP,ubuntu&FC5 grub failed

[Gayal]

I was using Win XP with FC5 and wanted to install Ubuntu as well.

So i deleted the FC5 partition (just for the fun of doing it) and installed
ubuntu straight from the live cd V6.10.
And my laptop dual booted perfectly with XP.
After that i installed FC5 and during the creation of boot loader i added XP
and Ubutu as well from there respective partitions.

But then triple boot failed.
This is the message i get when selected ubuntu from Fedora Core 5 Grub Menu
-----------------------------------

Booting 'ubuntu'
rootnoverify (hd0,6)
chainloadre +1

Error 13: Invalid or Unsupported executable format.
Press any key to continue

so how can i fix this problem and tripple boot my laptop.

my file systems are as follows:
XP - NTFS
ubuntu - reiserfs
FC5 - Ext3

-- 
Gayal Rupasinghe
SRI LANKA
(SU-APIIT)
User #396462 counter.li.org

[Jim Cornette]

Gayal wrote:
>  I was using Win XP with FC5 and wanted to install Ubuntu as well.
>  
>  So i deleted the FC5 partition (just for the fun of doing it) and 
>  installed ubuntu straight from the live cd V6.10.
>  And my laptop dual booted perfectly with XP.
>  After that i installed FC5 and during the creation of boot loader i 
>  added XP and Ubutu as well from there respective partitions.
>  
>  But then triple boot failed.
>  This is the message i get when selected ubuntu from Fedora Core 5 Grub Menu
>  -----------------------------------
>  
>  Booting 'ubuntu'
>  rootnoverify (hd0,6)
>  chainloadre +1
>  
>  Error 13: Invalid or Unsupported executable format.
>  Press any key to continue
>  
>  so how can i fix this problem and tripple boot my laptop.
>  
>  my file systems are as follows:
>  XP - NTFS
>  ubuntu - reiserfs
>  FC5 - Ext3
>  
>  -- 
>  Gayal Rupasinghe
>  SRI LANKA
>  (SU-APIIT)
>  User #396462 counter.li.org <http://counter.li.org>
>   
In the Ubuntu OS, you need to install its boot loader into the partition 
  that you have the ubuntu boot loader located in.

For example: I had to run grub-install /dev/hdb1 to chainload another 
installation from within the installation that had grub installed in 
that location, I don't know if it is a spelling difference such as 
British compared to US spelling, but chainloader +1 instead of 
chainlodre + 1 might be the problem with the setup.

There was also a problem related to reiserFS with grub in the past. I 
think that this factor should not matter. It might be solved already.

Jim


-- 
Everyone was born right-handed.  Only the greatest overcome it.

[Tod Merley]

On 8/30/06, Jim Cornette <fc-cornette(a)insight.rr.com&gt; wrote:
>  Gayal wrote:
>  > I was using Win XP with FC5 and wanted to install Ubuntu as well.
>  >
>  > So i deleted the FC5 partition (just for the fun of doing it) and
>  > installed ubuntu straight from the live cd V6.10.
>  > And my laptop dual booted perfectly with XP.
>  > After that i installed FC5 and during the creation of boot loader i
>  > added XP and Ubutu as well from there respective partitions.
>  >
>  > But then triple boot failed.
>  > This is the message i get when selected ubuntu from Fedora Core 5 Grub Menu
>  > -----------------------------------
>  >
>  > Booting 'ubuntu'
>  > rootnoverify (hd0,6)
>  > chainloadre +1
>  >
>  > Error 13: Invalid or Unsupported executable format.
>  > Press any key to continue
>  >
>  > so how can i fix this problem and tripple boot my laptop.
>  >
>  > my file systems are as follows:
>  > XP - NTFS
>  > ubuntu - reiserfs
>  > FC5 - Ext3
>  >
>  > --
>  > Gayal Rupasinghe
>  > SRI LANKA
>  > (SU-APIIT)
>  > User #396462 counter.li.org <http://counter.li.org>
>  >
>
>  In the Ubuntu OS, you need to install its boot loader into the partition
>    that you have the ubuntu boot loader located in.
>
>  For example: I had to run grub-install /dev/hdb1 to chainload another
>  installation from within the installation that had grub installed in
>  that location, I don't know if it is a spelling difference such as
>  British compared to US spelling, but chainloader +1 instead of
>  chainlodre + 1 might be the problem with the setup.
>
>  There was also a problem related to reiserFS with grub in the past. I
>  think that this factor should not matter. It might be solved already.
>
>  Jim
>
>
>  --
>  Everyone was born right-handed.  Only the greatest overcome it.
>
>  --
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>  
Hi Gayal Rupasinghe and Jim Cornette!

Gayle, Jim has it pretty much right I think.

The chainload of Ubuntu (sort of a "stop looking here and start fresh
right there!) should see a Fresh MBR (this is were I have a bit of a
question since I can only see an MBR as being generated for the first
sector of the disk) immediately followed (and referenced in the MBR)
by a file within your current /boot/grub called "reiserfs_stage1_5".
In every Ubuntu installation I have looked at stage 1.5 I have found
immediately following the MBR (MBR sector 1, Stage 1.5 sector 2).  I
believe it could be located anywhere as long as you pointed to that
location within the MBR.

The grub boot sequence is Stage 1 - the Master Boot Record - which
points to Stage 1.5 which is sort of a connector enabling the file
system intended ("reiser" in this case) - Stage 2 - GRUB proper.

The stage 1.5 I reference above is a bit less than eighteen 512 byte
sectors long.  I do not know where the partition file tables start.  I
guess I am saying that if it were me I would look a bit further before
I did indeed transfer stage 1.5 to "just after the MBR of the Ubuntu
partition".  I am talking a bit above my knowledge and experience
(although I am suspicious it would work).

Good Hunting!

Tod

[Jim Cornette]

Tod Merley wrote:

>  
>  Hi Gayal Rupasinghe and Jim Cornette!
>  
>  Gayle, Jim has it pretty much right I think.
>  
>  The chainload of Ubuntu (sort of a "stop looking here and start fresh
>  right there!) should see a Fresh MBR (this is were I have a bit of a
>  question since I can only see an MBR as being generated for the first
>  sector of the disk) immediately followed (and referenced in the MBR)
>  by a file within your current /boot/grub called "reiserfs_stage1_5".
>  In every Ubuntu installation I have looked at stage 1.5 I have found
>  immediately following the MBR (MBR sector 1, Stage 1.5 sector 2).  I
>  believe it could be located anywhere as long as you pointed to that
>  location within the MBR.
>  
>  The grub boot sequence is Stage 1 - the Master Boot Record - which
>  points to Stage 1.5 which is sort of a connector enabling the file
>  system intended ("reiser" in this case) - Stage 2 - GRUB proper.
>  
>  The stage 1.5 I reference above is a bit less than eighteen 512 byte
>  sectors long.  I do not know where the partition file tables start.  I
>  guess I am saying that if it were me I would look a bit further before
>  I did indeed transfer stage 1.5 to "just after the MBR of the Ubuntu
>  partition".  I am talking a bit above my knowledge and experience
>  (although I am suspicious it would work).
>  
>  Good Hunting!
>  
>  Tod
>   
Just adding that with the Fedora installer, there is an option for 
advanced bootloader settings during installation of Fedora.
The nice thing about the advanced features is the ability to add new 
information in a graphical interface where you can give a name for the 
alternative OS and select the partition that you want to chainload.

You still need to install the grub into the appropriate area using the 
OS that will be chainloaded. For instance, if Ubuntu has either / or 
/boot on /dev/hdb2, you will need to run grub-install /dev/hdb2 while 
booted into Ubuntu.
Afterwards, Ubuntu should be selectable from the Fedora version of grub, 
which should hand off control to the Ubuntu grub version from there on.

Jim

-- 
The person who's taking you to lunch has no intention of paying.

[Antonio Olivares]

--- Tod Merley <todbot88(a)gmail.com&gt; wrote:

>  On 8/30/06, Jim Cornette
>  <fc-cornette(a)insight.rr.com&gt; wrote:
>  > Gayal wrote:
>  > > I was using Win XP with FC5 and wanted to
>  install Ubuntu as well.
>  > >
>  > > So i deleted the FC5 partition (just for the fun
>  of doing it) and
>  > > installed ubuntu straight from the live cd
>  V6.10.
>  > > And my laptop dual booted perfectly with XP.
>  > > After that i installed FC5 and during the
>  creation of boot loader i
>  > > added XP and Ubutu as well from there respective
>  partitions.
>  > >
>  > > But then triple boot failed.
>  > > This is the message i get when selected ubuntu
>  from Fedora Core 5 Grub Menu
>  > > -----------------------------------
>  > >
>  > > Booting 'ubuntu'
>  > > rootnoverify (hd0,6)
> >  > chainloadre +1 
>  > >
>  > > Error 13: Invalid or Unsupported executable
>  format.
>  > > Press any key to continue
>  > >
>  > > so how can i fix this problem and tripple boot
>  my laptop.
>  > >
>  > > my file systems are as follows:
>  > > XP - NTFS
>  > > ubuntu - reiserfs
>  > > FC5 - Ext3
>  > >
>  > > --
>  > > Gayal Rupasinghe
>  > > SRI LANKA
>  > > (SU-APIIT)
>  > > User #396462 counter.li.org
>  <http://counter.li.org>
>  > >
>  >
>  > In the Ubuntu OS, you need to install its boot
>  loader into the partition
>  >   that you have the ubuntu boot loader located in.
>  >
>  > For example: I had to run grub-install /dev/hdb1
>  to chainload another
>  > installation from within the installation that had
>  grub installed in
>  > that location, I don't know if it is a spelling
>  difference such as
>  > British compared to US spelling, but chainloader
>  +1 instead of
>  > chainlodre + 1 might be the problem with the
>  setup.
>  >
>  > There was also a problem related to reiserFS with
>  grub in the past. I
>  > think that this factor should not matter. It might
>  be solved already.
>  >
>  > Jim
>  >
>  >
>  > --
>  > Everyone was born right-handed.  Only the greatest
>  overcome it.
>  >
>  > --
>  > fedora-list mailing list
>  > fedora-list(a)redhat.com
>  > To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-list
>  >
>  
>  Hi Gayal Rupasinghe and Jim Cornette!
>  
>  Gayle, Jim has it pretty much right I think.
>  
>  The chainload of Ubuntu (sort of a "stop looking
>  here and start fresh
>  right there!) should see a Fresh MBR (this is were I
>  have a bit of a
>  question since I can only see an MBR as being
>  generated for the first
>  sector of the disk) immediately followed (and
>  referenced in the MBR)
>  by a file within your current /boot/grub called
>  "reiserfs_stage1_5".
>  In every Ubuntu installation I have looked at stage
>  1.5 I have found
>  immediately following the MBR (MBR sector 1, Stage
>  1.5 sector 2).  I
>  believe it could be located anywhere as long as you
>  pointed to that
>  location within the MBR.
>  
>  The grub boot sequence is Stage 1 - the Master Boot
>  Record - which
>  points to Stage 1.5 which is sort of a connector
>  enabling the file
>  system intended ("reiser" in this case) - Stage 2 -
>  GRUB proper.
>  
>  The stage 1.5 I reference above is a bit less than
>  eighteen 512 byte
>  sectors long.  I do not know where the partition
>  file tables start.  I
>  guess I am saying that if it were me I would look a
>  bit further before
>  I did indeed transfer stage 1.5 to "just after the
>  MBR of the Ubuntu
>  partition".  I am talking a bit above my knowledge
>  and experience
>  (although I am suspicious it would work).
>  
>  Good Hunting!
>  
>  Tod
>  
>  -- 
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe:
>  https://www.redhat.com/mailman/listinfo/fedora-list
>   
Sorry to ask, but the line 
>  > chainloadre +1 
should'nt it be
chainloader ?

Regards,

Antonio 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

[Mike McCarty]

Tod Merley wrote:
>  Hi Gayal Rupasinghe and Jim Cornette!
>  
>  Gayle, Jim has it pretty much right I think.
>  
>  The chainload of Ubuntu (sort of a "stop looking here and start fresh
>  right there!) should see a Fresh MBR (this is were I have a bit of a
>  question since I can only see an MBR as being generated for the first
>  sector of the disk) immediately followed (and referenced in the MBR)
>  by a file within your current /boot/grub called "reiserfs_stage1_5". 
[snip]

Erm...

There is exactly one (1) MBR per physical fixed disc. Each non-extended
partition has a BR on it (sometimes called the geometry). GRUB
can run either from the MBR or from a BR. Extended partitions are
another story altogether.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Tod Merley]

On 9/6/06, Mike McCarty <Mike.McCarty(a)sbcglobal.net&gt; wrote:
>  Tod Merley wrote:
>  > Hi Gayal Rupasinghe and Jim Cornette!
>  >
>  > Gayle, Jim has it pretty much right I think.
>  >
>  > The chainload of Ubuntu (sort of a "stop looking here and start fresh
>  > right there!) should see a Fresh MBR (this is were I have a bit of a
>  > question since I can only see an MBR as being generated for the first
>  > sector of the disk) immediately followed (and referenced in the MBR)
>  > by a file within your current /boot/grub called "reiserfs_stage1_5".
>
>  [snip]
>
>  Erm...
>
>  There is exactly one (1) MBR per physical fixed disc. Each non-extended
>  partition has a BR on it (sometimes called the geometry). GRUB
>  can run either from the MBR or from a BR. Extended partitions are
>  another story altogether.
>
>  Mike
>  --
>  p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
>  This message made from 100% recycled bits.
>  You have found the bank of Larn.
>  I can explain it for you, but I can't understand it for you.
>  I speak only for myself, and I am unanimous in that!
>
>  --
>  fedora-list mailing list
>  fedora-list(a)redhat.com
>  To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
>  
Hi Mike McCarty!

So when you use a GRUB prompt or grub-install you can form a Boot
Record on any of the four Primary Partitions (the very first one being
the Master Boot Record of course)?

How do you make sure it is formed for the partition and knows were the
proper stage 1.5, stage 2, and grub.conf or menu.lst are?

Thanks!

Tod

[Mike McCarty]

Tod Merley wrote:
>  On 9/6/06, Mike McCarty <Mike.McCarty(a)sbcglobal.net&gt; wrote:
>  
> > Tod Merley wrote:
> > > Hi Gayal Rupasinghe and Jim Cornette!
> > >
> > > Gayle, Jim has it pretty much right I think.
> > >
> > > The chainload of Ubuntu (sort of a "stop looking here and start fresh
> > > right there!) should see a Fresh MBR (this is were I have a bit of a
> > > question since I can only see an MBR as being generated for the first
> > > sector of the disk) immediately followed (and referenced in the MBR)
> > > by a file within your current /boot/grub called "reiserfs_stage1_5".
> >
> > [snip]
> >
> > Erm...
> >
> > There is exactly one (1) MBR per physical fixed disc. Each non-extended
> > partition has a BR on it (sometimes called the geometry). GRUB
> > can run either from the MBR or from a BR. Extended partitions are
> > another story altogether.
> >
> > Mike
> > -- 
> > p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> > This message made from 100% recycled bits.
> > You have found the bank of Larn.
> > I can explain it for you, but I can't understand it for you.
> > I speak only for myself, and I am unanimous in that!
> >
> > -- 
> > fedora-list mailing list
> > fedora-list(a)redhat.com
> > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> >
>  
>  Hi Mike McCarty!
>  
>  So when you use a GRUB prompt or grub-install you can form a Boot
>  Record on any of the four Primary Partitions (the very first one being
>  the Master Boot Record of course)? 
Not quite. A BR is a part of a partition. The MBR is outside of any
partition, and contains the definitions (the Partition Table, or PT)
of the partitions as a part of it.

Using the classic layout, the PT has room for up
to 4 entries, at most one of which may be an extended partition.
Primary Partitions each have a BR which contains, as a part of it,
the BIOS Parameter Block (BPB) or the so-called geometry. An extended
partition may contain logical (as opposed to physical) volumes.
(Do not confuse these terms with the Red Hat "Logical Volumes".)
There is no arbitrary limit on the number of logical volumes may
be contained in an extended partition. Each logical volume has
a BR in it, like a primary partition.

>  How do you make sure it is formed for the partition and knows were
> the
>  proper stage 1.5, stage 2, and grub.conf or menu.lst are? 
During installation, you tell it. Installation into the MBR vs. a BR
really has no difference in procedure. USE of course is different.
If GRUB is not installed into the MBR, then something else must
be used as the boot manager. For example, my machine can boot either
Windows XP or Fedora. I use the Windows XP boot manager to load GRUB
from the BR of my Linux partition.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Jim Cornette]

Tod Merley wrote:
>  On 9/6/06, Mike McCarty <Mike.McCarty(a)sbcglobal.net&gt; wrote:
> > Tod Merley wrote:
> > > Hi Gayal Rupasinghe and Jim Cornette!
> > >
> > > Gayle, Jim has it pretty much right I think.
> > >
> > > The chainload of Ubuntu (sort of a "stop looking here and start fresh
> > > right there!) should see a Fresh MBR (this is were I have a bit of a
> > > question since I can only see an MBR as being generated for the first
> > > sector of the disk) immediately followed (and referenced in the MBR)
> > > by a file within your current /boot/grub called "reiserfs_stage1_5".
> >
> > [snip]
> >
> > Erm...
> >
> > There is exactly one (1) MBR per physical fixed disc. Each non-extended
> > partition has a BR on it (sometimes called the geometry). GRUB
> > can run either from the MBR or from a BR. Extended partitions are
> > another story altogether.
> >
> > Mike
> > -- 
> > p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
> > This message made from 100% recycled bits.
> > You have found the bank of Larn.
> > I can explain it for you, but I can't understand it for you.
> > I speak only for myself, and I am unanimous in that!
> >
> > -- 
> > fedora-list mailing list
> > fedora-list(a)redhat.com
> > To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
> >
>  
>  Hi Mike McCarty!
>  
>  So when you use a GRUB prompt or grub-install you can form a Boot
>  Record on any of the four Primary Partitions (the very first one being
>  the Master Boot Record of course)?
>  
>  How do you make sure it is formed for the partition and knows were the
>  proper stage 1.5, stage 2, and grub.conf or menu.lst are?
>  
>  Thanks!
>  
>  Tod
>   
Lokking through the replies, I did not see mention of what installs the 
basics for the bootloader.

When you run grub-install /dev/hdx# from any of your installations, 
information is installed for grub to finis booting. So when you install 
grub into /dev/hdb2 for example, information for grub and the first 
stage is chainloaded. (given over control to the particular OSes version 
of grub.) From there, it loads the consecutive stages in a similar way 
that installing grub into the MBR does. If grub is not installed into 
the MBR, the partition where you installed grub into must be marked as 
active. BIOS will take it from there to start grub from a partition 
where it is installed, consecutively going through the various stages 
grub goes through in order to load the OS.

Jim

-- 
Never let your sense of morals prevent you from doing what is right.
		-- Salvor Hardin, "Foundation"

[Mike McCarty]

Jim Cornette wrote:
>  
>  Lokking through the replies, I did not see mention of what installs the 
>  basics for the bootloader.
>  
>  When you run grub-install /dev/hdx# from any of your installations, 
>  information is installed for grub to finis booting. So when you install 
>  grub into /dev/hdb2 for example, information for grub and the first 
>  stage is chainloaded. (given over control to the particular OSes version 
>  of grub.) From there, it loads the consecutive stages in a similar way 
>  that installing grub into the MBR does. If grub is not installed into  
You were OK up to here.

>  the MBR, the partition where you installed grub into must be marked
> as 
>  active. BIOS will take it from there to start grub from a partition 
>  where it is installed, consecutively going through the various stages 
>  grub goes through in order to load the OS. 
The BIOS does NOT search the partition table for an active partition.
It is the code in the MBR which does that. All the BIOS looks for
is the first physical sector on the physical volume having the BOOT
RECORD signature (AA55) in the last two bytes. The BIOS accesses the
disc in a physical manner (LBA translation aside). It knows nothing
about partitions. Indeed, there are more than one way of partitioning
discs, and the "traditional" method is not the only one. Anyway, if
the BIOS finds the BR signature in the first physical sector, then it
simply loads it to 0000:7C00 (IIRC) and jumps to it. [NB: The processors
all reset to REAL mode, so this is not a selector address, but a
segmented address.]

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Jim Cornette]

Mike McCarty wrote:

>  The BIOS does NOT search the partition table for an active
> partition.
>  It is the code in the MBR which does that. All the BIOS looks for
>  is the first physical sector on the physical volume having the BOOT
>  RECORD signature (AA55) in the last two bytes. The BIOS accesses the
>  disc in a physical manner (LBA translation aside). It knows nothing
>  about partitions. Indeed, there are more than one way of partitioning
>  discs, and the "traditional" method is not the only one. Anyway, if
>  the BIOS finds the BR signature in the first physical sector, then it
>  simply loads it to 0000:7C00 (IIRC) and jumps to it. [NB: The processors
>  all reset to REAL mode, so this is not a selector address, but a
>  segmented address.]
>  
>  Mike 
So if I want to install grub onto partition 2 of my first drive and have 
no Grub installed into the MBR, the BIOS will not start loading whatever 
is in the first sector of my second partition?
I have not tried to load grub into a partition and then make the 
partition active. I thought that I read that someone else was loading 
grub from a partition.
I changed the active partition for the other OS and the OS which was on 
the active partition booted. When I changed the active partition to the 
other "other" OS, the secondary OS booted. I assumed that grub loaded in 
a similar way as the other OS to Load the Linux OS with the information 
grub puts into the selected partition.

I'm confused a bit on what grub is capable of. I'm curious enough to 
experiment on a computer. I want to try to run two different Linux 
distributions and be able to toggle the active partition in my 
experimenting. (Grub installed in the selected partition, no grub in the 
MBR)

Jim


-- 
Many receive advice, few profit by it.
		-- Publilius Syrus

[Mike McCarty]

Jim Cornette wrote:
>  Mike McCarty wrote:
>  
> > The BIOS does NOT search the partition table for an active partition.
> > It is the code in the MBR which does that. All the BIOS looks for
> > is the first physical sector on the physical volume having the BOOT
> > RECORD signature (AA55) in the last two bytes. The BIOS accesses the
> > disc in a physical manner (LBA translation aside). It knows nothing
> > about partitions. Indeed, there are more than one way of partitioning
> > discs, and the "traditional" method is not the only one. Anyway, if
> > the BIOS finds the BR signature in the first physical sector, then it
> > simply loads it to 0000:7C00 (IIRC) and jumps to it. [NB: The processors
> > all reset to REAL mode, so this is not a selector address, but a
> > segmented address.]
> >
> > Mike
>  
>  
>  So if I want to install grub onto partition 2 of my first drive and have 
>  no Grub installed into the MBR, the BIOS will not start loading whatever 
>  is in the first sector of my second partition? 
I repeat: The BIOS looks at the absolute first sector on the disc,
and if it ends with the BOOT RECORD marker AA55, then it loads it
to location 0000:7C00 and jumps to that location. If it does not
find the marker, then it looks at the next device in the list of
bootable devices. This is true for both floppy disc drives and
for fixed disc drives. What it does for CDROM and FLASH drives I dunno,
not having delved into that.

>  I have not tried to load grub into a partition and then make the 
>  partition active. I thought that I read that someone else was loading 
>  grub from a partition. 
That can be done. It just isn't done by the BIOS. I do it, for example.
My machine has the Windows XP Boot in the MBR. That bootstrap
looks for the XP Boot Manager, which has the capability to load GRUB.
In this case, not from the BR of another partition (although it is
installed there, too, and that's where I got it from) but from a file
in the XP file system. GRUB then loads stage 2, gets its config file
from the Linux partition, and allows me to boot one of several revisions
of FC. I also have some GRUB boot floppies, which are nice to have
for emergency situations. I believe that GRUB can also be installed
on a CDROM, though I have not done that.

>  I changed the active partition for the other OS and the OS which was
> on 
>  the active partition booted. When I changed the active partition to the 
>  other "other" OS, the secondary OS booted. I assumed that grub loaded in 
>  a similar way as the other OS to Load the Linux OS with the information 
>  grub puts into the selected partition. 
GRUB gets loaded by whatever loads it. If it is in the MBR, then the
BIOS loads it. If it is elsewhere, then something else loads it.
The BIOS has no concept of partitions. GRUB is not an OS. It is an OS
loader. My copy of GRUB gets loaded from a file in my Windows XP
partition by the XP Boot Manager.

>  I'm confused a bit on what grub is capable of. I'm curious
> enough to  
It can load any OS which is compatible with the standard promulgated
by GRUB, which is next to none, or possibly even none. It has some
kludgy hooks to allow it to load MSDOS, various versions of Windows,
and Linux, none of which is compliant with the standard it promulgates.

>  experiment on a computer. I want to try to run two different Linux 
>  distributions and be able to toggle the active partition in my 
>  experimenting. (Grub installed in the selected partition, no grub in the 
>  MBR) 
That is possible. It is even possible to chain load GRUB from GRUB.

I hope I'm not being overly terse. I have on occasion posted a
description of the full bootstrap process from start to finish.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Thufir]

On Fri, 08 Sep 2006 00:15:47 -0500, Mike McCarty wrote:
[...]
>  GRUB gets loaded by whatever loads it. If it is in the MBR, then the
>  BIOS loads it. If it is elsewhere, then something else loads it.
>  The BIOS has no concept of partitions. GRUB is not an OS. It is an OS
>  loader. My copy of GRUB gets loaded from a file in my Windows XP
>  partition by the XP Boot Manager. 
[...]

Ah.  If GRUB isn't in the MBR, but, for example, hda1, then what's in the
MBR?


-Thufir

[Mike McCarty]

Thufir wrote:
>  On Fri, 08 Sep 2006 00:15:47 -0500, Mike McCarty wrote:
>  [...]
>  
> >GRUB gets loaded by whatever loads it. If it is in the MBR, then the
> >BIOS loads it. If it is elsewhere, then something else loads it.
> >The BIOS has no concept of partitions. GRUB is not an OS. It is an OS
> >loader. My copy of GRUB gets loaded from a file in my Windows XP
> >partition by the XP Boot Manager.
>  
>  [...]
>  
>  Ah.  If GRUB isn't in the MBR, but, for example, hda1, then what's in the
>  MBR? 
Whatever you put into it. On my machine, it's Microsoft's MBR.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Tod Merley]

On 9/8/06, Mike McCarty <Mike.McCarty(a)sbcglobal.net&gt; wrote:

>  >
>  > Ah.  If GRUB isn't in the MBR, but, for example, hda1, then what's in the
>  > MBR?
>
>  Whatever you put into it. On my machine, it's Microsoft's MBR.
>
>  Mike
>  -- 
Hi again Mike!

I am thinking of recommending this structure to a friend wanting to do
CentOS/XP.  I think it is a good idea since I keep hearing about XP
and associated "security" and machine management SW scanning the MBR
and using a copy (of the original installed XP MBR) if they see a
change.

Does the above sound good?

On the one hand I feel kind of manipulated, on the other hand who
cares as long as it works.  GRUB does offer some "fall back" features
but other than that it appears to add nothing to the mix.

You are appreciated!

Tod

[Mike McCarty]

Tod Merley wrote:
>  On 9/8/06, Mike McCarty <Mike.McCarty(a)sbcglobal.net&gt; wrote:
>  
> > >
> > > Ah.  If GRUB isn't in the MBR, but, for example, hda1, then what's 
> > in the
> > > MBR?
> >
> > Whatever you put into it. On my machine, it's Microsoft's MBR.
> >
> > Mike
> > -- 
>  
>  
>  Hi again Mike!
>  
>  I am thinking of recommending this structure to a friend wanting to do
>  CentOS/XP.  I think it is a good idea since I keep hearing about XP
>  and associated "security" and machine management SW scanning the MBR
>  and using a copy (of the original installed XP MBR) if they see a
>  change. 
I've got a Presario (Compaq/HP) which, if it sees a change, wants
to do "recovery". I fiddled with this and that, and eventually
decided that the best setup for me is to let the MicroSoft
MBR load up the XP Boot Manager, and let the XP Boot Manager
load GRUB from the BR of my Linux Boot Partition. GRUB *cannot*
load XP on my machine, full stop. XP *can* load GRUB on my
machine, full stop.

>  Does the above sound good? 
IMO, it's a matter of what works well for your setup. What
I have works well for my machine. I have no axe to grind
with MicroSoft, or anyone else.

>  On the one hand I feel kind of manipulated, on the other hand who
>  cares as long as it works.  GRUB does offer some "fall back" features
>  but other than that it appears to add nothing to the mix. 
Well, it can load Linux directly (with some kludges) which the
XP Boot Manager cannot. OTOH, the MicroSoft MBR can load my
XP Boot Manager directly, which GRUB cannot.

>  You are appreciated! 
That's nice to hear.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Jim Cornette]

Mike McCarty wrote:
>  Jim Cornette wrote:
> > Mike McCarty wrote:
> >
> >> The BIOS does NOT search the partition table for an active partition.
> >> It is the code in the MBR which does that. All the BIOS looks for
> >> is the first physical sector on the physical volume having the BOOT
> >> RECORD signature (AA55) in the last two bytes. The BIOS accesses the
> >> disc in a physical manner (LBA translation aside). It knows nothing
> >> about partitions. Indeed, there are more than one way of partitioning
> >> discs, and the "traditional" method is not the only one. Anyway, if
> >> the BIOS finds the BR signature in the first physical sector, then it
> >> simply loads it to 0000:7C00 (IIRC) and jumps to it. [NB: The processors
> >> all reset to REAL mode, so this is not a selector address, but a
> >> segmented address.] 
I wiped out a disk that did have win2k on it. I removed all of the 
partitions and set up 4 partitions. The first two were 100 MB partitions 
which I dedicated one for each installation that I was making. I made 
partition 1 active and then created an lvm for the first installation on 
partition 3. Afterwards, I toggled the active flag on partition 1 to off 
and toggled partition 2 to active. I created a separate lvm for the 
second installation on partition 4. (setup a /boot on /dev/hda1 for 
installation 1 and a /boot partition on /dev/hda2 for the second 
installation. For the lvm content, I just made a swap system and a / 
system for each of the two installations. For the seperate lvms for each 
installation, I made different vg and lv names for the swap and / for 
each installation)

Anyway, toggling either partition 1 or partition 2 to active would allow 
the desired installation to boot. The only drawback would be that you 
need to toggle the currently active partition to inactive followed by 
making the new desired partition active.

So you are saying above that the MBR has the default code to search for 
the active partition. The BIOS does not know about active partitions 
without instruction from the MBR. Now if I took a brand new disk with 
nothing on it, partitioned as described above and toggled the active 
partition, it would just come up confused without some OS writing 
information into the MBR?

It works if you wanted to simply toggle active partitions instead of 
chainloading installations. Grub has to be putting some information in 
the partitions for this to work. So you should be able to add entries 
within grub in order to chainload either installation and forget about 
adding grub to the MBR.

By the way, selecting advanced options during installation allows you to 
choose where you want to install grub. Otherwise, it defaults to 
installing grub into the MBR.


> >>
> >> Mike
> >
> >
> > So if I want to install grub onto partition 2 of my first drive and 
> > have no Grub installed into the MBR, the BIOS will not start loading 
> > whatever is in the first sector of my second partition?
>  
>  I repeat: The BIOS looks at the absolute first sector on the disc,
>  and if it ends with the BOOT RECORD marker AA55, then it loads it
>  to location 0000:7C00 and jumps to that location. If it does not
>  find the marker, then it looks at the next device in the list of
>  bootable devices. This is true for both floppy disc drives and
>  for fixed disc drives. What it does for CDROM and FLASH drives I dunno,
>  not having delved into that. 
So the technology is still a little primitive? Sort of like needing to 
access a specific address for the 8086 and MFM drives? (low level 
formatting anyway)

I guess BIOS is less capable than I supposed. No technical research on 
my part. I understand that going to the absolute first sector of the 
disk, grabbing information from the MBR (whatever it may contain) and 
getting information from the MBR as to where to shoot from next if it 
stores active partition information within it would work.

>  
> > I have not tried to load grub into a partition and then make the 
> > partition active. I thought that I read that someone else was loading 
> > grub from a partition.
>  
>  That can be done. It just isn't done by the BIOS.  
OK, I'll buy that.

I do it, for example.
>  My machine has the Windows XP Boot in the MBR. That bootstrap
>  looks for the XP Boot Manager, which has the capability to load GRUB.
>  In this case, not from the BR of another partition (although it is
>  installed there, too, and that's where I got it from) but from a file
>  in the XP file system. GRUB then loads stage 2, gets its config file
>  from the Linux partition, and allows me to boot one of several revisions
>  of FC. I also have some GRUB boot floppies, which are nice to have
>  for emergency situations. I believe that GRUB can also be installed
>  on a CDROM, though I have not done that. 
I experienced messed up windows installations too many times to rely on 
installing a file to load grub via the XP bootloader. I rely on XP 
booting from the grub installed in the MBR. XP is of course on the 
active partition 1 and knows how to boot without the MBR being effected 
as well.

>  
> > I changed the active partition for the other OS and the OS which was 
> > on the active partition booted. When I changed the active partition to 
> > the other "other" OS, the secondary OS booted. I assumed that grub 
> > loaded in a similar way as the other OS to Load the Linux OS with the 
> > information grub puts into the selected partition.
>  
>  GRUB gets loaded by whatever loads it. If it is in the MBR, then the
>  BIOS loads it. If it is elsewhere, then something else loads it.
>  The BIOS has no concept of partitions. GRUB is not an OS. It is an OS
>  loader. 
I knew grub was not an OS itself and simply locates the intended kernel 
to load.

  I want to try to run two different Linux
> > distributions and be able to toggle the active partition in my 
> > experimenting. (Grub installed in the selected partition, no grub in 
> > the MBR)
>  
>  That is possible. It is even possible to chain load GRUB from GRUB.
>  
>  I hope I'm not being overly terse. I have on occasion posted a
>  description of the full bootstrap process from start to finish. 
Thanks for the explanation. The end result is the same. I guess my main 
error was on thinking BIOS did this vs. information within the BR when 
nothing is intentionally installed to the MBR.

Jim


>  
>  Mike 

-- 
No act of kindness, no matter how small, is ever wasted.
		-- Aesop

[Mike McCarty]

Jim Cornette wrote:
>  Mike McCarty wrote:
>  
> > Jim Cornette wrote:
> >
> >> Mike McCarty wrote:
> >>
> >>> The BIOS does NOT search the partition table for an active partition.
> >>> It is the code in the MBR which does that. All the BIOS looks for
> >>> is the first physical sector on the physical volume having the BOOT
> >>> RECORD signature (AA55) in the last two bytes. The BIOS accesses the
> >>> disc in a physical manner (LBA translation aside). It knows nothing
> >>> about partitions. Indeed, there are more than one way of partitioning
> >>> discs, and the "traditional" method is not the only one. Anyway,
> if
> >>> the BIOS finds the BR signature in the first physical sector, then it
> >>> simply loads it to 0000:7C00 (IIRC) and jumps to it. [NB: The 
> >>> processors
> >>> all reset to REAL mode, so this is not a selector address, but a
> >>> segmented address.]
>  
>   
[snip]

>  So you are saying above that the MBR has the default code to search
> for 
>  the active partition. The BIOS does not know about active partitions  
I don't know what is in your MBR, but is has the *only* (not just
default) code to search for "active partitions".

>  without instruction from the MBR. Now if I took a brand new disk with
>  
The BIOS does not receive instructions from the MBR. The MBR contains
a little program which gets loaded by the BIOS. It, like any other
program, does whatever it does once it is loaded into memory. When
it is executing, the BIOS has relinquished control, and no longer
runs the show. It is out of the picture entirely.[*]

>  nothing on it, partitioned as described above and toggled the active
>
>  partition, it would just come up confused without some OS writing 
>  information into the MBR? 
When you get a "blank disc" and "partition it" you use a tool
to write the Partition Table. The PT is *part* of the MBR.
That tool, usually, also writes the code portion of the MBR
with a program which can read and interpret the PT. What gets
put into the MBR depends on what tool you use to create the
initial partitions. This tool also often writes the BRs at the
beginning of the partitions, which contain the BPBs or "geometries"
of the partitions.

>  It works if you wanted to simply toggle active partitions instead of
>
>  chainloading installations. Grub has to be putting some information in 
>  the partitions for this to work. So you should be able to add entries 
>  within grub in order to chainload either installation and forget about 
>  adding grub to the MBR. 
GRUB, when installed into the MBR, *is* the code portion of the MBR.
There must be *some* code in the MBR, otherwise there is nothing
to interpret the PT, and find what is active and what is not.

>  By the way, selecting advanced options during installation allows you
> to 
>  choose where you want to install grub. Otherwise, it defaults to 
>  installing grub into the MBR. 
It really isn't necessary to quote everything which went before.

[*] Well, not *completely* entirely :-) The code in the MBR makes
BIOS service calls to read the disc, and display messages on the
screen, using software interrupt services. But the MBR code is
in the driver's seat, and the BIOS is just a bunch of I/O services
at that point.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!

[Jim Cornette]

Mike McCarty wrote:

>  It really isn't necessary to quote everything which went before.
Saving the basic points.

>  
>  [*] Well, not *completely* entirely :-) The code in the MBR makes
>  BIOS service calls to read the disc, and display messages on the
>  screen, using software interrupt services. But the MBR code is
>  in the driver's seat, and the BIOS is just a bunch of I/O services
>  at that point.  

Thanks Mike for the explanation.
I was more interested if it was possible to boot from the active 
partitions instead of installing grub or another program into the master 
boot record specifically.
It works, so I am happy that it is possible. I'll read up on the role of 
BIOS, the MBR to make the specifics more clear to me.

Jim

>  
>  Mike 

-- 
   Gentlemen, I want you to know that I am not always right, but I am
   never wrong. -Samuel Goldwyn

[Mikko Silvennoinen]

Hi !

I had sometimes help from installing Smart Boot Manager, it is OS 
independent and
can replace original code at MBR. Remember to use the backup feature 
first, to be able to
restore old MBR if necessary.
It is a command line utility, that I found from Linux Format Magazine's 
cover CDs.
It does not replace the need of Grub or Lilo, but let's you choose from 
which harddrive's MBR or
from which partition that has Grub or Lilo or XP you want to boot from.
It can scan for existing MBRs and partitions.

Mikko Silvennoinen

Jim Cornette wrote:

>  Mike McCarty wrote:
>
> > It really isn't necessary to quote everything which went before.
>
>
>  Saving the basic points.
>
> >
> > [*] Well, not *completely* entirely :-) The code in the MBR makes
> > BIOS service calls to read the disc, and display messages on the
> > screen, using software interrupt services. But the MBR code is
> > in the driver's seat, and the BIOS is just a bunch of I/O services
> > at that point. 
>
>
>
>  Thanks Mike for the explanation.
>  I was more interested if it was possible to boot from the active 
>  partitions instead of installing grub or another program into the 
>  master boot record specifically.
>  It works, so I am happy that it is possible. I'll read up on the role 
>  of BIOS, the MBR to make the specifics more clear to me.
>
>  Jim
>
> >
> > Mike
>
>
>

[Mike McCarty]

Mikko Silvennoinen wrote:
>  Hi !
>  
>  I had sometimes help from installing Smart Boot Manager, it is OS 
>  independent and 
I've used it as well. It also allows one to boot from devices
which the BIOS cannot recognize as bootable, as well. I have used
it to boot CDROMs on a machine which does not know how to boot from
CDROMs.

>  can replace original code at MBR. Remember to use the backup feature
>
>  first, to be able to
>  restore old MBR if necessary. 
And be sure to put the copied MBR on a medium which is bootable
and contains the tools necessary to restore it, should the install
not work. I use an MSDOS bootable floppy with a little program
to put the MBR back.

>  It is a command line utility, that I found from Linux Format
> Magazine's 
>  cover CDs. 
Current versions have a pseudo-graphical user interface.

>  It does not replace the need of Grub or Lilo, but let's you
> choose from 
>  which harddrive's MBR or
>  from which partition that has Grub or Lilo or XP you want to boot from.
>  It can scan for existing MBRs and partitions. 
With some reservations, I agree with your assessment. It would not
work on the machine I am currently using, however, and for the
same reason GRUB does not work in the MBR. So it is not a solution
to the type of problem GRUB has on my machine.

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!