On Friday, February 23, 2018 at 8:35:00 PM UTC+1, Daniil .Travnikov wrote:
> пятница, 23 февраля 2018 г., 14:07:38 UTC+3 пользователь awokd написал:
> > On Fri, February 23, 2018 10:46 am, Daniil .Travnikov wrote:
> > 
> > EFI is a bit different, not sure you get a Troubleshooting menu there. If
> > not, see
> > https://www.qubes-os.org/doc/uefi-troubleshooting/#change-installer-kernel-parameters-in-uefi
> > for how to edit the configuration directly on the installer.
> Many hours spent on this situation. I already changed my BOOTX64.cfg like in 
> guide:
> ---
> Edit /mnt/sysimage/boot/efi/EFI/qubes/xen.cfg and add to every kernel section:
> mapbs=1
> noexitboot=1
> ---
> And still nothing.
> What else could it be? It is very strange, because Qubes 3.2 working fine 
> with one of the kernels, but newer version in some reason won't work.

There is another way you can try fix this, that "might" work. I'll elaborate. 

Considering it's server hardware, I wonder if it's a similar problem for some 
server categories in general? I have at one point tried to install Qubes on a 
ProLiant Microserver Gen10, which resulted in a very similar experience to 

>From memory, I recall HVM working, while I/O MMU did not, pretty similar to 
>yours. I may have an untested solution, but I never got around to testing it 

Using it, I believe you can make it work if you change all your VM's to 
visualization mode "PV" instead of HVM or PVH.

I never got as far as to test that though, but think about it for a moment. HVM 
had PCI issues in early Qubes 4, it does PCI pass-through differently from PV 
mode and as far as I understand it, it relies on I/O MMU to work. PVH currently 
can't use PCI pass-through. Which leaves PV mode, which is also what Qubes 3.2. 

Since you have trouble getting the installer to work and install Qubes, you may 
not be able to do this fix on your local hardware. You may have to pull out the 
drive, put it in another computer and install Qubes there. Update everything, 
and then make sure you put sys-net and sys-usb in PV mode with the "qvm-prefs 
virt_mode" command in dom0.

Now because sys-net and sys-usb are in PV mode, it may be able to bypass the 
missing I/O MMU issue, which as far as I understand it is related to PCI 
pass-through. That's why you want sys-net, sys-usb and any other hardware that 
is pass-through to be using PV mode.

This isn't a beautiful fix, but it may just work. It's not the first time I've 
fixed a Qubes 4 install with this approach, however, I have not yet tried it on 
this server hardware, which like yours is missing I/O MMU. I believe it might 
work, but it might also not work. While installing on another machine has in 
the past worked, I never tried to use it to change sys-net and sys-usb to PV 
mode before putting it back.

This might also be what makes the difference between Qubes 3.2. and Qubes 4.0 
for you, considering Qubes 3.2. uses PV mode, and Qubes 4.0 uses HVM for 
pass-through and otherwise PVH for everything else. Considering you have no I/O 
MMU, it might not be surprising? that Qubes 4.0 doesn't work for you when not 
in PV mode.

If you use this approach, then be careful you don't wipe out any other drives 
or EFI settings on the other machine during install, take precautions against 
it. Also it's far easier to use LegacyBIOS/Grub, so you don't have to mess with 
EFI paths when bring the drive back.

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to