79 replies to this topic

[Wonko the Sane]

Yep , hence the non-strict definition of *need*.

 

BTW, the original idea was to have a way to boot *all* installs even with the first active partition "compromised".

Of course if you repair it (booting form "other media") as soon (and IF ) it becomes corrupted, there is never a case where you boot with first active partition compromised.

 

The good news are that this approach is simpler, the bad news are that it is pretty much how all people managed multi-boot since years, so nothing really "new" or with particularly increased "safety".

 

Wonko

[cdob]

The "files needed for booting" a Windows 7 system are BOOTMGR and a \boot\BCD.
These two files can be either:

• on a logical volume inside extended as long as the "sectors before" are corrected (because this is what allows booting from a logical volume)

 

As far as I know, bootmgr searches \boot\bcd at primary active partition.
http://www.multiboot...uk/bootmgr.html

Because of the way the Microsoft bootmanager works the Vista operating system expects that the BCD will always be on the system partition, so during bootup the Vista OS opens the system partition BCD. When using the Microsoft bootmanager the system partition is always the active primary partition on the drive seen in the BIOS as the first boot hard drive, even if that is not the partition you are actually running Windows from.

Never tried bootmgr at corrected "sectors before" logical partition so far.

the bad news are that it is pretty much how all people managed multi-boot since years, so nothing really "new" or with particularly increased "safety".

Yes, it would be nice, if \boot\bcd at logical partition is cleared.

[sir_bootalot]

