Debian in dom0

[mfc]

We have discussed this numerous times but don't have an issue to track these discussions. It would be worth understanding what would be needed to change dom0 from Fedora to Debian (say Debian 8). Benefits include:

• increased hardware compatibility
• incorporate serious work taken towards reproducible builds
• better firstboot installer
• better (slower) release cycle than Fedora with longer-term support
• other things?

This ticket does not encompass modifying the desktop environment.

[andrewdavidwong]

The other issue about changing/upgrading dom0's OS: #1807

[andrewdavidwong]

The other issue about changing/upgrading dom0's OS: #1807

[TNTBOMBOM]

the problem is , why anyone would take fedora which is very known for its issues (from about 2000) and their enterprise lockin on the code (redhat sucking stuff...) ?

is there anyone can give me good reasons why taking fedora at the first place ? why not debian ? why not even gentoo (which is regarding of code easiness/freedomcy better than fedora)?

im afraid the one who took the first (lets call it "bad") decision is still continuing to take these decisions which will make qubes a disaster even if u shifted to debian or X distro.

so i think consultations on these decisions is very important. and fedora to be the core of qubes or any other linux distro is a mistaken step.

[TNTBOMBOM]

the problem is , why anyone would take fedora which is very known for its issues (from about 2000) and their enterprise lockin on the code (redhat sucking stuff...) ?

is there anyone can give me good reasons why taking fedora at the first place ? why not debian ? why not even gentoo (which is regarding of code easiness/freedomcy better than fedora)?

im afraid the one who took the first (lets call it "bad") decision is still continuing to take these decisions which will make qubes a disaster even if u shifted to debian or X distro.

so i think consultations on these decisions is very important. and fedora to be the core of qubes or any other linux distro is a mistaken step.

[woju]

Fedora is currently hosting the graphical environment and, like it or not, it has the best compatibility with graphic cards. Debian generally has old X drivers and older kernel. This is especialy problematic with Qubes, because the hardware selection is already constrained by virtualisation extension. We will surely consider switching the distro when we implement GUI domain. It is on out roadmap and depends on GPU passthrough, which does not currently work, at least not without patching Xen and libvirt. We this it will be hard enough, and the effort should be directed there. When switching, it will be neither Fedora nor Debian or any general purpose distro, but something very minimal, like Alpine.

[woju]

Fedora is currently hosting the graphical environment and, like it or not, it has the best compatibility with graphic cards. Debian generally has old X drivers and older kernel. This is especialy problematic with Qubes, because the hardware selection is already constrained by virtualisation extension. We will surely consider switching the distro when we implement GUI domain. It is on out roadmap and depends on GPU passthrough, which does not currently work, at least not without patching Xen and libvirt. We this it will be hard enough, and the effort should be directed there. When switching, it will be neither Fedora nor Debian or any general purpose distro, but something very minimal, like Alpine.

[Jeeppler]

What exactly is the issue with GPU passthrough and Xen?

[Jeeppler]

What exactly is the issue with GPU passthrough and Xen?

[marmarek]

Take a look at this thread - it's a good summary of GPU passthrough and PCI passthrough to HVM at all: https://groups.google.com/d/topic/qubes-devel/mvZBIUuyjv0/discussion

[marmarek]

Take a look at this thread - it's a good summary of GPU passthrough and PCI passthrough to HVM at all: https://groups.google.com/d/topic/qubes-devel/mvZBIUuyjv0/discussion

[minad]

It would be really nice to have a choice here. Like @woju I think it would be best to have a minimal distribution. However it might be nice to try something more declarative like NixOS.

I guess you wouldn't want to maintain different distributions, at least not for the official distribution? Do you have an idea how many Fedora specific configuations are in the qubes builder and the applications?

[minad]

It would be really nice to have a choice here. Like @woju I think it would be best to have a minimal distribution. However it might be nice to try something more declarative like NixOS.

I guess you wouldn't want to maintain different distributions, at least not for the official distribution? Do you have an idea how many Fedora specific configuations are in the qubes builder and the applications?

[marmarek]

I guess you wouldn't want to maintain different distributions, at least not for the official distribution?

Exactly.

Do you have an idea how many Fedora specific configuations are in the qubes builder and the applications?

During the current Fedora 20 -> 23 upgrade I'm trying to collect that list. Actually two lists:

• customization of GUI domain (which currently is the same as dom0) - this list is almost completed based on #1784
• things customized in dom0 in general

I think the only really Fedora specific thing is update mechanism, other parts are just some system configuration which may need some adjustment when porting to other distribution (like config file locations etc).

Yes, we're considering NixOS here, but no decision has been made yet.

[marmarek]

I guess you wouldn't want to maintain different distributions, at least not for the official distribution?

Exactly.

Do you have an idea how many Fedora specific configuations are in the qubes builder and the applications?

During the current Fedora 20 -> 23 upgrade I'm trying to collect that list. Actually two lists:

• customization of GUI domain (which currently is the same as dom0) - this list is almost completed based on #1784
• things customized in dom0 in general

I think the only really Fedora specific thing is update mechanism, other parts are just some system configuration which may need some adjustment when porting to other distribution (like config file locations etc).

Yes, we're considering NixOS here, but no decision has been made yet.

[unman]

I think the only really Fedora specific thing is update mechanism, other parts are just some system configuration which may need some adjustment when porting to other distribution (like config file locations etc).

I've got some experience here as I've been running Debian in dom0 for a while. It's an unholy mix of packages, alien and hand crafted stuff,(hand crafted like the Borja Jesus), and not full Qubes. But it works well enough for my slight requirements. I'm hoping that the upgrade to 3.1 will be somewhat closer to full Qubes.
So far I would say there is almost nothing Fedora specific that comes outwith the normal repackaging process.

It's interesting that @mfc suggests that Debian provides increased hardware compatibility, while @woju says Fedora has best compatibility with graphic cards. Is there any evidence either way?

[unman]

I think the only really Fedora specific thing is update mechanism, other parts are just some system configuration which may need some adjustment when porting to other distribution (like config file locations etc).

I've got some experience here as I've been running Debian in dom0 for a while. It's an unholy mix of packages, alien and hand crafted stuff,(hand crafted like the Borja Jesus), and not full Qubes. But it works well enough for my slight requirements. I'm hoping that the upgrade to 3.1 will be somewhat closer to full Qubes.
So far I would say there is almost nothing Fedora specific that comes outwith the normal repackaging process.

