Jump to content











Photo

Windows 8.1 (UEFI Boot) Issues


  • Please log in to reply
248 replies to this topic

#126 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 11 July 2014 - 01:07 AM

Yes, it's a simple idea, perfect for including in my new upcoming product, "RarMagic QuadrupleSpace".

 

You would only need multiple WIMs to bound the the amount of extra disk space that is used during the process.  VSS should theoretically be unnecessary if you are excluding locked files anyway.  Although you also need to handle concurrent modifications of non-locked files, and also files that were not locked during the scan phase but were locked when their data needed to be read.  All of these are hard problems.  They really should be solved in wimlib itself, although I might be able to insert callbacks at appropriate places for your program to use.



#127 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 01:26 AM

Argh, unfair! I have already been beaten to market before I could complete DoubleSpace, by a much more powerful QuadSpace :D

 

PS: I still don't get how WIM's would help bound the disk space used...


Edited by simonking, 11 July 2014 - 01:26 AM.


#128 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 11 July 2014 - 01:38 AM

You create one WIM, say of size 1 GB, containing only a subset of the files.  Then free up disk space by setting all those on-disk files as externally backed by the WIM file.  This will free up at least 1 GB of space, so the next WIM file can be at least as large as the previous.

 

Actually I might as well skip right to OctupleSpace, which will delete Windows and replace it with Linux.



#129 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 01:44 AM

Oh, got it...

 

Does OctupleSpace run on stupid tablets  :D


Edited by simonking, 11 July 2014 - 01:44 AM.


#130 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 01:56 AM

Success!

 

The version of DoubleSpace included in the latest upload of ZIPmagic - www.zipmagic.co/zipmagic.msi - has worked offline from a WinRE partition, based entirely on WIMLIB, and has booted without getting indefinitely stuck in the spinning boot loader stage! Steps to reproduce this success:

 

1) Install Windows 8.1 Update 1 on VMware, in BIOS mode.

2) Install ZIPmagic.

3) Boot into WinRE using Misty's excellent batch file, after assigning drive letter R: to your recovery partition.

For that assignment, you can:

diskpart

select disk 0

select partition 1

assign letter r

exit

4) Once in WinRE, go ahead and copy DoubleSpace from the ZIPmagic install folder (to be found on drive D:) onto drive C: (which is a nice, empty RAM drive created by WinRE). Also copy d:\windows\system32\wimbootcompress.ini to x:\windows\system32\wimbootcompress.ini, because your WinRE will not have the standard exclusions file, that your Windows 8 Update 1 already has.

5) Run DoubleSpace from drive C: (and not the installed folder on drive D:, or it will fail).

6) Choose any compression setting, other than MaxSpeed, so WIMLIB is used instead of WIMGAPI. So you can choose MaxSpace or anything in between.

7) Reboot at the end of it all to enjoy DoubleSpace compression savings :D

 

Needless to say, the last challenge I'm facing before official launch is automating the steps above. Looking forward to that!

 

Thanks again, Misty for the excellent BATCH files and your kindness, and Wonko for your WinRE idea.

And a very big thanks to Eric, for building the library that makes, what Wonko would call my glorified UI, possible in the first place :D



#131 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 01:58 AM

Last but not least, I haven't yet had a chance to test any of this on UEFI VMware or x86 mode - will get to that soon.

 

A bit scared of testing live on my Surface's, but that too will be coming soon.

 

If we can avoid the indefinitely spinning boot spinner, the software goes gold.



#132 misty

misty

    Gold Member

  • Developer
  • 1033 posts
  •  
    United Kingdom

Posted 11 July 2014 - 08:03 AM

This really is my last post for a while - honest!
 

4) Once in WinRE, go ahead and copy DoubleSpace from the ZIPmagic install folder (to be found on drive D:) onto drive C: (which is a nice, empty RAM drive created by WinRE). Also copy d:\windows\system32\wimbootcompress.ini to x:\windows\system32\wimbootcompress.ini, because your WinRE will not have the standard exclusions file, that your Windows 8 Update 1 already has.

5) Run DoubleSpace from drive C: (and not the installed folder on drive D:, or it will fail).

