maharmstone / quibble Goto Github PK

I'm trying this project to boot windows 10 with btrfs as root on real hardware, unsure if this is even supported but I'm getting an error.
The only odd thing out is that I'm using an unofficial minimal windows iso install to speed up installs etc.

ARC name is btrfs(1f9da0e7-7228-7753-373a-54e2e4a73f76).
Loaded ntoskrnl.exe fffffeoo 0000000.
Booting NT version 10.0.19041.172.
Loading NLS file c_1252.nls..
Loading NLS file c_437.nls.
Loading NLS file l_intl.nls.
Loading inf\errata.Inf.
Using tm.sys Instead of ext-ms-win-ntos-tm-11-1-0.dll.
Using clipsp.sys instead of ext-ms-win-ntos-clipsp-11-1-0.dll.

....

Loaded storufs.sys at fffff80802b98000.
Loaded Intel TA.sys at fffff80802baa000.
Loaded volume.sys at fffff80802bb5000.
Loaded Windows TrustedRT.sys at fffff80802bco000 
Loaded Windows Trusted Proxy.sys at fffff80802
Loaded crashdmp.sys at fffff80802be2000.
Loaded tm.sys at fffff 80802000000
Loaded MASHED.d11 at fffff80802c27000.
Loaded BOOTVID.dll at fffff 80802041000
Loaded clipsp.sys at fffff 80802040000
Loaded kdcom.dll at fffff80802d5f000.
Loaded cmimcext.sys at fffff80802d6d0oo.
Loaded werkernel.sys at fffff80802d7b000.
Loaded ntosext.sys at fffff80802d8c000.
Loaded CI.dll at fffff80802d98000.
Loaded msrpc.sys at fffff80802e79000.
Loaded WDFLDR.SYS at fffff80802edbo00.
Loaded SleepStudyHelper.sys at fffff80802eee000.
Loaded WppRecorder.sys at fffff80802ef dooo.
Loaded WMILIB.SYS at fffff80802f0e000.
Loaded CEA.sys at fffff80802f 1a000.
Loaded PCIIDEX.SYS at fffff80802f33000.
Loaded CLASSPNP.SYS at fffff80802f46000 .
Loaded storport.sys at fffff80802fb2000.
Loaded NETIO.SYS at fffff 80803062000
Loaded ataport.SYS at fffff808030f 2000.
Loaded fupkcint.sys at fffff 80803136000
ext-ms-win-ntos-ksr-11-1-1.dll not found in API set array.
ACPI table at 57d600c8 error - cutting into non-free mapping

