ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5702
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sun Feb 24, 2019 11:58 am

Sounds good to me.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 26, 2019 2:22 pm

What follows is a partial, initial cut of some project goals, scope etc: not a specification!

This is very much a work in progress! Comments / suggestions are actively invited.

Project working name

Obviously, the most important thing to discuss is the name ^-^ So let's address that first.

Since, following ShiftPlusOne's suggestion, we're aiming to generalize the existing prototype to handle multiple OSes, including 32-bit ones, "raspbian-nspawn-64" isn't going to cut it.

So, I'm going to use pinc (= pi nspawn containers) as a working title for now (pronounced "pink"). If you have an idea for a better name, please chip in!

Overall goals

The overall goals of this project are to:
  • allow straightforward integration of non-Raspbian 32 and 64 bit OSes within the (32-bit) Raspbian desktop environment; and,
  • facilitate the sharing of such OS images by creators.

By straightforward integration, I mean that pinc users should be able to review the availability of, then install, start, stop and uninstall (instances of) guest OS images using only a simple GUI; further, that once an instance of an image is running, the user should (graphically) be able to open a shell within it; further, that applications installed within such a image instance should 'auto-magically' appear in the user's Raspbian desktop menu, from where they can be launched just as per 'standard' Raspbian apps; further, that when launched such applications should appear on the Raspbian desktop, have the ability to play sound and video, be able to access the network, and be able to operate on files in the user's home directory, just as if running as running as a normal process owned by that user in the host Raspbian OS.

