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 yours. >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 >out. 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. uses. 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 https://groups.google.com/d/msgid/qubes-users/2d647d70-ec41-4149-ab8f-3048fd8e0506%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
