Qubes on a Shoestring in a Hurry

[unc...@sigaint.org]

Hello,

How do I strip down Qubes (e.g. from the boot menu or system config) to
minimize resource usage, especially in the graphics subsystem?

I urgently need to get Qubes working on an old laptop with 2GB RAM,
underpowered CPU and weak GPU (see below). By "urgently" I refer to a
vulnerable personal situation I don't care to discuss publicly, save to
say that the €20 for another SODIMM could mean no food and still no
guarantee to get Qubes running... and I need a secure wifi communications
station while soon living out of my automobile.

The Qubes 3.1R-alpha1.1 LIVE version boots, but is unusable even with
great patience. The menus flicker, and are almost impossible to click
when they come up at all. From experience, I suspect the GPU is eating
shared memory and still not getting enough of it. If lack of RAM is not
the problem, I am in trouble. I did try the basic graphics mode from the
"Troubleshooting" option in the boot menu; but then the system hangs in
text mode during boot, without any interesting messages.

The processor is AMD E-350, graphics Radeon 6310. This was a €250 laptop,
when it was still manufactured five years ago! But it is what I have. I
only need a few qubes to begin with: Whonix Gateway, Whonix Workstation,
and one or two network utility qubes which should not take much in
resources. Eventually I would scrape together more RAM... if I could just
get it working.

My experience level: UNIX yes, Linux not much, Xen not at all. I have
hacked my BSD kernel, but am a real Linux newbie. I am looking to Qubes
as the only out-of-the-box OS which advertises a sane approach to securing
the graphical user interface (the Xorg code scares me). If I had a month
or two to work on this, I could probably roll something of my own; but
very suddenly, today, I need to deal with the "real world" where survival
in society can depend on websites which are "Javascript required".

More specific questions:

* How to get more detailed diagnostic messages? (Maybe lack of RAM is not
what is wrong.)

* How to strip out anything fancy, especially in the graphics? (I don't
mind running at 640x480 with all glitz turned off.)