Firstly, why not inject DoubleSpace into your customised WinRE - this saves the need to use a RAM drive and should make it easier to script in the future by using a hardcoded path - e.g. X:\path\to\doublespace

Secondly, I seem to recall that the wimbootcompress.ini is used mainly on extraction - not necessarily during the capture phase. And the default wimbootcompress.ini is missing, in my opinion, the following two entries in the [PrePopulateList] section -
\bootmgr
\boot\BCD
Admittedly these are only required if the OS drive also contains these boot files. Read this page (and possible the one after) for some background - http://reboot.pro/to...entation/page-6. I'd suggest just injecting your own customised wimbootcompress.ini file to your WinRE.

Now I'm not sure what doublespace does. I do know however that when using WimBoot the target .wim that you are using will need to include the WoF driver - this is currently limited to Windows 8.1 Update 1 and WinPE 5.1. This means that you will need to backup the Windows 8.1 Update 1 installation to a new .wim, then use this new .wim as the target.

cdob (a man who definitly knows where his towel is) posted about a wimboot setup with one partition only - http://reboot.pro/to...mboot/?p=183834
 

A bit scared of testing live on my Surface's, but that too will be coming soon.

I'd recommend taking a sector by sector backup first - using a forensic type process as recommend by Wonko earlier in this thread - a whole disk image to external media using something like dd would be my recommendation. Set the backup file as readonly and then mount it to check the file and partition structure is intact. Then you can restore this working backup if things do go wrong.

Regards,

Misty

#133 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 15103 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 11 July 2014 - 08:14 AM

@Misty

On the other hand, till now the WinRE is seemingly "untouched".

 

Just an idea, but if points 2) and 4) can be slightly changed it seems to me how it would be possible to use of the thingy as a "proper" backup solution.

I.e. have (say on a USB external hard disk or largish stick) a "portable" version of the thingy, then boot to the WinRE, run the tool from the USB device creating the .wim on the the external device.

If the WinRE needs mods, it can still, I believe be copied to the external device, modified and then run from it.

This way the PC internal hard disk (or SSD) remains "untouched", and the external device might represent a valid "snapshot" (allowing recovery) of the PC internal storage.

 

:duff:

Wonko



#134 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 11:57 AM

DoubleSpace is basically a backup/restore tool for your computer that works with both WIMGAPI and WIMLIB.

The main goal of DoubleSpace is usage as a live, transparent disk compression utility.

It also doubles (pun intended) as a generic backup/restore snapshot utility.

Here's a few things you get to do with a single click in DoubleSpace:

 

1) Automatic WIM capture of a drive to another drive; then formatting the original drive, and applying the captured WIM in WIMBoot mode.

2) Automatic WIM capture of a drive to the same drive; with deletion of files that are captured transparently as the WIM is built; then applying the captured WIM in WIMBoot mode. Note that this is something you could not do with any command line or other tool presently.

3) Four compression settings - ranging from MaxSpeed to MaxSpace. MaxSpeed is native WIMGAPI compression (XPRESS with 4K chunks). MaxSpace and everything else in between is custom WIMLIB compression, starting with XPRESS in 8K chunks, and ending with LZX in 32K chunks. Note that there were originally five compression settings, but because WIMGAPI itself is for some reason incompatible with the middle of the road XPRESS 16K setting, I removed it - so any WIM file created can be currently applied using native WIMGAPI tools (such as dism) as well, outside of DoubleSpace.

4) If you double-click the DoubleSpace icon in the UI, you get access to some "hidden settings" which let you customize some more software parameters (admittedly, at more than one click):

5) You can choose whether to Backup, Restore, or both. There is also a System Restore option, which when selected, applies your WIM file in non-WIMBoot, ordinary mode. This means that the contents of you WIM file will be restored as an ordinary, uncompressed disk image, to your target disk.

6) You get to customize the location and name of the target WIM file.

7) You can enable or disable on-the-fly deletion of files on the target volume. So if you just want to backup without doing anything else, make sure you use this option to disable on-the-fly deletion. This will turn off formatting the target volume when an Undo Disk is used. It will turn off deleting files on the source partition as the WIM is being built, when no Undo Disk is used.

