Dietpi: Inconsistent WiFi init connect (asus tb)

Created on 31 Jan 2018  路  15Comments  路  Source: MichaIng/DietPi

Workaround/Fix: https://github.com/Fourdee/DietPi/issues/1444#issuecomment-362385108


Required Information:

  • DietPi Version v6.1
  • SBC Device ASUS TB v1.2
  • Power supply used 5V 3.0A
  • SD card used SanDisk Ultra 16GB
  • Distro DietPi v6.0 / Standard Kernel

Expected behaviour:

First boot sequence should boot up and initialiaze the wlan0 to static like in dietpi.txt it is set.

Actual behaviour:

First boot runs well with configured dietpi.txt; after initial boot up and update the wlan0 will never come back when on v6.1 .

Steps to reproduce:

Configure dietpi.txt for wlan0 only and disable eth0
Insert needed credentials for WLAN router
Boot up device and wait until all updates are complete.
Reboot

NO WLAN0 will be available even if you set it up per dietpi-config, as there will be an issuer with "power-management" service or whatever... too fast to read or see.

Fresh install of untouched dietpi.txt will return same error even on fresh and unused SD-Card.

Did you submit a dietpi-bugreport?

not possible as system not available via SSH nor copy&paste works after.

ASUS Tinker Board Kernel related Known Issue Solution available

Most helpful comment

@Fourdee Horray... this version works oob. No Problems anymore!

root@DietPiTB:~# uname -a
Linux DietPiTB 4.4.16-00006-g4431f98-dirty #1 SMP Mon Apr 17 17:27:25 CST 2017 armv7l GNU/Linux

SOLVED: The issue is the kernel of 2.0.4. Now everything works.

All 15 comments

UPDATE: the service which will never start up is called "device-voltage".service or similar... (FYI)

with the v6-1 from begininng no problem at all .... only after it! It seems like the drivers being loaded may be causing the problem, but than the driver is doing some mess after the reboot.

No way around it atm.

At least the kernel seems to be the issue at least.

latest distro from: today = not working

聽 | DietPi_ASUSTB-ARMv7-Stretch.7z | 31-Jan-2018 19:40 | 70M | 聽
-- | -- | -- | -- | --

Anyone could help at this?

@SuBLiNeR

Thanks for the report, we'll try to replicate 馃憤

Notes:

  • Confirmed on initial boot
  • Strange, worked on 2nd attempt.
  • Failed after reboot/update
  • 馃埡 voltage-detect fails due to python not being installed by default in DietPi. All this does is detect low voltage on MicroUSB (4.65V <). Not critical to device operation and/or WiFi, as long as sufficient PSU used.
  • Subsequent reboots, 1/5 WiFi is fine.
  • In non-functional state, ifup/down fails, no errors in dmesg or anything useful to debug.
  • Scan always works, but fails to connect.
  • Modprobe/reset of 8723bs offers no solution.

Flaky WiFi driver in latest kernel?

Putting this down to a possible Kernel/driver issue of 8723bs (https://github.com/Fourdee/DietPi/issues/1444#issuecomment-362278083), other devices are fine.

@Fourdee So it looks like it must have something to do with the kernel as i expected. Which kernel was being used than? Didn't you used the latest available from TinkerOS or from DEBIAN ?
Latest one should be implemented and working from TinkerOS 2.0.4 or 1.8.

Suggestion: I'm running now TinkerOS from command line and everything works fine so far. I'll now tryin' the PREP-script from your git. Let's see if this works.
Kernel is atm: Linux Tinkerboard 4.4.71+

@SuBLiNeR

Did you use the latest available from TinkerOS or from DEBIAN

Correct 2.0.4

I believe the previous image we used would of been: 1.8. We need to test PREP with 1.8 to verify working WiFi and in-turn kernel cause.

@Fourdee Currently running the PREP-Script over 2.0.4 .
Let's see if afterwards it runs well, if not are there any chances to get maybe back to v158/159, so others could still enjoy DietPi?? At the current state the v6.0 should be taken down for ASUS-TB, shouldn't it?

UPDATE:Script fails at last part while trying to fetch files. :( Trying now with 1.8 as i guess the kernel is 2.0.4 is being fu....ed.

@SuBLiNeR

Let's see if afterwards it runs well, if not are there any chances to get maybe back to v158/159, so others could still enjoy DietPi?? At the current state the v6.0 should be taken down for ASUS-TB, shouldn't it?

TinkerOS v1.8 is fine, 10 reboots, WiFi always up.

Does suggest kernel issue, however, there could be image specific WiFi changes done by tinkerOS in v2.0.4, that we are either not aware of, breaking its functionality.
Unable to find any additional custom services in v2.0.4, that may be a factor.

Options:

  • Revert our image to tinker OS v1.8 PREP built
  • To 100% verify kernel issue, copy kernel from v1.8 image to our v2.0.4 built image and retest.

v1.8 K:

root@DietPi:~# uname -a
Linux DietPi 4.4.16-00006-g4431f98-dirty #1 SMP Mon Apr 17 17:27:25 CST 2017 armv7l GNU/Linux

v2.0.4 K:

4.4.71+

@Fourdee that what i'm suggesting to do now.... let's see... not 100% sure about it'll work...

How do i copy kernel from v1.8 to dietpi if the Prep script fails again? Simply copying kernel.img from 1.8 to DietPi v6 ?

@SuBLiNeR

How do i copy kernel from v1.8 to dietpi if the Prep script fails again?

Remove these folders/files from current DietPi tinker OS v2.0.4 image, then copy the contents from the tinker OS v1.8 image

#folders
/lib/modules
/boot/extlinux

#files
/boot/hw_intf.conf
/boot/rk3288-miniarm.dtb
/boot/zImage

Ok, i'll mark this as known issue, I'd prefer to keep the v2.0.4 based image as default with latest kernel. We'll offer a v1.8 based image as alternative for WiFi users.

Okay, even copying the 1.8 kernels doesn't work. Trying now Prep-script on TinkerOS 1.8

Alternativ: Reupload v.158 which works for TB...

btw. even eth0 stops working with v 6.0 somehow... stranged...

@SuBLiNeR

Please try:
http://dietpi.com/downloads/images/NR/NR_DietPi_ASUSTB-ARMv7-Stretch.7z

1.8 tinker OS based. I've tested success with static IP in dietpi.txt and wifi, running fine subsequent reboots. Please let us know results.

@Fourdee Horray... this version works oob. No Problems anymore!

root@DietPiTB:~# uname -a
Linux DietPiTB 4.4.16-00006-g4431f98-dirty #1 SMP Mon Apr 17 17:27:25 CST 2017 armv7l GNU/Linux

SOLVED: The issue is the kernel of 2.0.4. Now everything works.

@SuBLiNeR

Excellent, thanks for verifying 馃憤 . I'll mark this as closed.

Note to self:

  • If we get multiple reports of same issue, swap default image.
Was this page helpful?
0 / 5 - 0 ratings