26 replies to this topic

[tstaddon]

Hi

 

Suppose I have 16 different devices to image back to the original shipping condition and only one USB3 hard drive. For each make and model of laptop/desktop I have one unit still in the factory condition so I can run the builtin recovery media generation tool.

 

Some of them spit out ISOs which I can work with, but others generate a bootable pen drive - for example a Dell M4700 laptop using the Dell Recovery Manager tool can create a bootable pen drive with the folder structure is as follows:

 

Root directory:
  02/11/2006  07:53           438,840 bootmgr
  24/03/2014  09:22               206 ResSys.ini

\boot:
  18/09/2006  19:26           262,144 bcd
  18/09/2006  19:45         3,170,304 boot.sdi
  18/09/2006  19:27             1,024 bootfix.bin
  18/09/2006  19:27             2,048 etfsboot.com

 

\boot\fonts contains 5 Truetype fonts.

\Dell:
  24/03/2014  09:22         3,170,304 boot.sdi
  27/05/2009  19:40         8,591,509 WBF.wim

\Dell\Image:
  24/03/2014  09:22                63 catalog.ini
  24/03/2014  09:33     7,985,412,918 Factory.wim

\sources:
  24/03/2014  09:22       201,016,417 boot.wim

But this particular recovery image is tailored for only a few variations of Dell Precision laptops. So I need another pen drive for a Compaq CQ56. And another pen drive for a HP Elitebook. And another one for a Sony Vaio. And so on.

 

RMPREPUSB has a "drivetofile" option and it got me thinking...

 

Is that drive backup mountable and bootable, and if it is then what's the procedure to convert a physical pen drive into a bootable image on the larger HDD with a menu option in the boot loader?

 

And if that isn't possible, what's the simplest alternative?

 

Cheers

[steve6375]

Why not use Ghost or Clonezilla or any other imaging tool?

I don't quite understand what you want to do...

[sbaeder]

While to you (and me too), just making a bootable recovery tool that can make/restore a drive seems a simpler approach, but...

 

*IF* you wanted to leverage the MFG's recovery process and build recovery "images", couldn't you just convert the fash image to a bootable ISO and then use something like easy2boot to put all those ISO's on a single USB HDD?

 

However, this will only restore the OS, and not the complete DISK (i.e. the recovery partition that came with the machine)...Taking a FULL IMAGE of the hard drive ensures you can set it back to the original state - especially if you make the image before you even power the machine on for the first time.

[steve6375]

In Easy2Boot there is a sample .mnu file, CloneZillaBackupRestoreHDD0.mnu, which is for use with a Clonezilla LiveCD ISO. So by using say, an E2B 2TB USB HDD, you can go round to any machine and do full drive 0  backups and restores quickly and easily. However, you can't restore to a smaller system hard disk as it uses an image backup.

Hence, why I asked exactly what you are trying to achieve...

[tstaddon]

I've been using Ghost since before Norton bought it, and already have used Clonezilla and RMPREPUSB but it's a question of curiosity. I'd rather not buy lots of 4GB pen drives just so I can restore a load of old 4GB RMPREPUSB pen drive backups from a USB3 HDD.

 

Since I do have a USB3 HDD with those backups already sat on it I thought, are those backups like WIMs or ISOs, i.e. could I chainload an RMPREPUSB backup by presenting it as a "fake" hard drive in much the same way you can chainload an ISO image.

 

For me, that'd be the killer feature. One physical disk, many mountable pen drive images.

[steve6375]

You could try this

 

1. Take one of the 4GB USB flash drives

2. Use RMPrepUSB and install grub4dos to the MBR

3. Press F4 in RMPrepUSB and add a one line menu of    chainloader /bootmgr

4. Check it still boots

5. Press Ctrl-M in RMPrepUSB and make an ISO file from the USB flash drive

6. Copy the ISO to your E2B USB HDD drive \_ISO\MAINMENU and rename it to  a .isoPE01 file extension

7. Test the E2B HDD USB drive together with an E2B WINHELPER Removable flash drive to see if it works

 

cheers

Steve

 

P.S. I haven't tried it...  

[tstaddon]

Right, with you.

 

A pen drive boots fine with or without GRUB Bootloader. But I was getting this message whenever I used CTRL-M, regardless of how big or small the pen drive is or what's on it:

Make D:\Personal\Media\ISO\OEM from Recovery source files
using grldr as boot file (ISO volume name=Media\M4700)

Recovery does not exist!
Press any key to continue . . .

Then I sussed out it didn't like spaces in the folder names (The folder path is actually "D:\Personal\Media\ISO\OEM Recovery").

 

When I did get it to run, by renaming the folder, it reported this error:

mkisofs: Value too large for defined data type. File F:/Dell/Image/Factory.wim is too large - ignoring

So the resulting file consisted of this:

 

25/03/2014  10:27       380,254,208 m4700.iso

 

