Jeremiah Cornelius
-
Posts
16 -
Joined
-
Last visited
Posts posted by Jeremiah Cornelius
-
-
This is fantastic information and deserves to be highly rated.
I can see this as the basis for Armbian work with the Pinetab, and numerous other similar efforts.
-
22 hours ago, Jeremiah Cornelius said:
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!Heads up! jtremblant of the TwisterOS project, and a great systems guy, just informed me that HDMI audio output now works out-of-the-box for pure arm64 builds!
This was not true of earlier test builds. I suspect that I did not track a change, copying /var/lib/alsa/asound.state from my armhf build. These correct settings for ALSA mixer seem to be a likely solution.
Users of Fenix Ubuntu on VIM3 may want to verify if this solves audio issues, along with my other configuration details found here:
https://forum.khadas.com/t/twister-os-armbian-2-01-on-vim3-gl-acceleration-fan-and-audio-full-howto-and-working-image-dl/11775
₩₳ł₮ł₦₲ ₣ØⱤ ₮ⱧɆ ₲ł₣₮ Ø₣ ₴ØɄ₦Đ ₳₦Đ Vł₴łØ₦
— Jeremiah
-
8 hours ago, hexdump said:
@Jeremiah Cornelius - for your lightdm issue, maybe give the slick greeter for lightdm a try - it fixed my problems with non working lightdm on 32bit arm - might be worth a try
best wishes and good luck - hexdump
Thanks for the great suggestion. If it means a diff in a config file, versus a fork in the Armbian script library, it's a very good trade-off!
-
3 minutes ago, tparys said:
I'm not familiar with these boards at all, but I suspect there'd be some interest in getting support in the build system.
Have you considered seeing trying your hand at putting a PR to make automated builds? It's not too much work.
Thanks, that's my next step here, I think.
There was a fair amount of dispute in the Khadas forums a while back, about uBoot on the Khadas boards. I need to do more testing with an Armbian mainline uBoot, if nothing else. Right now, I cheat with the Khadas uboot which I built as a .deb with their Fenix tool. I get a second VIM3 in a couple more weeks, and this will be practical then.The VIM3 is a smoking hot SBC. A little pricey, and some storage I/O tradeoffs vs other considerations, but it's a rocket. Not everyone has use for the onboard NPU, which must be a part of the price differential and the Odroid N2+. Because it is so Android-friendly, especially with Khadas uBoot and Amlogic USB imaging, it looks a bit like a TV box on steroids. It's a lot more than that. Until a Rock Quartz shows up, this is many ways the board to beat for desktop use.
I know you probably have seen NicoD's review from a couple years back: -
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
-
14 hours ago, rpardini said:
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:
< snip >
Hopefully these will be of some help,
Ricardo
Oh, man. Thanks. This information is a goldmine!
I won't be able to dig in very deeply until the weekend, but I am champing at the bit, a bit. ;-) -
5 minutes ago, lanefu said:
BTW have you played with https://github.com/armbian/build. We have budgie I there, and would gladly take help there as well
..but you're doing 32bit userspace?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
-
2 minutes ago, tparys said:
You monster
Well, at least for function, and not capriciously!
— Jeremiah
-
17 hours ago, lanefu said:
Doing this should probably trigger it. https://github.com/armbian/build/blob/master/lib/distributions.sh#L157
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!
-
12 minutes ago, tparys said:
As a possible out-of-the-box solution. Have you tried directly mounting the original image, and just rsync'ing that to your partitions?
# mkdir /dev/shm/{original,current} # kpartx -av Armbian_21.02.1_Nanopim4v2_focal_current_5.10.12_desktop.img add map loop9p1 (253:0): 0 7258112 linear 7:9 32768 # mount /dev/mapper/loop9p1 /dev/shm/original # mount /dev/mmcblk0p1 /dev/shm/current # rsync -av --delete /dev/shm/{original,current}/ # umount /dev/shm/original # umount /dev/shm/current # syncI didn't try it (for obvious reasons), but that should reset pretty much all logs, passwords, user files, ssh keys, etc ..
The verbose option should list everything that it's doing.
Your mileage may vary. You might need to adjust if your build has two partitions. It may delete important things ...
That's a good idea. I'd have to be more selective - as there are changes to my images I'd need preserved, such as apt changes, dselect selections, dpkg options, for a start. I also do the unthinkable, and change contents of /etc/armbian-release and /etc/armbian-image-release, because the platforms aren't yet build targets, and I am playing Doctor Frankenstein with the parts. LOL
Thanks,
— Jeremiah -
16 hours ago, lanefu said:
Doing this should probably trigger it. https://github.com/armbian/build/blob/master/lib/distributions.sh#L157
Also take a look at
https://github.com/armbian/build/blob/master/lib/distributions.sh#L372-L379
Might be related to https://github.com/armbian/build/blob/master/packages/bsp/common/lib/systemd/system/armbian-firstrun-config.service#L9
Probably best to keep conversation here for now. Mostly we use issues in GitHub for major bugs / problemsReally 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
-
4 hours ago, lanefu said:
Can you just give me some quick bullet points on what you're waiting to achieve... I may have an answer.Thanks! Very kind.
- I am looking to re-set the firstboot state for a derived image, after customization and out-of-band additions.
- My efforts extend to re-enabling systemd unit files for armbian-firstrun, armbian-firstrun-config, and armbian-resize-filesystem.
- Results: New ssh keys are generated, and new UUID appended to /etc/armbian-image-release - no other config tasks are run (update root pw, create normal user, choose logon environment, etc)
Observation: /usr/lib/systemd/system/armbian-firstrun-config is deleted after being enabled, on next boot.
- Is this expected behavior?
- Is it an error in how symlinks under /etc/systemd are handled?
-
Would an issue on the git repository be well received?
I'd like the unit disabled, and maybe a re-settable flag written to the image, preventing accidental firstrun.
My main question is still why this isn't working as expected. Does behavior change, if /etc/armbian-image-release already exists? There's something I'm missing!
When I understand this fully, I'll be in a better position to offer contributions.
-
1 hour ago, Werner said:
You can help make this wish become reality. Everybody can contribute to make the documentation better: https://github.com/armbian/documentation
The lack of (human) resources is a big issue for the Armbian project so community contributions are more than welcome.
I agree. I'm very much in favor of making contributions, and not shy about being detailed. When the Linux world revolved around HOWTOs, not Reddit subs and siloed vendor forums, I was particularly active.
Here's a case where I'd gladly supply documentation, were I not faced with ambiguous outcomes, and a lack of authoritative information to begin!
Thanks!— Jeremiah
-
After a couple of days, this seems to be a stumper.
I'd wish that this, an essential piece of Armbian configuration and operation, were documented as well as the image building process!
-
Hello,
It's been more than two days working to solution. I have gone deep into the documentation and forum posts before asking this. Much of the information in this subforum is c 2017, and relates to /etc/init.d locations which are now obsolete, etc. Definitive assistance is much appreciated!I'm building clean Armbian-based images, for a number of unsupported desktop configurations on unsupported boards. These have been fantastically functional, I I'd like to make these available as community-supported releases. I do not expect such a hybrid configuration, despite using an Armbian kernel package, and an Armbian Focal base filesystem image, to ever be supported - regardless of how robust and useful.
Example, I have built Khadas VIM3 images, using the Meson64 kernel image with a 32-bit userland, and enabling the Amlogic hardware tweaks for sound and cooling etc., using a Khadas uBoot, built with the Fenix tools. This allows for the broadest multi-media and drm compatibility, as well as support for the Raspberry-Pi fueled wealth of armhf binaries, electron packages, etc.
Distribution of these images entails cleaning all logfiles, and scrubbing runtime customization of ssh keys, networks, users, groups, caches, bash histories, etc. This is no problem - my utility scripts for these things, and optimizing resulting .img.xz images work very well.
My stumbling block is getting an Armbian OOB firstrun experience. I want Armbian FS resize, ssh to be initialized, MOTD displayed, root passwd to be set, new user created, and graphical startup option requested.
AFAIK I have all the required systemd units in /usr/lib/systemd/system/, all the right scripts in /usr/lib/armbian, etc.
I delete all users but root, disable displaymanager with systemctl and then issue: 'systemctl enable armbian-firstrun && systemctl enable armbian-firstrun-config && systemctl enable armbian-resize-filesystem', then immediately 'shutdown -h now'.
At following power-up, I often notice multiple OpenSSHd server restarts, which I assume indicate key regenerations. However, I have never been prompted to generate a new root passwd, create a regular user, or any of the other configuration goodies. THERE'S CLEARLY SOMETHING I'm missing here! :-)
Does /root need to be completely vacant? Is there a hidden flag written as a dotfile under /usr/lib or /var that I don't know about?
Solving this would be very helpful. I'm not real happy with the Khadas and Pine contributed images, which typically include a default user, with cruft and artifacts that are sometimes a risk, and never the right way to deploy.
Thanks!- Jeremiah
₩₳ł₮ł₦₲ ₣ØⱤ ₮ⱧɆ ₲ł₣₮ Ø₣ ₴ØɄ₦Đ ₳₦Đ Vł₴łØ₦
Release Announcement: TWO New, Community Unofficial Armbian MAINLINE Desktop Images for Khadas VIM3 Pro
in Common issues / peer to peer technical support
Posted
I'm very glad to help here! It makes me glad to hear of your progress.
I do have TWO VIM3 Pros for testing, LOL.
My current limitation is I will be in UK til Aug 3, and while vacationing, haven't brought any of my boards!