I made tests to get the Windows boot from the second hard drive (it was Vista, but works similarly, using OSL2000 boot manager, I think. It worked, but used the BCD on the first primary partition on the _first_ hd, that had Vista too (I tested by trying to open the BCD with notepad. It opened, so the BCD from second hd wasn't in use).

 

But you can choose to use hd2 as a boot drive by using F12 (if the BIOS allows) at the boot.

 

Generalizing (or respecializing) the BCD should also fix that issue of booting from second hd primary so it uses the correct BCD. (Might need aid from boot manager to remove active flag from the first hd primary partition).

 

Booting from logical is a bit harder. I'm not sure if it can be done with generalizing BCD, fixing the hidden sectors number, and using OSL2000 or BareMetal BootIt (XOSL didn't work). Hopefully will work with grub4dos.

 

Anyway, about those boundaries. I just experimented with Partition Wizard. It made the smallist possible first primary partition to sector 16064, and the steps were multiplies of 16065. The first step included 63 sectors reserved for MBR (with extra sectors).

 

IF the size of multiplies of 8*16065 aka 128520 is used (about 64 MB), then the END of the partition sets on the boundary that satisfies all the possible alignments (that you might want for large new HDs OR SSD disks), up to 4096.

 

The START of first primary and the start of every logical partition does not start on boundary, though. I don't know how much does it mean for large hd efficiency, but I think for SSD use people have done it that way (when they want to maintain the compatibility to 63 sector scheme).

 

So I think I'm gonna make the partitions with Partition Wizard in multiplies of 128520 sectors (about 64 MB), so the P1 would be either 128520, OR if W7 install really requires 100MB+ 'system' partition for boot files, then I'll use the size of 257040 sectors.

[cdob]

but used the BCD on the first primary partition on the _first_ hd,

Does this refers to BIOS first hard disk?

 

But you can choose to use hd2 as a boot drive by using F12 (if the BIOS allows) at the boot.

This swaps hard diks order: hd2 becomes BIOS first hard disk that way.
Bootmgr finds bcd at first BIOS hard disk, can be your called hd2 drive.

[Wonko the Sane]

 
Anyway, about those boundaries. I just experimented with Partition Wizard. It made the smallist possible first primary partition to sector 16064, and the steps were multiplies of 16065. The first step included 63 sectors reserved for MBR (with extra sectors).
 
IF the size of multiplies of 8*16065 aka 128520 is used (about 64 MB), then the END of the partition sets on the boundary that satisfies all the possible alignments (that you might want for large new HDs OR SSD disks), up to 4096.

 
Well, I wouldn't post anything of this tagged as "news", it is what I posted on post #20 .
 

 The START of first primary and the start of every logical partition does not start on boundary, though. I don't know how much does it mean for large hd efficiency, but I think for SSD use people have done it that way (when they want to maintain the compatibility to 63 sector scheme).

And again, there is NO difference of ANY kind if the small primary active is aligned to 4096 or it is not, all that is read on that is the BOOTMGR, the \boot\BCD and possibly a few more files added for multi-boot.
On "normal" hard disks, you can only appreciate the 4096 alignment by benchmarking high intensity disk activity, which the small primary active will never need to perform.
If you really-really want to align the logical volumes inside extended, the number of hidden sectors can be modified accordingly, though I don't think that an "automagic" tool capable of doing that exists, it needs to be done "manually" via hex editor or batch/script.

And again - set aside SSD's where other factors come into play (and possibly the AF disks, or more generally the new bg-big disks with 4K sectors ), there won't be any difference you will be able to notice under "normal" work if an internal fastish hard disk is not aligned to 4096.
 

As far as I know, bootmgr searches \boot\bcd at primary active partition.
http://www.multiboot...uk/bootmgr.html
Never tried bootmgr at corrected "sectors before" logical partition so far.Yes, it would be nice, if \boot\bcd at logical partition is cleared.

Neither did I, but I did use floppy images successfully (guess why I advised that ), and it is logic as the floppy is in itself a *primary partition* (being the only volume) of the boot device.
There is additionally (provided that a partition table entry is still free) the option to use "liberally" grub4dos features such as partnew (which BTW could be also a quick way to correct the "sectors before" on logical volumes) and also maybe - just maybe - map --in-situ

I have not at all clear when exactly the BOOTMGR "switches" to "protected mode" (or *whatever*) i.e. when exactly the booting system stops "trusting" the info from the BIOS and the system is re-scanned.

Besides the above , if the BIOS is trusted long enough, even something *like*:

4. Emulates an HD partition as the first hard disk and boot DOS from it:

map --read-only (hd2,6)+1 (hd0)
map --hook
chainloader (hd0,0)+1
rootnoverify (hd0)
map --harddrives=1
boot

may work.

 

Wonko

[sir_bootalot]

Does this refers to BIOS first hard disk?

 This swaps hard diks order: hd2 becomes BIOS first hard disk that way.
Bootmgr finds bcd at first BIOS hard disk, can be your called hd2 drive.

 

To the first question, yeah, when I didn't make the swap with F12.

 

To the comment below, yeah, thats when I made the BIOS swap. Just mentioned it as a way to implement an easy multiboot system without any hassle, just install (or clone) Windows to more than one HD, and use F12 to boot the other ones.

[sir_bootalot]

 And again, there is NO difference of ANY kind if the small primary active is aligned to 4096 or it is not, all that is read on that is the BOOTMGR, the \boot\BCD and possibly a few more files added for multi-boot.
On "normal" hard disks, you can only appreciate the 4096 alignment by benchmarking high intensity disk activity, which the small primary active will never need to perform.

 

Ok, so doesn't matter on performance. But the aligned P1 would mean the start point of P2 would be aligned too, so it would affect to Windows on P2 (performancewise, small or not, with big disks, and those SSD wear considerations).

 

But it seems the steps to respect both alignment schemes would have to be around 30 GB, so maybe I'll discard the idea anyway at least on my laptop.

 

16065*4096 = 65802240  so n*65802240 size partitions would respect both 63 sector alignments and 4096 (and possible SSD 2048 or 1024).

 

IF the SSD one would use had a recommended alignment of 1024, then 16065*1024 is around 8 GiB. (No, don't have currently SSD, just planning ahead when I'm gonna implement this with SSD. Don't even know for sure if my 1.5TB and 1TB hd's have 4096 used or whatever).

 

If you really-really want to align the logical volumes inside extended, the number of hidden sectors can be modified accordingly, though I don't think that an "automagic" tool capable of doing that exists, it needs to be done "manually" via hex editor or batch/script.

And again - set aside SSD's where other factors come into play (and possibly the AF disks, or more generally the new bg-big disks with 4K sectors ), there won't be any difference you will be able to notice under "normal" work if an internal fastish hard disk is not aligned to 4096.

 

Yeah, but I don't like to go that way. Some imaging tools etc. might fuck the things up after that.

Edited by sir_bootalot, 14 February 2013 - 12:14 AM.

[Wonko the Sane]

Ok, so doesn't matter on performance. But the aligned P1 would mean the start point of P2 would be aligned too, so it would affect to Windows on P2 (performancewise, small or not, with big disks, and those SSD wear considerations).

Sure, but there is NO issue whatsoever in leaving a "hole" between first and second parittion, thus having the second partition aligned and the first 1 "old standard".

 

 

Yeah, but I don't like to go that way. Some imaging tools etc. might fuck the things up after that.

No.

Imaging tools won't (or they are NOT imaging tools or they are buggy/they don't do what they should do ).