It's interesting that @mfc suggests that Debian provides increased hardware compatibility, while @woju says Fedora has best compatibility with graphic cards. Is there any evidence either way?

[minad]

The Borja jesus 😂 That still sounds somehow encouraging! What are your reasons for prefering Debian on the dom0? I just started using qubes and I had much more experience with Debian, Arch, ... but basically none with Fedora. It took a short while to get accustomed - but in the end it feels all the same with some minor package manager differences. Since qubes takes a more radical approach in general, I think it would also make sense to consider a change to something conceptually "better" or more advanced like nix.

[minad]

The Borja jesus 😂 That still sounds somehow encouraging! What are your reasons for prefering Debian on the dom0? I just started using qubes and I had much more experience with Debian, Arch, ... but basically none with Fedora. It took a short while to get accustomed - but in the end it feels all the same with some minor package manager differences. Since qubes takes a more radical approach in general, I think it would also make sense to consider a change to something conceptually "better" or more advanced like nix.

[h01ger]

unman, could you please share more details about your setup, maybe even commits? ;-) Are you running this on a jessie based dom0 or stretch? How did you build+install the qubes specific stuff?

I'm still pondering doing the same, and looking at the cubes git repos I've identified these as being needed for dom0:

• qubes-core-admin
• qubes-core-admin-linux
• qubes-core-agent-linux
• qubes-core-libvirt
• qubes-core-vchan-xen

Is that correct? Which are missing? Cause once dom0 is working one should be able to deploy VMs from a backup… ;-)

[h01ger]

unman, could you please share more details about your setup, maybe even commits? ;-) Are you running this on a jessie based dom0 or stretch? How did you build+install the qubes specific stuff?

I'm still pondering doing the same, and looking at the cubes git repos I've identified these as being needed for dom0:

• qubes-core-admin
• qubes-core-admin-linux
• qubes-core-agent-linux
• qubes-core-libvirt
• qubes-core-vchan-xen

Is that correct? Which are missing? Cause once dom0 is working one should be able to deploy VMs from a backup… ;-)

[marmarek]

On Wed, May 18, 2016 at 09:03:43AM -0700, Holger Levsen wrote:

I'm still pondering doing the same, and looking at the cubes git repos I've identified these as being needed for dom0:

• qubes-core-admin
• qubes-core-admin-linux
• qubes-core-agent-linux
• qubes-core-libvirt
• qubes-core-vchan-xen

Is that correct? Which are missing?

In addition to above:

• qubes-vmm-xen (yes, you need this, not native Debian packages because
  of Qubes-specific patches, and parts in Debian packages - libxenvchan,
  stubdomains)
• qubes-gui-common (required to build gui-daemon)
• qubes-gui-daemon
• qubes-core-qubesdb
• qubes-manager

And mgmt-salt stuff (everything with "base" and "dom0").

Some of them already have debian packaging.

Packaging Xen for dom0 would be tricky because of stubdomains. It
consists of some external libraries/tools built as part of Xen build and
statically linked. Something that AFAIR is against Debian policy (for
example there are multiple source tarballs, from different projects).

And template packages needs to be converted to deb. Or not packaged at
all and installed some other way - which I think would be even better
option (installing templates as packages have a lot of side effects...).

Cause once dom0 is working one should be able to deploy VMs from a backup… ;-)

Yes, it should be possible.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Wed, May 18, 2016 at 09:03:43AM -0700, Holger Levsen wrote:

I'm still pondering doing the same, and looking at the cubes git repos I've identified these as being needed for dom0:

• qubes-core-admin
• qubes-core-admin-linux
• qubes-core-agent-linux
• qubes-core-libvirt
• qubes-core-vchan-xen

Is that correct? Which are missing?

In addition to above:

• qubes-vmm-xen (yes, you need this, not native Debian packages because
  of Qubes-specific patches, and parts in Debian packages - libxenvchan,
  stubdomains)
• qubes-gui-common (required to build gui-daemon)
• qubes-gui-daemon
• qubes-core-qubesdb
• qubes-manager

And mgmt-salt stuff (everything with "base" and "dom0").

Some of them already have debian packaging.

Packaging Xen for dom0 would be tricky because of stubdomains. It
consists of some external libraries/tools built as part of Xen build and
statically linked. Something that AFAIR is against Debian policy (for
example there are multiple source tarballs, from different projects).

And template packages needs to be converted to deb. Or not packaged at
all and installed some other way - which I think would be even better
option (installing templates as packages have a lot of side effects...).

Cause once dom0 is working one should be able to deploy VMs from a backup… ;-)

Yes, it should be possible.

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[h01ger]

Marek, thanks for the hints!

For a start I don't mind violating Debian policy if needed. That said, while statically linking and embedded code copies are discouraged in general, there are also exceptions to these rules.

But really, at first I just want to be able to use a Debian based system as dom0.

[h01ger]

Marek, thanks for the hints!

For a start I don't mind violating Debian policy if needed. That said, while statically linking and embedded code copies are discouraged in general, there are also exceptions to these rules.

But really, at first I just want to be able to use a Debian based system as dom0.

[unman]

@h01ger
Worked through the build logs from fedora and the spec files. I followed the same build order and worked through each package in turn. I started with a base jessie install, and built up from there.
I tried cherry picking Xen packages from sid and applying the Qubes patches, and that worked reasonably but I found difficult to incorporate stubdomains, and got pretty lost. In the end I basically built everything from source. It was relatively easy to identify Debian equivalents for the fedora requirements, and referencing the native Debian packages also helped, particularly for Xen.
I had some success using alien for simpler stuff, although some paths and scripts needed to be bodged by hand.
I didn't build manager or salt stack, but I cant imagine they would be difficult.
Some stuff just doesn't work at all - can't boot from iso in HVM, for example. And nothing is really packaged so it's probably fragile on updates.

I'm currently working on 3.1, and trying to do the right thing, packaging properly and (sometimes) using qubes-builder framework, but I have limited time before my next trip. When I have anything sensible to share I will certainly commit, but I'm a way off that at present.

When I started there was a clear thought that Qubes would be moving to Debian, and I wanted to see what would be involved. Now, of course, that's no longer the case, so I suspect time is better spent working on Debian issues on the vm side.

[unman]

