I will soon be in the situation of having an offsite Helios4 installation at my non-techie father's place on another continent. I want to prepare for being able to do remote updates and if possible even some Armbian image testing. For that, I need a robust, bullet-proof and fully remote mechanism. The most I should assume to be able to ask my father is to unplug and replug the machine to powercycle. I hope you guys don't mind me joining your conversation to discuss my options. In the past, I had a setup on X86 with grub that I would like to hopefully replicate now in function with the Helios 4. There was a very minimal (read-only?) OS in a partition (network with DHCP, sshd) that would be the default boot target. The machine would always boot into this after a power cycle. From there, I issued a grub-reboot command to reboot into my desired OS. If I screwed the main system up somehow, I was always able to go back into the minimal system. How would I go about doing that in the Armbian world? From your discussion, it seems to be about tweaking armbianEnv.txt. But how can I do that in a way that has a bullet-proof option the system falls back to after a power cycle but also allows me to tweak it in a way that survives a warm reboot? I do like btrfs a lot and believe it should play a role here. I read @eselarm mentioning btrfs support in u-boot. How can I verify which u-boot is installed on my machine and whether it supports btrfs or not?

There are various recent reports of windows corrupting the partition table.

If I remember correctly, recently there was a similar thread on the forum re GPT corruption under windows. Not sure, but there might be some useful info. Alternatively, flashing under Linux might be an option.

Hi, I am returning to Armbian after quite a few years. I was trying to follow guidance from nexbox-a95x-armbian and after a search found the debian & Ubunt images (https://www.armbian.com/uefi-arm64/) which I downloaded and wrote to a USB using Rufus (also balenaEtcher). I then tries to look at the FAT32 partition contents but the GPT was corrupt - tried many windows tools and Linux.I "repaired" the GPT using Linux tools but then the FAT32 filesystem was corrupt. What am I doing wrong? any help much appreciated

Thanks for the reply @laibsch . I looked for alternative solutions and it seems to be possible to only disable certain parts of PAM instead of the whole thing. Specifically it seems like the armbian dynamic MOTD is the biggest part of the problem. I opened /etc/pam.d/sshd , and commented out these lines to disable the motd: session optional pam_motd.so motd=/run/motd.dynamic session optional pam_motd.so noupdate And rebooted. This drastically improved the speed, from 5 seconds to around 2-3 seconds on first login and 1 second on subsequent logins. Still pretty bad though, what is there that needs to take one whole second or more to do to open a simple shell connection?