All Activity

Hi friends, I have one nagging thorn in my side that I just cannot figure out. I need someone who has a 1password account for help with this one. The problem - their desktop app and browser plugin work in tandem -- and it will not synchronize on Armbian for some reason. I've tried everything I can think of - ensuring nothing is downloaded from Flatpak and therefore sandboxed and preventing any connectivity issues. But still not working. If someone can take 5 mins and create a free trial account on 1password, then here are the steps to reproduce: Download the latest arm64 version of 1password Desktop: curl -sSO https://downloads.1password.com/linux/tar/stable/aarch64/1password-latest.tar.gz Extract and move the files: sudo tar -xf 1password-latest.tar.gz sudo mkdir -p /opt/1Password sudo mv 1password-*/* /opt/1Password Run the post-installation script, and launch 1password sudo /opt/1Password/after-install.sh 1password Everything is all good, and working. I log in to my vault, as intended, and the app is fully unlocked. Settings already default to synchronization being enabled, but just for the sake of double checking: So we are all set on the desktop side. Now, for the browsers. I have checked this with both Firefox, and Chromium extensively -- all various kinds of versions, ensuring no Flatpak or anything like that. We install the browser plugin: https://1password.com/downloads/browser-extension And click on your corresponding browser, and enable the extension/plugin. At this point -- and I have done this hundreds of times across all of my other devices and installations -- there SHOULD be nothing to do in the extension as far as entering a username and password goes. It's supposed to detect the local socket and interface with the desktop application, meaning once you are authenticated on the Desktop app, your browser plugin will unlock. The most you'd have to do is click through the 1st-time-launch welcome message and skip the tutorial, but NOT authenticating needed. And sadly, this is where obviously, it doesn't work. We are instead prompted for our username and password and the extension shows a lock symbol which is totally incorrect. We right click the extension in Chrome and pick Settings, to figure out what the heck is going on: And are met, with the dreaded, connection problem and yellow light. Instead of all systems go and the GREEN light, as it is supposed to be: I've pretty much exhausted the amount of testing I can possibly do, I'm just a novice user personally Any help would be greatly appreciated, I'd even make a donation if someone can crack this nut, as it's a pretty glaring (for me) missing feature that I've grown accustomed to across every other device I own, and it does typically work very well, on any other OS.. I run it on Linux Mint, PopOS, Debian, Windows, all kinds of stuff never a problem I am able to report back with any further information requests or diagnostics etc. and already plan to forward this link to 1password support as well Thanks in advance for any help!

Thank you for your suggestions. I am trying to build Mesa in my Orange Pi Zero 3. When I tried installing the build dependencies, apt could not find libxatracker-dev, libllvm-18-dev, libspirv-tools-dev i added changed "deb-src" in the /etc/apt/debian.list, so I could download *-dev packages. How did you install all the dependencies? Are you in Bookworm, or Trixie? Actually I am looking for a double benefit with a new Mesa: *H264 hardware acceleration *I know that Raspberry has a newer Mesa, and X11 can handle the same LCD, with the same kernel module panel-mipi-dbi.ko

Thanks!, it works nicely, i was using a minimal image and had to install xfce then edit the media-buster-legacy-rk3328 deb to not ask for armbian-buster-desktop, i also needed mpv-legacy and got it from a github link so far everything is working good, 4K hevc in kodi is fine but for some reason chromium in chrome://gpu says that video decoding isnt accelerated, only webgl stuff

Doing a little digging, From https://patchwork.ozlabs.org/project/uboot/patch/20210822044649.13585-3-samuel@sholland.org/ "Most Allwinner sunxi SoCs have separate boot ROMs in non-secure and secure mode. The "non-secure" or "normal" boot ROM (NBROM) uses the existing sunxi_egon image type. The secure boot ROM (SBROM) uses a completely different image type, known as TOC0." I am not an expert, but I feel that is likely the issue here. Since the X96 s400 will launch the bootrom, it should only require a bootrom change. from https://linux-sunxi.org/TOC0#U-Boot.27s_mkimage It should only need a RSA key generated, as the X96 S400 will launch the sboot, thus no Vendor e-fuse should be set.

