I don’t think that I’ve really done that much to receive explicit credit. In case you really feel like you need to mention me, please simply use “awl” or “awl29” (without a full real name).
And another difference in naming: While the “M” models are called Nano**Pi, the “T” models are called NanoPC**, so you may want to change the models’ long description texts one more time…!?
Yup, I know. I had already done so in my image with which I was able to successfully boot DietPi.
Regarding the full model patch for NanoPi3, would it be possible for you to please also modify the finalise script until Wednesday: It must be changed in a way that it also post-processes /etc/fstab in order not to end up with an unbootable system (an unpatched finalise script for HW_MODEL=62 currently ends up with a boot partition of type vfat and resulting boot failure).
Also, I’ve already noted some issue with serial console, which I seem to be unable to switch between disabled and enabled state.
Finally, the tty1 console does not seem to have a getty spawned (no login prompt after the last kernel boot log message), while virtual consoles tty2 up to tty6 do exist and show a login prompt, even though only tty1 and tty2 should really exist. Will look into this on Wednesday or later when I have more time…
Thanks again for your help in putting me on track quite fast
While the “M” models are called NanoPi, the “T” models are called NanoPC, so you may want to change the models’ long description texts one more time…!?
Its mainly a visual thing.
We need to use short descriptions, so the dietpi-banner lines fit on single lines with 320x240 > displays. The purple lines are the max width in 320xXXX
Regarding the full model patch for NanoPi3, would it be possible for you to please also modify the finalise script until Wednesday: It must be changed in a way that it also post-processes /etc/fstab in order not to end up with an unbootable system (an unpatched finalise script for HW_MODEL=62 currently ends up with a boot partition of type vfat and resulting boot failure).
Also, I’ve already noted some issue with serial console, which I seem to be unable to switch between disabled and enabled state.
Are there any “other” config files in /boot/* that are not dietpi.txt or config.txt?
Finally, the tty1 console does not seem to have a getty spawned (no login prompt after the last kernel boot log message), while virtual consoles tty2 up to tty6 do exist and show a login prompt, even though only tty1 and tty2 should really exist. Will look into this on Wednesday or later when I have more time…
Although with one small known issue:
I still can neither disable the serial console nor switch it from disabled to enabled nor vice-versa.
How can I debug the menu scripts/files? There seems to be some error messages when I select Enable/Disable, but I am unable to read them as they are displayed only for a few milliseconds before the screen gets blue again and the menu window displayed.
Where do you want me to upload the 7z file? Please advise!
Or should I rather wait until you officially released v131, and then rebuild from the real “master” branch as soon as v131 has been integrated?
Although your 1st image is probably fine, it wouldn’t be a bad idea, just to make sure there are no “kinks”. Hoping to release v131 Sunday, so that would be the perfect time to recreate the image if you are able to?
If you do this, make sure you use the current system prep script,https://github.com/Fourdee/DietPi/blob/dev/PREP_SYSTEM_FOR_DIETPI.sh
I still can neither disable the serial console nor switch it from disabled to enabled nor vice-versa.
How can I debug the menu scripts/files? There seems to be some error messages when I select Enable/Disable, but I am unable to read them as they are displayed only for a few milliseconds before the screen gets blue again and the menu window displayed.
I will definitely do so in order to ensure that the image becomes official and contains a released state, although I’d still consider it beta state due to potential other issues like with the serial console (see below) that you maybe want to address before releasing v131.
The serial console device is called /dev/ttySAC0 on this device, not ttySAC2
systemctl returns “Invalid argument” for ttyAMA0 (even though the device /dev/ttyAMA0 as such exists)
There are the following systemd services in failed/degraded state
root@DietPi:~# systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
â hwservice.service loaded failed failed hwservice
â hwservice_monitor.service loaded failed failed hwservice_monitor
â lcd4linux.service loaded failed failed daemon for driving LCD based displays
As I am a complete newbie to systemd, please advise! As you seem to have access to a NanoPi2, can you please check whether the same issues also exist there (which, IMO, is quite likely)?
>
Bash and Shell scripts are two different programs. So expected result: http://stackoverflow.com/questions/5725296/difference-between-sh-and-bash
DietPi is all /bin/bash
Although the array init could be =0, then generate the array, i'll take a look.
> ```text
root@DietPi:~# systemctl --state=failed
UNIT LOAD ACTIVE SUB DESCRIPTION
â hwservice.service loaded failed failed hwservice
â hwservice_monitor.service loaded failed failed hwservice_monitor
â lcd4linux.service loaded failed failed daemon for driving LCD based displays
Not sure what these are, try running the following to get more information:
systemctl status hwservice.service -l
systemctl status hwservice_monitor.service -l
systemctl status cd4linux.service -l
The serial console device is called /dev/ttySAC0 on this device, not ttySAC2
Aha! Lets see if this has any effect on the serial console. Please try running:
systemctl enable serial-getty@ttySAC0.service
reboot
ps aux > /root/attach_enabled.txt
Then same again with disable:
systemctl disable serial-getty@ttySAC0.service
reboot
ps aux > /root/attach_disabled.txt
You should have two files in /root (attach_*.txt), please copy/paste or attach them.
As you seem to have access to a NanoPi2, can you please check whether the same issues also exist there (which, IMO, is quite likely)?
Doubtful, we use ARMbian to build that image. But i’ll make a note to check it either way.
Sorry, I had planned to respond tonight, but I have just found that the SD card in my NanoPC-M3 seems to have crashed, and the image I created last week seems corrupt (partition table has a filesystem size that is much smaller than the correct size in the superblock), so I need to rebuild the image…
I have finally found some time to use a proper SD card to rebuild the image - this time based on the official released v131 codebase - and try again:
Oh, I see. Sorry, I should have done “bash -x /DietPi/dietpi/func/dietpi-set_hardware serialconsole enable” (which indeed works fine).
root@DietPi:~# systemctl status hwservice.service -l
● hwservice.service - hwservice
Loaded: loaded (/lib/systemd/system/hwservice.service; enabled)
Active: failed (Result: exit-code) since Thu 2016-09-22 15:25:44 BST; 5h 15min ago
Process: 591 ExecStart=/etc/init.d/hwservice start (code=exited, status=127)
Main PID: 591 (code=exited, status=127)
Sep 22 15:25:44 DietPi systemd[1]: Starting hwservice...
Sep 22 15:25:44 DietPi hwservice[591]: /etc/init.d/hwservice: line 16: /usr/sbin/hwservice: No such file or directory
Sep 22 15:25:44 DietPi systemd[1]: hwservice.service: main process exited, code=exited, status=127/n/a
Sep 22 15:25:44 DietPi systemd[1]: Failed to start hwservice.
Sep 22 15:25:44 DietPi systemd[1]: Unit hwservice.service entered failed state.
root@DietPi:~# systemctl status hwservice_monitor.service -l
● hwservice_monitor.service - hwservice_monitor
Loaded: loaded (/lib/systemd/system/hwservice_monitor.service; enabled)
Active: failed (Result: exit-code) since Thu 2016-09-22 15:25:44 BST; 5h 17min ago
Process: 584 ExecStart=/etc/init.d/hwservice_monitor start (code=exited, status=127)
Main PID: 584 (code=exited, status=127)
Sep 22 15:25:44 DietPi hwservice_monitor[584]: /etc/init.d/hwservice_monitor: line 16: /usr/sbin/hwservice_monitor: No such file or directory
Sep 22 15:25:44 DietPi systemd[1]: hwservice_monitor.service: main process exited, code=exited, status=127/n/a
Sep 22 15:25:44 DietPi systemd[1]: Failed to start hwservice_monitor.
Sep 22 15:25:44 DietPi systemd[1]: Unit hwservice_monitor.service entered failed state.
root@DietPi:~# systemctl status lcd4linux.service -l
● lcd4linux.service - daemon for driving LCD based displays
Loaded: loaded (/lib/systemd/system/lcd4linux.service; enabled)
Active: failed (Result: exit-code) since Thu 2016-09-22 15:25:44 BST; 5h 17min ago
Process: 524 ExecStart=/usr/sbin/lcd4linux $ARGS (code=exited, status=127)
Sep 22 15:25:44 DietPi lcd4linux[524]: /usr/sbin/lcd4linux: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory
Sep 22 15:25:44 DietPi systemd[1]: lcd4linux.service: control process exited, code=exited status=127
Sep 22 15:25:44 DietPi systemd[1]: Failed to start daemon for driving LCD based displays.
Sep 22 15:25:44 DietPi systemd[1]: Unit lcd4linux.service entered failed state.
For the first two, it is very interesting that /usr/sbin/hwservice does indeed exist, but on the NanoPi3 is a dangling relative link:
root@DietPi:~# ls -l /usr/sbin/hwservice
lrwxrwxrwx 1 root root 6 Jun 29 12:53 /usr/sbin/hwservice -> bin/ls
and of course, /usr/sbin/bin/ls does not exist. But I have no clue why “hwservice” should even link to “/bin/ls”…!?
Regarding the second one, it first looked like at least Debian packages libx11-6, libgd-3, libmysqlclient18 and libpython2.7.so.1.0 (including their dependencies) are missing, as the lcd4linux binary on my NanoPi3 was dynamically linked against those libraries. But even installing all library dependencies did not help - now lcd4linux failed differently:
root@DietPi:~# systemctl status -l lcd4linux.service
● lcd4linux.service - daemon for driving LCD based displays
Loaded: loaded (/lib/systemd/system/lcd4linux.service; enabled)
Active: failed (Result: resources) since Thu 2016-09-22 21:14:16 BST; 3s ago
Process: 2149 ExecStart=/usr/sbin/lcd4linux $ARGS (code=exited, status=0/SUCCESS)
Sep 22 21:14:16 DietPi LCD4Linux[2151]: LCD2USB: could not find a LCD2USB USB LCD
Sep 22 21:14:16 DietPi LCD4Linux[2151]: Error initializing driver LCD2USB: Exit!
Sep 22 21:14:16 DietPi systemd[1]: PID file /var/run/lcd4linux.pid not readable (yet?) after start.
Sep 22 21:14:16 DietPi systemd[1]: lcd4linux.service never wrote its PID file. Failing.
Sep 22 21:14:16 DietPi systemd[1]: Failed to start daemon for driving LCD based displays.
Sep 22 21:14:16 DietPi systemd[1]: Unit lcd4linux.service entered failed state.
I then noticed that “my” lcd4linux binary was not from Debian, but seemingly from FriendlyARM, as the Debian package “lcd4linux” was not even installed. I then did an “apt-get install lcd4linux”, which indeed finally made the errors go away, and the lcd4linux service is now running, but still has suspicious output:
root@DietPi:~# systemctl status -l lcd4linux.service
● lcd4linux.service - daemon for driving LCD based displays
Loaded: loaded (/lib/systemd/system/lcd4linux.service; enabled)
Active: active (running) since Thu 2016-09-22 21:24:59 BST; 54s ago
Process: 2620 ExecStart=/usr/sbin/lcd4linux $ARGS (code=exited, status=0/SUCCESS)
Main PID: 2622 (lcd4linux)
CGroup: /system.slice/lcd4linux.service
└─2622 /usr/sbin/lcd4linux
Sep 22 21:24:59 DietPi systemd[1]: lcd4linux.service: Supervising process 2622 which is not our child. We'll most likely not notice when it exits.
Sep 22 21:24:59 DietPi systemd[1]: Started daemon for driving LCD based displays.
Sep 22 21:24:59 DietPi LCD4Linux[2622]: widget 'Rain': class 'icon' not supported
Any ideas?
Results attached - the ZIP contains both the enabled and the disabled case.
I think you mixed up NanoPi2 (i.e. NanoPi-M2/NanoPC-T2 - for which no Armbian exists) with NanoPi NEO or NanoPi-M1 (for which indeed Armbian images are available). But in case you have indeed created the NanoPi2 image from an Armbian build for the Samsung/Nexell S5P4418 SoC, it would also be possible to use this exact build for NanoPi3 - except both the initramfs and the kernels on the /boot partition, which must be specific to S5P6818.
Additional news:
Even though I think the above issues should probably be fixed before the NanoPi3 image becomes official, I have nevertheless uploaded my new v131 master branch image for NanoPi3 to your dropbox. What do you think?
Thanks again, sorry for all those new (but truly minor!) issues & best regards,
awl attach_output.zip (2.99 KB)
Thanks for the update.
I’ve not had a chance to go through your full post yet, so i’ve created a git ticket to remind me. Hopefully get back to you within a few days: https://github.com/Fourdee/DietPi/issues/530
As far as I can tell, these are non-standard services. Probably something FriendlyARM manually added to their images.
I think for now, we should try disabling them with:
systemctl disable name.service
We can do this with a patch/update. Are those services still enabled on the dropbox uploaded image?
I think you mixed up NanoPi2 (i.e. NanoPi-M2/NanoPC-T2 - for which no Armbian exists) with NanoPi NEO or NanoPi-M1 (for which indeed Armbian images are available).
As yes, correct. M2 image is based on the FriendlyARM image. So many images, hard to keep track lol
I’ll release it under beta, once we can check a few things:
Onboard WiFi and Bluetooth. Is this functional at the moment?
I’ll need to code this into dietpi-set_hardware. Can you run the following commands for me please:
/DietPi/dietpi/func/dietpi-set_hardware wifi enable
cat /etc/modules
ls -lha /etc/modprobe.d/
cat /etc/modprobe.d/*
Serial console. if systemctl disable serial-getty@ttySAC0.service has no effect, I believe this may be hard coded as enabled in the /boot binary files. Cant see any config files we can edit. So not much we can do this about this for now.
Yes, unfortunately they are. If they have been created by FriendlyARM (and not Debian or even DietPi), I feel like we should even remove them fully instead of simply disabling them:
systemctl stop [servicename]
systemctl disable [servicename]
rm /etc/systemd/system/[servicename]
rm /etc/systemd/system/[servicename] symlinks that might be related
systemctl daemon-reload
systemctl reset-failed
Thanks, but it’s mostly due to your great instructions on how to do so (including shrinking the image).
WiFi: Yes, Bluetooth: No.
It looks like Bluetooth support (CONFIG_BT) is missing in the Debian/Linux kernel as opposed to the Android kernel. Also, there is a file /etc/modprobe.d/disable_bt.conf that blacklists the respective kernel modules. I will try to work around this, remove the blacklist file and compile a kernel with BT support on my own (based on FriendlyARM’s source: GitHub - friendlyarm/linux-3.4.y: Linux kernel source tree for FriendlyARM NanoPi 2, NanoPi 3) during the next couple of days and report back here.
WLAN is fully functional:
root@DietPi:~# iwconfig wlan0
wlan0 IEEE 802.11bg ESSID:off/any
Mode:Managed Access Point: Not-Associated
Retry short limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
root@DietPi:~# cat /etc/modules
# /etc/modules: kernel modules to load at boot time.
#
# This file contains the names of kernel modules that should be loaded
# at boot time, one per line. Lines beginning with "#" are ignored.
I think that not all hope is lost: For testing purpose, I had already successfully changed and repackaged the initramfs in file /boot/root.img.gz in order to avoid the call to resize2fs, so I can also have a look whether I can find anything that is responsible for the serial console to be activated on every boot and comment it out…
Many thanks so far, I will report back shortly - as time permits - regarding Bluetooth and serial console in initramfs.
I feel like we should even remove them fully instead of simply disabling them:
Yep agree. I also found these services on the NanoPi M2 image (based on FriendlyARM). I’ll add a patch to remove them during dietpi-update on both M2 and M3 images.
WiFi, excellent.
I’ve added the module (bcmdhd) to the dietpi-set_hardware wifi script. So when wifi is disabled, the module wont be loaded into memory.
Many thanks so far, I will report back shortly - as time permits - regarding Bluetooth and serial console in initramfs.
Excellent, no rush, great work
OK, so after two days of digging really deep into the pitfalls of Broadcom Bluetooth device initialisation (the NanoPi-M2/NanoPC-T2 and NanoPi-M3/NanoPC-T3 both use a combination of AP6212/BCM43438), I have good news: I have finally managed to find out how to reliably initialize and attach Bluetooth on the NanoPi/NanoPC devices!
With regards to DietPi for the NanoPi-M3/NanoPC-T3, this means that I will update “my” image soon to include the steps as described in my posting. Please note that you may want to do the same for your image for NanoPi-M2/NanoPC-T2 in order to get a working Bluetooth for this SoC as well.
And finally, regarding serial console: I have now found that it is not initramfs, but the u-boot default environment “bootargs” variable containing a kernel parameter “console=ttySAC0,115200,8n1” that causes a serial console to be created on every boot, and disabling serial console from DietPi to fail.
Unfortunately, I think that there is not much that we can do about this in a DietPi image, as the u-boot environment seems to be stored directly on the device in NVRAM and not on the DietPi SD card. So I think that every NanoPi2/NanoPi3 owner will have to remove this on his own to disable serial console.
Base line: I would like to rebuild “my” image one more time to include all changes mentioned so far, and to incorporate the new September Debian image by FriendlyARM (my previous DirectPi image was still based on their June Debian image). What would be the best time to do so? Right now, again based on v131, or would you like me to wait for your next release?
What would be the best time to do so? Right now, again based on v131, or would you like me to wait for your next release?
If you use the master branch (default stable), you can do the image at anytime. DietPi will always update to the latest version on 1st run. So if there are any additional “fixes” we need to add, that can be done easily and before the image is released to the public.
OK, so after two days of digging really deep into the pitfalls of Broadcom Bluetooth device initialisation (the NanoPi-M2/NanoPC-T2 and NanoPi-M3/NanoPC-T3 both use a combination of AP6212/BCM43438), I have good news: I have finally managed to find out how to reliably initialize and attach Bluetooth on the NanoPi/NanoPC devices! > >
Great work, although sounds like a nightmare few days lol.
I’ll try your fix with the NanoPi M2, and, the BPi M2+ (has a AP6212 chip).
variable containing a kernel parameter “console=ttySAC0,115200,8n1” that causes a serial console to be created on every boot, and disabling serial console from DietPi to fail.
Yep no worries. If the option isn’t available as a var we can change on the fly, not much we can do about it. If we start having to compile various kernels/uboot just to toggle 1 option, we would dig ourselves into a never ending loop.
Ok, great stuff. I’ll take a look at the bluetooth/wifi fix you made.
I have done so and used the exact same prepping script (especially with regards to the “apt-get purge” commands) on the FriendlyARM September Debian Jessie image that I had previously used on the June image, but at the end of the script, I have much more space still being occupied on the rootfs (nearly 600M) than I had on the June Debian Jessie image (immediately before calling finalise):
well, when we had ~440MB with the FriendlyARM June build, I think that 600MB with the September build would mean that DietPi did not follow its diet plan…
Fine, but frees only an additional 5MB.
Thanks, sorry - I should clearly have suspected other files/locations than Debian packages at the first place…
Ran “du -k /” and indeed found out about a /usr/nexell tree, about additional unmatching kernel modules for s5p4418 and some other files which did not belong there. I also cleared /var/cache and got back to about the level of the FriendlyARM June image…
So stay tuned - there will be hopefully a new build by the end of tomorrow (Mon)…
unfortunately, it looks as if we need an update to dietpi-set_hardware in order to properly support Bluetooth:
Currently, the brcm_patchram_plus service was set to be started on boot, but the way that you have set up things means that with modprobe file “disable_bt.conf” active, the firmware upload to the Broadcom device simply can not happen during boot.
Therefore, it looks to me like the most simple way out of this is to start with brcm_patchram_plus service disabled, and only start and enable the service when “dietpi-set_hardware bluetooth enable” is called, and stop and disable things again when “dietpi-set_hardware bluetooth disable” is called.
Please note that I think I have found a small bug: During disable, you’ll also need to stop and disable the systemd bluetooth service first, and not only/simply force unload “modprobe -rf” the modules…
I have attached an updated version of dietpi-set_hardware that seems to do the job for me and would like to ask you to integrate this fix into v134. I will only then create a new build, as otherwise, I cannot make Bluetooth work out-of-the-box.
I have also found out that - specifically for DietPi (not needed for plain Debian or Ubuntu) - I need to remove the dependency of the systemd “brcm_patchram_plus.service” to “syslog.service”, because a systemd service for logging does not seem to exist with DietPi - am I correct?
If you find some time, can you please also check whether (with an updated service file as stated above) my brcm_patchram_plus service does indeed also make Bluetooth work for NanoPi-M2/NanoPC-T2 (and possibly, BPi M2+ as you mentioned)?