Obvously *anything* that deviates from common "standards" is more likely to be affected, and every "solution" or approach should be tested and tested thoroughfully.

 

Partitioning tools, particularly any Commercial and/or GUI "smart" tools will most surely.

Even "official" tools as seen in the mentioned thread:

http://reboot.pro/to...itioning-issue/

to do what apparently is a simple, plain change may deliver instead data loss .

 

Wonko

[sir_bootalot]

Okay, I'm prolly going to go with approach A), but before doing lots of work let me confirm which ones of these solutions work, and if I have understood something wrong. (I used to multiboot legacy Windows versions only with bootmanagers like SystemCommander and BootIt Next Generations, so most of stuff I have to go through now are new to me)

 

Let's say four Windows 7/8 OS's, and two linuxes. Aka 6 operating systems alltogether.

 

A)

100 MB 'System" primary partition (P1). Single BOOTMGR/BCD located on P1. Windowses on both primary and logical partitions, linuxes on logicals. If I understand things right, in this approach I choose the Windows I want to boot in BOOTMGR from BCD entries, not from grub4dos. In grub4dos the selection is 1) Windowses 2) Linux1 3) Linux2 and if I choose 1), I enter in the BOOTMGR menu, where I pick the Windows installation I want to boot (not from grub4dos menu).

So I can't put several Windows 7/8 entries in grub4dos menu, because only one BOOTMGR/BCD is used in this approach.

 

B )

Multiple BOOTMGR/BCD. Each one on it's own cloned Windows 7/8 partition. I made the selection which one of these (or linuxes) I boot from grub4dos menu. This requires fixing hidden sectors number if Windows is on logical. Also BCD's must be fixed by using generalized BCD inside the base Windows to be cloned, and/or respecializing every BCD in every Windows system/boot partition.

No common small 'system' partition used in this approach.

 

C)

Another multiple BOOTMGR/BCD approach. In this one, though, every BOOTMGR/BCD combo is located on a floppy image. Floppy images can be located to eg. small logical partition, and selection of which Windows to boot is made in grub4dos menu.

Either 4 floppy images for 4 Windowses, or one BOOTMGR/BCD combo located on the first Windows partition (P1), and the other 3 BOOTMGR/BCD combos on 3 floppy images (on a small logical partition). No need to fix hidden sectors numbers on logicals, but BCD's must be fixed by using either generalized BCD's or respecialized.

 

Would every approach A), B ), or C) work?

 

Have I understood something wrong in some of the approaches?

Edited by sir_bootalot, 14 February 2013 - 04:27 PM.

[cdob]

A and C should work.

B is unclear: does bootmgr find bcd at logical parition?
Bootmgr may read bcd from the fixed logical partition.
Or ignore the logical partition and search bcd at primary active partition.
Addional grub4dos mapping may help as Wonko the Sane named
http://reboot.pro/to...e-2#entry167839

Added:
B seems to work too. No need to fix hidden sectors.
http://kemovitra.blo...om-logical.html

[Wonko the Sane]

Added:
B seems to work too. No need to fix hidden sectors.
http://kemovitra.blo...om-logical.html

Hmmm, let me doubt it.

Unless the BCDEDIT repair procedure fixes them automagically or *somehow* the "new" bootcode of WIndows 7 completely ignores the BPB.

