Re: Drive not bootable after resize
cmdr,
Here you go:
www.chuckscomputer.com/Gifs/hda.MBR2
Thanks for sticking with me!
If the voices inside my head paid rent, I'd be rich!
You are not logged in. Please login or register.
GParted forum → GParted → Drive not bootable after resize
cmdr,
Here you go:
www.chuckscomputer.com/Gifs/hda.MBR2
Thanks for sticking with me!
Hi Musky,
ok, my new MBR arrived ! "GParted", "fdisk -l -u" and "MC_HxEd" should "see" it as hda1.
Try Windows "chkdsk" again.
Additionally I put hda.MBR3 here for download, which contains the same size value as the PBR. Load it with "dd" (like MBR1) to your HDD and try it, too.
Regards
cmdr
Hey cmdr,
I'm moving a little slow this morning. When you say:
ok, my new MBR arrived ! "GParted", "fdisk -l -u" and "MC_HxEd" should "see" it as hda1.
Do you mean that it's where it's suppose to be already? I have tried to access the drive several times within Windows recovery console as well as from the "command prompt" in the Vista repair CD. and I get the "unreadable drive error" which each word differently, but neither will allow access to the drive. From the Vista command prompt, I get "unreadable drive" when I type in "C:"
So now I will try loading the new MBR you just posted. I assume I should rename the file "had,MBR3? to "hda.MBR1" before I upload it to the hard drive?
Thank you!
cmdr:
I downloaded the hda.MBR3 file, renamed it "hda.MBR1" and used the USB stick to upload it to the drive in the terminal window. I then tried mounting the drive and got the same "specify file system" error I got yesterday.
I booted to Windows recover console and still could not run chkdsk.
I went back in Gparted, and now in the graphical interface window it shows a bootable NTFS partition, still with the caution flag, of 92.81 GB, but then at the end of the drive, it shows "unallocated" space of 18.98GB. This was never there before and must be a result of the last MBR uploaded.
18.98 GB was roughly the size of the original system "C" partition that I began with, the one I expanded to fill the drive. Is this just a reporting error in the MBR?
I imagine you are getting tired of dealing with this
Thanks!
Hello Musky,
I imagine you are getting tired of dealing with this...
No, I love the challenge !
I went back in Gparted, and now in the graphical interface window it shows a bootable NTFS partition, still with the caution flag, of 92.81 GB, but then at the end of the drive, it shows "unallocated" space of 18.98GB. This was never there before and must be a result of the last MBR uploaded.
With my last uploaded MBR (hda.MBR3), I flipped hda2 and hda1. Furthermore I put the drive size contained in PBR of hda1 (former hda2) to the MBR, supposing, that this value might still be true, thus creating a Windows compatible environment. Note, that we did NOT change anything, except for the MBR. If your drive still has a working or correctable NTFS structure, we get it to work. If not, files might be recoverable with "testdisk" / "photorec".
Yes, the "unallocated space" is the result of the fact, that hda1 - at the moment - does not use the whole drive. The last not yet tested possibility is, that your resizing operation was successful, except for the updating of the new size within the PBR, thus cutting important administrative structures, which consequently corrupted NTFS. I could correct this by exchanging both MBR and PBR, but you haven't yet tried the "check" function of "GParted" with your current configuration. Maybe a simulation of a resizing action to 120GB with "ntfsresize" offers new important hints (ntfsresize -n -s 120G /dev/hda1). Please test both. If applicable, "ntfsresize" triggers Windows "chkdsk" for the next reboot with a Windows repair console.
I played around last weekend with a NTFS formatted USB stick and reduced the drive size value in PBR step by step. With small steps , "chkdsk" from Vista repair console adapted the file system, so that nothing got lost. In other words, I successfully reduced ( and grew !) the partition size without the help of an appropriate software ! A big shrinking step corrupted the filesystem, so that even "GParted" was not able to do anything ... but restoring the last valid size value brought back full access ! And the "check" function of "GParted" worked reliably.
Chin up, we'll get it !
cmdr
Hi cmdr!
I thought I'd lost you
You have mentioned the "check disk" function of Gparted before, where is this found? I have looked at the tools menu that pops up when you right-click in the Gparted GUI, but can't seem to see the "check" function.
I'm also afraid that you are losing me with the steps you want me to try, like I said, I am out of my "comfort zone" here LOL
Do you want me to run this command from a terminal windows in Gparted?
(ntfsresize -n -s 120G /dev/hda1)
Thanks, I really appreciate the help!
Hi Musky,
You have mentioned the "check disk" function of Gparted before, where is this found?
Highlight "hda1", right-click for context menu, choose "Check" (between "Manage Flags" and "Label"). You also find it under menu item "Partition". Just let it run, store "gparted-details.htm" and upload it.
Do you want me to run this command from a terminal windows in Gparted?
Yes, but without the brackets :
ntfsresize -n -s 120G /dev/hda1
This simulates a resizing of the first partition from its actual size 92.81 GB to 120 GB without writing something to the drive. The fault messages are important. If they are interesting (not all "error"), you can redirect output to a file this way :
ntfsresize -n -s 120G /dev/hda1 > /root/resize.txt
... and upload it, too.
Regards
cmdr
Hey cmdr!
Here is the details file:
http://www.chuckscomputer.com/Gifs/gparted_details.htm
And here is the resize text:
http://www.chuckscomputer.com/Gifs/resize.txt
Hope we can solve this
Hi Musky,
both uploads are nearly identical ( so we now know, who does the "check" work : ntfsresize ) ... and do NOT solve your problem !
And now the last "standard" trial, before the use of "testdisk" : we exchange MBR (again) with "hda.MBR1" (which gives drive hda its big size of 120GB back) and old PBR with new hda1.PBR, which inflates filesystem to 120GB, too. So the whole drive gets into scope. This is also good for "testdisk", which we might have to use later. Try to boot and tell possible error messages.
hda.MBR1 is still downloadable. You get new hda1.PBR here.
Loading the boot records (NO TYPOS ! RESPECT PATH NAMES !):
dd if=/mnt/usb/BootRec/hda.MBR1 of=/dev/hda bs=512 count=1
dd if=/mnt/usb/BootRec/hda1.PBR of=/dev/hda bs=512 seek=63 count=1
Regards
cmdr
Well,
I've hit a snag.
This command:
dd if=/mnt/usb/BootRec/hda.MBR1 of=/dev/hda bs=512 count=1
Worked fine, it said "one file in, one file out"
But this one:
dd if=/mnt/usb/BootRec/hda1.PBR of=/dev/hda bs=512 seek=63 count=1
Just returns an error: "No such file or directory"
I have tried several times, and re-downloaded the PBR file to make sure it isn't corrupt. It will just not load the PBR file!
A side point is, that now in the GUI it shows "/dev/had1" as 111.79GIB, so it is still not showing the whole drive. I'm sure it is because the MBR and PBR are no longer matched, but I can't seem to load a new PBR.
Hi Musky,
But this one:
dd if=/mnt/usb/BootRec/hda1.PBR ...
Just returns an error: "No such file or directory"
Either you used another path or you did not respect, that Linux file/folder names are case-sensitive, e.g. "hda1.PBR" is not synonymic to "hda1.pbr" as it is with Windows.
Or it was just a typo. Anyway "/dev/hda" exists or the first "dd" command would have failed, too.
A side point is, that now in the GUI it shows "/dev/had1" as 111.79GIB, so it is still not showing the whole drive.
The value, your very first MBR showed ( and which I used of course ), is 0xDF93782 sectors (=> 234,436,482 sect. x 512 Bytes/sect. = > 120,031,478,784 Bytes = 120.03 GB; decimal value, given by the manufacturer).
120,031,478,784 / (1,024 x 1,024 x 1,024) = 111.79 GiB (spoken G-bi-bytes for Giga (b)i(nary information unit) Bytes).
Ergo, it fits.
Regards
cmdr
Good Morning.
I have tried several times this morning and I still get the "No such file or directory" error. I have tried different USB sticks just in case, still it will not load the hda1.PBR. I have double checked for typos also.
Could it have something to do with this part"
seek=63
Maybe it can't locate sector 63 if that is what the command means? It is the only difference in the two commands?
I am grasping at straws to find the problem, so it may not be that.
Also, I wonder why the drive use to show in Gparted as "119.xx GIB"
Thanks again!
Hello Musky,
I have tried several times this morning and I still get the "No such file or directory" error. I have tried different USB sticks just in case, still it will not load the hda1.PBR. I have double checked for typos also.
The fault message states, that it can NOT find a "file or directory". There are only two parameters concerning files or directories : if(input file)=/mnt/usb/BootRec/hda1.PBR and of(output file)=/dev/hda. We can definitly exclude the latter, because the first "dd" worked. If you used the same USB stick as with post 16 of this thread, it shold still have folder "<driveletter>:\BootRec" with Windows, where you could store downloaded "hda1.PBR". If you mounted it with "MC_HxEd" (just by clicking on an arbitrary drive) , you should see /mnt/usb/BootRec/hda1.PBR with "mc".
Open a second Terminal console, to verify it additionally with :
echo /mnt/usb/BootRec/*
If path does exist, you see file "hda1.PBR" as output, else you see "/mnt/usb/BootRec/*".
If your real path is "/mnt/usb/Bootrec", the file is not found with path "/mnt/usb/BootRec".
In this case, follow the path upwards with "mc" and look, where it differs. Type your real path instead with "dd". Do not touch "seek=63", nor omit it ( if this already happened, you may have overwritten MBR. Just repeat the first "dd" command line to correct it) !!!!
Regards
cmdr
CMDR,
Well, your advice allowed me to see the problem, but not the solution. When I run the echo command, it shows the path to the PBR file on the usb drive as correct, except, that it shows the PBR extension in lower case "pbr". That is why is won't move it to the hard drive because I was entering the file name correctly, with an upper case extension "PBR". This is what it shows on my working computer, and on the flash drive from my working computer. No matter what I do (I even tried saving it to the usb stick in lower case to see what would happen). It still shows "hda1.PBR" as "hda1.pbr". It shows the "hda1.MBR" correctly.
What would cause it to read upper case letters as lower case? And should I use DD to copy it to the hard drive anyway, hoping that it will be read in upper case from there? "hda1.PBR"?
When I look at the MC windows, on the left side under "/mnt/usb/BootRec/" it shows two files:
hda.MBR1
hda1.pbr (lower case)
On the right side of the MC screen under "HOME" and below it is "USER" where it shows:
hda1.PBR (upper case) with today's date and time.
Where is the "USER" tree? Is that on the hard disk? Did it copy over from the usb stick anyway, even thought is was giving me the file not found error?
Very strange!
Hi Musky,
Very strange!
no, this is Linux! And you did (almost) nothing wrong !
One by one :
1. On downloading "hda1.PBR" , Windows (?) changed file name to "hda1.pbr". This is NOT the first time, that it happened; Windows doesn't care, but Linux does ! If you look at the download site, you can see, that the upload was written correctly.
2. Your USB stick holds path "/mnt/usb/BootRec" as needed, and it contains file "hda1.pbr" (your download; compare file date = 09-07-07). You see it on the left side after mounting your stick with "MC_HxEd" in "Midnight Commander".
3. Since you clicked on "hda1" to trigger mounting of the stick, the current PBR of hda1 ( which doesn't work !) is temporarily stored in (RAM-)folder /home. Its file extension uses capital letters, because "MC_HxEd" names this file that way. To avoid confusion, you'd better click to create "drvs.dat", which also mounts your stick.
4. Use the following command to write "hda1.pbr" to your HDD:
dd if=/mnt/usb/BootRec/hda1.pbr of=/dev/hda bs=512 seek=63 count=1
Regards
cmdr
wow....nice post.....
sales tracking software
That makes sense except for one thing. In every other computer I own, when viewing the files on the flash stick, it shows the file name as "hda1.PBR" in upper case!
Why is it only Gparted that it shows as lower case letters?
Hello Musky,
maybe it's a DOS issue with long filenames and short (8+3) filenames. With "hda1.PBR" they are equal, except for the used characters. The short filename is stored as "HDA1.PBR" within the DOS FAT. Lower-case names prevail in Linux, maybe there is a convention to use the short filename, if it (almost) matches the long one and to convert it to lower case; its my speculation, no explanation.
Regards
cmdr
P.S.: I did a few tests and can confirm, that it happens with my USB stick, too. But if I copy the downloaded file directly from the Linux mounted HDD (NTFS) , original filename is preserved. Strange behaviour !
Cmdr,
Sorry for the delay, I had out of town business.
You are right about it being strange. Once I loaded the file from my USB stick to the drive using the "DD" command with a lower case "pbr" extension, the file copied fine. But it changed the file name on my USB stick from upper case PBR to lower case pbr when I checked it in my other computer.
Anyway, I now finally have the new hda.MBR1 and hda1.pbr file loaded. I did a disk check with Gparted and here is the link to that:
http://www.chuckscomputer.com/Gifs/gparted_details.htm
Unfortunately, Windows still does not see the file system. When I try to run chkdsk from the recovery console I still get "The disk contains one or more unrecoverable problems"
I wish there was a way we could communicate faster, maybe email? Because of our different locations, these back and forth posts takes a day or more each way
Thanks again!
Hi Musky,
Unfortunately, Windows still does not see the file system. When I try to run chkdsk from the recovery console I still get "The disk contains one or more unrecoverable problems"
... and "Gparted" tells the same, there is NO progress ... and we, gradually, run out of gun powder!
Anyway, it's time for "testdisk" (see here for an instruction). Use the version, that comes with latest "GParted Live".
What you should know :
1. Testdisk has its own (console) user interface; it's not a pure commandline tool.
2. Testdisk offers a log for all your actions, which you MUST enable for our purpose (analysis)!
Always create a new logfile (backup the former before), when you restart !
3. As long as you don't press "Write", your HDD is NOT altered in any way. You MUST NOT
press "Write" without my prior consent.
4. If analysis is positive ( you might see your files ), you must do all steps again to get back
to that point. So write down each action, you did with "testdisk".
5. Your disk has an "Intel partition table" and partitions were probably not "created under
Vista". "Deep search" is the last (time-consuming) rescue effort.
6. Of course: upload the (zipped) log files.
Perhaps "testdisk" suggests to use "photorec" as last rescue trial. Be aware, that images may contain metadata with their filename, nearly all other files do not. Therefore files might get arbitrary numbered filenames... and you need an external storage device for the recovered files.
Regards
cmdr
GParted forum → GParted → Drive not bootable after resize
Powered by PunBB, supported by Informer Technologies, Inc.
Currently installed 2 official extensions. Copyright © 2003–2009 PunBB.