User avatar
Botspot
Posts: 125
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 20, 2019 8:06 pm

sakaki wrote:
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
Hi Sakaki,

Thank you for all the insight on how I could get this to work. I hope to be able to plug a SD card into the USB-to-SD adapter on my pi, do some action (run a command, click a shortcut,...), and then run the desktop environment that is on the external SD card, in a window inside the native desktop environment that my host raspberry pi is running.

I first tried using xephyr. To open the second X server within the main X server I ran this command: does that look right?

Code: Select all

Xephyr -ac -screen 1280x1024 -br -reset -terminate 2> /dev/null :1 &
Then I inserted a Raspbian-formatted SD card into my USB-to-SD slot, and it automatically mounted the root partition to /media/pi/rootfs on the host.
But if I understand correctly, by default, the auto-mount does not allow any elevated privelages, and if I attempt to run a program on it as superuser, it returns the error: 

Code: Select all

sudo: effective uid is not 0, is /usr/bin/sudo on a file system with the 'nosuid' option set or an NFS file system without root privileges?
So I remount it to allow superuser.

Code: Select all

sudo mount -n -o remount,suid /media/pi/rootfs
Now I can 'boot' up the root partition with systemd-nspawn.

Code: Select all

sudo systemd-nspawn -bD /media/pi/rootfs --bind /dev/tty2 --bind /lib/modules
The terminal returns a colorful text-based output similar to what it looks like when I boot up Raspbian when splash screen is disabled.
Image
I notice all hardware-dependant processes fail. As you mentioned,
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)
So I will assume such failures are desirable.
Pretty soon the boot process is finished and I am offered a login prompt. After logging in, I will try to connect to xephyr (running on the host DE) with Xorg.

Code: Select all

export DISPLAY=:1
​​​​​​​startx
Startx did not work as expected. Nothing appeared in the xephyr window, instead startx gave error(s).

Code: Select all

_XSERVTransSocketUNIXCreateListener: ...SocketCreateListener() failed
_XSERVTransMakeAllCOTSServerListeners: server already running
(EE) 
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) 
(EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
(EE) Please also check the log file at "/home/pi/.local/share/xorg/Xorg.0.log" for additional information.
(EE) 
(EE) Server terminated with error (1). Closing log file.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 7 requests (7 known processed) with 0 events remaining.
Couldn't get a file descriptor referring to the console
It looks like startx can detect Xorg is already running, but how? And secondly, where it says "Resource temporarily unavailable on X server :0", why is it trying to connect to screen :0 when I set the default screen to :1?

I moved on and tried the VNC method.

Code: Select all

vncserver
Because I had mounted the root partition with the suid flag, vncserver started with no error. (before using mounting with suid, vncserver did not work)
The command output included a VNC address I could connect to. Back to the host DE, I started VNC Viewer and typed in the address, which in my case was 192.168.0.10:2.
A VNC browser window opened, and right there was the full DE of default Raspbian Stretch within the window! Perfect, exactly what I want. In fact, it runs it runs at 100% native speed! (compare that to QEMU)
Image

First thing I notice is that VNC's screen refresh is slow. Not a big deal, but somewhat bothersome if I play a video.
Second, how would I go about forwarding the sound to the host's sound devices?
Last edited by Botspot on Tue May 21, 2019 6:23 pm, edited 1 time in total.
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)

Tue May 21, 2019 2:29 pm

Botspot wrote:
Mon May 20, 2019 8:06 pm
Pretty soon the boot process is finished and I am offered a login prompt. After logging in, I will try to connect to xephyr (running on the host DE) with Xorg.

Code: Select all

export DISPLAY=:1
​​​​​​​startx
Startx did not work as expected. Nothing appeared in the xephyr window, instead startx gave error(s).

Code: Select all

...
(EE) 
Fatal server error:
(EE) Cannot establish any listening sockets - Make sure an X server isn't already running(EE) 
(EE) 
...
(EE) Server terminated with error (1). Closing log file.
XIO:  fatal IO error 11 (Resource temporarily unavailable) on X server ":0"
      after 7 requests (7 known processed) with 0 events remaining.
Couldn't get a file descriptor referring to the console
It looks like startx can detect Xorg is already running, but how? And secondly, where it says "Resource temporarily unavailable on X server :0", why is it trying to connect to screen :0 when I set the default screen to :1?
Running startx will attempt to start another X server in your guest. You need to use e.g.

