28 replies to this topic

[Wonko the Sane]

For the record, there is NO §@ç#ing *need* to "install" grub4dos.

You can, besides writing grldr.mbr to the MBR or making a VBR invoking grldr (which is - I presume - what you mean by "installing") load it from BOTH NTLDR (which won't be used in a PE 2/3/4/5) and BOOTMGR (which is needed for a PE 2/3/4/5).
The "installation" (which is NOT at all an installation) consists in two steps:

• copy to the root of the device a grldr (and it's menu.lst)
• create in the root of the device a file named BOOT.INI with these contents:

[boot loader]
Timeout=30
default=C:\grldr
[operating systems]
C:\grldr="grub4dos"

Of course you are perfectly free to call the above procedure "installation" and to consider it "difficult" or "advanced", or "another level of complexity".

Same goes for "differential testing", no matter what you believe (and how much right you are in your beliefs) the differences between running a tool in a "full" OS vs. running it in a PE (as long as it actually works in the more limited PE environment) won't turn a turtle by magic in to a hare.
For the early classification between "slowish" and "fastish" we could use even VM's, like Qemu (to be able to test a "pure" IDE interface), or another one (to be able to test a simulated SCSI in VMWare or Virtualbox for a SATA one) with a "full" OS installed in it, since we are going to measure "relative" differences in speed, it will be as effective as that.
BTW, what I am telling you is that - at least in this preliminary phase - it makes NO sense whatsoever to attempt imaging anything bigger that (say) 2 times the size of the cache of the hard disk, and definitely attempting to image a 1.5 Tb disk would be foolish and unneeded.




Wonko

[misty]

For the record, there is NO §@ç#ing *need* to "install" grub4dos...

I am aware of some of the different methods of booting grub4dos - thanks to a number of your posts over the years and also the Grub4Dos guide.

Whilst the term installing may not be the most accurate - using the method described here (also as installing) is the method I still use - well something similar anyway. I believe that there are now far easier ways to write the Grub4dos code to the VBR/PBR - including Clonedisk?

I accept that writing Grub4dos code to the VBR is unnecessary, it's just always been my preferred method.

I take your point on the merits of virual environments/disks for testing comparative speeds of different imaging software and will have a think about when and how to best do this. I'm still planning on purchasing a nice shiny new 2 TB hard drive as I'm running out of storage space at home as I'm a hoarder by nature. This new drive will provide me with enough storage to also test imaging the 60GB SSD drive I mentioned previously. Something I have been planning to do for a number of months now

Regards,

Misty

[Wonko the Sane]

Just for the record the way I described in my previous post is "outside" the Guide and is actually the least known (and i presume also less used) method/approach.

 

It makes uses of a "side effect" of BOOTMGR which, besides accessing the \boot\BCD, also accesses the BOOT.INI (and discards each and every entry leading to an ArcPath BUT displays on screen together with the "normal"  \boot\BCD entries whatever entries point directly to a file - which normally in the original MS provisions would be a copy of a VBR).

 

It was found out, by mere chance, here, by ilko :

http://www.msfn.org/...ager-installer/

 

All in all it provides (for *anything* using BOOTMGR in the boot process) the least "intrusive" way to load grub4dos/grldr.

 

Wonko

[misty]

Wonko - I hadn't realised from your previous post that the boot.ini menu was automatically parsed by bootmgr. Thanks for the more detailed explanation - it's nice to learn something new