Debian MATE on Raspi4 with dual monitors

abstract: What is missing when using a $100 piece of hardware to replace a desktop PC?

Debian MATE on Raspi4 with dual monitors

The experiments with installation of my environment everywhere with Ansible has demonstrated the advantage of having simple, clean interfaces layered.

My ansible based installation starts with a Debian vanilla installation (produced by debian-installer) on which the rest ist layered on, mostly with apt install. Ansible itself ist using a simple interface on the remote host, name bash and python, which is already produced by d-i; after installation one must assure that ssh works and a key is exchanged with the remote host (ssh-copy-id)

footnote: I have now fixed on using Python3. The switch from python2 to python3 caused some annoying issues but nothing dramatic. The effect is mostly in voiding documentation and many of the useful advice on finds on the web.

My actual limitation was wth the Raspi; the other Single Board Computers (SBC) are all installed initially with Armbian, which is available with recent kernels and Debian images ready to run. The Raspi starts with its own Raspian OS, which is sort of based on Debian. For the Raspi4, running in the 64 bit mode, I used an ubuntu image, which replaces the regular Debian sources with its own - with some small but annoying differences to vanilla Debian. Therefor a quest for Debian MATE on Raspi4.

footnote: ubuntu is trying to install all what could be necessary for the class of users they imagine and all the services they have invented to make life for the same imagined user class more pleasant. I am convinced that only systems which include what is really needed for the real everyday user are lean, effective and easy to understand.


The ubuntu-mate 20.10 image runs a mate desktop on an ubuntu plattform the closes I could come to my target. The debian images for raspi4 start the Debian platform on which MATE can be installed, but are not ready for dual monitors.

The relevant differences are not in the Debian sources and not in the kernel, but in the underpinning, the code which connects the kernel with the hardware. This is the boot process controlled by the boot loader.

Boot loaders come in several species: - Intel BIOS architecture: a multi-stage boot process, with code hidden somewhere in the MBR disk layout. The BIOS is basically a table of entry points for processes to call specific functions which the OS (e.g. the linux kernel) calls. - UEFI (mostly for Intel/AMD hardware); the boot code is in an EFI (orESP) partition, which contains either a BIOS (ACPI) table or a description of the hardware (dt). Programs in systemd (bootctl) allow to start bootable images directly.

question: test - does it use grub? does it work on arm and amd?

footnote: UEFI was an idea of microsoft to close the PC hardware architecture to make it easy for vendors to make it impossible to load operating systems other than Microsoft's on the hardware; The protests of the EU commission and the rest of the industry was immediately strong enough that Microsoft claimed that their goal was only to insure naive users against malicious efforts to make them boot insecure OS - therefore the claim for secure boot. Overtime, the installation of Linux (and other OS) on EFI hardware became possible with the required keys integrated; hardware vendors build systems which can handle (more or less) legacy (BIOS) and modern (UEFI) boot.

In the process, some the limiations of the original PC architecture of the 1970 were given up (e.g. the MBR disk layout was replaced with GPT), slowly taking over, 50 years later replaicing restrictions where hardly anybody remembers the hardware it were introduced for.

footnote: bootctl in systemd is derived from U-Boot (codenamed Gummiboot!).


