Question: Create Win10 ARM64 Windows-To-Go from Win10 X64 OS

[Biswa96]

I successfully installed Win10 X64 as Windows-To-Go media in a Virtual Hard Disk (VHD file). And it can be boot with VirtualBox. Here are the steps:

1. Make a VHD file with Disk Management or with Hyper-V management console.
2. Mount and initialise it with GPT partition table, make a simple volume.
3. Open Rufus, select the mounted VHD (like D:) as destination device, select the Win10 ISO as source, choose Windows-To-Go not standard installation.

When I tried it with Win10 ARM64 ISO file it extracts install.wim file successfully but shows an error at bcdboot step. How can I do that?

Here are the logs after removing the extracting file (click to show).

``` Closing: \\.\CDROM0\sources\install.wim Setting up MS EFI system partition Successfully mounted '\Device\HarddiskVolume12' (USB partition 3) as 'I:' Formatting EFI system partition I: Creating file system... Enabling boot using command 'C:\Windows\Sysnative\bcdboot.exe H:\Windows /v /f ALL /s I:' Failed to enable boot Successfully unmounted 'I:' Copying 'unattend.xml', to disable the use of the Windows Recovery Environment... Finalizing, please wait... NTFS Fixup (Checkdisk)... Found VHD device 'Microsoft Virtual Disk' 1 device found Disk type: FIXED, Disk size: 136GB, Sector size: 512 bytes Cylinders: 16578, Tracks per cylinder: 255, Sectors per track: 63 Partition type: GPT, NB Partitions: 3 Disk GUID: {4CA7EC7D-3820-4F32-BF7B-222ACBBBC4DD} Max parts: 128, Start Offset: 17408, Usable = 136365177344 bytes Partition 1: Type: {E3C9E316-0B5C-4DB8-817D-F92DF00215AE} Name: 'Microsoft reserved partition' ID: {26838340-DDF1-4ECE-97C4-7943D58D0FAC} Size: 128 MB (134217728 bytes) Start Sector: 2048, Attributes: 0x0000000000000000 Partition 2: Type: {EBD0A0A2-B9E5-4433-87C0-68B6B72699C7} Name: 'Microsoft Basic Data' ID: {B9EB86F2-921B-4198-8590-16CCF9566FBD} Size: 126.8 GB (136125061632 bytes) Start Sector: 264192, Attributes: 0x0000000000000000 Partition 3: Type: {C12A7328-F81F-11D2-BA4B-00A0C93EC93B} Name: 'EFI system partition' ID: {5EF00851-3A54-4D68-A96F-FE1D535FEFF8} Size: 100 MB (104864256 bytes) Start Sector: 266133453, Attributes: 0x0000000000000000 ```

[JonnyTech]

I do not think that rufus supports ARM64 systems...

[pbatard]

@Biswa96,

You truncated the log. Please don't do that as it makes it exceedingly difficult to try to replicate the issue.

For one thing, I need to know the exact name of the ISO you use and where exactly you downloaded it. Its SHA-1 would be very nice too.

