Fedora 22+ in dom0

[marmarek]

Main reason: newer X drivers.

This is currently blocked on (any of):

• KDE 5 decoration plugin: #1784
• GNOME support: #1806

There is some unfinished work done on the installer: https://github.com/marmarek/qubes-installer-qubes-os/tree/fedora-22

Disclaimer: this ticket doesn't mean we've decided to stay with Fedora forever. It can be also replaced with another way of solving the main goal here: newer X drivers.

[marmarek]

For anyone wanting to help, approximate build instructions:

1. Create builder.conf - either copy from example-configs/qubes-os-master.conf, or use setup script

2. Change/add those settings:

   DIST_DOM0 = fc22
   BRANCH_desktop_linux_kde = fedora-22
   BRANCH_installer_qubes_os = fedora-22

3. Execute make get-sources

4. (optional) Apply patches from #1784

5. Execute make qubes iso

Then try to install resulting ISO (I recommend using external disk - not a fast way, but pretty painless).

If you've skipped step 4, window decorations will not be marked with VM color on KDE. But it should be possible to test and fix everything else.

[marmarek]

For anyone wanting to help, approximate build instructions:

1. Create builder.conf - either copy from example-configs/qubes-os-master.conf, or use setup script

2. Change/add those settings:

   DIST_DOM0 = fc22
   BRANCH_desktop_linux_kde = fedora-22
   BRANCH_installer_qubes_os = fedora-22

3. Execute make get-sources

4. (optional) Apply patches from #1784

5. Execute make qubes iso

Then try to install resulting ISO (I recommend using external disk - not a fast way, but pretty painless).

If you've skipped step 4, window decorations will not be marked with VM color on KDE. But it should be possible to test and fix everything else.

[jgriffiths]

I've started on this with a view to getting dom0 running on Fedora 23 (since Fedora 22 will be EOL in 4-5 months it doesn't seem a good target). There is a lot for me to learn about whats happening under the hood of the build process, but so far I've managed to get a fair amount building with some simple patches.

The instructions above assume @marmarek repos rather than the qubes ones I think. I'm building from the qubes repos. Pull requests are incoming for fixes and I will list them in a comment here to track progress.

[jgriffiths]

I've started on this with a view to getting dom0 running on Fedora 23 (since Fedora 22 will be EOL in 4-5 months it doesn't seem a good target). There is a lot for me to learn about whats happening under the hood of the build process, but so far I've managed to get a fair amount building with some simple patches.

The instructions above assume @marmarek repos rather than the qubes ones I think. I'm building from the qubes repos. Pull requests are incoming for fixes and I will list them in a comment here to track progress.

[jgriffiths]

I'm confused by tools/qemu-xen-traditional/ in our xen 4.6.0 tarball. there doesn't appear to be any such path in the official xen repos stable 4.6.0 branch. Is this just for back compat or is it actually used by qubes? It seems there are bugs in it, e.g. handling of rndis_state in tools/qemu-xen-traditional/hw/usb-net.c looks rather broken...

[jgriffiths]

I'm confused by tools/qemu-xen-traditional/ in our xen 4.6.0 tarball. there doesn't appear to be any such path in the official xen repos stable 4.6.0 branch. Is this just for back compat or is it actually used by qubes? It seems there are bugs in it, e.g. handling of rndis_state in tools/qemu-xen-traditional/hw/usb-net.c looks rather broken...

[marmarek]

Xen tarball is composed from multiple git repositories. tools/qemu-xen-traditional is here: http://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=summary

Or you can simply download the tarball from xenproject.org

[marmarek]

Xen tarball is composed from multiple git repositories. tools/qemu-xen-traditional is here: http://xenbits.xen.org/gitweb/?p=qemu-xen-traditional.git;a=summary

Or you can simply download the tarball from xenproject.org

[jgriffiths]

Thanks. Seems its been fixed in upstream qemu here but not back-ported into qemu-xen-traditional. I'll request a back-port at some point if we aren't going to move to using upstream.

[jgriffiths]

Thanks. Seems its been fixed in upstream qemu here but not back-ported into qemu-xen-traditional. I'll request a back-port at some point if we aren't going to move to using upstream.

[marmarek]