The Debootstrap software tool allows to graft a new linux on an existing linux running system. Assuming that the ubuntu system the required data to run in 64bit on the ARM with enugh information to manage two monitors (which vanilla debian, started from the d-i images or with UEFI and netbios has not.

The process is in several steps:

Preparation the MATE system:

Copy the ubuntu-mate image on an SSD (formated GPT) with at least 30 GB and start it, which takes a long time to install and set up the system. Set password and allow to expand partition 2 to fill the disk.

Footnote: I assume it works as well with a big enough SD - only SD are much slower and thus more wait time will be asked for.

If you are more familiar with another desktop for which ubuntu 20.10 is available, then try it - I do not see anything which is specific to MATE here.

Get system updated and upgraded with apt -- where unattended upgrades automatically run by ubuntu could get into your way; upgrade notifier may run for half an hour or more, just kill it and then do the apt upgrade which is not yet done... and takes a while, given a lot of installed software in ubuntu MATE.

Partition 1 (label boot,formatted FAT) contains the raspi4 specific code, partition 2 contains the ubuntu-mate system.

Fix the issue with the slow, unresponsive mouse:

`sudo nano /boot/firmware/cmdline.txt`
add at end of line `usbhid.mousepoll=0`. 

I add also, which may be useful.

I would recommand reboot and check that MATE expands on both monitors.


An hour later, used for setting up and upgraded ubuntu; it did add a number of new critical files describing the interface to the Raspi4 hardware.

Install debootstrap with apt install debootstrap.

On a different system, edit the disk layout: Reduce the partition 2 (with ubuntu on it) to 15GB and create a new partion 3 with 15GB; this partition is where the new system will be - I labeled it as deb11.

In this description I use only a single disk, all references will be to sda (dev/sda1 etc.). On this disk are two partitions:

Mount the partition 3 as /mnt (may require mkdir /mnt first and perhaps umount /dev/sda3) # mount /dev/sda3 /mnt

check that /dev/sda1 is mounted at /dev/sda2/boot and /dev/sda1 is mounted as /boot/firmware. For example df -h shows

df -h
Filesystem      Size  Used Avail Use% Mounted on
tmpfs           776M  4,3M  772M   1% /run
/dev/sda2        20G  5,6G   15G  29% /
tmpfs           3,8G     0  3,8G   0% /dev/shm
tmpfs           5,0M  4,0K  5,0M   1% /run/lock
tmpfs           4,0M     0  4,0M   0% /sys/fs/cgroup
/dev/sda1       255M  152M  103M  60% /boot/firmware
tmpfs           776M  124K  776M   1% /run/user/1000
/dev/sda3        33G   24K   31G   1% /mnt

(if not, add # mount /dev/sda1 /boot/firmware). The sda1 contains the setup necessary for linux to run and it is, when linux is started mounted into the /boot directory.

create new system

`debootstrap --arch=arm64 bullseye /mnt`

This loads a new absolutely minimal system of the bullseye release into the sda3 (which is /mnt) based on the debian mirror in Austria.

There may be some messages about missing keys and then the necessary packages are retrieved, configured, unpacked and installed - takes a few minutes (less than 15 minutes).

It says at the end: Base system installed successfully.

Before we can switch ( change root with command chroot), a number of mounts must be prepared so the current environment, the connections to the net etc. is available in the new system.

sudo mount -o bind /dev /mnt/dev
sudo mount -o bind /dev/pts /mnt/dev/pts
sudo mount -t sysfs /sys /mnt/sys
sudo mount -t proc  /proc /mnt/proc

and copied the mounts and the resolver configuration. cp /proc/mounts /mnt/etc/mtab cp /etc/resolv.conf /mnt/etc/resolv.conf

old: Perhaps not needed is: sudo cp -r /boot /mnt/boot The last line gives warning that /boot/firmware and /mnt/boot/firmware are the same file - which is as intended.

It helps to keep the current fstab as a model: cp /etc/fstab /mnt/etc/fstab It will need edits later.


`sudo chroot /mnt

make it usable

add a root password: passwd apt: modify /etc/apt/sources.list which is set from debootstrap and add contrib non-free nano /etc/apt/sources.list deb bullseye main contrib non-free

`apt update`    

software: apt install openssh-server locales consoles-data dbus sudo

requires selection of keyboard (qwerty US standard standard is a good initial choice. can be adapted later)

kernel: apt install linux-image-arm64 braucht as firmware package (which is in debian or should one have a newer version? )

locale to at least (for Austrian German, adapt as necessary) localedef -i en_US -c -f UTF-8 en_US.UTF-8 localedef -i de_AT -c -f UTF-8 de_AT.UTF-8

Add a desktop (or any other usable package); if not already installed apt install tasksel) tasksel select MATE (or whatever desktop you fancy), ssh server.

This runs for a while (20 minutes?)

fstab: edit the copied fstab: change label to LABEL=deb11 (or whatever you selected) which should look like:

LABEL=deb11      /               ext4    defaults,noatime,x-systemd.growfs   0   0
LABEL=system-boot   /boot/firmware  vfat    defaults                            0   1

add users as desired and give them privileges: adduser me adduser me sudo

fix the name of the computer in /etc/host to a new name and fix the time: dpkg-reconfigure tzdata

Exit the chroot environment: exit

change boot instruction

Change in /boot/firmware the root (not in the chroot environment) for the next boot from LABEL=writable to LABEL=deb11

reboot and hope for the best!

The new system should start with the login screen.

df -h shows that / is /dev/sda3 and /dev/sda1 is mounted as /boot/firmware.

If not - debug with google is your friend.

old - to check when next clean start!

The new system starts with kernel 5.8.0-1016-raspi but should start with 5.10.0-3. Obviously some of the upgrades did not end up in the right place.

force with update-initramfs

there are files missing in /boot and there is a large number of dt files newline generated when updating. where do files come for future updates?

open question:

How to get the updates/upgrades for the firmware, which we copied from the existing ubuntu. In the sourceslist of ubuntu was deb groovy main restricted

report: I tried to include the ubuntu provided firmware. once, I perhaps copied what was in /lib (especially lib firmware). and or tried to install with adding ubuntu repositories while in chroot, but did not work for all of the list of possible candidates. but nevertheless the initramfs was rebuild and then the system started with dual monitors.

saved on march 2 on siam as seon - deb11minimal.

Produced with SGG on with master5.dtpl.