lanefu

I just released Armbian Focal Desktop MAINLINE images for Khadas VIM3 Pro. These are individually, pure arm64 and hybrid arm64/armhf variations.
Thanks go to @lanefu for key pointers in understanding how to "re-arm" the firstboot and firstboot-config mechanism in current-state Armbian.
 
Please offer feedback and experiences if you test these. The images are currently hand-built, but if enough interest is generated, and time permitting, I will commit to a git fork for an unsupported standard building process.
 

 
I have more detail on the distribution site at archive.org, and in the corresponding posts to the Khadas forums:
 
armhf Hybrid
LightDM will NOT work as display manager in this configuration, and I've chromed-up lxdm as a replacement. Autologin may be a work still in progress.
Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - 32-bit Userspace - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro With 32-bit Userspace  
arm64 Native
UPDATED INFO
HDMI audio out is non-functional with the 64-bit userspace, which is true for all Debian and Ubuntu systems, including Khadas Fenix builds.
This capability may be a user's deciding factor in chosing between builds.
With further testing, HDMI AUDIO NOW WORKS in arm64 image build!
Archive.org: Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro - arm64 - Ubuntu Focal Xfce Desktop Forums.khadas.com: Community Armbian 21.02.3 MAINLINE Image For Khadas VIM3 Pro arm64 Native  

Hello,
Recently I installed docker on my armbian and motd got broken. Previously it was printing correctly information about traffic:
RX today: 20,72 GiB But after installing docker and playing with some images motd is displaying following error:
RX today: Error: Not all requested interfaces found in database or given interfaces aren't unique. The problem is that docker adds new network interfaces that are not initialized in vnstat. I've solved my issue by adding the new docker interfaces in vnstat:
vnstat --add -i docker0 vnstat --add -i veth160e0f9 Perhaps /etc/update-motd.d/30-armbian-sysinfo script should somehow detect new interfaces and add them automatically to vnstat or maybe variable in /etc/default/armbian-motd should not include virtual interfaces?
PRIMARY_INTERFACE="$(ls -1 /sys/class/net/ | grep -v lo | sed -n -e 'H;${x;s/\n/+/g;s/^+//;p;}')"  

If anyone needs to get the 3.5mm audio jack working on the N2+, here's one method.
 
1. Edit or create /etc/asound.conf with these lines. Copied directly from the Hard Kernel Ubuntu setup.
 
pcm.!default{     type hw     card 0     device 1 } ctl.!default{     type hw     card 0 }  
2. Run this script to turn on the 3.5mm audio in alsamixer. The settings are listed in the same order as in alsamixer.
#!/bin/bash  # 3.5MM JACK, set to max gain  amixer sset 'ACODEC' '255' # 3.5MM JACK - set in/out channels (src/sink) amixer sset 'FRDDR_B SINK 1 SEL' 'OUT 2' || true amixer sset 'FRDDR_B SRC 1 EN' 'on' || true # 3.5MM JACK amixer sset 'TOACODEC SRC' 'I2S C' || true amixer sset 'TOACODEC OUT EN' 'on' || true amixer sset 'TOACODEC Lane Select' '0' || true # SAVE NEW SETTINGS alsactl store  

it is not a bootsplash problem
 
at boot the kernel searches for device and activates them and if a device takes time to get seen by the kernel the kernel get a amount of time to wait
so when a device for example my usb3 got called before the bootsplash there is no bootsplash because kernel is waiting for the usb before he wants to put something on screen.
 
you can see that effect if you boot through a console then you see the kernel spit out messages sometimes fast sometimes slower
and it happens even more when you reboot but that is more less nowdays because the drivers are getting better
 

I'm sorry. These are rhetorical questions.
I can't get used to articulating thoughts in the style of English grammar so that the automatic translation looks correct.
In fact, I am an experienced user and will find any information.
But if we give the user the ability to search, update, or reinstall by key tags, it will be very good.
 
sudo apt search armbin
This command will display the full list of packages provided by armbian.
sudo apt search armbin-edge
This command will only show packages for $BRANCH
It is the word combination that is important here armbian-$BRANCH
sudo apt reinstall armbian-current
This command will actually do a package update for the $BRANCH
 
Here we not only take care of the user, but also improve the armbian.
 