Code: Select all

DISPLAY=:1 lxsession
(There are various ways to do this) The host xservers (on :0 and the xephyr one on :1) will be "visible" in the guest because, when you invoke systemd-nspawn directly as you do here (iirc), network namespacing is not activated, so the UNIX abstract domain sockets for the server on the host are visible on the guest too. When you run startx, it (by default) tries to run a new server on :0, but there already is one running (the host's desktop). See e.g. these notes for further discussion.
Botspot wrote:
Mon May 20, 2019 8:06 pm
Second, how would I go about forwarding the sound to the host's sound devices?
The approach I take is to ensure the host (and guest) OS has pulseaudio installed and running, bind mount /run/user to /run/host-user (in the guest) , and then export PULSE_SERVER="unix:/run/host-user/${UID}/pulse/native". See e.g. here and here. The UIDs on host and guest need to match - this will be fine for the "pi" user but will get interesting once you start independently creating users ^-^ The raspbian-nspawn-64 image has a (path-unit-triggered) script that keeps guest UIDs (and various other things) forcibly synced between host and guest; probably overkill for your use case.

hth, sakaki

SuburbanDad
Posts: 1
Joined: Mon May 27, 2019 4:14 am

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

Tue May 28, 2019 5:45 pm

sakaki wrote:
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).
...
@sakai Thanks for this. I needed a 64 bit userland for a go project and finally found this after fumbling around with Ubuntu and other arm64 options for the pi. Literally nothing out there is as lean as raspbian and in the absence of a native 64 bit option, this is by far the best option. I am getting a graphical environment and a 64 bit shell open with ~100mb resident mem usage. Fantastic work.

User avatar
Gavinmc42
Posts: 3136
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)

Tue May 28, 2019 11:37 pm

Literally nothing out there is as lean as raspbian and in the absence of a native 64 bit option, this is by far the best option. I am getting a graphical environment and a 64 bit shell open with ~100mb resident mem usage. Fantastic work.
Had not thought of Go on this version.
I have been having fun with AJ Starks OpenVG Go stuff on Raspbian and Ultibo.
I expect it to break in 64bit mode.

Go and Rust both work in Sakaki's pure 64bit Gentoo64.
Eric Anholt's OpenGL works in that, so OpenVG and OpenGLES should too?
I'm dancing on Rainbows.
Raspberries are not Apples or Oranges

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)

Thu May 30, 2019 7:37 pm

SuburbanDad wrote:
Tue May 28, 2019 5:45 pm
@sakai Thanks for this. I needed a 64 bit userland for a go project and finally found this after fumbling around with Ubuntu and other arm64 options for the pi. Literally nothing out there is as lean as raspbian and in the absence of a native 64 bit option, this is by far the best option. I am getting a graphical environment and a 64 bit shell open with ~100mb resident mem usage. Fantastic work.
Thanks for the feedback, happy to hear you found it useful ^-^

Actually, your comment about the lack of 64-bit support in the official repos reminds me that a plan was afoot some time back to package and upstream this stuff.

@ShiftPlusOne - I'm going to have a bit of bandwidth coming free in around a week or so's time, so would be very happy to do anything I can to assist you in the completion of remaining packaging. The current Buster-based guest seems reasonably stable, and (as mentioned here, bottom of the post) an install script has been added to (hopefully) simplify the guest userland package part.

Alternatively, if you're snowed please just let me know (either here or directly at sakaki@deciban.com), and I'll hit the mute button ^-^

Thanks! S.

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)

Thu May 30, 2019 8:46 pm

Email incoming

jchidley
Posts: 1
Joined: Sun Jun 23, 2019 6:49 am

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

Sun Jun 23, 2019 6:59 am

sakaki wrote:
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 sakaki@deciban.com.

Best,

sakaki
I have 2 use cases for this:
1. I want to run Arch Linux - Aarch64 - but keep Raspbian because almost all examples, snippets, etc for Pi hardware use Raspbian.
2. I want to compile programs for other ARM boards (e.g. Nordic Semiconductor’s nRF52840 BLE ANT+ etc) and the official ARM GCC for it is only supported for 64bit Linux.

Jack

Return to “General discussion”