DietPi-Software | Docker: Install fails on 1st run install

[dezren39]

Creating a bug report/issue:

I recently attempted to take a copy of DietPi and install Docker. This failed, and so I'll attached the messages below. My only modifications to the DietPi config file were for locatalization, to 'auto-install' without user interference, infinite wait on network and to install Docker at the very bottom. I'll also attach this config file. It appears some module for the kernel may be missing, though I haven't been able to ascertain much more than that.

Required Information:

• DietPi version | 6.16
• Distro version | 9.5
• Kernel version | Linux f3-cluster 4.4.49-s5p6818 #1 SMP PREEMPT Wed May 9 14:01:02 CST 2018 armv7l GNU/Linux
• SBC device | NanoPi M3/T3/F3 (armv7l)
• Power supply used | 5V 2.5A per Port, 12A max, 6-Ports
• SDcard used | Generic 16gb, first formatting, Etcher writes at ~10MB/sec verifies at ~20mb/sec

Additional Information (if applicable):

• Software title | Docker
• Was the software title installed freshly or updated/migrated?
• Freshly
• Can this issue be replicated on a fresh installation of DietPi?
• Yes, but when I run dietpi-bugreport I obtain the following:

root@f3-cluster:~# dietpi-bugreport
[  OK  ] DietPi-Bugreport | Root access verified.
[  OK  ] DietPi-Bugreport | RootFS R/W access verified.