Last time I checked, Microsoft did not provide generic ISOs for ARM64 installation, so I really need to know how you came across the ARM64 ISO you use. Unless it is an official ISO that can be downloaded straight from Microsoft (rather than something that gets reconstructed on a client's machine), then it's unsupported.

[Biswa96]

The remaining part of the log was just "extracting x y z files..." like this. Extraction of ISO file goes well. I made the ISO from this link https://uup.rg-adguard.net/index.php and it was Windows 10 Insider 17643 Pro ARM64. File Name: 17643.1000.180405-1509.RS_PRERELEASE_CLIENTPRO_OEMRET_ARM64FRE_EN-US.ISO SHA256: 42335FBF68D4EDC8258319B5E4FA51B6F98C7C992DA38541AFADBB625351866A

I downloaded the X64 and X86 of same Windows build with same procedure and those works as I said before. The problem is may be with bcdboot.

• Edit: After applying this change Rufus can make the Win10 ARM64 without any error. But I can't boot this in Qemu (not related with Rufus).

index 5fe0dad..8cbeba2 100644
--- a/src/format.c
+++ b/src/format.c
@@ -1453,7 +1453,7 @@ static BOOL SetupWinToGo(const char* drive_name, BOOL use_ms_efi)
    // Also, since Rufus should (usually) be running as a 32 bit app, on 64 bit systems, we need to use
    // 'C:\Windows\Sysnative' and not 'C:\Windows\System32' to invoke bcdboot, as 'C:\Windows\System32'
    // will get converted to 'C:\Windows\SysWOW64' behind the scenes, and ther is no bcdboot.exe there.
-   static_sprintf(cmd, "%s\\bcdboot.exe %s\\Windows /v /f ALL /s %s", sysnative_dir,
+   static_sprintf(cmd, "%s\\bcdboot.exe %s\\Windows /v /f UEFI /s %s", sysnative_dir,
        drive_name, (use_ms_efi)?ms_efi:drive_name);
    uprintf("Enabling boot using command '%s'", cmd);
    if (RunCommand(cmd, sysnative_dir, usb_debug) != 0) {

May you elaborate why this change doesn't show any error?

[pbatard]

The remaining part of the log was just "extracting x y z files..." like this.

No, it contained more, like extended properties about the ISO you selected and more. I need that. Please, please, PLEASE, do NOT assume that you can tell what parts of a log are important for troubleshooting and what aren't. I point out very explicitly when you create an issue that I need a full log. This it not because I want to annoy users, but because there is data in there that most people won't think can be relevant, but that very much is.

May you elaborate why this change doesn't show any error?

I have an idea. But since you chose to withhold information (full log) when explicitly requested, and I can't confirm whether that assumption is correct or not, I am not going to disclose it until I have had a chance to test it, which will probably take a few hours or more...

[pbatard]

By the way, the ISO created by the link you pointed is a reconstructed ISO and has nothing official. It's just a bunch of downloaded component gathered on an ISO by a non official Microsoft tool. As such it is very much NOT supported by Rufus.

[Biswa96]

But it works... OK, just tell me about the edit in bcdboot command that I've mentioned before, then close this issue. BTW, when I compile Rufus from the current repo state, the visual looks is different than the released version.

[pbatard]

But it works...

But didn't you open this issue precisely because it doesn't?

OK, just tell me about the edit in bcdboot command that I've mentioned before, then close this issue.

I need to verify some stuff before I can do that. Plus, at this stage, I'm getting a bit annoyed that you are still refusing to acknowledge that a full log was needed, which makes me a lot less inclined to want to help you. My goal here is to help everybody who may try to create an ARM64 bootable Windows USB, not just you . So, even though I am very tempted to do so, because the ISO you are using is NOT an official Microsoft ISO, and therefore 100% unsupported, I'm not going to just close this issue because you have managed to find a workaround...

BTW, for what is worth, I have been releasing ARM and ARM64 Rufus Windows binaries for some time now. You can find them in https://rufus.akeo.ie/testing/

BTW, when I compile Rufus from the current repo state, the visual looks is different than the released version.

Let me reverse the roles here, since you're so kind as to offer me an occasion to demonstrate how annoying it is when the other party chooses to withhold data that they could easily provide: How about you take a guess as to why that is? I don't think I should have to provide that information to you, because it should be pretty obvious...

[pbatard]

I told that the procedure works for x64

But not for ARM64, which is the issue (your title is about ARM64, not x64), and which is something I'm planning to look into.

[Biswa96]

Here is the rufus.log file (18.2 MB): rufus.log

• rufus.log SHA256: EEB756BF9C1786A956AD4F088051104FAFD2A82741715805A44DB9FD2529437C
• Win10 Insider 17650.1001 en-US ARM64 ISO SHA256: 3D5BE31C51AB072F7888ECBD2A3CA61D95A93428DE060CA44B2DE8E02F147AF4

I made the ISO file from this website https://uup.rg-adguard.net/index.php and choose the following options: Windows Insider > Windows 10 Insider Preview 17650.1001 > en-US > Windows 10 Professional > Download ISO compiler in OneClick. My final goal is to run the Win 10 ARM64 in Win10 X64 OS with Qemu (like in this @riverar's article).

[pbatard]

@Biswa96, thanks for the log. I always want a full log, no matter the size, and, as you have found out, github does allow you to attach it even if it's large.

For the record, if you are interested in running Win10 ARM64 in QEMU you can follow this post, which provides a ready-to-run image. This is how I checked that Rufus worked on ARM64 versions of Windows.

I am still planning to look into this issue (which is why I haven't closed it, even though, since the generated ISO is anything but official, I could easily dismiss it - as a matter of fact I'd be really curious to hear what the official procedure for Win10/ARM64 installation on bare hardware is from Microsoft, because they sure as heck don't seem to provide anything that could pass as official installation media), but it is low priority, so it'll probably be a few days or weeks before I do so.

[Biswa96]

Can I filter the logs in Rufus? Is is there any option to do that?

[pbatard]

Nope. As mentioned in the FAQ, the log is for the benefit of the developer (me) only, so I am not planning to add any options or features that would detract from that.

For the record, I'm usually spending a lot of time on this issue tracker berating users for not including a FULL log. There's a reason for that: I REALLY need to have the whole picture always to troubleshoot issues. Therefore the last thing I want is a partial log. I don't care if your log is 1GB long, with tons of lines that people may think are irrelevant, I will always want to see it all. So I'm afraid I have to reject your suggestion.

On the other hand, since Rufus is Open Source, you can always create your own version with whatever filtering you want.

[rmenessec]

I'm a bit hesitant to comment on such a thorny issue, but it seemed like this question might better go here than in a new issue: is Rufus likely to support the creation of "To Go" or PE install media, whatever architecture, at some point? Or is that out of scope?

EDIT: I'm sorry; I didn't realize that Rufus already supports To Go creation. Question amended.

[pbatard]

Well, if you can find an official Microsoft ISO for Windows installation on ARM system (i.e. one that would be officially distributed as retail, or downloadable as an actual ISO from MSDN), then yes Rufus is meant to support the creation of a USB installation media for ARM (most likely provided your target ARM system is UEFI based, since there's no such thing as "BIOS" for ARM). However, it is possible that you may run into a bcdboot.exe issue when doing so, which I can't validate and/or fix, since I don't have access to any official Microsoft ISO for Windows installation on ARM (the ARM64 ISOs above are non official and reconstructed from bits and pieces, so not something I really want to go out of my way to support in Rufus - In the case of ARM64, https://uup.rg-adguard.net/index.php does not provide a straight ISO download but relies on a third party local tool to create it).

As to Windows To Go, that's a whole different story.

In other words, without Microsoft publicly providing Windows 10 ARM64 installation ISOs, like they do for x86, ARM64 media creation support is a completely nebulous area, and there is not much of any promise I can make with regards to what Rufus can or cannot do (and, in case of 'cannot do', how I might be able to fix it) unless we start seeing official retail ARM64 Windows 10 installation ISOs from Microsoft on the net. So far, I haven't been able to locate any (but then again, I don't have MSDN access).

[rmenessec]

Sorry, I should have been clearer: I don't have any interest in ARM / ARM64 specifically. I was asking whether, in general, Rufus might eventually support the creation of Windows PE media for using recovery tools.

I'm personally amd64 everywhere (except embedded systems...), so I would be creating amd64 PE images on amd64 machines. By "whatever architecture," I meant "regardless of architecture."

Right now, creating Windows PE boot media seems to require the entire Windows Assessment and Deployment Kit. If there's some way that Rufus could make that process easier—and require a lot less disk space—that would be really great.

If that's out of scope for Rufus, I understand.

[pbatard]

That's certainly out of scope of this issue. Please don't piggyback on an unrelated open issue, as it makes it confusing for everybody.

And, with regards to your question, since Rufus is not designed for sysadmins, and creating PE environments seems to be mostly a sysadmin-like concern (Pretty sure that 99.9% of the people who use Rufus would never use that feature), looking into it doesn't seem like a good investment of my time, as it already is in very short supply. So the answer is: No, I have no plans to have Rufus help you with your PE environment creation.

[Biswa96]

One thing I want to clarify. Yes, I do accept that the website, https://uup.rg-adguard.net/index.php, doesn't download the "real ISO" from Microsoft website. But it downloads the CAB and ESD files from Microsoft server with aria2. Then it creates ISO from those files with wimlib-imagex.exe, 7z.exe etc. which are free & open-source. And I agree with pbatard's decision.

[pbatard]

Then it creates ISO from those files with wimlib-imagex.exe, 7z.exe etc. which are free & open-source.

Which I'm absolutely fine with (of course).

My only issue is that these aren't the tools that Microsoft uses to master their ARM64 ISOs, and there is therefore no way of telling what the official boot method from retail ARM64 Windows ISO is supposed to be (which in turn, makes it difficult to support it in Rufus).

It's a bit like trying to deduce what a retail Microsoft Windows ISO might look like when all you have access to is an All-In-One ISO. Sure, their goal is pretty much the same, but the AIO might be using something like GRUB EFI bootloader and a bunch of install.esd's, whereas the official retail might use a single install.wim, and of course, no GRUB. The only compatibility I am interested in for Rufus is with official ISOs, as there are just too many ways to create non-official ones...

[Biswa96]

You may close this issue anytime you want.

[pbatard]

You may close this issue anytime you want.

Yes I can. 😄

But I still want to take a look into what's going on with the "unofficial" images, especially as I think there's probably a small fix I should add to Rufus to make them work, if there is an issue with bcdboot.exe. And I'm also hoping that at some stage, official Microsoft ARM64 installation ISOs will appear on the net.

I just haven't found the time to do so, since it's not a high priority (which is why this issue is tagged as deferred)...

[djhayman]

Hi @pbatard,

Official ISO files are available for ARM64 from https://my.visualstudio.com/Downloads if you have a Visual Studio with MSDN subscription.

There are two versions available:

"Windows 10 (consumer editions), version 1803 (Updated March 2018) (ARM64) - DVD (English)" Released: 30/Apr/2018 SHA1: 4B83EDBC2BE4C1CAE51F44B752A96D6A2723E645 File name: en_windows_10_consumer_editions_version_1803_updated_march_2018_arm64_dvd_12063378.iso

"Windows 10 (consumer edition), version 1803 (Updated Aug 2018) (ARM64) - DVD (English)" Released: 22/Aug/2018 SHA1: 1B5E55032163854D16EC5DAED7FC4A9B19AFD3CF File name: en_windows_10_consumer_edition_version_1803_updated_aug_2018_arm64_dvd_c3f1ab29.iso

For some reason, the architecture drop-down says "UNK" instead of "ARM64", but they are both definitely ARM64 editions.

[pbatard]

Thank you very much for this information. This is exactly the kind of data I needed. I'll try to get my hands on one of these images and to validate and fix the issue that was reported, if I can replicate it.

[pbatard]

Okay, I was able to replicate the issue with en_windows_10_consumer_edition_version_1803_updated_aug_2018_arm64_dvd_c3f1ab29.iso and can confirm @Biswa96's analysis that the issue comes from trying to apply BIOS bcdboot.exe settings to an image that is UEFI only.

Now, I've got to figure out the best way to detect Windows ISOs (I suspect the absence of a bootmgr in the root directory should do it ), and I should have a fix for this in Rufus 3.3.

[pbatard]

Issue should now be fixed and will be included in Rufus 3.3 that I'm planning to release early next week.

There's a BETA of Rufus 3.3 available here if you want to check.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue if you think you have a related problem or query.