Active threads

I will soon be in the situation of having an offsite Helios4 installation at my non-techie father's place on another continent. I want to prepare for being able to do remote updates and if possible even some Armbian image testing. For that, I need a robust, bullet-proof and fully remote mechanism. The most I should assume to be able to ask my father is to unplug and replug the machine to powercycle. I hope you guys don't mind me joining your conversation to discuss my options. In the past, I had a setup on X86 with grub that I would like to hopefully replicate now in function with the Helios 4. There was a very minimal (read-only?) OS in a partition (network with DHCP, sshd) that would be the default boot target. The machine would always boot into this after a power cycle. From there, I issued a grub-reboot command to reboot into my desired OS. If I screwed the main system up somehow, I was always able to go back into the minimal system. How would I go about doing that in the Armbian world? From your discussion, it seems to be about tweaking armbianEnv.txt. But how can I do that in a way that has a bullet-proof option the system falls back to after a power cycle but also allows me to tweak it in a way that survives a warm reboot? I do like btrfs a lot and believe it should play a role here. I read @eselarm mentioning btrfs support in u-boot. How can I verify which u-boot is installed on my machine and whether it supports btrfs or not?

There are various recent reports of windows corrupting the partition table.

Thanks for the reply @laibsch . I looked for alternative solutions and it seems to be possible to only disable certain parts of PAM instead of the whole thing. Specifically it seems like the armbian dynamic MOTD is the biggest part of the problem. I opened /etc/pam.d/sshd , and commented out these lines to disable the motd: session optional pam_motd.so motd=/run/motd.dynamic session optional pam_motd.so noupdate And rebooted. This drastically improved the speed, from 5 seconds to around 2-3 seconds on first login and 1 second on subsequent logins. Still pretty bad though, what is there that needs to take one whole second or more to do to open a simple shell connection?

hi, I am unable to boot Armbian on Gamebox G11 Pro. I am able to boot CoreElec and Emuelec easily via sd card. I have tried every tip and trick to boot it, lot of Armbian versions and forks. Can you suggest a suitable armbian dtb file for the same. The most reliable method to boot it.

@Nick A also there are some problem with root, when i try ‘su’ on terminal emulator, it showed /system/xbin/su : permission denied is there any problem with root?

@Cancer if NetworkManager is masked I'd unmask that for use with netplan e.g. systemctl unmask NetworkManager systemctl enable NetworkManager systemctl start NetworkManager In the 'minimal IOT' images for OrangePi Zero 3, NetworkManager is not shipped with my images. I'd need to install that myself. Perhaps for other boards or images, NetworkManager could have been included by default. (but like you mentioned masked) in my /etc/netplan/configfile.yaml , I configured it as like that 3 lines, removed other liines so that I used NetworkManager utilities to configure the interfaces. I think that is 'simplier' than fumbling with netplan yaml configs which I'm unfamiliar as well. I'm actually running a Wifi AP, but that the AP itself is not managed by NetworkManager, it is managed by hostapd, as given prior https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 I prefer hostapd as like discussed with @bushw, I think NetworkManager WiFi AP uses dnsmasq by default and setup a NAT (i.e. configures firewall rules for NAT masquerade) https://thekelleys.org.uk/dnsmasq/doc.html and a dhcp server to distribute ip address to the Wifi clients. While this works, it may not be the configuration I prefer. The other thing is hostapd logs every wifi connection in journalctl logs, that is something I specifically want, so that I can check the connections if need be. NetworkManager it seemed do not log the connection attempts at the AP. As to the rational that NetworkManager WiFi AP uses dnsmasq and setup NAT, 'mess with firewall rules', I think that is because it is a 'canonical' configuration that 'just works'. Because otherwise you need to consider routing , bridging , whether to run dhcp server etc which don't have any standard setup for a 'WiFI AP' based network. I.e. the config is specific and unique to your network configuration (the whole physical network, not just the board) and you need to configure that manually, e.g. with using hostapd. you can build 'very complex' networks if you bother to go the distance, e.g. to do routing, ipv6, special NAT, special firewalling etc, to the extend if you have the skill, I think you can even configure clients to 'roam' across WiFI APs in your network, that is not 'mesh' but rather a full 'autoroam' setup of network configs. but everything is manual, custom and specific / unique to your physical network. on a different off-topic note, my WiFI AP (hotspot) that I configured as described in the gist has been running (very) well on my OrangePi Zero 3 'for months' practically as a desktop WiFI AP. Throughput is good (I get slightly above 100 Mbps due to OrangePi Zero 3 having a good wifi chip), Armbian runs well on it, and I even run various apps on it. e.g. I managed to run rpi-monitor on it there is a thread about OrangePi Zero 3 but that it seemed for the edge kernels and images, there may be 'some troubles', I've not tried it though. I'm not sure if it affects the 'stable' images, hopefully that the 'stable' images which is a bit older in terms of kernel releases are still ok.

The mmcblkXbootX partitions are hardware defined partitions on eMMC storage device and can be used by storing boot firmware.

Great to see continued development for RK3318/RK3328 boards, Armbian support really helps unlock their full potential for lightweight Linux projects.

@usual user The USB and Ethernet ports are exposed, but how would that work exactly? I don't know how to make the software boot from USB or Ethernet and even if I did I don't know what to boot into that can write an image file to the emmc chip. I can find no info on this on radxa or armbian sources.

When you do first login, you need to choose correct locales combination and language in desktop should follow - you still need to install desktop packages ... If you don't have locales support in the system, you won't be able to use it in desktop. I think this is the problem. In my case, when I select my own locales (sl_SI.UTF-8) and install those desktop related packages, I have Gnome with Slovene support.

