Skip to content

Release v1.4.8

Latest
Latest
Compare
Choose a tag to compare
@sakaki- sakaki- released this 25 Feb 12:18
· 11 commits to master since this release
v1.4.8
8b98194

31 Oct 2020: sadly, due to legal obligations arising from a recent change in my 'real world' job, I must announce I am standing down as maintainer of this project with immediate effect. For the meantime, I will leave the repo up (for historical interest, and since the Debian package is still in the official Raspbian repos); however, there will be no further updates to the underlying OS images etc., nor will I be accepting / actioning further pull requests or bug reports from this point. Email requests for support will also have to be politely declined, so, please treat this as an effective EOL notice.

For further details, please see my post here.

With sincere apologies, sakaki ><

Thanks to ShiftPlusOne, as of 2 March 2020 raspbian-nspawn-64 can be installed from the official Raspbian repo, just like any other regular package, using apt - so no need for a custom bootable image! For more details, please see this post, but to install, simply issue:

pi@raspberrypi:~ $ sudo apt-get update && sudo apt-get install -y raspbian-nspawn-64

As such, this v1.4.8 image is essentially just the 2020-02-13 with-desktop Buster release of Raspbian (available here), into which this raspbian-nspawn-64 package has been pre-installed, via the techniques shown in this post, and on which the official 64-bit kernel has been activated (by setting arm_64bit=1 in /boot/config.txt). The rootfs has also been expanded slightly from the original (to 5GiB), but otherwise, the system is in a 'factory fresh' state (so e.g. the root partition will still autoexpand, the piwiz setup wizard will still run on first boot, etc.). It is provided (given a deb now exists) as a convenience only.

Changes in this release (wrt v1.3.0):

  • Menu commands like System Tools→Run 64-bit Program... will now display an error dialog if attempted while running under a 32-bit kernel (they used to just fail silently).

  • CLI-commands (ds64-runner etc.) will not use zenity to display dialog boxes if this package is not installed (or the GUI isn't running), falling back to console output in this case.

  • The underlying 64-bit Debian Buster image deb (debian-buster-64) has been updated to a version debootstrapped on 19 Feb 2020.

  • Package metadata retained in the debian-buster-64 image this time (since a very common issue has been people not remembering to sudo apt-get update in the 64-bit shell, before trying to install new packages there — this way, while you may still need to update if it has become stale wrt certain packages, at least there's a helpful prompt to tell you that).

  • Added a mechanism to automatically bind mount 'shadow' copies of top-level dot-files and dot-directories for regular users, where an appropriate 'doppelganger' is provided. Specifically, for any (normal) file or directory ~/.foo, if a 'shadow' ~/.foo-debian-buster-64 is present, this will be automatically be bind mounted over the original inside the container only. No graphical editor for this is currently provided; however, it does allow for easy solution of the following (e.g.):

    • To work around the issue where e.g. chromium has different format ~/.config/... entries in the 32-bit host and 64-bit container, create the directory ~/.config-debian-buster-64 - this will then be used as ~/.config within the 64-bit container context only. (NB - the automatic bind mounts only happen at container startup, so you may need to reboot your system, or use System Tools→Stop 64-bit Container followed by System Tools→Start 64-bit Container to have your change 'take'.)

    • To have a separate 32-bit and 64-bit bash history, create the file ~/.bash_history-debian-buster-64 - this will then be used as ~/.bash_history within the 64-bit container context only. (Again, changes are applied at container startup.)

Known Issues

Chromium v79 and v80

There are a number of regressions affecting 64-bit chromium v79 and v80 when run in a container (or when using a remote X server); these can make the browser window appear with all content 'whited out'. For details, please see e.g. chromium bug 1048186 and bug 1035803.

However, for chromium v79 at least (the current Debian Buster aarch64 version at the time of writing) you can install a working version of the browser via the following small workaround.

First, open a container shell, and if you haven't already, install 64-bit chromium:

pi@raspberrypi:~ $ ds64-shell
pi@debian-buster-64:~ $ sudo apt-get update
pi@debian-buster-64:~ $ sudo apt-get install -y chromium

Once complete, ensure (per the above bug reports) that the --ignore-gpu-blacklist option will always be given at browser startup. Issue:

pi@debian-buster-64:~ $ sudo nano -w /etc/chromium.d/ignore-gpu-blacklist

and place in that file:

# Workaround rendering failure on RPi, see bug #1048186 and bug #1035803
export CHROMIUM_FLAGS="$CHROMIUM_FLAGS --ignore-gpu-blacklist"

Save, and exit nano. You should now find the browser starts up correctly!

NB, to avoid conflict with the 32-bit chromium on the host desktop, you may also wish to set up a 'shadow' ~/.config directory, as described above (although this is not mandatory).

Assets 4
Loading