Creating a bug report/issue
Required Information
- DietPi version
G_DIETPI_VERSION_CORE=8 G_DIETPI_VERSION_SUB=8 G_DIETPI_VERSION_RC=1 G_GITBRANCH='master' G_GITOWNER='MichaIng'
- Distro version
bullseye
- Kernel version
Linux DietPi 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 GNU/Linux
- SBC model
Native PC (x86_64)
- Power supply used
Some 750W power supply
#### Additional Information (if applicable)
- Software title | (Literally anything, nextcloud, transmission etc)
- Was the software title installed freshly or updated/migrated? At least up to date
- Can this issue be replicated on a fresh installation of DietPi? No, the spare pi was fresh and it worked
← If you sent a “dietpi-bugreport”, please paste the ID here →
- Bug report ID |
echo $G_HW_UUID
#### Steps to reproduce
- … No idea frankly, all services stopped being accesible through WAN and LAN.
- … It may have been due to an update, but I can’t remember for sure.
#### Expected behaviour
- … I should be able to access my transmission GUI through LAN and nextcloud through LAN and WAN
#### Actual behaviour
- … It appears these applications are running, but I cannot access them.
#### Extra details
- … Again, that random pi works just fine, and the two other machines stopped working at the same time. It’s not a port forward issue since I can’t use LAN either. I suspect it has something to do with the X86 builds specifically.
Could you share following
dietpi-services status
Yes, they are indeed active, as I suspected.
could you check all LISTEN ports?
ss -tulpn | grep LISTEN
Did you install something like a firewall? Or VPN?
Btw: thre is no need to do screen prints. You should be able to copy everything directly from SSH terminal.
On the first desktop, I actually tried to backup, reinstall the OS and recover from the backup, thinking that maybe it was a bug that caused it, which could maybe be reset on a fresh base install, depending on if the backup is a 1/1 mirror copy or not.
The PC is just stuck in GRUB after the reboot. Just leads me to think something hella weird happened.
I have that other desktop though, where I have not reinstalled anything yet. I had no VPN or extra firewalls on the first desktop, but the other was connected to protonVPN.
And yeah I know I can post text directly from the terminal:
tcp LISTEN 0 128 0.0.0.0:51413 0.0.0.0:* users:(("transmission-da",pid=1020,fd=15))
tcp LISTEN 0 1000 0.0.0.0:22 0.0.0.0:* users:(("dropbear",pid=765,fd=4))
tcp LISTEN 0 128 0.0.0.0:9091 0.0.0.0:* users:(("transmission-da",pid=1020,fd=14))
tcp LISTEN 0 128 [::]:51413 [::]:* users:(("transmission-da",pid=1020,fd=16))
tcp LISTEN 0 128 *:21 *:* users:(("proftpd",pid=1017,fd=0))
tcp LISTEN 0 1000 [::]:22 [::]:* users:(("dropbear",pid=765,fd=5))
this might have added a killswitch blocking local access as whole traffic is passed thru VPN.
On the LISTEN ports I see FTP, SSH and Transmission running only. Is this the same server you have posted the running services? Because I don’t see any web server stack LISTEN.
I was aware of a killswitch, had issues with it before, so I disabled it. The same problem still happens on the machine without a VPN.
Yes, both of them ran services.
let’s check the web server
systemctl restart lighttpd.service
systemctl status lighttpd.service
journalctl -u lighttpd.service
Interesting
systemctl status lighttpd.service
journalctl -u lighttpd.service
Failed to restart lighttpd.service: Unit lighttpd.service not found.
Unit lighttpd.service could not be found.
-- Journal begins at Sun 2022-09-18 20:38:08 BST, ends at Mon 2022-09-19 14:11:18 BST. --
-- No entries --
Can you share following again
dietpi-services status
This is of course from the other machine with the same problem now
DietPi-Services
─────────────────────────────────────────────────────
Mode: status
[ OK ] DietPi-Services | avahi-daemon active (running) since Sun 2022-09-18 16:22:02 BST; 22h ago
[ OK ] DietPi-Services | proftpd active (running) since Sun 2022-09-18 16:22:26 BST; 22h ago
[ OK ] DietPi-Services | transmission-daemon active (running) since Sun 2022-09-18 16:22:32 BST; 22h ago
[ OK ] DietPi-Services | docker active (running) since Sun 2022-09-18 16:22:42 BST; 22h ago
[ OK ] DietPi-Services | cron active (running) since Sun 2022-09-18 16:22:43 BST; 22h ago
[ OK ] DietPi-Services | dropbear active (running) since Sun 2022-09-18 16:22:01 BST; 22h ago
[ OK ] DietPi-Services | openvpn active (exited) since Sun 2022-09-18 16:22:11 BST; 22h ago
[ OK ] DietPi-Services | dietpi-vpn active (running) since Sun 2022-09-18 16:22:12 BST; 22h ago
[ INFO ] DietPi-Services | dietpi-cloudshell inactive (dead)
[ OK ] DietPi-Services | dietpi-ramlog active (exited) since Sun 2022-09-18 16:22:01 BST; 22h ago
[ OK ] DietPi-Services | dietpi-preboot active (exited) since Sun 2022-09-18 16:22:02 BST; 22h ago
[ OK ] DietPi-Services | dietpi-postboot active (exited) since Sun 2022-09-18 16:22:11 BST; 22h ago
[ INFO ] DietPi-Services | dietpi-wifi-monitor inactive (dead)
ok let’s try to mix your system and fix one by one. It’s quite confusing which services are running on wich system. On the current system we tried to fix lighttpd which is not even installed.
on the actual system, what exactly is not working? I see OpenVPN being active. Can you switch it off? Does it still block some access?
Lighttpd is not installed on this system, because it does not have Nextcloud. It only really had transmission. This is also the one which runs with a VPN.
I tried to switch VPN off entirely, and still no luck. I am now restoring from a backup just to see if it will magically solve it.
Nope, backup didn’t solve it. At least it boots though. I could just reinstall honestly, no data would be lost. But it would be a pity to not isolate the issue.
So you are not able to connect to transmission web UI?
Nope, not on any of the two machines
Can we focus on one system and avoid mixing both? On the one we currently working, how do you access transmission?
We are only talking about one machine, the other one gets stuck on grub. I access transmission the normal way, just the IP and the correct port. I did the same for the other machine, just so you know.
Note: I just completely reinstalled dietpi without a backup on the nextcloud PC. Transmission now lets me access the UI there.
I ended up getting everything working again with a reinstall. Hardly the desired solution, but I am back and running again.