@h01ger
Worked through the build logs from fedora and the spec files. I followed the same build order and worked through each package in turn. I started with a base jessie install, and built up from there.
I tried cherry picking Xen packages from sid and applying the Qubes patches, and that worked reasonably but I found difficult to incorporate stubdomains, and got pretty lost. In the end I basically built everything from source. It was relatively easy to identify Debian equivalents for the fedora requirements, and referencing the native Debian packages also helped, particularly for Xen.
I had some success using alien for simpler stuff, although some paths and scripts needed to be bodged by hand.
I didn't build manager or salt stack, but I cant imagine they would be difficult.
Some stuff just doesn't work at all - can't boot from iso in HVM, for example. And nothing is really packaged so it's probably fragile on updates.

I'm currently working on 3.1, and trying to do the right thing, packaging properly and (sometimes) using qubes-builder framework, but I have limited time before my next trip. When I have anything sensible to share I will certainly commit, but I'm a way off that at present.

When I started there was a clear thought that Qubes would be moving to Debian, and I wanted to see what would be involved. Now, of course, that's no longer the case, so I suspect time is better spent working on Debian issues on the vm side.

[Jeeppler]

I thought one of the main reasons to switch from Fedora to Debian are reproducible builds. Debian made and make a lot of progress in this area.

The other question which was discussed before is moving from KDE to GTK (Gnome) for the desktop.

@woju proposed above a switch to Alpine Linux. I understand that Alpine Linux has nice security features, but it seems to be a radical switch. A switch to Alpine would be less radical if the management GUI and dom0 would be separated. In the case the separation between GUI and dom0 would be possible and implemented, dom0 would be Alpine, but what about the GUI domain?

Why not going step by step. First moving from Fedora to Debian, because of the ability to create reproducible builds. Then moving from KDE to GTK (Gnome). The final step would be to separate Dom0 into separate domains. The management domain would be Alpine whereas the graphical engagement domain would be still Debian.

Another good point of @woju is the problem with drivers, older kernel and drivers in Debian. This is true for Debian stable, but Debian has a testing, unstable and experimental repository which contain more up to date packages.

Debian and Linux in general has many distribution derivatives. Why not using one of the derivatives which fulfills the requirements:

• based on Debian
• static release model
• up-to-date driver

Tanglu is a distribution which fulfills all the requirements. Tanglu is based on Debian, but uses software packages from testing, unstable and sometimes experimental to provide the newest drivers and other software packages, but is still based on Debian stable. Tanglu has three main editions KDE, GNOME and core. In addition Tanglu uses Calamares the independent system installer.

[Jeeppler]

I thought one of the main reasons to switch from Fedora to Debian are reproducible builds. Debian made and make a lot of progress in this area.

The other question which was discussed before is moving from KDE to GTK (Gnome) for the desktop.

@woju proposed above a switch to Alpine Linux. I understand that Alpine Linux has nice security features, but it seems to be a radical switch. A switch to Alpine would be less radical if the management GUI and dom0 would be separated. In the case the separation between GUI and dom0 would be possible and implemented, dom0 would be Alpine, but what about the GUI domain?

Why not going step by step. First moving from Fedora to Debian, because of the ability to create reproducible builds. Then moving from KDE to GTK (Gnome). The final step would be to separate Dom0 into separate domains. The management domain would be Alpine whereas the graphical engagement domain would be still Debian.

Another good point of @woju is the problem with drivers, older kernel and drivers in Debian. This is true for Debian stable, but Debian has a testing, unstable and experimental repository which contain more up to date packages.

Debian and Linux in general has many distribution derivatives. Why not using one of the derivatives which fulfills the requirements:

• based on Debian
• static release model
• up-to-date driver

Tanglu is a distribution which fulfills all the requirements. Tanglu is based on Debian, but uses software packages from testing, unstable and sometimes experimental to provide the newest drivers and other software packages, but is still based on Debian stable. Tanglu has three main editions KDE, GNOME and core. In addition Tanglu uses Calamares the independent system installer.

[adrelanos]

For reference:

• https://wiki.debian.org/Qubes
• https://wiki.debian.org/Qubes/Devel

[adrelanos]

For reference:

• https://wiki.debian.org/Qubes
• https://wiki.debian.org/Qubes/Devel

[h01ger]

https://wiki.debian.org/Qubes/Devel is the relevant URL for this issue.

https://wiki.debian.org/Qubes just describe how to use Qubes from the point of view of someone familar with Debian - and that wiki page is also a bit outdated.

[h01ger]

https://wiki.debian.org/Qubes/Devel is the relevant URL for this issue.

https://wiki.debian.org/Qubes just describe how to use Qubes from the point of view of someone familar with Debian - and that wiki page is also a bit outdated.

[adrelanos]

@unman in #1781 (comment)

I don't think that #1919 is still a target.

How did you come to that conclusion?

In any case it seems to me that most users should be kept well away from dom0 and so what is running there is irrelevant. If anyone has the nous to tinker in dom0 then they should be able to handle the differences.

I don't think Fedora can be as transparent as that. Once one wants to do certain things, one example is #1375 and there are others, one is back to learning about Fedora. Same when issues happen or when debug info is requested. And that probably is not going to go away. Also higher effort for developers to know two systems. For example makes getting grsecurity in Qubes harder since an rpm package / repository is required.

[adrelanos]

@unman in #1781 (comment)

I don't think that #1919 is still a target.

How did you come to that conclusion?

In any case it seems to me that most users should be kept well away from dom0 and so what is running there is irrelevant. If anyone has the nous to tinker in dom0 then they should be able to handle the differences.

I don't think Fedora can be as transparent as that. Once one wants to do certain things, one example is #1375 and there are others, one is back to learning about Fedora. Same when issues happen or when debug info is requested. And that probably is not going to go away. Also higher effort for developers to know two systems. For example makes getting grsecurity in Qubes harder since an rpm package / repository is required.

[marmarek]

Once one wants to do certain things, one example is #1375

No, it isn't - if you have enabled USB VM. Generally we want to keep user away from manipulating dom0 as much as possible. The extreme case (on the roadmap!) is GUI domain, where user have no way for direct interaction with dom0.
Anyway, we're not going to switch dom0 to any other distribution until implementation of GUI domain.

[marmarek]

Once one wants to do certain things, one example is #1375