8) What is referred to as an "Undo Disk" on the main UI is simply an external drive to contain your WIM file. If one is supplied, you will not need to delete any files on-the-fly, which is really good for you because if there's some unknown bug in DoubleSpace, or WinRE, or your power supply unit; this will not leave you high-and-dry with a half-deleted partition and a WIM file that failed to be created.

 

You also get to enjoy nice progress display while DoubleSpace is running :)

 

Common metrics are files per second while restoring, and megabytes per second while backing up. MaxSpace seems to run at about 10 megs per second on Surface Pro 2, whereas all other settings including MaxSpeed seem to average 40 megs per second.

 

There is no noticeable runtime speed impact when running out of a MaxSpace compressed volume. In fact, my main development system has been MaxSpaced for quite some time now, I am squeezing a whopping 128 GB of data onto a puny 64 GB SSD :D So I don't see why anyone would choose XPRESS over LZX, or why MS allows only XPRESS in their WIMGAPI interfaces; I'll leave that up for speculation :D

 

DoubleSpace is the King of WIMBoot land - until, of course, QuadSpace or OctupleSpace are released :)

 

Of course, as of this writing, there's still a few to-do's left with the tool:

 

1) Automate the entire process I documented above to use WinRE, so one-click in live Windows does everything I described above - RE location, injection, rebooting, running DoubleSpace from RE, and then booting back into live Windows.

2) 32 bit version quality assurance. In a brief test yesterday I saw DoubleSpace go crazy in 32 bit mode, which probably makes sense, since I had never tested it before in 32 bit mode :)

 

What you can already confidently do is, put DoubleSpace, together with its supporting WIMLIB DLLs, on any portable USB stick - be it PE 5.1 or RE sourced, etc. - and use it is a disk doubling or generic backup solution, in 64 bit mode.

 

Please enjoy, you all have contributed to this effort!

 

(Hint-Hint: DoubleSpace has still not been tied into ZIPmagic licensing, so download it now.)


Edited by simonking, 11 July 2014 - 11:58 AM.


#135 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 12:11 PM

For those people who will actually be using DoubleSpace to compress their drives as originally intended, here's a few tips:

 

1) Keep files that are modified frequently off your drive to compress, before compression. WoF will extract these files automatically the first time they are modified; effectively causing you to lose the compression savings on those files.

2) Especially, keep files that you may want to delete at a future date off your drive to compress. When you delete files that are WIM-backed, they end up going nowhere, since they're still in the WIM. So when you're uninstalling apps or deleting that are stored in your main image, don't be surprised if you do not gain any additional free space. They're still going to be in the WIM.

3) Use DriveSpace (NTFS compression) to compress any additions to your WIM backed drive. DriveSpace skips processing any files stored in the WIM, so there's no space duplication. It will, however, compress any data that has been extracted out to your drive, out of the WIM.

4) Feel free to recompress your drive at any time with DoubleSpace. This will reclaim all space previously lost due to files modified/deleted out of the WIM. It will also, of course, compress any files you had since packed with DriveSpace's inferior NTFS compression, using the superior DoubleSpace compression.

 

Last but not least - while the DoubleSpace UI suggests that DoubleSpace is intended mainly for your boot drive, it can equally easily pack any other drive using WIMBoot technology :) And for this, you wouldn't even need to boot into another Windows (like RE or PE) - you could do the entire processing on-line.

 

However, for data (non-boot) drives, I'd still recommend Stacker from the suite. Space savings you gain from data deduplication (Stacker's underlying technology) far outstrip savings you'd gain with both DoubleSpace, and DriveSpace.


Edited by simonking, 11 July 2014 - 12:12 PM.


#136 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 11 July 2014 - 01:23 PM

 

 

So I don't see why anyone would choose XPRESS over LZX, or why MS allows only XPRESS in their WIMGAPI interfaces; I'll leave that up for speculation  :D

 

As I mentioned to you earlier, I think this is still in need of a benchmark that does *random reads* from WIM-backed files.  The question is, if you read 100 bytes from the file, will the full 32768 byte chunk always be decompressed, or will the decompressed data be stored in the operating system's page cache and used to satisfy further short reads.  Of course, if Microsoft wrote their driver properly it should be the latter.

 

