Jeremiah Cornelius

I solved this, for anyone experiencing the same. Simple answer is to apt uninstall pipewire-media-session, and allow apt dependencies to replace this automatically with wireplumber. Gnome Remote Desktop requires pipewire-media-session, but the software is inferior to wireplumber, especially when jackd is present. In any case, Remote Desktop functions remain in the Sharing options under Settings, and the "Legacy VNC Protocol" was tested with Wayland as the Gnome display server, and still works very well. Some of the problems may have arisen with pipewire-media-session and legacy configuration after do-release-upgrade, but switching to wireplumber is a better overall idea, and even endorsed by the pipewire-media-session developer. Switching audio output to HDMI was now a secondary issue, solved by the Gnome extension Sound Input and Sound Output Device Chooser. The labels for HDMI vs mini-jack are ambiguous, and could probably be fixed by fiddling with asound.conf, but the setup works and I'm not interested in potentially breaking things ahgain, by changing ALSA card order and labels, etc. I hope this helps others to get a working configuration on Station M2 with the latest Ubuntu LTS.

Right, that's reasonable. I had to fix this similarly with the VIM3, for the previous LTS Ubuntu userspace. I guess that I'm going back in. LOL.

I get no audio devices in Gnome/Jammy userland on an Armbian 5.18 kernel. From the console, alsamixer has controls for Analog RK809, but no Playback Mux for the speaker (mini jack) and changing the card Default to HDMI reports "This Sound Device Does Not Have Any Controls". The Gnome/Ubuntu audio applet has only a dummy device. Thanks!

So how do we disable Uart0? 😉

This is fantastic. I'm coming off sabbatical now, and will be checking this out!

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!

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.

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

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!

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

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. ;-)

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

Well, at least for function, and not capriciously! — 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!

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

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

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.

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ł₴łØ₦