Linux Windows dual boot not restoring properly

  • Thread starter Thread starter John Doe
  • Start date Start date
J

John Doe

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.
 
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.
Click to expand...

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
 
Paul said:
John Doe wrote:

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 ?
Click to expand...

I'm trying to devise a method to dual-boot and back it up. With
both Linux and Windows on the same hard drive. Nothing should be
stored on the secondary drive that has anything to do with the
startup of either.

To do the install...

.... do a clean install of Windows or restore a backup copy of
windows, to the primary drive (nothing else is on that drive)

.... disconnect the secondary drive (assuming it be there) so that
the forthcoming Linux installation doesn't use it

.... install Linux to the primary drive (shrinking the Windows
partition to make room for the Linux partition, there is plenty of
room for both)

.... after the linux install, reconnect the secondary drive

At this point everything works fine. Dual booting between Linux
and Windows is a breeze. As I recall, I was able to see the Linux
installation folders in drive C. I'm sure that's correct, but I
will double check on the next attempt.

So I made a copy of the primary drive C dual-boot setup from
within Windows using Macrium Reflect. Later, that copy was
restored. At that point... I can boot into Windows just fine. But
when booting to Linux, the file manager shows Windows folders
instead of Linux folders. Apparently the Linux boot loader no
longer knows where the Linux partition is.

So I have to find a better way to back up the primary drive dual
boot configuration/setup, and of course (as needed) restore the
primary drive so that it's exactly the way it is when it was
backed up.

I suppose Drive Image is a possibility. And maybe the Windows PE
stuff. It shall be done.

I might also try making a backup copy of the primary drive from a
rescue CD instead of from within Windows.

Thanks.
 
On second thought... I just redid the dual-boot installation.
Again, Linux is showing the Windows folders in its file manager
under the name of what effectively was drive C. It was the only
partition on drive C. I guess, when the Linux installation
decreases that Windows partition size in order to make a partition
for Linux, it figures that what formerly was effectively the drive
name (since there was only one partition on the drive) should
apply only to the original partition.

Anyway. I probably don't need access to drive C Windows files, but
as long as everything is working, it don't matter. I was spooked
because I've seen similar happen before, in other situations.

In other words... Apparently there is no problem. Maybe the Linux
installer thinks that a user needs easy access to the Windows
partition. That might make sense, at least for those who use the
Windows Documents folder.
 
On second thought... I just redid the dual-boot installation. Again,
Linux is showing the Windows folders in its file manager under the name
of what effectively was drive C. It was the only partition on drive C.
Click to expand...

Linux is capable of reading and writing Windows-formatted partitions.
The reverse is not true, however.
 
In case not clear...

Using Macrium Reflect to back up a dual-boot Linux and Windows drive
works fine. You can even backup and restore parts of the whole.

And (at least when reinstalling Linux) I think you can install right
over the prior Linux partition. Meaning that you don't have to
reinstall Windows or even copy Windows from a known good backup
before doing the Linux reinstallation.

Very flexible.
 
Back
Top