GeertVc Posted yesterday at 04:52 AM Posted yesterday at 04:52 AM Hi, First post here. I'm fairly new with Armbian. I have a LibreComputer Le Potato that I want to use for Home Assistant. To avoid all the hassle of setting up Home Assistant with docker, I used the Armbian imager to install the Armbian 26.2.1 Home Assistant on an SD card. Once the SD card was flashed, I put it into the Le Potato board. The board starts up fine, asks for the root password, creates a new user and so on. Later on, the Preparing Home Assistant Supervised window appears. However, after the first round to 100% I get a "RTNETLINK answers: Invalid argument" on the screen. The preparation goes on and on, moving the progress bar over and over to 100%. But the installation seems to never stop. See the image attached for the error I get. Anyone any idea? Best, --Geert 0 Quote
GeertVc Posted yesterday at 05:28 AM Author Posted yesterday at 05:28 AM Update: if I wait long enough, then I finally see the Reboot screen. After reboot, I can go to http://<IP_address_Le_Potato>:8123 and I do see the Home Assistant intro screen. After creating an account, giving the location parameters and so on, I finally get the Home Assistant screen. I see in the command terminal that the following containers are available: hassio_observer hassio_supervisor See attached image. However, when I go to Settings, I don't see the Add-ons section. I admit I'm not a Home Assistant expert yet (first steps into HA) but I thought that the superviisor was just to have the Add-ons section available to the user? That's the reason I tried the Armbian Home Assistant image, hoping the Add-ons section would be available. Do I have to make myself a "supervisor" (again, I'm not a Home Assistant expert yet...)? If so, how can this be done? I need MQTT and Zigbee2MQTT, hence the need for the Add-ons section, which I currently don't have... Best, --Geert 0 Quote
eselarm Posted 17 hours ago Posted 17 hours ago 12 hours ago, GeertVc said: However, when I go to Settings, I don't see the Add-ons section. I have the same on my 2 year old HA Supervised install I did once on a Debian Bookworm installation (Aarch64). I actually first did the same as you, not on a real HW Lepotato SBC, but as a KVM QEMU U-Boot. One only needs to change boot.scr in the (Amlogic) image, the kernel runs on virtio devices. I can confirm the 15-min waiting, or longer, I haven't looked at it, is a bit strange, but it magically still works this Supuervised. I did restore a backup from my Debian HA install, so very little effort. But it shows as problem that the OS is unsupported and also unsupported install method. The later is known and on HA Wiki/docs, supervised it not mentioned anymore, only the own HAOS en Container. I think 'Add-ons' are now called 'Apps' and also Container does not seem to support it. So for MQTT I anyhow have mosquito as Debian package installed. But teh Zigbee bridge is then a showstopper I see / I think. But also check yourself. I have no ZigBee HW and also HA is only testing for mee, see it it does things better than my current home automation softwares (mostly Node-RED based). The only option I see then is to put HAOS as KVM on Lepotato. It is 4x Cortex-A53 I see, so it can work. But not sure how RAM will work out. If 1GB RAM, then maybe 512M host and 512M guest. I have done that on RPI3 to run a router instance using VLANs. 0 Quote
eselarm Posted 3 hours ago Posted 3 hours ago (edited) I changed allocated RAM for the virtual machine from 2G to 1G, still 4x Cortex-A55 vCPUs from RK3588 ROCK5B yesterday. At reboot and first login, it showed on 2 container, while earlier it showed a lot more. So now manual stats: root@lepotato:/etc/update-motd.d# ./10-armbian-header ; ./15-ap-info ; ./25-containers-info ; ./30-armbian-sysinfo _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v26.2.1 for Le potato running Armbian Linux 6.18.10-current-meson64 Packages: Debian stable (trixie) Containers: hassio_multicast, hassio_audio, hassio_dns, hassio_cli, homeassistant, hassio_observer, hassio_supervisor Performance: Load: 5% Uptime: 12h 18m Memory usage: 64% of 975M Zram usage: 56% of 487M Usage of /: 79% of 7.8G RX today: 54 MiB Only thing it really does is showing energy page, is 4x 10s sampled data (2x solar and power and delivery). Various Tasmota modules via MQTT don't claim that much resources I think. But strange is a rather constant regular dmesg like this: [44265.955953] hassio: port 2(vethf224414) entered disabled state [44265.957193] vethed7ef10: renamed from eth1 [44266.109287] hassio: port 2(vethf224414) entered disabled state [44266.116189] vethf224414 (unregistering): left allmulticast mode [44266.116262] vethf224414 (unregistering): left promiscuous mode [44266.116357] hassio: port 2(vethf224414) entered disabled state [44266.186986] docker0: port 1(veth76765bf) entered disabled state [44266.187218] veth1a28eaf: renamed from eth0 [44266.285174] docker0: port 1(veth76765bf) entered disabled state [44266.292147] veth76765bf (unregistering): left allmulticast mode [44266.292219] veth76765bf (unregistering): left promiscuous mode [44266.292256] docker0: port 1(veth76765bf) entered disabled state [44268.119635] docker0: port 1(veth51c04e7) entered blocking state [44268.119726] docker0: port 1(veth51c04e7) entered disabled state [44268.119797] veth51c04e7: entered allmulticast mode [44268.120352] veth51c04e7: entered promiscuous mode [44268.245380] eth0: renamed from veth916ebeb [44268.251728] docker0: port 1(veth51c04e7) entered blocking state [44268.251798] docker0: port 1(veth51c04e7) entered forwarding state [44268.384290] hassio: port 2(vethaf9bc59) entered blocking state [44268.384376] hassio: port 2(vethaf9bc59) entered disabled state [44268.384423] vethaf9bc59: entered allmulticast mode [44268.384986] vethaf9bc59: entered promiscuous mode [44268.513343] eth1: renamed from veth48fb602 [44268.520780] hassio: port 2(vethaf9bc59) entered blocking state [44268.520872] hassio: port 2(vethaf9bc59) entered forwarding state [44274.819685] audit: type=1400 audit(1784532963.305:477): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor" pid=35485 comm="apparmor_parser" [44274.819758] audit: type=1400 audit(1784532963.305:478): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor///usr/bin/gdbus" pid=35485 comm="apparmor_parser" [44274.819829] audit: type=1400 audit(1784532963.305:479): apparmor="STATUS" operation="profile_replace" info="same as current profile, skipping" profile="unconfined" name="hassio-supervisor///usr/bin/git" pid= Maybe that is because the minimal KVM QEMU arguments: if ! test -f /usr/lib/u-boot/qemu_arm64/u-boot.bin ; then apt install u-boot-qemu fi cd /local/s0/vmimg taskset --cpu-list 0-3 qemu-system-aarch64 -M virt -cpu host -enable-kvm -m 1024 -smp 4 \ -bios /usr/lib/u-boot/qemu_arm64/u-boot.bin \ -drive if=none,file=armimg.img,format=raw,id=hd0 \ -device virtio-blk-device,drive=hd0 \ -netdev bridge,id=hn1 -device virtio-net,netdev=hn1 \ -nographic I think I will further limit to 512M and see if it still works; My older own HA Supervised used Btrfs as rootfs (compress-force=zstd:3 mount option), for this fake/KVM lepotato still Ext4 and I did: truncate -s8G armimg.img before 1st boot. For reference, I initially did change boot.cm/boot.scr to something rather static I had done long time ago for virtualizing ROCK3A, but it is more effective if this extlinux method is added to the image (need loopmount it before 1st boot, it assumes extlinux overrides boot.scr method): root@lepotato:/boot# cat extlinux/extlinux.conf menu title Select the kernel variant DEFAULT default TIMEOUT 80 LABEL default KERNEL /boot/Image INITRD /boot/uInitrd APPEND root=LABEL=armbi_root rootwait rw earlyprintk loglevel=7 Edited 3 hours ago by eselarm 0 Quote
eselarm Posted 3 hours ago Posted 3 hours ago (edited) 512M seems too low: [ 70.791346] containerd: page allocation failure: order:1, mode:0x40820(GFP_ATOMIC|__GFP_COMP), nodemask=(null),cpuset=containerd.service,mems_allowed=0 [ 70.791404] CPU: 1 UID: 0 PID: 1727 Comm: containerd Not tainted 6.18.10-current-meson64 #1 PREEMPT [ 70.791410] Hardware name: linux,dummy-virt (DT) [ 70.791414] Call trace: [ 70.791417] show_stack+0x20/0x38 (C) [ 70.791427] dump_stack_lvl+0x74/0x90 [ 70.791436] dump_stack+0x18/0x28 [ 70.791441] warn_alloc+0x134/0x1c0 [ 70.791449] __alloc_frozen_pages_noprof+0x780/0xe70 [ 70.791457] alloc_pages_mpol+0xbc/0x1c8 [ 70.791463] alloc_frozen_pages_noprof+0x50/0xd0 [ 70.791468] new_slab+0x2ec/0x3a8 [ 70.791474] ___slab_alloc+0x654/0xbb8 [ 70.791480] __slab_alloc.isra.0+0x50/0xa8 [ 70.791485] __kmalloc_noprof+0x410/0x638 [ 70.791491] virtqueue_add_sgs+0x2e4/0x6d0 [ 70.791499] virtblk_add_req+0xb8/0x130 [ 70.791507] virtio_queue_rq+0x80/0x208 [ 70.791513] blk_mq_dispatch_rq_list+0x104/0x6f0 [ 70.791521] __blk_mq_sched_dispatch_requests+0x45c/0x570 [ 70.791527] blk_mq_sched_dispatch_requests+0x38/0x88 [ 70.791532] blk_mq_run_hw_queue+0x25c/0x2d0 [ 70.791538] blk_mq_dispatch_list+0x110/0x420 [ 70.791545] blk_mq_flush_plug_list+0x5c/0x190 [ 70.791551] __blk_flush_plug+0xf0/0x158 [ 70.791559] blk_finish_plug+0x40/0x60 [ 70.791565] read_pages+0x130/0x2c8 [ 70.791573] page_cache_ra_unbounded+0x1e4/0x300 [ 70.791580] page_cache_ra_order+0x41c/0x488 [ 70.791586] filemap_fault+0x5d8/0xb68 [ 70.791592] __do_fault+0x44/0x240 [ 70.791599] __handle_mm_fault+0x9e4/0x18a0 [ 70.791604] handle_mm_fault+0x194/0x2e0 [ 70.791609] do_page_fault+0x110/0x6f8 [ 70.791616] do_translation_fault+0x54/0x80 [ 70.791623] do_mem_abort+0x4c/0xa8 [ 70.791630] el0_ia+0x50/0xd0 [ 70.791637] el0t_64_sync_handler+0xe0/0xe8 [ 70.791644] el0t_64_sync+0x198/0x1a0 [ 70.791650] Mem-Info: [ 70.791832] active_anon:11944 inactive_anon:39978 isolated_anon:0 [ 70.791832] active_file:11107 inactive_file:13422 isolated_file:0 [ 70.791832] unevictable:0 dirty:0 writeback:8 [ 70.791832] slab_reclaimable:5622 slab_unreclaimable:10672 [ 70.791832] mapped:6999 shmem:423 pagetables:2117 [ 70.791832] sec_pagetables:0 bounce:0 [ 70.791832] kernel_misc_reclaimable:0 [ 70.791832] free:912 free_pcp:426 free_cma:29 [ 70.791874] Node 0 active_anon:47776kB inactive_anon:159912kB active_file:44428kB inactive_file:53688kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:27996kB dirty:0kB writeback:32kB shmem:1692kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB kernel_stack:6016kB pagetables:8468kB sec_pagetables:0kB all_unreclaimable? no Balloon:0kB [ 70.791907] Node 0 DMA free:3648kB boost:4096kB min:6768kB low:7436kB high:8104kB reserved_highatomic:2048KB free_highatomic:56KB active_anon:47776kB inactive_anon:159912kB active_file:44428kB inactive_file:53460kB unevictable:0kB writepending:32kB zspages:76228kB present:524288kB managed:484516kB mlocked:0kB bounce:0kB free_pcp:1960kB local_pcp:908kB free_cma:116kB [ 70.791945] lowmem_reserve[]: 0 0 0 0 [ 70.791963] Node 0 DMA: 276*4kB (MEC) 54*8kB (MEH) 90*16kB (MEH) 20*32kB (UE) 2*64kB (U) 0*128kB 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4000kB [ 70.792025] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 70.792038] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ 70.792051] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 70.792063] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ 70.792076] 24919 total pagecache pages [ 70.792084] 33 pages in swap cache [ 70.792091] Free swap = 184kB [ 70.792098] Total swap = 242256kB [ 70.792105] 131072 pages RAM [ 70.792112] 0 pages HighMem/MovableOnly [ 70.792119] 9943 pages reserved [ 70.792126] 32768 pages cma reserved [ 70.792133] 0 pages hwpoisoned [ 70.792140] SLUB: Unable to allocate memory on CPU 1 (of node 0) on node -1, gfp=0x820(GFP_ATOMIC) [ 70.792154] cache: kmalloc-8k, object size: 8192, buffer size: 8192, default order: 3, min order: 1 [ 70.792168] node 0: slabs: 29, objs: 116, free: 0 ... and many OOM killer actions to follow, but could type: poweroff It might be that is no zram swap and swap on disk, that is could work, but from some earlier HA topic here I remember that was a swapping hell on a 4-core Cortex-A53 and SD-card, way too slow. My KVM is image on NVME on ROCK5B, so fastest available more or less for 'cheap' ARM64 SBC. To compare: Domoticz did run OK with about the same amount of objects on a NanoPi-NEO (4x Cortex-A7, 512MiB, SD-card). It still does, but I moved most objects to a 2x Cortex-A55 1G RAM (KVM on same ROCK5B). # free -m total used free shared buff/cache available Mem: 963 330 77 2 635 632 Swap: 981 45 936 BUT I see also something with 'containers' when ZigBee in my google search. I would maybe see what exactly is needed. After many years, I also figured out that my 433MHz transceiver internally is just a 38k4 serial thing tied to an serial-to-USB chip. It was driven as serial port by Domoticz via USBIP on that NanoPi-NEO, but that needs explicit sync/reconnect actions at reboot. Now done via ser2net, swapping/replacing the device from serial to LAN in Domoticz, same database history, no actions at reboot/powercycle and with ser2net point-to-multipoint, also also available to multiple softwares in the home LAN or VPN etc if needed. Of course respecting write/send operations to be exclusive, just one. Same ser2net trick with electricity meter, that is why I can easily run HA/HAOS simultaneously with my normal home automation software stuff. Edited 3 hours ago by eselarm 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.