Reboot fails when Windows is on virtual disk.

[midaspt]

As verbosely detailed at https://www.q4os.org/forum/viewtopic.php?id=1985, and confirmed later with other installs (see below), when using wubiuefi with a Windows that is itself installed to a virtual disk (VHD), the process will proceed normally but it will fail on reboot.

The issue is caused by the fact that 'wubildr' and 'wubildr.mbr' files will be placed at the root of the Windows drive -- i.e., inside the Windows container file -- and will vanish once the system is no longer booting into Windows.

To solve this issue, it is enough to move the files from the virtual drive to the root of the physical drive.

Other setups the issue was observed and fixed in: latest stable releases of Lubuntu and Xubuntu (wubi).

I also tried Mint 19.2 and LMDE but, although the installation process seemed to progress normally (wubi md5) at first and the misplacement of files was observed and corrected, upon reboot only a glitched GRUB menu was displayed without any Linux option present.

[hakuna-m]

Other setups the issue was observed and fixed in: latest stable releases of Lubuntu and Xubuntu (wubi).

Which Wubi for the latest stable releases of Lubuntu and Xubuntu do you mean ? If you mean Wubiuefi: What is the issue for Wubiuefi ?

[midaspt]

Other setups the issue was observed and fixed in: latest stable releases of Lubuntu and Xubuntu (wubi).

Which Wubi for the latest stable releases of Lubuntu and Xubuntu do you mean ? If you mean Wubiuefi: What is the issue for Wubiuefi ?

Except for Q4OS, all were tested with wubiuefi only, latest v1904r336, downloaded a few days ago.

The references between parenthesis are the ones wubiuefi self-assigned to the install, either in its GUI or as entries in the bootmenu, whenever the installs resulted in functional systems -- I used local ISOs with the "--isopath=" parameter in all cases.

[midaspt]

As a wild afterthought, I would be golden if wubiuefi could be made to produce VHD installs for the OSes it supports. I have seen it discussed as a real possibility but my knowledge is far too little to get it.

[hakuna-m]

The references between parenthesis are the ones wubiuefi self-assigned to the install, either in its GUI or as entries in the bootmenu, whenever the installs resulted in functional systems -- I used local ISOs with the "--isopath=" parameter in all cases.

So you used the feature "various distros/versions" in all cases.

There is nothing wrong to use that feature but note the self-assignment of a desktop environment does not mean that the installation is fully supported.

e.g. a Debian based distro like LMDE is not supported. There are also known issues with a newer version of the Linux Mint installer. But all these issues have nothing to do with virtual disks, of course.

In general, we know that Wubi(uefi) has never supported all special Windows disks. But of course, it would be also a good idea to add new features. But do you really need such a feature for modern UEFI systems. UEFI systems do not use wubildr and wubildr.mbr for booting.

[midaspt]

e.g. a Debian based distro like LMDE is not supported.

Yes, I was aware of it beforehand as I read all documentation. But as Q4OS (also Debian based) was using some kind of (modified?) Wubi installer, I decided to try it anyway.

There are also known issues with a newer version of the Linux Mint installer.

Any info on that would be welcome, as it was my ultimate goal. Would an older version work?

In general, we know that Wubi(uefi) has never supported all special Windows disks.

Well, virtualizing the OS disk solves a long list of user worries related to ease of installation (no partitioning), system stability and backup. FYI, I haven't had to re-install Windows 7 since January 2015 -- that's the major reason why I am so keen in getting the same setup for Linux.

UEFI systems do not use wubildr and wubildr.mbr for booting.

Always good to know. But in keeping to the KISS principle, I only adopt a more complex solution if I can't make do with a simpler one. I could have moved to UEFI as both my computers support it, but I would gain very little with such increase in admin complexity.

Summing up, apart from the looming end of support for Windows 7, the reason I'm pushing hard a move to Linux is because I live by its old mantra of "do one thing, but do it well". :)

Thank you for all your work -- and for listening.

[hakuna-m]

I only adopt a more complex solution if I can't make do with a simpler one.

For Wubiuefi it is the simpler one:

• It should already work for UEFI systems because they use boot files on an EFI partition.
• The count of UEFI systems should increase because newer systems have UEFI by default. So the count of effected users should decrease in the future.
• The workaround for non UEFI systems is easy. I don't know if a fix for Wubiuefi is also easy.

If you want that I evaluate the complexity of a fix, I need logs from an installation with virtual disk issue.

So Wubiuefi has to recognize that there is a virtual disk environment (how?). Then it is necessary to copy wubildr and wubildr.mbr to another drive (which one?)

[midaspt]

I need logs from an installation with virtual disk issue.

I'll be sure to get you some in my next installation attempt. It might take a couple of days, though.

So Wubiuefi has to recognize that there is a virtual disk environment (how?).

I'm no expert here but a quick search pointed to 'libguestfs-tools' (RedHat) as a native Linux toolkit to deal with VHDs -- I'm sure other options exist.

Then it is necessary to copy wubildr and wubildr.mbr to another drive (which one?)

That's an easy one, I guess: it's the drive harboring the virtual disk -- in my case, under Windows, the virtual drive is marked "boot" and the host drive is marked "system".

BTW, would you be so kind as to check https://mir.cr/IIAKJHIM, where I mirrored an archive with the file structure (according to https://github.com/hakuna-m/wubiuefi/wiki#various-distrosversions) extracted from 'linuxmint-19.2-mate-64bit.iso' (Linux Mint Mate 19.2)?

