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:
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
fsck.repair=yes, 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
dev/sda1 etc.). On this disk are two partitions:
Mount the partition 3 as /mnt (may require
mkdir /mnt first and perhaps
# 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
`debootstrap --arch=arm64 bullseye /mnt http://ftp.at.debian.org/debian`
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
add a root password:
passwd apt: modify /etc/apt/sources.list which is set from debootstrap and add contrib non-free
deb http://deb.debian.org/debian bullseye main contrib non-free
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)
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 sudo
fix the name of the computer in /etc/host to a new name and fix the time:
Exit the chroot environment: exit
Change in /boot/firmware the root (not in the chroot environment) for the next boot from
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?
How to get the updates/upgrades for the firmware, which we copied from the existing ubuntu. In the sourceslist of ubuntu was deb http://ports.ubuntu.com/ubuntu-ports/ 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.