[wip] nix_flakes support #14
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "mwojcik/wfvm:nix_flakes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I was about to say that I'm done... exported makeWindowsImage functions, layers, utils as used by nix scripts, moved everything to the flake, updated win10 iso/vs community hashes; however it hangs though after a while on
RESTRICTDIST-windows.img> qxl_send_events: spice-server bug: guest stopped, ignoring
Full log:
So in current state do not merge, any clues how to go about the issue would be appreciated
flake.nix
, nor is it desirable. Can you try to stay closer to the original organization? Would also help review.Might be useful to bisect the problem.
Is there a URL with a fixed version of the ISO download?
Even on downgraded nixpkgs it still hangs, same place just without the error noted.
Could be the different Windows ISO perhaps?
I put the original one in your home folder. xks67i4frg8k7rmlv5298aac0s4n5nih-RESTRICTDIST-release_svc_refresh_CLIENT_LTSC_EVAL_x64FRE_en-us.iso
How long should it take? Doesn't seem like the older ISO helped, but maybe I should leave it on for an hour or two.
If you use the "impure" mode to debug, you should be able to see the VM screen.
Would it make sense that it's actually stuck on the OS choosing screen? MS may have changed the installer's behaviour...
It's supposed to do a fully unattended install based on the provided XML data generated by wfvm/autounattend.nix. But just like a lot of Microsoft software, the XML parser for such installs is crippled with bugs and other problems; obscure failures without an error message are common. Those were sorted out before though, and the ISO I gave you is supposed to install without such trouble. Are you sure you are still generating and feeding the XML data exactly as before?
Yeah, the XML data should be fed, I haven't changed a thing from the previous file and the bootstrap img file is still created.
All the files called by qemu-system-x86_64 are present, autounattend is created too, but qemu itself is still complaining about missing files? Could that be the issue, that it's not actually seeing the XML file?
Although newer ISO first complained about being unable to read
<ProductKey>
from the unattend file, but then throws this error anyway:Just realized that it's stuck at that because the image name doesn't match. Replaced the name in autounattend with index.
Image will now build but now it's stuck at DisablePasswordExpiry.
However, this also seems to be the case for the non-nix build process:
Did you let it retry? Sometimes it takes a few attempts.
I let it run for the entire 600 seconds, to no avail.
Checkout
From your project repository, check out a new branch and test the changes.