used both methods, the /dev/sda and the ata name
okay, thatās annoying.
So letās step back a bit, and try making a VM with the created storage file, make sure that works?
like, paring back a few steps to see which way forward?
so i played with it some more and i noticed that if i add sda sda1 and sda2 and change their boot order the message i get changes as well.
the system itself sits on sda2 and the message are as follow depending on boot order:
sda -
Booting from Hard Diskā¦
No bootable device.
sda1-
Booting from Hard Diskā¦
Boot failed: not a bootable disk.
No bootable device.
sda2-
stuck on
Booting from Hard Diskā¦
for like 15-20 min strightā¦
and after checking the XML its exactly like you wrote to me under devices so i dont see the problemā¦
Right, okay, I have a last thought, but must retire for the evening.
In general, when windows is first normally installed, it sets up the boot sequence, right?
It gathers data about the computer, and the drives, and stuff, then sets the order and settings needed to load the OS.
So you have taken an existing drive, with all the boot setup which expects to be looking for a motherboard, hard drive, usb bus, memory channels and chipset and stuff,
but ripped that out, and wrapped it in the VM, confining it and isolating it from all that stuff.
So instead, the boot sector sees all the stuff provided by the VM, like Virtual ram, Virtual USB bus, virtual network card and stuff.
I think the bootloader is just a bit confused.
I would suggest, if you can, to copy the original drive to a temporary drive(hdd or virtual drive image), and play around āfixingā the startup section with a windows10 install ISO attached to the VM, and choosing the ārepair computerā option.
If you donāt have another drive to copy, and play with, then you Might potentially be able to try and fix the boot partition with the original drive, but you might not ever be able to boot to windows separate again, and changes will be permanent, and you should really practice first, if you can on a copied drive.
I know itās a pain, but that would only be if you donāt want to start from scratch.
Anyway, Iām off to bed, and wish you luck!
i installed a windows 10 from iso in the same virt-manager settings just nowā¦
i really donāt know why the /dev/sdb doesnāt work for me it really frustratingā¦
1 Like
Quick not for people supporting virt0manager here.
It does support editing the XML directly in virt-manager.
virsh would be needed only to change the schema.
Regarding the problem - I believe your Windows installation is using UEFI and it is either not located on the same drive or you have created a VM that does not support UEFI.
Please fill in the following:
- Does your PC boot into windows right away and shows the wheel of death? (Rotating dot pattern)
- When you created the VM in the virt-manager, did you select that it will be Win10?
- In overview of the VM, does it show: Chipset: Q35 and Firmware: UEFI
- When you installed Win on your computer did you have any other drives in it?
- Is there a small 100MB partion on the SSD you are trying to push?
- no, my PC boot order is as follow:
BIOS, Password from encrepted Manjaro, GRUB menu, Manjaro/Windows 10(selected from the GRUB menu)
the windows 10 works just fine from GRUB, im writing this message on it right now. - i selected it as windows 10 and as generic, it doesnt do anything.
- yes
- no.
- yes its called /dev/sdb1, the system itself is on /dev/sdb2 but i already tried pushing /dev/sdb, /dev/sdb1 and /dev/sdb2, /dev/sdb and sdb1 and sdb2, /dev/sdb1 only, /dev/sdb2 only
nothing worked.
EDIT:
ok i just checked and the Firmware was on BIOS, changed it to UEFI and now i get this from running the vm:
Now that is on UEFI it matters how you passed it and what is setup in the boot section of the virt-manager. Try to pass the entire drive as raw using SATA (For sata drive), then make sure it is selected for boot.
it doesnāt matter, even if i pass the entire drive as raw using SATA its still gives me UEFI Shell.
look at the settings:
this is the XML:
> <disk type="block" device="disk"> > <driver name="qemu" type="raw" cache="none" io="native"/> > <source dev="/dev/sdb" index="1"/> > <backingStore/> > <target dev="sda" bus="sata"/> > <alias name="sata0-0-0"/> > <address type="drive" controller="0" bus="0" target="0" unit="0"/> > </disk>
Looks like the efi shell just needs to know where the boot program is.
Looking for BOOTX64.efi or something
You might try entering these in the efi shell, (the bit after the > arrow)
SHELL>cd BLK2
FS1>dir
#(then it lists the directories, we want either efi then boot or boot then efi, not sure which)
FS1>dir efi\boot\ # or dir boot\efi
#lists contents. we need an efi file, if I remember, it's called bootx64.efi
FS1>cd efi\boot\ # might not need to actully load the directory first
FS1\efi\boot>bootx64.efi
If the bit in front changes from SHELL> thatās fine, even if it changes to BLK2> or FS0>
if the dir commands wirk, but no efi or boot folder, try the other blk device/file system?
if i try to cd or ls it gives me:
Current directory not specified.
Ah, try
BLK2:
first, to select device
or
BLK1:it just drops a line:
Shell>BLK2: (enter)
Shell>
Shell>BLK1: (enter)
Shell>
Shell>BLK0: (enter)
Shell>
can you LS or cd after?
nope
without the colon?
with out the colon it gives the usual error āāBLK2ā is not recognized as an internal or external commandā¦ā
what if you attach the windows ISO to the VM, set it as first boot priority, and see if you can boot that way?
I fonly to the CD menu?
it might have a "repair boot " sub menu?
Unless you already triedā¦
Huh, it seems if there is no FS listed, then the efi shell does not recognise the file system.
the fact it lists BLK devices points to it seeing partitions, but not in a format it recognises.
Thatās odd, considering it boots direct from the metal outside the vm
