Archlinux qubes agent and template

[Olivier Médoc]

Hello,

I updated the Qubes agents for archlinux and the current template.

I attached the git patches:

core-agent-linux:
0001-archlinux-add-notification-daemon.patch
0002-archlinux-follow-fedora20-qubes-agent-improvement.patch
0034-archlinux-follow-fedora20-qubes-agent-improvement.patch
0035-archlinux-enable-disable-services-when-corresponding.patch

gui-agent-linux:
0001-xorg-revert-xorg-binary-to-start-as-the-root-user.patch
Note that this last patch is not specific to archlinux. It is a bypass to a new security mecanism introduced in xorg-server 1.16 that enforce starting Xorg using an unprivileged user (the current user) based on logind. The reason is that qubes-gui-daemon does not starts from a proper console session.

linux-template-builder:
0001-archlinux-update-current-is-version.patch
0002-archlinux-remove-linux-kernel-from-the-base-install-.patch
0003-archlinux-template-flavor-support-including-minimal-.patch
With these patches, a minimal template can be built that takes ~1G (~500M for the rpm) and that include working xterm, working qubes agents and sound.

Remaining bug:
- The template fails to perform the first start, probably because of systemd dependencies similar to qubes-sysinit.service, but that only occurs at the first startup. After the first startup successfully completed (using an old kernel version), the template can be started using the newest linux kernel.

Uploaded packages:
I uploaded all the packages to http://olivier.medoc.free.fr/archlinux/pkgs/. One can add this qubes agent repository to his archlinux template the following way:
Add the following to /etc/pacman.conf:
[qubes]
Server = http://olivier.medoc.free.fr/archlinux/pkgs/

Potential package signature and verification issues have still to be fixed. Currently you need to import my signature key:
# pacman-key --recv-key C1833B9C
# pacman-key --lsign-key C1833B9C

Key signature:
pub   2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
      Key fingerprint = D85E E12F 9678 51CC F433  515A 2043 E7AC C183 3B9C
uid                  Olivier MEDOC (Qubes-OS signing key) <o_m...@yahoo.fr>

Uploaded templates:
Now that the template is small enough I managed to upload it to my ftp server:
http://olivier.medoc.free.fr/fc20/rpm/qubes-template-minimal.rpm

Note that the template is not signed and use it at your own risk. Also, as discussed in remaining bugs, you probably have to start it with an old kernel version (at least the first time) or wait for this bug to be fixed.

[Zrubecz Laszlo]

On 1 August 2014 12:58, 'Olivier Médoc' via qubes-devel

<qubes...@googlegroups.com> wrote:
> I updated the Qubes agents for archlinux and the current template.

Cool!

> With these patches, a minimal template can be built that takes ~1G (~500M
> for the rpm) and that include working xterm, working qubes agents and sound.

I just wonder why any sound related stuff included in a minimal template?

> Note that the template is not signed and use it at your own risk. Also, as
> discussed in remaining bugs, you probably have to start it with an old
> kernel version (at least the first time) or wait for this bug to be fixed.

Please give us some hints about the 'old kernel' we should boot first.
- 3.9?
- 3.7?

Thanks.


--
Zrubi

[Olivier Médoc]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/01/14 12:58, 'Olivier Médoc' via qubes-devel wrote:
> Hello,
>
> I updated the Qubes agents for archlinux and the current template.
>
> I attached the git patches:

In fact, the HEAD has just changed for the gui agent and the patch probably do not apply anymore. Should I regenerate them ?

>
> core-agent-linux:
> 0001-archlinux-add-notification-daemon.patch
> 0002-archlinux-follow-fedora20-qubes-agent-improvement.patch
> 0034-archlinux-follow-fedora20-qubes-agent-improvement.patch
> 0035-archlinux-enable-disable-services-when-corresponding.patch
>
> gui-agent-linux:
> 0001-xorg-revert-xorg-binary-to-start-as-the-root-user.patch
> Note that this last patch is not specific to archlinux. It is a bypass to a new security mecanism introduced in xorg-server 1.16 that enforce starting Xorg using an unprivileged user (the current user) based on logind. The reason is that qubes-gui-daemon does not starts from a proper console session.
>
> linux-template-builder:
> 0001-archlinux-update-current-is-version.patch
> 0002-archlinux-remove-linux-kernel-from-the-base-install-.patch
> 0003-archlinux-template-flavor-support-including-minimal-.patch
> With these patches, a minimal template can be built that takes ~1G (~500M for the rpm) and that include working xterm, working qubes agents and sound.
>

