John said:
Something is messing up in the translation. When Macrium Reflect
restores my drive C dual-boot drive that has three partitions
(Linux, Windows, and a Linux generated small unformatted 4 GB
partition), the Linux boot loader (or whatever it's called) uses
the first partition (Windows) instead of using the Linux
partition. In other words... Within Linux, drive C shows Windows
files instead of Linux files.
I would think that the Linux boot loader would be able to identify
its own partition. Macrium Reflect does the backup from within
Windows, but I don't see how that should change anything. Maybe
the problem happens during the restore from the Macrium Reflect
boot CD.
When you're in Windows, the Linux partitions aren't mounted.
(A package called EXT2IFS can do it. I have that on my Win2K
install, but only for making a particular older Linux partition visible.)
A backup tool that knows about (unmounted) Linux partitions,
might still be able to back them up. For example, my copy of
Partition Magic, could both make ext2 and recognize ext2, but
it did a poor job on the "make" step.
*******
Parts of GRUB are "invisible", in terms of where they're stored.
GRUB has a number of bootstrapping "stages". Sector 0 (MBR) has
some code. And the next stage might be stored in the
sector 1 thru sector 62 area. To get all of it, a backup utility
has to know about those locations (to save all of GRUB, and restore it).
GRUB also exists in two different versions. GRUB was rewritten
at some point, and distros differ in which GRUB they use.
When you install Linux, it probably installs GRUB in the MBR (440
bytes of code). The boot process later brings up the Linux boot screen,
and from there, you get to select Windows as an OS. So Linux may be what
booted.
If you used WUBI to install Ubuntu, *that* will mess around
with the Windows partition. So you have to distinguish between
having used WUBI as an install method, versus booting the CD
by itself and installing from there. WUBI uses files stored
on the Windows partition, to hold the Ubuntu system. The files
are loopback mounted, to make file systems out of them again.
To start, have a look at your partition setup. And see if
there are Linux partition(s) present. And they're big enough
to hold an install.
If you wanted your Windows back, you could always try a "fixmbr"
from the Windows recovery console. That will remove the first stage of
GRUB, from sector 0.
At this point, it's not clear to me, what problem you want
to solve first. Are you trying to get the system back
the way it was, before Linux came along ? Or are you working
on honing a backup strategy, in the hopes of storing Windows
and Linux content in a relatively independent fashion ?
With regard to Linux "recognizing partitions", it would
start that process by seeing ext2/ext3/ext4 entries in the
partition table. The booting process, on a modern distro,
uses a GUID as a means of identifying a partition. That
scheme allows you to move the disk cabling around, and Linux
will still boot. The older scheme, relied on identifiers such
as /dev/sda1, and if you moved the disk to another SATA port,
the device would become /dev/sdb1 and then it wouldn't boot.
I actually hate the GUID scheme. On the one hand, it's an advancement
in terms of recognizing where stuff is. But since the tools to
support it aren't immediately obvious, if you need to change
a GUID, or fix something up after a restore, it's a PITA.
When I want to get a system booted, and I'm stuck looking at
a black screen, that's not the time to be reading up on what
tools fix GUID problems. With the old scheme, I'd just edit
the stupid entry that says /dev/sda1 to /dev/sdb1, and we'd
be off and running again. Fixing a GUID problem, is more work.
Paul
