Search the Community

Hello, with the last kernel update I have untimely reboot of my nas. some info : hardware : helios64 os : armbian bullseye based with openmediavault 6 on top kernel : armbian-bsp-cli-helios64-current:arm64 23.8.1 before the update to armbian-bsp-cli 23.8.1 the system have some unexpected restarts, but less than 1 by day. With last version, the system restarts itself sometime only few minutes after the start. With a debug console, I got the following kernel panic : [ 510.791607] Internal error: Oops: 0000000096000044 [#1] PREEMPT SMP [ 510.792174] Modules linked in: xt_nat xt_tcpudp veth xt_conntrack nft_chain_nat xt_MASQUERADE nf_nat nf_conntrack_netlink nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xfrm_user xfrm_algo xt_addrtype nft_compat nf_tables nfnetlink br_netfilter bridge rfkill quota_v2 quota_tree snd_soc_hdmi_codec snd_soc_rockchip_i2s snd_soc_core hantro_vpu rockchip_vdec(C) snd_compress v4l2_vp9 leds_pwm videobuf2_dma_contig rockchip_rga v4l2_h264 videobuf2_dma_sg v4l2_mem2mem videobuf2_memops snd_pcm_dmaengine pwm_fan snd_pcm videobuf2_v4l2 gpio_charger videobuf2_common snd_timer videodev panfrost gpu_sched snd mc drm_shmem_helper rockchip_rng rng_core soundcore fusb302 sg tcpm typec lz4hc lz4 gpio_beeper cpufreq_dt zram softdog ledtrig_netdev lm75 nfsd auth_rpcgss nfs_acl lockd grace sunrpc ip_tables x_tables autofs4 raid10 raid0 multipath linear raid1 dm_raid raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx md_mod dm_mod realtek dwmac_rk stmmac_platform stmmac pcs_xpcs adc_keys [ 510.800061] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G C 6.1.50-current-rockchip64 #3 [ 510.800866] Hardware name: Helios64 (DT) [ 510.801219] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 510.801840] pc : ct_kernel_enter.constprop.0+0xb8/0x180 [ 510.802323] lr : ct_kernel_enter.constprop.0+0xa8/0x180 [ 510.802794] sp : ffff800009eebd80 [ 510.803094] x29: ffff800009eebd80 x28: 0000000000000000 x27: 0000000000000000 [ 510.803739] x26: ffff000000761e00 x25: ffff800009474298 x24: ffff800009a3dc70 [ 510.804382] x23: fffe800100ee71e0 x22: ffff8000097668f0 x21: ffff8000094ea818 [ 510.805023] x20: 0000000000000000 x19: ffff8000097668f0 x18: 0000000000000000 [ 510.805664] x17: 0000000000000000 x16: ffff0000f7765f00 x15: 0000000000000000 [ 510.806306] x14: 0000000000000001 x13: 00000000000001ef x12: 0000000000000001 [ 510.806946] x11: 0000000000000000 x10: 0000000000000a90 x9 : ffff800009eebd50 [ 510.807587] x8 : ffff0000007628f0 x7 : 0000000000000000 x6 : 00000002f5f32d3a [ 510.808228] x5 : 00ffffffffffffff x4 : 0000000000152374 x3 : ffff800009757008 [ 510.808870] x2 : ffff000000761e00 x1 : ffff8000094868b0 x0 : 0000000000000001 [ 510.809510] Call trace: [ 510.809733] ct_kernel_enter.constprop.0+0xb8/0x180 [ 510.810177] ct_idle_exit+0x1c/0x30 [ 510.810498] default_idle_call+0x48/0x17c [ 510.810864] do_idle+0x23c/0x2b0 [ 510.811164] cpu_startup_entry+0x28/0x30 [ 510.811521] secondary_start_kernel+0x124/0x150 [ 510.811934] __secondary_switched+0xb0/0xb4 [ 510.812322] Code: f8605b00 b8606ac4 d503201f d2800020 (f90006e0) [ 510.812868] ---[ end trace 0000000000000000 ]--- [ 510.813283] Kernel panic - not syncing: Attempted to kill the idle task! [ 510.813877] SMP: stopping secondary CPUs [ 510.814234] Kernel Offset: disabled [ 510.814548] CPU features: 0x40000,20834084,0000421b [ 510.814987] Memory Limit: none [ 510.815273] Rebooting in 90 seconds.. Someone have ideas to have this fixed ? Where to report this problem ? Where to have help to get more informations ? Thank you Note : I have some programming skilled (and debugging), but no kernel development experience.

Hello. I decided to build an original image for my Fly Pi board. HDMI output not working. The image is shown only when loading Uboot, and then turns off and a black screen appears. Here are the logs: https://ix.io/4EWM DISPLAY=:0 xrandr output: can't open display :0 X org log: https://paste.debian.net/1290516 I'm confused and don't know what to do...

Hi Folks, this is just out of the blue but Armbian based on Devuan would be very cool. I find more manageable and predictable Devuan than Debian, I am slowing ditching Debian for Devuan, I recently tested both on some very little Linux compatible laptops and Devuan resulted in better compatibility and lesser weird issue with ACPI and LID operations. I use Runit as default init system and for desktop use I found it very stable: for instance when connected to the wifi printer if the printer goes in standby systemd is unable to reconnect to the scanner (you to restart sane) while runit is always on; there are plenty on these little cases where Devuan is out of my way, while I have to constantly checking my son's laptop for what is not working and unavoidable it is always some systemd units failing for unknown reasons. That's my experience, thanks! F.

Hi all, I need to customize the /etc/fstab during the build to mount a mtd partition and also to override some mountpoints with tmpfs in order to reduce wearing on mmc. So, have added the following lines to customize-image.sh: cat <<EOT >> /etc/fstab # Reduce SD wearing by storing log files into ram (no need as overlayroot is used to freeze all the rootfs) tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev 0 0 tmpfs /run tmpfs defaults,noatime,nosuid,nodev 0 0 tmpfs /var/tmp tmpfs defaults,noatime,nosuid,nodev 0 0 tmpfs /var/log tmpfs defaults,noatime,nosuid,nodev,noexec 0 0 tmpfs /var/lib/logrotate tmpfs defaults,noatime,nosuid,nodev,noexec,size=1m,mode=0755 0 0 tmpfs /var/lib/sudo tmpfs defaults,noatime,nosuid,nodev,noexec,size=1m,mode=0700 0 0 # MTD EEPROM memory dev/mtdblock0 /mnt/mtd jffs2 ro,relatime 0 0 EOT However changes in /etc/fstab are overridden somewhere over the build process, and this is the resulting /etc/fstab: UUID=c8167755-b557-4288-9109-9108bc48dd94 / btrfs defaults,noatime,commit=600 0 1 UUID=27ac6cc6-eff3-4736-a7bd-5517e3b150c0 /boot ext4 defaults,commit=600,errors=remount-ro 0 2 tmpfs /tmp tmpfs defaults,nosuid 0 0 Is there a way to safely patch the /etc/fstab file? Thanks very much! Andrea

I'm using the latest WIP config for the NanoPC-T6 build. I've discovered a problem that I don't have using an official FriendlyARM Debian image on the device. I have one HDMI output connected to a dual input screen in desktop mode. It works fine if I select the NanoPC-T6 screen input from the start, but if at a later stage I swap the screen input to a different source and back again, the NanoPC-T6 does not output video. I can ssh to the box but there is nothing obvious in either dmesg or syslog. summary-build-476d3c90-225f-4793-8dbb-01abf490e940.md

Video 1. Checking Jira and GitHub tickets 2. Warming up for Khadas support 3. Changes on Allwinner group management

Video Subtitles What we did? This: 1. Check remaining from Jira tickets https://www.armbian.com/participate/ 2. Review issues https://github.com/armbian/build/issues 3. Review pull requests https://github.com/armbian/build/pulls

Video What we did? This: 1. Check remaining from Jira tickets https://www.armbian.com/participate/ 2. Review issues https://github.com/armbian/build/issues 3. Review pull requests https://github.com/armbian/build/pulls

I made a first round of testing, some manually: khadas edge 2, installed to eMMC, logs: https://paste.armbian.com/iviwutanag bananapi m2+, installed to eMMC, logs: orangepi lite2, logs: https://paste.armbian.com/awicabotod khadas vim1, installed to eMMC, logs: https://paste.armbian.com/ulopiziseb , maintainer needed khadas vim2, installed to eMMC, logs: https://paste.armbian.com/editiyaziv orangepi2e, installed to eMMC, logs: https://paste.armbian.com/ekuyaporil and some via auto-testing machinery. Most of images works: We need to fix Rpi4, Jetson nano, perhaps other media?

Video Summary: Just overview on the status of CI and discussion on known problems regarding upcoming release. We are pretty confident new build framework will be up to the job. On the board support level, still we need to do testing, try to bump boot loader on Allwinner devices, bump rockchip64 current to 6.1.y.

Video 1. Reviewing where we are with CI support 2. Challenges of upcoming release

Video 1. Progress of CI support - build matrix almost work. It could be integrated into production code, but we will do another week of polishing. - we have added on-demand cloud runners action to add additional 128 build runners when needed 2. Security concerns We talked about potential issues and how to improve that. A dedicated person, a CSO volunteer for Armbian project is most welcomed. There are issues in general and GitHub CI specifics, so understanding of those process is needed to understand or learn. @Contributor/Maintainer

Video 1. Progress of CI support https://github.com/armbian/os Changes: - release numbering changed from 23.05 -> 23.5 - we have two separate version configs. One for nightly, one for stable, so its easy to generate a new release. Full or partial - for a single board only. It automatically increment patch number when doing that. - all images are rebuild every run / night on 8 build clusters. - splitting testing related tasks from armbian/os to armbian/ci is planned for future - all currently enabled 3rd party packages are syncing also to stable repository. All those scripts needs to be feed with JSON which is still around a week or two before integration. We checked the progress. 2. Mechanism for rebuilding packages from sources We concluded its better to switch to some existing solution. As this is still a low priority and not needed for upcoming release, main development won't be touching with it within next two months. @Contributor/Maintainer