By facilitate [...] sharing I mean that it should be possible for third-party OS image creators (those who regularly publish in this board's "Operating system distributions -> Other" forum, for example), to easily package, and publicize the availability of, OS images, so that end-users of pinc can "see", download, and use them in the manner just described.

For those coming fresh to this project, please note that a "proof of concept" of at least the menu and app integration components has been created - this is not "vapourware"; please review earlier posts in this thread for details, or see the bootable image available here.

It is intended that (at least for the 1.0 release) guest OSes will be hosted using a systemd-nspawn container.

Subject to QA approval, it is intended that pinc be made available via the official Raspbian repository (see notes on packaging below).


What pinc is not

This project is not:
  • NOOBS or PINN: while the OSes to be used will be booted, they will not be natively booted on the hardware, but rather started up inside a systemd-nspawn container. Raspbian-32 will always be the host OS (and it is assumed the user has already successfully configured it for network access etc.)
  • KVM: a single kernel will be shared by all OSes (host and guest(s)).
  • QEMU: emulation will not be used, guest OSes will run natively (this point might get relaxed; tbd).
  • chroot: guest OSes will run fully booted, with their own systemd and dbus, within a separate process namespace.
  • Docker: guest OSes will be natively multi-process and do not require any support middleware, other than systemd itself. At least initially, no concept of 'multi-layered' OS images will be supported, for simplicity. This is an OS, not service, deployment approach.
  • firejail: while the use of containers adds some security, the primary purpose here is not to facilitate a more unbreakable jail for OSes, but rather to more easily integrate them.
  • a CLI toolkit: the focus being rather on a simple system that 'just works', usable by only relatively inexperienced users.

Who will use pinc?

The target audience for pinc includes those who, while wishing to stay within the familiarity of the 32-bit Raspbian desktop, need (or would like) to:
  • run apps, or versions of apps, only available on 64-bit (e.g. mongodb-3.2);
  • run apps, or versions of apps, only available on other distros (e.g. Arch) or other releases of an OS (e.g. Debian Buster);
  • easily test software compatibility across multiple OSes.
  • try other OSes without having to restart their Pi.
  • try out other OSes that don't have (or have only limited) Pi driver support.
It is hoped that relatively inexperienced users will be able to use pinc successfully.

OS image creators will also use the pinc infrastructure to publicize and (possibly, see below) periodically build and distribute their images. (Such operations, being performed by a relatively small number of relatively knowledgeable individuals, will require the usage of CLI tools.)


Target hardware and software

To natively run 64-bit OSes a 64-bit kernel is required (under ARMv8a). That limits availability to the RPi3B, 3B+, 3A+, CM3 CM3L and 2Bv1.2 (per this post, TODO check).

However, if only 32-bit OSes are required, then any RPi should be usable. TODO check kernel requirements for systemd-nspawn against raspberrypi-kernel config.

The target host OS is 32-bit Raspbian with desktop (LXDE).

The pinc gui will (probably) be written in Python (PyQt?) so as to be straightforwardly portable. Support services (such as the 'reflectors' for .desktop files and /etc/{passwd,shadow,group,gshadow}) will be written in bash.


Some comments on scope

For 1.0, the following are out of scope:
  • guest OSes that don't run systemd
  • (gui support for) guest OSes that don't use X11 (but use e.g. wayland natively)
  • (sound support for) guest OSes that do not support pulseaudio
  • guest OSes shipped in a binary format incompatible with native execution on the Pi (e.g. x86_64)
  • guest OSes that require network namespacing to operate (may be relaxed when Raspbian migrates to Buster, please see notes on namespacing later)
  • guest OSes that require user namespacing to operate
  • guest applications that require MMAL / OpenMAX IL when booted under a 64-bit kernel
TODO: expand


Some comments on packaging

A 64-bit kernel is required to run 64-bit (unemulated) userspace, and since no official 64-bit kernel is currently provided in the RPF repos, one will be provided as part of this project, using the tarballs from my bcmrpi3-kernel-bis kernel autobuild project. A fair draft prototype of this has already been created by ShiftPlusOne; please see here ff.
The production variant of this will automatically track autobuild releases, and (subject to QA) be made available (as a versioned series of debs) in the official Raspbian repo.

The pinc gui application, support scripts and systemd service files will be published as a second package, with two variants:
  1. One that can support both 64-bit and 32-bit guest OSes, which will depend on the above 64-bit binary kernel package; and
  2. One that only supports 32-bit guest OSes, which will not.
Again, subject to QA, the intention is for these to be made available as debs in the official Raspbian repo.

OS images will likely be distributed as compressed, signed root filesystem tarballs, and published by placing an entry in a metadata file visible at a pre-arranged URL (known to the pinc client app). For example, we might follow the Gentoo overlay model here, and have a GitHub site, controlled by RPF, holding an "available_images.xml" (or similar) catalogue file, against which pull requests (PRs) may be made to add entries. (The precise mechanism TBD, so versions can efficiently be handled without necessarily requiring a sign-off each time.)

Users will be able to append their own known images via a local file too (requiring no special permissions).


On the trustworthiness of images

The format of the image catalogue file is TBD, but will contain a trust level for each image version. At least 3 levels will initially be supported:
  • Official: these are images distributed by the RPF themselves, hosted on their servers, and signed with an RPF release key. At least a 64-bit Debian (probably Buster) image will be provided by the time of the 1.0 release in this manner.
  • Community: these are images hosted and built on the pinc image server (see below), signed by a "community" key.
  • Personal: images hosted on servers other than the above, signed by the contributor themselves.

Some comments on infrastructure

I am in discussion currently with a potential sponsor who has expressed interest in funding a three-year VPS contract, to act as a community image server (CiS).

The idea is that this host would be managed by a group of individuals from the Pi user community and (should any wish to do so) some RPF engineers. Users could submit images for hosting on the CiS by providing a bash script (a sort of dockerfile-lite ^-^), which would, when invoked:
  • Check if a new image (of the particular target OS) needs to be built, and if so:
  • Build it. This would usually involve downloading a baseline image from a well-known official site (or using debootstrap, pacstrap etc to create same), adding some customization to it (additional packages etc.) using only official upstream repos, setting some required baseline configuration to make the image 'pinc-compatible' (see further comments below) and then tarring up the result.
Image tarballs created in this way would then be signed by a "community" key and hosted on the CiS itself. Autobuilds could be created on, say, a monthly cadence (ensuring end-users did not have to spend too much time on the initial package update step, since all provided images would be reasonably 'fresh').

Those managing the service would only need to review the submitted creation script once, at the outset, to check it didn't do anything obviously mendacious, that it only downloaded from official repos etc., and then approve it. Images thereby created would then have an accelerated (or automatic?) path to publication in the catalogue file.

NB: it may be that licensing concerns etc. prohibit such a service getting off the ground, but it'd be a nice 'halfway house' to provide users some level of assurance they aren't downloading anything truly toxic, without RPF having to sign off on everything.

Alternatively: could just run the scripts (a la ebuilds ^-^) on the end-user's system, constructing the desired spin 'on the fly'. In this case, only the scripts would need to be community hosted (after checking), and these could just live in a GitHub repo or similar. This idea breaks down somewhat where compilation etc. needs to be done for any packages, as then compiler and other build-support packages would need to be loaded by each end-user, rather than once at the CiS. TBD.


Namespacing

By default, guest OSes will run in their own process namespace, courtesy of systemd-nspawn.

However, due to issues with bind mounts in /tmp under the Stretch version of systemd (v232), network namespacing will initially not be supported (as the Unix abstract domain sockets for the host X11 server need to remain visible, see e.g. my notes here). This could be relaxed once the move to Buster has been completed. However, once network namespacing is used, a host bridge also needs to be put in place so the veth tunnel traffic from the container can be routed (and inter-container routing is also made more complex). Also, those users who want to do interface specific stuff in an image (for example, kali) will not want network namespacing on. So it should remain an optional feature, even when permitted by the OS.

Due to the relative complexity of specifying 'punchouts' under systemd-nspawn, user namespacing will also not initially be supported. It may be an option for future releases however.


Preparation of images

Modifying an existing OS root filesystem image for use with pinc should be straightforward. It will look something like:
  • Downloading the 'baseline' guest image, then entering it via a chroot (or non-boot systemd-nspawn).
  • Updating / downloading package metadata on the guest.
  • Installing systemd container support, sudo, pulseaudio and zenity libraries into the guest (plus their deps of course).
  • Setting locale and timezone (TBD)
  • Adding required scripts etc. (e.g. to ensure pulseaudio is used by default)
  • Disabling any services which might try to 'take control' of the RPi3 peripherals on boot
  • Adding any 'image maintainer payload' applications and setup (i.e., those specific to a particular 'spin')
  • Cleaning up the image (removing root's bash history, package archives, possibly package metadata), exiting the chroot.
  • Tarring up the resulting filesystem.
  • Signing the tarball.
Note that no additional users, groups etc. need be created as part of the image prep, since pinc's "reflector" services will take care of this auto-magically (this concept is already functional in the prototype, btw).


Images and instances

While we deliberately won't go down the Docker stacked-image rabbit hole for v1.0, it will probably be useful to borrow their terminology of 'images' and 'instances'.

So, when an OS image (probably a tarball, actually, rather than a true filesystem image) is downloaded, it will be stored in read-only form (in /var/lib/pinc or somewhere). Then when an instance of this is created, an OverlayFS will be built, with the 'upper' (copy-on-write) layer in /var/lib/machines, and the 'lower' (read-only) layer being the image itself. This makes it trivial (and very fast) to create multiple instances of an image, once it has been downloaded.

Future versions of pinc could possibly extend this (checkpointing etc.), but we'll keep things simple for now.

It may be beneficial to use SquashFS or similar for the (read-only) images themselves, should the the CPU overhead of decompression be outweighed by the benefit of fewer backing-store accesses onto relatively slow media. TBD.


Sketched use cases

An end-user story

Alice is an RPi3B+ user who would like to run a more up-to-date version of the Chromium browser than the one available in the standard Raspbian repo. Having done some research, she finds an appropriate version is available on 64-bit Debian Stretch. She opens the pinc application and sees this is available as an official image, and clicks on it to install. Once downloaded, she is prompted for an instance name, and chooses "debian-stretch-64" (!). The OS is booted in a container (this only takes a few seconds, and consumes minimal system memory) at which point her new instance appears in the pinc GUI. She clicks on it and selects "Open container shell...". A terminal opens inside the container OS instance, and she does a standard "sudo apt get update && sudo apt-get install -y chromium" to install the browser. Once this completes, a new menu item for her browser appears (auto-magically) inside the "Internet" section of her Raspbian desktop main menu, underneath her existing (32-bit) Chromium menu item. She clicks on the new item and 64-bit Chromium opens on her desktop. She browses to youtube.com - audio and video playback both work! She opens another tab, goes to a google doc and saves it in her home directory - this works too; the document is saved with her user credentials - and she isn't even logged on as "pi".

Alice installs a few more apps inside her container, and then elects, via the pinc GUI, to have the instance auto-started on boot. She powers down her RPi3. Later, she starts it back up again, and when the Raspbian desktop appears, clicks on the menu item to run (64-bit) Chromium. It opens (since the underlying container has been autostarted) with her browsing history intact.

NB, conveniently ^-^, this is a flow that has at least partially been prototyped; you can try it out yourself, using the 'proof of concept' raspbian-nspawn-64 image. Please see my post here.


Todo add to this with image creator's story etc.


On future directions

While out of scope for 1.0, there are some directions that could be subsequently explored with pinc:
  1. The use of emulation: for example, supporting x86_64 linux/systemd OS images via user-mode QEMU and binfmt_misc would be relatively straightforward.
  2. The integration of Windows applications using wine.
  3. The integration of non-systemd guest OSes (which are still linux).
  4. The integration of non-linux guest OSes and apps therein.
  5. etc.
The first two could probably be integrated fairly straightforwardly within a systemd-nspawn approach. The third is more problematic, and the fourth, challenging.

Nevertheless, targeting only arm/arm64 systemd-based linux OS images for 1.0 still covers a lot of bases. Most of the systems covered in the "Operating system distributions -> Other" board could probably be straightforwardly adapted (Debian, openSUSE, Arch, Ubuntu etc.)


Comments welcome!

To reiterate, at this stage this is very much a rough sketch / work in progress and comments are actively invited. Per the previously published schedule, I would like to complete the review period on this phase by Fri Mar 8. Ideally, please post comments in this thread; alternatively, I can be reached at [email protected].

Best,

sakaki

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 26, 2019 7:52 pm

Sorry sakaki, but I don't get it. This seems like a huge amount of work, but I honestly don't see the point of it. Who is going to produce the images for pinc? I can't see Fedora, openSUSE, Ubuntu etc producing official images especially to run under this. There doesn't seem to be a lot of individuals interested in producing 'normal' images, and this just fragments things further. There is already NOOBS, PINN, grub2 and u-boot capable of producing a multi-os SD card.

For me this is the wrong approach. I'm all for making running other OSs more accessible, but you do this by standardizing booting, installing and making Pi specific things easily available. The latter could be achieved by packaging pi stuff as snaps or flatpaks instead of raspbian debs.

It would be easy to create a 64 bit debian image with the rasberry pi desktop.

You've obviously already put a huge amount of thought and work into this, but I would caution about being too ambitious. Stick to having it work with your gentoo image or a debian image like in your opening post.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 26, 2019 9:41 pm

feelslikeautumn wrote:
Tue Feb 26, 2019 7:52 pm
Sorry sakaki, but I don't get it. This seems like a huge amount of work, but I honestly don't see the point of it. Who is going to produce the images for pinc? I can't see Fedora, openSUSE, Ubuntu etc producing official images especially to run under this. There doesn't seem to be a lot of individuals interested in producing 'normal' images, and this just fragments things further. There is already NOOBS, PINN, grub2 and u-boot capable of producing a multi-os SD card.
So, I guess I have a different opinion about this. Part of the problem with the RPi (or any not-totally-mainstream) platform is that major distros don't have the resources to target the specific drivers, kernel opts etc. to make it boot properly with all peripherals operational, and even if they do this for one model, things break when a new hardware rev is released (RPi2->3 or RPi3B -> B+ even). What they do have is their own (aarch32 or aarch64) repositories, often containing versions of software not available on Raspbian, particularly (for now anyhow) when you look at the 64-bit side of things.

The pinc approach lets you take a 'vanilla' aarch32 or aarch64 OS image (which is typically what distros officially provide) and then, via a simple bash script, setup construction of a pinc-compatible tarball (see notes above). You just have to build that script once, and it isn't a big deal (I've been writing a few of them over the last couple of days myself to check). Once that's in place, and submitted to the community server, new images (incorporating security updates etc. for fixed point releases ,and new versions of software for rolling ones) will automatically be made available and published. So the amount of maintainer effort is actually really tiny. And you can get away with this, because you're letting the Raspbian host OS take all the platform-specific strain.

The alternative (and I have lived it with my gentoo-on-rpi3-64bit image!) is to take a vanilla (say) aarch64 system that console-boots on (say) the RPi3B+, then try to get bluetooth, wifi, ethernet (with workarounds), vc4, etc. etc. all working with it. And keep releasing versions of this image to track the underlying OS, together with major revisions when the hardware bumps (Pi4, anyone?). The result can, I hope, be worth it, but even if/when you get it 100% right, many users don't want to take that "all-or-nothing" leap, they want their 64-bit minecraft server, or database, or whatever, to just work, but staying inside the familiar Raspbian desktop where all their other apps live. I think - and I might be wrong - the pinc approach relatively neatly finesses that dilemma. It isn't the right approach for all users.

And to clarify further, I'm absolutely not trying to compete with PINN or NOOBS with this - if you want to boot fully into a distro, by all means do so - I mean c'mon, I'm talking as a Gentoo fangirl here ^-^ That's not what this is about. What pinc tries to leverage rather, is the commitment of the RPF engineering team to keep Raspbian working correctly (and supported) with all RPi hardware going forward, and adds to it the ongoing package management commitment of those other OSes vanilla aarch64 (and 32) teams going forward. And makes the latter easily accessible for a wide spectrum of users of the former. For me, that's more than the sum of the parts.
feelslikeautumn wrote:
Tue Feb 26, 2019 7:52 pm
You've obviously already put a huge amount of thought and work into this, but I would caution about being too ambitious. Stick to having it work with your gentoo image or a debian image like in your opening post.
Well, I hear you. In fact I was genuinely in two minds about this point to begin with (see my point 2 under "Productionization (of the Userland Packages)" in this earlier post), but ShiftPlusOne's comments tipped me towards generalizing it. I think I can see how this more general approach could work, but maybe I'm mistaken - it wouldn't be the first time for sure ^-^ But even if I'm wrong, I think the more limited goals will still be delivered, I'll just have burnt some cycles building out some generality that doesn't get used. Hopefully over the next couple of weeks, with the help of others on here, I'll be able to fill out the current rough outline of the design into something well formed that is bounded and can be delivered in the timescale I've allotted to it.

With all of that said, thanks for the feedback, genuinely. For avoidance of doubt, I'm not offended and appreciate you taking the time to make these points. Please continue to pitch in!

Best, sakaki

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5702
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 26, 2019 10:30 pm

Maybe go with the KISS approach and generalize it later if there's interest from the community? I don't have a good feel for how many people would actually want to go further with it.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Feb 26, 2019 11:04 pm

ShiftPlusOne wrote:
Tue Feb 26, 2019 10:30 pm
Maybe go with the KISS approach and generalize it later if there's interest from the community? I don't have a good feel for how many people would actually want to go further with it.
Yes, perhaps so. Well, we're going to be 95% of the way with this once your initial packaging of the demo system is complete. I suppose the main question is, whether we want to be able to support just 1 guest OS at any time, or >1. Once you go >1, there needs to be a way for end users to control that, which (realistically) entails a small management GUI etc. Whether or not a community image server exists is not really critical to that design point, more an imagining of how life-cycle management for guest images could operate in general.

So, sticking with the plan of record for now, perhaps we should try and complete the 'debification' of the demo components by Mar 8, and in the meantime everyone can continue discussion on this thread about a more general design. I'll put out a design doc for a ">1 capable" gui app by Mar 22, we can review that, and I'll put out a bootable image supporting that generalized approach by Apr 26, and host somewhere (not in a fully productionized manner!) a few guest OS images out that can be used with it. Then, users can actually try out a "KISS" (any-colour-you-like-as-long-as-it's-debian) and the new more general approach side by side, and we can take like-for-like soundings. Then, we can then commit to implementing whichever has the stronger feedback as the initial variant.

How does that sound?

Best, sakaki

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Wed Feb 27, 2019 8:03 am

I'm glad you weren't offended as I did worry it sounded a bit harsh!

I think this will interest people who want a modern browser in Raspbian, but I also think there are better ways of achieving that. If the raspbian guys were bothered about this they could solve it right now by packaging firefox/chromium as a snap/flatpak.

Similarly the lack of bluetooth and wifi firmware in upstream is a failing of pi/broadcom. We have to rely on your excellent gentoo instructions to find out how to make them work in other OSs. Once you've found some instructions (this is the hard bit) then it is pretty easy, and I don't think justifies locking into a Raspbian environment. I don't think the pi is any harder to use in linux than a lot of other computers.

Maybe I overestimate the abilities of pi users. I think the people who have a genuine need for 64 bit should have a good technical background.

In truth I've no idea what people use a pi for. They seem to be bought by people with good intentions, but I'm convinced the majority of pi's spend their time at the back of drawer, part of the throw-away culture. If your project stops a pi from landfill then that is a good thing! Good luck!

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5702
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Fri Mar 08, 2019 6:21 pm

sakaki wrote: So, sticking with the plan of record for now, perhaps we should try and complete the 'debification' of the demo components by Mar 8, and in the meantime everyone can continue discussion on this thread about a more general design.
Sorry, going to have to delay it a bit unfortunately.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Fri Mar 08, 2019 9:53 pm

No probs, got a bit of work to do on a follow-up 1.4.1 bugfix release for gentoo-on-rpi3-64bit right now anyhow.

Best, sakaki

ejolson
Posts: 3015
Joined: Tue Mar 18, 2014 11:47 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 09, 2019 3:17 am

feelslikeautumn wrote:
Wed Feb 27, 2019 8:03 am
I think the people who have a genuine need for 64 bit should have a good technical background.
I think most people who have a genuine need for 64 bit are just wanting to surf the web using a reasonably up-to-date web browser.

Having said this, I do like the idea of providing a standard way for ARM Linux to run on the Pi without having to separately configure custom drivers and boot loaders for each distribution. Being able to run a variety of operating systems was guaranteed when Pi was the only SBC around. Moving forward it is plausible that there will be many SBCs on which Linux runs well. To remain relevant most Linux distributions should run well on the Pi.

Heater
Posts: 12603
Joined: Tue Jul 17, 2012 3:02 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 09, 2019 6:47 am

ejolson,
I think most people who have a genuine need for 64 bit are just wanting to surf the web using a reasonably up-to-date web browser.
Then there is me. I want to run a cluster of distributed CockroachDB instances. Cockroach can be hacked to build and run on 32 bit machines but it's a chore and not optimal.
Being able to run a variety of operating systems was guaranteed when Pi was the only SBC around.
Do what? There never was a time when the Pi was the only ARM SBC that could run Linux around. There have been many for many years before the Pi.

Admittedly they tended to be marketed to industrial users rather than hobbyists and "makers" and rather expensive. For years before the Pi my company used the IGEP v2: https://www.isee.biz/products/igep-proc ... pv2-dm3730 at about 250 dollars a pop.

The revolutionary thing the Pi did was to crash the price down, provide a "works out of the box" Linux installation and market to hobbyists with support normal people could understand.
Moving forward it is plausible that there will be many SBCs on which Linux runs well.
Moving backwards, there has been for many years :)
To remain relevant most Linux distributions should run well on the Pi.
For whom to remain relevant?

The Pi does not need thousands of distros. By way of user community support it's better we only have one or a few.

The distros perhaps don't need to support the Pi.

User avatar
Gavinmc42
Posts: 3138
Joined: Wed Aug 28, 2013 3:31 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 09, 2019 7:09 am

With Pi's you have freedom to do anything you want, apart from the secret sauce in start_x.elf everything is pretty open.
People who say 32bit is enough are delusional or have yet to bump into 32bit limitations.
64bit stuff is getting there, the last 6months has been very exciting, with most stuff now possible not improbable.

By the time PIU4 is out most of the 64bit issues will be history.
Some are just impatient and "I want it now". (insert Queen sound track here).
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

Heater
Posts: 12603
Joined: Tue Jul 17, 2012 3:02 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 09, 2019 8:03 am

Gavinmc42,
People who say 32bit is enough are delusional or have yet to bump into 32bit limitations.
Delusional?

A 32 bit processor with a Gig or RAM running at a gigahertz is orders of magnitude more than I need for most of the things my Pi are doing.

Even when developing code on the Pi any 32 bit limitations are far away.

feelslikeautumn
Posts: 307
Joined: Wed Aug 09, 2017 9:51 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 09, 2019 2:05 pm

ejolson wrote:
Sat Mar 09, 2019 3:17 am
feelslikeautumn wrote:
Wed Feb 27, 2019 8:03 am
I think the people who have a genuine need for 64 bit should have a good technical background.
I think most people who have a genuine need for 64 bit are just wanting to surf the web using a reasonably up-to-date web browser.
But you don't need 64 bit for this. Firefox has been working fine under armhf on other distros for nearly a year.
Having said this, I do like the idea of providing a standard way for ARM Linux to run on the Pi without having to separately configure custom drivers and boot loaders for each distribution.
At the start of the year the final piece for working pi wifi was included in linux-firmware. It means that wifi should work out of the box for distros going forward. Bluetooth is still problematic I think.

Distros are trying to standardise bootloaders. Currently u-boot for armhf. Grub2 for arm64. It is raspbian/raspberry pi that is bucking the trend.

ejolson
Posts: 3015
Joined: Tue Mar 18, 2014 11:47 am

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 09, 2019 3:51 pm

feelslikeautumn wrote:
Sat Mar 09, 2019 2:05 pm
Distros are trying to standardise bootloaders. Currently u-boot for armhf. Grub2 for arm64. It is raspbian/raspberry pi that is bucking the trend.
I think this is what I was trying to say. When Pi was the only cheap SBC it set the standard. Currently Raspberry Pi has the market share to define their own standards, but bucking the trend in the future may eventually put Pi in the minority.

One of the reasons people buy Intel compatible PCs is because of the wide availability of software and add-on hardware. The reason for all these options is standard design and popularity. Currently the Pi sets the standards for low-cost ARM SBCs through its popularity. However, two things are happening: Multiple manufacturers of competing low-cost ARM SBCs have entered the market and Linux is starting to run well on those ARM SBCs.

As many know, IBM created the PC standard and then tried to go it alone with OS/2 and the proprietary micro-channel system bus. Even though IBM still had significant market share, this immediately made their product appear incompatible and unpopular.

A similar effect can happen with any single-vendor standard once there is an established multi-vendor standard. If the Pi uses a boot method that is incompatible with many Linux distributions, that could make it appear a minority choice even though it has a majority market share. Therefore, it is important that the Pi continues to boot a diverse selection of operating systems and work with a large variety of add-on hardware. Of course, breaking reverse compatibility across the Pi lineup would make things even worse. This is why the method of easily boot-loading different 64-bit Linux distributions on the Pi proposed above is so interesting and in my opinion necessary.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat Mar 16, 2019 3:12 pm

Hi ShiftPlusOne,

hope all is well with you. I'm just getting back onto this now, given that the gentoo-on-rpi3-64bit 1.4.0/1 is now out and seems reasonably stabilized.

So, I think maybe how we should proceed with this now might be as follows.

To simplify, let's constrain the work to be done for upstreaming into the Raspbian distro to the 'single-image' variant. That will minimize work for you, and keeps things simple. Plus that was what you were originally greenlighted for internally (AIUI), and I don't want to (even unintentionally) be trying to railroad a more general solution, against that specific mandate. Also, having played around with this for a while, I think the 'more general' version looks quite like a GUI for systemd's machinectl anyway, and so might have application beyond just the RPi domain. As such, the simplest thing is probably for me to try to develop that in parallel, and then publish an image with it when done. That will give a more concrete basis for people to comment on (works / doesn't work / too complicated / etc) than publishing a written spec here; this isn't a mailing list, and so it's not really fair of me to expect users to take the time out to review and comment in detail on such a doc. An image that can just be downloaded and played with is a much more realistic proposition.