As for qemu - we're stuck with qemu-traditional, because it is the only one supported in stubdomains. Adding support for upstream qemu in stubdomains is being postponed since AFAIR Xen 4.4, and probably will also miss Xen 4.7... So, it's probably good idea to request a backport.

Let me know when you want me to merge those fixes. I'd prefer to do it in one go (or at least some bigger chunks) to save time on testing over and over.

[marmarek]

As for qemu - we're stuck with qemu-traditional, because it is the only one supported in stubdomains. Adding support for upstream qemu in stubdomains is being postponed since AFAIR Xen 4.4, and probably will also miss Xen 4.7... So, it's probably good idea to request a backport.

Let me know when you want me to merge those fixes. I'd prefer to do it in one go (or at least some bigger chunks) to save time on testing over and over.

[marmarek]

Offtopic: @jgriffiths take a look at https://www.qubes-os.org/doc/code-signing/. Soon we're going to introduce a policy to require contributions to be signed, to be included in https://www.qubes-os.org/team/ page. And it looks like you're going to send a lot of patches ;)

[marmarek]

Offtopic: @jgriffiths take a look at https://www.qubes-os.org/doc/code-signing/. Soon we're going to introduce a policy to require contributions to be signed, to be included in https://www.qubes-os.org/team/ page. And it looks like you're going to send a lot of patches ;)

[jgriffiths]

That's a shame about qemu, the gulf between the two seems large at first blush.

I'm not worried about getting the fixes merged so much as reviewed so I can make sure I'm not going off course. As long as you don't mind me submitting them and updating the list here then hold off as long as you need to. I don't want to take up too much of your time, but if you see a pull request thats dumb do please let me know if you can, thanks!

edit: I'll check out the signing info. I hope to be able to contribute more in the future, for sure.

[jgriffiths]

That's a shame about qemu, the gulf between the two seems large at first blush.

I'm not worried about getting the fixes merged so much as reviewed so I can make sure I'm not going off course. As long as you don't mind me submitting them and updating the list here then hold off as long as you need to. I don't want to take up too much of your time, but if you see a pull request thats dumb do please let me know if you can, thanks!

edit: I'll check out the signing info. I hope to be able to contribute more in the future, for sure.

[marmarek]

Ok :)

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]

Ok :)

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?

[jgriffiths]

I'm a bit stuck now building linux-pvgrub2-dom0. The details are in this gist if you have any idea how to find the underlying cause, please let me know.

I've built every other component now (skipping linux-dom0-updates), so AFAICS that's the only thing blocking "make iso" from working...

[jgriffiths]

I'm a bit stuck now building linux-pvgrub2-dom0. The details are in this gist if you have any idea how to find the underlying cause, please let me know.

I've built every other component now (skipping linux-dom0-updates), so AFAICS that's the only thing blocking "make iso" from working...

[marmarek]

Probably some inconsistency on Fedora update servers. You can try with
--refresh. Or simply skip linux-pvgrub2 for now (remove from
COMPONENTS and conf/comps-qubes.xml)).
This is quite independent piece of software and can be worked on later.

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]

Probably some inconsistency on Fedora update servers. You can try with
--refresh. Or simply skip linux-pvgrub2 for now (remove from
COMPONENTS and conf/comps-qubes.xml)).
This is quite independent piece of software and can be worked on later.

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?

[jgriffiths]

Probably some inconsistency on Fedora update servers.

Yes it looks like it. I need to check my caching setup as well, perhaps I should move to apt-cache-ng as you do.

Just want to note (in case anyone else is trying to build) that the fix for libsolv under xen is in testing. I used sudo dnf install -y dnf-1.1.7-2.fc23 dnf-plugins-core-0.1.17-1.fc23 libsolv-0.6.19-2.fc23 --enablerepo=updates-testing in the build VM and and the fc23 chroot to speed up building at lot.

EDIT: dnf now fixed in stable, above not needed

[jgriffiths]

Probably some inconsistency on Fedora update servers.

Yes it looks like it. I need to check my caching setup as well, perhaps I should move to apt-cache-ng as you do.

Just want to note (in case anyone else is trying to build) that the fix for libsolv under xen is in testing. I used sudo dnf install -y dnf-1.1.7-2.fc23 dnf-plugins-core-0.1.17-1.fc23 libsolv-0.6.19-2.fc23 --enablerepo=updates-testing in the build VM and and the fc23 chroot to speed up building at lot.