But if the latter, how can it find the BOOTMGR at all?

 

The same Author, here:

http://kemovitra.blo...ws-xp-from.html

gives the corresponding set of instructions for XP, where again, fixing the "sectors before" is not mentioned.

 

BUT we do have some (confused - I have to admit) reports about the need to fix the "hidden sectors before" on logical volumes for XP:

http://reboot.pro/to...ical-partition/

http://reboot.pro/to...nded-partition/

 

Particularly this report from Karyonix (actually the one two posts after this and following):

http://reboot.pro/to...e-2#entry101147

confirms this.

 

To the best of my knowledge an XP on logical volume (without "hidden" sectors before corrected) will result in rebooting the PC, but it is also possible that some partitioning tools (including the Disk management of Windows in some version) actually creates the "right" number of "hidden sectors" from the start 

 

Wonko

[cdob]

I doubted this myself and tried:

Windows 7 installation, shift F10, diskpart
select disc 0
clean
create partition primary size=100
create partition extended
create partition logical size=16000

Both are NTFS partitions.

Booted to a PE:
c: primary partition
e: logical partition

Copy c:\bootmgr and c:\boot\ to e:\
Install grub4dos-0.4.5c-2013-01-13 to MBR. And copy grldr, default menu.lst to e:\
Move c:\bootmgr and c:\boot\ to c:\backup\
bcdedit.exe /store E:\Boot\BCD /set {bootmgr} device partition=E:


Reboot: grub4dos, c
chainloader (hd0,4)+1
boot

Windows 7 does boot. Success!

Yes, confirmed: bootmgr reads \boot\bcd from logical partition.

Logical partition hidden sectors: 2048
This relate to offset to extended partition, this is not a LBA.

Crosscheck: grldr from grub4dos 0.4.4 from 1999:
Windows 7 does boot still.

Be aware:
this requires a 48-bit LBA capable BIOS at partitions after 128 GB.

[sir_bootalot]

I got only cross-linked results, both from primary and logical partitions.

 

I have a small common 'system' primary partition for boot files (P1) and two more primary partitions, P2 for original Windows 7 install, and P3 for a cloned one (cloned from P2 with fsarchiver).

 

The third Windows 7, also cloned from P2, is at the first logical, L1.

 

I made two more entries to BCD for those cloned windowses, and got them to boot, but e.g. /users/ directory is crosslinked to C: partition, that is P2 on both P3 and L1 windowses. So if I create a text file on desktop in any one of those Windowses, it shows up in every other one's desktop.

 

Checking with disk manager showed the 'Boot' partition was correct, D: when booting P3 and E: when booting L1. But some of the registers had C: in them because the cross-linking happened.

 

http://www.multiboot...ve_letters.html

 

This situation was mentioned in multibooters.co.uk link, and it was recommended to make the _first_ boot with all the other partitions hidden at the same hd. So I tried restoring new copies of image on both P3 and L1, and tried to boot them with all the other partitions changed to type 63 (Gnu Hurd), so only two partitions on the hd were visible, the P1 'system' and the one I tried to boot (P3 or L1).

 

The result was jamming on boot with both of them.

 

Any ideas of solution?

 

Fixing the registers afterwards the way it was described at multibooters.co.uk link is too much hassle that would take a way the idea of my setup, to get a fresh restore of a Windows image fast when I want.

 

Could the reason be fsarchiver? By reason I mean, that it just doesn't do the job similarly than I think Easus does. So cloning and restoring to another partition with Easus perhaps fixes the registers automagically so that cross-linking doesn't happen, but fsarchiver doesn't so fixing must be done afterwards.

 

