The emmc is detachable, sitting on the slot.
I’ve previously tried dietpi on SD but the bootloader didn’t like it much. Got the emmc-module in the mail earlier in the week, that’s why i decided to try dietpi again.
It is capable to boot from emmc successfully with other distros, i mentioned armbian previously.
I’m eagerly waiting for a fully working dietpi 
Ah right, having a closer I see it now. The PCB of the eMMC module looks so similar to the underlying base board PCB part, with the white lines and borders matching very well 
.
I didn’t try it with an eMMC yet, to be true, with SD card only. Will do that. However, if it has issues booting from SD card as well in your case, there seem to be a general issue with our current kernel/bootloader and your board revision. In both cases is stops somewhere when the kernel is loading already?
Can you try to adjust the CPU scheduler in /boot/dietpi.txt and set it to ondemand or powersafe? On old boards with old kernel, there were cases where schedutil caused instabilities, and this is a difference of our images compared to Armbian (they ship with ondemand by default).
We have a new set of Quartz64 images with unmodified mainline kernel and U-Boot moved/rebased onto a stable mainline branch as well: Index of /downloads/images/testing
This solved some strange issue on Quartz64 model A, where resizing the filesystem lead to a superblock corruption error and read-only remount, while actually nothing got corrupted, and simply rebooting the system leads to a clean functional system (fsck -f-proven). I guess it was some bug in early Linux v6.1-rc1. Probably it solves your @microboars boot issues as well on SOQuartz.
A bunch of expected kernel features added, some strange legacy/faulty features removed, some converted from builtin to modules. I’m actually surprised how well this all works without any kernel patches 
.
Please test and give feedback. I’m sure there is a lot more to enhance about the kernel config, as this is newland to me.
Hi Michalng, I’m a new user of dietpi and I’m trying to get k3s running on soquartz. Your testing image mentioned in this post seems to almost get me there, but, k3s wants CONFIG_CFS_BANDWIDTH available in the kernel so that there’s a cpu.max cgroup value (source in podman issue thread here) Is there any way you can add that in? I’d compile the kernel myself but I’m using a turing pi 2 board and don’t have local console access to figure out why my compiled image is failing to boot.
State: Waiting
Reason: CrashLoopBackOff
Last State: Terminated
Reason: StartError
Message: failed to create containerd task: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: openat2 /sys/fs/cgroup/kubepods.slice/kubepods-besteffort.slice/kubepods-besteffort-podb7fb3e02_a33b_4203_97d4_f310a10862bc.slice/cri-containerd-45c3fc8d4cebae4d08befdeb44cc025a0cb4c4d8cb3aac08cc2b997c85d94dae.scope/cpu.max: no such file or directory: unknown
Exit Code: 128
Sure: v8.15 · MichaIng/DietPi@05be48b · GitHub
New kernel builds are running, afterwards I’ll create new images with them: quartz64 · MichaIng/DietPi@9a25214 · GitHub
Success! With the following steps, soquartz+turing pi 2 works for k3s:
apt-get -y install vim iptablesupdate-alternatives --config iptables and set the alternative to iptables-legacy
update-alternatives --config ip6tables and set the alternative to ip6tables-legacy
vim /etc/hostname
One more request, if you’d help @MichaIng , can you please also enable the modules for iscsi? 
I use iscsi storage in k3s and can’t use the open-iscsi tools to mount without iscsi enabled in the kernel.
Thanks a bunch! I’ll be subscribing to the patreon shortly!
Will do.
Why didn’t you use the K3s install option in dietpi-software? It would have done all that for you. apparmor was not required in your case? I remember it was when we implemented it, and we install it hence as dependency as well. But it might have just suffered from a similar false detection of whether AppArmor is used which Docker suffers from currently: DietPi-Software | Docker: Service fails to start after upgrade (AppArmor) · Issue #6126 · MichaIng/DietPi · GitHub
To be honest, I didn’t realize it was a software option until after I had done it the manual way, and so I just kept doing the manual install method on a bare image. Since I’ll have to rebuild these nodes when you have the iscsi module anyway, I’ll try using the dietpi-software route instead.
Its probably because k3s uses containerd instead of docker.
And containerd had this bug already for a long time, fixed just recently after it appeared in Docker. I’ll retest, probably we can remove the apparmor dependency then.
EDIT: Nope, still needed:
CreateContainerError: "failed to create containerd container: get apparmor_parser version: apparmor_parser resolves to executable in current directory (./apparmor_parser)"
Weird:
root@tpi1n4:~# dpkg --list | grep apparmor
ii libapparmor1:arm64 2.13.6-10 arm64 changehat AppArmor library
root@tpi1n4:~#
images running:
root@tpi1n4:/usr/local/bin# ctr c ls
CONTAINER IMAGE RUNTIME
028cc3fad95f40605815433fc9059633b45f32f53dbdd26dddfcc04b40a50400 docker.io/rancher/mirrored-pause:3.6 io.containerd.runc.v2
470a4b1d46b990f3663cb989ce85611513d01e48cfead323c04a4f3bea8f0aab docker.io/rancher/mirrored-pause:3.6 io.containerd.runc.v2
48ffd5f15fea06e094ae8c5c6cd6dacf4e01be81ec981dab73680ac4dd93b8f2 docker.io/rancher/mirrored-pause:3.6 io.containerd.runc.v2
4e6fb72a870c91bfd32dfa1253db61172a33a07670228e0c953408e5c73fbc2a quay.io/prometheus/node-exporter:v1.5.0 io.containerd.runc.v2
5e2ac4822a7747bb901f3594d6ea8aa5f67d8119ea03cead87dd8e34f993af7e docker.io/timberio/vector:0.27.1-distroless-libc io.containerd.runc.v2
62242ce8452f1ca2e7d0901d153db73b64dea5097fa873334269e0321414820d k8s.gcr.io/ingress-nginx/controller@sha256:545cff00370f28363dad31e3b59a94ba377854d3a11f18988f5f9e56841ef9ef io.containerd.runc.v2
8a2a1212a55070ef684d42c9fe79e1c29c039ad4a6f8e2dba2b82271eac604e6 docker.io/rancher/mirrored-pause:3.6 io.containerd.runc.v2
8d9ce26f883004562e76b2a8e5b3de82bd23e018c83aea8495d13c81b225d538 k8s.gcr.io/sig-storage/csi-node-driver-registrar:v2.3.0 io.containerd.runc.v2
9919f7c6d767d9cc6310080ef5ad501cc919f08565c8c76476026e8c628a2d00 docker.io/rancher/mirrored-pause:3.6 io.containerd.runc.v2
d838cd5c19a67b3df9a82dfa046985baba90bc8daa7b4efa1741981d67850c24 docker.io/synology/synology-csi:v1.1.1 io.containerd.runc.v2
fe2f073b59096efabb8661601f28225e892539be9804f918059ee79e07309ba4 quay.io/metallb/speaker:v0.12.1 io.containerd.runc.v2
The bug only kicks in if the kernel has AppArmor support and apparmor=1 set by default (or it was set manually), but then no userland tools are installed. This is the case with our x86_64 images, since the Debian kernel has AppArmor enabled OOTB this way. Adding apparmor=0 to cmdline solves it as well in this case. However, this is not Linux default, hence most other kernels/images are not affected.
The bug is even separately reported on K3s GitHub: Upgrade to v0.21.0-k3s1r0, get CreateContainerError on all pods · Issue #702 · rancher/k3os · GitHub
I just recognised we missed to do legacy iptables configuration (if required, i.e. if nftables is not supported by kernel). Added now for next release: https://github.com/MichaIng/DietPi/commit/738c9a9
Btw, using iptables-legacy really is required? I thought I added full support for it: DietPi/quartz64_defconfig at 738c9a991a71d4336fabf9c21916aef8a779b96e · MichaIng/DietPi · GitHub
When watching journalctl -fu k3s-agent output, the log was spammed with error messages saying that iptables (nftables) was unable to load comment and conntrack matches, even if the kerrnel modules were enabled.
Hmm, probably something else is missing then, since support for those two matches is enabled explicitly 
. We might need someone with more kernel config experience then.
About iSCSI, so we need sysfs entries for attached devices? iSCSI Transport Attributes - CONFIG_SCSI_ISCSI_ATTRS - scsi_transport_iscsi.ko - kernelconfig.io
I.e. device entries below /sys/ for iSCSI device to get information about them.
Same for iSCSI “boot information”: iSCSI Boot Sysfs Interface - CONFIG_ISCSI_BOOT_SYSFS - iscsi_boot_sysfs.ko - kernelconfig.io
But I don’t know what this is about 
.
I am assuming you need CONFIG_SCSI_ISCSI_ATTRS because of the breadcrumbs in this bugzilla for redhat: 1768635 – iscsid: can not create NETLINK_ISCSI socket
root@tpi1n3:~# systemctl start iscsid
root@tpi1n3:~# journalctl -fu iscsid
-- Journal begins at Sun 2023-02-26 16:23:20 GMT. --
Feb 26 16:23:58 tpi1n3 iscsid[983]: can not create NETLINK_ISCSI socket [Protocol not supported]
Feb 26 16:23:58 tpi1n3 systemd[1]: iscsid.service: Main process exited, code=exited, status=1/FAILURE
Feb 26 16:23:58 tpi1n3 systemd[1]: iscsid.service: Failed with result 'exit-code'.
Feb 26 18:58:52 tpi1n3 systemd[1]: Starting iSCSI initiator daemon (iscsid)...
Feb 26 18:58:52 tpi1n3 iscsid[8159]: iSCSI logger with pid=8160 started!
Feb 26 18:58:52 tpi1n3 systemd[1]: Started iSCSI initiator daemon (iscsid).
Feb 26 18:58:52 tpi1n3 iscsid[8160]: iSCSI daemon with pid=8161 started!
Feb 26 18:58:52 tpi1n3 iscsid[8160]: can not create NETLINK_ISCSI socket [Protocol not supported]
Feb 26 18:58:52 tpi1n3 systemd[1]: iscsid.service: Main process exited, code=exited, status=1/FAILURE
Feb 26 18:58:52 tpi1n3 systemd[1]: iscsid.service: Failed with result 'exit-code'.
Let’s try without it first. New builds are running.
Kernel package ready for upgrade:
cd /tmp
curl -sSfO 'https://dietpi.com/downloads/binaries/firmware-soquartz.deb'
dpkg -i firmware-soquartz.deb
rm firmware-soquartz.deb
I… didn’t realize I could upgrade to the new version without reflashing, that’s good to know!
the reason I cannot use the k3s install from dietpi today is that it defaults to installing the server, without asking me if I want to be an agent (compute node) instead of a server (master node) – I’m using these soquartz as extra compute capacity so they are connecting into my existing k3s environment.
your changes in this latest firmare allow openiscsi to fire up!
Thanks 
EDIT: I just tried a fresh flash of the latest image, and attempted to start k3s in agent mode without updating alternatives to iptables-legacy. The iptables provided by nf_tables did not work. I had to update the alternative to iptables-legacy.
Perfect 
.
Good point. It should be possible to do this via SOFTWARE_K3S_EXEC setting in /boot/dietpi.txt, which sets the INSTALL_K3S_EXEC environment variable, to set default executable arguments. Also the default config can be pre-created via /boot/dietpi-k3s.yaml, copied to /etc/rancher/k3s/config.yaml on install.
But probably we should offer to interactively do this fundamental choice. K3S_URL and K3S_TOKEN would need to be set, right?
Correct, those are the two arguments that cause the k3s install script to use agent mode.