EDIT: dnf now fixed in stable, above not needed

[jgriffiths]

BRANCH_installer_qubes_os = fedora-22

FYI I've rebased your fedora22 to master here. My pull request will include a few more changes on top of that.

[jgriffiths]

BRANCH_installer_qubes_os = fedora-22

FYI I've rebased your fedora22 to master here. My pull request will include a few more changes on top of that.

[jgriffiths]

Open changes/TODO:

• Updated, should be merge-able now:
  QubesOS/qubes-linux-kernel#3
• These will need to go in together when fc23 work is complete:
  QubesOS/qubes-desktop-linux-xfce4#1
  QubesOS/qubes-installer-qubes-os#1
• linux-pvgrub2-dom is still broken by fedora package errors
• Need to ask for xen-traditional merge as discussed above

[jgriffiths]

Open changes/TODO:

• Updated, should be merge-able now:
  QubesOS/qubes-linux-kernel#3
• These will need to go in together when fc23 work is complete:
  QubesOS/qubes-desktop-linux-xfce4#1
  QubesOS/qubes-installer-qubes-os#1
• linux-pvgrub2-dom is still broken by fedora package errors
• Need to ask for xen-traditional merge as discussed above

[jgriffiths]

Currently QubesOS/qubes-installer-qubes-os#1 can build an fc23 iso. Booting the iso fails due to missing os-release files; my latest attempt to fix that hasn't worked.

TODO:

• Fixes from lorax 23 need to be backported into 22.1, or lorax 23 imported and patched backwards to support python2
• Our lorax-templates need to be rebased to the lorax version above

[jgriffiths]

Currently QubesOS/qubes-installer-qubes-os#1 can build an fc23 iso. Booting the iso fails due to missing os-release files; my latest attempt to fix that hasn't worked.

TODO:

• Fixes from lorax 23 need to be backported into 22.1, or lorax 23 imported and patched backwards to support python2
• Our lorax-templates need to be rebased to the lorax version above

[jgriffiths]

As much as it pains me to say it, I may have to give up on this.

I am trying different approaches locally to see what works and what doesn't. Most recently I was looking at upgrading pungi to python 3 instead of downgrading everything else to python 2, since http://fedora.portingdb.xyz/pkg/pungi/ indicates many of its dependencies are ported, and the former approach is difficult and not sustainable going forward. However whenever I change the packages and get build failures I have to rebuild from scratch to be sure I am testing the right thing, or face unrelated errors. The time it takes to effectively test changes is so long that I fear I am just wasting my (already quite limited) time.

My gut feeling is that it shouldn't be this painful to (essentially) download packaged sources, apply some patches and build them in chroot environments, even given the combinations of distro, dom0, vm and vm+flavours. I'll try to find another way to contribute in the meantime.

[jgriffiths]

As much as it pains me to say it, I may have to give up on this.

I am trying different approaches locally to see what works and what doesn't. Most recently I was looking at upgrading pungi to python 3 instead of downgrading everything else to python 2, since http://fedora.portingdb.xyz/pkg/pungi/ indicates many of its dependencies are ported, and the former approach is difficult and not sustainable going forward. However whenever I change the packages and get build failures I have to rebuild from scratch to be sure I am testing the right thing, or face unrelated errors. The time it takes to effectively test changes is so long that I fear I am just wasting my (already quite limited) time.

My gut feeling is that it shouldn't be this painful to (essentially) download packaged sources, apply some patches and build them in chroot environments, even given the combinations of distro, dom0, vm and vm+flavours. I'll try to find another way to contribute in the meantime.

[marmarek]

Thanks for enormous amount of work you've done here! I'll take it up from here.

[marmarek]

Thanks for enormous amount of work you've done here! I'll take it up from here.

[marmarek]

Regarding python version for pungi/lorax, it looks like pungi in fc23 (version 4.0.7) calls lorax as a separate process, instead of importing it (as it was before). So it shouldn't be a problem - just need to update our pungi version.

[marmarek]

Regarding python version for pungi/lorax, it looks like pungi in fc23 (version 4.0.7) calls lorax as a separate process, instead of importing it (as it was before). So it shouldn't be a problem - just need to update our pungi version.

[marmarek]