So, back to the next steps on the 'single image' approach. Reviewing where we are, three debs were originally mentioned:
  1. A 64-bit kernel package. Your bcmrpi3-kernel-bis (source here, debs here) seems to be auto-updating fine and also appears to install OK. This was in many ways the most challenging of the three components to package, and I think we are in good shape here. Many thanks ^-^
  2. The debian-stretch-64 userland image package - what we need here is just a deb that will unpack a single tar.xz tarball to /var/lib/machines. Hopefully not too complex to put together. If we can get something working with the current debian-stretch-64 tarball (available here), then for the production release I'll put together another image that uses buster (since this is on the verge of becoming the stable release). I'll also keep that one minimal (no bundled Firefox web browser etc.) to minimize download time. Cutting over to the buster version from the current stretch one should (hopefully) just involve a simple tweak to the deb.
  3. For the raspbian userland support package, would it help if I supplied an install script, that would work on an unpacked tree from the GitHub source release tarball (e.g. this one), installing say from $SRCDIR (root of the unpacked tarball) to $DESTDIR (temporary or real filesystem install root)? Again there are a few things for the actual release (making some of the "container-is-up?" tests more robust, referencing buster rather than stretch etc.) that would need doing, but these could hopefully then fall mostly on me rather than you (if an install script were to be used).
