rpardini

Hey @Jeremiah Cornelius great stuff.
I've been working on removing the ODROID-specific cruft from the G12B family in armbian/build.
That is almost done now (some damned patches are still in the way) so I could start work on adding VIM3 officially.
Are you on Armbian's Discord? Catch me there in #amlogic as 'rpardini'
We could surely benefit from each other's work (and I from the fact you have a VIM3 to test on ;-) 
Let me know
 

Yeah, don't bring boards on vacation is a decent policy, though often violated I hear.
 
I realized after posting that we're on a tight schedule (Armbian 21.08 release) so I jumped the gun and sent a very basic PR, but is 100% untested.
It's Armbian's default meson64 kernel, mainline u-boot 2021.04 with vim3 default config, and the a311d DTB from mainline kernel, and that's it.
It could benefit from your work (asound file, any gpu/X11 settings, etc) but should otherwise be very similar to the N2 image I understand you based off.
If it boots, it's a win already.
 
Enjoy your vacations!
 
 

Hey @Jeremiah Cornelius 
I've been working on something similar it seems, thanks to @lanefu for making the connection.
Although the path I took was directly modifying the Armbian build scripts, instead of modifying a live image and then re-packing it.
 
My fork of Armbian is quite complex, but I'm slowly splitting and reorganising things (and sometimes writing a metaprogramming Bash framework in the process ) 
A few points that may be of interest to you:
 
- Onboarding replaced by cloud-init, instead of any interactive onboarding, I configure cloud-init to read some YAML files from /boot.
  /boot/network-config can configure all aspects of networking (including wifi), /boot/meta-data is just that, and /boot/user-data can do almost anything, create users, passwords, import SSH keys, install packages, run scripts, resize rootfs, create SSH host keys, etc.
  cloud-init is of course focused on cloud images, but actually can be used on any environment, if you can stomach its YAML and hammer on its config.
  With cloud-init comes netplan.io (in place of NetworkManager) and some other stuff that may not be appropriate for your use-case so take with a grain of salt.
  Also my implementation is not bullet-proof yet, but it aims to work just like the Ubuntu RaspberryPi 4 "Server" image (also has cloud-init out of the box).
  Most of it is done in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/cloud-init/cloud-init.sh (including the .not_logged_in_yet thing)
  Some other related stuff in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/more_like_ubuntu_cloud.sh (which disables a bunch of stuff in the BSP,  during BSP-generation, so that reinstalls/upgrades of the bsp package do not ruin everything).
 
- A trick I call rootfs-in-rootfs, during the image build process, I capture an e2image ext4 dump of the produced ext4 rootfs and then include it in the rootfs.  A bit like having a directory full of files, creating a .zip of it, then including that .zip file inside itself  but without the compression.
  Then boot the SD card (which includes the rootfs dump inside) and run "e2image -racp /root/rootfs.ext4.e2img /dev/sda2" for example.
  The nice thing is that e2image (part of e2fsprogs) can do a "smart" copy (-c), knowing that reading is cheaper than writing, it can read both the source and destination and only write the changed blocks to the target. This allows for a very, very fast version of "nand_sata_install",  especially on the 2nd+ "flash".
  More speed comes from reading/writing some hundred-thousand whole blocks instead of possibly millions of files that rsync would need to inspect individually.
  The relevant code fragment is https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/rootfs_e2img_inside_rootfs.sh
 
Hopefully these will be of some help,
Ricardo
 
 

Hey @Jeremiah Cornelius 
I've been working on something similar it seems, thanks to @lanefu for making the connection.
Although the path I took was directly modifying the Armbian build scripts, instead of modifying a live image and then re-packing it.
 
My fork of Armbian is quite complex, but I'm slowly splitting and reorganising things (and sometimes writing a metaprogramming Bash framework in the process ) 
A few points that may be of interest to you:
 
- Onboarding replaced by cloud-init, instead of any interactive onboarding, I configure cloud-init to read some YAML files from /boot.
  /boot/network-config can configure all aspects of networking (including wifi), /boot/meta-data is just that, and /boot/user-data can do almost anything, create users, passwords, import SSH keys, install packages, run scripts, resize rootfs, create SSH host keys, etc.
  cloud-init is of course focused on cloud images, but actually can be used on any environment, if you can stomach its YAML and hammer on its config.
  With cloud-init comes netplan.io (in place of NetworkManager) and some other stuff that may not be appropriate for your use-case so take with a grain of salt.
  Also my implementation is not bullet-proof yet, but it aims to work just like the Ubuntu RaspberryPi 4 "Server" image (also has cloud-init out of the box).
  Most of it is done in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/cloud-init/cloud-init.sh (including the .not_logged_in_yet thing)
  Some other related stuff in https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/more_like_ubuntu_cloud.sh (which disables a bunch of stuff in the BSP,  during BSP-generation, so that reinstalls/upgrades of the bsp package do not ruin everything).
 
- A trick I call rootfs-in-rootfs, during the image build process, I capture an e2image ext4 dump of the produced ext4 rootfs and then include it in the rootfs.  A bit like having a directory full of files, creating a .zip of it, then including that .zip file inside itself  but without the compression.
  Then boot the SD card (which includes the rootfs dump inside) and run "e2image -racp /root/rootfs.ext4.e2img /dev/sda2" for example.
  The nice thing is that e2image (part of e2fsprogs) can do a "smart" copy (-c), knowing that reading is cheaper than writing, it can read both the source and destination and only write the changed blocks to the target. This allows for a very, very fast version of "nand_sata_install",  especially on the 2nd+ "flash".
  More speed comes from reading/writing some hundred-thousand whole blocks instead of possibly millions of files that rsync would need to inspect individually.
  The relevant code fragment is https://github.com/rpardini/armbian-build/blob/rpardini-fragments/userpatches/fragments/rootfs_e2img_inside_rootfs.sh
 
Hopefully these will be of some help,
Ricardo