RPi added some checks in their initramfs post-update script which causes this, found here: /etc/initramfs/post-update.d/z50-raspi-firmware: case $flavour in v8|v8-rt|2712|v6|v7|v7l) ;; *) echo "ERROR: Unsupported initramfs version ($initrd_version)" exit 0 ;; esac However there is also another fine in this folder which was added years ago: https://github.com/armbian/build/pull/6039/files#diff-02b9b6fbb77fcab23278cd4a148b3f2c91d2c1361d05f33a21bdab19182caf21R139-R153 That seems to handle initramfs creation properly. So the error message is purely cosmetical. That would give trouble when updating rpi packages from upstream since there would be changes detected. Better solution might be to add a hint to our code stating that the ERROR can be ignored as long as overall initramfs generation was successful.

Additional Info: The "Current" Kernel I found the equivalent code in the Current kernel. It is a clearly a different version of the file, but it looks like the same error is present. I have not tested it. Snippet Source: ./build/cache/sources/linux-kernel-worktree/6.12__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts &analog_sound { pinctrl-names = "default"; pinctrl-0 = <&hp_detect>; simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>; simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>; // This line here: Change GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH simple-audio-card,widgets = "Microphone", "Onboard Microphone", "Microphone", "Microphone Jack", "Speaker", "Speaker", "Headphone", "Headphones"; The "Vendor" Kernel I found the equivalent code in the Vendor kernel's devicetree. It is also a clearly different version of the file from the other two kernel trees. But it looks like this particular coding error (for the audio) is not present here. The headphone detection level is set to GPIO_ACTIVE_HIGH. Source: ./build/cache/sources/linux-kernel-worktree/6.1__rk35xx__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts However in my experience (tested again just now with version 28.5.1), the Vendor kernel seems a bit crippled: No GPU or video acceleration, and no ES8388 analog audio whatsoever (not even at the ultra-low volume I was getting with the Edge kernel). At least the screen, keyboard, mouse, and ethernet works, but with no video acceleration the video is slow and clumsy (in gnome). I suspect that the best place to look for the audio issue with the Vendor kernel is not to focus on the audio, so much as to focus on what broke on an apparently deeper level.

still on windows , but microsoft suggests 11 so looking for linux 11

It's worth noting that you don't have to necessarily change anything in the build process. As long as you plan to not insert partitions in the middle, you can: write the image to the card with parted, resize the root partition to whatever you want make a new partition If you want to have more than 4 partitions total, this works best with GPT partition table, but legacy msdos works too with a little more effort `fsck.ext4 -f /dev/foo` where foo is the root partition `resize2fs /dev/foo` after you have the machine booted, you can then mkfs the new partition [you could probably do it in advance of booting the system too] I do this regularly, b/c I typically only partition about 1/2 or 1/4 of the SD card to leave the rest for wear-leveling. Are you trying to do this as a one-off or are you trying to do it for a dozen or more SBCs of the same type?

@fevangelou nice guide. THX! but maybe it would be best to have the instruction in an separate topic! in best case it gets also pinned. so new users can find it much easier than scrolling though 18 pages (in this thread. there is also the 4gb thread) to find it......

Yes I'm aware that I can only rely on the community for any help or tip. I'm now considering to revert back to a bullseye setup with a 5.10 Radxa kernel, but I was kind of reluctant to keep an old version of Debian as my Rockpi is accessible from ouside my network... The Rockpi is powered by a PoE hat, it never had any issue so far but maybe the PoE management is the culprit. I'll try an use the Rockpi with a traditional power supply, but in any case if this is the issue it won't be a sustainable solution for my target setup.

I had the precise information about data-offset from "--examine" mdadm command, and also I was in raid1, that's far less sensitive to error than raid5 or raid0 for example. I would not have been surprised that the resync, if taken to the end, would have worked... But I will never know. As far as I know, I get the data back and I'm very lucky and happy. Thank you

@dale you need a display overlay that is compatible with tm16xx. OpenVFD overlays are NOT supported. You can read README.md and dt-bindings documentation at https://github.com/jefflessard/tm16xx-display But note that there has been many changes recently to the code base since the driver is currently in review process to be upstreamed into mainline kernel (targeting v6.18). So double check which bindings version format has been integrated into Armbian rockchip64. The GitHub repo also contains a vfd-convert utility to automatically convert OpenVFD configuration files to expected tm16xx DTSO. But : 1. It requires OpenVFD conf file, not dtso. 2. You may need to go through file history to get the version matching of what has been integrated into Armbian rockchip64.

Customizing image and customizing kernel are different tasks. For latter use the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } kernel-config command and then copy over the created config file from output to userpatches. The framework will look for custom kernel configuration files and uses them if they're detected. More details here: https://zuckerbude.org/armbian-using-kernel-config/

That seems to have gone away. ? SNILMERG... Now using very small but 1920x1080 screen, xfce terminal text is about 7 microns tall, way too small for my ancient eyes, Simplified keyboard. ctrl&shift&+ magnify's text but when big enough to read, bottom of xfce4 terminal is offscreen below bottom of screen, so cannot see command line. Is there a keycode combo that expands text independently from terminal window size? Thank you.

Armbian kernel and BSP Debian/Ubuntu userland

You are still using an old Linux. You need Linux 6.13 or newer. You need to build your own Armbian OS. Also, don't forget the cma=256M kernel argument

removed

reopening after moving to "Software / Applications / Userspace"

Anyone an idea?