New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fedora 22+ in dom0 #1807

Closed
marmarek opened this Issue Mar 4, 2016 · 37 comments

Comments

Projects
None yet
6 participants
@marmarek
Copy link
Member

marmarek commented Mar 4, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Mar 8, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 10, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 11, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Mar 11, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 11, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Mar 11, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Mar 11, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 11, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Mar 11, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 12, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Mar 12, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 13, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 13, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Mar 15, 2016

Open changes/TODO:

@jgriffiths

This comment has been minimized.

Copy link

jgriffiths commented Mar 21, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Apr 3, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented Apr 3, 2016

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

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Apr 5, 2016

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 added a commit to marmarek/qubes-installer-qubes-os that referenced this issue Apr 5, 2016

pungi: update to 4.0.7
This is required for compatibility with python3-based lorax.

Signature verification patches are submitted here:
https://pagure.io/pungi/pull-request/63

QubesOS/qubes-issues#1807
@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Apr 5, 2016

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

This comment has been minimized.

Copy link

jgriffiths commented Apr 5, 2016

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

@m-v-b

This comment has been minimized.

Copy link

m-v-b commented Apr 11, 2016

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

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:

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 added a commit to marmarek/qubes-installer-qubes-os that referenced this issue Apr 24, 2016

anaconda: enable only initial-setup.service variant
It should take care of choosing the right one.

QubesOS/qubes-issues#1807
@m-v-b

This comment has been minimized.

Copy link

m-v-b commented Apr 25, 2016

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

marmarek added a commit to marmarek/qubes-builder that referenced this issue Apr 25, 2016

Use non-master branch in desktop-linux-*
Content of those components depends on dom0 distribution version. Switch
to non-master for stable releases to allow upgrading dom0 in next
Qubes release.

QubesOS/qubes-issues#1807

marmarek added a commit to marmarek/qubes-desktop-linux-kde that referenced this issue May 4, 2016

@marmarek marmarek referenced this issue May 4, 2016

Open

Support for HiDPI #1951

2 of 4 tasks complete

marmarek added a commit to marmarek/qubes-core-admin-linux that referenced this issue May 4, 2016

@m-v-b

This comment has been minimized.

Copy link

m-v-b commented May 7, 2016

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 added a commit to marmarek/qubes-builder-rpm that referenced this issue May 18, 2016

@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented May 19, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented May 19, 2016

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

This comment has been minimized.

Copy link

h01ger commented May 19, 2016

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

This comment has been minimized.

Copy link
Member

marmarek commented May 19, 2016

UEFI or legacy mode?

@h01ger

This comment has been minimized.

Copy link

h01ger commented May 19, 2016

legacy

marmarek added a commit to marmarek/qubes-installer-qubes-os that referenced this issue May 24, 2016

qubes-release-3.2-0.24
Increase release number to 0.24, because upstream systemd package
conflicts with fedora-release<23-0.12.
Also cleanup transitional upgrade package.

QubesOS/qubes-issues#1807

marmarek added a commit to marmarek/qubes-installer-qubes-os that referenced this issue May 25, 2016

marmarek added a commit to marmarek/qubes-installer-qubes-os that referenced this issue May 25, 2016

marmarek added a commit to marmarek/qubes-installer-qubes-os that referenced this issue May 25, 2016

@MMihelic

This comment has been minimized.

Copy link

MMihelic commented May 26, 2016

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 added a commit to marmarek/qubes-core-admin-linux that referenced this issue Jun 3, 2016

dom0-updates: patch dnf.conf to use local repository
Add the same options as for yum. And do that with nice markers, instead
of forcefully overriding the entries.

QubesOS/qubes-issues#1807

marmarek added a commit to marmarek/qubes-installer-qubes-os that referenced this issue Jun 7, 2016

lorax: make sure qubes-artwork is installed
DNF based pungi isn't deterministic and sometimes chooses fedora-logos
(both provide system-logos). Make sure the right one is installed.

QubesOS/qubes-issues#1807
@marmarek

This comment has been minimized.

Copy link
Member

marmarek commented Jun 7, 2016

@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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment