Re: BOOTMGR is Missing - Linux Boot Possible

TheScullster wrote:
Hi all

Sorry guys I was given some duff info yesterday!
I now have the PC (Packard Bell) available and on start up the actual error messages are:

Verifying DMI Pool Data ................
BOOTMGR is missing
Press Ctrl-Alt-Del to restart

Has a Win XP logo on front.

So the question is pretty much the same:

Should I be able to access the data from Ubuntu CD boot?

Also, I have used the terminal "force" commands to gain access to a laptop drive previously.
But I know very little about Linux software and possible corruption of data.
Can using these force commands to enable disk access actually cause data corruption?
The PC I'm looking at has valuable family pics on apparently and I certainly don't want to risk rendering the disk unrecoverable.



I'm not familiar with these "force" commands...

If Linux can detect a valid file system, it's going to put
an entry in /etc/fstab so it can be mounted. It will only
mount, if you click in a file manager, on the disk icon.

Linux will check the partition type in the MBR, but it is also
going to do at least a basic check that the metadata is correct
for the file system. If the metadata is bad, the mount step will
fail (presumably read-only, so Linux won't attempt to overwrite

If you successfully mount the partition, and you decide to
drag and drop files, *then* you are taking a chance. Because
now you're modifying the file system. But if all you're doing
is looking, far less damage should result.

Linux lacks any form of CHKDSK, so it can't repair damage as such. One
utility has the ability to set the "dirty" bit, so the next time Windows
is running, Windows can use CHKDSK to repair the file system. But that
isn't the same thing as Linux doing the repairs itself. There is
one commercial Linux utility ($99+) that claims to know how to
repair NTFS. Linux developers know enough to be able to write such
a repair utility, but it hasn't happened yet.

"BOOTMGR is missing" by itself, doesn't portend a total collapse. It could
be triggered by just one missing thing.

By the way, that error implies someone has installed or attempted to
install, Windows 7 or Vista. You may be seeing a WinXP logo on the
computer case, but that doesn't imply there has not been some
creative updating by the owner. Maybe they tried to install the
beta of Windows 7 or something. The word "BOOTMGR" didn't get there
on its own. (If you saw NTLDR, then it might be Win2K or WinXP.)

As a repair person, this is a laundry list you can use.
Sure, people work with less, but this is intended to take
the maximum care, so you can look the computer owner in the
face, and say you did your very best.

1) Determine the size of the hard drive in the computer.

2) Have on hand, at least two empty disks the same size or larger
than the drive you're working on. One disk will hold an "image"
sector by sector, of the sick disk drive. The other spare disk,
is for saving scavenged files, if it comes to that. (If you
cannot repair, you scavenge files from the sick disk, to the
second spare disk.)

3) Make a backup of the sick disk to the first spare. This is an
example of a basic Linux command using disk dump.

dd if=/dev/hda of=/dev/hdb

Obviously, there is more to learn than that, about using "disk dump",
but that is an example of making a sector by sector copy. If
you later break /dev/hda somehow, you can copy hdb back to hda at
some point in the future. Typical performance of that (non-optimal)
example is 13MB/sec. In my example, I'm assuming hdb is the same
size or bigger than hda.

In Linux, you need root to make the copy, so if you were using
a Ubuntu disk, you might do it as

sudo dd if=/dev/hda of=/dev/hdb

To give another example, this is how I back up my WinXP partition,
before doing crazy experiments. This uses a Windows version of dd
and Windows syntax. Using block size and count parameters, speeds
up the transfer by a factor of three. Note that "bs" is a multiple
of 512 bytes. bs*count = raw_size_of_partition. You need to get
the raw size info, then factor the number, to come up with "good"
values for bs and count. I try to keep bs below 512KB in size. Another
nice aspect about using bs and count, is it transfers a precise amount
of info, unlike the other command which just stops when you hit
the end of one of the two disks. You can see, this requires a bit
more work.