Does that seem fair to you? In parallel, I'm going to keep working on the more general solution, but we can decouple it from this project to make a 64-bit buster container solution available to RPi3 users in a reasonably constrained timescale.

I'm very aware that you have loads of day-job stuff to do, and you're helping out on this in your spare time, so anything I can do to minimize your work on this, please just let me know!

Best, sakaki

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5702
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Mar 18, 2019 9:44 pm

Hi sakaki, sorry about the late reply.

I have the userland chroot image in the works and it's pretty much exactly as you've described. I had to shelve it for a bit, since I wanted to finish up a few things at work that were taking too long (chromium is a pain).

For the postinst and postrm scripts to handle the edge cases properly, does this sound about right:
On postinst, it should extract the tarball if the target directory does not exist.
On postrm, it should leave the directory in place.
If the user purges the package, it should stop the machine if it's running, then remove it.

Any potential issues with that?
sakaki wrote: For the raspbian userland support package, would it help if I supplied an install script, that would work on an unpacked tree from the GitHub source release tarball (e.g. this one), installing say from $SRCDIR (root of the unpacked tarball) to $DESTDIR (temporary or real filesystem install root)?
Not sure. I haven't looked at that package yet.
sakaki wrote: I'm very aware that you have loads of day-job stuff to do, and you're helping out on this in your spare time, so anything I can do to minimize your work on this, please just let me know!
Thank you for the offer. All in all, I don't think there's much to do on my end, it's just a matter of setting aside half an hour or so to just do it.