[hakuna-m]

I'm no expert here but a quick search pointed to 'libguestfs-tools' (RedHat) as a native Linux toolkit to deal with VHDs -- I'm sure other options exist.

If we use your workaround (file copy of wubildr/wubildr.mbr) for fixing Wubiuefi, we need a fix under Windows.

IMHO, we need the fix here

        if drive is self.info.system_drive \
        or drive.path == "C:" \
        or drive.path == os.getenv('SystemDrive').upper():

Maybe, a solution is to copy wubildr to the root directory of the target installation drive, too. I assume that in your case the target drive was not C: or the system drive.

So only the first part of the boot sequence works:

Windows boot menu -> D:\ubuntu\winboot\wubildr.mbr

In the second part the virtual MBR (wubildr.mbr) reads a new view of your drives directly from BIOS which does not contain virtual Windows drives or Windows drive letters.There is only a very poor search for wubildr in the root directory of every found drive/partition.

So if virtual drive C: is not available, a non virtual target drive should also do the job..

BTW, would you be so kind as to check https://mir.cr/IIAKJHIM, where I mirrored an archive with the file structure

The better check is to try if self-assignment of a desktop environment is possible. If it is not possible the log should contain information about missing files.

[midaspt]

Maybe, a solution is to copy wubildr to the root directory of the target installation drive, too. I assume that in your case the target drive was not C: or the system drive.

If I understand this correctly, you're proposing to copy the files to multiple locations, which looks perfectly OK to me.

Given that under Windows the boot drive is always C: -- even if '%WINDIR%' may reside in a different drive and also because it's perfectly possible to have more than one volume inside a VHD -- it is safe to assume that, when Windows is no longer booted from its virtual drive, the C: drive allocation will shift.

You are correct then (you can check from the images in the Q4OS forum post linked from OP): when I boot Windows, the virtual drive is C: and the physical host drive is D:; when I boot something else, the virtual drive isn't mounted so the physical drive is shifted down to C;.

In the second part the virtual MBR (wubildr.mbr) reads a new view of your drives directly from BIOS which does not contain virtual Windows drives or Windows drive letters. There is only a very poor search for wubildr in the root directory of every found drive/partition.

The images I posted when I first got the error confirm this, all drives where indeed checked; the files weren't found because they were hidden inside the unmounted virtual drive.

The better check is to try if self-assignment of a desktop environment is possible. If it is not possible the log should contain information about missing files.

I see. You mean that I should boot the system first and then check for the relevant file locations. I will try to do that next, I now have the distro installed in a pendrive. Question is, this being USB, will a livecd install work or it needs to be a normal system install?

[hakuna-m]

If I understand this correctly, you're proposing to copy the files to multiple locations, which looks perfectly OK to me.

Yes, you understand this correctly.

Currently, there are also copies to multiple locations if Windows system drive is not C:. But some copies are obsolete. The path in Windows boot menu for wubildr.mbr points always to subfolder ubuntu\winboot on target drive. So the copy of wubildr.mbr was only needed for older versions of Wubi. We need only wubildr in a root directory of a drive/partition which is available. The root directory of the target drive/partition should be always a good idea.

You mean that I should boot the system first and then check for the relevant file locations.

I don't know what you mean exactly. Wubiuefi checks the file structure automatically during the Windows part of installation. There are Wubi logs. Wubiuefi cannot check completely if the Linux installer of the distro is compatible with Wubiuefi. So the Linux part of installation with Wubiuefi can still fail.

Note: Wubiuefi does not check if an installation without Wubiuefi is possible.

[midaspt]

We need only wubildr in a root directory of a drive/partition which is available. The root directory of the target drive/partition should be always a good idea.

Well, then, that could be the whole solution there. :)

In fact, as it's a single tiny file, it could be easier and safer to just place a copy it in every physical volume root folder -- preferably specifying the volume GUID notation where 'ubuntu\winboot' resides, instead of a shifting drive letter...

Wubiuefi checks the file structure automatically during the Windows part of installation. There are Wubi logs. Wubiuefi cannot check completely if the Linux installer of the distro is compatible with Wubiuefi. So the Linux part of installation with Wubiuefi can still fail.

I'm a little lost here but, as it's really unrelated to the issue above, I think I'll just open a different issue to carry on about solutions to make wubiuefi work with Linux Mint (to start with) and Debian.

[hakuna-m]

I added the change to source code. If we create an exe for r337 and above the additional copy of wubildr and wubildr.mbr to target drive should be enabled.

preferably specifying the volume GUID notation where 'ubuntu\winboot' resides, instead of a shifting drive letter...

IMHO, it is not necessary to change drive letter notification to volume GUID notification because the issue is a different view of drives/partitions. As long as Wubiuefi uses drive letters there is no shifting drive letter and Ubuntu does not use drive letters.

I think I'll just open a different issue to carry on about solutions to make wubiuefi work with Linux Mint (to start with) and Debian.

You are right. It is a different issue.

Note: In general, it is not possible to support all distros like Ubuntu. It is no problem to add a new layout (desktop environment) for Ubuntu based distros (for non Ubuntu based distros it makes no sense). But if a distro uses a modified installer which does not work with Wubiuefi, we cannot provide support.