Just pushed fedora-23 branch to https://github.com/marmarek/qubes-installer-qubes-os
It contains QubesOS/qubes-installer-qubes-os#1 with some additional fixes. But it doesn't work yet, because of lorax bug (update will be soon). And probably some other problems I can't test right now.

[marmarek]

Just pushed fedora-23 branch to https://github.com/marmarek/qubes-installer-qubes-os
It contains QubesOS/qubes-installer-qubes-os#1 with some additional fixes. But it doesn't work yet, because of lorax bug (update will be soon). And probably some other problems I can't test right now.

[jgriffiths]

Thanks for the updates @marmarek, I will keep my branches synced in case I have another go at it :-)

[jgriffiths]

Thanks for the updates @marmarek, I will keep my branches synced in case I have another go at it :-)

[m-v-b]

I created a number of pull requests to help with the resolution of this issue:

• marmarek/qubes-installer-qubes-os#1
• marmarek/qubes-desktop-linux-kde#1
• marmarek/qubes-linux-template-builder#3
• marmarek/qubes-linux-pvgrub2#1
• QubesOS/qubes-gui-daemon#1
• marmarek/qubes-core-admin-linux#1
• marmarek/qubes-builder-rpm#3
• marmarek/qubes-artwork#1

Other than these, a few minor additional changes are required, but I did not create pull requests for them, as @jgriffiths has already done so:

• XFCE4 customizations (Please note that I have also prepared a bug-fix commit which fixes an issue that causes RPM installation transaction errors at system installation time: https://github.com/m-v-b/qubes-desktop-linux-xfce4/commit/6bccc030f555045d3690594206dd330ebaf0d967)
• Minor corrections in the Linux kernel repository

With the aforementioned changes, I am able to prepare an .iso image that boots into the installer and installs Qubes OS with legacy/BIOS boot. I have also briefly tested the installed system. Some of the remaining to-do items are the following:

• KDE's default settings need to be ported to KDE 5.
• When initial-setup is finished, kwin_x11 crashes with a segmentation fault. I was thinking of using the openbox window manager instead.
• initial-setup currently always uses graphical user interface as opposed to automatically switching to text user interface if the graphical interface does not work.

[m-v-b]

I created a number of pull requests to help with the resolution of this issue:

• marmarek/qubes-installer-qubes-os#1
• marmarek/qubes-desktop-linux-kde#1
• marmarek/qubes-linux-template-builder#3
• marmarek/qubes-linux-pvgrub2#1
• QubesOS/qubes-gui-daemon#1
• marmarek/qubes-core-admin-linux#1
• marmarek/qubes-builder-rpm#3
• marmarek/qubes-artwork#1

Other than these, a few minor additional changes are required, but I did not create pull requests for them, as @jgriffiths has already done so:

• XFCE4 customizations (Please note that I have also prepared a bug-fix commit which fixes an issue that causes RPM installation transaction errors at system installation time: https://github.com/m-v-b/qubes-desktop-linux-xfce4/commit/6bccc030f555045d3690594206dd330ebaf0d967)
• Minor corrections in the Linux kernel repository

With the aforementioned changes, I am able to prepare an .iso image that boots into the installer and installs Qubes OS with legacy/BIOS boot. I have also briefly tested the installed system. Some of the remaining to-do items are the following:

• KDE's default settings need to be ported to KDE 5.
• When initial-setup is finished, kwin_x11 crashes with a segmentation fault. I was thinking of using the openbox window manager instead.
• initial-setup currently always uses graphical user interface as opposed to automatically switching to text user interface if the graphical interface does not work.

[marmarek]

Thanks! I'll review and test this as soon as possible, but given the ISO build time it will take some time...

[marmarek]

Thanks! I'll review and test this as soon as possible, but given the ISO build time it will take some time...

[m-v-b]

Sorry for the delay, and thank you for the reviews! I am in the process of addressing your comments.

[m-v-b]

Sorry for the delay, and thank you for the reviews! I am in the process of addressing your comments.

[marmarek]

I've tried to build this and failed.

1. pungi fails at some python semaphore throwing NotImplementedError; mounting /dev/shm in chroot helps
2. Lorax fails on SEGV in librpm, not solved yet.

This was on the state with master branches + the whole installer-qubes-os PR included.

[marmarek]

I've tried to build this and failed.

1. pungi fails at some python semaphore throwing NotImplementedError; mounting /dev/shm in chroot helps
2. Lorax fails on SEGV in librpm, not solved yet.

This was on the state with master branches + the whole installer-qubes-os PR included.

[m-v-b]

Regarding missing /dev/shm in the chroot, I already have a commit in the qubes-builder repository, but apparently I forgot to mention it and publish my commit. Sorry about this. I will create a pull request for that as well.

Regarding librpm and segmentation faults, I have not yet encountered this issue. One possibility for this is that I have a commit implementing a .stamp file-based incremental build mechanism in my qubes-builder repository (which is a great time saver, but I do not know if it is suitable for inclusion), and I have not built Qubes OS from scratch in the past week or so.

[m-v-b]

Regarding missing /dev/shm in the chroot, I already have a commit in the qubes-builder repository, but apparently I forgot to mention it and publish my commit. Sorry about this. I will create a pull request for that as well.

Regarding librpm and segmentation faults, I have not yet encountered this issue. One possibility for this is that I have a commit implementing a .stamp file-based incremental build mechanism in my qubes-builder repository (which is a great time saver, but I do not know if it is suitable for inclusion), and I have not built Qubes OS from scratch in the past week or so.

[m-v-b]

Sorry for the delay. I have finally reproduced the lorax/librpm segmentation fault. (I did not observe this issue before because I was using an HTTP proxy for lorax in the kickstart configuration file.)

Fortunately, there is a bug report for it at [1] and a patch for it at [2]. Unfortunately, however, this means that we need to patch lorax until it is patched in the Fedora 23 repositories.

[1] https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1208296
[2] weldr/lorax@b3bf61b

[m-v-b]

Sorry for the delay. I have finally reproduced the lorax/librpm segmentation fault. (I did not observe this issue before because I was using an HTTP proxy for lorax in the kickstart configuration file.)

Fortunately, there is a bug report for it at [1] and a patch for it at [2]. Unfortunately, however, this means that we need to patch lorax until it is patched in the Fedora 23 repositories.

[1] https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=1208296
[2] weldr/lorax@b3bf61b

[marmarek]

If running through a proxy is enough, maybe we can setup one (unless
already configured). AFAIR Whonix template build scripts does/did exactly
that already, so shouldn't be that hard.

On the other hand, if lorax is now running as a separate process,
probably it doesn't use gpg key configured in kickstart file (I can't
see it in the lorax command line). So (I guess) it doesn't verify
signatures on downloaded packages.
Apparently RH don't care:
clumens/pykickstart#32

Which means we don't have other option than local package with our
patch...

I'll handle package verification (I've done that already for quite a few
installer related components).

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]