I think we're mostly on the same page as to what to do and how it should work, I'm just being a bit slow.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Mar 19, 2019 12:53 pm

ShiftPlusOne wrote:
Mon Mar 18, 2019 9:44 pm
For the postinst and postrm scripts to handle the edge cases properly, does this sound about right:
On postinst, it should extract the tarball if the target directory does not exist.
On postrm, it should leave the directory in place.
If the user purges the package, it should stop the machine if it's running, then remove it.

Any potential issues with that?
That sounds fine I think (if by target directory you mean "/var/lib/machines/debian-stretch-64" - incidentally, you may need to create the parent directory /var/lib/machines also if it does not exist, chmod 0700). A user issuing "purge" would expect to have any user-created content (installed 64-bit apps etc.) deleted I take it, per Debian guidelines?

Best, sakaki

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5702
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Tue Mar 19, 2019 2:41 pm

sakaki wrote: you may need to create the parent directory /var/lib/machines also if it does not exist, chmod 0700)
It seems to be added when systemd-container is installed, but I'll check for that as well, thanks
sakaki wrote: A user issuing "purge" would expect to have any user-created content (installed 64-bit apps etc.) deleted I take it, per Debian guidelines?
Yeah, piuparts (a debian package QC tool, installs the package) notes down all the new files, purges it and then makes sure the system is left exactly as it was before the package is installed, which would mean the user loses all data related to that package.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Apr 01, 2019 1:29 pm

Hi ShiftPlusOne,

just a quick heads-up on this. I have now pretty much finished testing the Debian Buster 64-bit container locally, and it all seems to work pretty much as expected. I assume we should target this rather than Stretch for the production release, as it will soon be the stable variant?

One quick question - on the original Stretch-container-based system, I manually configured time-zone and locale to UK defaults in the container, before shipping. In an attempt to keep pre-configuration to a minimum, however, for the Buster system I did not configure either post-debootstrap. Things seem to work (I assume it is using the C locale, and UTC or whatever), but is this OK? Or should I try to automatically 'reflect' the locale and timezone from the host, much as passwords, groups etc. are?

Best, sakaki

ShiftPlusOne
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5702
Joined: Fri Jul 29, 2011 5:36 pm
Location: The unfashionable end of the western spiral arm of the Galaxy

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Apr 01, 2019 2:33 pm

sakaki wrote: I assume we should target this rather than Stretch for the production release, as it will soon be the stable variant?
We're targetting Buster for almost everything we're doing at pi towers right now and it seems like the release shouldn't be that far off.
sakaki wrote: Things seem to work (I assume it is using the C locale, and UTC or whatever), but is this OK? Or should I try to automatically 'reflect' the locale and timezone from the host, much as passwords, groups etc. are?
I'd go by user feedback. If they run into issues and mirroring solves those issues, then maybe it's worthwhile.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon Apr 15, 2019 5:49 pm