> *Remaining bug:*

> - The template fails to perform the first start, probably because of systemd dependencies similar to qubes-sysinit.service, but that only occurs at the first startup. After the first startup successfully completed (using an old kernel version), the template can be started using the newest linux kernel.
>

> *Uploaded packages:*

> I uploaded all the packages to http://olivier.medoc.free.fr/archlinux/pkgs/. One can add this qubes agent repository to his archlinux template the following way:
> Add the following to /etc/pacman.conf:
> [qubes]
> Server = http://olivier.medoc.free.fr/archlinux/pkgs/
>
> Potential package signature and verification issues have still to be fixed. Currently you need to import my signature key:
> # pacman-key --recv-key C1833B9C
> # pacman-key --lsign-key C1833B9C
>
> Key signature:
> pub   2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
>       Key fingerprint = D85E E12F 9678 51CC F433  515A 2043 E7AC C183 3B9C
> uid                  Olivier MEDOC (Qubes-OS signing key) <o_m...@yahoo.fr>
>

> *Uploaded templates:*

> Now that the template is small enough I managed to upload it to my ftp server:
> http://olivier.medoc.free.fr/fc20/rpm/qubes-template-minimal.rpm
>
> Note that the template is not signed and use it at your own risk. Also, as discussed in remaining bugs, you probably have to start it with an old kernel version (at least the first time) or wait for this bug to be fixed.
>
>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJT26sVAAoJEJ54sGCFWKhbGjUH/R/7KJTVRvDE9eq5ve8/SH5i
922nLCEiV6ftc9usPVGh/tOa/IZLMkn8nsj0FuQy2wa1WP2+tMpxN8QnIWKhjSD9
0HpRTbRh6NHvtd6Rnm0GSaF3e/889sROZa5eZZn62PvuK26OJjy+Z1eOP1eu/+D5
1z03EkRmsaqGCOKrmMyZKnJ3tg2vO78cpghfnoFxh5dP8VEwSWPtOh8G6qtVDnIz
aLRKPxX8NRtlpRD08MfbxT4Mq1DiKLVkIHpOzcBYUr+bpdUT3f2pB089foL/3ieW
9mvz2TtFpjoMITSzajQlbjPh0JjS39Wy946gPdWF2NrBTJjzRHg5QV0R6t3AHEE=
=RRo4
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

On 01.08.2014 16:58, 'Olivier Médoc' via qubes-devel wrote:
>
> On 08/01/14 12:58, 'Olivier Médoc' via qubes-devel wrote:
>> Hello,
>
>> I updated the Qubes agents for archlinux and the current template.
>
>> I attached the git patches:
> In fact, the HEAD has just changed for the gui agent and the patch
> probably do not apply anymore. Should I regenerate them ?

Yes, please. See below.

>> core-agent-linux:
>> 0001-archlinux-add-notification-daemon.patch
>> 0002-archlinux-follow-fedora20-qubes-agent-improvement.patch
>> 0034-archlinux-follow-fedora20-qubes-agent-improvement.patch
>> 0035-archlinux-enable-disable-services-when-corresponding.patch

Applied.

>> gui-agent-linux:
>> 0001-xorg-revert-xorg-binary-to-start-as-the-root-user.patch
>> Note that this last patch is not specific to archlinux. It is a bypass
> to a new security mecanism introduced in xorg-server 1.16 that enforce
> starting Xorg using an unprivileged user (the current user) based on
> logind. The reason is that qubes-gui-daemon does not starts from a
> proper console session.