dd if=\\?\Device\Harddisk0\Partition2 of=winxp.dd bs=129024 count=604031

If I had to back up my whole 250GB disk, it looks like this. This is Linux.
193536*1292056 = 250GB approx. The Linux "factor" command can help you
factor the reported full size of the disk.

sudo dd if=/dev/hda of=/dev/hdb bs=193536 count=1292056

4) You also have the option, of slaving the disk to another
Windows PC and working on it. That is handy, if you need
CHKDSK, for example. But I would make my disk to disk copy
first, before any CHKDSK runs. *Any* utility that makes
"in-place" changes (changing forever, the one copy you've
got), runs the risk of making things worse. So before
doing anything to the sick disk, you make a copy first.
CHKDSK has been known to ruin a disk. That would typically
happen if the disk was corrupted by a half connected disk cable,
and the disk was chock full of errors. CHKDSK would fix non-existent
things, and have a merry old time for itself. That is known
as "error multiplication", just ruining the disk forever. And
this is why you make a backup, before doing CHKDSK.

If you're careful with their data, you can do as much experimenting
as is necessary to fix it. As long as you have a properly made backup,
there is nothing to worry about. The spare disks you use, should be
known good. If the spare disks show bad SMART data, as shown by
HDTune or a similar utility, then find better disk(s) before
starting your work.

You can keep your backup, after the computer is returned to the owner.
If, after a week, there are no more phone calls, you can delete it
or use Secure Erase or whatever you want. The erasure should be known
to cover all the sectors you used for your backup. If the computer
is damaged in the process of shipping it back to the owner, it
pays to have the backup just in case. If the owner, with a
straight face, can tell you that a backup already exists, then
you can erase the damn thing as soon as you're done. But if
the owner is a careless person, you'll need to hold onto the
backup for a few days.


Now that you've safely made a backup, we can look at some other options.

If your Linux work shows some fully functional partitions,
and you can traverse the file system and see all the
usual files in there, you can consider using a repair disc.

Normally, a responsible owner, would burn the repair disc provided
my Microsoft. When I got my Win 7 laptop, the laptop prompts you
to burn a repair disc. This is not an installer DVD, it is a
boot CD, about 200MB or so perhaps. That disc is sufficient
to get access to an MSDOS command prompt, so you can issue
commands. There are also automated repair options.
The automated repair options work, if when booting the disc, the
disc detects a valid partition. If I boot the Windows 7
repair CD on my WinXP machine, the WinXP partition won't appear
in the menu of things to repair. Yet, if I want, I can instead
use the command prompt in there, and use programs like
"bootsect" to put back a WinXP MBR.

Now, your suspicion is, the owner installed Windows 7 or Vista.
That means, they have the original DVD. That DVD can also be
used as a repair disc.

You used to be able to download the 200MB repair disc from
here, but both the Windows 7 and Vista versions have been
removed. That means, you're going to have to hit up the owner
for some disc. Either the installer DVD, or a repair CD, could be
used to fix the BOOTMGR is missing.


This is an example of a repair. If you've made your copy of the
disk drive, you can give this a shot. Half an hour to back up
the hard drive, and ten minutes fiddling with this.

1) Boot from Windows 7 DVD.
2) First screen chooses language/keyboard etc.
3) “Repair your computer" is the next thing to select.
4) Menu pops up with a list of valid partitions to repair.
Select the correct one.
5) Next is "Recovery Options" "Startup Repair"

Notice there is a command prompt option there, if all else fails.
Then you're in a MSDOS like environment.

6) An automated sequence will try to repair it.
Obviously, if something key has been removed (like
say the 100MB boot partition that is sometimes used),
it's going to fail and tell you so.

Installs come two ways. They can consist of boot_partition + main_partition
or can have just the main_partition. My laptop has the former option.
There is some way to force an install to not use the 100MB boot partition
method, so having it all in C: is also an option you can run into.