(Side note: in wimlib v1.7.0, I enabled the kernel_cache option to FUSE when mounting WIM images on Linux.  So the Linux kernel will cache the decompressed data that wimlib provides as a result of reads to o mounted WIM image.  Whether the equivalent is happening with Microsoft's implementation on Windows, I don't know.)



#137 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 01:28 PM

Uh-oh. There's a bit of a problem with the WinRE approach. I was testing drive re-compression, only to find out that it will not work on a WinRE that hasn't been updated to include the WoF driver.

 

From the command line, you can dir files and such, but you cannot actually access what's inside them - the older WinRE doesn't know how to follow the pointers back into the WIM file. A "DOS" command like type myfile.txt returns the error:

 

The file cannot be accessed by the system.

 

I noticed the problem only when I was using WIMLIB MaxSpace to recompress the disk. The progress was moving unnaturally fast. Only then did it occur to me that WIMLIB had not raised an error due to inability to follow the pointer files; but was also not actually operating properly. I don't know if WIMLIB could manually decipher the content of such files - not to suggest that this is a reasonable expectation in the first place.

 

Now for a bit more of WIMLIB troubleshooting: So then I decided to do a system restore (regular restore, no WIMBoot), based on the existing backing WIM that I already had in place. Now, the process went on for a while - but I ended up with a new error:

 

The requested operation is unsupported

[ERROR] Can't extract data: too  many open files!

 

I am now retrying the same system restore operation using WIMGAPI, to see if it also errors out somehow. This ought to have worked with WIMLIB too, because I was doing a regular (non-WIMBoot) restore based off of a WIM file that was pre-built (and located on another partition).

 

I'm also going to see how WIMGAPI itself behaves, when I use it to recompress an already WIMBoot'ted drive, without the WoF driver, just for kicks :)


Edited by simonking, 11 July 2014 - 01:31 PM.


#138 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 01:32 PM

Very true, this would be a call for any enterprising benchmarkers out there :)



#139 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 11 July 2014 - 01:38 PM

 I noticed the problem only when I was using WIMLIB MaxSpace to recompress the disk. The progress was moving unnaturally fast. Only then did it occur to me that WIMLIB had not raised an error due to inability to follow the pointer files; but was also not actually operating properly. I don't know if WIMLIB could manually decipher the content of such files - not to suggest that this is a reasonable expectation in the first place.

 

 

"WIMBoot pointer files" are reparse points with the special tag 0x80000017, which is handled by the WOF driver.  The WOF driver hides the reparse point and causes applications to see the redirected file, whereas when the WOF driver is not running, applications see the reparse point.  wimlib is working exactly as designed in archiving the reparse points, and I doubt WIMGAPI is any different.  It would require a lot of additional logic to duplicate what WOF is doing when it redirects access to the files...

Now for a bit more of WIMLIB troubleshooting: So then I decided to do a system restore (regular restore, no WIMBoot), based on the existing backing WIM that I already had in place. Now, the process went on for a while - but I ended up with a new error:

The requested operation is unsupported
[ERROR] Can't extract data: too  many open files!

In wimlib v1.7.0 this can happen if you're performing an extraction operation that includes more than 1024 byte-for-byte identical files.  However, I already fixed this in wimlib v1.7.1-BETA (before you started working with this), this should be fixed, except in an edge case when extracting to a filesystem such as FAT that doesn't support hard links.  So I don't know why you're observing this error, exactly.  Can you run 'wimlib-imagex info --lookup-table WIMFILE' on your WIMFILE and attach its output?



#140 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 11 July 2014 - 02:02 PM

Total false alarm here with that error, sorry about that.

 

WIMGAPI failed with the error "out of disk space" and of course, that makes total sense!

 

I was trying to do a normal restore on a disk that was already doubled previously. So WIMLIB's error is totally normal, if a bit misleading in the description.



#141 cdob

cdob

    Gold Member

  • Expert
  • 1449 posts

Posted 11 July 2014 - 08:07 PM