No, it isn't - if you have enabled USB VM. Generally we want to keep user away from manipulating dom0 as much as possible. The extreme case (on the roadmap!) is GUI domain, where user have no way for direct interaction with dom0.
Anyway, we're not going to switch dom0 to any other distribution until implementation of GUI domain.

[adrelanos]

No, it isn't - if you have enabled USB VM.

Which does not work for me due to effectively only 1 usb controller and all usb devices including internal keyboard connected to that, no ps2 either.

Other issues #2387 / #2360 also require quite some Fedora knowledge to sort out.

Anyway, we're not going to switch dom0 to any other distribution until implementation of GUI domain.

That sounds great and also sounds like there is still hope for dom0 Debian.

[adrelanos]

No, it isn't - if you have enabled USB VM.

Which does not work for me due to effectively only 1 usb controller and all usb devices including internal keyboard connected to that, no ps2 either.

Other issues #2387 / #2360 also require quite some Fedora knowledge to sort out.

Anyway, we're not going to switch dom0 to any other distribution until implementation of GUI domain.

That sounds great and also sounds like there is still hope for dom0 Debian.

[marmarek]

That sounds great and also sounds like there is still hope for dom0 Debian.

Yes, that's right. But because of complexity of GUI domain, it will not be soon.

[marmarek]

That sounds great and also sounds like there is still hope for dom0 Debian.

Yes, that's right. But because of complexity of GUI domain, it will not be soon.

[jpouellet]

@adrelanos re 1 USB controller: have you tried https://github.com/QubesOS/qubes-app-linux-input-proxy?

It provides questionable security benefit, but (of particular relevance here) does further the goal of users not needing to do much in dom0.

[jpouellet]

@adrelanos re 1 USB controller: have you tried https://github.com/QubesOS/qubes-app-linux-input-proxy?

It provides questionable security benefit, but (of particular relevance here) does further the goal of users not needing to do much in dom0.

[v6ak]

What about Ubuntu LTS? It provides 5Y support with releases every 2Y. So, we could stick with one version for 3Y-5Y.

It seems that there is some support of new hardware: https://wiki.ubuntu.com/Kernel/LTSEnablementStack

[v6ak]

What about Ubuntu LTS? It provides 5Y support with releases every 2Y. So, we could stick with one version for 3Y-5Y.

It seems that there is some support of new hardware: https://wiki.ubuntu.com/Kernel/LTSEnablementStack

[adrelanos]

Ubuntu has the wrong mindset privacy wise:
https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks

Ubuntu is problematic license wise:

• https://www.whonix.org/wiki/Dev/Operating_System#Switch_from_Ubuntu_to_Debian
• http://www.networkworld.com/article/2226367/opensource-subnet/making-sense-of-the-ubuntu-licensing-fiasco.html

That's also the reason why there is no Ubuntu template for Qubes.

https://www.qubes-os.org/doc/templates/ubuntu/

[adrelanos]

Ubuntu has the wrong mindset privacy wise:
https://www.eff.org/deeplinks/2012/10/privacy-ubuntu-1210-amazon-ads-and-data-leaks

Ubuntu is problematic license wise:

• https://www.whonix.org/wiki/Dev/Operating_System#Switch_from_Ubuntu_to_Debian
• http://www.networkworld.com/article/2226367/opensource-subnet/making-sense-of-the-ubuntu-licensing-fiasco.html

That's also the reason why there is no Ubuntu template for Qubes.

https://www.qubes-os.org/doc/templates/ubuntu/

[Jeeppler]

@v6ak Ubuntu LTS or Debian "Stable" does not matter. Ubuntu is based on Debian "Stable". Additionally, both offer support for 3/5 years. However, as @adrelanos pointed out there are license and privacy issues regarding Ubuntu.

