murphy78 DiskPart and Apply Image Script

Discussion in 'Scripting' started by murphy78, Apr 2, 2014.

  1. Flipp3r

    Flipp3r MDL Expert

    Feb 11, 2009
    1,962
    904
    60
    I think it should remain just a batch file. It makes it easy for people to customize it for their personal needs.
    I use AutoIT as well & it's terrific. Some antivirus packages complain about these compiles though. Some even auto delete.
    True that since we are in a WinPE environment this is unlikely to be an issue.

    With respects to recovery, there's a fantastic project found here: ANARETHOS-RECOVERY-TOOLS-with-MEDIA-CREATOR

    Anarethos has provided full source & AutoIT is in use.

    I use a script very similar to Murphy's to apply my images.
    Once they are complete I use Anarethos Tool to create Recovery (Mainly for win7)...

    Backup scripts/util is always good though. Perhaps a new tool?
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  2. murphy78

    murphy78 MDL DISM Enthusiast

    Nov 18, 2012
    7,394
    11,615
    240
    The good thing about scripts is that they are easy to edit, like you said.
    I'm not really sure I'd have the patience to tinker around endlessly with a fully-fledged gui program.
    Scripts are pretty straight-forward and you don't really have a problem where changing one tiny section will break other things.

    I guess that's because scripting is very linear, where most programs are very object-based.
    Programming is still a better option, if you can do it.
    The problem, I guess, is that there's not really any money to be had in this sort of thing.
    Even if you made a little tool with a donate button, you'd be spending way more money on electricity and bills than you'd ever get back for this sort of thing.

    I guess if you were already pretty good with simple programming, then it wouldn't be much of a big deal, but I've avoided programming for the last 17 years.
    I get terrible headaches if I read too much. I am legally blind in one eye, but it's not completely gone; it's just extremely blurry. Guitar strings FTL.
     
  3. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    @murphy78 I would also suggest that you modify your script to ask about drivers location if needed and if they wish to copy $OEM$ folders earlier in the script. To give the install recovery image process more of an unattended process once all options are selected. This way users do not need to wait till just before the Saving Image portion to make those selections. ;)

    Is there any specific reasons that this would not work on a vista install? I have not tried it yet. But I notice in your instructions that it works in boot.wim files for Windows 7 and up.

    I have tried using the script with the option to not format drives but so far I have been unsuccessful. I will run some more tests and see if I can figure out what I am doing wrong.

    Great work BTW!!
     
  4. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    OK... I think a lot of the issues I have had in the past are due to an incompatibility with your script and the easy2boot usb scripts.

    First issue is that to boot an iso with e2b a loadiso.cmd needs to launch just before windows setup loads. This is performed by the autounattend.xml. Without loadiso.cmd then windows setup can not see the install.wim file on the disk.

    murphy78's Menu.cmd is launched before loadiso.cmd... so here is the first issue. Menu.cmd can not see the install.wim.

    So I modified Menu.cmd to be executed instead by the autounattend.xml just after loadiso.cmd. Which works.

    The next issue is caused by I think loadiso.cmd setting the iso drive letter as Y:\

    Because in Menu.cmd the drive letters it uses are set to specific drives. So I think this is an issue.

    I modified the Menu.cmd to change all instances of the Y drive to R drive. I thought I had finally fixed it to work with e2b... but then I have the issue again at "Saving Image" where it gets to 2% and fails.

    I am not sure why it is failing. All of the drives that are needed seem to be created just fine. The R:, W:, Z:. The Y: drive is the iso and install.wim is recognized by the script. The x: drive is the boot drive. I did notice it is running out of space. Is it possible to run a command to make the x: drive larger?
    The z: drive is the OS partition. and it is copying windows files to it as it should.

    What I want to accomplish is being able to run this from the usb drive without having to compile it within the boot.wim of the windows installer iso. This way I am not adding almost 200 MB of data to each iso. This will save a lot of space on my e2b drive since it has many iso's that it uses.

    Here is a link to the modified files I have created:
    http://techware.net/temp

    I have placed a Readme.txt in the archive with details on how to use this modified version.
    My dism.log file is in the archive as well.

    I hope you will have time to look into it for me to show me what I am doing wrong. Thanks! :worthy:
     
  5. Flipp3r

    Flipp3r MDL Expert

    Feb 11, 2009
    1,962
    904
    60
    There's no need for easy2boot or iso's. Murph's script works with .wim & .esd...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  6. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    The modifications I made are just a way to make it simpler to implement and more universal. There are many different ways to do things. I disagree with you Flipp3r. ;) I don't think there's nothing wrong with figuring out other ways to implement it. The more universal it is the more it can grow as well. My mod is 90% working. I know it's gotta be a simple fix... but I'm stuck.

    On my usb stick I'd like to choose whether I want to use Murph's script or install normally. At this point I am so close it's killing me. LOL!
     
  7. Flipp3r

    Flipp3r MDL Expert

    Feb 11, 2009
    1,962
    904
    60
    #47 Flipp3r, Jun 27, 2014
    Last edited by a moderator: Apr 20, 2017
    In your dism.log there's a lot of
    Code:
    There is not enough space on the disk.
    There is also reference to capture:
    Code:
    DISM.EXE: Executing command line: dism  /capture-image /imagefile:R:\Recovery\install.wim /capturedir:Z:\ /name:"Windows Recovery Image" /description:"Windows Recovery Image" /compress:max /checkintegrity /verify
    I'm not sure about your drivers letters either. Wouldn't W: be for your OS? R: for recovery & S: is normally system (for a bios/legacy/mbr install).

    I'll have a look at menu.cmd later & try follow it through...
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  8. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    In the modded script I changed the Y drive... which is what the script had set as the Recovery drive to the R drive. all of the other drives are the default that murphy78 coded. That is the code I narrowed down as the issue myself as well. But the R drive has 30 GB of space on it in my most recent test. I started my tests at 10GB and moved up to 30 GB. It doesn't seem to matter what size I make it... it has been failing a 2%.

    When it fails I check every drive and they look to be correct. The W drive seems to only be used to copy the WinRE file to it. I think in my tests it isn't really used since I have never modded the WinRE file. The Z drive is the big partition. In my tests it is about 260+ GB. The Y drive seems to be the drive given to my Windows Setup ISO (which is read only). The G drive is given to my USB Stick. The X drive is the boot.wim drive. Which doesn't have much space on it at all... and when the Saving Image fails I do notice that my X drive is full.

    All I can think is that it somehow is failing because of the full X drive... but the command you posted does not specify the X drive for anything. Even the dism file resides on the G drive.

    I can manually copy files to the R drive without an issue. But if I try to manually run that command we found... it still does not work.

    Thanks for helping! hopefully we can narrow down something. I know it has got to be something obvious that I am just not seeing.

    G: USB (Can be different. Depends on your system setup)
    R: = Recovery
    W: = WinRE
    X: Boot.wim
    Y: ISO (Could be different. Depends on your system)
    Z: System
     
  9. murphy78

    murphy78 MDL DISM Enthusiast

    Nov 18, 2012
    7,394
    11,615
    240
    #49 murphy78, Jun 27, 2014
    Last edited by a moderator: Apr 20, 2017
    (OP)
    If you're just running out of scratch space you can try modding the bootable index with dism to use more scratch space.
    Code:
    dism /image:c:\mount /set-scratchspace:512
    I think 512 is max. It just sets the x drive's free space to 512 instead of the default 32 megs.

    I can't think of why you'd be running out of space though... capturing the recovery image doesn't use x-drive space.
     
  10. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    Yeah I'm not sure why it is either. I'm gonna run more tests and figure out whats writing to X drive that shouldn't be. Thanks!
     
  11. Flipp3r

    Flipp3r MDL Expert

    Feb 11, 2009
    1,962
    904
    60
    I've forgotten about scratchspace. I remember we talked about it back when there was corruption/failure in wims.
    In WinPE 3 I did set it to 512 but 512 is now the default with the current PE. What's New in Windows PE
    512 is max:
     
    Stop hovering to collapse... Click to collapse... Hover to expand... Click to expand...
  12. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    After another test it isn't the X drive for sure. It isn't full. None of the drives are full and they all seem to have plenty of space on them. So it must be something else. :( I'm gonna keep working on it to try and narrow it down. I hate issues like this. Makes me want to punch the laptop! LOL! I know the problem is staring me in the face! Haha!
     
  13. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    I think I found the problem!! The issue is caused by Microsoft! It is a bug in DISM for Windows 8. I'm guessing since I have a USB drive connected it is trying to use it automatically for the scratchdir (Although it has almost 4GB free). Or one of the other drives... or maybe it is trying to use X drive and X does not have enough space (20MB free)... So I need to specify another unused drive to use. I manually sent that command with /ScratchDir:W:\ at the end of it... and it started working! So... somehow in the code we need to place /ScratchDir:[FreeDrive]:\ at the end.

    I'm wondering if W would be a safe bet since the code auto creates it and it is not used at the time anyways?
     
  14. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    OK... so I am not going to specify the W drive as the ScratchDir... I am going to set it to Z. I didn't think I could use Z since the command is using Z to create the install.wim onto the R drive. But I tried it and it seems to be working. murphy78 does not seem to be creating the W drive all the time... so I don't want to have to force creation of any other drives if I don't have to.

    I also have created a simple Menu.exe with autoit that recognizes what type of Windows Setup and what OS Arch we are booting into. Then it copies the correct choice.exe and choice.exe.mui to the X:\Windows\System32 and en_US directories. Right now I have built in WIN_7 X86/x64, Vista x86/x64 and I will test again with WIN_8 if I need to use the choice.exe from a Windows 8 disk. Also Menu.exe launches the correct Menu.cmd file pertaining to x86 or x64.

    I will post my new version of files when I have completed all my tests. :)
     
  15. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    Hmmm... looks like using the Z drive for the ScratchDir is not a good idea. I think it messes up booting to that drive. So I am trying to use the R drive instead.
     
  16. murphy78

    murphy78 MDL DISM Enthusiast

    Nov 18, 2012
    7,394
    11,615
    240
    You might be misunderstanding what a scratchdir does.
    Scratchdir is the directory that cab files get extracted to when the servicing parses the contents of a package.
    It doesn't affect any other dism functionality.
    It will only do something in combination with dism when you do add-package or remove-package and specify a cab or msu file.

    If you don't specify, it will automatically use %windir%\temp\somehexadecimalname

    It won't magically target a different drive. If yours is trying to use another drive, you likely have a problem with your diskpart assigns or other scripting
     
  17. murphy78

    murphy78 MDL DISM Enthusiast

    Nov 18, 2012
    7,394
    11,615
    240
    Maybe it has some sort of automatic allocation or something when it detects a certain amount of ram, but in my experience, it's always seemed to list 32mb when I create a winpe5.1 image.
     
  18. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    It is 32mb on the X drive. But I can't change the size of it. It says it can not because the X drive is considered the System Drive. So I am trying to figure out a way to use a different location for it. Everything acts like it is working until the computer restarts. Then the hard drive doesn't boot for some reason.
     
  19. murphy78

    murphy78 MDL DISM Enthusiast

    Nov 18, 2012
    7,394
    11,615
    240
    #59 murphy78, Jun 28, 2014
    Last edited by a moderator: Apr 20, 2017
    (OP)
    You don't change it while using it. You mount the bootable index and do:
    Code:
    dism /image:c:\mount /set-scratchspace:512
     
  20. Proph

    Proph MDL Junior Member

    May 2, 2007
    56
    64
    0
    #60 Proph, Jun 29, 2014
    Last edited by a moderator: Apr 20, 2017
    Ahhh... that explains it. ;-)

    I did verify it was the X drive not having enough space. Not sure what circumstances cause it to run out. But I did create a T drive and pointed to it as a scratchdir to forward the process to it. The T drive I made was 100MB. I noticed it quickly dropping down to a little over 50MB while in use. Then the Saving Image process still failed at 16%. The 100MB T partition was still running out of space for the task. So I went ahead and made the T drive 512MB and then the Saving Image process completed 100%. Then I had the T drive merged back with the Z drive.

    Once I get past one issue... I tend to create another for myself though!! LOL! Now after merging back the T drive with Z... I am assuming the Z drive is no longer set as active because the windows partition is not recognized as bootable.

    So now after merging the T drive with Z I am re setting the Z drive as active and will have it run bcdboot Z:\Windows.

    If this does not work... I will go back to removing the T drive from the script and attempt to set the boot.wim to 512 scratchspace. I wanted to prevent from having to mess with the boot.wim at all if I can. That way anyone can just copy script files to the root of their drive/iso and edit their autounattend.xml to implement it. Or they can still install it inside the boot.wim as well if they wish.