Hello,

I've just released v1.2.0 of the bootable image on GitHub, here.

This now comes with a Debian Buster 64-bit guest pre-installed; uses (courtesy of ShiftPlusOne) a proper Debian package for the kernel; and has a number of host -> guest synchronization improvements (locale, timezone etc. are now automatically reflected).

As before, you can burn the image (~932MiB compressed) to a microSD card (>=8GB), then boot your RPi3 from it directly (the root partition will be automatically resized to fill the card on first boot, per the standard Raspbian flow). Full instructions for download and use are provided on the project's GitHub page.

With this version of the image, it's now really easy to try out 64-bit applications from the Debian Buster repository, while remaining in a familiar 32-bit (userland) Raspbian environment!

For example, say you wanted to try out the 64-bit Chromium web browser. Begin by downloading and booting the image onto a spare microSD card, following the instructions on the project's GitHub page.

After two minutes or so (subsequent boots are much faster), you should be presented with the usual Raspbian first-time setup wizard:
Image

Follow this through as you would for a standard Raspbian startup, making sure to setup networking when prompted, and to reboot when prompted, once the software update step has been completed. (As of version 1.2.0 of the image, any changes you make to timezone or locale using the setup wizard will automatically be reflected into the guest too.)

When your RPi3 comes back up, select System Tools -> Terminal (64-bit), and a container shell terminal should open. There's nothing to configure or set up; it's ready for use immediately!
Image

Issue sudo apt-get update in this 64-bit container shell, followed by sudo apt-get install -y chromium, exactly as you would if using a 32-bit terminal:
Image

Once the install completes, a menu item for your new package will automatically appear in the host desktop:
Image

Just click on that menu item, and your 64-bit Chromium browser will open!
Image

And that's it! Just as with the previous release, applications that you install this way have full access to your home directory, and can play video and audio on the host desktop. You can, of course, still install and use 32-bit apps from the standard Raspbian repository, just as you would before (use a regular, 32-bit terminal window when installing these, of course!)

64-bit integration with less of the headache ^-^

Further details of how all this works under the covers may be found on the project's GitHub page, and in my detailed tutorial, here.

Changes in this Release

Following suggestions from a number of users, this version features the following changes:
  • The kernel is now supplied by a Debian package (courtesy of ShiftPlusOne), so going forward should be updatable via apt-get etc. (the upstream autobuild is here). The particular kernel version shipped on the image is 4.19.34-v8-43958a67195d-bis+.
  • The host image is now based upon the latest (8 April 2019) version of Raspbian Stretch with Desktop.
  • The 64-bit guest image has been updated, from Debian Stretch to Debian Buster (aarch64).
  • Added a (host -> guest) locale reflector. This watches for changes to /etc/default/locale on the guest (via this path unit), and when seen triggers a script to update a matching /etc/default/host-locale file within the guest's filesystem. There, a counterpart path unit, service and script act on any changes (whenever the guest is running), to bring the guest locale in line. If the necessary locale is not present in the guest, it will be compiled automatically (note that locales are never removed from /etc/locale.gen automatically, only added). The counterpart path unit may be disabled in the guest, if locale reflection is not desired.
  • Added a (host -> guest) timezone reflector. Similar in action to the above, this watches for changes to /etc/timezone on the host (via this path unit), and when seen triggers a script to update a matching /etc/host-timezone file within the guest's filesystem. There, a counterpart path unit, service and script act on any changes (whenever the guest is running), to bring the guest time zone in line.
  • Added an init-container service on the host (unit, script) to prepare the guest image prior to its startup. This takes care of installing all context-specific units, scripts etc. into the guest (meaning that other than ensuring the latter has all necessary packages installed - which for avoidance of doubt the version on this image does - no custom prep is required). One of the services enabled by this in the guest is the container-init counterpart (unit, script) which performs some additional setup when the guest image is booted (hostname conformance, etc.).
  • The host userland components are now installed into mainstream locations (/usr/{s,}bin rather than /usr/local/bin etc.) A host image directory is now provided (here).
  • Added an install script for the host userland (here, supports specifying $DESTDIR, and understands preinst, install, postinst, prerm, uninstall / purge, and postrm actions). Hopefully this will simplify packaging.
  • Various script clean-ups.
Although not separately required (as already installed on the main image), a tarball of the Debian Buster guest filesystem may be downloaded here. Its
sha256sum is 3a3c1433caf3a1f89fb624081fdb1799b7ed20376d28c327affc711858204595.

Best,

sakaki