1) Install Windows 8.1 Update 1 on VMware, in BIOS mode.

To clarify: do not install Windows 8.1 and run windows update. The WinRE, is not upated that way: WinPE 5.0
Windows 8.1 Update 1 WinRE refers to WinPE 5.1.
 

3) Boot into WinRE

running: shutdown /r /o
http://www.eightforu...indows-8-a.html
http://pcsupport.abo...s-windows-8.htm

Yes, wimboot is active. Thanks.


If WinRE is missing locally:

There are direct ADK 8.1 winpe.wim manufacturer links, however WinPE 5.0
http://www.catonrug....m-download.html

I don't know any relating WinPE 5.1 links.
http://technet.micro...r/hh699156.aspx
Windows 8.1 Evaluation is a big file.
Boot the DVD and press shift F10.

#142 synchronicity

synchronicity

    Frequent Member

  • Advanced user
  • 165 posts
  •  
    United States

Posted 12 July 2014 - 12:12 AM

Total false alarm here with that error, sorry about that.

 

WIMGAPI failed with the error "out of disk space" and of course, that makes total sense!

 

I was trying to do a normal restore on a disk that was already doubled previously. So WIMLIB's error is totally normal, if a bit misleading in the description.

 

No, the error you received from wimlib has nothing to do with running out of disk space.  I will put this on my todo list of things to look into.  The dump of the WIM's lookup table as I requested would be helpful too.



#143 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 12 July 2014 - 12:23 AM

Oh, you think this is something else still then? I don't know if I have that exact WIM anymore, but I'll try to reproduce this and get it to you.



#144 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 13 July 2014 - 04:13 AM

OK, it's done and working.

 

I have just compressed a VMware x64 EFI system, as well as a VMware x64 BIOS system, both Windows 8.1 Update 1 of course (the EFI installed native from scratch with an Update 1 DVD - sadly, WinRE still below PE 5.1), using ZIPmagic DoubleSpace. Running in fully automated fashion!

 

1) Extract the contents of the archive www.zipmagic.co/doublespace.7zip.

2) Run project1.exe. Here's the testing harness UI, which is nasty, so here's some further instructions to help out:

3) Make sure drive Z: is unused and available for use as a new temporary drive letter on your computer.

4) Click Automatic. The tool scans all your volumes. It finds winre.wim. And then it should say Found! on project1.exe's window caption area (take that, Wonko, for a glorified UI :)) Finally, it should say The operation completed successfully on the caption, or something went bad and you should stop here. Verify that winre.wim is found next to project1.exe on your hard disk.

5) Click Inject. The UI should freeze for a few moments. The caption of the window won't even change, because there's very little that can go wrong here if #3 went OK, thanks to the superb WIMLIB. Now, the default winre.wim has been updated to contain ZIPmagic DoubleSpace.

6) Make sure no drive letter is assigned to your WinRE partition; if one is assigned, remove it using diskpart first.

7) Click Boot. You won't have to stare at the window caption anymore; you'll get a live display as your BCD store is updated. If you don't get as far as Creating ZIPmagic entry, you know something went wrong. This first copies winre.wim to your C: drive root, and then it duplicates your BCD store entry for the standard winre.wim instance. Duplication, instead of Misty's approach of re-creation, has the added benefit that the same code works on both UEFI and BIOS systems without even needing to query which mode it is. Also all that code about a ramdrive is unneeded, since all that stuff got duplicated too.

8) Reboot, and choose the new ZIPmagic DoubleSpace entry created for you by #7 above.

9) DoubleSpace runs in full, dedicated mode :) It offers to reboot when its finished.

10) Upon rebooting, choose the Windows menu entry, instead of the DoubleSpace menu entry.

11) Right-click the Start Button, and select Disk Management.

12) Enjoy your newly doubled disk, as verified by the WIMBoot indicators on your boot partition.

 

Thanks again for all who have helped, sorted by the date of their contributions to the project:

Sinan Karaca of InstallAware, for the idea, and prototype code.

Eric Biggers of WIMLIB, for the late night troubleshooting help and excellent library.

Jaclaz/Wonko and Misty, for the WinRE idea and example batch files.

 

The only drawback to this implementation (the only thing it cannot do, and that you will need PE 5.1 for) is drive recompression. So make sure you do not attempt to recompress your drive with this version just as yet!

 

Of course, project1.exe shall soon bite the dust, and all of this will be done automatically from the DoubleSpace UI automatically, the moment you choose to compress your boot partition. But that'll take a while to implement, so I figured I'd let you see the proof of concept working first.


Edited by simonking, 13 July 2014 - 04:23 AM.


#145 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 13 July 2014 - 04:24 AM

The most amazing thing of all, the above process seemed Surface-immune until it was not :D It seemed to work even on the Surface where I had the weird device not ready errors with the partition letter R: that I had assigned earlier! Incredible.

 

Alas, when booting in, I got the error:

 

"There isn't enough memory available to create a ramdisk device."

 

0xc00..0017

 

Does that blue screen make any sense at all? Is this actually one drawback to having duplicated a boot entry - could the original entry that was duplicated out of date/corrupted somehow?

 

Unfortunately, this is why, VM testing is no longer sufficient :'(

 

Rebooting back to Windows is of course possible.

 

The device seems to shut off some moments after displaying the blue screen, and can be restarted normally.


Edited by simonking, 13 July 2014 - 04:28 AM.


#146 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 13 July 2014 - 04:37 AM

Ooooh. The other Surface, the one with the apparently intact and accessible R: partition (WinRE partition could be dir'd without getting "device not ready errors") has been blue screening as well, after appearing to nearly boot completely. The error message on the blue screen is SYSTEM_PTE_MISUSE.

 

The plot does get thicker! Is this further proof that Microsoft's Surface strategy is failing? ;)

 

Again, once the Surface reboots, one can easily boot back into Windows. So at least, none of this causes a fatal problem right now. Would be sure nice to be able to run on Surface's without having to use USB sticks, of course...


Edited by simonking, 13 July 2014 - 04:39 AM.


#147 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 13 July 2014 - 04:49 AM

UNMOUNTABLE_BOOT_VOLUME is what happened on the Surface that previously had SYSTEM_PTE_MISUSE. What I changed is, I used Misty's trusty old batch files. And the boot loader came up in text mode, which I thought was weird, because I had not seen this inside the VMs, or on this same Surface, in the immediately preceding test that had ended with SYSTEM_PTE_MISUSE. All the other tests had a nice Please wait text added to the standard Windows 8 boot spinner screen. I really have no way to account for the difference. :(

 

Oh, the VMs were so good. They just worked.


Edited by simonking, 13 July 2014 - 04:50 AM.


#148 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 13 July 2014 - 04:52 AM

Did I mention that the VMs also did not get stuck in the "Boot loader spinning indefinitely" stage, despite DoubleSpace using WIMLIB to restore?

 

I haven't been able to test the restore on the Surface's...I'm pretty sure I can count on that going wrong too with them :)



#149 simonking

simonking

    Frequent Member

  • Advanced user
  • 236 posts
  •  
    Australia

Posted 14 July 2014 - 04:34 AM

OK, this bit has finally been sorted out: DoubleSpace now automagically preps a WIM file, and boots itself into it :D

 

I even just finished testing and validating WIMLIB on a Surface - no boot spinner rotation problem.

 

I believe any problem caused by seemingly random Surface corruption would surface immediately when trying to boot into the BCDEDIT menu entry that DoubleSpace creates. The process seems to stall there, so no harm can be done during further processing, thankfully.

 

I believe the project goals have been realized - a one-click, WIMBoot based, transparent full-disk compressor; which can utilize an external "Undo Disk" when available, but does not mandate one to be available. And can boot into itself without needing any USB stick, and/or manual/automated WinPE construction :D



#150 Tripredacus

Tripredacus

    Frequent Member

  • Expert
  • 234 posts
  • Interests:K-Mart-ian Legend
  •  
    United States

Posted 14 July 2014 - 03:38 PM

Alas, when booting in, I got the error:
 
"There isn't enough memory available to create a ramdisk device."
 
0xc00..0017
 
Does that blue screen make any sense at all?


What is the size of your boot image?




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users