Lost network hardware and battery awareness with Manjaro Sway and Kde on PinebookPro

After most recent update with Manjaro Sway testing on sd card on pinebookpro, I lost hardware availability of my wifi card and awareness of my battery. I can run the laptop unplugged, but waybar fails on finding both the wifi and battery. Neither a wifi dongle or usb/ethernet works to establish network connection or are even detected as viable network devices. Checked physical switches and this appears unrelated unless the led indicators are not connected to the physical switch. ip a returns only loopback and no network hardware. Booting manj kde on emmc has the same issue so I’m not sure if it’s kernel or firmware related.

inxi shows

Network: No Arm data found for this feature

usb appears powered, but does not detect any devices including storage.

strike that last reply. It just wasn’t happy with the file formats on a few of my old usb drives. Here is the inxi -Faz output (y throws an error that 0 cannot be passed)

System:    Host: bilbo Kernel: 5.8.3-2-MANJARO-ARM aarch64 bits: 64 
           parameters: console=tty1 console=ttyS2,1500000 root=LABEL=ROOT_MNJRO rw rootwait 
           bootsplash.bootfile=bootsplash-themes/manjaro/bootsplash earlycon=uart8250,mmio32,0xff1a0000 
           Desktop: sway 1.5 Distro: Manjaro ARM 
Machine:   Type: ARM Device System: Pine64 Pinebook Pro details: N/A serial: <filter> 
CPU:       Topology: 6-Core (2-Die) model: N/A variant-1: cortex-a72 variant-2: cortex-a53 bits: 64 type: MCP MCM family: 8 
           model-id: N/A stepping: 4 microcode: N/A 
           Speed: 1008 MHz min/max: 408/1416:2000 MHz Core speeds (MHz): 1: 408 2: 408 3: 408 4: 408 5: 1008 6: 1008 
           Vulnerabilities: Type: itlb_multihit status: Not affected 
           Type: l1tf status: Not affected 
           Type: mds status: Not affected 
           Type: meltdown status: Not affected 
           Type: spec_store_bypass status: Vulnerable 
           Type: spectre_v1 mitigation: __user pointer sanitization 
           Type: spectre_v2 status: Vulnerable 
           Type: srbds status: Not affected 
           Type: tsx_async_abort status: Not affected 
Graphics:  Device-1: display-subsystem driver: rockchip_drm v: N/A 
           Device-2: rk3399-mali driver: N/A 
           Display: server: X.Org 1.20.9 driver: N/A tty: N/A 
           Message: Unable to show advanced data. Required tool glxinfo missing. 
Audio:     Device-1: simple-audio-card driver: N/A 
           Device-2: simple-audio-card driver: N/A 
           Sound Server: ALSA v: k5.8.3-2-MANJARO-ARM 
Network:   Message: No ARM data found for this feature. 
Drives:    Local Storage: total: 116.62 GiB used: 6.94 GiB (6.0%) 
           ID-1: /dev/mmcblk1 model: LX64G size: 58.37 GiB block size: physical: 512 B logical: 512 B 
           ID-2: /dev/mmcblk2 model: DA4064 size: 58.24 GiB block size: physical: 512 B logical: 512 B 
Partition: ID-1: / raw size: 58.14 GiB size: 56.97 GiB (98.00%) used: 6.88 GiB (12.1%) fs: ext4 dev: /dev/mmcblk1p2 
           ID-2: /boot raw size: 213.6 MiB size: 213.4 MiB (99.89%) used: 70.0 MiB (32.8%) fs: vfat dev: /dev/mmcblk2p1 
Sensors:   Message: No sensors data was found. Is sensors configured? 
Info:      Processes: 177 Uptime: 1m Memory: 3.71 GiB used: 322.9 MiB (8.5%) Shell: bash inxi: 3.0.37

everything is fine on a fresh 20.0.8 manjaro sway image from sd card

1 Like

My best guess: could be either a kernel or uboot problem.

Looks like your root filesystem is from the SD card but the eMMC boot partition is mounted at /boot. This happens because fstab points to LABEL=BOOT_MNJRO and that label exists on both the SD card and the eMMC. If a kernel update is installed in this condition, the kernel and modules get written to the eMMC boot partition and are not actually used during the SD card boot.

You could prevent problems by changing the file system label to be unique or use UUID in fstab.

I had a similar thing happen but it resulted in boot to black screen in both eMMC and SD card installs. I think changing the fstab to use UUID could help solve many of these “update broke…” problems that are hard to diagnose.


nice catch. I had a different issue with the duplicate labels early on when I was trying to get sway to boot from sd. It is confusing.

1 Like