PS: Hi ShiftPlusOne, I think the implementation in this release is close to something that could be upstreamed, given appropriate packaging. Apropos of which:
  • Your bcmrpi3-kernel-bis package, used on this image, seems pretty much good to go.
  • For the guest image package, I believe, based on your previous post, that you have something almost ready to go here too? If so, this simply needs to be pointed at the new Debian Buster image (available here) instead of the Stretch one.
  • For the userland support package, as noted above I've added a simple install script (here) which will hopefully simplify writing the package wrapper. Just download the source tarball for the release, untar and cd into it, then run ./install.sh <command> to do the necessary setup. The script respects the $DESTDIR target (defaults to "/" if not specified). So a typical (unpackaged!) install run might look something like:

    Code: Select all

    [email protected]: ~ $ wget -c https://github.com/sakaki-/raspbian-nspawn-64/archive/v1.2.0.tar.gz
    [email protected]: ~ $ tar -xzpf v1.2.0.tar.gz
    [email protected]: ~ $ cd raspbian-nspawn-64-1.2.0
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh preinst # stops any running services
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh install # installs files to $DESTDIR
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh postinst # enables (but does not start) supplied services
    
    A reboot will then be required to complete the install.

    To upgrade, not sure if Debian tracks existing installed files and does a automatic meld, or if the installer has to sort this out itself? If the latter, then an upgrade would be most simply done as:

    Code: Select all

    [email protected]: ~ $ wget -c https://github.com/sakaki-/raspbian-nspawn-64/archive/v1.2.0.tar.gz
    [email protected]: ~ $ tar -xzpf v1.2.0.tar.gz
    [email protected]: ~ $ cd raspbian-nspawn-64-1.2.0
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh prerm # stops any running services
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh uninstall # remove any files, leaving configs
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh postrm # remove any desktop files etc
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh preinst # stops any running services (redundant actually)
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh install # installs files to $DESTDIR
    [email protected]: raspbian-nspawn-64-1.2.0 $ sudo ./install.sh postinst # enables (but does not start) supplied services
    
    Even if you would rather code the install actions into the deb directly, the script is at least explicit about what needs to be done.

    Any questions, please ask! Again, completely appreciate you are doing this in your spare time so no pressure to get this done ^-^

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Wed Apr 17, 2019 7:11 pm

In addition to direct download from GitHub (here), the v1.2.0 raspbian-nspawn-64 image is now also available for installation via PINN:

Image

(As shown, it is called "nspawn64" there)

Thanks to procount for helping me to get this live!

If you experience any problems, please let me know.

Best, sakaki

User avatar
Botspot
Posts: 126
Joined: Thu Jan 17, 2019 9:47 pm
Location: Texas

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Mon May 13, 2019 12:28 pm

sakaki wrote:
Tue Jan 29, 2019 1:35 am
A 64-bit (aarch64) Debian Stretch userspace guest OS booted inside a lightweight systemd-nspawn container
Could you tell me more about systemd-nspawn containers and what they can and cannot do?
I am looking to run a second instance of Raspbian Stretch Desktop, inside a QEMU-style window, on my main Raspbian operating system.
Right now I am using a Raspberry Pi 3.

I do not want to emulate all the hardware like QEMU does, nor do I want to run the second OS on another Pi and connect to it with VNC. I want something more in between, running locally, but not emulating every one and zero.

So far I have successfully booted a second Raspbian OS to the command line with systemd-nspawn, but it gives sudo errors and cannot start Xorg server.
Most people don't think for themselves much anymore. 
Their brains run single core at a speed similar to a Pi 1. Then they go out and purchase smart devices to help them think. Ridiculous!

Not me, I voided my brain's warranty bit due to overclocking.

User avatar
sakaki
Posts: 214
Joined: Sun Jul 16, 2017 1:11 pm

Re: Easily run 64-bit Debian Stretch packages on a Raspbian system: new RPi3 demo image released (systemd-nspawn, LXDE)

Sat May 18, 2019 12:56 am

Hi Botspot,

firstly, apologies for the delay in responding, I have been travelling.

As to your question, systemd-nspawn lies roughly in the system virualization spectrum between a guest OS chroot, and a full-blown KVM approach. Unlike KVM, when booted under systemd-nspawn the (>=1) guest OS shares a common kernel with the host (which implies, for example, on ARMv8, if you want to run a 64-bit guest, a 64-bit kernel must be used, even if the host OS userland is 32-bit). And unlike a (standard) chroot, under systemd-nspawn the guest OS runs inside its own process namespace, so has its own PID 1 init (and, the host system can 'see' guest processes, but not vice versa). Other Linux container technologies (e.g. network namespacing, control groups for resource control etc) can also be straightforwardly leveraged under systemd-nspawn (they can be used for chroots also, but the management is more fiddly).

However, although a systemd-nspawn guest has its own init (here, by construction, systemd is used), things will generally go badly if the guest tries to directly configure hardware during boot that the host has already set up (for example, the GPU).

For that reason, on the raspbian-nspawn-64 image, the approach I take is to have a vanilla 32-bit Raspbian host OS userspace (run under a 64-bit kernel), within which is booted a 64-bit Buster guest OS which does not contain any initial device-specific setup. However, because of the way the image is set up (read through this thread and the project's README for more details), apps launched within the guest can access the host's X-server (for display) and pulseaudio server (for sound), so the experience (of launching full-scale 64-bit apps from a 32-bit desktop) is fairly seamless. When apps are installed or removed from the guest, appropriate launchers are automatically added into the host's desktop.

For your use case, you could (as you note) run an X11 server in your guest Raspbian OS, rendering to a virtual framebuffer, and then view this via VNC (or similar) on the host desktop (I use a similar approach with KVM here). Another alternative is to run a secondary "X server in a window" on your host desktop, and then use this as the primary X11 server within the guest (I have used xephyr for this in the past, and it works pretty well, see e.g. here). Or, you could copy the approach used in the raspbian-nspawn-64 image, and use the host's X11 server directly for apps launched within the guest.

One tip - if you are planning to share the standard X11 server socket from the host to guest, you need to ensure that network namespacing is turned off; this allows the Unix abstract domain sockets to be used. On the version of systemd-nspawn included with Debian (and hence Raspbian) Stretch, there is a bug preventing /tmp being bind-mounted (which would be the normal approach). This issue is fixed in the Buster release (so there you can use network namespacing; alternatively, if this level of isolation is important to you, you can always use the VNC approach, even under Stretch).

hth, sakaki

Return to “General discussion”