* Any other tips/advice? (Even "you ask the impossible" would be
appreciated, so I don't waste time I don't have. But I note that [1]
says, "It is possible to install Qubes on a system with 2 GB of RAM, but
the system would probably not be able to run more than three qubes at a
time.")

All due thanks in advance!

"Uncubed"

[1]
https://www.qubes-os.org/doc/user-faq/#how-much-memory-is-recommended-for-qubes

[Holger Levsen]

On Sat, Jun 04, 2016 at 12:19:14PM -0000, unc...@sigaint.org wrote:
> The Qubes 3.1R-alpha1.1 LIVE version boots, but is unusable even with
> great patience. The menus flicker, and are almost impossible to click
> when they come up at all.

did you try XFCE instead of KDE? XFCE is much more ressource friendly.
Also the live version is less snappy in my experience…


--
cheers,
Holger

[Robin Schneider]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi

> * How to get more detailed diagnostic messages? (Maybe lack of RAM is not
> what is wrong.)

I would start with going thought the kernel log using `dmesg` in dom0. This
might help to identify issues. Sounds like your GPU might need some tweaking.

> * Any other tips/advice? (Even "you ask the impossible" would be
> appreciated, so I don't waste time I don't have. But I note that [1] says,
> "It is possible to install Qubes on a system with 2 GB of RAM, but the
> system would probably not be able to run more than three qubes at a
> time.")

You can maybe try to give dom0 a bit of swap space considering the 2 GB of RAM :
)

- --
Live long and prosper
Robin `ypid` Schneider
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXUsvAAAoJEIb9mAu/GkD41EAQAJVqugSwlkVw93pSyq1EWc9o
NQQk8+8SG/CmBc8eKCQDd2fWstaYwz4ml7EyclHd7s5VXfs4g0zlnrBo3gqEBDvG
HcO900Re1z5q2zPA2XTg64f0yfAkLpCQI5WmrdnsFOGeC63uIZbL4hqPnBq9sWzN
CahoFjgcDHYHHlviEUH+JPaeGYniRp/cGDhQv6lzyBbt5orh0w2ET7PzXxjvXmrp
rrDHD0qXS91naybHkUUSOyW7BkWb2pFBMfDMW49Yn3qzMQSaJsetzq/Yn30h7KMu
0rVdr6NjBox/UGgYNCC4rH2MvRfagrStnOhhOQpsaBVyLoyeNl78D1CphvNFJpVQ
PxuQZPPJXjh/gvGr85pC2PpTiXnQlWpprXBNCHEqGFbRgpk+jdHawx7zfkowBaQz
3cAs15eLTMhzGxaA2pJmNoeOlAUJdh+w5ZFM8ZjYvMVuu++jsv4f2tysiOyd2Ovm
OKPtoKabUQ+Ug26XCCeF0goIaBewlnGOa7fop19npILT1SBeL4HX7ki6LsuZrMQu
/DHfkSoflbR6KHo5Ol3Q6lvQP7JG0g7LUhE6PlAGSgaAoZ/mG2dGShIBLGH79BbK
4o6GmKXAfqWKxViBT/8vsbjhaIu9sFgRJA7Rq3fGrghx778U+2/wKfT9JvTvg4wq
zoqeN/WxHGeTyybBEsXz
=EnKW
-----END PGP SIGNATURE-----

[unc...@sigaint.org]

Thanks for the tip! I must try a full install; unfortunately that will
take me offline for some hours, for obvious reasons...

I tried the live version based on the general advice to use it for testing
compatability with Qubes, and was hoping to run qubes-hcl-report; but I
would need to get a terminal window open first.

"Uncubed"

[unc...@sigaint.org]

On Sat, June 4, 2016 12:38 "Robin Schneider" <yp...@riseup.net> wrote:

>> * How to get more detailed diagnostic messages? (Maybe lack of RAM is not
>> what is wrong.)
>
> I would start with going thought the kernel log using `dmesg` in dom0. This
> might help to identify issues. Sounds like your GPU might need some
tweaking.

I always reach for dmesg first, but I couldn't even get a terminal window
open. I am looking more for info-gathering which could be invoked from
the boot menu, or a way to start in a terminal without any Xorg at all, or
otherwise diagnose a system where the GUI is unusable; I should have been
more specific.

>>[snip]

>
> You can maybe try to give dom0 a bit of swap space considering the 2 GB
of RAM :)

I will try this if the install actually works. Or is there a way to tell
the Live version boot menu, "Trash this disk/slice and use it for swap"?

Thanks!

"Uncubed"

[unc...@sigaint.org]

On Sat, June 4, 2016 13:58, unc...@sigaint.org wrote:

> On Sat, June 4, 2016 12:35, "Holger Levsen" <hol...@layer-acht.org> wrote:
>
>> did you try XFCE instead of KDE? XFCE is much more ressource friendly.
>
>

> Thanks for the tip! I must try a full install; unfortunately that will
> take me offline for some hours, for obvious reasons...

I manually configured a 4GiB encrypted swap partition on an old hard disk,
and separately an encrypted LVM for Qubes, plus /boot and biosboot.

The good news is that Qubes R3.1 starts, and LXDE is smooth.

The bad news is that Qubes doesn't use the swap, and important things fail
due to out-of-memory.

I think the rest is best explained in chronological order.

In the Qubes installer, I elected to configure all the default qubes plus
the option to route all system/update traffic through Whonix
("experimental"). During the final stage when it shows a progress bar and
configures various qubes, I received the following modal dialog while it
was configuring networking:

--- begin dialog box
[title bar: "[Dom0]"]

Setting up networking failure!

['/usr/sbin/service', 'qubes-netvm', 'start'] failed:
Redirecting to /bin/systemctl start qubes-netvm.service
Job for qubes-netvm.service failed. See 'systemctl
status qubes-netvm.service' and 'journalctl -xn' for
details.

[Close]
--- end dialog box

When I hit "Close", the installer immediately finished. I do not know
whether it just bailed, and left important configuration undone, or if it
really finished. Thence to the Qubes login screen.

