DietPi-Config | Remove 'green LED' form LED Control for H3 devices

[k-plan]

http://dietpi.com/phpbb/viewtopic.php?f=11&t=2473&p=9685#p9683

for 3.x Kernels with Jessie on H3 devices (NanoPi Neo, NanoPi Air, OrangePi One, ...)

Perhaps it will be possible to do this by $HW_MODE in /DietPi/dietpi/func/dietpi-led_control because blue/red led trigger is working in 3.x Kernel for now.

With Mainline kernel images things have changed and will to-be develop.

[Fourdee]

@k-plan

Thanks 👍

In DietPi LED control, we pull the available LED options and their current values directly from kernel.
Once the current values are stored, they get applied during boot.

update-initramfs: Generating /boot/initrd.img-3.4.113-sun8i
Then issue occurs

I believe in Gordons case, a kernel update has changed the available LED options/layout, causing the existing DietPi LED control settings to be "not as expected".

Quick solution, remove the DietPi LED existing settings:

rm /DietPi/dietpi/.dietpi-led_control
reboot

LED's will now revert to default, and DietPi LED control will match during boot.

[k-plan]

@Fourdee

hmm ... same behaviour with my NanoPi Neo here.

Yes, I have started from scratch with last DietPi_v145_NanoPiNEO-armv7-(Jessie).img from Feb-2017 and update to Kernel Linux NanoPi-Neo 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l during first boot up with:

http://dietpi.com/phpbb/viewtopic.php?f=11&t=2488

But I will test it ...

root@NanoPi-Neo:~# cat /DietPi/dietpi/.dietpi-led_control
blue_led mmc0
green_led heartbeat

root@NanoPi-Neo:~# rm /DietPi/dietpi/.dietpi-led_control

root@NanoPi-Neo:~# ls -lah /DietPi/dietpi/.dietpi-
.dietpi-autostart_index  
.dietpi-process_tool
.dietpi-backup_settings  
.dietpi-survey

root@NanoPi-Neo:~# reboot

But now you have to wait, until getting back at home and have a look at the leds on boot. :smile:

Will give you a check-back indication.

Thanks for your super quick help! :+1:

cu
k-plan

[k-plan]

@Fourdee

check-back indication:

root@NanoPi-Neo:~# reboot

Power On => boot, green goes ON => then blinking 10x times (means ‘ready to login’ = [heartbeat] for about 10 sec.) => then ON.

root@NanoPi-Neo:~# cat /DietPi/dietpi/.dietpi-led_control
blue_led mmc0
green_led heartbeat

root@NanoPi-Neo:~# cat /sys/class/leds/green_led/trigger
none mmc0 timer heartbeat backlight [default-on]

Double check it with OrangePi One:

───────────────────────────────────────
 DietPi     | 12:30 | Sat 25/11/17
 ───────────────────────────────────────
 V158       | OrangePi One (armv7l)
 ───────────────────────────────────────

root@OrangePi-One:~# uname -a
Linux OrangePi-One 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l GNU/Linux

root@OrangePi-One:~# cat /DietPi/dietpi/.dietpi-led_control
green_led heartbeat
red_led mmc0

root@OrangePi-One:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer [heartbeat] backlight default-on

root@OrangePi-One:~# rm /DietPi/dietpi/.dietpi-led_control

root@OrangePi-One:~# reboot

Power On => boot, green goes ON => then blinking 10x times (means ‘ready to login’ = [heartbeat] for about 10 sec.) => then ON.

root@OrangePi-One:~# cat /DietPi/dietpi/.dietpi-led_control
green_led heartbeat
red_led mmc0

root@OrangePi-One:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer heartbeat backlight [default-on]

In DietPi LED control, we pull the available LED options and their current values directly from kernel.

Hmm ... this can be '_part-of-the-problem_' because it depends on timing, when this is be done.
With my humble skill, I can't find this.

A "_work-around_" is this in /etc/rc.local :

#### switch on GREEN LED for heartbeat activity
sleep 10
echo 1 >/sys/class/leds/green_led/brightness
echo heartbeat >/sys/class/leds/green_led/trigger

But, I think, to remove this option is a cleaner/easier/quicker way or you possible fix it, if you think it's worth time and effort.

_PS: - May I change the lable to bug?_ 😉 🙊 😃

[Fourdee]

@k-plan

> root@OrangePi-One:~# cat /DietPi/dietpi/.dietpi-led_control
green_led heartbeat
red_led mmc0
root@OrangePi-One:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer heartbeat backlight [default-on]

DietPi-LED_Control looks correct, something else is changing the value during boot, and after DietPi LED control is run.

What happens if you reapply DietPi LED control manually?

/DietPi/dietpi/func/dietpi-led_control 1

[k-plan]

What happens if you reapply DietPi LED control manually?

root@NanoPi-Neo:~# reboot

Power On => boot, green goes ON => then blinking 10x times (means ‘ready to login’ = [heartbeat] for about 10 sec.) => then ON.

root@NanoPi-Neo:~# cat /DietPi/dietpi/.dietpi-led_control
blue_led mmc0
green_led heartbeat

root@NanoPi-Neo:~# cat /sys/class/leds/green_led/trigger
none mmc0 timer heartbeat backlight [default-on]

root@NanoPi-Neo:~# /DietPi/dietpi/func/dietpi-led_control 1


 DietPi-LED_Control
──────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] blue_led: mmc0
 [Ok] green_led: heartbeat


root@NanoPi-Neo:~# cat /sys/class/leds/green_led/trigger
none mmc0 timer [heartbeat] backlight default-on

root@NanoPi-Neo:~# reboot

... and clearance will starting similarly from scratch.

... something else is changing the value during boot, and after DietPi LED control is run.

Yes!

Armbian Documentation

Allwinner H3 boards

Default settings

_Armbian unlike older/other H3 OS images uses the green led as ‘power on’ indicator (blinking means ‘ready to login’ or ‘shutting down’), the red led (blue on NanoPis) can be used for your own purpose._

https://docs.armbian.com/Hardware_Allwinner-H3/#allwinner-h3-boards

... or is coded into kernel. Will test it.

[k-plan]

@Fourdee

No different behave in all different kernels.

• Linux 3.4.113-sun8i #10 SMP PREEMPT Thu Feb 23 19:55:00 CET 2017 armv7l GNU/Linux

• Linux 3.4.113-sun8i #18 SMP PREEMPT Thu Jun 15 02:16:06 CEST 2017 armv7l GNU/Linux

• Linux 3.4.113-sun8i #4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux

_BUT ..._
_(have to use OrangePi One, because NanoPi is in business)_

---

_System Defaults (after fresh installation):_

root@OPi-1_LED-TEST:~# cat /DietPi/dietpi/.dietpi-led_control
green_led default-on
red_led heartbeat


root@OPi-1_LED-TEST:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer heartbeat backlight [default-on]

root@OPi-1_LED-TEST:~# reboot

_Power On => boot, green goes ON => then blinking 2-3x times (means ‘ready to login’ = [heartbeat] for about 3 sec.) => then ON._

---

DietPi-LED_Control
─────────────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] green_led: default-on
 [Ok] red_led: heartbeat

 DietPi-LED_Control
─────────────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] green_led: default-on
 [Ok] red_led: mmc0

root@OPi-1_LED-TEST:~# cat /DietPi/dietpi/.dietpi-led_control
green_led default-on
red_led mmc0

root@OPi-1_LED-TEST:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer heartbeat backlight [default-on]

root@OPi-1_LED-TEST:~# reboot

_Power On => boot, green goes ON => then blinking 2-3x times (means ‘ready to login’ = [heartbeat] for about 3 sec.) => then ON._

---

DietPi-LED_Control
─────────────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] green_led: default-on
 [Ok] red_led: mmc0

 DietPi-LED_Control
─────────────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] green_led: heartbeat
 [Ok] red_led: mmc0

root@OPi-1_LED-TEST:~# cat /DietPi/dietpi/.dietpi-led_control
green_led heartbeat
red_led mmc0

root@OPi-1_LED-TEST:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer [heartbeat] backlight default-on

root@OPi-1_LED-TEST:~# reboot

_Power On => boot, green goes ON => then blinking 10-12x times (means ‘ready to login’ = [heartbeat] for about 10 sec.) => then ON._

---

_Let's check:_

root@OPi-1_LED-TEST:~# cat /DietPi/dietpi/.dietpi-led_control
green_led heartbeat
red_led mmc0

root@OPi-1_LED-TEST:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer heartbeat backlight [default-on]

_Let's cross-check:_

 DietPi-LED_Control
─────────────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] green_led: heartbeat
 [Ok] red_led: mmc0

 DietPi-LED_Control
─────────────────────────────────────────────────────
 Mode: Applying LED triggers
 Please wait...

 [Ok] green_led: mmc0
 [Ok] red_led: heartbeat

root@OPi-1_LED-TEST:~# cat /DietPi/dietpi/.dietpi-led_control
green_led mmc0
red_led heartbeat

root@OPi-1_LED-TEST:~# cat /sys/class/leds/green_led/trigger
none [mmc0] mmc1 timer heartbeat backlight default-on

root@OPi-1_LED-TEST:~# reboot

_Power On => boot, green goes ON => then blinking 2-3x times (means ‘ready to login’ = [heartbeat] for about 3 sec.) => then about 6-7 sec. blinking showing sd card activity => then ON._

---

_Let's double check:_

root@OPi-1_LED-TEST:~# cat /DietPi/dietpi/.dietpi-led_control
green_led mmc0
red_led heartbeat

root@OPi-1_LED-TEST:~# cat /sys/class/leds/green_led/trigger
none mmc0 mmc1 timer heartbeat backlight [default-on]

---

_Conclusion:_

• Don't touch trigger setting of green_led !

---

---

BTW:

• I personaly only use blue/red_led: mmc0 because _green_led heartbeat_ , if it will work by my dirty hack, gives me the willies.
  And I love ‘ready to login’ indicator. It's not the sense, but now we have the option to switch it between 3 or 10 secends. 🙈 😄

---

PS:

• While fiddeling around with the hole bunch of kernels, versions and patches, I notice something is going wrong with a patch in a former version, which uninstall pci-tools.
  After this, each time apt-get upgrade showing:

Calculating upgrade... The following package was automatically installed and is no longer required:
  libpci3
Use 'apt-get autoremove' to remove it.

Easy to fix, but can novice make twitchy.

And using the last images from beginning of 2017 is a pain in the a...
Creating two time 2GB swap files and updating 15 version is really time-killing and not Lightweight justice.
Yes, I have noticed, you are on Media Systems trip and focus on Strech. It's okay. 😃

[Fourdee]

@k-plan

Don't touch trigger setting of green_led !

👍 The LED control relies on solely the available kernel options and their stability. Theres even a few LED options available on RPi, that have no effect.

And using the last images from beginning of 2017 is a pain in the a...

Yep, i'll update them when I can. Extremely time consuming to update all our images.
I'll tweak the patch file now to only generate 1 swapfile :)

and focus on Strech

Yep, glad we started this early, but still much to do to ensure stable experience, especially for RPi.

[k-plan]

@Fourdee

The LED control relies on solely the available kernel options and their stability. Theres even a few LED options available on RPi, that have no effect.

Yes, I have notice this as well. But nobody have claim this so stiff-necked before. :see_no_evil:
Shall I make a new issue for this? :speak_no_evil: No, no, only joking. :smile:

Will you put H3 green_led options into rubbish bin?

Yep, i'll update them when I can. Extremely time consuming to update all our images.

Yes, I know this. So I have a long time reflected, if I should mention this.
New users are very anxious for getting started with their new toys. So it's a bad user experience.
Maybe we should cancel some supported devices and sort out some software, so you will get more time, to work on important thing, you personally want to push forward.
I become scared, if see here 224 open issue, over 40 different supported devices, more then 150 installable pieces of software and only one main service coder ... :fearful:

[Fourdee]

@k-plan

Maybe we should cancel some supported devices and sort out some software, so you will get more time, to work on important thing, you personally want to push forward.
I become scared, if see here 224 open issue, over 40 different supported devices, more then 150 installable pieces of software and only one main service coder ...

Yep, i've been considering dropping all images excluding:

• RPi
• Odroid
• Sparky
• Pine
• PC/VM
• BBB
• Asus TB

So basically all the NanoPi, BPi, OPi (which are far too many, they make a board every week it seems lol) images.
We rely on their kernel stability, and in most cases, its hit and miss. Most in early dev and unstable experience. ARMbian do a great job, making these boards available to end users, however, its not the same stability and control we can offer with our core images, and a "true" DietPi experience. Nor do I really have the time to spend on those devices , which see very little installations from our user base.

and only one main service coder ...

Yep, with the kids and managing long term ill health, so little time. I usually get 30-60 minutes a day which gets eaten up with emails and tickets, instead of working on the code. Wish I had more time, but such is life 😃
Although @MichaIng is doing is a great job with NextCloud/Owncloud and various other items, full credit to him.

[Invictaz]

Maybe just focus on fixing issues. There are a lot of devices already. Adding more isnt a viable option. Software is always a thing. With 150 pieces we are at the limit now what is maintainable.

[Fourdee]

Marking as closed due to the following:

• LED control scrapes solely from the kernel for all its available LED's and options.
• LED control then sets the selected LED option, directly to the kernel. As intended. If the result is not expected, then the kernel is the cause.
• Applying "fixes" per device is not the way forward, as a kernel update, which may improve kernel LED support, could simply render the workaround pointless within a few days. Resulting in an endless support cycle.

In short, if the kernel support for device LED's is fully functional, so is our LED control script.