Minus the 8GB WIM. In other words I think your approach might work fine for my legacy recovery partitions (XP/Vista based) or split .swm files, or GHOST based recovery setups, but I just don't see it remaining a viable solution for Win8 recovery media in the future. I already have one system where the factory restore image contains Windows 8.1 and Office 2013 Home And Student, the recovery system is over 16GB and the factory WIM is over 8GB. The only way you can even create it is to plug in a pen drive which it completely wipes when creating the image. You get one shot only to create the recovery media; if it goes wrong halfway through it'll say "you've already done this". That's the use case for what I'm doing.

 

So there are limitations with the ISO approach that are going to become more and more obvious as newer systems come out, so if the full pen drive backup (DriveToFile) can create a .BIN that can be booted as-is I'd rather do that to be honest.

 

Even if that seems like a monumental waste of disk space.

 

Thinking about it - I can already buy a quality 500GB USB3 hard drive cheaper than buying a 4GB, 8GB, 16GB, 32GB and 64GB pen drive for the purpose of creating space-saving ISOs for all my legacy recovery images.

 

On that basis, given the choice between creating an uncompressed 32GB .BIN file for 20GB of real disk data with one click in RMPREPUSB, or creating a trimmed down ISO that needs additional effort to present >8GB files as if they were inside the ISO when they aren't, I'd rather waste the disk space and have the .BIN.

[tstaddon]

Ah. Example of a system with a huuuuge recovery WIM and the kind of issues people run into when trying to recover from them:

 

http://forums.comput...?threadID=74915

 

Long term: I will want a big bootable USB3 HDD (not a pen drive) to just have a boot menu where I can select

 

"Toshiba WT8-A-102 UEFI bootable recovery pen drive"

 

To save me the inordinate faff of having to follow the convoluted process Toshiba have come up with.

[steve6375]

Instead of mkisofs, try oscdimg. Download it from a GetWAIK and just add the oscdimg.exe to the RMPrepUSB application folder and try Ctrl+M again.

 

The other approach may be to use the grub4dos partnew command

 

1. Use RMPrepUSB - Drive->File on a 4GB stick, but use P1 as the start and end position on the USB stick - this will save the sectors starting at the PBR and will skip the MBR and reserved sectors

2. Copy the .img file to \_ISO\MAINMENU\MNU folder  (e.g. test.img)

3. Make a .mnu file on your E2B USB HDD drive at \_ISO\MAINMENU\MNU\test.mnu

 

title test Recovery image

partnew (hd0,2) 0x0 $HOME$/test.img
root (hd0,2)
chainloader /bootmgr || chainloader +1

 

 

This may cause problems when you reboot E2B as it will have a 3rd partition.

Note that no checking is done that partition 3 is empty or unused by this menu - so make sure you boot drive does not have a 3rd partition with valuable data in it before you test it!

 

 

P.S. You could make a 'clear 3rd partition menu' in case you needed to boot linux's with persistence which use a .mnu file which check the 3rd partition is free

title Clear PTN3
partnew (hd0,2) 0 0 0 0
configfile (md)0xa000+0x50 || configfile /menu.lst

[cdob]

mkisofs: Value too large for defined data type.

Instead of mkisofs, try oscdimg.

Yes, oscdimg is the manufacturer tool as for a bootmgr based PE.

Big file support has been added in 2006 to mkisofs. Can you use a current version?

mkisofs with storage optimization cdrtools-3.01.a23-bootcd.ru
http://cdob.reboot.pro/

Be aware the mingw version is picky and expects a folder name: d:\
The cygwin version works at d:

[steve6375]

@Cdob

I tried the new versions and both give error messages about non-existent folders/files - see below:

 

C:\Program Files (x86)\RMPrepUSB\QEMU>mkisofs -iso-level 3 -D -quiet -force-uppercase -volid "GRUB4DOS"  -b grldr -no-emul-boot -hide boot.catalog -o C:\temp\test.iso E:/
mkisofs: No such file or directory. Non-existent or inaccessible: E:/..
mkisofs: No such file or directory. Non-existent or inaccessible: E:/..

Volume in drive C is 2TB_PTN1
Volume Serial Number is 7C4A-3DB1

Directory of C:\temp

25/03/2014  18:38    13,178,144,768 test.iso
               1 File(s) 13,178,144,768 bytes
               0 Dir(s)  1,003,687,002,112 bytes free

Finished!

 

 

 

I tried E:, E:\ and E:/  all gave error messages...

Any way to avoid this?

[Wonko the Sane]

Try "E:/" (inside double quotes) or E:/../ or E:\..\

 

Wonko

[cdob]

I tried the new versions and both give error messages about non-existent folders/files

This are more warnings, cdrtools are *nix application by design, havn't never ported to windows fully.
At least the ISO image is created.
 

Any way to avoid this?

Supported is a *nix path style /cygdrive/? by cygwin. Try

mkisofs -iso-level 3 -D -quiet -force-uppercase -volid "GRUB4DOS"  -b grldr -no-emul-boot -hide boot.catalog -o C:\temp\test.iso /cygdrive/E

[steve6375]

Thanks :-) that works a treat!

[Wonko the Sane]

This was related (and it works) for the mingw version:

Try "E:/" (inside double quotes) or E:/../ or E:\..\

 

 