If running through a proxy is enough, maybe we can setup one (unless
already configured). AFAIR Whonix template build scripts does/did exactly
that already, so shouldn't be that hard.

On the other hand, if lorax is now running as a separate process,
probably it doesn't use gpg key configured in kickstart file (I can't
see it in the lorax command line). So (I guess) it doesn't verify
signatures on downloaded packages.
Apparently RH don't care:
clumens/pykickstart#32

Which means we don't have other option than local package with our
patch...

I'll handle package verification (I've done that already for quite a few
installer related components).

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]

Pushed updated fedora-23 branch. I think all the installer-related comments are handled now. ISO build works :) Haven't tried to install it yet.

[marmarek]

Pushed updated fedora-23 branch. I think all the installer-related comments are handled now. ISO build works :) Haven't tried to install it yet.

[m-v-b]

As a status update, I started building this commit from scratch. The referenced commit pulls some of my experimental changes via a custom override.conf file. For the record, previous builds of the same commit (but incremental and local) produced good results.

I was going to create pull requests for the following commits, but I am not sure if all of my changes are in a deliverable state: marmarek/qubes-installer-qubes-os@fedora-23...m-v-b:fedora-23-updates-merge

[m-v-b]

As a status update, I started building this commit from scratch. The referenced commit pulls some of my experimental changes via a custom override.conf file. For the record, previous builds of the same commit (but incremental and local) produced good results.

I was going to create pull requests for the following commits, but I am not sure if all of my changes are in a deliverable state: marmarek/qubes-installer-qubes-os@fedora-23...m-v-b:fedora-23-updates-merge

[m-v-b]

