lanefu
-
Posts
1148 -
Joined
-
Last visited
Posts posted by lanefu
-
-
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
-
18 hours ago, Werner said:
apritzel (or Andre) is a well known mainline developer from ARM with good intention to make ARM support in Linux better for everyone and the old fashion way to discuss patches is the mailing list so he is right when asking to continue doing stuff there so all interested person can give their opinion since they most likely not watching our comparable small repository if something interesting pops up. I am already amazed that Samuel and Andre got in touch here.
But this is going way off topic 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?
-
2 hours ago, tparys said:
Though, reading through the posts here, the simplest solution is to delete the dispatcher script altogether, and add it via an optional package if users would still want that functionality.
K we've pulled it out.. Hopefully we can get a permanent solution by next release -
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
-
-
5 hours ago, Superkoning said:
FWIW: I'm an Armbian user, and, yes, I've done a few donations in the past.
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
🤠
-
5 hours ago, tony013 said:
did that on armbian, but when I try to mount a share, I get the error message, that nfs protocol (version) is not supported.
what's your mount target.... for grins try added -o vers=3 -
1 hour ago, tony013 said:
ust updated my armbian current to 5.10.35 and I'm quite excited, as pwm and gpio works as with LE
Then I tried to mount some nfs-shares from nas. Usually I only have to install nfs-common.
I did that on armbian, but when I try to mount a share, I get the error message, that nfs protocol (version) is not supported.
The used command work on every other system I have (desktop and rockpi).
I just use 'nfs' as filesystem type - no version specified/requested.
Is there something special on armbian, to have nfs support enabled?
that is weird..
can you do the followingzgrep -i nfs /proc/config.gz
and also armbianmontor -u -
-
17 hours ago, Nitrax said:
(Fact is, log2ram took down my entire kubernetes cluster, because when /var/log was full on one node, containers started to crash, causing more logs to be written on the other nodes (by a factor of 10-100) causing these to also crash within a few hours timeframe.)
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! -
1 hour ago, Eric74 said:
he Idea is copy the current configuration of eg. cubieboard2 and modify it in order to fit my requirements.
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. -
6 hours ago, Igor said:
Not directly related, but imo it's wise not to merge both at once.
agreed thanks for the heads up. -
5 hours ago, manuti said:
I used UUIDs to mount via fstab. You can see it in the snapshot and I suppose this info is also included in armbian-monitor dump included.
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.
-
44 minutes ago, cw73 said:
Hello folks! What is your preferred way to receive trouble reports? I have actually two issues with the recently release on a Cubieboard2. I do know that this is officially not supported. So your answer might well be, that you are not in favor of receiving any reports. Thanks!
Hey great question. Just share your issue in the peer support thread or the subforum that is relevant to the hardware you're using
-
1 hour ago, tony013 said:
I thought I had found my solution, but unfortunately that is not the case.
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.
1 hour ago, tony013 said:What a mess!
Comments like this are insulting to me and probably other devs as well.
my ordeal with rockpi4 and Penta Sata Hat + Tower
in Reviews, Tutorials, Hardware hacks
Posted
How's that been working for you? What SATA card are you using?