(Haven't tried Easus yet with this setup)

Edited by sir_bootalot, 15 February 2013 - 03:23 AM.

[cdob]

I made two more entries to BCD for those cloned windowses,

That's a outdated approach
 

Checking with disk manager showed the 'Boot' partition was correct, D: when booting P3 and E: when booting L1. But some of the registers had C: in them because the cross-linking happened.

Well, insane manufacturer: 'Boot' partition should be C: always.
Use label names. 

http://www.multiboot...ve_letters.html
 

Fixing the registers afterwards the way it was described at multibooters.co.uk link is too much hassle that would take a way the idea of my setup, to get a fresh restore of a Windows image fast when I want.

Delete MountedDevices\DosDecices\C: first, clone the partition next.

[Wonko the Sane]

@cdob, good .

Yes, confirmed: bootmgr reads \boot\bcd from logical partition.

I would rather say that it tries reading the \boot\BCD from the same volume the booted BOOTMGR resides (but the effect is the same).

 

So, we can "draw" a line, *somehow* BOOTMGR (unlike NTLDR) or very possibly the PBR code invoking BOOTMGR (unike the PBR code invoking NTLDR) does not need the correction for "hidden sectors" before.

 

BUT, can you also try (still with no correction of the "hidden sectors"):

 

 

 

chainloader (hd0,4)/BOOTMGR
boot

and

 

 

root (hd0,4)
chainloader /BOOTMGR
boot

to (hopefully) verify if it's the PBR or the BOOTMGR?

 

Wonko

[cdob]

So, we can "draw" a line, *somehow* BOOTMGR (unlike NTLDR) or very possibly the PBR code invoking BOOTMGR (unike the PBR code invoking NTLDR) does not need the correction for "hidden sectors" before.

Yes, it's unclear.
.

chainloader (hd0,4)/bootmgr
Will booot NTLR from drive=0x80, partition=0x4(hiddens sectors=0x33000)
boot

Windows 7 does boot.
.

root (hd0,4)
Filesystem type is ntfs, partition partition type 0x07
chainloader /bootmgr
Will booot NTLR from drive=0x80, partition=0x4(hiddens sectors=0x33000)
boot

Windows 7 does boot.

Does grub4dos patch hiddens sectors on the fly?

Some \boot\bcd\ at logical partition behaviours:
There is no registry hive HKLM\BCD00000000
msconfig.exe can't configure start options.
'Bcdedit.exe': "The boot configuration data store could not be opened."
'Bcdedit.exe /store %SystemDrive%\boot\bcd' lists entries.


New game:
at 100 MB primary parition
\boot\bootmgr
\boot\bootsect.bin : the first 16 sectors from the logical partititon
\boot\bcd

BCDedit.exe /createstore BCD
BCDedit.exe /store BCD /create {bootmgr} /d "Windows Boot Manager"
call :add_bootsector \boot\bootsect.bin "\boot\bootsect.bin"
goto :eof

:add_bootsector
 for /f "tokens=1-3" %%a in ('BCDedit.exe /store BCD /create /application BOOTSECTOR') do set guid=%%c
 BCDedit.exe /store BCD /set %guid% device boot
 BCDedit.exe /store BCD /set %guid% path %1
 BCDedit.exe /store BCD /set %guid% description "%~2"
 BCDedit.exe /store BCD /displayorder %guid% /addlast
goto :eof

\boot\bootmgr at 100 MB primary parition booted:
black screen, blinking cursor at upper left corner.
Remember that's 2048 hidden sectors at logical partition.


The extended partiton starts at sector 206848.
The logical partiton starts at sector 206848+2048 = 208896 (0x33000 this matches grub4dos output)
The logical partition hidden secors set to 208896. And the file \boot\bootsect.bin adjusted.

\boot\bootmgr at 100 MB primary parition booted:
Windows 7 does boot 

[Wonko the Sane]

Does grub4dos patch hiddens sectors on the fly?

No, not that I know of, and since you tried also 0.4.4 I doubt that it can be a "new feature" and, on the other hand, IF it corrected them, then NTLDR would boot as well, but the mentioned threads testify the opposite.

Can you try adding a NTLDR, a BOOT.INI with two entries to that logical volume and chainloading it?

root (hd0,4)
chainloader /NTLDR
boot

should fail booting, until you correct the "hidden sectors in the BPB of the logical volume and get you happily to the two BOOT.INI choices.
 

 
New game:

Nice , this confirms (if the above test with NTLDR gives the expected results) that BOOTMGR (when invoked directly) *somehow* "finds itself", ignores the BPB recalculating the "hidden sectors", while when using a "legacy" chainload bootsector approach, trusts the BPB and fails miserably unless the "hidden sectors" number is corrected AND that the PBR code manages to find BOOTMGR ignoring the BPB "hidden sectors" data.


Wonko

[cdob]

Can you try adding a NTLDR, a BOOT.INI with two entries to that logical volume and chainloading it?

XP SP3 ntldr and boot.ini copied to logical partition:

At 208896 hidden sectors still:
'chainloader (hd4,0)/ntldr' does work: ntldr list boot.ini entries


At 2048 hidden sectors:
\boot\bootsect.bin works still. Windows 7 does boot.
It's sufficient to patch the boot sector file only.

'chainloader (hd4,0)/ntldr' fails:

Invalid BOOT.INI file

boot.ini is not found. Yes, this fails as predicted.
Setupldr.bin fails too: ntdetect failded. Hence ntdetect.com is not found

To summerize:
ntldr requires patched hidden sectors at a logical parition
bootmgr works at windows default hidden sectors, if loaded from the logical partition. No need to patch hidden sectors.
A patched boot sector file can be used too.

[Wonko the Sane]

To summarize:
ntldr requires patched hidden sectors at a logical parition
bootmgr works at windows default hidden sectors, if loaded from the logical partition. No need to patch hidden sectors.
A patched boot sector file can be used too.

Very good.

Can we add (or clarify) that the patched bootsector file works with BOTH NTLDR and BOOTMGR?

 

I propose you another experiment (while you are at it, and of course only if you have the time for this).

Can we finally put aside the (not fully debunked till now) myth that to boot Windows XP NTLDR is actually needed?

See here:

http://www.msfn.org/...er/page__st__20

Basically it seems that BOOTMGR (when there is an entry in the \boot\BCD for the "legacy" OS) needs not NTLDR, accesses BOOT.INI directly and is (maybe) capable of loading the XP without NTLDR. 

 

 

Wonko

[sir_bootalot]

Haven't been able to solve the cross-linking problem with these attempts.

 

Plan: Windows 7 to four partitions on a laptop. Primary 1: 128 MB 'System' partition (P1). P2, P3, and logical 1, and L2 Win7 boot partitions (and a few more logicals on HD1). 63 sector alignment used.

 

I installed the P2 Windows, and added just one more entry to BCD for P3 Windows first. (Trying to get the Bootmanager to boot Windows both from primary and logical first, before installing Grub4dos) So I copied the original Windows 7 entry (Win7 P2) to another (Win7 P3), to boot from the third primary after cloning.

 

The P3 partition was originally labeled as L: (P1 on HD2 had took D:), but I had moved the partition letters so, that the partitions on HD1 were now C:, D:, E:, F: ... etc. so BCDEdit showed the Win7 P3 boot entry as D:, but I labeled it as \Device\HarddiskVolume3 on both 'device' and 'osdevice' (after unmounting D: from Disk Manager).

 

C: stayed there for the first Windows 7 boot entry (is this correct, or should it be \Device\HarddiskVolume2? Can't unmount C: from Disk Manager, so it should be made booting from DVD...)

 

Attempt 1)

 

Before cloning the first Windows (P2), I deleted C: and D: DosDevices from registry, and also their corresponding \??\Volume... that had the same data value.

 

Then cloned with fsarchiver, and restored on P3. P3 booted, but the cross-linking was still there.

 

Attempt 2)

 