As another status update, the previous attempt did not go well, as I encountered intermittent errors related to my Internet connection, and I could not continue due to almost filling up the quota for my Internet connection in the past month -- this will hopefully be resolved in a few days. (I have started to use apt-cacher-ng as well.)

One issue I encountered with a from-scratch build yesterday is related to the Fedora 23 chroot bootstrap. Due to a bug involving the nss-softokn-freebl package's dependencies in Fedora, there is a need to use the updates repository as well as the fedora repository when bootstrapping the chroot.

Otherwise, dnf, rpm and others start to exit with SIGABRT due to the version of the NSPR library being too old in the fedora repository (but not in updates repository). Here is a link to the bug report about the low level details of this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1314592

In summary, there is a need to modify the yum-bootstrap.conf file in the qubes-builder-fedora repository to include the updates repository for Fedora 23.

[m-v-b]

As another status update, the previous attempt did not go well, as I encountered intermittent errors related to my Internet connection, and I could not continue due to almost filling up the quota for my Internet connection in the past month -- this will hopefully be resolved in a few days. (I have started to use apt-cacher-ng as well.)

One issue I encountered with a from-scratch build yesterday is related to the Fedora 23 chroot bootstrap. Due to a bug involving the nss-softokn-freebl package's dependencies in Fedora, there is a need to use the updates repository as well as the fedora repository when bootstrapping the chroot.

Otherwise, dnf, rpm and others start to exit with SIGABRT due to the version of the NSPR library being too old in the fedora repository (but not in updates repository). Here is a link to the bug report about the low level details of this issue: https://bugzilla.redhat.com/show_bug.cgi?id=1314592

In summary, there is a need to modify the yum-bootstrap.conf file in the qubes-builder-fedora repository to include the updates repository for Fedora 23.

[marmarek]

Ok, here is preliminary test image:
https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20160518.iso
https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20160518.iso.asc (signature made with my code key, not release key)

This is just for test upgraded dom0 (mostly new KDE) and make it easier for anyone wanting to help. Should not be used for anything serious and probably will not be able to upgrade to later stable (or even release candidate) version.
Known issues/limitations:

• there is only one template - Fedora 23 (no Whonix nor Debian, sorry)
• that one template have a bug - still using R3.1 repositories by default (this means no easy way to upgrade it later, without manual repository fix)
• some bugs mentioned in #1784
• initial setup fails to create default VMs (including sys-net and sys-firewall)
• many stuff not tested at all (for example Xfce4)

This image is compiled with use of qubes-os-master.conf, with those exceptions:

GIT_PREFIX = marmarek/qubes-
DISTS_VM = fc23
BRANCH_linux_kernel = devel-4.4
BRANCH_installer_qubes_os = fedora-23
BRANCH_desktop_linux_kde = fedora-23
BRANCH_desktop_linux_xfce4 = fedora-23

All the packages besides installer, KDE and Xfce4 are also uploaded to current-testing repository. So it is possible to build just specific component without building all the Qubes OS, by adding those options to builder.conf:

USE_QUBES_REPO_VERSION = 3.2
USE_QUBES_REPO_TESTING = 1

[marmarek]

Ok, here is preliminary test image:
https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20160518.iso
https://ftp.qubes-os.org/~marmarek/Qubes-DVD-x86_64-20160518.iso.asc (signature made with my code key, not release key)

This is just for test upgraded dom0 (mostly new KDE) and make it easier for anyone wanting to help. Should not be used for anything serious and probably will not be able to upgrade to later stable (or even release candidate) version.
Known issues/limitations:

• there is only one template - Fedora 23 (no Whonix nor Debian, sorry)
• that one template have a bug - still using R3.1 repositories by default (this means no easy way to upgrade it later, without manual repository fix)
• some bugs mentioned in #1784
• initial setup fails to create default VMs (including sys-net and sys-firewall)
• many stuff not tested at all (for example Xfce4)

This image is compiled with use of qubes-os-master.conf, with those exceptions:

GIT_PREFIX = marmarek/qubes-
DISTS_VM = fc23
BRANCH_linux_kernel = devel-4.4
BRANCH_installer_qubes_os = fedora-23
BRANCH_desktop_linux_kde = fedora-23
BRANCH_desktop_linux_xfce4 = fedora-23

