Working on making a dual boot again, WinXP & Ubuntu

[Timothy Daniels]

Read the info in the URL I posted above - very informative

The only URL posted "above" in this thread leads to an
inaccessible .gif file. Did you post it under another name?

*TimDaniels*

 

[Timothy Daniels]

Read the info in the URL I posted above - very informative

If you're referring to the gnu.org site that you posted
further along in the thread, that *does* look informative.
Thanks for that one.

*TimDaniels*

 

[iforone]

If you're referring to the gnu.org site that you posted
further along in the thread, that *does* look informative.
Thanks for that one.

*TimDaniels*

Yes - that's the one (GNU.org) that I'm talking about ;-)
....no prob, your welcome.

 

[iforone]

A Further Synopsis...

It's all at that URL - but here's another with some info;
http://en.wikipedia.org/wiki/GNU_GRUB

** GRUB boot process **


The BIOS finds a bootable device (hard disk) and moves control to the
master boot record (MBR, the first 512 bytes of the hard disk).

The MBR/MPT does /not/ have to have an Active/Boot flag set for GRUB
(Linux)-- but AFAICT
windoze WILL overwrite it as soon as you try to boot from it. I have
disabled the Boot flag from hda1(win98 Primary) and rebooted into it,
and what do you know - it's back - set as "Boot" when I check it with
cfdisk after rebooting to linux. With Linux, the boot flag could be
active or not - it doesn't matter AFAICT.

The MBR contains GRUB stage 1. Given the small size of the MBR, Stage 1
does little more than load the next stage of GRUB (which may reside
physically elsewhere on the disk). Stage 1 can either load stage 1.5,
or it can load Stage 2 directly.

Stage 1;

0000170: 00be 937d e82a 00eb fe47 5255 4220 0047 ...}.*...GRUB .G
0000180: 656f 6d00 4861 7264 2044 6973 6b00 5265 eom.Hard Disk.Re
0000190: 6164 0020 4572 726f 7200 bb01 00b4 0ecd ad. Error.......

GRUB Stage 1.5 is located in the first 30 kilobytes of hard disk
immediately following the MBR. Stage 1.5 loads Stage 2.

Stage 1.5;

00002f0: e83f 00eb 06be 1e21 e837 00be 2321 e831 .?.....!.7..#!.1
0000300: 00eb fe4c 6f61 6469 6e67 2073 7461 6765 ...Loading stage
0000310: 312e 3500 2e00 0d0a 0047 656f 6d00 5265 1.5......Geom.Re
0000320: 6164 0020 4572 726f 7200 bb01 00b4 0ecd ad. Error.......
0000330: 1046 8a04 3c00 75f2 c300 0000 0000 0000 .F..<.u.........

GRUB Stage 2 (loaded by Stage 1 or 1.5) receives control, and displays
to the user the GRUB boot menu.

Stage 2;

0000400: ea70 2200 0000 0302 ffff ff00 0000 0000 .p".............
0000410: 0200 302e 3935 00ff ff06 ff2f 626f 6f74 ..0.95...../boot
0000420: 2f67 7275 622f 7374 6167 6532 202f 626f /grub/stage2 /bo
0000430: 6f74 2f67 7275 622f 6d65 6e75 2e6c 7374 ot/grub/menu.lst
0000440: 0000 0000 0000 0000 0000 0000 0000 0000 ................
.....

0001fc0: 0a0a 4752 5542 206c 6f61 6469 6e67 2c20 ..GRUB loading,
0001fd0: 706c 6561 7365 2077 6169 742e 2e2e 0a00 please wait.....
0001fe0: 696e 7465 726e 616c 2065 7272 6f72 3a20 internal error:
0001ff0: 7468 6520 7365 636f 6e64 2073 6563 746f the second secto
0002000: 7220 6f66 2053 7461 6765 2032 2069 7320 r of Stage 2 is
0002010: 756e 6b6e 6f77 6e2e 0000 0000 0000 0000 unknown.........

 

[Timothy Daniels]

"chrisv" responded:

ntldr is right where it normally is, on C:\. The Windows install
on my machine is completely usual. The ONLY differences
are that I've copied the Linux boot-sector (it's just a 512-byte
file, no need for it to "understand" NTFS) onto C:, and I've
edited boot.ini to give the option of passing control to that
Linux boot-sector ("Grub stage one" as iforone more
accurately describes it).


"Normal", yes, but edited.


If I choose Windows, ntldr loads Windows. If I choose Linux,
ntldr passes control to Grub stage one (those 512 bytes in
a file on C, which then passes control to "the real" Grub,
which is residing on an ext3 partition along with the rest of
GNU/Linux. Grub can then load and boot Linux, or pass
control back to ntldr.

For that edited boot.ini file (with its entries
"default=c:\bootsect.lnx" and "c:\bootsect.lnx="Linux")
to be understood, it must be read by software other
than ntldr since that is not part of the normal boot.ini
syntax. Could that software be grub?

What is an "ext3" partition? Is it a kind of Extended
partition? If so, why was an Extended partition chosen
over a Primary partition?

*TimDaniels*

 

[Timothy Daniels]

Caution! The MBR that "looks for the "active" partition" is
already an MS MBR. Others may do something else as, e.g.,
the Grub MBR does.

So grub/Linux has has its own type of MBR?

*TimDaniels*

 

[Arno Wagner]

OK, what is the boot process up to the point that
grub is started, beginning with the selection of the MBR
by the BIOS?

Grub is in the MBR. The BIOS loads the MBR and then has the CPU
ececute the code in it.

Arno

 

[Arno Wagner]

"chrisv" responded:

For that edited boot.ini file (with its entries
"default=c:\bootsect.lnx" and "c:\bootsect.lnx="Linux")
to be understood, it must be read by software other
than ntldr since that is not part of the normal boot.ini
syntax. Could that software be grub?

No. It is loaded by the NT loader and it does understand
the boot.ini syntax above. Grub comes later. Actually Grub is
in bootsect.lnx in this configuration.

What is an "ext3" partition? Is it a kind of Extended
partition? If so, why was an Extended partition chosen
over a Primary partition?

ext3 is just a Linux filesystem. As NTFS or FAT32 is a Windows
filesystem.

Arno

 

[Arno Wagner]

So grub/Linux has has its own type of MBR?

It has its own executable code in the MBR. Apart from that the MBR
is the standard DOS type, listing the disk geometry and the 4
primary pattitions, so I would say it is the standard MBR with
boot-code by Grub and not Microdift. A matter of interpretation ;-)

Arno

 

[Arno Wagner]

A Further Synopsis...

The MBR/MPT does /not/ have to have an Active/Boot flag set for GRUB
(Linux)--

Correct. And the BIOS also does not care. It will execute the MBR
boot code. If that code needs an active flag and does not find one,
it will just return and the BIOS will try the next MBR it finds
(on another disk) AFAIK.

but AFAICT
windoze WILL overwrite it as soon as you try to boot from it. I have
disabled the Boot flag from hda1(win98 Primary) and rebooted into it,
and what do you know - it's back - set as "Boot" when I check it with
cfdisk after rebooting to linux.

I think it is the other way round: Windows will not boot if its
boot partition is not set active. Therefore the ususl Grub configuration
will set it active before booting with the chainloader. Example
from my Grub menue file:

title Trash-OS /dev/hda1
root (hd0,1) <== The Partition that is c:\ under Windows
makeactive <== Set active flag
chainloader +1 <== boot from partition

With Linux, the boot flag could be active or not - it doesn't matter
AFAICT.

The kernel does not care. It gets told on the kernel command line
which partition contains the root filesystem ("/", "aquivalent to
"c:\" an Windows). Alternatively the root partition specification
can be hard-coded into the kernel binary.

Example from my Grub menue file:

title Linux 2.6.15.4 /dev/md1
kernel (hd0,0)/2_6_15_4 root=/dev/md1

This loads the file named "2_6_16_4" from the first disk,
first partition, as kernel and tells it to use /dev/md1 as its
root partition. The thing is that Grub is filesystem aware and
can load regular files.

Arno

 

[Timothy Daniels]

"Arno Wagner" replied:

No. It is loaded by the NT loader and it does understand
the boot.ini syntax above. Grub comes later. Actually Grub is
in bootsect.lnx in this configuration.

Well, that "c:\bootsect.lnx" is understood by ntldr makes
sense because "x:\" in a pathname is only understood
(AFAIK) by Windows/DOS. But that implies that grub
need not be part of the MBR or of the "active" partition's
boot sector since those are encountered prior to ntldr
getting control. And it sounds that up to the point of ntldr
getting control, the MS-supplied MBR and boot sector
can be used in the boot process for both Windows and
Linux, and that the Linux-specific code (i.e. grub) can be
handed control by ntldr according to the user's selection
of entries from boot.ini . If that is true - that ntldr can be
told to hand off control to grub - it can also be told to hand
off control to any Linux OS in the system as long as its
startup file can be designated by boot.ini . In other words,
Windows' multi-boot manager, ntldr can do multi-booting
of Windows OSes as well as Linux OSes, and grub is not
even needed if you have Microsoft's MBR and boot sector
(which I suspect are generic PC items) and Microsoft's
boot files.

*TimDaniels*

 

[Timothy Daniels]

It has its own executable code in the MBR. Apart
from that the MBR is the standard DOS type, listing
the disk geometry and the 4 primary pattitions, so
I would say it is the standard MBR with boot-code
by Grub and not Microdift. A matter of interpretation ;-)

Why would there need to be grub-specific code in
the MBR? All that the MBR has to do is to read the
partition table and find the "active" partition and pass
control to the boot sector there. Previous postings in
this thread claim that ntldr then gets control, just as it
would for Microsoft booting, so there must not be
anything in the MBR or the boot sector that *has* to be
Linux-specific. It sounds as if the Linux-specificity can
be put off until ntldr hands control to grub/lilo or
whatever loads Linux.

*TimDaniels*

 

[iforone]

I think it is the other way round: Windows will not boot if its
boot partition is not set active. Therefore the ususl Grub configuration
will set it active before booting with the chainloader. Example
from my Grub menue file:

title Trash-OS /dev/hda1
root (hd0,1) <== The Partition that is c:\ under Windows
makeactive <== Set active flag
chainloader +1 <== boot from partition

I'm reaching a bit - and my brain is starting to hurt - but I have
those exact same entries in GRUB for win98 (except mine's --> root
(hd0,0)) -- I guess it's because of my GRUB 'chainloader +1' entry for
windoze that causes that small bit of grub code in the MBR to seek out
it's 1.5 and 2.0 stages - which then passes control to the DOS IO.sys
file in 98 (located at hda1, offset by 63 heads(?), which also contains
an 'active' flag -- I guess in essence, an Extended boot record or
EBR)....BTW - this can get very complicated once you start looking at
the Assembly language, offsets, and jump code -- note; FAT32 uses a
larger BPB than FAT16, and NTFS uses some 'reserved' bytes (4-6 bytes)
between the 440bytes of the MBR code and the 64bytes of the MPTs.

Has anyone been looking into the way the newer EFI (Extensible Firmware
Interface) interacts, since it will shortly replace our typical BIOSes

The kernel does not care. It gets told on the kernel command line
which partition contains the root filesystem ("/", "aquivalent to
"c:\" an Windows). Alternatively the root partition specification
can be hard-coded into the kernel binary.

and also even a mini kernel image;

title Debian GNU/Linux, kernel 2.6.8-2-386 (recovery mode)
root (hd0,6)
kernel /boot/vmlinuz-2.6.8-2-386 root=/dev/hda7 ro single
initrd /boot/initrd.img-2.6.8-2-386
savedefault
boot

I don't yet fully understand all the possibilities yet, but here's some
man initrd info
-------------------------------------------------------------------------------------
The special file /dev/initrd is a read-only block device. Device
/dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot
loader before the kernel is started. The kernel then can use the the
block device /dev/initrd's contents for a two phased system boot-up.

In the first boot-up phase, the kernel starts up and mounts an initial
root file-system from the contents of /dev/initrd (e.g. RAM disk
initialized by the boot loader). In the second phase, additional
drivers or other modules are loaded from the initial root device's
contents. After loading the additional modules, a new root file system
(i.e. the normal root file system) is mounted from a different device.
-----------------------------------------------------------------------------------------

Example from my Grub menue file:

title Linux 2.6.15.4 /dev/md1
kernel (hd0,0)/2_6_15_4 root=/dev/md1

This loads the file named "2_6_16_4" from the first disk,
first partition, as kernel and tells it to use /dev/md1 as its
root partition.

The thing is that Grub is filesystem aware and
can load regular files.

Arno

I haven't yet looked into the standard Legacy GRUB vs GRUB 2.0
differences yet.....I only mention to avoid confusion - and to clarify
just what we are discussing (note; That's why I'm sure to mention the
98 vs NT diffs too).

 

[chrisv]

"Arno Wagner" replied:


Well, that "c:\bootsect.lnx" is understood by ntldr makes sense
because "x:\" in a pathname is only understood (AFAIK) by
Windows/DOS. But that implies that grub need not be part of the MBR
or of the "active" partition's boot sector since those are
encountered prior to ntldr getting control.

Right. It's not.

And it sounds that up to the point of ntldr getting control, the
MS-supplied MBR and boot sector can be used in the boot process for
both Windows and Linux, and that the Linux-specific code (i.e. grub)
can be handed control by ntldr according to the user's selection of
entries from boot.ini . If that is true - that ntldr can be told
to hand off control to grub - it can also be told to hand off
control to any Linux OS in the system as long as its startup file
can be designated by boot.ini . In other words, Windows' multi-boot
manager, ntldr can do multi-booting of Windows OSes as well as Linux
OSes,

Yes, but see below.

and grub is not
even needed if you have Microsoft's MBR and boot sector (which I
suspect are generic PC items) and Microsoft's boot files.

You still need Grub or lilo "eventually", as ntldr will not load and boot
Linux directly. This is called chain-loading and is discussed in the Grub
manual that iforone provided a link to.

Likewise, if you choose to have "Grub stage one" in the MBR so that Grub
comes up first, you still need ntldr, which Grub will pass control to if
you want to boot Windows.

 

[Arno Wagner]

I'm reaching a bit - and my brain is starting to hurt - but I have
those exact same entries in GRUB for win98 (except mine's --> root
(hd0,0)) -- I guess it's because of my GRUB 'chainloader +1' entry for
windoze that causes that small bit of grub code in the MBR to seek out
it's 1.5 and 2.0 stages - which then passes control to the DOS IO.sys
file in 98 (located at hda1, offset by 63 heads(?), which also contains
an 'active' flag -- I guess in essence, an Extended boot record or
EBR)....BTW - this can get very complicated once you start looking at
the Assembly language, offsets, and jump code -- note; FAT32 uses a
larger BPB than FAT16, and NTFS uses some 'reserved' bytes (4-6 bytes)
between the 440bytes of the MBR code and the 64bytes of the MPTs.

It is not that complicated. My XP installation is just not on the
first partition. I have a small ext2 (Linux Filsystem) partition
before it, were I keep my kernels. Windows ignores that partition
and uses the second primary partion as c:\, so in my case the
chainloader starts the bootsector of the second partition of
the fist disk. In your case it starts the bootsector of the first
partition of the first disk. Here is an extract from my partition
table:

oot /home/wagner>fdisk -l

Disk /dev/hda: 160.0 GB, 160041885696 bytes
255 heads, 63 sectors/track, 19457 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hda1 1 10 80324+ 83 Linux <== hd0,0
/dev/hda2 * 11 764 6056505 b W95 FAT32 <== hd0,1
.... ^^^ active flag

Has anyone been looking into the way the newer EFI (Extensible Firmware
Interface) interacts, since it will shortly replace our typical BIOSes

Well, some Linux guys managed recently to boot Linux on an INtel
MAC that uses EFI (I think). So there is hope.

and also even a mini kernel image;

title Debian GNU/Linux, kernel 2.6.8-2-386 (recovery mode)
root (hd0,6)
kernel /boot/vmlinuz-2.6.8-2-386 root=/dev/hda7 ro single
initrd /boot/initrd.img-2.6.8-2-386
savedefault
boot

That would be a root image, i.e. a small ramdisk image the kernel
uses as root partition. I find this feature still pretty impressive.

[...]

I haven't yet looked into the standard Legacy GRUB vs GRUB 2.0
differences yet.....I only mention to avoid confusion - and to clarify
just what we are discussing (note; That's why I'm sure to mention the
98 vs NT diffs too).

I think Grub 2.0 is still not finished yet.

Arno

 

[Arno Wagner]

"Arno Wagner" replied:

Well, that "c:\bootsect.lnx" is understood by ntldr makes
sense because "x:\" in a pathname is only understood
(AFAIK) by Windows/DOS. But that implies that grub
need not be part of the MBR or of the "active" partition's
boot sector since those are encountered prior to ntldr
getting control. And it sounds that up to the point of ntldr
getting control, the MS-supplied MBR and boot sector
can be used in the boot process for both Windows and
Linux, and that the Linux-specific code (i.e. grub) can be
handed control by ntldr according to the user's selection
of entries from boot.ini .

Essentially correct.

If that is true - that ntldr can be
told to hand off control to grub - it can also be told to hand
off control to any Linux OS in the system as long as its
startup file can be designated by boot.ini .

No, I think that does not work, because the ntldr can only
"chainload" a bootsector. And while Linux is great, the kernel
will not fit into 512 bytes for some time to come ;-)=)

