Running TBWinRE/TBWinPE on UEFI without a Boot Disk

Check if IFW has the log option enabled. Might be trying to save to another location if you don't have it set to the default.

RunScript will only run the command once, but you can copy it out or create another script file so you can run it again easily while testing. Could remove /uy also until you get it right so it won't actually do the restore. Any changes you make while booted to TBWinRE won't be kept so no worries about playing with the file.

Or you could just copy the command and paste it in a Command Prompt and tweak it there.

 

When the Restore operation failed I run manually a Validate operation and this is what the log said:

Code:

--------------------------------------------------------------------------
[25/03/2016 19:16:50] Image for Windows (x64) 2.99-00
[25/03/2016 19:16:50] Starting ...
imagew.exe /v /f:w0@0x6:"\win81x64"
[25/03/2016 19:16:50] Validating: OS Partition (04) 100412 MiB NTFS
[25/03/2016 19:16:50] From: w0@0x6:\win81x64.TBI
[25/03/2016 19:18:26] Operation Completed with Error Code 0
[25/03/2016 19:18:26] Stop

I think partitions (01), (02) and (03) are missing no?
I guess the Backup operation did not include those three partitions in the first place. Hence that's the cause of error in Restore operation.

 

Confirmed.

I did a backup operation from IFL on a USB stick and included partitions (01) (02) (03) (04) in the win81x64.tbi file.
Next I run Restore.cmd and it successfully performed the operation.

So again, the Backup.cmd script did not included the 4 partitions just the 4th one, Windows partition.

Something's wrong with the syntax, I guess:

Code:

/b /uy /um /d:w0@0x4 /f:w0@0x6:"\win81x64" /v /comp:14 /log:0 /rb:4

 

@MudCrab

I want to apologize a lot. My mistake, my bad bad lol
Instead of selecting "Include RunScript.cmd" I was selecting "Include InitScript.cmd" during TBWinPE/RE Builder.

My vision is kind of deteriorating lately

Trying again in this very moment...

Edit: That didn't work either. LOL

 

You would need to add the other partitions to the backup:

Code:

/b /uy /um /d:w0@0x1,0x2,0x3,0x4 /f:w0@0x6:"\win81x64" /v /comp:14 /log:0 /rb:4

 

Yup, thanks. I suspected it from the beginning but wasn't that sure.

I'll test it later tonight.

 

You could also remove the /log:0 option. Then you can look at the log if the operation fails. The log file will be lost on reboot so normally there's no reason to disable it.

 

Going to try in a few. I believe this time is not going to fail whatsoever, pretty sure it was the backup cmd line which didn't include the 4 partitions. However if it fails again then I'll enable logging.

 

Yes!!! As expected it worked now!
Both operations processed 4 items (4 partitions) as intended.

@MudCrab
Thank you very much for this one. You're one of the best.

 

Now I'm going to test setting D:\TBWinRE Recovery in C:\TBWinRE Recovery. On D: drive there's still the chance some distracted user could mess with that folder, even worse delete it.
As I intend to use a static configuration I don't believe there's need to update anything in the future.

 

This type of build is way better and faster than booting from a USB stick. This solution saves you the pain of entering machine's setup and adjust to boot from the pendrive and adjust it back again to pure UEFI, etc.

 

Is it possible to add two more parameters to restore cmd line for the following funtions?

1. Write Standard MBR Code
2. Restore First Track.

 

Those were there already (unless you removed them): /t /rft

 

Oh yes, sorry I missed them. Thank you.

 

Ok, again as expected, it worked. Flawlessly.

Again thank you @MudCrab

 

You're welcome.

 

MudCrab,

I like your method and I've adapted it slightly for my use. Do you know of a way to use IFL for auto restores (no USB media) with UEFI systems? Tom Pfeifer suggested trying EasyUEFI which worked but caused BIOS issues.

 

I was wondering just the same thing a few days ago.
Thanks for bringing it up.

 

If you want to keep the system booting normally (like the TBWinRE method here), I haven't seen a usable method for that in what I read and tried myself. In my testing, UEFI booting still seems quite unstable and problematic -- even just booting Windows, in some cases.

I'm curious too, though. If you get it setup as a boot device, that might work. Maybe on a secondary disk if it doesn't work on the primary disk.

 

MudCrab,

I recall we discussed EasyUEFI in February this year and it was unsatisfactory. There have been a few updates since then and I just tried the latest version, ver 2.7. It works, no problems at all, so far.

An IFL UFD was created with the "Run List-Run Scripts Listed in scriptslist.txt" option. The UFD was booted and scripts were created in the Scripts folder. The UFD partition was copied (with IFW) to Free Space on my third HD (test computer) and resized to 100 MB. EasyUEFI was installed and the Boot order set up. To choose the impending IFL restore I used a script to edit scriptslist.txt and run EasyUEFI. For example...

Code:

@echo off
CD /d %~dp0
set TBOSDT=C:\Program Files (x86)\TeraByte Drive Image Backup and Restore Suite\TeraByte OSD Tool Suite Pro\win
"%TBOSDT%\tbosdtw.exe" type.tbs
echo.
pause
start "" "C:\Program Files\EasyUEFI\bin\easyuefi.exe"

Code:

sub main()
  ext("open fs 0: 2 0x03")
  ext("del file 0:\scripts\scriptslist.txt /y")
  ext("SET TEXTLINE 0:\scripts\scriptslist.txt ^"Restore and reboot.tbs^"")
  printl("")
  ext("type 0:\scripts\scriptslist.txt")
  ext("close fs 0:")
end sub

In EasyUEFI choose a One-time boot for IFL and then Power, Reboot.

Edit... the third HD is a MBR disk. The IFL partition has had the drive letter removed.

 

@Brian K
Could you please elaborate your method lil bit more? All prerequisites needed and all steps to successfully understand it. In other words, elaborate for non-experts like me.

Even better, I'm going to open a new thread for it. I think this is a good name, is it?
Running IFL on UEFI without a boot disk

 

OK, good name.

 

Okay, done.
https://www.wilderssecurity.com/threads/running-ifl-on-uefi-without-a-boot-disk.389002/

 

Code:

Possible values for VolumeName along with current mount points are:

    \\?\Volume{9e92db18-e845-11eb-b906-806e6f6e6963}\
        C:\

    \\?\Volume{9e92db19-e845-11eb-b906-806e6f6e6963}\
        D:\

    \\?\Volume{751ff544-1b13-11ec-b226-806e6f6e6963}\
        E:\

    \\?\Volume{751ff545-1b13-11ec-b226-806e6f6e6963}\
        F:\

Does "posible values" mean the program mountvol.exe is not 100% certain of it?

If a volume is resized does it lose its current GUID?
If a volume is added/removed to the disk are the current volume GUIDs changed somehow?
Are volume GUIDs more reliable to work with on this TBWinRE + IFW context?


Edit:
It occurred to me today to run a Strelec's WinPE then run mountvol.exe and oddly it showed different GUIDs for all the same volumes:

Code:

\\?\Volume{81460f84-0000-0000-007e-000000000000}\
    C:\

\\?\Volume{81460f84-0000-0000-00d0-dd4908000000}\
    D:\

\\?\Volume{81460f84-0000-0000-0082-8fca23000000}\
    E:\

\\?\Volume{81460f84-0000-0000-0076-a2c224000000}\
    F:\

I believed GUIDs were stamped on every partition at disk level, OS independent.

 

Mr.X,

No and no.

IFW won't change the GUIDs unless you select "Change GUID" in the Options screen.

I suggest you run TeraByte's partinfo. Then click File, Export to Text File. You will see the...

Device, Type and Partition GUIDs.