The X96_S400_20220610-1210 will error out with: sunxi sprite: toc magic is error need secure image This was from an attempted flash with Phoenixsuite

Oops, I screwed up which Android image works. The X96 image, not x96q will launch uboot during the Phoenixsuit flash, but will not fully complete and will complain it needs secure or something, I'll get logs, the Transpeed atv image will flash and will get stuck not getting past sboot. The images in question: X96_S400_20220610-1210 h313_20230921_atv_Transpeed_2_16_orig I can upload them if it will help.

So, unfortunately all the images that I have tried get stuck in fel mode. I do know the G96 needs secure mode according to debug logs when I was using Phoenixsuit before and is signed in test keys if that helps. The h313_20230921_atv_Transpeed_2_16_orig android image will launch into uboot (I can get into uboot shell via serial) and flash in Phoenixsuit, but will get stuck in sboot upon rebooting and unable to get any farther, so no uboot shell. Armbian-unofficial_25.05.0-trunk_Tanix-tx6s-axp313_bookworm_edge_6.12.11 stuck at fel Armbian-unofficial_25.05.0-trunk_X98h_bookworm_edge_6.12.11_server stuck at fel Armbian-unofficial_25.05.0-trunk_Transpeed-8k618-t_bookworm_edge_6.12.11_server stuck at fel Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server stuck at fel Armbian-unofficial_25.05.0-trunk_X96q-lpddr3-v1-3_bookworm_edge_6.12.11_server also stuck at fel

hi all, pls, is possible to use armbian ueafi-x86 as host for virtualbox? I expect the ubuntu version?? how to install this from cli? recently it seems something was broken on my win11 (after reinstall of new bag of things) or with virtualbox 7.1xx; these were things that worked for years, even with hyper-v on (wsl2), but now, I am writing from armbian, testing old intel nuc10 system booted from sdcard/usb3 (preparing to test new amd machine too) ... virtualbox is quite crucial for some my yold dev things which I can run only in Win2K or Win7; btw, ms copilot was recently quite nice and understanding very tired guy ... https://copilot.microsoft.com/shares/7NhhL6e4MYhkvJC8Grmih Petr

Probably your issue is the proprietary trust os that is shutting the system down in a sort of suspended state

hi, not sure for the sbc, but on uefi-x86, alsa has hdmi audio, but its not loaded for pulseaudio ... ?? here I managed to load it and unmute SPDIF in alsamixer (I still dont understand how devicetree powered SBCs differ against uefi-x86 system ... excuse me) crucial help from Lyra 🙂 ... unmuting SPDIF did the thing, probably also loading the sink also, ufff https://chatgpt.com/share/68836e5f-9e4c-8000-8874-46ea35a07331

wow, the help from chatgpt is in fact quite good ... I now unmuted that SPDIF in alsamixer and tried also to change the pavucontrol configuration profile for something with digital hdmi (but this is NOT necessary ... its all really in the alsamixer unmuting that primary SPDIF - which is reverted to MM with some changes to pavucontrol profile !!) - pavucontroll still shows "headphones" but the audio goes to the hdmi out playing video ... that manual adding of sink to pa probably helped - internal PCI audio shows as "built in audio analog stereo" and the hdmi tv output shows in pa as "builtin audio" ... uff, that audio channels naming ... excuse me, I am linux newbie in this area completelly, may be it was obvious for some, ... quite mess for me but okay, loading module, unmuting spdif ... will see Petr

Those were the days I remember compiling Linux 0.9 something .... it took a day and often nothing worked LOL. In embedded Linux, compiling kernel is nothing unusual, which is the reason why our build framework is focused into making this job easier. For tacking this parameter, you don't need to recompile everything. DTB can be recompiled on a device following by reboot https://www.google.com/search?q=recompile+device+tree+blob Device tree is just a hardware configuration that is provided to the kernel when it boots. This was the only possible related quick, cheap and easy way that I could come up with. Changing the value should have some effect - like (sometimes/always) not detecting PCI when going with weird numbers. More serious debug require a lot more time carefully checking code changes on areas that might have impact alongside with https://www.google.com/search?q=how+to+debug+pci+bus+on+signal+level Which is of course not cheap nor simple.

hi, I have the hdmi issue in uefi-x86 on intel nuc10 minipc - now testing it from fast sandisk microsd in usb3 reader, thats quite fast (after few issues with overheating and slow verbatim and kingston flash keys) this is armbianmonitor output https://paste.armbian.com/jidekuvaza here I tried to ask machine for possible issues and from some detection, it says that my TV is not reporting in EDID any audio?? in windows it works, so may be its something missing? first try to add some forcing to grub didnt helped ... https://chatgpt.com/share/68836e5f-9e4c-8000-8874-46ea35a07331 **** List of PLAYBACK Hardware Devices **** card 0: PCH [HDA Intel PCH], device 0: ALC256 Analog [ALC256 Analog] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [Beyond TV] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 falken@uefi-x86:~$ xrandr --verbose | grep -A20 HDMI subconnector: HDMI supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native link-status: Good supported: Good, Bad CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 CONNECTOR_ID: 99 supported: 99 non-desktop: 0 range: (0, 1) 1920x1200 (0x45) 154.000MHz +HSync -VSync *current +preferred h: width 1920 start 1968 end 2000 total 2080 skew 0 clock 74.04KHz v: height 1200 start 1203 end 1209 total 1235 clock 59.95Hz 1920x1080 (0x46) 148.500MHz -HSync -VSync h: width 1920 start 2008 end 2052 total 2200 skew 0 clock 67.50KHz v: height 1080 start 1084 end 1089 total 1125 clock 60.00Hz 1920x1080 (0x47) 148.500MHz +HSync +VSync h: width 1920 start 2448 end 2492 total 2640 skew 0 clock 56.25KHz v: height 1080 start 1084 end 1089 total 1125 clock 50.00Hz 1680x1050 (0x48) 119.000MHz +HSync -VSync h: width 1680 start 1728 end 1760 total 1840 skew 0 clock 64.67KHz v: height 1050 start 1053 end 1059 total 1080 clock 59.88Hz -- Clones: HDMI-1 CRTC: 1 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: EDID: 00ffffffffffff006318512800000100 141d0103807944780a0dc9a057479827 12484c2108008140a940818081c0a9c0 01010101010108e80030f2705a80b058 8a00b9a84200001e023a801871382d40 582c4500b9a84200001e000000fc0042 65796f6e642054560a202020000000fd 00324b1e503c000a202020202020017d 020367f15261605f6665909f05140413 1221225e625d20320907071517505517 016704033d07c05f7e0183010000e200 cb6e030c002000b84421008001020304 68d85dc40178880702e305e301e20f1b -- subconnector: HDMI supported: Unknown, VGA, DVI-D, HDMI, DP, Wireless, Native link-status: Good supported: Good, Bad CTM: 0 1 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0 1 CONNECTOR_ID: 112 supported: 112 non-desktop: 0 range: (0, 1) 3840x2160 (0x58) 594.000MHz +HSync +VSync +preferred h: width 3840 start 4016 end 4104 total 4400 skew 0 clock 135.00KHz v: height 2160 start 2168 end 2178 total 2250 clock 60.00Hz 4096x2160 (0x59) 594.000MHz +HSync +VSync h: width 4096 start 4184 end 4272 total 4400 skew 0 clock 135.00KHz v: height 2160 start 2168 end 2178 total 2250 clock 60.00Hz 4096x2160 (0x5a) 594.000MHz +HSync +VSync h: width 4096 start 5064 end 5152 total 5280 skew 0 clock 112.50KHz v: height 2160 start 2168 end 2178 total 2250 clock 50.00Hz 4096x2160 (0x5b) 593.407MHz +HSync +VSync h: width 4096 start 4184 end 4272 total 4400 skew 0 clock 134.87KHz v: height 2160 start 2168 end 2178 total 2250 clock 59.94Hz -- HDMI-1 disconnected (normal left inverted right x axis y axis) Identifier: 0x43 Timestamp: 5494311 Subpixel: unknown Clones: DP-2 CRTCs: 0 1 2 Transform: 1.000000 0.000000 0.000000 0.000000 1.000000 0.000000 0.000000 0.000000 1.000000 filter: HDCP Content Type: HDCP Type0 supported: HDCP Type0, HDCP Type1 Content Protection: Undesired supported: Undesired, Desired, Enabled max bpc: 12 range: (8, 12) content type: No Data supported: No Data, Graphics, Photo, Cinema, Game Colorspace: Default supported: Default, SMPTE_170M_YCC, BT709_YCC, XVYCC_601, XVYCC_709, SYCC_601, opYCC_601, opRGB, BT2020_CYCC, BT2020_RGB, BT2020_YCC, DCI-P3_RGB_D65, DCI-P3_RGB_Theater aspect ratio: Automatic

