*Some useful info about 90 seconds delay*

[0xhellord]

I had research and work on diskless development for many years, the 90 seconds delay(on some version is 30 seconds) can be "fixed" by set all ndis/wfp filter drivers to boot start, or unbind all of them from all eth NICs, or completely uninstall them. (details in the TODO file )

Note:

I haven't try these on windrdb, because I'm not familiar with drbd server setup, but according to my experience on diskless, I think the solution in the TODO file will work.

If it doesn't work, let me know.

Signed-off-by: hellord hellord@hidden.xxx

[0xhellord]

And more:

1. If users install thrid party ndis filter drivers, the drivers also need to be set to boot start;
2. Better to have a bus filter driver which attach to all NICs(at least boot NIC), and force all irp_mn_query_remove and irp_mn_remove request fails. This doesn't relate to 90 seconds delay, the purpose is to make windows works more stable in some special case, such as the user may need to update NIC drivers, with out this bus filter, windows will hang; and in a few cases, windows will hang when shutdown or reboot)

[johannesthoma]

Hi 0xhellord,

Thank you very much for the useful info. Since we also observe a shutdown hang which I could not explain to date I will try the things you suggested. Please give me some time I will get back to you via github when I need something, Thanks for your contribution,

Best regards,

• Johannes

[0xhellord]

Yes, sometimes it's hard to debug why OS run into hang state. Many reasons, such as pending IRPs, or missed IRPs, or not missed but we doesn't handle it properly, especially PNP/Power IRP, without OS source code, we have to use debugger/log/verifier/checked build windows to find out what happened..... really a diffcult work!

[johannesthoma]

Thanks for your contribution! I will try what you suggested in the next weeks (still fixing HA bugs ...) I will keep you updated via github.

• Johannes

[johannesthoma]

Hi there, I finally found time to try what you suggested ... the WinDRBD device in Windows Setup appears (after some command line magic) but Windows thinks the device is not bootable: I am attaching a screen shot.

The command line for starting the WinDRBD driver and the root resource is (you also need to set up a DRBD resource on Linux):

wpeutil initializenetwork
wpeutil disablefirewall
# or whatever your WinDRBD CD is ...
d:
# this should load the driver. If you have an unsigned driver
# spress F8 at early boot and then select Disable driver signature
# enforcement.
windrbd install-bus-device windrbd.inf
# This URL is just a sample. It should match your (Linux) WinDRBD
# root resource
# If you booted via local CD ROM (which you should, else Windows
# tries to locate a CD ROM driver which does not exist, so
# do not serve the CD ROM via iPXE ...) you need this:
windrbd create-resource-from-url drbd:resource=windrbd-install-windows7-2;protocol=C;this-node-id=2;node1.address=192.168.56.102:7694;node2.address=0.0.0.0:7694;node2.hostname=windows;node1.hostname=johannes-VirtualBox;node2.volume1.minor=42;timeout=60;ping-timeout=30;ping-int=10;connect-int=20;syslog-ip=192.168.56.102
# to check if resource is there ...
drbdsetup status
x:
# from sources dir ...
setup

If you have any idea what is causing Windows think the BIOS cannot boot from this device that would be great. I will go ahead and check the source code for PnP and DeviceControl settings, maybe I did something wrong there ... also I will check the RedHat virtio driver, it is possible to install Windows directly on top of a vioscsi disk.

Thanks again,

• Johannes

[acidrop]

Hi Johannes,

Sorry to jump in into this conversation, but I thought it may be interesting to give it a shot. I've booted from Windows 10 Setup (ISO), switched to command prompt (Shift+F10) and then executed all commands one by one, but I'm stuck at this step...

"windrbd install-bus-device windrbd.inf"

Any ideas what I'm doing wrong ? I created a windrbd.iso image manually from an existing windrbd installation on a different machine, then placed all its content within the iso file, not sure if that's the correct thing to do though. I just presumed that's what you meant by "WinDRBD CD" on your instructions. :-)

Yannis

[johannesthoma]

Hi Yannis, thank you for trying this.

The issue you face can be solved by obtaining an updated version of CygWin ... I have to update it frequently and haven't done so recently. The easiest way is probably to update CygWin and then copy the newer binaries into a folder, something like

bash$ for i in *.exe *.dll ; do cp $( which $i ) . ; done

or so and then creating a new ISO should do the trick (provided . is not in the path)...

Thank again and don't hesitate to reach out if you need help,

• Johannes

[acidrop]

Thanks, that worked. I managed to get past of the "Windows cannot be installed to this disk" error too. Apparently Windows thinks that WinDRBD disk is both "offline" and "read only", so I had to change both those values with "diskpart" utility. After that, Windows installation continued without issues. Now I'm stuck at the 2nd stage of the installation, once the installer reboots, it expects the setup to continue booting from the "installation disk". However, I'm a bit unsure how I can setup WinDRBD to PXE boot in UEFI mode ? I've done it successfully in the past in MBR/Legacy mode, but that process does not seem to work in UEFI mode. Any ideas ?

Thanks, Yannis.

[johannesthoma]

Oh wow this is good news thank you so much for solving this. Just an idea: is there a WinDRBD driver installed on the image? Does loading the Windows driver work, or does iPXE fail to load Windows?

Thank you for looking into this, I will try it myself later,

Best regards,

• Johannes

[acidrop]

I believe that the WinDRBD storage driver "should" be installed, as I loaded it (.inf file) during the Windows setup stage, otherwise Windows would not be able to detect the hard disk at all. It's basically iPXE failing to load Windows after rebooting (EFI bootloader, kernel etc) which I'm stuck at the moment. Here's a screenshot...

[johannesthoma]

Ohh .. I never tried this. What you want is something that loads a patched iPXE from some server (for example via http) and runs it which then passes the WinDRBD URL via ACPI to the WinDRBD kernel driver. I think you already did download this but it looks like this iPXE is never executed .. hmmm .. http boot over IPv4 looks good but is it the UEFI firmware that runs it or the iPXE WinDRBD patched? I will try to reproduce the issue when I am back to the office after chrismas (probably around the December 28th).

Is there a legacy BIOS boot option? Does it work with this one?

Best regards,

• Johannes

[johannesthoma]

Is it an OpenSource UEFI implementation? I then will try to install it on my VirtualBox VMs or on a hardware box.

[acidrop]

http boot over IPv4 looks good but is it the UEFI firmware that runs it or the iPXE WinDRBD patched?

It's the UEFI Firmware.

Is there a legacy BIOS boot option? Does it work with this one?

Tried that too, but it does not seem to work either. Moreover, in BIOS boot mode I could not get past of the disk partitioning during Windows setup (same issue you posted on your original reply). It looks like the disk partitioning works only in UEFI mode for some reason. By the way, this (disk partitioning) issue does not seem to be windrbd related, as I could reproduce it also when attaching the vdisk directly on the VM via vioscsi controller. Only option that works, seems to be IDE controller.

Is it an OpenSource UEFI implementation?

It's Alma Linux 8.7 + Virt Manager/QEMU, but I tested it on other implementations too, same result (Proxmox VE). Might try to test it on a physical system once I get back from the holiday break.

I will try to reproduce the issue when I am back to the office after christmas

No worries, this is not urgent. Enjoy your holiday break and merry xmas to the whole team! :-)