User discussion and information resource forum for Image products.
Fri Apr 07, 2017 5:33 pm
Thanks. That looks fine. What are the other two partitions?
I'm interested in your hardware to see if we could run an experiment with that SSD.
Fri Apr 07, 2017 5:48 pm
Sorry for this, but I don't think we're all on the same page. I think I have a hold of it, but it's greased and I'm afraid to lose it, so I'm posting.
I read the dissimilar hardware link and I don't think that's what he's doing. Here's how I see it.
He has a system with W7 on it currently residing on an HDD. What he wants to do is just change the HDD for an SSD. The new drive will be in the same system the old came out of so there are no driver differences as there would on a totally different system, SATA controller etc. It'd be just like a drive failure except there you'd be dealing with an Image and here he's using the Copy function.
Now, the way he's going about it, which seems backwards to me is he's removing the old HDD, before the copy, installing the new SSD, connecting the old HDD via USB and then doing the copy, old to new. Seems connecting the new SSD via USB and leaving the old installed during the Copy then making the swap would be the way to do it, but maybe it doesn't matter. Then again, the OS on the old HDD wouldn't be marked active if it wasn't in the system at the time, no?
I get using copy considering the drive size to accomplish what he wants.
I'll wait for Marc's confirmation I have it right.
Fri Apr 07, 2017 5:59 pm
OK. Not a driver issue but it is using different hardware so...
"Assume Same Target System – Enable this option to prevent problems where users restore an image from another system to a drive that will be put back in the other system. For example, the hard drive from PC-A is backed up; PC-B is used to restore to a new hard; that new drive is placed back in PC-A. Without this option enabled, Image for Windows would setup the partition to properly boot on the hard drive for PC-B which can sometimes (not always) be a problem when the hard drive is going back to PC-A. This option solves that and is equivalent to the individual Use MBR Geometry override."
Fri Apr 07, 2017 6:04 pm
Brian K wrote:
> OK. Not a driver issue but it is using different hardware so...
> "Assume Same Target System – Enable this option to prevent problems
> where users restore an image from another system to a drive that will be
> put back in the other system. For example, the hard drive from PC-A is
> backed up; PC-B is used to restore to a new hard; that new drive is placed
> back in PC-A. Without this option enabled, Image for Windows would setup
> the partition to properly boot on the hard drive for PC-B which can
> sometimes (not always) be a problem when the hard drive is going back to
> PC-A. This option solves that and is equivalent to the individual Use MBR
> Geometry override."
Ok, but everything's happening on PC-A, no PC-B involved, or do you know that. Sorry, my heads a lot :willy: from trying to untwist this pretzel.
Fri Apr 07, 2017 6:14 pm
"The first, which I haven't talked about, was to make an image on an external USB drive (HDD in Laptop, External USB HD and Bootable USB with IFD). Then I attached the External USB HD with the image file and the new SSD via USB to my own laptop (with USB 3.0). I used IFW to copy the Image to the SSD. No errors reported, successful validation. But when I put the SSD in the Compaq Laptop - would not boot."
Two computers involved.
Fri Apr 07, 2017 6:31 pm
Ah, we're going from different methods. Yes, I see how that works in that situation and agree its the way to go. The method I went by made no sense at all if you read through it. I still wonder if it can be accomplished that way, but in the order I mentioned.
Glad that's sorted.
Sat Apr 08, 2017 9:10 am
Ok, lets not complicate things. I would like to focus on the last attempt. This involved only the one computer and the SSD drive was installed, the original HDD was attached as a USB drive and the operation was a COPY.
I did it this way because of the recommendations in this thread: https://www.terabyteunlimited.com/ucf/v ... f=4&t=2087
"Keep in mind that generally it's best to have the destination drive in its final location when the copy is performed. In this case, the SSD would be installed as the booting drive and the HDD would be in the hot swap caddy." -Paul Purviance, TeraByte Support
On the second page of that thread, someone had the same problem as I do. Paul from Support replied:
"For the partitions, the small System partition should be set active. ... You could also try using the "Write Standard MBR Code" option."
On the SSD after COPYing, the SYSTEM partition was set to active and I had used the Write Standard MBR code.
I had forgotten that I reviewed that thread before going to Florida and attempting the upgrade. Maybe I should have added my post to the end of that thread but it is a year old so I started a new one.
Before I forget again, the other 2 partitions are: the Restore to factory setup partition and one called "HP Tools".
Sat Apr 08, 2017 10:02 am
Ok Marc I see I was right on what you were trying to do.
Given everything you've said so far the only thing I see being an issue is the align to 1 meg and write standard MBR. Standard MBR went out with XP (maybe Vista, but I skipped that OS). There's an option to write W7 MBR and/ or convert standard to W7 which means you might try that before doing anything else to the SSD. Could be that simple. As to the 1meg thing, it's for when different programs use different sector sizes when formatting or creating a partition to prevent overlaps. You get a warning that there's a conflict if you don't have it enabled when it needs to be. I don't know if there's a warning the other way around or it doesn't matter as there'll be no overlap. Might just show 1 MB of free space between partitions if it isn't.
Those two partitions, the recovery and tools should contain no boot info. The recovery is to return your system to factory state and the HP one contains diagnostic tools for the system. Unless it's a GPT drive, boot info is written to two places. Part of it goes to the MBR and the other to the OS partition or in some cases to the 100 MB partition created during the install associated with that OS partition. This is where you'd point to the small partition to access the OS's part of the total boot info. The boot files can be moved to the OS partition and the 100MB partition deleted. It involves another process and I'm trying to keep it simple.
Brian's way is correct for the first method you used, with two systems. You said you wanted to tackle the method in your first post so I'm going by that.
Sorry for the confusion, we were just making sure we gave you the correct info. Making a new thread was fine, just wish you laid everything out in the first post instead of dribs and drabs. Again, no biggie, it was good exercise for the bean working through it. Read through that standard MBR link and make sure it isn't old and talking about XP. If there are any more questions/ confusion just let us know, we'll try to explain further.
To sum up, I think you have the wrong type MBR possibly combined with pointing to the wrong partition looking for the OS's part of the boot data. If you see something I'm not getting, shout out.
Sat Apr 08, 2017 10:40 am
I'm afraid I have to disagree with you "Align Partitions on 1 MiB Boundaries" is the standard for writing to SSDs. Do a quick google search on 1 MB boundaries and SSDs and you'll find a lot of info. Here's the gist of it:
"Solid State Disks require partition alignment to 4KB boundaries for optimum performance and life. 1MB aligned partitions are also aligned on 4KB boundaries so present no problem, however, CHS aligned partition are often aligned on 63 sectors (31.5KB) and this will degrade SSD performance and life time considerably."
As far as the Write Standard MBR: IFW, by default, is using the the MBR code base compatible with Vista or later - which includes Win 7.
The W7 MBR option that you referenced is only used to disable this for older configurations.
From IFW manual page 124:
Windows Vista and later tied the kernel loader to the MBR code such that using previous MBR code may not allow Windows Vista or later to boot on certain machines. By default, Image for Windows uses the code base compatible with Windows Vista or later. The new MBR code will continue to boot older OSes with the exception of some (rare) configurations using Win9x on FAT32. Specify this option to have Image for Windows use Windows 9x compatible MBR code.
Note that the .ini file value is not used on command-line based operations. Default if omitted : MBR code compatible with Vista/Windows 7 or later is used."
Sat Apr 08, 2017 11:46 am
Disagreement is good, shows we don't have a meeting of the minds.
Ok, forget the 1MB thing, like I said, you'd only get an error if it were needed and no harm if not so that's moot.
According to your quote, checking write standard MBR is to be used only on 9.x systems in certain rare instances. The W7 format is default as long as the write standard MBR isn't checked. You checking it took it out of the default setting which is why I said converting it back to W7 format might fix it. What it's saying is the new default format will work on older OS's and Vista forward and the old is for "rare configs using 9.x on FAT32". This is where the write standard is required. Since you said you used this option, the MBR is not compatible with W7 as it exists on the system now. Thus, the simple conversion to the default W7 format via Part Work or whatever would make it compatible. Does that make sense so far?
Now, we have to add in the partitions and what contains the OS part of the boot info. The restore and tools partitions do not. The only other partition that could hold them other than the OS is a 100MB partition, created during OS install to unpack the installer data if a destination partition isn't set up before the OS disk is inserted. This is when a partition other than C can contain the boot info. It will always be 100MB and have no drive letter or label, etc...
Here's where we're differing in interpretation.
"Windows Vista and later tied the kernel loader to the MBR code such that using previous MBR code may not allow Windows Vista or later to boot on certain machines. By default, Image for Windows uses the code base compatible with Windows Vista or later. The new MBR code will continue to boot older OSes with the exception of some (rare) configurations using Win9x on FAT32. Specify this option to have Image for Windows use Windows 9x compatible MBR code.
Make sense or still confused?
phpBB® Forum Software © phpBB Group.
phpBB Mobile by Artodia.