Now I booted P2 and noticed there was also L: DosDevice in registry, although I had no L: anymore showing in Disk Manager. It was the old drive letter of the P3.

 

Now I deleted DosDevices C:, D:, L:, and a few more of the partitions L1 and L2, and also the letters they were previously before I moved drive letters as described above. I also deleted couple more \??\Volume... that I thought were previous keys to the drives L1 and L2. (Hopefully I didn't make mistake in that).

 

I left the partitions P3, L1 and L2 without drive letter. I cloned P2, restored it to P3.

 

Now P3 did not boot (autocheck missing, bluescreen, reboot).

 

After that I booted to P2, and noticed DosDevices for D: and E: were generated in registry, although I didn't have drive letters for them used anymore. (instead, also removed F: didn't have DosDevices generated)

 

One more observation: When I booted from DVD and looked at the partition P1 (the 'System'), there was BOOTMGR, but no BCD at the \boot directory. There was BCD.LOG and couple of more log files named perhaps BCD1.LOG BCD2.LOG or something like that. So if I should edit BCD booting from DVD, I wonder where it is located. (And yes, I'm sure about partition, it was named as SYSTEM)

Edited by sir_bootalot, 18 February 2013 - 03:27 PM.

[Wonko the Sane]

I refuse to read anything formatted like the above.
Punctuation, carriage returns/newlines, lists (pointed or numbered) etc. do help in making things readable.


Wonko

[sir_bootalot]

I hadn't java script on, so it ate the line feeds. I corrected it in a few minutes. You can try again.

 

For extra clarification:

 

P1  SYSTEM (primary)

P2  Windows 7 original install  (primary)

P3  Windows 7 clone  (primary)

L1  Windows 7 clone  (logical)

L2  Windows 7 clone  (logical)

L3-L6 perhaps (other logicals)

 

And with those two attempts, I only tried to get the P3 clone to work without cross-linking.

Edited by sir_bootalot, 18 February 2013 - 05:18 PM.

[Wonko the Sane]

Yep now it is readable/understandable.

BUT, we are still (more or less exactly) here :

"Cloning" over and over the same Windows 7 install on different volumes on the same disk (though possible) is not the easiest thing in the world.
It seems to me like (at the two opposite extremes) the "first install" from which the clones are made can be either a "plain, simple, install with no third-party add-ons or programs" (and in this case it makes much more sense (easier and probably also faster) to do several installs from original source, or it can be a "fully configured", up to the smallest detail install, in which case it makes little sense having several copies (identical), if each of them should late be tweaked to "differentiate" it from the other ones, again possibly doing several installs might be easier and faster.

About the steps to "image" or "clone" (they are not exactly synonyms and there are all shades of gray) or "backup" and to restore the whole system or single parts/files/partitions/volumes it is by itself another whole topic.
There are n tools, some with same functionalities/more approaches, some with only parts of them (and that need to be "assisted" with complementary steps) it all depends on WHAT exactly youwant to do.
As an example if you use a "forensic sound" or "dd-like" image, it is - strangely enough -  an EXACT image and you need NOT to carry any particular "fixing" step.
Other solutions may or may not need them.

I am (still) greatly perplexed by the "cloning" procedure that you used (and that you did not specify in detail), I would again suggest you to make several INSTALLS, at least one on P2 and one on P3 and one on L1, this approach has surely worked in the past and there is no reason why it shouldn't work for you and on your setup.


Wonko

[sir_bootalot]

Hmm, let's wait if cdob has an idea how to fix up that cross-linking problem of clones.

 

So I have a few alternatives how to progress from here:

 

1) A solution for cross-linking problem will appear. Then I need only one base install. I'm sure this can be done somehow. I just don't understand Windows registers and startup procedure well enough.

 

2) Using Easus Todo (or some other cloning program, instead of fsarchiver that I used above) might fix things. But I would rather use an open source 'offline' program. Easus is supposed to have some functions like making the register changes needed when cloning operation systems to other partitions, but will it fix up things enough for my purpose, is yet to be seen. And it's a function limited free version of a commercial program. If I'm gonna buy the commercial version, prolly must pay for every computer separately, that I'd use it with.

 

3) Several Windows base installations, like you suggested

 

I'd prefer the route 1). I hate circumventing problems instead of solving.

Edited by sir_bootalot, 18 February 2013 - 06:39 PM.

[Wonko the Sane]

I'd prefer the route 1). I hate circumventing problems instead of solving.

Sure , but till now you did not attempt to solve the problem, you simply ignored it and the problem retaliated by presenting itself in all it's might! 

 

Here :

http://www.msfn.org/...-easily-the-os/

 

Just for your interest Cannie tends to make extremely long tutorials (and some of the steps may be unneeded or simplified ) BUT they are usually VERY well written and detailed , you might want to spend some time on the above, actually if I were you I would print it on paper so that you have it handy.

 

Wonko