Settling on ubuntu

After consulting IT support and opening a ticket it became obvious that getting my hands on a windows installer will not be easy so I decided to give ubuntu a chance on the company SSD. And I did not regret that - everything works flawlessly including native Teams desktop application, the faster than wired gigabit 160 MHz Intel AX200 wifi 6 adapter and the VNC with Remina via autostarting OpenVPN to the test lab I am using. Finally using Windows 10 in a virtual machine is giving me access to an Outlook desktop client via company Global Protect VPN that makes the experience totally complete. I have even upgraded to the newest Edge browser.

Victims of the progress

The installation of my work custom xubuntu eventually failed with qemu on my laptop running RPD. Probably because I could not figure out how to create a VM with more than 2047 MB memory that seems to be an out of box limitation of the qemu package on RPD. With the 64GB SD card and also another 64GB UHS micro SD card the installation did not complete fully and could only boot up to runlevel 3 with upstart option as it kept missing hugepages.

Also, the mini PC freed up from its work VPN duties suffered fatally when I realised that its BIOS only lists bootable USB if formatted to NTFS and tried to change boot image BIOS setting from Windows to Android. After this change, the mini PC did not even load BIOS anymore...

But I did not give up and tried to install my work custom xubuntu burned onto a USB stick plugged into one port on my laptop to another bootable USB stick plugged into another port. After a few cycles I had to realise that I need to remove the SSD drive and use the iso image of my work custom xubuntu in the left side USB port otherwise the installer kept overwriting it. Just to be sure I have used a locked SD card in a USB reader eventually just to be sure. Also, the destination USB stick had to be ext4 formatted with GParted as in the case I created just a boot partition with fdisk it complained about missing root file system mounting point. Even in the case when the USB stricks have been plugged in the right order the installer stumbled a bit creating the necessary partitions but allowed an option that eventually made progress through the partitioning successfully.

Applying all of it to work

Work has always been one of the most important reason to start this journey and now it is showing some return as I applied my recent learning on kvm to install some components of the SW I am working with on an SD card. I had an empty 16GB SD card and the custom ubuntu from my work system happily installed on it. I have even found a nice GUI called aqemu with which I could send ctl-alt-f1 to switch to tty1 and start deployment by sending commands via the clipboard copied from the bring-up guide. I got stuck when the 10GB bulk release had to be pulled in that clearly did not fit into the qcow2 image due to the overall 16GB size of the SD card where it resides. So I freed up the 64GB SDXC card from my video camera by shoveling its entire content on my Synology. I have also realised after some unsuccessful struggle to install 32 bit Windows desktop client of Global Protect company VPN with wine that openconnect support Global Protect protocol perfectly for my company VPN so I can ditch the remote desktop to the Windows Mini PC I used so far to get access to the bring-up guide. This also opens the possibility to explore the option to install the other custom ubuntu image on the Mini PC and learn more about the networking aspect of the virtualised world. While this Mini PC only has an Atom processor but that has two cores with 2 threads on each and have hardware support for VT-x virtualization so have some hope that the company SW can be installed on it. More about it later.

[UPDATED] Second try with Ubuntu

My first try with Ubuntu failed as its live USB ISO did not contain a persistent option. As I learned about qemu more recently the idea has given itself to apply it to give a second try with Ubuntu. While I do not really have enough disk space on my nice&neat little Sandisk Cruzer Fit only 32GB I still thought I give it a try. Moving ISO files across was painful. While using bitorrent on Synology did help to get the image in the house when I downloaded it to the Sandisk it was painfully slow. Nevermind it was high time to get my next gadget from amazon anyway so a 128GB SSD in nice&neat little USB 3.0 form factor is on its way now supporting over 200MB/s transfer rate.

But back to the Ubuntu try: I found this article https://linuxhint.com/install_qemu_debian/ that focused on hardware acceleration so I thought I follow this one but with Ubuntu instead of Alpine. It turned out that the maximum memory that can be used is 2GB and the minimum disk space needed is 9GB so I used these parameters and started to install the 20.04 LTS with minimum configuration but it kept halting. Maybe I better wait for the new USB key with this...

[UPDATE]
As it did not install even overnight I checked again what is behind 200MB/s headline number and found a lot of misery with write speed in the reviews so I cancelled the new card and thought about a new strategy of using a separated SD card in the SD card slot in my laptop to install Ubuntu on it. This went reasonably fast so the next step on getting familiar with Ubuntu has been accomplished.

[FIXED] Burn-n-boot pihole

I think I found the ultimate solution for making my own custom burn-n-boot Raspbian image with fully fledged pihole running on it.

Wrote Raspbian Lite with Imager this time on the SD card. Then installed qemu-system-arm on my live USB Debian and downloaded ready made kernel image and compiled device tree file from https://github.com/dhruvvyas90/qemu-rpi-kernel that can emulate my Raspberry Pi 1. Quick fdisk -l to find out disk name this time is /dev/sda and this single command has booted an entire virtual machine from the SD card:

sudo qemu-system-arm -M versatilepb -cpu arm1176 -m 256 -hda /dev/sda -dtb ~/Downloads/versatile-pb-buster.dtb -kernel ~/Downloads/kernel-qemu-4.19.50-buster -append 'root=/dev/sda2 panic=1' -no-reboot &

