I think that an option to check compatible hardware is useful, and as far as i know since the installer starts xen this is a good way to check if Qubes OS is compatible (not perfect because here installer starts good but stops when creating net-vm because of wifi driver problem) for example, if i buy new pc i will: -get model info at the shop (and mostly online) -ask someone at the shop "can i plug this usb key and boot?" -->checked if Qubes is compatible
what about removing xen (which seems that makes many tasks easier) and add a boot option "check compatibility" which starts xen and display: "hello from xen: it works; vt-x present; vt-d missing; tpm missing;" forgive me if what i'm asking is no-sense and if this is too much off-topic, i'm new to mailing lists Il 03/11/2016 21.13, Marek Marczykowski-Górecki ha scritto: > Hi, > > Currently Qubes OS installer is starting full Xen + Linux dom0 to > perform installation. On one hand it is good, because it is obvious at > this early stage if hardware is not compatible (especially display > driver and its cooperation with Xen). But on another hand, it is IMHO > much easier to fix such problems having the system already installed. > When even installer does not start, in most cases the only alternative > is trying other installer (in extreme case - building custom > installation image). Also, starting Xen for installation require some > effort when preparing the installer (see below). > > Initially running Xen was needed because all qubes tools crashed when > running without it - for example most of the tools do check running VM > list and of course there is no such thing when running without Xen. > But since Qubes OS 3.0, it is no longer the case - we have introduced so > called "offline mode" to perform those few tasks (create initial > qubes.xml, register installed template(s) etc) without need to launch > libvirt daemon in chroot environment there. All the tasks really > requiring Xen running are performed during first boot. > > Long story short - technically Xen is no longer needed during > installation of Qubes OS. Or at least is very close to such state. > > So, now the question - do we want to keep launching Xen for > installation, or launch just plain Linux? > > Benefits of keeping Xen: > - earlier (negative) confirmation of hardware compatibility > - possibility of (re-)introducing later something that require Xen running > during installation > - rescue mode have Xen running (but not libvirt), which may ease some > tasks > - no need to change anything related to ISO build, at least not right > now > > Benefits of dropping Xen: > - no longer limited to 32MB of initrd for UEFI boot[1] > - easier starting installation in non standard environment (network > boot, non standard installation media) > - ability to use almost any tool to write USB installation image (most > of them, like unetbootin, generously setup a bootloader to launch > _linux_ image found in the ISO image) > - better changes to install on not perfectly compatible hardware and > easier way to adjust the system afterwards (like - get at least > command line access and upgrade the kernel) > - less work when upgrading to new installer version (as part of > upgrading dom0 distribution) > > [1] > https://github.com/QubesOS/qubes-issues/issues/794#issuecomment-135988806 > > PS I'm writing this exactly because of the ticket linked above - I hit > this problem again when building some Qubes OS 4.0 test images... > > -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/6ba56e06-b589-1932-927e-339560a4a48f%40posteo.net. For more options, visit https://groups.google.com/d/optout.