Very similar problem was fixed as part of debian support. Perhaps this can be
unified? It looks totally different, so I'm not sure if possible...

Relevant diff:
http://git.qubes-os.org/?p=marmarek/gui-agent-linux.git;a=blobdiff;f=appvm-scripts/usrbin/qubes-run-xorg.sh;h=6ef0079c6346ac8f1265a207435143514f0d0468;hp=38065c596ce6d1463ea9fbdcb0119394d1aec834;hb=6b1a400a55707242ab4ad6608b6b9c64e09da2ca;hpb=4a7d641482871f625ecdc0ac80d65c1d63995721

>> linux-template-builder:
>> 0001-archlinux-update-current-is-version.patch
>> 0002-archlinux-remove-linux-kernel-from-the-base-install-.patch
>> 0003-archlinux-template-flavor-support-including-minimal-.patch
>> With these patches, a minimal template can be built that takes ~1G
> (~500M for the rpm) and that include working xterm, working qubes agents
> and sound.

Applied.

>
>> *Remaining bug:*
>> - The template fails to perform the first start, probably because of
> systemd dependencies similar to qubes-sysinit.service, but that only
> occurs at the first startup. After the first startup successfully
> completed (using an old kernel version), the template can be started
> using the newest linux kernel.

Strange... Perhaps some problem with /lib/modules mounting?

>> *Uploaded packages:*
>> I uploaded all the packages to
> http://olivier.medoc.free.fr/archlinux/pkgs/. One can add this qubes
> agent repository to his archlinux template the following way:
>> Add the following to /etc/pacman.conf:
>> [qubes]
>> Server = http://olivier.medoc.free.fr/archlinux/pkgs/
>
>> Potential package signature and verification issues have still to be
> fixed. Currently you need to import my signature key:
>> # pacman-key --recv-key C1833B9C
>> # pacman-key --lsign-key C1833B9C
>
>> Key signature:
>> pub 2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
>> Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
>> uid Olivier MEDOC (Qubes-OS signing key)
> <o_m...@yahoo.fr>

Do you want to include this repo by default? I assume that "package signature
and verification issues" simply means new key for those packages, right?

I think it is very close to the moment where I can upload archlinux template
rpm to qubes-templates-community repository. The only remaining need is some
way to update qubes packages (=repo with updates).

>> *Uploaded templates:*
>> Now that the template is small enough I managed to upload it to my ftp
> server:
>> http://olivier.medoc.free.fr/fc20/rpm/qubes-template-minimal.rpm
>
>> Note that the template is not signed and use it at your own risk.
> Also, as discussed in remaining bugs, you probably have to start it with
> an old kernel version (at least the first time) or wait for this bug to
> be fixed.

--

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?

[Olivier Médoc]

On 08/01/14 13:32, Zrubecz Laszlo wrote:
> On 1 August 2014 12:58, 'Olivier Médoc' via qubes-devel
> <qubes...@googlegroups.com> wrote:
>> I updated the Qubes agents for archlinux and the current template.
>
> Cool!
>
>> With these patches, a minimal template can be built that takes ~1G (~500M
>> for the rpm) and that include working xterm, working qubes agents and sound.
>
> I just wonder why any sound related stuff included in a minimal template?

Hello,

The sound packages are set as dependencies instead of optional dependencies for qubes agents. One of the reason is to patch an archlinux bug during the qubes package installation.

This way every thing is installed automatically. If not, when a user install the sound packages he will have to force reinstalling the qubes agents.

>
>> Note that the template is not signed and use it at your own risk. Also, as
>> discussed in remaining bugs, you probably have to start it with an old
>> kernel version (at least the first time) or wait for this bug to be fixed.
>
> Please give us some hints about the 'old kernel' we should boot first.
> - 3.9?
> - 3.7?
>
> Thanks.

In fact, I use a custom archlinux kernel instead of qubes-fedora ones. It is the version 3.10.35-lts.

[Olivier Médoc]

Ok, I will check that, the bug seems to be quite similar, but I don't
know if the solution is effective in archlinux (XSession does not seems
to exists).