We can jump right into installing pihole:

sudo curl -sSL https://install.pi-hole.net | bash

Could configure the final static IP address and default gateway also as it will only be applied after reboot so could still pull static DHCP config file from host:

sudo scp jordana@10.0.2.2:04-pihole-static-dhcp.conf /etc/dnsmasq.d

After minimal password management shutdown the virtual machine:

passwd
pihole -a -p
sudo shutdown -h now

Dropped a new file named ssh into boot disk from File Manager before ejected it and that is it. Swapped in the new card into RPI and the family did not notice the change. Finished by expanding the file-system with raspi-config, apt update/upgrade and enabling DHCP from web interface and confirmed it is all running OK.

Burn-n-boot pihole

This post https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=231762 has made me thinking if I could burn-n-boot pihole onto a spare SD card and swap it in my RPI without the family noticing it. Since the lockdown the entire family is constantly hooked on the net so pihole has become a critical component of the peace at home.

The process was successful but not flawless. Here is my workflow with findings:
First I booted Debian with Raspberry Pi Desktop on my ThinkPad from persistent live USB.
Then started the workflow with writing newest Raspbian on an SD card with Imager.
sudo fdisk -l
gave me that the SD card is disk /dev/sda
sudo mkdir /mnt/raspbian
sudo mount /dev/sda2 /mnt/raspbian
sudo mount /dev/sda1 /mnt/raspbian/boot
sudo systemd-nspawn -D /mnt/raspbian
and here I arrived at the first hiccup:

ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded (cannot open shared object file): ignored.

I could get rid of this ERROR by commenting the only line in /etc/ld.so.preload that contained the shared object file that cannot open.
apt update
apt -y upgrade
there was some hiccup:
System has not been booted with systemd as init system (PID 1). Can't operate
invoke-rc.d: could not determine current runlevel
Warning: using insecure memory!
but the upgrade eventually finished.
curl -sSL https://install.pi-hole.net | bash
Here I arrived some more hiccups

[✗] Checking apt-get for upgraded packages
Kernel update detected. If the install fails, please reboot and try again
SELinux not detected
Unsupported setsockopt level=270 optname=11
Unknown host QEMU_IFLA type: 50
Unknown host QEMU_IFLA type: 51
Unknown host RTA type: 25

when I tried to set-up static IP I got kicked out with:

RTNETLINK answers: Operation not permitted

but I could see the changed static IP in /etc/dhcpcd.conf

interface eth0
        static ip_address=192.168.1.3/24
        static routers=192.168.1.1
        static domain_name_servers=8.8.8.8 8.8.4.4

so when run pihole install script again it did accept the static IP settings because:

Static IP already configured

then some more checks failed:

[✗] Check for existing repository in /etc/.pihole
[✗] Check for existing repository in /var/www/html/admin

but ultimately the install finished.
Removed webserver password and copied over dhcp config from running server:
pihole -a -p
scp jordana@192.168.1.3:/etc/dnsmasq.d/02-pihole-dhcp.conf /etc/dnsmasq.d 
scp jordana@192.168.1.3:/etc/dnsmasq.d/04-pihole-static-dhcp.conf /etc/dnsmasq.d
then finished with some user management and enabled ssh:
groups pi
useradd -m -G <all-pi-groups-comma-separated> jordana
passwd pi
passwd jordana
touch /boot/ssh
exit
finally umount and ejected the SD card
sudo umount /mnt/raspbian/boot
sudo umount /mnt/raspbian
Popping the SD card into my RPI booted nicely and I could ssh with configured user but pihole was not running.
Not sure what is wrong but only repair seemed to fix it.
pihole -r
While the repair process was reasonably fast so I only got angry looks for a minute or two I am wondering how could this workflow be improved so that pihole would just start after burn-n-boot without repair?

Using SSH keys and setting jordana with NOPASSWD for sudo

Last week got hooked on the advert appeared in Teams within a Chromium tab to install a native Debian desktop app for Teams. It was very appealing to combine the two so distant world of open source and proprietary. But the install was far from flawless - .deb installer did not install by simple doubleclick and from command line apt was really had to be forced. While Teams did work for a while the next real apt update got broken by the applied force during Teams install.

The easiest way to fix for me was to reset persistence in the Debian boot menu.

Using lxrandr and xbacklight/xbindkeys to reinstate my user environment was already just a finger exercise but installing openvpn from Preferences -> Add / Remove Software did not bring up the tunnel during boot even after placing config file in /etc/openvpn. Starting it manually was also further hindered as jordana user needed password for sudo so process got stopped if first invoke was trying to send it the background.

Amongst so many very interesting things the solution for setting jordana with NOPASSWD for sudo was in this article:

https://opensource.com/article/20/5/disk-image-raspberry-pi

I have noticed that user pi already has NOPASSWD configured for sudo in /etc/sudoers.d/ so I simply copied its altered config file over for jordana user which made openvpn started flawless in the background.

This article made me also think to generate ssh keys for the connections I frequently use like the Raspberry Pi I update daily and the jumpserver for the company test lab I frequently use. This was a piece of cake with ssh-keygen and ssh-copy-id.