Boot to Windows installer not working

[artslob]

Tried to install single Windows iso - Win10_1809Oct_Russian_x64.iso - from both Ubuntu 17.10 and Windows 10. Same result: when loading to usb drive, there is option in grub menu called Win10_18090Oct_Russian_x64, when hitting enter at this option happen instant return to main menu of usb. Tried change syslinux.cfg like in #404, but it didnt help.

Sinlge Linux iso works by the way

[ma3yta]

I got the same result with Windows_10_Pro_1809_x64.iso downloaded using MediaCreationTool https://go.microsoft.com/fwlink/?LinkId=691209

[DanielRios549]

Verify if the partition has the boot flag

[A9G-Data-Droid]

Are you using UEFI boot? You must boot using legacy mode for Windows installers to work. (This has some unfortunate consequences if you want to later use UEFI boot, post-install.)

[alete89]

@A9G-Data-Droid Thanks for the tip, it worked. Although I would prefer to install using UEFI.

[A9G-Data-Droid]

@alete89 So would I. I think the problem is how Windows UEFI bootloader works. Maybe we could use clover: https://sourceforge.net/projects/cloverefiboot/

[haxj]

I've found a solution. When booting to bootmgr.efi in UEFI mode, the error is:

/EndEntire
file path: {path}/EndEntire
error: cannot load image

Solution: Instead of chainloading /bootmgr.efi, copy /efi/boot/bootx64.efi in Windows ISO to the USB then chainloading it. Windows boot normally now.

[A9G-Data-Droid]

@haxj Can you write out the steps you took in Python?

[haxj]

@A9G-Data-Droid Sure, I've just committed the fix Can some core contributors review this fix?

[mbusb]

Can you make a pull request?

[haxj]

Edit: Oops, wrong issue, my bad. This comment is for issue #459

Okay so after some tests, apparently other distros also have detection problems. Here is the thing: There are 2 tests to detect the type of an ISO: keyword based and file list based (function detect_iso_from_file_list()). Whichever performed first may return distro type, if it can't detect the distro then the other test comes in.

• In version 9.2.0: Keyword based test is performed before file list based test. Detection works fine (At least for ubuntu, centos and windows).
• In master: File list based test is performed before the other and the file list test was refactor a bit. This causes Windows detection problem (#459). I tried to make file list test performed like 9.2.0, and the Windows problem is resolved.

However, the fact that file list based test is performed first causes problems with CentOS (and may be other distros as well).

• In version 9.2.0: Keyword based test recognizes CentOS ISOs correctly and file list test is never performed
• In master: File list test wrongly recognizes CentOS ISOs as slitaz because it see the string "dban" in CentOS ISO's file list (as in /Packages/...broadband.rpm). Therefore, the keyword test is not performed.

I can see some possible solutions:

• Perform keyword test before file list test (revert the change to the same as 9.2.0). This will make detection slower (keyword test takes longer)
• Exact match instead of wildcard match the file name, so "dban" can only match with "dban" and not "dban"). This may fixes the problem for CentOS, but I'm not sure about other distros. What other ISOs that have also broken? Will they still broken after this fix? Or will this fix introduce detection problem to other distros?

Many things are broken here. I don't have experience with other ISOs (slitaz, memtest, alpine, f4ubcd, etc.) so I cannot test MBUSB with them. Can some core developers take a closer look at this issue? This is quite serious as this may affected many type of ISOs.