@Igor Yes, but only for those packages that contain programs, libraries that have their own version.
This is necessary to correctly register the mutual dependencies.
And this is especially true for the kernel and libraries that use the functionality of this particular kernel.
The final version can be formed by concatenating the original version and the armbian version.

Examples:

- new board to existing family
- new board and new family

Good news! I was able to follow the devmem2 instructions in this forum article posted by @Ohms, and get all 26 pulses (by modifying the debounce timer).  Result!

After mounting and unmounting several times both external units it seems to start working. Now the mount point at /sda is consistent across all the commands. The outpus you asked, @lanefu, is:
ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 15 may 11 22:57 d4e4d15d-d587-4f5d-83d7-4cbb1700e7c5 -> ../../mmcblk0p1 lrwxrwxrwx 1 root root 9 may 11 22:57 dcb5a19c-6bd2-4c5a-8fc4-9ed4adec7074 -> ../../sdb lrwxrwxrwx 1 root root 9 may 11 22:57 e6201983-bfd8-4eae-bf54-90575f09835f -> ../../sda  
I also added a new screenshot. Thanks for the help. And I'll keep an eye on this if it happens again.

... has been changed to https://github.com/armbian/build/blob/master/lib/main.sh#L395-L396 so this package is only board specific now. Similar variant will come for desktop.

Anyway, since release days are over, this can be moved in - if ready. FYI, there is another larger chunk of additions by @rpardini which needed review, understanding and integration. Not directly related, but imo it's wise not to merge both at once. @lanefu

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.

When designing a good sbc for general compute/server tasks I think you need a set of features that enable both a 'desktop' as well as 'server rack' deployment.  The reason for this is the evaluation process someone will likely undertake in order to buy into the boards features. No one is going to buy 32 boards for a 'server rack' deployment as the first purchase.  Instead they are likely to purchase one or a few to evaluate first.  That evaluation is not going to happen in a rack mount, but instead will happen on a desktop.  Once someone is comfortable that the base board works for their basic needs (i.e. the software and general hardware works), then they will explore the 'server rack' deployment options as they plan to scale a use of the board.
In my opinion therefore you need to make sure you have the features necessary to have a good evaluation experience on the desktop for the board ultimately to be successfully purchased in larger quantities for server work.  One example of this is an hdmi port.  While an hdmi port is completely useless in a server deployment, it can be quite useful during board evaluation on a desktop.  Another example is cooling as mentioned in the above posts.  I think you need to have good thermal design for both deployment scenarios (both as a desktop board and in a server rack mount), which might require different heat dissipation strategies for the different environments. Finally POE while likely unnecessary for a desktop evaluation is critical for a server deployment.
 
My ideal feature list would be:
1gbit POE ethernet port
4GB ram
32GB emmc (or more optional)
good external storage options (m.2 or other)
hdmi port
2 or more usb ports (at least one being usb3)
power port for non POE usage
optional case for desktop use with good thermals
optional rack mount with good thermals
 