>>> linux-template-builder:
>>> 0001-archlinux-update-current-is-version.patch
>>> 0002-archlinux-remove-linux-kernel-from-the-base-install-.patch
>>> 0003-archlinux-template-flavor-support-including-minimal-.patch
>>> With these patches, a minimal template can be built that takes ~1G
>> (~500M for the rpm) and that include working xterm, working qubes agents
>> and sound.
> Applied.
>
>>> *Remaining bug:*
>>> - The template fails to perform the first start, probably because of
>> systemd dependencies similar to qubes-sysinit.service, but that only
>> occurs at the first startup. After the first startup successfully
>> completed (using an old kernel version), the template can be started
>> using the newest linux kernel.
> Strange... Perhaps some problem with /lib/modules mounting?
>

I don't really know. It does not survives the root switch, but it
apparently mount xvdd successfully:

[ 1.328179] systemd[1]: systemd 208 running in system mode. (+PAM
+LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
[ 1.328316] systemd[1]: Detected virtualization 'xen'.
[ 1.328331] systemd[1]: Running in initial RAM disk.

Welcome to .[0;34mFedora 20 (Heisenbug) dracut-037-11.git20140402.fc20
(Initramfs).[0m!

[ 1.329322] systemd[1]: Inserted module 'autofs4'
[ 1.329672] systemd[1]: No hostname configured.
[ 1.329695] systemd[1]: Set hostname to <localhost>.
[ 1.329793] systemd[1]: Initializing machine ID from random generator.
[ 1.456165] systemd[1]: Expecting device dev-mapper-dmroot.device...
Expecting device dev-mapper-dmroot.device...
[ 1.456264] systemd[1]: Starting -.slice.
[.[32m OK .[0m] Created slice -.slice.
[ 1.456618] systemd[1]: Created slice -.slice.
[ 1.456656] systemd[1]: Starting System Slice.
[.[32m OK .[0m] Created slice System Slice.
[ 1.456821] systemd[1]: Created slice System Slice.
[ 1.456848] systemd[1]: Starting Slices.
[.[32m OK .[0m] Reached target Slices.
[ 1.456909] systemd[1]: Reached target Slices.
[ 1.456933] systemd[1]: Starting Timers.
[.[32m OK .[0m] Reached target Timers.
[ 1.456992] systemd[1]: Reached target Timers.
[ 1.457030] systemd[1]: Starting udev Kernel Socket.
[.[32m OK .[0m] Listening on udev Kernel Socket.
[ 1.457158] systemd[1]: Listening on udev Kernel Socket.
[ 1.457189] systemd[1]: Starting udev Control Socket.
[.[32m OK .[0m] Listening on udev Control Socket.
[ 1.457309] systemd[1]: Listening on udev Control Socket.
[ 1.457340] systemd[1]: Starting Encrypted Volumes.
[.[32m OK .[0m] Reached target Encrypted Volumes.
[ 1.457397] systemd[1]: Reached target Encrypted Volumes.
[ 1.457435] systemd[1]: Starting Dispatch Password Requests to
Console Directory Watch.
[ 1.457559] systemd[1]: Started Dispatch Password Requests to Console
Directory Watch.
[ 1.457588] systemd[1]: Starting Paths.
[.[32m OK .[0m] Reached target Paths.
[ 1.457650] systemd[1]: Reached target Paths.
[ 1.457678] systemd[1]: Starting Journal Socket.
[.[32m OK .[0m] Listening on Journal Socket.
[ 1.457870] systemd[1]: Listening on Journal Socket.
[ 1.458143] systemd[1]: Starting dracut cmdline hook...
Starting dracut cmdline hook...
[ 1.459277] systemd[1]: Starting Create list of required static
device nodes for the current kernel...
Starting Create list of required static device nodes...rrent
kernel...
[ 1.460494] systemd[1]: Starting Sockets.
[.[32m OK .[0m] Reached target Sockets.
[ 1.460565] systemd[1]: Reached target Sockets.
[ 1.460598] systemd[1]: Starting Journal Service...
Starting Journal Service...
[.[32m OK .[0m] Started Journal Service.
[ 1.461784] systemd[1]: Started Journal Service.
Starting Apply Kernel Variables...
[.[32m OK .[0m] Reached target Swap.
[.[32m OK .[0m] Reached target Local File Systems.
[.[32m OK .[0m] Started Create list of required static device nodes
...current kernel.
Starting Create static device nodes in /dev...
[.[32m OK .[0m] Started Apply Kernel Variables.
[.[32m OK .[0m] Started Create static device nodes in /dev.
[.[32m OK .[0m] Started dracut cmdline hook.
Starting dracut pre-udev hook...
[ 1.866137] blkfront: xvda: flush diskcache: enabled; persistent
grants: enabled; indirect descriptors: enabled;
[ 1.868900] xvda: unknown partition table
[ 1.887411] blkfront: xvdb: flush diskcache: enabled; persistent
grants: enabled; indirect descriptors: enabled;
[ 1.917589] xvdb: unknown partition table
[ 1.919621] blkfront: xvdd: barrier or flush: disabled; persistent
grants: enabled; indirect descriptors: enabled;
[ 1.920735] xvdd: unknown partition table
[ 1.922111] blkfront: xvdc: flush diskcache: enabled; persistent
grants: enabled; indirect descriptors: enabled;
[ 1.923037] xvdc: xvdc1 xvdc2
[ 1.923381] Setting capacity to 819200
[ 1.923389] xvdd: detected capacity change from 0 to 419430400
[ 1.990606] bio: create slab <bio-1> at 1
[.[32m OK .[0m] Started dracut pre-udev hook.
Starting udev Kernel Device Manager...
[ 2.094528] systemd-udevd[205]: starting version 208
[.[32m OK .[0m] Started udev Kernel Device Manager.
Starting dracut pre-trigger hook...
[.[32m OK .[0m] Found device /dev/mapper/dmroot.
[.[32m OK .[0m] Started dracut pre-trigger hook.
Starting udev Coldplug all Devices...
[.[32m OK .[0m] Started udev Coldplug all Devices.
Starting dracut initqueue hook...
[.[32m OK .[0m] Reached target System Initialization.
[.[32m OK .[0m] Reached target Basic System.
[.[32m OK .[0m] Started dracut initqueue hook.
Starting dracut pre-mount hook...
[.[32m OK .[0m] Started dracut pre-mount hook.
Mounting /sysroot...
[ 2.509703] EXT4-fs (dm-0): mounted filesystem with ordered data
mode. Opts: (null)
[.[32m OK .[0m] Mounted /sysroot.
[.[32m OK .[0m] Reached target Initrd Root File System.
Starting Reload Configuration from the Real Root...
[.[32m OK .[0m] Started Reload Configuration from the Real Root.
[.[32m OK .[0m] Reached target Initrd File Systems.
[.[32m OK .[0m] Reached target Initrd Default Target.
[ 2.671098] dracut-pre-pivot[365]: mount: /dev/xvdd is
write-protected, mounting read-only
[ 2.672145] kjournald starting. Commit interval 5 seconds
[ 2.672199] EXT3-fs (xvdd): mounted filesystem with ordered data mode

Generating "/run/initramfs/rdsosreport.txt"


Entering emergency mode. Exit the shell to continue.
Type "journalctl" to view system logs.
You might want to save "/run/initramfs/rdsosreport.txt" to a USB stick
or /boot
after mounting them and attach it to a bug report.


:/#

I tried to list the files that are created on the first startup (as I
said, once the VM has been started once, I can start it sucessfully with
any kernel):

$ sudo find /mnt/vm/ -newer /mnt/vm/timestamp
/mnt/vm/
/mnt/vm/home
/mnt/vm/etc
/mnt/vm/etc/os-release
/mnt/vm/etc/xdg/autostart
/mnt/vm/etc/xdg/autostart/nm-applet.desktop
/mnt/vm/etc/resolv.conf
/mnt/vm/etc/mtab
/mnt/vm/etc/sysconfig
/mnt/vm/etc/sysconfig/clock
/mnt/vm/etc/udev
/mnt/vm/etc/udev/hwdb.bin
/mnt/vm/etc/hosts
/mnt/vm/etc/ld.so.cache
/mnt/vm/var
/mnt/vm/var/lib/systemd
/mnt/vm/var/lib/systemd/coredump
/mnt/vm/var/lib/systemd/random-seed
/mnt/vm/var/lib/systemd/timers
/mnt/vm/var/lib/systemd/timers/stamp-man-db.timer
/mnt/vm/var/lib/systemd/timers/stamp-logrotate.timer
/mnt/vm/var/lib/systemd/timers/stamp-shadow.timer
/mnt/vm/var/lib/systemd/catalog
/mnt/vm/var/lib/systemd/catalog/database
/mnt/vm/var/lib/qubes
/mnt/vm/var/lib/qubes/first-boot-completed
/mnt/vm/var/cache/ldconfig
/mnt/vm/var/cache/ldconfig/aux-cache
/mnt/vm/var/log
/mnt/vm/var/log/journal
/mnt/vm/var/log/journal/cf2c099ffa9440dc960e8589ee84cfdd
/mnt/vm/var/log/journal/cf2c099ffa9440dc960e8589ee84cfdd/system.journal
/mnt/vm/var/log/journal/cf2c099ffa9440dc960e8589ee84cfdd/user-1000.journal
/mnt/vm/var/log/lastlog
/mnt/vm/var/log/btmp
/mnt/vm/var/log/wtmp

>>> *Uploaded packages:*
>>> I uploaded all the packages to
>> http://olivier.medoc.free.fr/archlinux/pkgs/. One can add this qubes
>> agent repository to his archlinux template the following way:
>>> Add the following to /etc/pacman.conf:
>>> [qubes]
>>> Server = http://olivier.medoc.free.fr/archlinux/pkgs/
>>> Potential package signature and verification issues have still to be
>> fixed. Currently you need to import my signature key:
>>> # pacman-key --recv-key C1833B9C
>>> # pacman-key --lsign-key C1833B9C
>>> Key signature:
>>> pub 2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
>>> Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
>>> uid Olivier MEDOC (Qubes-OS signing key)
>> <o_m...@yahoo.fr>
> Do you want to include this repo by default? I assume that "package signature
> and verification issues" simply means new key for those packages, right?
> I think it is very close to the moment where I can upload archlinux template
> rpm to qubes-templates-community repository. The only remaining need is some
> way to update qubes packages (=repo with updates).

Yes it is only about testing if it really reject unsigned package and
finding how renewing the keys in 2 years automatically.

Of course I can include it by default by replacing the local repository
created for installation purposes.

[7v5w7go9ub0o]

On 08/05/14 06:12, 'Olivier Médoc' via qubes-devel wrote:
> On 08/03/14 00:05, Marek Marczykowski-GÃŗrecki wrote:
>> On 01.08.2014 16:58, 'Olivier MÊdoc' via qubes-devel wrote:

Is Grsecurity compatible with these changes?

Is Grsecurity something you might want to build into your base kernel at
a modest level: e.g. non-user-involving modifications such as: internal
increased entropy pools, memory protections, randomized structure
location, etc.?

<https://wiki.archlinux.org/index.php/grsecurity#Installation>

<https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options>

[Olivier Médoc]

Hello,

I updated again the archlinux agent and fixed some bugs with the new archlinux install ISO.

Patches are attached and have been prepared based on the release2 tag of Marmarek repository (except for linux-template-builder which is apparently based on a 1 or 2 month commit.

- Xorg server bug: the Xorg server bug where xorg fail to start unprivileged, I didn't found any satisfying solution. Apparently, the xorg server process is started through su and logind does not register it as a valid console session. I don't know if xorg server starts unprivileged on Fedora or Debian, but from what I understood, fedora uses a specific PAM_console.so wrapper module that allows this (along with /run/console?). This module is not available on archlinux. Current workaround: I modify /etc/X11/XWrapper.conf during qubes-gui package installation in order to allow xorg server to start as root.

- Archlinux repository: I can apparently push new packages to my ftp server and sign it almost automatically (using a script called sign-packages.sh as suggested). I will update linux-template-builder to register this repository during the template building process.

- Archlinux minimal template: My running template is still working with the updated agents, however I didn't tested a fresh template since last time. I know the template failed to initialize the first time, probably because of a directory created after first boot but that is required by systemd scripts.

[Olivier Médoc]

[Marek Marczykowski-Górecki]

On Tue, Jan 13, 2015 at 02:36:02PM +0100, 'Olivier Médoc' via qubes-devel wrote:
> On 08/01/14 12:58, 'Olivier Médoc' via qubes-devel wrote:
> > Hello,
> >
> > I updated the Qubes agents for archlinux and the current template.
> >
> > I attached the git patches:
> >
> > core-agent-linux:
> > 0001-archlinux-add-notification-daemon.patch
> > 0002-archlinux-follow-fedora20-qubes-agent-improvement.patch
> > 0034-archlinux-follow-fedora20-qubes-agent-improvement.patch
> > 0035-archlinux-enable-disable-services-when-corresponding.patch
> >
> > gui-agent-linux:
> > 0001-xorg-revert-xorg-binary-to-start-as-the-root-user.patch
> > Note that this last patch is not specific to archlinux. It is a bypass
> > to a new security mecanism introduced in xorg-server 1.16 that enforce
> > starting Xorg using an unprivileged user (the current user) based on
> > logind. The reason is that qubes-gui-daemon does not starts from a
> > proper console session.
> >
> > linux-template-builder:
> > 0001-archlinux-update-current-is-version.patch
> > 0002-archlinux-remove-linux-kernel-from-the-base-install-.patch
> > 0003-archlinux-template-flavor-support-including-minimal-.patch
> > With these patches, a minimal template can be built that takes ~1G
> > (~500M for the rpm) and that include working xterm, working qubes
> > agents and sound.
> >

> > *Remaining bug:*

> > - The template fails to perform the first start, probably because of
> > systemd dependencies similar to qubes-sysinit.service, but that only
> > occurs at the first startup. After the first startup successfully
> > completed (using an old kernel version), the template can be started
> > using the newest linux kernel.
> >

> > *Uploaded packages:*

> > I uploaded all the packages to
> > http://olivier.medoc.free.fr/archlinux/pkgs/. One can add this qubes
> > agent repository to his archlinux template the following way:
> > Add the following to /etc/pacman.conf:
> > [qubes]
> > Server = http://olivier.medoc.free.fr/archlinux/pkgs/
> >
> > Potential package signature and verification issues have still to be
> > fixed. Currently you need to import my signature key:
> > # pacman-key --recv-key C1833B9C
> > # pacman-key --lsign-key C1833B9C
> >
> > Key signature:
> > pub 2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
> > Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
> > uid Olivier MEDOC (Qubes-OS signing key)
> > <o_m...@yahoo.fr>
> >

> > *Uploaded templates:*

> > Now that the template is small enough I managed to upload it to my ftp
> > server:
> > http://olivier.medoc.free.fr/fc20/rpm/qubes-template-minimal.rpm
> >
> > Note that the template is not signed and use it at your own risk.
> > Also, as discussed in remaining bugs, you probably have to start it
> > with an old kernel version (at least the first time) or wait for this
> > bug to be fixed.
> >
> >
>
> Hello,
>
> I updated again the archlinux agent and fixed some bugs with the new
> archlinux install ISO.
>
> Patches are attached and have been prepared based on the release2 tag of
> Marmarek repository (except for linux-template-builder which is
> apparently based on a 1 or 2 month commit.
>

> - *Xorg server bug*: the Xorg server bug where xorg fail to start

> unprivileged, I didn't found any satisfying solution. Apparently, the
> xorg server process is started through su and logind does not register
> it as a valid console session. I don't know if xorg server starts
> unprivileged on Fedora or Debian, but from what I understood, fedora
> uses a specific PAM_console.so wrapper module that allows this (along
> with /run/console?). This module is not available on archlinux. Current
> workaround: I modify /etc/X11/XWrapper.conf during qubes-gui package
> installation in order to allow xorg server to start as root.

Apparently Fedora 21 also needs similar change.
One day we might rework gui-agent to start X server as normal user with
properly registered console session. But such a change will require a
lot of testing. We want to stabilize R3 first.

> - *Archlinux repository*: I can apparently push new packages to my ftp

> server and sign it almost automatically (using a script called
> sign-packages.sh as suggested). I will update linux-template-builder to
> register this repository during the template building process.

Great. Once you'll done it, I'll upload template to templates-community
repository, so installing the template will be much easier.

> - *Archlinux minimal template*: My running template is still working

> with the updated agents, however I didn't tested a fresh template since
> last time. I know the template failed to initialize the first time,
> probably because of a directory created after first boot but that is
> required by systemd scripts.

[Olivier Médoc]

Hello,

I finally manage to build a working template. The remaining bug was due
to dracut that silently fails just after pre-root switch if
/etc/os-release does not exists.

I uploaded all the new agents on
http://olivier.medoc.free.fr/archlinux/pkgs/ so that the custom
repository 'qubes' is available to archlinux templates.

The archlinux minimal template can be found on
http://olivier.medoc.free.fr/rpm/noarch/qubes-template-archlinux--x64-minimal-2.1.8-201501311819.noarch.rpm

The only thing is that my GPG key needs to be installed before being
able to use the custom repository:

Potential package signature and verification issues have still to be
fixed. Currently you need to import my signature key:
# pacman-key --recv-key C1833B9C
# pacman-key --lsign-key C1833B9C

Key signature:
pub 2048R/C1833B9C 2014-03-27 [expires: 2016-03-26]
Key fingerprint = D85E E12F 9678 51CC F433 515A 2043 E7AC C183 3B9C
uid Olivier MEDOC (Qubes-OS signing key)
<o_m...@yahoo.fr>

Marek, several patches from my last email have not been applied to your
repositories yet. Is it normal ? Are there problems with the patches ?

Please find the following patches (in addition to the patches in my last
email), the first two patches are not specific to archlinux:
linux-utils (release2):
0001-filecopy-O_TMPFILE-is-already-defined-in-usr-include.patch

gui-agent-linux (release2):
0001-configure-ensure-libtoolize-binary-is-used.patch

linux-template-builder:
0001-archlinux-fix-etc-os-release-and-add-remote-qubes-re.patch

Thanks a lot for your support,
Olivier Médoc

[jeremia...@web.de]

Hey Olivier,

thank you for your work. But if I install the package I get some errors
from the appmenus script.
Please look at the attached screenshoot for more details.

Best regards
Jeremias Eppler

[Marek Marczykowski-Górecki]

I'll add this to our wiki...

> Marek, several patches from my last email have not been applied to your
> repositories yet. Is it normal ? Are there problems with the patches ?

Sorry, I've lost your email in a long queue of other mails...
Now applied (actually core-agent-linux patches was already applied
earlier).

> Please find the following patches (in addition to the patches in my last
> email), the first two patches are not specific to archlinux:
> linux-utils (release2):
> 0001-filecopy-O_TMPFILE-is-already-defined-in-usr-include.patch

This one is already fixed.

> gui-agent-linux (release2):
> 0001-configure-ensure-libtoolize-binary-is-used.patch
>
> linux-template-builder:
> 0001-archlinux-fix-etc-os-release-and-add-remote-qubes-re.patch

Done.

[Olivier Médoc]

On 02/01/15 23:04, jeremia...@web.de wrote:
> Hey Olivier,
>
> thank you for your work. But if I install the package I get some errors
> from the appmenus script.
> Please look at the attached screenshoot for more details.
>
> Best regards
> Jeremias Eppler

Hello,

I think the reason is that I don't initialize appmenus at the end of the
template creation procedure. I my case, the template still install
successfully (even if there are errors).