Wonko

[steve6375]

This was related (and it works) for the mingw version:

Wonko

OK thanks, it didn't work for cygwin version which is what I tried. I have updated RMPrep with a new cygwin version now and changed the script to allow paths with spaces (v2.1.718).

[Wonko the Sane]

Reality check:

Cygwin version:

mkisofs.exe 366.080

cygwin1.dll 1.109.385

in .7z 610.583 bytes

 

mingw version:

mkisofs.exe 371.200 -> in .7z 149.923 bytes

 

Unless there are some different features (something missing or not working) in the mingw version, it seems a winner.

(you were the one whining about the increased bandwidth of your site, remember )

 

Wonko

[steve6375]

There was an issue previously with mingw version not being able to create >4GB files, so I stuck with cygwin as I didn't know if it was fixed or not...

[Wonko the Sane]

There was an issue previously with mingw version not being able to create >4GB files, so I stuck with cygwin as I didn't know if it was fixed or not...

Yep , but cdob's versions should be the SAME source code compiled in two different ways.

 

Wonko

[cdob]

There was an issue previously with mingw version not being able to create >4GB files, so I stuck with cygwin as I didn't know if it was fixed or not...

This was fixed by TumaGonx. Big files are supported at mingw.
http://opensourcepac...p/cdrtools.html

There is schily-cdrtools-3.01a23.7z currently. Good: no message "No such file or directory."
Drawback: -force-uppercase and duplicates-once are not supported.
And neither hardlinks, should be ignored

This version is a new winner. win32 file size 376 kb.

With this version

mkisofs -iso-level 3 -allow-multidot -no-iso-translate -relaxed-filenames -allow-leading-dots -N -l -d -D -volid "GRUB4DOS" -boot-load-size 4 -b grldr -no-emul-boot -hide boot.catalog -o C:\temp\test.iso G:\

This result uppercase names.

-boot-load-size 4 is recommed for a strange BIOS. By default the whole grldr file is loaded by eltorito boot, however some BIOS fails that way. grldr supports -boot-load-size 4 to supports such BIOS.

Overall it's uclear, if boot.wim routines reads a big ISO file.

[tstaddon]

Tsk. I ask a simple question...

But seriously: thanks everyone for this project. I'm tied up on something else for a few days but as soon as I get the time I'll have a play with some more bleeding edge kit.

[cdob]

There was an issue previously with mingw version not being able to create >4GB files, so I stuck with cygwin as I didn't know if it was fixed or not...

The mentioned cdrtools-3.01.a23-bootcd.ru mingw version does support >4GB files.
The message "No such file or directory." is not displayed.
And -focre-uppercase and -duplicates-once does work. No hard links support, use duplicates-once instead.

[tstaddon]

OK, I'm having a bit of a brain fart. Here's what I get if I ctrl-M on a pen drive with Grub Bootloader installed and where menu.lst just contains chainloader /bootmgr:

 

To use oscdimg for WinPE ISOs, add oscdimg.exe to the RMPrepUSB\QEMU folder...

USING MKISOFS

WinPE \BOOT\BCD folder detected
WinPE \SOURCES\boot.wim file detected
WinPE \bootmgr file detected

Make a grub4dos multiboot ISO or a WinPE ISO?

   Y = Force uppercase filenames, non-Joliet

Make a WinPE ISO (Y/N) :

 

This Confuses Me. The entire pen drive consists solely of filenames in 8.3 format except for a folder for 3rd party apps and drivers, like Ext2Fsd-0.51.exe. I want to create a bootable ISO of a WinPE recovery pen drive created by the Dell recovery media, which only had Grub installed on it because I was given the impression this was needed in order to create a bootable ISO from a pen drive.

 

What actually happens if I choose Y, and what actually happens if I choose N?

[steve6375]

Ctrl_M is for grub4dos bootloader USB drive not grub.

 

If you choose Y then the ISO will be made with a different mkisofs command which forces files to uppercase. This is usually best for WinPE drives which boot from a flat file system like yours.

The batch file is in the RMPrepUSB folder (press F3 in RMprepusb to see it) under \QEMU\makegrub4dosiso.cmd

 

If you are making flat file PE ISOs, and are having problems with mkisofs, just copy the Microsoft oscdimg.exe file to the QEMU folder and the script will use oscdimg instead.

 

P.S. Use the latest version of RMPrepUSB 2.1.718

[tstaddon]

Sorry, yes I meant Grub4DOS.

 

Makes sense to me now! I've created an ISO for the Dell recovery system now and shuffled that onto the HDD. The HDD is an existing one with tons of pre-Vista recovery setups already on it from older systems. They all work from Grub4DOS, and I'm just adding this to the relevent lst:

title Dell M4700 Recovery ISO (Experimental)
find --set-root /iso/M4700_W7x64.iso
map /iso/M4700_W7x64.iso (hd32)
map --hook
chainloader (hd32)
savedefault --wait=2

And now to test... If this works then effectively I'll be able to continue using the same approach for direct back-to-factory-restore without having to use forensic disk imaging.