The two things I think it shouldn't have:
- no wifi/bluetooth
The reason I say these are not desired is that good wireless (good antenna's, good software support) is difficult to design into a board, it isn't needed in the server rack case and can be accomplished better with a usb addon for the desktop case without incurring the added cost to the base board.
- no SD card
The reason I wouldn't include an sd card slot is if emmc is standard, that will be the preferred deployment storage media.  You only need another option to install/update the internal emmc and usb should be sufficient for that.  The sd support then just becomes an added cost with no real long term need.  It does require that booting from usb be well supported by the firmware.
 
Such a board would span a lot of use cases from general purpose single desktop use case to hundreds of boards deployed in dense rack configurations.
 
My personal experience is that I try things out first by evaluating one of something, then scale up to a few, and ultimately more as each step of the evaluation process shows the product is capable of the next deployment step.
 
Finally I'll mention price.  In my opinion you likely need the above described board at a price point no more than a RaspPi.  Given the large ecosystem and mind share built around that platform, and it is already capable of doing the above (although not well in many respects), you can't have something like this be at a 'high end' premium price point and expect it to be successful.  Price will to an extent drive the evaluation process.  If the price is considered too high, then people won't even start the evaluating, they will just stick with what the everyone else uses.
 

Thanks @PetrozPL
Added
https://armbian.atlassian.net/browse/AR-735

I want a stripped down board that has real 802.3af POE

I want a stripped down board that has real 802.3af POE

The thing is I want to be able to incorporate my SBCs in some 19" rack (1 U preferably), in desk grommet, or any other type of enclosure, so I don't want a well designed enclosure, as it won't help me.

Manufacturers will always add all hardware features that does not cost a lot : i.e. crappy cheap wifi and so on, because they do not bother to provide good drivers.
 
In the other hand, RAM is always priced a lot and thermal design bad. If I want a SBC for specific use case like computing (and not a X86 server), I want it to be passively cooled and energy efficient. Storage is also a choice : either emmc, either a good bus design for drives.
 
I simply cannot find a SBC for a use case because they are all designed for "general purpose" like a RPI or expensive with no guarantee of software support.
 

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
 
 

Hi,
 
so I merged master into release candidate branch.  Can you please check the Jira issues that are still "In Progress", or can I assume they are all not done? Or are some expected to be closed in May?
 
https://armbian.atlassian.net/secure/RapidBoard.jspa?rapidView=2&projectKey=AR

After wasting way to much time on this finally figured it out...in case anyone NEEDs UART on Pin 8,10 (UART2B) this is how you do it
 
Go to amrbian config and edit .dts file
 
disable i2c3 port (shares same pins as UART2B) ...change status to "disabled" in i2c@ff130000
hijack uart2 address to point to UART2B pins instead of UART2C (the debug pins)....change phandle-0 in serial@ff1a0000 to 0x143
 
now this is all you technically need to do, but this is tied to ttyS2 which is also the serial console output which is configured i believe at the kernel level (if anyone know how to disable let me know), so we need to swap ttyS2 to another interface to voice this
 
so i just changed serial@ff1a0000 to point to ttyS1 by doing below
swap serial1 ->serial2
swap uart1 -> uart2
 
If anyone has an elegant way to do all of the above with a nice dts overlay lmk, have no idea how overlay syntax works. 
 
BTW also tried directly hijacking serial1 and serial 3 which are disabled (by changing phandle-0), but it only works in serial@ff1a0000...i guess all UART2 ports (UART2a,b,c) are tied to this address. 

Reason I do that is that I've used this technique to backup (or obliterate) full OS images. If I rsync from an image that doesn't have that new directory, it'll wipe out the mount.
 
If I have the mount in a tmpfs at a known location, that shouldn't happen.

Budgie is on my list - as I get kinks worked out with clean, vanilla Armbian. I am doing hybrid arm64 kernels and armhf userspace because of audio-plugins. This worked well for me in Pinebook Pro, etc.

I'd do more with pure arm64, if I can solve some gaps with Carla, and when there's a 64-bit Linux Widevine. That's when Google decides they need a 64-bit Chromebook, I guess.
 
— Jeremiah

This is it!
Touching /root/.not_logged_in_yet gets the desired, correctly reset behavior for the armbian-firstrun-config systemd unit. I knew it was some small, critical configuration I'd been missing.
I now have what's needed for a community, unsupported Armbian Khadas VIM3 image that's functionally equivalent to Odroid N2+, and have plans for similar with 32-bit apt/userspace, which enables access to an armhf ecosystem of commercial audio software, and snap images.
 
This also means that the VIM3 Twister OS image that I have some good interest in from users, can be updated to use this firstrun logic - with an addition that will hardlink the new user to the "pi" account on which Twister OS scripts and configurations depend.
 
In the background are plans for ready-to-run Armbian VIM images with Budgie desktop and Elementary OS, pre-built. Being unsupported, some of these may advance from Focal to Groovy or Hirsute.
 
Thanks!

Make your changes to the image before you call rsync? /dev/shm/original is mounted rw unless you tell it otherwise.
 
 
You monster

Really thanks for this. It gives me a lot more to go on.
I'll do more work in the next day or so, and be back with some updates - HOPEFULLY with some guidance to offer others, if successful!
 
The ""${SDCARD}"/root/.not_logged_in_yet" is a GREAT hint!
It's the opposite of touching a flag in the file system, so of course finding it in a configured system is impossible! I'd have taken a long time, before I got to it in the script sources.
 
— Jeremiah