[ INFO ] DietPi-Bugreport | Lines required for Whiptail box and its contents (y=61, z=0), exceeds screen dimensions (y=40).
[ INFO ] DietPi-Bugreport | Lines required for Whiptail box and its contents (y=61, z=0), exceeds screen dimensions (y=40).
Warning: rc-local.service changed on disk. Run 'systemctl daemon-reload' to reload units.
[ INFO ] DietPi-Bugreport | Packing upload archive, please wait...
[  OK  ] DietPi-Bugreport | Connection test: ssh.dietpi.com
stat: cannot stat 'ffb1dd3a-80b7-4fdc-947f-700c2212c26a.7z': No such file or directory
/DietPi/dietpi/dietpi-bugreport: line 153: ((: <= 10000000 : syntax error: operand expected (error token is "<= 10000000 ")
[FAILED] DietPi-Bugreport | The bug report upload archive appears to be unexpected large. Please inspect and in case clean up the locations to be uploaded, as their size should never be that large:
CMD_OUT.txt
G_ERROR_HANDLER_GITREPORT
/var/log/*
/DietPi/*
/boot/dietpi.txt
/boot/config.txt
/boot/dietpi/*
/tmp/.G*
/var/tmp/dietpi/logs/*
/var/lib/dietpi/*
/etc/bash.bashrc
/etc/bashrc.d/*
/root/.bashrc
/home/*/.bashrc
/etc/profile
/etc/profile.d/*
/root/.profile
/home/*/.profile
/etc/rc.local
/etc/X11/xorg.conf
/etc/asound.conf
/etc/network/interfaces
/etc/fstab
/etc/sysctl.conf
/etc/sysctl.d/*
/etc/init.d/*
/etc/systemd/system/*
/lib/systemd/system/*
/etc/apt/sources.list
/etc/apt/sources.list.d/*
root@f3-cluster:~#

2018-10-21_journalctl_copied.txt

Steps to reproduce:

1. Format SD Card with most recent DietPi
2. Replace DietPi.txt config file with the file to be attached.
3. Power on the Fire3 with the SD card on a DHCP-enabled network with internet.

Expected behaviour:

• Device obtains IP, boots, installs all dependencies and updates, installs Docker, Docker service can be started.

Actual behaviour:

• Device obtains IP, boots, installs all dependencies and updates, fails to install Docker, showing error messages, docker command becomes available but Docker service cannot be started. service docker start produces similar output to the error output when the initial install fails.

Extra details:

• I've been having issues with these PR's timing out and the GitHub Unicorn staring at me. I will attempted opening the PR, then attaching my attachments as comments. Attachments will be my install/config file and a copy of executing journalctl -xe. I'd be happy help with debugging this if there is anything you'd like me to try or if there were something I'm doing wrong. I'm hoping that these boards are at least capable of using Docker as that is what I bought them for and they are using a new enough kernel. LMK what I can do to help.

[dezren39]

ah, I see GitHub caught up and listed all of the issues I made. Thanks and sorry for the mess.

[Atavic]

Close them, just leave one opened.

[Fourdee]

@dezren39

Thanks for the report, we'll try to replicate.

ah, I see GitHub caught up and listed all of the issues I made. Thanks and sorry for the mess.

No worries, Github has been a nightmare my end aswell 👍

[dezren39]

Thanks again. I don't see a dietpi file attached on this one, so here is one of those. If I can be of assistance in any way, please lmk. I can test, etc.
dietpi.txt

[MichaIng]

@dezren39
As mentioned within the other topic, I tried install on Stretch VM and it worked well there without issues.

You mentioned that it failed when you chose it to install on 1st boot. Does it install when when you (re)install it afterwards, after first run setup has completely finished?

Also you face a strange issue with the bugreport. Perhaps there is a deeper issue somehow related:

stat: cannot stat 'ffb1dd3a-80b7-4fdc-947f-700c2212c26a.7z': No such file or directory
/DietPi/dietpi/dietpi-bugreport: line 153: ((: <= 10000000 : syntax error: operand expected (error token is "<= 10000000 ")

Check code: https://github.com/Fourdee/DietPi/blob/dev/dietpi/dietpi-bugreport#L140

Could you try the following and report output:

dietpi-bugreport 1
cat /tmp/dietpi-bugreport_compress.log

Lol by chance found a similar bugreport issue: https://github.com/Fourdee/DietPi/issues/2087#issuecomment-423990473
Hmm, even if it's not related, need to find out why this fails in some situations.

[dezren39]

First run setup completes fine, bug report immediately after successful first run setup fails. Attached is the log from that as well as the tail end of trying to install Docker as an individual install using the dietpi-software command. Still no luck. There was no data in /tmp. I'll try manually installing docker after a successful first run and see what happens then.
2018-10-23_fresh_install_failed_bug_report.txt

[dezren39]

https://github.com/lxc/lxd/issues/2321
https://bugs.launchpad.net/ubuntu/+source/docker.io/+bug/1618283
These two suggest Docker may be failing to load modules it already has installed.
https://bugzilla.redhat.com/show_bug.cgi?id=1586189
This link suggested there may be generic modules disabled for this image/kernel.

[Fourdee]

@dezren39

Its most likely kernel compile options are missing for full Docker support on this device. NanoPi tend to strip back their kernel (CIFS/NFS support missing in most cases).

Unfortunately, we do not offer/compile custom kernels, due to limited man hours. We rely on the provided kernel by FriendlyARM.

---

@MichaIng

stat: cannot stat 'ffb1dd3a-80b7-4fdc-947f-700c2212c26a.7z': No such file or directory

Unsure what the cause is here. Removal of 7z resulted in DietPi error handle correctly.

Doesn't make sense as https://github.com/Fourdee/DietPi/blob/dev/dietpi/dietpi-bugreport#L150 would detect if no file, just before stat is run. Maybe an issue in older version of DietPi only?

[MichaIng]

According to error message this issue is not related to: https://github.com/Fourdee/DietPi/issues/2238

• The drop of fd:// support seems to be due to a very recent APT update between 2 - 3 weeks then.

@Fourdee
We should try to replicate on other NanoPi and in case drop Docker install options for those devices.
Additionally we can send feature request to FriendlyARM to have required kernel modules for docker compiled by default.

Quick search result, not sure if still current: https://vjordan.info/log/fpga/friendlyarm-nanopi-neo-mainline-and-docker.html

[dezren39]

Docker does work with Armbian. No luck with default kernel so far. Thanks again. I hope compatibility can be figured out as I like the project. Let me know if / when you have any need for testing. Hopefully FriendlyARM patches!

[dezren39]

I reached out to FriendlyArm a little bit back about this and the developer said that they knew it could be enabled using instructions from Gentoo, but hadn't had the time to completely figure it out yet.

I followed FriendlyARM's guide to compile their kernel oneself and added the needed changes from the Gentoo Docker guide. Then, I mounted something like the 6.17 image and placed my new kernel contents over /boot which left the DietPi parts alone.

This worked! At least I can run many of the basic ARM images so far without any problems, I haven't tried anything _too_ complex. I remember that you rely on the kernel provided by FriendlyARM, I've starting working on cleaning up my changes to reach out to them because I'd love to get the change official. :-)

I'm unsure what the timeline for that might be, but I'd guess that's the preferred way to incorporate the kernel changes into this project. I'd also like to offer to see what kinds of evidence or changesets might be sufficient to bring the change to the project directly. There's some level of trust in such things, especially in maintaining even a minor fork for some period of time, and so I understand that may be impractical. As such, I'll mainly focus on bugging FriendlyARM. ;-)

[MichaIng]

I had another look on this. Yeah as already stated, we do not have the man power to build custom kernels here.

• ARMbian image has reached EOL, so no support/development there anymore and I guess with this 4.14 kernel the issue persists?: https://www.armbian.com/nanopi-m3/
• FriendlyARM has recently updated images, but I can't find the Debian image anymore: https://pan.baidu.com/s/1kVySP6Z#list/path=%2FFriendlyARM-S5P6818
  Currently downloading the friendlycore xenial image to have a look into it, but xenial looks like it is Ubuntu-based. Those are all 4.4 kernel.
  
  
  
  • Uff, 8 GiB image, so much stuff pre-installed
  
  
  • Ah yeah Ubuntu core based, so definitely not what we can use 😉: http://wiki.friendlyarm.com/wiki/index.php/FriendlyCore_(based_on_ubuntu-core_with_Qt)#Download_Image_Files
  
  

If indeed with the available images Docker does not run, I am afraid we need to disable our Docker support for this device.

For completeness I found another 3rd party Debian installer for M3: https://github.com/rafaello7/debian-installer-nanopi-m3

[dezren39]

Sounds good! I've gotten it working locally but real life has distracted me from making a proper defconfig patch for FriendlyElec. It looks like Fire3 is still supported by Armbian btw, https://www.armbian.com/nanopi-fire3/ and that image natively supports Docker. Yeah those huge images are part of what made me so determined to get DietPi working with Docker, a 300mb image I might be able to netboot from, not an 8gb.

That debian install project is super cool! I hadn't seen that before. Might see how well it does.

[MichaIng]

@dezren39
Jep that's true, Fire3 and T3 support is there, only M3 is EOL on ARMbian. We ship the same image for all of them, as FriendlyARM does, since the core is the same. Not sure if the ARMbian Fire3 image works for all of them as well, possibly boot configs/defaults need to be adjusted. Not sure about device specific ARMbian APT sources, perhaps those would need to be adjusted too.

So you actually own a Fire3? Then we marked the issue wrong 😉. In this case the ARMbian image + converting via DietPi-PREP indeed would be an option to test. Perhaps some research first makes sense first to verify Docker support by reading/searching the ARMbian forum about this.

[MichaIng]

I mark this issue as closed. Added NanoPi M3/T3/F3 request to the Buster image overview thread: #2979