How-to: Arch Linux on a Librem

ok scroll right to the bottom of,

might try and arch install alongside manjaro on my 13v2 this seems to suggest that it’s entirely possible


I’d be interested to know your results! We know the 13v4 will work, as the relevant specs are identical to the 15v4.


To help people looking to experiment outside of PureOS, it would be very useful to have the hardware reference pages completed. – at least the specs.

Or a more logical place would be alongside the other information at

Current-model hardware is easy because the specs are on the main site. Once it is no longer current or no longer being sold, it can be difficult to determine exactly what internals you’re working with.


Just out of curiosity, can you decrypt luks with your pgp smartcard ?

I know it can be done, but I have not tried it. I use a split password: half of it is in my head, the other half is a complex 64 character string saved my second slot.

The link back here from the Arch wiki was removed by another for a fair enough reason. Upside: Purism and Librems are now listed in the wiki as known to be compatible! yeehaw

1 Like

Arch dont officially support ARM architecture!
How much pkgs for ARM?

There is a separate Arch-based distro for ARM:

I already tried it on my Raspberry and can confirm that I did not face serious issues with finding the required (for me) packages. All I needed was in the official repo.

1 Like

Very useful and interesting post, that might put Arch on my list of options!

How do I know what can and cannot be safely installed from AUR?
For example, I’d be interested in installing VMWare, which is under that branch, how do I go about assessing if it is safe, is there some sort of a “score” given to a package or “reputation” awarded to a package uploader?

Not directly related to Arch, but still on topic of “Other OS”, I encountered difficulties installing a new OS on my Librem 15 v4 with Pureboot. The only way out was to flash the BIOS to use SeaBIOS instead of HEADS (Coreboot).

I have no intention of ever using Arch myself, but I just had to tell you that your guide here is top notch. You deserve a standing applause for the effort you put into this!


Yes, it is a great guide although I find it frightening for the novice. I think that this:
is simpler although it does not have all the bells and whistles of the above guide.
One more thing: I will not move to Wayland if the Wayland guys and girls insist on not supporting network transparency. Wayland reminds me the Gnome2-to-Gnome3 situation. The Gnome Foundation decided on their own to abandon Gnome2 and have been practically forcing people to follow them to a desktop you could not configure for years. Still, after so many years, window managers like AfterStep have more options than Gnome3.:smiley:

I understand this is good for small screens (like L5) but on the desktop, mate will stay my No1 choice; on L13 too.

Gnome or not still better than M$-windoze …

1 Like

X11 isn’t network transparent. It is from the application writers perspective, and even that only sorta. On a local machine, a buffer is allocated, and pointers to the buffer are passed around. Over the network, the buffers are copied. Each uses an independent section of the XServer code. Heck, by default Xorg doesn’t even listen on the IP stack anymore due to the lack of use, terrible security implications, and terrible performance of doing so.

Most Wayland compositor teams recommend using a different protocol for networked use, ideally one like VNC which supports h264 encoding the frames, thereby significantly improving bandwidth. That said, a network-aware extension for Wayland would be easy enough, if anyone actually wanted it. It’s also relatively easy to implement a shim, which acts as a Wayland server on the application side and a Wayland client on the display side. This, someone may do, as it would probably be able to outperform vnc, support at least some Wayland extensions, and be pretty easy to do. It would beat X-over-the-network by a wide margin too, as the every-frame-is-perfect promise of Wayland avoids the nasty tearing that networked X has.

1 Like

OK I do not want to get into technicalities. However, I know this: we have labs with many seats for students running LTSP5. The labs work for years now more than 10) with no problem at all. The thin clients are indeed thin and can not become fat (they are dedicated thin clients of Fujitsu). With Wayland around the corner we have to through everything in the garbage and buy fat clients. LTSP has moved to support only fat clients (LTSP2019).

This is just an example of a situation where Wayland is bad unless it becomes network transparent one way or the other.

Actually even fat clients are bad for a lab. Because most students are required to run heavy programs like MatLab which will require a very-fat client if it is to beat our LTSP servers.

Actually we are thinking about financing the continuation of the development of LTSP for thin clients, but this will again require network transparency of some sort.

Hm, that is something of an interesting use case… Normally the limiting factor in remote X connections is the sheer bandwidth required, without intelligent encoding, even with ssh forwarding and gzip compression, at 1080p each frame is 8 megabytes. Even if we assume 90% compression (yeah right, be lucky to get 20%), that means 20fps saturates a 100mb connection. Hence why vnc, rdp, and so on, are so strongly preferred. The require more CPU power to encode and decode the traffic, but can get much better compression, downcode the video stream, and intelligently drop frames as needed.

Sounds like your use case has sufficient network bandwidth that raw streams are acceptable, especially since the actual changed portion of the frame is likely to often be small (and X supports damage tracking), and CPU time is the significant limitation on the decoding (and possibly the encoding) end.

The good news is that, as I said, adding network transparency on-par with Xorg’s to Wayland is pretty straightforward. The simplest way works if you have Xorg running on the client. Just fire up an X-nested wayland session on the server, it’ll paint its window on the client. Of course, that doesn’t intelligently handle using the server’s video card for buffers, so performance and stability are something of a challenge (I can’t even get it to start if the client is running XWayland).

The real solution is a lightweight wayland compositor, running on the server side, which connects to a wayland client running on the client side. Basic functionality is pretty trivial to set up, some advanced things (screen locking/password passing) might need protocol extensions.

Does your common server have a dedicated video device?

Actually on a University lab the only thing you do not care is high resolution video :smiley: So the 1080 is not an issue. Low resolution is enough, and actually HD is the only thing that does not work. But it doesn’t matter.

Now the thin clients all have Gigabit ethernet, they are connected to a Gigabit switch with the server (which does have a dedicated video card if this is what you asked). On the LTSP side we use DirectX connections which makes everything go faster. We know that this is a security issue but the lab is inside a firewall perimeter and in lab security is not an issue as the labs are used for courses. Everything works nice (except HD), even usb sticks (OK this is ltspfs and not X), sound, the works.
The user just boots the client and s/he is presented with a login of the server (through ldm (which uses ssh)).

Is this possible with wayland? I do not think so. Or if I am wrong tell me.

There isn’t currently a Wayland implementation that can do that. The Wayland protocol itself doesn’t prevent it though, so writing a compositor which can would be relatively straightforward. It isn’t simple, since there are lots of messages that have to be relayed, and while many of them can be simply relayed, some of them will require extra work to emulate shared memory.

It’s actually easier for this sort of use, since the thin client doesn’t need to composite anything itself, it can just get the frames over the network and dump them to the screen. You could have the server side send each client frame individually, and composite them on the thin client, which you would need to do if you also wanted to run local programs on the thin client, but for dedicated fullscreen, it’s quite straightforward. Heck, it should even work with OpenGL and Vulkan programs.

We should probably move this to its own thread…

1 Like

I successfully installed Arch on a Librem laptop as well as a Lenovo following these instructions.

Thank you to the OP.


What is a proper name for a new thread? Wayland over X or LTSP on PureOs? In any case I would love to see an implementation of LTSP for thin clients on a rolling distribution. Currently no such thing exists.