66 replies to this topic

[Wonko the Sane]

Under Linux you use the same dd command that you used to create it's backup inverting IF (InFile) with OF (OutFile).

You ran:

dd if=/dev/hda of=my_mbr.bin count=1 bs=512

to restore the mooded MBR run:

dd if=my_mbrhda_mod1.bin of=/dev/hda count=1 bs=512

Or you can use a disk editor, cannot say right now which one is on Debian, to either restore the "mod" MBR or change on theactual MBR the byte at offset 0x1C3 from FE to EF (254 to 239).

To get 51,200 bytes or 100 sectors:

dd if=/dev/hda of=my_first100.bin count=100 bs=512

Wonko

[apemax]

I restored the mbr you gave me and grub still doesn't load the menu.lst and windows still doesn't boot.

here is the first 100 sectors.

[Sha0]

Sure , but how easy is to install the Recovery Console if you cannot boot?

Am I missing something, Wonko the Sane? Which of the methods you gave do not require you to be booted? Did you not say much the same thing here? If you're not prepared already with an RC environment and have just borked your computer, then come to these forums looking for help, you're going to have to boot something to produce your RC environment, aren't you?

As mentioned here, you can produce the PXE-booted RC on any computer with XP/2003 installed.

For the RAM disk method, you can build the environment on any computer with XP/2003 installed. Using WinVBlock, you avoid license complications caused from using the RAMDISK.SYS from Windows Server 2003, not that there's been a lot of sentiment for respect of that end-user license agreement in these forums.

It might help to give a sample case, then some assumptions are fleshed out:

• User has two computers with, let's say, Windows XP
• Computer A gets borked
• User uses computer B to visit these forums, in search of help
• Find excellent tutorials for how to create a Recovery Console environment
• Prepare the RC environment on computer B
• Boot the RC environment on computer A
• Perform repairs

[Wonko the Sane]

If you're not prepared already with an RC environment and have just borked your computer, then come to these forums looking for help, you're going to have to boot something to produce your RC environment, aren't you?

Yep , the point I was trying to make was exclusively that not necessarily one has:

• another computer with XP/2003 installed (the "other" instructions can be "ported" to any other OS)
• an updated to same Service Pack source to install the RC from (I've never tested it, but I presume that you cannot install an RC with a lower SP than the one running )
• is willing to install the RC anywhere

And that definitely not many people will have a Server properly configured to serve a RC via PXE, TFTP or SMB.

In other words, both your tutorials, which are very, very nice should have the option to start from "source" (CD or downloadable floppies from MS) as an alternative to starting from an installed RC.


As mentioned here, you can produce the PXE-booted RC on any computer with XP/2003 installed.

Using WinVBlock, you avoid license complications caused from using the RAMDISK.SYS from Windows Server 2003,

Yep, the Winvblock option is very good , if anyone cares about licensing issues

not that there's been a lot of sentiment for respect of that end-user license agreement in these forums.

something that as you have noticed, is not "mainstream" here.

@apemax
I'll have a look at the "new sectors".
Can you describe how was the hard disk partitioned before resizing the "XP" partition?
Was it just a huge single NTFS partition?



Wonko

P.S.: My bad, I sent you a WRONG MBR with value 240 instead of the expected 239, please try again with the attached.

Attached Files

•  my_mbrhda_mod2.zip   607bytes   301 downloads

[Sha0]

An XP/2003 RC install is no different than a file copy (and a BOOT.INI entry), as nearly as I can tell, so I see little difference between copying files from floppy, download, or optical disc media or simply installing it. Maybe someone using Vista or 7 would not wish to install an XP RC? For completeness, a sample directory listing has been added to this post. Thanks for the discussion.

[Wonko the Sane]

An XP/2003 RC install is no different than a file copy (and a BOOT.INI entry), as nearly as I can tell, so I see little difference between copying files from floppy, download, or optical disc media or simply installing it. Maybe someone using Vista or 7 would not wish to install an XP RC? For completeness, a sample directory listing has been added to this post. Thanks for the discussion.

Nice try , BUT:

01/22/2008  19:58			 8,192 BOOTSECT.DAT

01/22/2008  19:58			40,647 migrate.inf

Wonko

[Sha0]

Those aren't used by the tutorials! How about the batch file found here? There's an alternative to actually installing the Recovery Console. It should be portable to other operating systems (as in, re-worked for them).

[apemax]

@apemax
I'll have a look at the "new sectors".
Can you describe how was the hard disk partitioned before resizing the "XP" partition?
Was it just a huge single NTFS partition?

there was the NTFS partition that was about 25GB big and a IBM predesktop area that i think debian did something to because it won't go to the predesktop area.

P.S.: My bad, I sent you a WRONG MBR with value 240 instead of the expected 239, please try again with the attached.

I restored the mbr you gave me and grub still doesn't load the menu.lst and windows still doesn't boot.

still the same as ^^. i ran chkdsk for D: and the same message came up.

the volume appears to contain one or more unrecoverable problems.

[Wonko the Sane]

Hmm.

We can try, instead of changing the MBR setting, to try with the bootsector one.

I.e. change in it the geometry from 240 to 255.

Try restoring your original MBR and then restore the attached Bootsector (BE CAREFUL this is a bootsector is target is /hda1, NOT /hda).

If this doesn't work, try restoring both your original MBR and bootsector and try running TESTDISK.

It should already be available on debian, otherwise, get Parted magic:
http://partedmagic.com/

(you can run it from cd or add it to the USB stick with grub4dos)

This is a "beginner's guide to it's use:
http://www.cgsecurit...sk_Step_By_Step


@Sha0



Wonko

Attached Files

•  my_mbr_actuallyBS_mod1.zip   610bytes   287 downloads

[apemax]

I tried restoring the bootsector but windows still doesn't boot and chkdsk comes up with the same error massage.

i ran testdisk and went to analyze and heres the results:

TestDisk 6.11.3, Data Recovery Utility, May 2009Christophe GRENIER <grenier@cgsecurity.org>[url="http://www.cgsecurity.org"]http://www.cgsecurity.org[/url]Disk /dev/hda - 30 GB / 27 GiB - CHS 62016 15 63Current partition structure:     Partition                  Start        End    Size in sectorsWarning: Incorrect number of heads/cylinder 240 (NTFS) != 15 (HD)                1 * HPFS - NTFS              0   1  1 41343  14 63   39070017 [IBM_PRELOAD]Warning: Bad ending head (CHS and LBA don&#39;t match) 2 P Linux                41344   0  1 61335  14 63   18892440Warning: Bad starting head (CHS and LBA don&#39;t match) 3 E extended             61336   0  1 62015  14 63     642600Warning: Bad starting head (CHS and LBA don&#39;t match) 5 L Linux Swap           61336   1  1 62015  14 63     642537    Next*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted[Quick Search]  [ Backup ]                            Try to locate partition

[Wonko the Sane]

Now I am really perplexed.

• There is evidence from the MBR that the partition has been created with a 255 head geometry.
• grub4dos also "understands" the hard disk as having a geometry of 255 heads.
• There is evidence from the bootsector that the filesystem has been created with a 240 head geometry.
• TESTDISK "senses" a 15 head geometry.

Whilst both the 255 and 240 has some sense (first one being the common "default", the second being the "normal" for Lenovo Notebooks) the 15 is a "very unusual" kind of geometry.

http://www.cgsecurit...i/Menu_Geometry

Try going to the Geometry section of TESTDISK and try forcing the 240 heads, then re-analize disk.
You should then be able to access the files on the NTFS partition.


Wonko

[Sha0]

From QEmu's man page:

-hdachs c,h,s,[,t]
Force hard disk 0 physical geometry (1 <= c <= 16383, 1 <= h <= 16,
1 <= s <= 63) and optionally force the BIOS translation mode
(t=none, lba or auto). Usually QEMU can guess all those parameters.
This option is useful for old MS-DOS disk images.

Oftentimes when I use QEmu to work with HDDs, I have to be very conscious of the fact that any partitioning and filesystem formatting that I do is likely to have geometry parameters unlike what I'd get with physical hardware. Also, a physical disk given to a QEmu VM can have FS geometry params which would not be valid since they don't meet QEmu's constraints. This can cause pain.

[apemax]

You should then be able to access the files on the NTFS partition.

i have managed to mount the ntfs partition before using:

mount /dev/hda1 /mnt/windows -t ntfs-3g -o force

but it won't mount normally.

[Wonko the Sane]

No, I meant through TESTDISK, in order to analyze and hopefully fix it.

As said, though I see it possible that somehow the program you used to resize the partition left some original values (like the 240) in the filesystrem and used a non-standard (on your particular hardware) geometry (the 255), the "15" is strange.

I don't know HOW Lenovo's make the (otherwise normally 255) geometry of the disk behave or be "sensed" as 240, but there have been several reports of this particular geometry Lenovo's use, and that is confirmed by the value in your bootsector.

On the other hand, it seems like the Linux install uses the 255 one.

Maybe this peculiar geometry is somehow caused by the original Lenovo's MBR (which has been now overwritten by the legacy GRUB code)?


Wonko

[apemax]

Try going to the Geometry section of TESTDISK and try forcing the 240 heads, then re-analize disk.
You should then be able to access the files on the NTFS partition.

I did that and windows still won't mount normally and still won't boot.

I re-analysed the disk and here's what it says now:

TestDisk 6.11.3, Data Recovery Utility, May 2009Christophe GRENIER <grenier@cgsecurity.org>[url="http://www.cgsecurity.org"]http://www.cgsecurity.org[/url]Disk /dev/hda - 30 GB / 27 GiB - CHS 3876 240 63Current partition structure:     Partition                  Start        End    Size in sectors 1 * HPFS - NTFS              0   1  1  2583 239 63   39070017 [IBM_PRELOAD]Warning: Bad ending head (CHS and LBA don&#39;t match) 2 P Linux                 2584   0  1  3833 119 63   18892440Warning: Bad starting head (CHS and LBA don&#39;t match) 3 E extended              3833 120  1  3875 239 63     642600Warning: Bad starting head (CHS and LBA don&#39;t match) 5 L Linux Swap            3833 121  1  3875 239 63     642537Warning: Bad starting head (CHS and LBA don&#39;t match)*=Primary bootable  P=Primary  L=Logical  E=Extended  D=Deleted[Quick Search]  [ Backup ]                            Try to locate partition

[Wonko the Sane]

No, I meant from within TESTDISK.
So you wrote the "forced" geometry of 240 to the MBR?
And have you tried then to re-run CHKDSK?
And it gave you the same error as before?

If yes, I guess we are stuck.

The right thing to do at this point would be to image the drive.

Once it is done, we can try playing with the image, trying to recover the MFT, etc., but I wouldn't risk doing anything else to the "real" thing.

It is well possible that manual recovery can be performed but it's not something you can do alone, not even if somewhat guided by me or any other member from a distance.

Do you have valuable data on that NTFS partition?

If not re-formatting/re-installing seems like the right thing to do.

Still I have not an idea of the actual cause of this problem, nor a definite opinion about the "right" geometry that HD should have.

It is clear that the original partition had a 240 head geometry and that the Linux somehow created 255 head geometry partition, but something else in the NTFS filesystem must have been changed incorrectly if CHKDSK is failing to work on it.

Even most commercial utilities are oriented to the recovery of files, as opposed to the repair of the filesystem, so, unless someone has an idea on how/what happened manual repair is the only option left - and is not guaranteed it will work.



Wonko

[Sha0]

If you are having problems with CHKDSK under Windows, geometry should not come into play. I believe that Windows uses LBA and clusters, and does not care about geometry. As far as I know, geometry is only an issue for BIOS INT 13h disk access, such as at boot-time. For example, try changing the ending C/H/S for some partition to 2/2/2 and see if you can still CHKDSK. You can.

[apemax]

So you wrote the "forced" geometry of 240 to the MBR?
And have you tried then to re-run CHKDSK?
And it gave you the same error as before?

ok what i did was i went to the geometry section, then selected the heads option, then i set it to 240 and pressed enter, then i went to analyse again and the code section in my previous post is what came up. does just pressing enter on ok write it to the mbr or is there something else i need to do? i ran chkdsk after doing that and the same error came up.

I'm no expert but the mbr is just used for booting right? and then the OS takes over controlling the computer. so would it not be a problem with the actual OS files?

[Wonko the Sane]

@Sha0
This is a "special" case.
Lenovo's do use a disk geometry of 240 Heads.
A Partition and filesystem created normally has this geometry.
The Linux utility that was used *somehow* decided to interpret the geometry as 255, and it RESIZED the existing NT partition with this geometry.
It is possible that the filesystem was written incorrectly in the process. (this has very little to do with actually booting)

@apemax
No, if you just pressed OK you temporarily set the way TESTDISK accesses the image with the forced geometry.
Nothing is changed in the MBR or bootsector, so no surprise that nothing changed when you tried again once out of TESTDISK.

There is an explicit option to write the changes, cannot remember right now where/which it is but is documented on TESTDISK help pages.

The idea was (maybe still is) to see if changing the geometry TESTDISK could analyse and repair some parts of the filesystem that create the problem with checkdsk, this involves writing the 240 based geometry, see what TESTDISK has to say in the Advanced section (you have to read the help for it), then try again running checkdsk.


Wonko

[Sha0]

A Partition and filesystem created normally has this geometry.

Why don't we check out the filesystem, in that case? Perhaps apemax could share the 512 bytes at sector 63? According to Microsoft's DiskProbe.exe by R. Eugene Baucom, we can look at some geometry parameters in the NTFS boot record.

[Wonko the Sane]

Why don't we check out the filesystem, in that case? Perhaps apemax could share the 512 bytes at sector 63? According to Microsoft's DiskProbe.exe by R. Eugene Baucom, we can look at some geometry parameters in the NTFS boot record.

What do you think we have done till now?

The sector was posted here:
http://www.boot-land...?...11320&st=14
(by mistake instead of the MBR)

And that's where I found the 240 head value, which makes no sense on a 255 partitioned hard disk.

To recap once again:

• the MBR has data indicating a 255 geometry
• the bootsector has a geometry indicating a 240 one
• Lenovo's do use 240 geometry
• Partition cannot be checked by CHKDSK

My *suspect* is that this has happened because of the resizing and of the conflicting values in MBR and PBR, but the "usual" fixes seem like not working on this partition.


Wonko

[apemax]

There is an explicit option to write the changes, cannot remember right now where/which it is but is documented on TESTDISK help pages.

would this be it? on this page: http://www.cgsecurit...ki/Menu_Analyse
Write
Writes the changes that have been made in TestDisk's memory buffer to the hard drive. If you are unsure of the changes (often to the MBR's partition table), then don't use this function!