Running "systemctl status -l qubes-netvm.service", the pertinent lines
read in pertinent part (sorry, all of this is manually copied and
retyped):

--- begin quote
ERROR: ERROR: insufficient memory to start VM 'sys-firewall'
qubes-netvm.service: main process exited, code=exited, status=1/FAILURE
--- end quote

On startup, exactly two qubes are running: dom0 and sys-net. top(1)
(which I grit my teeth running in dom0; is it part of the TCB?) shows less
than 30M free memory, and... 0 swap!

Specific questions:

(a) How do I not only add my swap partition, but make Qubes automatically
unlock and use it at boot? I think this start config issue is probably a
Qubes-specific question, because Qubes is not really like other Linux
distributions in these under-the-hood system things. ;-)

(b) Related to (a), how do I make sure in the Qubes startup configuration
that it unlocks both the LVM partition and the swap partition with the
same LUKS passphrase? It is not good to type the passphrase multiple
times, e.g. in public with shoulder surfers and possibly security cameras
around. (Or better yet, swap with a one-time ephemeral key.)

(c) If I can get sufficient qubes started, how do I verify that all
network traffic (including update traffic) is routed through sys-whonix?
IOW in which qube do I fire up tcpdump(1) or check the logs, and really
get a global view of which packets are coming in/out? I am accustomed to
watching traffic (through pf and on physical interfaces). I just need to
know where in the Qubes intranet to get a global view, *without* risking
compromise to dom0 or another important qube with a tcpdump(1) or
libpcap(3) bug.

Thanks in advance!

Almost no longer,

"Uncubed" (un-uncubed?)

[Drew White]

On Sunday, 5 June 2016 19:20:43 UTC+10, unc...@sigaint.org wrote:

On Sat, June 4, 2016 13:58, unc...@sigaint.org wrote:

> On Sat, June 4, 2016 12:35, "Holger Levsen" <hol...@layer-acht.org> wrote:
>
>> did you try XFCE instead of KDE? XFCE is much more ressource friendly.
>
>
> Thanks for the tip!  I must try a full install; unfortunately that will
> take me offline for some hours, for obvious reasons...

I manually configured a 4GiB encrypted swap partition on an old hard disk,
and separately an encrypted LVM for Qubes, plus /boot and biosboot.

The good news is that Qubes R3.1 starts, and LXDE is smooth.

The bad news is that Qubes doesn't use the swap, and important things fail
due to out-of-memory.

Firstly, I would recommend setting Dom to use only 1 GB of RAM. This is best set after initial install and tell it to
NOT create ANY of the VMs..  That way you can define everything after first boot.
Set each VM to have 256 MB RAM. IF you have Memory Balancing on, then set Maximum to 356 for NetVM and ProxyVM

So install Qubes, but don't create any VMs, create them yourself AFTER you have configured Dom0 using the
live DVD /USB after the install.

You say you have 2 GB RAM, so have 512 for Dom0, but better for 1 GB.
Then you have 1 GB to share among the other VMs.
You can go as low as 50 MB for a NetVM. I've got mine running at that.
Min 256 for a ProxyVM (depending on how many firewall rules it will have to handle.)
So then you have 700MB (rough)) for all other VMs.


 

[Albin Otterhäll]

Drew White:

> Min 256 for a ProxyVM (depending on how many firewall rules it will have to
> handle.)

I haven't done it myself, but wouldn't MirageOS for the firewall be a
good option here?[1] It's experimental, but Uncubed seems to be in a
desperate situation where this is could be considered a good option.
Leonard has got it running, and the Firewall only needs 20MB compared to
the minimum 256MB that the Fedora based firewall need. This would give
Uncubed around thirty percent more memory that can be used by qubes. You
can find the ongoing discussion about implementing MirageOS in Qubes on
this mailing list.[2]

[1]
http://roscidus.com/blog/blog/2016/01/01/a-unikernel-firewall-for-qubesos/
[2] https://groups.google.com/forum/#!topic/qubes-devel/ZnGQkOU-Odc