_{(log made by googles' text scanner so not 100% correct)}

Can you add support for Windows 10 Insider OS dev builds

Just tried to get 21H2 booting without much luck.
ntfs2btrfs was successful and I can mount the btrfs volume from Linux. I compiled HEAD and added /ONECPU to the boot options which fixed another issue I was seeing. However now I am getting a BSOD with 'INACCESSIBLE_BOOT_DEVICE' and just before this, 'ext-ms-ntos-ksr-l1-1-1.dll not found in API set array'. Some research suggests this module is something to do with kernel soft reboot? Which doesn't seem to be supported by Windows 10.

Let me know if I can test/try anything, happy to provide more info.

Ignore.

Hi, I don't want to switch to btrfs can I use the quibble on existing windows 10 on vmware?

I'm not quite sure if this is the best place to put this, but I figured the issues page is probably a good bet.

I did something similar to this for a project called UbWI (Ubuntu Windows Installer, like Wubi but the other way around). However, instead of writing a clean re-implementation of the Windows EFI bootloader blobs, I opted for a much-more cumbersome method of injecting hooks at known offsets using a separate EFI application, then wrapping file IO commands to a custom loop device driver which exposed an NTFS image file from an ext4 partition as a distinct virtual "disk" to bootstrap the NT kernel. While the kernel driver portion of the project is still a work in project, stage 1 worked well enough to kickstart ntoskrnl until it panicked.

Do you have anything like this in the works for quibble? If not, what is your stance on adding it? For reference, I'd be happy to re-license my existing EFI work under the LGPL.

Would be great once the ZFSin driver (https://github.com/openzfsonwindows/ZFSin) matures (it seems to be almost there)

Windows XP starts and reaches bootvid, but eventually BSODs with PROCESS1_INITIALIZATION_FAILED. Both Quibble 20200213 and XP build 2600 (no service packs) are under FAT32 partitions. Under Quibble 20210111, XP does not reach bootvid at all.

The original installation boots to desktop when using the SeaBIOS CSM directly.

Please add support for classic BIOS.

Hello,
Just tried to boot Windows using Quibble 20210111 and 20201108, but got:

1. With /DEBUG:

Booting Windows...
...
Loaded fwpkclnt.sys at fffff808034b0000.
ext-ms-win-ntos-ksr-11-1-1.dll not found in API set array.
ACPI table at 7fbf90e8
...
error - cutting into non-free mapping

than it hangs.

2. Without /DEBUG:

ARC name is btrfs(fa15...).
OpenSubvol returned EFI_NOT_FOUND

than it hangs.

Also tried 20200405 and 20200213:

1. With /DEBUG:

ARC name is btrfs(fa15...).
OpenSubvol returned EFI_NOT_FOUND
Opening

than it hangs.

2. Without /DEBUG:

ext-ms-win-ntos-ksr-11-1-1.dll not found in API set array.

It automatically reboots.

My configuration:

[Host]
Laptop: MSI Bravo 17
CPU: AMD Ryzen 7
OS: Ubuntu 20.04 x86_64
uname -a: Linux msi 5.10.0-1016-oem #17-Ubuntu SMP Mon Mar 1 18:06:30 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Hypervisor: KVM + QEMU + LibVirt
QEMU emulator version: 4.2.1 (Debian 1:4.2-3ubuntu6.17)
LibVirt version: 6.0.0

[Guest]
OS_1: Windows 10 21H1 Professional for Workstations x86_64 (error - cutting into non-free mapping)
OS_2: Windows 8.1Pro x86_64 (error - cutting into non-free mapping)
OS_3: Windows 7 MSDN-2020 Ultimate x86_64 (automatically reboots without any error)
EFI: OVMF_CODE64--seabios.fd (from the README.md)
FS: BTRFS (converted fron NTFS via ntfs2btrfs)
BTRFS driver version: 1.7.8.1
Quibble version: 20210111; 20201108 (error - cutting into non-free mapping)
Quibble version: 20200405; 20200213 (with /DEBUG hangs on "ARC name is btrfs(<UUID of partition>).")
Quibble version: 20200405; 20200213 (without /DEBUG reboots automatically)

What am I doing wrong?
How to solve this problem?

UPD 1: Tried the same with Windows 8.1 x86_64 & Windows 7 x86_64 and got the same result, but in case of Windows 7 instead of displaying error - cutting into non-free mapping VM shows boot log, without any error and automatically reboots.

UPD 2: I can add links to videos with the boot process, if it will be needed.

UPD 3: Tried all 4 existing releases of Quiblle. Didn't help me. Result is still same.

... and SecureKernel too perhaps?

On ArchLinux quibble fails to build due to CMAKE_SYSTEM_PROCESSOR being x86_64 instead of AMD64 (as, I persume, you expected) in CMakeLists.txt.

Please consider fixing this.

I've tried everything I can think of, but it just results in hanging with a black screen: using the onecpu flag, booting from arc address and reinstalling windows 2004 instead of 2010. Any ideas? I have an HP Pavilion 15-au111TX, without the recent BIOS update (to F.55) as the motherboard had to be replaced and HP updater now disallows it. (HP also detects it now as a Pavilion 15-158TX)

Hi,
Initially I continued the ReactOS issue, but I find the same error on Windows XP, so I'm opening a new one.
I installed Windows XP on a MBR disk, then I converted it to GPT, added an EFI partition and converted NTFS in BTRFS with your tool. Sadly quibble returned the error in the title. A similar things happened on ReactOS. I installed it on BTRFS (MBR disk, ROS doesn't support GPT yet), added an EFI partition and tried to boot with quibble.
The systems are virtualized on qemu and as firmware I used OVMF with CSM support, built for 32bit.
I link a screenshot, hoping it could be useful.

I'd need to tinker with it, but I'd also need a little information, but let me start out by explaining how this could be done. I'm no stranger to editing WIM files, which is the "disk image" that Windows uses during installation to both boot and install the system. I'm not sure, and seriously doubt, that simply ploping the sys file into the WIM image would be enough, as I'm sure there's a number of registry edits that would be needed, but, is Quibble capable of booting a WIM file currently?

If not, all that may be necessary to allow the installation to occur is to simply inject the driver into the WIM, and then load the installer using Quibble. Beyond that, maybe using one of the various methods of modifying the installer itself might be required to replace whatever script it's using for formatting the drive in whatever way MS deems appropriate to instead use btrfs and leave most everything else the same.

There may be a need to add a post-install script to move Quibble itself into the boot partition and make the changes nessecary for it to look at the new installation, but ultimately it should be a process that's been done many times before for customized Windows installations. Not exactly hard, but definitely time consuming and with plenty of trial and error.

There are some tablets/cheap laptops with an x64 capable processor, that are crippled by 32 bit UEFI firmware, thus these can boot 32 bit Windows only. Could it be possible to load 64 bit Windows on 32 bit version of quibble (reverse of what is mentioned in To-do list)? Thank you for your work in any case.

How do I go about installing it in that OS?

Hello,

I tried booting Windows 10 1909 amd64 on a VM with NTFS drivers, but failed.

With https://efi.akeo.ie/ I ended at

With the rEFInd driver I was able to go a little bit further, but also without any great success:

Did anybody manage to boot Windows on NTFS? If yes, what drivers did you use?

I haven't tried quibble yet but I wonder if it support the file system drivers of rEFInd: https://sourceforge.net/projects/refind/
They are separate files.

Considering that it has EFI drivers for ext2/3fs, ext4fs, ReiserFS, HFS+, NTFS, and ISO-9660 it may be interesting adding support for them (if they aren't already supported).

I am able to get it to boot up to what is most likely the login screen. It's just a black screen, but the mouse is able to be moved around. When it is first booting up, it says that some file seems to be missing.
EDIT: It says ext-ms-win-ntos-ksr-l1-1-1.dll not found in API set array.

Hello,

I have added the Btrfs driver from this repository to my motherboard's UEFI using UEFI Tool and flashrom, and have been using it to boot Arch Linux from my SSD without a partition scheme (formatted the whole thing as Btrfs), however, I have noticed that upon enabling Ultra Fast Startup in my motherboard's configuration utility, it no longer results in any noticeable decrease in boot time, taking around 13 seconds to get from the firmware to the kernel according to systemd-analyze, vs only around 4 without the driver

This is more to document behavior than a bug (as I'd assume this is outside of the project scope) but Windows 2000 (Service Pack 4, build 2195) does not currently boot due to a lack of support of registries using CM_KEY_FAST_LEAF for indexes.

I can't run quibble-20200405.zip/amd64/quibble.efi from x64 EFI shell, but the one in quibble-20200213.zip can be run.

And the file size is weird:

• quibble-20200405.zip/amd64/quibble.efi (original) size: 144,376 bytes
• quibble-20200213.zip/amd64/quibble.efi (original) size: 411,610 bytes

I saw in the source code that 1909 (well, 1903, but since 1909 uses the same values) is the highest supported Win10 version - how do you find these values? I have a ntfs2btrfs-readied partition with Windows 10 2004 to test with, but I'm not sure how boot.c should look for it to find windows 10...

Great work, by the way!

I wanted to try btrfs + quibble in VMware Workstation 16.

What I did:
First, I made 2 Windows 10 VMs with BtrfsWin installed.

I powered off VM 2, attached the virtual disk to VM 1, ran ntfs2btrfs and rebooted to make sure everything is still on there, which seemed to be the case.

Then, I mounted the ESP of the target VM, copied the quibble files into the ESP's root, unmounted the ESP, and shut down.

I then booted up the target VM, chose "Boot from file" and selected quibble.efi, which opened fine and hit enter.

Sadly, this is all I'm getting.

Problem with quibble, problem with the VMware EFI or a layer 8 issue ;) ?

Edit: Now I had a new boot device and it "worked" a little bit (No Quibble UI, Automatic repair and BSOD)

ReactOS support as well?

Does Quibble work with Windows 10 20H2? Tried a fresh iso (Enterprise) from today on a Dell XPS 12 2in1 laptop, and contrary to last time I tested Quibble, Quibble itself works now, and seems to load Windows' files just fine, but the machine freezes after "Booting Windows..." (nothing happens). Tested with /DEBUG and /DEBUG /ONECPU, and with CSM module both loaded and unloaded..

Any tips to something else I could try?

It looks like this:

WoA is a thing, perhaps this would help ReactOS too.

I tried to boot Quibble from efi shell, but the timer events seem to be unsupported on my BIOS-es EFI build.

Possible workaround: Disable the timer alltogether in freeldr.ini

Hi, thank you for this projet!
I wanted to ask if a Ext4 support is plan and if I can help with that ? In a dual boot with Linux cenario, even if btrfs is already a good alternative to ntfs.

Does this bootloader enable NT5.x booting from EFI?
Vista winload.efi does support booting NT 5.x IA-32 (with a IA-32 winload.efi from beta2-level) and x64 to some extent, not sure if quibble can do that too.

I've been getting this "Unable to parse ARC name" error.
The OS is Windows 8.1 (as Windows 10 loves screwing with me) and i'm using the provided OVMF binaries on QEMU. I think i've messed something in the config.

also i'm using the first version because the new release doesn't really work

Virtualbox 6.1, Windows 10 19041 x64, rEFInd 0.11.4 NTFS driver

BSOD: DRIVER_IRQL_NOT_LESS_OR_EQUAL

WinDbg KD output:
BTRFS VM
NTFS VM

Both reach Booting Windows... and both display ext-ms-win-ntos-ksr-l1-1-1.dll not found in API set array.

Things to note:
I couldn't find Fast boot option in settings or control panel.
I tried booting with quibble right after selecting restart in Windows.
NTFS Quibble output is quite longer and it takes quite a bit more time to boot.

using the ovmf in the readme - updated system - qemu 5.2

https://youtu.be/caFw2LjI5ek

Many years ago, I installed and started Windows on the exFAT partition, but only supported Windows 8 and above, I hope this project can support exFAT to boot Windows 7 and below.

exFAT boot preview

This is a detailed installation tutorial I wrote in Simplified Chinese (because I am from China)
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=388226&mobile=no
I appologize for my grammatical mistake because English isn't my main language.

I have a bcache partition formatted to btrfs with windows installed to a subvolume on that partition. I'm not exactly sure how I would add quibble.efi to my UEFI boot options. I rather create a GRUB menu entry for it, but there's no documentation on how to do that.

Could you please mention in the Licence part of Readme, that you used some parts of ReactOS Freeloader code?

Is it possible to somehow utilize dism and/or wimlib for copying the NTFS Windows install to btrfs partition?

I'm trying to boot Windows XP x86 in Virtualbox. This is the error i get:
Could not open Windows on volume.
Open returned EFI_NO_MAPPING
boot returned EFI_NO_MAPPING

freeldr.ini is default, except with Windows line endings. XP's boot.ini contains the same multi(0)disk(0)rdisk(0)partition(1)\Windows as freeldr.ini
Windows XP is installed on an NTFS partition and i'm using this driver placed in the driver folder next to quibble.efi. Quibble files are on an another virtual hdd, fat32 formatted, at the root directory.
I saw no mention of CSM anywhere in Virtualbox settings nor UEFI menu and I do get the pretty font.

is it possible to make it compatible with ReFS partition ?

I'm testing to boot btrfs with a self-compiled WinBtrfs, and I just wondered if Quibble supports booting Windows with testsigning on (booting as you did a bcdedit /set testsigning on)?

Is this possible? Is it just an argument like /DEBUG ? Maybe /TESTSIGNING?

Since I had problems with ntfs2btrfs, I just copied all the files from my Windows partition to a btrfs subvolume. I got into quibble, and it had a bunch of lines about loading from different memory addresses, but when it finished, my computer just reboots.

On both VirtualBox and QEMU the default boot option doesn't work and just gives a
OpenSubvol returned EFI_NOT_FOUND

But when booting through the Debug boot option it starts loading everything but once it reaches "Booting Windows.."

VirtualBox get a Guru Meditation error. Here is the logfile
w1nbtrfs-2021-04-26-12-59-50.log

And QEMU (using OVMF for efi) just simply reboots.

Using a Windows 10 2009 and simple used cp to copy the files to a btrfs partition.

I also tested it on a Laptop with UEFI firmware but it just gets stuck at "Booting Windows..."

I would like to point out that an identifier like “_EFI_QUIBBLE_PROTOCOL” does eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

Hello,

AFAIK, this is the first bootloader that is able to boot Windows directly. All other bootloaders/bootmanagers I now are just chaining bootmgfw.efi.

Is there any publicly available documentation on how to boot Windows and Windows boot process? If not, would it be possible to document that?

please open/setup the Github sponsor page, so people could support you or the project

When playing around with quibble, I find myself constantly trying with different ARC names to find where my Windows install is.
It would be helpful to have a simple tool to list all the devices it finds, in ARC naming scheme, like ls in grub2 or map in EFI shell.
Just partition size and location (which disk the partition is in) should be enough for the first version.

It would be nice if a program/batch was made to install it to a drive so it can be used/tested by more people.

I want to use quibble in 16-bit real mode.
And does Quibble now support Squashfs, Aufs /overlayfs, EROFS?

OVMF's QemuVideoDxe contains VbeShim which emulates a bare minimum VESA BIOS to get Windows 7 to boot without CSM.
And there is VgaShim which enables the same feature on generic UEFI hardware (oddly enough it does not work with neither QEMU nor Virtualbox).
How about incorporating VbeShim into quibble and remove CSM dependency?