All the packages besides installer, KDE and Xfce4 are also uploaded to current-testing repository. So it is possible to build just specific component without building all the Qubes OS, by adding those options to builder.conf:

USE_QUBES_REPO_VERSION = 3.2
USE_QUBES_REPO_TESTING = 1

[marmarek]

Workaround for failed default VMs creation - in dom0 terminal, as root:

echo -n dom0 > /etc/salt/minion_id
qubesctl top.enable config pillar=True
qubesctl state.sls config
qubesctl top.enable qvm.sys-net qvm.sys-firewall qvm.work qvm.personal qvm.vault qvm.untrusted
qubesctl state.highstate

[marmarek]

Workaround for failed default VMs creation - in dom0 terminal, as root:

echo -n dom0 > /etc/salt/minion_id
qubesctl top.enable config pillar=True
qubesctl state.sls config
qubesctl top.enable qvm.sys-net qvm.sys-firewall qvm.work qvm.personal qvm.vault qvm.untrusted
qubesctl state.highstate

[h01ger]

Sadly this image doesnt work for me, after "loading Initrd.img" the screen goes blank (with a cursor) and then goes dark and the system reboots. (thinkpad x260, skylake cpu)

(Not really surprised, but tested for completeness sake.)

[h01ger]

Sadly this image doesnt work for me, after "loading Initrd.img" the screen goes blank (with a cursor) and then goes dark and the system reboots. (thinkpad x260, skylake cpu)

(Not really surprised, but tested for completeness sake.)

[marmarek]

UEFI or legacy mode?

[marmarek]

UEFI or legacy mode?

[h01ger]

legacy

[h01ger]

legacy

[MMihelic]

Good morning, Marek. Here is a summary of my experience with the FC23 test ISO on x Lenovo X220 notebook with BIOS 1.42 (I think BIOS version is significant) using UEFI boot.
My notebook requires the "/mapbs /noexitboot" switches to boot or install Qubes. Using this switches I was able to install R3.1 on it. I guess something must have changed in the EFI loader since then since it is impossible to boot the latest ISO. The only way for me to install it was to use a secondary flash drive with rEFind (v0.10.3) to do the boot and then manually add the required parameters to the /EFI/boot/xen.efi entry.
In my experience the rEFInd has a lot better compatibility than other EFI loaders. I was even able to boot my experimenting Qubes (R3.1) copy on a external drive using VMWare Player 12.1.1 with it.

The rest of my observations are probably just gliches that will get ironed out. I also noticed that there is a package missing from the ISO and the installation complains but it continues. I think it was the chrony - I am sorry but, I didn't put it down. I have also noticed that the Plasma is not responding to my notebook display switch button.

-- Regards, Matej.

[MMihelic]

Good morning, Marek. Here is a summary of my experience with the FC23 test ISO on x Lenovo X220 notebook with BIOS 1.42 (I think BIOS version is significant) using UEFI boot.
My notebook requires the "/mapbs /noexitboot" switches to boot or install Qubes. Using this switches I was able to install R3.1 on it. I guess something must have changed in the EFI loader since then since it is impossible to boot the latest ISO. The only way for me to install it was to use a secondary flash drive with rEFind (v0.10.3) to do the boot and then manually add the required parameters to the /EFI/boot/xen.efi entry.
In my experience the rEFInd has a lot better compatibility than other EFI loaders. I was even able to boot my experimenting Qubes (R3.1) copy on a external drive using VMWare Player 12.1.1 with it.

The rest of my observations are probably just gliches that will get ironed out. I also noticed that there is a package missing from the ISO and the installation complains but it continues. I think it was the chrony - I am sorry but, I didn't put it down. I have also noticed that the Plasma is not responding to my notebook display switch button.

-- Regards, Matej.

[marmarek]

@MMihelic take a look at #2046, and especially commit message of fix. That's about adding /mapbs /noexitboot at installed system though, not installer itself. But for installer itself, make sure you've added also some placeholder after 'xen.efi' and before '/mapbs' (first argument is ignored, so actual option must be later).

[marmarek]

@MMihelic take a look at #2046, and especially commit message of fix. That's about adding /mapbs /noexitboot at installed system though, not installer itself. But for installer itself, make sure you've added also some placeholder after 'xen.efi' and before '/mapbs' (first argument is ignored, so actual option must be later).