DietPi-Software | Docker APT failure after kernel upgrade #3126
Labels
Milestone
Comments
|
@Akito13 Hmm, I just tested the Docker install on VM and did not run into any APT/dpkg error. Which device + distro version did you try this on? Generally I aim to add some "Open shell to investigate/fix issue" option to our error prompt. Until then you can always simply open an additional TTY or SSH session, fix the issue there, and hit |
|
@MichaIng Well, I usually reboot the device and then hit CTRL+C at the time the error occurs. This is not ideal though, because it requires manual intervention, which is especially unpractical if you require the device to be set up automatically by the DietPi first boot script. I had to attach an extra monitor and change circumstances in my setup, to be able to fix the issue manually offline.
If that would've been possible, the described issue would've been child's play for me. The fun stops when I can't SSH into a machine, at all.
I wasn't able to fill in the information at the time of writing the report, as I could not access the system, yet. I will add them now and you can check out the OP to see the results. |
|
@Akito13 Okay RPi4 Buster. We did some fix back and forth since the official Docker installer first did not support Buster at all, then not Raspbian Buster, then no ARMv6 RPi models etc 😄. But that is all fixed now AFAIK, and as well the current DietPi master code does correct check to apply a workaround only if required, just verified that. Will run some test on RPi2 Buster, if you can capture the error log you faced, that would be awesome. |
It might be possible that I do a test installation with the same
Yes, I remember.
Yes, usually I can SSH during an installation but this time the device did not connect to my router (i.e. not visible on the router's web interface), at all, even though I had a LAN cable connected and I enabled LAN within dietpi.txt (i.e. it was already enabled). |
|
@Akito13 Based on router settings and whether DHCP or static IP is used I as well see my devices sometimes not in the online list of the router, or not listed at all, even they are definite there with network access and SSH working well. If the router really somehow allows outgoing requests for these devices but block inbound requests from within local network, then this would be a strange and false router setup. |
Ah right, completely forgot about that. The thing is, if there is any type of connectivity, then all devices I ever used immediately show up in the router's list. Even if they aren't actually connected to the internet, or what else. If they are connected to the router and powered on, they are always shown. Additionally, I am always able to at least try to establish an SSH connection. This time though, it was like the device did not even exist. SSH gave me an error saying something like that, whereas usually if something goes wrong, it acknowledges the device, but refuses to connect.
I doubt there is something wrong with the router, because all the other devices work as always and as expected and I have never seen such behaviour before. As I said, it has to at least be shown in the router's list and the device has to be at least knockable. That's how all other devices behaved I ever connected to that router. |
|
Okay, it is a separate topic anyway. Just keep in mind that those router lists do not always show all attached devices correctly. The router DHCP might refuse to assign the expected IP, if some entry with different hostname or MAC already exist or for other reasons, or due to some doubled values, one hides the other one. These are finally array entries as well that can double, one overriding each other etc, what I have seen and manually created on Fritz!Box routers e.g 😉. So you can only know for sure when checking the apparent IP from the device itself and try to ping or SSH that. However lets concentrate on the Docker issue now, I hope I find time today night for the test. |
|
Out of curiousity I ran the same image with all the same settings, except the network connection, as I had to change to Wi-Fi, on the Raspberry Pi 3 A+. The device is immediately shown in the router's list as the new DietPi device and upgrading through APT worked flawlessly.... ...except the docker-ce installation.
|
|
@Akito13 I just rechecked the open issues on Docker GitHub about Raspbian Buster. There was one reported issue similar to yours, although details logs are missing: docker/for-linux#709 (comment) |
MichaIng
changed the title
start failed." creates loop during first boot
After SSHing: |
(I added some \n to make it more readable.) |
|
@Akito13
Can you verify that Docker start continues to fail until you do a reboot? Although the final failure is indeed about nft support. This has indeed been added just recently to the RPi kernel. iptables should use netfilter as fallback, but probably it is a similar issue here about mismatch between loaded and installed/upgraded kernel. I will try to replicate the issue on a virtual machine with downgraded kernel. In case we need to force a reboot after first run dietpi-update when a kernel upgrade was detected, or we check if |
|
I issued a reboot over SSH. The |
|
@Akito13 |
|
@Akito13
I just wanted to implement the fix now, however I recognised that we did not do any error handling of the Docker installer: https://github.com/MichaIng/DietPi/blob/master/dietpi/dietpi-software#L6055-L6057 Error handling has already been implemented for v6.26, however exit code was not transferred to G_ERROR_HANDLER, so good that I had another look on it. Now this should work well. |
MichaIng
added
Bug 🐞
Solution available 🥂
MichaIng
changed the title
This was referenced Sep 28, 2019
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating a bug report/issue
Required Information
Additional Information (if applicable)
sed -n 5p /DietPi/dietpi/.hw_modelSteps to reproduce
Set
dietpi.txtto install Docker for you.Expected behaviour
Installation of docker-ce.
Actual behaviour
Installation loop during first boot of automated set up of DietPi prevents system from working.
The docker service fails to start after installation. (common issue)
Extra details
The issue with the docker service itself is common and usually easily fixable, by stopping and starting the service manually, but it is definitely not ideal to interrupt the first boot of DietPi when it tries to set up the system, before the first login.
The text was updated successfully, but these errors were encountered: