registry team mailing list archive

[CurtisNelson <586175@xxxxxxxxxxxxxxxxxx>]

I have this problem as well.  I'm installing using a slightly different
situation -- I'm restoring a WinXP/Win2k3 backup that was made with
fsarchiver -- but essentially I run across the same issue namely that
boot fails when mbr tries to boot the first partition.  In my case I use
install-mbr from the mbr package but have also tried to install the
windows mbr from the boot cd without success.  Here are the steps I've
taken and the partial fix I've discovered.

First, let me say that these steps worked perfectly in 9.10.  In fact, I
can move the raw image from 9.10 to 10.04 and boot it without problem.
That was initially how I got these restores to work; I installed on a
Karmic laptop and moved the raw image to Lucid.

Install Notes:

Install Procedure (for karmic or lucid):

1. boot system to image to rescuecd and backup xp or win2k3 using fsarchiver:
 fsarchiver savefs /some/remote/location/win.fsa /dev/sda1
2. on kvm host create restore disk:
 lvcreate -L10GB -n win vg
3. boot virt with rescuecd
 kvm -m 1024 -cdrom rescuecd.iso -hda /dev/vg/win -boot d
3. partition disk (entire disk, one partition, active):
 fdisk /dev/sda
 commands: o n p 1 [] [] t 7 a 1 w
4. restore archive:
 fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1
5. install mbr:
 install-mbr /dev/sda
6. halt virt and reboot to image:
 kvm -m 1024 -hda /dev/vg/win

At this point, the image will boot in 9.10. But following the same steps
in lucid it will hang after the mbr boots the first partition.

I tried everything I could think of and all the different steps found on
the web including repairing the mbr changing disk types and boot options
to no avail.  What was odd for me is that the resulting image created on
karmic would boot on lucid which indicated to me that once the install
was completed successfully whatever kvm was doing didn't matter -- it
was just the creation of the mbr or file system in the kvm boot that was
at fault.

My next step at this point was to install hexedit and compare the two
resulting images.  Specifically, the mbr at the beginning of the disk
and the ntfs partition starting at sector 63.  On the net there is some
talk about changing 0x7E1A to 'FF' -- which is supposed to indicate disk
geometry of the ntfs partition.  There were three values that were
different at this point in the ntfs file region -- 0x8E18, 0x7E1A, and
0x7E1C.  The first two did not seem to have any effect.  But changing
0x7E1C to the value of '3F' would result in the image booting properly.
Evidently this is the part of the NTFS file system that records the
starting sector of the partition.  This change successfully booted all
my test cases restores with a single partition.

OK, so at this point I backtracked and did just steps 1-4 on both Karmic
and Lucid but instead of booting to a rescuecd in the virt I used kpartx
to mount the raw file system:

1. make backup
 fsarchiver savefs win.fsa /dev/sda1
2. create disk
 lvcreate -L10GB -n win vg
3. partition
  fdisk /dev/vg/win
4. mount to loop, restore, detach
 kpartx -av /dev/vg/win
 fsarchiver restfs win.fsa id=0,dest=/dev/mapper/vg-winp1
 kpartx -dv /dev/loop0
5. install mbr
 install-mbr /dev/vg/win

At this point, unfortunately, these steps will not boot on either karmic
or lucid -- the boot section of the ntfs partition does not seem to
write correctly (0x8E18, 0x7E1A, and 0x7E1C are all '00').  However, if
you change 0x7E1C to '3F', these resulting images will boot fine:

6. after hexedit, boot, success
 kvm -m 1024 -hda /dev/vg/win

Hope this helps track down this issue.  My feeling here is that this is
not an issue with the mbr but rather the creation of the ntfs file
system.  And it does seem that the disk geometry presented by the
version of kvm in lucid is different enough from karmic to cause the
ntfs file system incorrectly write sector 0x7E1C thus causing the
resulting image to hang at boot.

-- 
Windows XP/2003 doesn't boot
https://bugs.launchpad.net/bugs/586175
You received this bug notification because you are a member of Registry
Administrators, which is the registrant for Debian.