So you need to have another boot manager or OS loader between
ntldr and the Linux kernel for it to work.

In other words,
Windows' multi-boot manager, ntldr can do multi-booting
of Windows OSes as well as Linux OSes, and grub is not
even needed if you have Microsoft's MBR and boot sector
(which I suspect are generic PC items) and Microsoft's
boot files.

Unfortunately untrue. ntldr cannot boot windows, only
another boot-manager. But you can simulate the effect by telling
the other bootmanager (e.g. Grub), to not ask the user any questions
and boot Linux directly

Arno

 

[Arno Wagner]

Why would there need to be grub-specific code in
the MBR?

Since the boot-manager code (or its first stage) is allways
in the MBR.

All that the MBR has to do is to read the
partition table and find the "active" partition and pass
control to the boot sector there.

That is what the Microsoft boot-manager/loader does.
Others do things differently, since the "active flag"
semantics is rather limited.

Previous postings in
this thread claim that ntldr then gets control, just as it
would for Microsoft booting, so there must not be
anything in the MBR or the boot sector that *has* to be
Linux-specific.

ntldr is sort of the third stage of the MS bootmanager.
The first stage is in the MBR. The second is the bootsector
of the active partition. It is possible to start the
MS booting process from the second stage onwards, which is
exactly what Grub does during chainloading.

It sounds as if the Linux-specificity can
be put off until ntldr hands control to grub/lilo or
whatever loads Linux.

That is one option. And it is possible the other way round as
well.

Arno

 

[chrisv]

Unfortunately untrue. ntldr cannot boot windows, only
another boot-manager.

Of course, you meant to say "ntldr cannot boot Linux"

 

[Arno Wagner]

Arno Wagner wrote:

Of course, you meant to say "ntldr cannot boot Linux"

Ooops, yes. Something Feudian at work I guess ;-)

Arno

 

[Timothy Daniels]

I tell ntldr to use the Linux boot-sector that I've copied to my C:
partition. It then passes control to Grub, which has been installed
on my / Linux partition. Only the C: partition is active.

Which partition at this point does ntldr consider to be "C:"?
Is it the partition that ntldr is in, i.e. the "active" partition on the
drive? Or can ntldr be instructed to pass control to a Linux
boot sector on another partition?

*TimDaniels*