DietPi-Software | Solve misleading output on CertBot install #2870
Comments
MichaIng
added
the
Visual 🌹
|
@hyperionlevelq Actually the output is just misleading:
So actually you should have fount the three entries in a commented way, thus HDMI should have been still active. To check the long boot time, please paste: Another minor:
|
|
Right. OK, this makes a lot of sense. I can see now that the Although, the boot took around 7 minutes, if the ^ After this it connected to WiFi, and within another minute the boot was complete. ^ Thanks for the clarification about the HDMI thing. It was definitely confusing to see that output before the Pi rebooted itself. I was afraid for a bit that I would have had to redo the entire installation since I couldn't log-in using either HDMI or SSH. However, I think the issues I experienced had something to do with the Pi's WiFi settings, since that doesn't seem to be working right now for some reason, and the boot process seemed to be waiting for WiFi, until it finally timed out. Though, I'm still not sure why HDMI didn't work (it still isn't working, though that might be because I'm using an HDMI to VGA converter?) but I'll make another update if I figure that out. |
|
@hyperionlevelq
Indeed, known issue: #2806 |
|
Wow. OK, yes that worked; boot time is back to normal . One |
|
@hyperionlevelq |
|
Output of that on my Pi: |
|
@hyperionlevelq Hmm perhaps the host key of ssh.dietpi.com is missing. Please try:
Ah since we apply this for root only, it needs to be run as sudo, and perhaps the connection time is too long, so please try:
|
|
I tried re-adding the key, but I got a warning that it already existed. So, I ran the curl test as suggested, and got this: |
|
@hyperionlevelq
Indeed a timeout 🤔. We should use the timeouts here that one can not set in via dietpi-config network options. |
|
Sadly, another no-go... |
|
@hyperionlevelq The values we have in the code worked very well for several years. Not sure why lately some systems, even with fast internet bandwidth, have so slow connection times. 5s for a simple sftp connection (upload not included) is the real no-go here. In my case it's 0.2s for exactly the same operation 😉. The reaction has already been done with v6.23 by allowing to adjust the timeouts. It has simply not yet been applied to bug report since there the usual connection test function is not in use. Everything else is out of our control. It's core Linux/Debian network with default tools that are present on any default Raspbian/Debian image. |
|
Yeah, that makes sense, and the connection really shouldn't be taking so long. Well, I guess I can't really make a bug report, then. |
|
@hyperionlevelq |
A check of |
|
@hyperionlevelq In case: We could actually remove the timeout from dietpi-bugreport 🤔. It is never called non-interactively. So leave it running and print hint that ctrl+c can be used to cancel. |
|
|
@hyperionlevelq
|
|
|
@hyperionlevelq |
|
Yep, 20 will be sufficient (since that 7's from a computer that's low-power to begin with, pushed nearly to its limits, and using a satellite Internet connection). |
|
@hyperionlevelq I guess you already found the dietpi-config > Network Options: Misc > G_CHECK_URL_TIMEOUT setting? I anyway plan to do a more precise error handling for the timeouts, so it a timeout has been detected that you will directly be offered to adjust them within the error prompt. As said they need to stay for all scripts that can be called non-interactively, which includes updates, software installs (automated first run installs), time sync, dietpi-survey and such. But for bug report indeed it can be removed completely. |
|
Ah, the And, yes, being able to adjust timeouts directly within error prompts would be nice, for sure. |
|
I will reopen to now forget about the mentioned changes. |
|
Uh. No it does not. I am sitting here, on my rpi0w with hdmi after using certbot to setup gitea. HDMI still works... |
|
Like I noted above, it's possible that my monitor/HDMI-to-VGA converter caused one of the issues I experienced. However, I was suspecting the installation for doing it at first, since I was misled by one of the status messages it gave me before my Pi rebooted: [ SUB1 ] DietPi-Set_hardware > headless (disable)
[ OK ] DietPi-Set_hardware | Comment in /DietPi/config.txt converted to setting: #hdmi_ignore_hotplug=0
[ OK ] DietPi-Set_hardware | Comment in /DietPi/config.txt converted to setting: #hdmi_ignore_composite=0
[ OK ] DietPi-Set_hardware | Comment in /DietPi/config.txt converted to setting: #hdmi_blanking=0
[ OK ] headless disable | CompletedHowever, I was experiencing the very real #2806, which greatly affected the time it took for my Pi to reboot. Thanks for the confirmation that HDMI isn't actually affected. |
MichaIng
changed the title
|
Finished: #2907 |
MichaIng
added
Solution available 🥂
Information:
DietPi version: 6.24.1
Distro version: Debian Stretch
Kernel version: Linux DietPi 4.19.42+ General | Update VM images to Stretch #1219 Tue May 14 21:16:38 BST 2019 armv6l GNU/Linux
SBC device: Raspberry Pi Zero W v1.1
Power supply used: 5V 1A USB -> 120V (Generic Digipower brick with official-looking RPi USB cable)
SDcard used: Kingston 16GB (Class 10)
Software title: Certbot installation script
Steps to reproduce:
Expected behaviour
Actual behaviour
Extra details (the full log, see the bold part at bottom for unexpected behaviour)
Like I said, I was able to log back in and change back the HDMI settings, but I wasn't expecting this and figured it was worth sharing in case anybody else experienced this.
The text was updated successfully, but these errors were encountered: