DietPi | Update images

[k-plan]

---

- Images update (Jessie - Kernel: 3.x) :

_#### (Hint: - Dependent on hardware - can only do update for devices I own myself)_

---

• [x] 🈯️ DietPi_v158_OrangePiOne-armv7-(Jessie).img=> complete => uploaded
  _Kernel Version : ( legacy - by armbian )_
• _Linux OrangePi-One 3.4.113-sun8i # 4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux_

.

• [x] 🈯️ DietPi_v158_PineA64-arm64-(Jessie).img => complete => uploaded
  _Kernel Version : ( legacy - lastest by longsleep )_
• _Linux PineA64 3.10.105-0-pine64-longsleep # 3 SMP PREEMPT Sat Mar 11 16:05:53 CET 2017 aarch64 GNU/Linux_

.

• [x] 🈯️ DietPi_v158_OdroidC1-armv7-(Jessie).img => complete => uploaded
  _Kernel Version : ( legacy - by meveric )_
• _Linux oDroid-C1 3.10.107 # 1 SMP PREEMPT Wed Sep 13 18:48:10 CEST 2017 armv7l GNU/Linux_

.

• [x] 🈯️ DietPi_v158_NanoPiNEO-armv7-(Jessie).img =>=> complete => uploaded
  _Kernel Version : ( legacy - by armbian )_
• _Linux NanoPi-Neo 3.4.113-sun8i # 4 SMP PREEMPT Wed Nov 22 13:45:28 CET 2017 armv7l GNU/Linux_

.

[k-plan]

@Fourdee

Any interest for DietPi_v158_RPi-armv6-(Jessie).img with last dietpi_rpi_kernel_4.9.zip?

.

• [x] - 🈯️ DietPi_v158_RPi-armv6-(Jessie).img => complete => uploaded
  _Kernel Version : ( mainline LTS - by Fourdee )_
  _Linux RPi 4.9.62+ # 1 Fri Nov 17 22:37:52 GMT 2017 armv6l GNU/Linux_
  .

_Edit:_
The RPI image stuck on v150

With some quirks, see: #1270

[k-plan]

@Fourdee

Bonus:

• [x]  🈯️ DietPi_v158_OdroidC2-arm64-(Jessie).img => complete => uploaded
  _Kernel Version : ( legacy - by meveric )_
• _Linux Odroid-C2 3.14.79+ # 1 SMP PREEMPT Sun Jul 23 00:04:44 CEST 2017 aarch64 GNU/Linux_

But with some quirks, see: #1270

(_Edit: moved over to "Quirks noticed by v158 image update"_)

[k-plan]

@Fourdee

Question to https://github.com/Fourdee/DietPi/issues/1268#issuecomment-350108752

Started update image building on RPi Zero W:

• on auto-update from DietPi v150 => v158 dietpi_rpi_kernel_4.9.zip will be install with new kernel 4.9.62 and firmware updates

• directly after this, automated apt-get update installed updated fimware files

1. 
   
   • [ ] - is it safe to remove/delet old kernel 4.9.27 modules by hand❓
   
   

root@RPi-Zero-W:~# du -hs --time /lib/modules/4*
53M     2017-05-26 14:41        /lib/modules/4.9.27+
54M     2017-05-26 14:41        /lib/modules/4.9.27-v7+
53M     2017-11-17 23:58        /lib/modules/4.9.62+
54M     2017-11-17 23:58        /lib/modules/4.9.62-v7+

1. 
   
   • [ ] - is/can it a problem apt-get overwrite firmware and module file witch has been copy by dietpi_rpi_kernel_4.9.zip before❓
     
     Safer to run a new pass of dietpi_rpi_kernel_4.9.zip after automated apt-get update❓
   
   

Any hints are welcome. Want at last finalize update image building and move forward ...

[MichaIng]

@k-plan

• The kernel backups are held, in case you get serious boot problems or similar issues after new kernel installation, also if kernel is just custom/buggy or something.
  So if you do not face issues like that, and especially since we use 4.9.62 already since a whole on our devices, it is safe to remove to old ones. Especially for new images we want to have them slim and clean.
• Generally overwriting apt kernels manually or other way round is no problem. I did this long time on RPi, since I ran apt upgrade and rpi-update both regularly. I didn't know that time, that kernel apt packages and rpi-update overwrite each other. But of we ship tested kernel packages on dietpi-update, I would suggest the apt packages to be marked als hold, as it is at least on RPi images, to avoid unnecessary overwriting.

[k-plan]

@MichaIng

👍

Danke Michael für deine Antwort. Wenn ich die Zeichen richtig deute, dürftest du Deutsch verstehen. Daher die Antwort so, weil mir das Schreiben somit deutlich leichter fällt.
Schön, dass du Dich hier so großartig einbringst.

• Habe die Kernel 4.9.27 Module jetzt gelöscht und testweise das neu erstellt Image probiert. Geht soweit.

• War etwas verwirrt, da ich in den letzten Tage so viel mit verschiedensten Image herum gespielt habe. Da war es immer möglich die alten Module mittels apt oder den spezifischen Update-Script zu entfernen bzw. diese wurden durch das Script selbst entfernt.
  Macht aber jetzt Sinn, wenn das vorherige Update nicht via apt-get dist-upgrade oder rpi-update installiert wurde.

• Werde das dietpi_rpi_kernel_4.9.zip vorsichtshalber zum Abschluss noch einmal 'drüber bügeln'. Datum ist: 07-Dec-2017 17:36 - kannst ja einmal ins Archiv reinschauen. Du hast sicher mehr Ahnung davon als ich.

Danke für Deine Hilfe.

[k-plan]

@Fourdee

all images fixed and uploaded is running (..._lastest-try)

Quirks for RPi you get tomorrow. (_edit: done_ #1270 (comment))

Must leave my home now ... bye

[k-plan]

Closed for now. (what a mess ...) 😉

[MichaIng]

@k-plan
Hehe, ja richtig, wie auch immer geschlussfolgert, ich heiße allerdings wirklich nur "Micha" ohne "el" 😉.

Ich war beim Erstellen des VirtualBox images auch etwas am überlegen bzgl. APT Kernel vs DietPi Kernel. Keine Ahnung wie stabil linux-image* normalerweise ist, allerdings denke ich, dass es grundsätzlich laufen sollte. Falls wir nicht aktiv neuere Kernels via dietpi-update implementieren (wie beim RPi), sind die APT packages eine gute, eher konservativ stabil gehaltene, Alternative (beim RPi definitiv!).

Stellen wir einen eigenen Kernel bereit, auch zwecks Tests mit DietPi, dann sollten wir die APT packages hingegen auf "hold" setzen, dass sie sich nicht laufend gegenseitig überschreibt. Beim RPi können wir es gut selbst bereit stellen, alles ist prima via github bereit gestellt für alle RPi Versionen: https://github.com/raspberrypi/firmware
Wie gesagt kp was andere Plattformen angeht.

[Fourdee]

@k-plan

Many thanks for doing these images 👍
I've downloaded them all, I will test each one and upload to dietpi.com.

[Fourdee]

@k-plan

There a few multiples, just to confirm _lastest-try.7z are the correct/final images?

[k-plan]

@Fourdee

There a few multiples, just to confirm _lastest-try.7z are the correct/final images?

Yes. All with:

##DietPi_ ... -(Jessie)_lastest-try.7z

##DietPi_NanoPiNEO-armv7-(Jessie)_lastest-try.7z) 
MD5 = 03448272522e7d9693819315f158f6c6

##DietPi_OrangePiOne-armv7-(Jessie)_lastest-try.7z) 
MD5 = 6f30dae8808cc6dfc4582b30ba770d7c

##DietPi_PineA64-arm64-(Jessie)_lastest-try.7z) 
MD5 = 39e53a33cd0241e7e2b31c48b1c3d58e

##DietPi_OdroidC1-armv7-(Jessie)_lastest-try.7z) 
MD5 = 874661656c65c18d64c189113479ea2f

##DietPi_OdroidC2-arm64-(Jessie)_lastest-try.7z)
MD5 = 87f9b3cef14c6c3ee4c8084b80aca96e

##DietPi_RPi-armv6-(Jessie)_lastest-try.7z)
MD5 = fc8e082c51ea211f42728e51631ab44b

''DietPi_ ... -(Jessie)_lastest-try.7z was only a typo while in rush and uploading, I can't delete it later.

As always, everything is without engagement or guarantee, but the best I can do. 😃

Happy testing.

[k-plan]

@MichaIng

Hallo Micha,

ja, das mit den Firmware und Kernel Fixierung sehe ich genauso.
Daher habe ich deinen Vorschlag auch hier mit eingearbeitet: https://github.com/Fourdee/DietPi/issues/1270#issue-278797206

Wie gesagt kp was andere ...

kp ... ? => Kein Plan? (🇬🇧 = dunno) | Das ist jetzt aber mein Pseudonym ! 😃

But now better back to english before @Fourdee get a crunch.

cu
dunno (k-plan)

[k-plan]

My new toy arrived at Christmas time: Odroid HC1 - unfortunately without the Clear Case. 😢

Noticed @Fourdee get on as well from Hardkernel! 👍 Nice, a photo of his device is here 😃

Important discovery:

• without a HDD/SSD attached to SATA connector device will not boot up completely! (no network/ssh connection)

Have played around with DietPi and other images and observe, network and file transfer perforamance is disappointing. And yes, I have a Gigabit enterprise network at home.

Started with DietPi Jessie (Kernel 3.10.106+) and switched over to DietPi Jessie (Kernel 4.9.61+)

---

Odroid HC1 - DietPi v159 (Kernel 3.10.106+) Jessie

iperf:

root@Odroid-HC1_Jessie_3:~# cat /etc/debian_version
8.10

root@Odroid-HC1_Jessie_3:~# cat /DietPi/dietpi/.version
159

root@Odroid-HC1_Jessie_3:~# uname -a
Linux Odroid-HC1_Jessie_3.x 3.10.106+ #1 SMP PREEMPT Wed Nov 15 21:07:58 CET 2017 armv7l GNU/Linux


root@Odroid-HC1_Jessie_3:~# iperf -s 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  3.35 GBytes   479 Mbits/sec


root@Odroid-HC1_Jessie_3:~# iperf -c  
------------------------------------------------------------
Client connecting to 1 , TCP port 5001
TCP window size: 0.02 MByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  5083 MBytes   711 Mbits/sec

ProFTP file transfer performance on DietPi Jessie (Kernel 3.10.106+) :

Benchmark SMB/CIFS file transfer performance on DietPi Jessie (Kernel 3.10.106+) :

Benchmark RAM performance on DietPi Jessie (Kernel 3.10.106+) :

---

Odroid HC1 - DietPi v159 (Kernel 4.9.61+) Jessie

iperf:

root@Odroid-HC1_Jessie_4:~# cat /etc/debian_version
8.10

root@Odroid-HC1_Jessie_4:~# cat /DietPi/dietpi/.version
159

root@Odroid-HC1_Jessie_4:~# uname -a
Linux Odroid-HC1_Jessie_4.x 4.9.61+ #1 SMP PREEMPT Sat Nov 18 15:15:45 UTC 2017 armv7l GNU/Linux


root@Odroid-HC1_Jessie_4:~# iperf -s 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  4.55 GBytes   651 Mbits/sec

root@Odroid-HC1_Jessie_4:~# iperf -c 
------------------------------------------------------------
Client connecting to  , TCP port 5001
TCP window size: 0.04 MByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6634 MBytes   928 Mbits/sec

ProFTP file transfer performance on DietPi Jessie (Kernel 4.9.61+) :

Benchmark SMB/CIFS file transfer performance on DietPi Jessie (Kernel 4.9.61+) :

Benchmark RAM performance on DietPi Jessie (Kernel 4.9.61+) :

---

DietPi Jessie with Kernel 4.9.61+ show a improved RAM performance.
Guess from there come the better file transfer rates.
Thus I have decided to go with Kernel 4.9.61+ for future tests.

So a long trip started with a lot of searching and testing.
It cost me more than a week, but finally I got it to work as desired.

Will split it here to get more clearness.

[k-plan]

Frist I have to say, all hint have been foung by google around the Net.
Script, code and adjustment are not from me, credit must go to originator.
So I can't say you will get it on DietPi. It will be Fourdee decision.

Some infos found here:
https://forum.odroid.com/viewtopic.php?f=52&t=25424
https://magazine.odroid.com/wp-content/uploads/ODROID-Magazine-201702.pdf#page=8

Change

• IRQ allocation for SATA Bridge and Gigabit Ethernet Controller

• additional parameters in smb.conf to get a better overall SMB/CIFS performance

• modified conditioning for file transfer relevant services

• upper cpu_min_frequency default parameter

Result on DietPi Jessie (Kernel 4.9.61+)

iperf

root@Odroid-HC1_Jessie_4:~# iperf -s 
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  6.45 GBytes   923 Mbits/sec

root@Odroid-HC1_Jessie_4:~# iperf -c 
------------------------------------------------------------
Client connecting to  , TCP port 5001
TCP window size: 43.8 KByte (default)
------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.30 GBytes   902 Mbits/sec

ProFTP file transfer performance on DietPi Jessie (Kernel 4.9.61+) :

Benchmark SMB/CIFS file transfer performance on DietPi Jessie (Kernel 4.9.61+) :

---

I have build a image DietPi_v158-SE_OdroidXU4_jessie-4.9.img for test purpose, so @Fourdee can make his own test and have a look on it.
Will upload this later.

Have tested this modifications with:

• DietPi v159 Jessie (Kernel 3.10.106+) | _file transfer performance increase is lower_

• DietPi v159 Jessie (Kernel 4.9.61+) | _as pointed_

• DietPi v159 Stretch (Kernel 4.9.61+) | _working_

• DietPi v159 Stretch (Kernel 4.14.9+) | _working_

Will upload DietPi_v159-SE_OdroidXU4_stretch-4.14.9.img for test purpose as well.

Have fun and happy testing.

cu
k-plan

_Edit: -upload is ready!_

[MichaIng]

@k-plan simply great!
To reduce work load I would concentrate on the Stretch image (with kernel 4.9 as repo default version), as we anyway wan't to drop Jessie. Or might the issues with Odroid C2 also be present here, which are the reason we do not yet have stable Stretch?: https://github.com/Fourdee/DietPi/issues/1032

[k-plan]

@MichaIng

have not tested Pi-Hole on Odroid HC1 so far. Full concentration was on file transfer performance.

Have as well choose Jessie to have a better comparison to OMV (erasmus) which work as well with Jessie at this moment.

DietPi v159 Stretch is a apt-get update && apt-get upgrade && apt-get dist-upgrade && install linux-image-4.14-armhf-odroid-xu4 version of (NR_4.x)_DietPi_v158_OdroidXU4-armv7-(Jessie).img.
https://forum.odroid.com/viewtopic.php?f=96&t=17542&sid=b1be1a1ccdcb4deac16c29ba6ca55b55&start=600#p208191

But I will switch off my mods and will test Pi-Hole on DietPi v159 Stretch (Kernel 4.9.61+).

[MichaIng]

@k-plan
Hehe don't wanted to turn down testing fun 😄! Just if you guys are going to start boring tests with installing/uninstalling all our software or something like this, before release, then, as we already had the "many devices" discussion, it should be enough to do that for Stretch 4.9 😉.

But if kernel 4.14. is working fine so far, and maybe especially this new board has benefits from it, we could also directly use this one?

About Odroid C2 issues: The issues seem (at least kodi) related to meverics image, that we use as base, and as I don't see some custom image for HC1 there, I guess you used official Debian image?

[Fourdee]

I'll mark this as closed, due to v159 images being replaced by v6.0.

Apologies @k-plan for not testing/using the images you kindly spent time making. I'll recreate all the v6.0 images (will accept help if its offered 😃 ):
https://github.com/Fourdee/DietPi/issues/1385