After installing the latest update, my 3D printer warns about outdated instructions in the MCU and asks to recompile and flash it. What should I do?

It's most likely a local ipv6 op is talking about, not a public. ipv6 in range fe80::/10 is local only. To remove ipv6 in that regard, ipv6 has to be disabled on the device or it will get an address like that. And according to what is provided: 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether be:63:9c:35:dd:4f brd ff:ff:ff:ff:ff:ff inet 192.168.71.2/24 brd 192.168.71.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::bc63:9cff:fe35:dd4f/64 scope link valid_lft forever preferred_lft forever Today I learned a bit more about systemd-resolved, seems 127.0.0.53 IS the correct config for systemd-resolved: https://unix.stackexchange.com/questions/612416/why-does-etc-resolv-conf-point-at-127-0-0-53 And: If dhcp server is configured correctly, nothing has to be done on the devices (except resolving domains to local ip unless that is done on the LAN by dnsmasq)

This does not support f2fs I guess; standard in U-Boot is only FAT and Ext4 Some never U-Boot builds also include Btrfs. f2fs I have not seens working, but you will need to build a custom u-boot yourself then. Other option is at add Armbian argument to use an extra bootfs, tha will then be FAT or Ext4, so you can still use f2fs for rootfs. I would make U-Boot understand Btrfs and then use Btrfs for rootfs, as for several boards/platforms that is already default (likely only when you use newer/edge/mainline U-Boot).

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

My ISP offers no IPv6, so I usually set IPv6 configuration on disable or ignore. You still might see a link-local IPv6 address (starting with fe80), but that should not matter. I don't know why you can't simply type an IPv4 address in the various fields of nmtui. I have no issues with that. The risks is that you have various other random issues; If you try to do an fsck of /dev/sdc1 and it fails, that is a sign on the wall. It usually is something with SD-card, it might be counterfeit or your SD-card adapter has issues.