Fedora is a nice choice, but the 9 months release cycle is a problem for dom0 in Qubes OS. The release cycle of Fedora is too short as a result most Qubes OS versions ship with an soon to be outdated or outdated version of Fedora as Dom0. Debian "Stable" and Ubuntu LTS on the other hand do not always support new hardware and kernel/packages are even on release date kind of out-of-date. I would prefer if Qubes OS would use a Debian "Testing" based OS for Dom0 with a semi-rolling or rolling release model. SparkleLinux (https://sparkylinux.org) could be an option.

[Jeeppler]

@v6ak Ubuntu LTS or Debian "Stable" does not matter. Ubuntu is based on Debian "Stable". Additionally, both offer support for 3/5 years. However, as @adrelanos pointed out there are license and privacy issues regarding Ubuntu.

Fedora is a nice choice, but the 9 months release cycle is a problem for dom0 in Qubes OS. The release cycle of Fedora is too short as a result most Qubes OS versions ship with an soon to be outdated or outdated version of Fedora as Dom0. Debian "Stable" and Ubuntu LTS on the other hand do not always support new hardware and kernel/packages are even on release date kind of out-of-date. I would prefer if Qubes OS would use a Debian "Testing" based OS for Dom0 with a semi-rolling or rolling release model. SparkleLinux (https://sparkylinux.org) could be an option.

[v6ak]

@v6ak <https://github.com/v6ak> Ubuntu LTS or Debian "Stable" does not matter. Ubuntu is based on Debian "Stable". Additionally, both offer support for 3/5 years.

AFAIK Debian does not provide 5Y support for new hardware.

However, as @adrelanos <https://github.com/adrelanos> pointed out there are license and privacy issues regarding Ubuntu.

Yes, this is a good point.

as a result most Qubes OS versions ship with an soon to be outdated or outdated version of Fedora as Dom0.

If Fedora has a better support for new hardware, it is effectively nullified by having outdated version, itn't is?

I would prefer if Qubes OS would use a Debian "Testing" based OS for Dom0 with a semi-rolling or rolling release model. SparkleLinux (https://sparkylinux.org) could be an option.

Well, uh rolling release in dom0? I want my dom0 to be working and stable. I know this might be a little bit contradictory (support for new hardware requires changes), but still. Introducing a new drivers to dom0 is probably rather wanted, major upgrades of some packages (especially Xfwm/Kwin) are however likely to be breaking in context of Qubes.

[v6ak]

@v6ak <https://github.com/v6ak> Ubuntu LTS or Debian "Stable" does not matter. Ubuntu is based on Debian "Stable". Additionally, both offer support for 3/5 years.

AFAIK Debian does not provide 5Y support for new hardware.

However, as @adrelanos <https://github.com/adrelanos> pointed out there are license and privacy issues regarding Ubuntu.

Yes, this is a good point.

as a result most Qubes OS versions ship with an soon to be outdated or outdated version of Fedora as Dom0.

If Fedora has a better support for new hardware, it is effectively nullified by having outdated version, itn't is?

I would prefer if Qubes OS would use a Debian "Testing" based OS for Dom0 with a semi-rolling or rolling release model. SparkleLinux (https://sparkylinux.org) could be an option.

Well, uh rolling release in dom0? I want my dom0 to be working and stable. I know this might be a little bit contradictory (support for new hardware requires changes), but still. Introducing a new drivers to dom0 is probably rather wanted, major upgrades of some packages (especially Xfwm/Kwin) are however likely to be breaking in context of Qubes.

[Jeeppler]

Sorry, for using the term outdated. Unsupported is the right term. Fedoras release model is as following:
"Release X is supported until one month after the release of Release X+2." [1] as a result Fedora 24 will reach it's end of life (EOL) approx. one month after the Fedora 26 release. The current supported versions are Fedora 24 and 25. Therefor Fedora 23 which is currently used for Dom0 is unsupported by the Fedora team.
Unsupported does not mean Fedora is outdated. Fedora comes always a lot of new software in every release. The hardware support is still superior compared to other distribution.

Kalilinux is doing pretty well since they based their OS on the Debian "Testing" branch. Other distributions are successful doing the same. The Debian "Testing" branch is far more conservative compared to Arch Linux. Arch Linux has new software shortly after it is available. With other words Arch Linux follows a pretty aggressive rolling release model. Debian "Testing" on the other hand accepts packages only if they have been proven to work in the Debian "Unstable" branch [2]. As a result, I would consider Debian "Testing" as having conservative rolling release model. In addition, I think it fits into Qubes OS release model. Qubes OS receives minor upgrades and features even during the lifetime of a major release. For example, Qubes VM Manager updates or kernel updates during the lifetime of Qubes OS 3.2.

[1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
[2] https://wiki.debian.org/DebianReleases

[Jeeppler]

Sorry, for using the term outdated. Unsupported is the right term. Fedoras release model is as following:
"Release X is supported until one month after the release of Release X+2." [1] as a result Fedora 24 will reach it's end of life (EOL) approx. one month after the Fedora 26 release. The current supported versions are Fedora 24 and 25. Therefor Fedora 23 which is currently used for Dom0 is unsupported by the Fedora team.
Unsupported does not mean Fedora is outdated. Fedora comes always a lot of new software in every release. The hardware support is still superior compared to other distribution.

Kalilinux is doing pretty well since they based their OS on the Debian "Testing" branch. Other distributions are successful doing the same. The Debian "Testing" branch is far more conservative compared to Arch Linux. Arch Linux has new software shortly after it is available. With other words Arch Linux follows a pretty aggressive rolling release model. Debian "Testing" on the other hand accepts packages only if they have been proven to work in the Debian "Unstable" branch [2]. As a result, I would consider Debian "Testing" as having conservative rolling release model. In addition, I think it fits into Qubes OS release model. Qubes OS receives minor upgrades and features even during the lifetime of a major release. For example, Qubes VM Manager updates or kernel updates during the lifetime of Qubes OS 3.2.

[1] https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle
[2] https://wiki.debian.org/DebianReleases

[v6ak]

Therefor Fedora 23 which is currently used for Dom0 is unsupported by the Fedora team. Unsupported does not mean Fedora is outdated.

It depends. With my new laptop, Fedora 23 is surely outdated and a newer kernel was needed.

Debian "Testing" on the other hand accepts packages only if they have been proven to work in the Debian "Unstable" branch [2].

This doesn't make it suitable for Qubes, see my note on Xfwm/Kwin. Maybe this could be solved by adding Xfwm/Kwin with high version number, but I am not sure about all the consequences. -- Sent from my fruity BlackBerry pocket computer powered by Android with K-9 Mail. Please excuse my brevity.

[v6ak]

Therefor Fedora 23 which is currently used for Dom0 is unsupported by the Fedora team. Unsupported does not mean Fedora is outdated.

It depends. With my new laptop, Fedora 23 is surely outdated and a newer kernel was needed.

Debian "Testing" on the other hand accepts packages only if they have been proven to work in the Debian "Unstable" branch [2].

This doesn't make it suitable for Qubes, see my note on Xfwm/Kwin. Maybe this could be solved by adding Xfwm/Kwin with high version number, but I am not sure about all the consequences. -- Sent from my fruity BlackBerry pocket computer powered by Android with K-9 Mail. Please excuse my brevity.

[Jeeppler]

@v6ak I do not get your point of Xfwm/Kwin. Please elaborate on that a little bit more.

[Jeeppler]

@v6ak I do not get your point of Xfwm/Kwin. Please elaborate on that a little bit more.

[adrelanos]

Whonix was based on Debian testing. (now on stable) The short summary "testing was absolutely horrible". Long summary:

https://www.whonix.org/wiki/Dev/Operating_System#Why_is_Whonix_based_on_Debian_Stable.2C_not_Debian_Testing.3F

[adrelanos]

Whonix was based on Debian testing. (now on stable) The short summary "testing was absolutely horrible". Long summary:

https://www.whonix.org/wiki/Dev/Operating_System#Why_is_Whonix_based_on_Debian_Stable.2C_not_Debian_Testing.3F

[Jeeppler]

@adrelanos that make sense. Thanks. I thought Debian "testing" is more reliable.

[Jeeppler]

@adrelanos that make sense. Thanks. I thought Debian "testing" is more reliable.

[tasket]

An Ubuntu-based distro (not Ubuntu itself) could be a better choice if long-term support in the form of patches is a priority, which I think it should be. There is also the benefit of Ubuntu's hardware testing program... they're the only distro I'm aware that has validated an extensive list of PC desktop systems and components and done the tweaking necessary to get them working smoothly.

Some of this effort trickles down to Debian, but the trend is unreliable. Debian does not really care if desktop users are stymied by a server-centric kludge or bad UI choice or naive defaults from upstream.

Trisquel Linux specifically tracks Ubuntu LTS releases. But if FOSS-only is too confining (and I'm not sure it is), it may be worthwhile to remove the few offending components from Ubuntu ourselves and put the distro under a Qubes moniker.

OTOH, Fedora is really a problem: It is the only major distro that does not sign its repo metadata as a full set, allowing attacks that selectively hold-back patches -- yes, this is a big deal! Yet Fedora-based distros like RHEL and CentOS do fully sign. The reason I surmise for the disconnect is Red Hat's desire to direct users to paid RHEL subscriptions as the "serious choice with security". Fedora also lacks considerably in package selection. Its a testbed distro, not for serious use.

[tasket]

An Ubuntu-based distro (not Ubuntu itself) could be a better choice if long-term support in the form of patches is a priority, which I think it should be. There is also the benefit of Ubuntu's hardware testing program... they're the only distro I'm aware that has validated an extensive list of PC desktop systems and components and done the tweaking necessary to get them working smoothly.

Some of this effort trickles down to Debian, but the trend is unreliable. Debian does not really care if desktop users are stymied by a server-centric kludge or bad UI choice or naive defaults from upstream.

Trisquel Linux specifically tracks Ubuntu LTS releases. But if FOSS-only is too confining (and I'm not sure it is), it may be worthwhile to remove the few offending components from Ubuntu ourselves and put the distro under a Qubes moniker.

OTOH, Fedora is really a problem: It is the only major distro that does not sign its repo metadata as a full set, allowing attacks that selectively hold-back patches -- yes, this is a big deal! Yet Fedora-based distros like RHEL and CentOS do fully sign. The reason I surmise for the disconnect is Red Hat's desire to direct users to paid RHEL subscriptions as the "serious choice with security". Fedora also lacks considerably in package selection. Its a testbed distro, not for serious use.

[Jeeppler]

@tasket Trisquel would be a nice choice. However, it is 100% free and libre software.

I like the idea of an Ubuntu-based distro. However, removing offending components from Ubuntu is not worth the effort. There are several other distros based on Ubuntu. My favorite among them would be Linux Mint. Another advantage would be that Linux Mint offers Cinnamon, Mate, Xfce and KDE flavors out of the box. Other desktop environments can be installed afterwards (i3, GNOME etc.). All Linux Mint 18.x editions are based on Ubuntu 16.04 LTS [1].

[1] http://blog.linuxmint.com/?p=3145

[Jeeppler]

@tasket Trisquel would be a nice choice. However, it is 100% free and libre software.

I like the idea of an Ubuntu-based distro. However, removing offending components from Ubuntu is not worth the effort. There are several other distros based on Ubuntu. My favorite among them would be Linux Mint. Another advantage would be that Linux Mint offers Cinnamon, Mate, Xfce and KDE flavors out of the box. Other desktop environments can be installed afterwards (i3, GNOME etc.). All Linux Mint 18.x editions are based on Ubuntu 16.04 LTS [1].

[1] http://blog.linuxmint.com/?p=3145

[tasket]

@Jeeppler How many components are there to remove from Ubuntu: Amazon and the Ubuntu font and...?

Linux Mint switched to Debian years ago and had a history of negligence re: not passing along security patches. So I take it they switched back?

[tasket]

@Jeeppler How many components are there to remove from Ubuntu: Amazon and the Ubuntu font and...?

Linux Mint switched to Debian years ago and had a history of negligence re: not passing along security patches. So I take it they switched back?

[jpouellet]

Mint got owned and served backdoored install ISOs not to long ago, and yet even after that they still don't make sigs available on their downloads page. I don't know anything about their internal processes or track record, but this as my first impression suggests there are likely serious security concerns about their development process and their goals as a project are not aligned with Qubes', especially for use in dom0.

Remember also that ideally we want to move towards a completely reproducibly built system. Debian has been making lots of progress on that front. Is this a priority for Ubuntu or derivatives as well?

[jpouellet]

Mint got owned and served backdoored install ISOs not to long ago, and yet even after that they still don't make sigs available on their downloads page. I don't know anything about their internal processes or track record, but this as my first impression suggests there are likely serious security concerns about their development process and their goals as a project are not aligned with Qubes', especially for use in dom0.

Remember also that ideally we want to move towards a completely reproducibly built system. Debian has been making lots of progress on that front. Is this a priority for Ubuntu or derivatives as well?

[v6ak]

I guess that no privacy offending component would actually send anything in network-disconnected dom0. Yes, one might complain about unclean solution or about ideological background, but not about the result.

@v6ak I do not get your point of Xfwm/Kwin. Please elaborate on that a little bit more.

Window managers in Qubes generally require some patching in order to have properly colored window borders. Additionally, Qubes is tied to X11 (i.e., it currently cannot be used with Wayland in dom0) and just a change in external component (e.g., Xfce) cannot fix it without a modification in Qubes. When switching from Fedora 20 to Fedora 23, KDE was upgraded from 4.* to 5.*. No matter how much stable KDE Plasma was, it required KDE Qubes integration to be rewritten from scratch, with a different design. The new Kwin is not directly tied to X11, so its API tries to be display server agnostic. While this might be seen as painful, it is natural part of such project. Now, developers have at least some option to decide when to upgrade Fedora. For example, they have decided that Qubes 4 will be still based on Fedora 23 in order to release it sooner. But try to imagine this with a rolling release distro. One day, some (even well-tested) update with breaking effect on Qubes will come. While we can try to skip its installation (e.g., by depending on an exact version of a package), we can get another classes of problems like dependency hell and requiring old unavailable package versions. It might be manageable, but it would probably generate urgent tasks for developers.

[v6ak]

I guess that no privacy offending component would actually send anything in network-disconnected dom0. Yes, one might complain about unclean solution or about ideological background, but not about the result.

@v6ak I do not get your point of Xfwm/Kwin. Please elaborate on that a little bit more.

Window managers in Qubes generally require some patching in order to have properly colored window borders. Additionally, Qubes is tied to X11 (i.e., it currently cannot be used with Wayland in dom0) and just a change in external component (e.g., Xfce) cannot fix it without a modification in Qubes. When switching from Fedora 20 to Fedora 23, KDE was upgraded from 4.* to 5.*. No matter how much stable KDE Plasma was, it required KDE Qubes integration to be rewritten from scratch, with a different design. The new Kwin is not directly tied to X11, so its API tries to be display server agnostic. While this might be seen as painful, it is natural part of such project. Now, developers have at least some option to decide when to upgrade Fedora. For example, they have decided that Qubes 4 will be still based on Fedora 23 in order to release it sooner. But try to imagine this with a rolling release distro. One day, some (even well-tested) update with breaking effect on Qubes will come. While we can try to skip its installation (e.g., by depending on an exact version of a package), we can get another classes of problems like dependency hell and requiring old unavailable package versions. It might be manageable, but it would probably generate urgent tasks for developers.

[Jeeppler]

@tasket @marmarek once pointed out that the problem about Ubuntu is that the Ubuntu license prevents the Qubes team from redistributing a modified Ubuntu under the Ubuntu name. Even if you remove all the privacy concerning parts of Ubuntu you still end up with the trademark issues.

Linux Mint is based on Ubuntu. I think you got confused between Linux Mint and Linux Mind Debian Edition (LMDE). LMDE is based on Debian.

@jpouellet your security concerns are maybe valid. The data breach which happened to them is one thing, that can happen to anybody. Linux Mint is a community project, Qubes OS developers and users can always work together with them to improve their security standard.

Debian and GuixSD are the two distributions which made some serious progress towards reproducible builds. Ubuntu on the other hand is not even listed in the reproducible-builds.org [1] page.

[1] https://reproducible-builds.org/who/

[Jeeppler]

@tasket @marmarek once pointed out that the problem about Ubuntu is that the Ubuntu license prevents the Qubes team from redistributing a modified Ubuntu under the Ubuntu name. Even if you remove all the privacy concerning parts of Ubuntu you still end up with the trademark issues.

Linux Mint is based on Ubuntu. I think you got confused between Linux Mint and Linux Mind Debian Edition (LMDE). LMDE is based on Debian.

@jpouellet your security concerns are maybe valid. The data breach which happened to them is one thing, that can happen to anybody. Linux Mint is a community project, Qubes OS developers and users can always work together with them to improve their security standard.

Debian and GuixSD are the two distributions which made some serious progress towards reproducible builds. Ubuntu on the other hand is not even listed in the reproducible-builds.org [1] page.

[1] https://reproducible-builds.org/who/

[tasket]

I don't think re-branding is a hurdle... more of a threshold. But I wasn't aware Ubuntu was ignoring reproducability. That, together with full repo signing and alternative architectures, makes Debian the more interesting choice.

[tasket]

I don't think re-branding is a hurdle... more of a threshold. But I wasn't aware Ubuntu was ignoring reproducability. That, together with full repo signing and alternative architectures, makes Debian the more interesting choice.

[v6ak]

Sure, legal problems with Ubuntu remain if it is not rebranded. Ideally, we would use some Ubuntu LTS fork that's well maintained and debranded. But I am afraid it is easier said than done.

[v6ak]

Sure, legal problems with Ubuntu remain if it is not rebranded. Ideally, we would use some Ubuntu LTS fork that's well maintained and debranded. But I am afraid it is easier said than done.

[Jeeppler]

@v6ak qubuntu or qubesuntu ;-)

[Jeeppler]

@v6ak qubuntu or qubesuntu ;-)

[msusi]

Until Fedora remains the default dom0 for QubesOS it would be nice to deblob it using for example packages from freed-ora: https://www.fsfla.org/ikiwiki/selibre/linux-libre/freed-ora.en.html

[msusi]

Until Fedora remains the default dom0 for QubesOS it would be nice to deblob it using for example packages from freed-ora: https://www.fsfla.org/ikiwiki/selibre/linux-libre/freed-ora.en.html

[ghost]

Related: #833

Dom0 should definitely have the smallest possible TCB, so something like Alpine would make sense.

[ghost]

Related: #833

Dom0 should definitely have the smallest possible TCB, so something like Alpine would make sense.

[tasket]

I'm a bit skeptical about alternatives like Alpine. They are rarely discussed or deployed, and the fact that the Qubes community has not adopted it for domU use may indicate a lack of flexibility or utility in the distro. I sometimes find even Fedora's selection of CLI tools too limiting.

Further, it adds a third Linux flavor that contributors and admins must become familiar with. This saps attention and energy away from exploring true alternative operating systems.

[tasket]

I'm a bit skeptical about alternatives like Alpine. They are rarely discussed or deployed, and the fact that the Qubes community has not adopted it for domU use may indicate a lack of flexibility or utility in the distro. I sometimes find even Fedora's selection of CLI tools too limiting.

Further, it adds a third Linux flavor that contributors and admins must become familiar with. This saps attention and energy away from exploring true alternative operating systems.

[v6ak]

I'm a bit skeptical about alternatives like Alpine. They are rarely discussed or deployed, and the fact that the Qubes community has not adopted it for domU use may indicate a lack of flexibility or utility in the distro. I sometimes find even Fedora's selection of CLI tools too limiting.

+1 While GUIVM will reduce the need of various drivers etc., I still find helpful if I can Google for various issues and find Fedora-related (or Debian-related or so) issues. I am not sure if I know all the relevant drivers, but: * Suspend will likely remain dom0's responsibility. * GUI drivers will be probably still needed in some cases (boot time, GUIVM crash, …). While this is much less an issue then (one can probably accept higher power consumption for few seconds during boot), it still can be important when the driver crashes. * Partitioning tools? (Hmm, how will they run with GUIVM?)

[v6ak]

I'm a bit skeptical about alternatives like Alpine. They are rarely discussed or deployed, and the fact that the Qubes community has not adopted it for domU use may indicate a lack of flexibility or utility in the distro. I sometimes find even Fedora's selection of CLI tools too limiting.

+1 While GUIVM will reduce the need of various drivers etc., I still find helpful if I can Google for various issues and find Fedora-related (or Debian-related or so) issues. I am not sure if I know all the relevant drivers, but: * Suspend will likely remain dom0's responsibility. * GUI drivers will be probably still needed in some cases (boot time, GUIVM crash, …). While this is much less an issue then (one can probably accept higher power consumption for few seconds during boot), it still can be important when the driver crashes. * Partitioning tools? (Hmm, how will they run with GUIVM?)

[Jeeppler]

My biggest issue with Fedora as Dom0 is, that the version which is used is in Qubes OS is already unsupported by the Fedora community. Qubes 4.0 is a good example. Qubes 4.0 was released on the 29th March 2018. Qubes 4.0 ships with Fedora 25. The end of life for Fedora 25 was the 12th December 2017. I would prefer to have a long term distribution as basis for Qubes OS. Both Debian and CentOS would be better options, because of there long term support. However, the problem with both is the lack of up-to-date driver for new computer models. In case of Debian this could be avoided by using Debian 'testing'.

[Jeeppler]

My biggest issue with Fedora as Dom0 is, that the version which is used is in Qubes OS is already unsupported by the Fedora community. Qubes 4.0 is a good example. Qubes 4.0 was released on the 29th March 2018. Qubes 4.0 ships with Fedora 25. The end of life for Fedora 25 was the 12th December 2017. I would prefer to have a long term distribution as basis for Qubes OS. Both Debian and CentOS would be better options, because of there long term support. However, the problem with both is the lack of up-to-date driver for new computer models. In case of Debian this could be avoided by using Debian 'testing'.

[v6ak]

Note that up-to-date Alpine might not get more community support than outdated Fedora. For CentOS and Debian, you're right. IMHO this will not be done before dom0+GUIVM split. After the split, it should be much easier to make changes to dom0 or GUIVM, either upgrading or switching to another distro.

[v6ak]

Note that up-to-date Alpine might not get more community support than outdated Fedora. For CentOS and Debian, you're right. IMHO this will not be done before dom0+GUIVM split. After the split, it should be much easier to make changes to dom0 or GUIVM, either upgrading or switching to another distro.

[adrelanos]

From Whonix linux distribution maintenance experience I can tell, that Debian testing is a nightmare. https://www.whonix.org/wiki/Dev/Operating_System#Why_is_Whonix_based_on_Debian_Stable.2C_not_Debian_Testing.3F I would very much like to see Debian stable in Qubes dom0 (and also sys-net / sys-firewall / sys-usb) by default. As a developer and user it is very difficult to cope up with two base distributions at the same time.

[adrelanos]

From Whonix linux distribution maintenance experience I can tell, that Debian testing is a nightmare. https://www.whonix.org/wiki/Dev/Operating_System#Why_is_Whonix_based_on_Debian_Stable.2C_not_Debian_Testing.3F I would very much like to see Debian stable in Qubes dom0 (and also sys-net / sys-firewall / sys-usb) by default. As a developer and user it is very difficult to cope up with two base distributions at the same time.

[tasket]

Seems like it would be easy for Debian stable instances to pull in drivers (especially) from testing. I've done this with various packages over the years with few issues.

[tasket]

Seems like it would be easy for Debian stable instances to pull in drivers (especially) from testing. I've done this with various packages over the years with few issues.

[DemiMarie]

It seems that the problem is twofold:

• Most LTS distros are aimed at enterprise systems and servers, which have a relatively limited range of hardware. Qubes, on the other hand, is aimed at end-users, so it needs to support pretty much any hardware that has the necessary virtualization support. That means a recent kernel and drivers, which the LTS distros avoid.
• On the other hand, Qubes cannot tolerate frequently upgrading Dom0. Why is that? I know that most recent Linux distributions can do this non-destructively.

One way around this is that the Linux kernel has a fantastic backwards-compatibility story when it comes to its userspace APIs. Perhaps we could drop-in a newer kernel? No, that won’t work.

[DemiMarie]

It seems that the problem is twofold:

• Most LTS distros are aimed at enterprise systems and servers, which have a relatively limited range of hardware. Qubes, on the other hand, is aimed at end-users, so it needs to support pretty much any hardware that has the necessary virtualization support. That means a recent kernel and drivers, which the LTS distros avoid.
• On the other hand, Qubes cannot tolerate frequently upgrading Dom0. Why is that? I know that most recent Linux distributions can do this non-destructively.

One way around this is that the Linux kernel has a fantastic backwards-compatibility story when it comes to its userspace APIs. Perhaps we could drop-in a newer kernel? No, that won’t work.

[Jeeppler]

It would not be a huge issue to upgrade Dom0 once in a while. The upgrades should not break anything. Rolling release would be to fast and LTS is to slow. The best would probably be a semi-rolling release model. I think, having every 2-3 months a kernel upgrade would be acceptable.

[Jeeppler]

It would not be a huge issue to upgrade Dom0 once in a while. The upgrades should not break anything. Rolling release would be to fast and LTS is to slow. The best would probably be a semi-rolling release model. I think, having every 2-3 months a kernel upgrade would be acceptable.

[DemiMarie]

What about using Fedora’s system-upgrade mechanism to upgrade dom0?

…

On Mon, Apr 9, 2018, 3:15 PM Jeppler ***@***.***> wrote: It would not be a huge issue to upgrade Dom0 once in a while. The upgrades should not break anything. Rolling release would be to fast and LTS is to slow. The best would probably be a semi-rolling release model. I think, having every 2-3 months a kernel upgrade would be acceptable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1919 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB2Vbky0VQ9YKCwSrMcZPnZ7hRuwlks5tm7NbgaJpZM4IJ5V1> .

[DemiMarie]

What about using Fedora’s system-upgrade mechanism to upgrade dom0?

…

On Mon, Apr 9, 2018, 3:15 PM Jeppler ***@***.***> wrote: It would not be a huge issue to upgrade Dom0 once in a while. The upgrades should not break anything. Rolling release would be to fast and LTS is to slow. The best would probably be a semi-rolling release model. I think, having every 2-3 months a kernel upgrade would be acceptable. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1919 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGGWB2Vbky0VQ9YKCwSrMcZPnZ7hRuwlks5tm7NbgaJpZM4IJ5V1> .

[v6ak]

What would it bring? Qubes uses a patched kernel, patched Xfwm (in order to support window coloring) etc. You can't just upgrade the Fedora in dom0 without porting anything. Even if you boot after such upgrade, it might bring some security issues, e.g., missing protection from USB devices, missing protection from block device headers parsing, missing window coloring on Xfce… If you just mean this way would be more user friendly (without suggesting to immediately allow upgrade to any newer version of Fedora), then it is a bit OT in this issue, I think.

[v6ak]

What would it bring? Qubes uses a patched kernel, patched Xfwm (in order to support window coloring) etc. You can't just upgrade the Fedora in dom0 without porting anything. Even if you boot after such upgrade, it might bring some security issues, e.g., missing protection from USB devices, missing protection from block device headers parsing, missing window coloring on Xfce… If you just mean this way would be more user friendly (without suggesting to immediately allow upgrade to any newer version of Fedora), then it is a bit OT in this issue, I think.