@Igor Thanks for the reply. My last self compiled kernel was probably 25 years ago (with make menu-config etc), so i'm not sure if i went the correct way: * cloned into https://github.com/armbian/build * checked the mentioned patch, bus-scan-delay-ms, although i'm on a rockpi-4a and not rockpro64, and the issue is not in 6.6 but in current (6.12), so i changed the parameter in https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/board-rockpi4-0003-arm64-dts-pcie.patch (not sure if this is the correct place?) * ran ./compile.sh KERNEL_BTF=no BOARD=rockpi-4a BRANCH=current (wanted to make sure and compile the whole kernel, instead of just the dtb) * installed resulting image to another sd and booted == same behaviour with kernel panic. also tried to dpkg -i the dtb deb-file only to the current running minimal armbian where i compiled the kernel with, same issue. * tried the same with BRANCH=edge, same result/issue What i wonder in your suggestion, in the 6.6 patch, the value of ms is the same as in the newer version. Why should this be a possible culprit? Today i'm probably trying to build the 6.6 image and check that against my issue. Thanks for any advise in advance.

Whatever help you can provide know that it is truly appreciated! I will follow your suggestion and try a different kernel and report back my findings, thank you!

I just tested shutting down hostapd and restarting, it works systemctl stop hostapd.service systemctl start hostapd.service system process like hostapd should normally be properly started up and shutdown using systemd, killing the process etc may leave the kernel in inconsistent state. And maybe that's why you observe the issue. this is how I set it up https://gist.github.com/ag88/de02933ba65500376d1ff48e504b1bf3 accordingly, hostapd may require the interface to be on a bridge, I'm not sure about this, but that I'm using a (software) bridge so that the wifi interface is on it. > uname -a Linux orangepizero3a3 6.12.35-current-sunxi64 #1 SMP Fri Jun 27 10:11:46 UTC 2025 aarch64 GNU/Linux > nmcli c NAME UUID TYPE DEVICE bridge a6aa1bb8-c47e-400e-8de1-7faf96489c7a bridge br0 lo 084c74b2-0638-48be-b4c9-364f854ecabd loopback lo br-eth 6bab09b0-e16c-438b-a1bf-e0d82ca5141b ethernet end0 > sudo bridge link 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 master br0 state forwarding priority 32 cost 100 I put both ethernet and wifi on the bridge, wifi is not managed by network manager, hostapd patch that into the bridge. it is possible to just let hostapd setup the bridge in hostapd.conf, and normally that's all needed. this isn't the earliest armbian I'm running hostapd in, i've done it since linux 6.6.x kernel an earlier release some 1 year back or so, no issues.

Maybe some further notes on w.r.t. running HAOS in a VM: As indicated, the process is described for Intel, see https://www.home-assistant.io/installation/alternative For ARM, people have selected RaspberryPi and then ask why it does not work. That is because RPi uses proprietary bootloader (not U-Boot, nor EFI). You need the haos_generic-aarch64 build/image, see https://github.com/home-assistant/operating-system/releases I do not use qcow2, but just a flat img. That is easy to mount as loop device in case some changes are needed to partitions or so. I extracted the .img.xz file and changed the storage (VirtIO Disk) of my existing HA VM to use the new native HAOS instead of my old Debian+supervised_HA. It started without issues and I get to the webpage from where the rest is a standard 'HA getting started', e.g. restore its backup so all devices stats etc are back again. I know many people ask for VMware or Proxmox (or some for VirtualBox), but Linux has anyway all the low-level stuff build-in and a GUI as well: root@rock5b:~# apt install virt-manager virt-manager is already the newest version (1:5.0.0-5). I have this running on ARM64 since Debian Buster 64-bit beta RPi (and 1st early 64-bit Ubuntu server image for RPi4 and also Opensuse Tumbleweed 64-bit) so the commercial ones I dropped long time ago. Above is latest Trixie. Kernel is Armbian vendor currently, but that is only because I want video HW accel (ffmpeg codecs) to work. Otherwise Armbian edge or current offers better stability IMO. Simple tests show that DRAM speed for RK3588 is same or better as for old Intel Core I7, so with also up to 32GB, is great KVM server and desktop same as that old Intel boxes, but 4 Watt idle instead of 40 Watt or so. 40W means about 40 * 9000 is 360 kWh per year, that is 108 Euros per year for my energy contract (30 cents per kWh).

This is the current normal version output: Linux orangepizero3 5.4.125 #1.0.8 SMP Wed Mar 19 23:35:12 CST 2025 aarch64 aarch64 aarch64 GNU/Linux To investigate this issue, I continued to use Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal.img Then uname -a output: Linux orangepizero3 6.12.30-current-sunxi64 #2 SMP Thu May 22 12:29:54 UTC 2025 aarch64 GNU/Linux

The historical archive of armbian orange pi zero 3 seems to have been lost. I am currently using the 5.4 official image.

anything 'interesting' in dmesg? and what is the Armbian / kernel version? e.g. uname -a btw 'real' armbian is currently at linux version 6.12.x https://www.armbian.com/orange-pi-zero-3/ btw I disabled wpa_supplicant when I run hostapd, I'm not sure if it'd affect anything, normally hostapd should work with wpa_supplicant running should be 'no problem'. wpa_supplicant is 'connecting out', while hostapd is an AP hotspot.

It depends on what kind of- and if- HW I/O is used. USB can be redirected. PCI-E can be re-allocated from host to VM when proper IOMMU (HW) is there, that I only go working for Intel PCs, there is interest in it for ARM64, but so far haven't seen anyone got that working. Other typical SBC HW I/O like SPI, 1-wire, GPIO high-low toggle, etc, can not be virtualized, so not available to a VM. Same for video codecs HW accell blocks. Storage and networking, all things typically relevant for enterprise/servers, is no issue.

Has anyone encountered this problem? I reproduced this problem on the 6.1 kernel image, and finally I returned to the 5.4 historical image, and hostapd ran normally.

I tried the following commands, but none of them worked. Only when I rebooted the device did hostapd start correctly. ip link set wlan0 down ip link set wlan0 up rfkill unblock wifi systemctl stop NetworkManager systemctl stop wpa_supplicant

It doesn't work. The wlan0 status is on. I think it's a kernel driver problem.

Welcome / Witaj! Plenty of options for quick and easy start: https://docs.armbian.com/User-Guide_Armbian-Software/ Those small things can do big things