[Wonko the Sane]

would this be it? on this page: http://www.cgsecurit...ki/Menu_Analyse
Write
Writes the changes that have been made in TestDisk's memory buffer to the hard drive. If you are unsure of the changes (often to the MBR's partition table), then don't use this function!

Yes.
That one.
After you have written the changes, try re-running CHKDSK.

@Sha0
JFYI:
http://sourceforge.n...sfixboot/files/
maybe you can make something out of the source code.


Wonko

[Sha0]

Wonko: I've read all that source code; thanks for passing it along! The name you mention is ntfsfixboot. C/H/S geometry should only be important for booting, so I really don't think C/H/S geometry is worth considering in this instance. What do you think? By the way, you are quite right about not being able to attach 512-byte .bin or .mbr files.

apemax: If the Recovery Console CHKDSK is having problems, perhaps we can find out more detail. What would a non-RC CHKDSK say, for example? That is, a CHKDSK from a Windows PE or full Windows. Would this be worth trying? It might produce more useful error information.

Apparently your $MFT is at sector 805326 X 8 (sectors-per-cluster) = 6442608, with the $MFTMirr at 3274421 X 8 = 26195368. Just for fun, you could try the NTFS boot record I've attached, where I've simply swapped these two... Since they're supposed to be copies, I doubt that it'll make any difference, but you could be lucky!

Attached Files

•  apexmax.zip   580bytes   323 downloads

[Wonko the Sane]

@Sha0
It was only a test, I was hoping that CHKDSK, when it finds this kind of error refers to some other data to make sure, by changing this other data, maybe it could work.

The "full" CHKDSK being somehow different (hopefully "better" ) from the RC one is possible, though.

TESTDISK has built-in capabilities to compare the two $MFT copies and choose the one that is right (if any of it is right):
http://www.cgsecurit..._and_MFT_Repair

What would be the most easy to build project with "full" CHKDSK?

(Apart UBCD4WIN )

@apemax
You do have an XP install CD, right?


Wonko