lanefu

How's that been working for you? What SATA card are you using?

IInteresting i guess we should add another kernel option for the virtual then

Yeah either would need to modify ubooy config on sdcard or flash uboot to spi. (Which we dont have access to yet) Hc4 support is early days. If you're not an expert with uboot id suggest just booting from sdcard for now

But.... this is a great topic where we need to start working on a process / protocol for patches like this

oh man that is sweet... will definitely check it out. thanks!

For those wondering Why? Here's several possible reasons because we can better opportunities for automated testing of changes faster manual testing easier to test desktop builds (I actually hate flashing sdcard and having to touch hardware) Broaden visibility of armbian as a platform for compute

Been dreaming of this one for a while. Finally got a weekend to focus on it recently. I'm hoping someone is eager to take what I've done and move It along some more. Here's what we have so far. * a linux 'family' called virtual.conf * a kernel config called linux-virtual-current.config * a board called virtual-qemu.wip The result is a full HVM accelerated armbian image with a kernel compiled with all the virtio drivers for disk, network and video. Also a u-boot.bin made for qemu that can boot the image when used as the qemu bios/firmware I've ran it as a VM on ubuntu using plain qemu on a Ampere eMag box.. and using UTM (qemu) on Apple M1 in MacOS this is using u-boot, not uEFI.. and you need to copy the u-boot.bin manually from cache/sources/u-boot...../u-boot.bin and use it as your chosen bios for qemu. I left some quick breadcrumbs on how to launch within the board config file. I want to keep the u-boot option, but obviously we need this to support uEFI booting to be viable for the masses. Next steps: * automatically resize and convert resulting image to qcow2 format * solve how to add cloud-init to image * solve for installing grubEFI for booting and whatever partition layout is needed * figure a proper way to write uboot to the image so thet qemu can boot without loading as a bios * strip extra hardware drivers out of kernel and make this thing lean PS Did I mention Desktop Works too?

K we've pulled it out.. Hopefully we can get a permanent solution by next release https://github.com/armbian/build/pull/2850

yeah deleting script makes sense.. So htop 3.x has network stuff built into it.. (I haven't tested it) Would be ideal to get to htop 3. and see if we can just bring over the minimal patches needed for the cpu stuff..... although we had some security stuff in our patches we had to recently addressed...so.. you know having someone that knows what they're doing in C would be good. https://github.com/armbian/build/tree/master/packages/extras-buildpkgs/htop/debian/patches

bare metal armbian on m1 will likely never be a practical pursuit for us... But I fully intend to have good options to run Armbian as a VM on M1

Thanks @Wernerfor all your work helping us migrate

FYI your donation IS greatly appreciated. I don't want the context of this conversation to convey the contrary.

Also riscVian doesn't sound as good 🤠

what's your mount target.... for grins try added -o vers=3

that is weird.. can you do the following zgrep -i nfs /proc/config.gz and also armbianmontor -u

https://docs.armbian.com/Developer-Guide_Build-Options/

Out of curiosity what hardware are you running for your k8s cluster? Expanding the log2ram size can help.. and also you could increase the frequency of the cleanup job. /etc/cron.d/armbian-truncate-logs also make sure your cluster isn't double logging to /var/log and to systemd journal.

not surprised armbian-config needs systemd for some tasks.... i'd go ahead and use like an armbian minimal image with that and keep things super light. pretty cool!

Yeah unfortunately the process isn't well documented.. but literally copying the cubieboard2 board config file for your board and then following the inheritance path and adjust where needed. Most likely your adjustments will just be pointing the board to different device tree files for uboot.

agreed thanks for the heads up.

okay sorry I didn’t understand the issue exactly. so I believe this is a technicality of using lsblk. A btrfs subvolume isn’t going to trace back to a block device. Would be interesting to look at the output of ls -l /dev/disk/by-uuid

IMHO I'd omit HDMI or any sort of output other than console. If the eMMC is a detachable module, then yeah eliminating SDCard is a good idea.

block device names can vary especially on USB.... it's best practices to use UUIDs or LABELS to mount filesystems.

Hey great question. Just share your issue in the peer support thread or the subforum that is relevant to the hardware you're using

I don't understand what problem you're trying to solve. Based on the picture you shared, you just need to press enter and a fresh prompt will draw. Comments like this are insulting to me and probably other devs as well.