Yes, the build target/tools need to be additionally defined when installing Rust, and the binary is stored in a sub dir. Will fix this and rerun builds after work.
1 Like
Finally, it works on on ARMv6 
.
confirmed. 
is working on my RPi 1 as well
1 Like
There was a vaultwarden update a few days ago. How will it work with future vaultwarden updates? Will you do a build and update via a dietpi patch or something?
1 Like
We will trigger GitHub actions to rebuild the package manually. Update on user side would need to be done via dietpi-software reinstall as usual.
New packages have been created yesterday but we still need to move them in place Index of /downloads/binaries/bullseye/testing
@MichaIng pls could you do that
New packages are in place.
Hi! I’ve just realised I’m on an outdated version of vaultwarden on my pi because I was missing a new feature and wondered why it isnt’t there.
Just to get it right:
- To obtain vaultwarden updates on my pi, I have to manually run “dieptpi-software reinstall 183”?
- And from DietPi version 8.7 onward this command won’t take as much RAM and time as it did in the past?
Yes, both points are correct. To be more precise, with DietPi v8.7 it won’t be compiled in place but a precompiled package installed. The compiling was what took so long and required so much memory before.
Hi guys, I updated DietPi to v8.7 and reinstalled vaultwarden.
Going to https://<your.IP>:8001 fails to connect. Any ideas on how to debug?
Can you check:
journalctl -u vaultwarden
Seems to indicate no .env file found?
Aug 02 13:36:01 DietPi systemd[1]: Started vaultwarden (DietPi).
Aug 02 13:36:01 DietPi vaultwarden[1618]: /--------------------------------------------------------------------\
Aug 02 13:36:01 DietPi vaultwarden[1618]: | Starting Vaultwarden |
Aug 02 13:36:01 DietPi vaultwarden[1618]: |--------------------------------------------------------------------|
Aug 02 13:36:01 DietPi vaultwarden[1618]: | This is an *unofficial* Bitwarden implementation, DO NOT use the |
Aug 02 13:36:01 DietPi vaultwarden[1618]: | official channels to report bugs/features, regardless of client. |
Aug 02 13:36:01 DietPi vaultwarden[1618]: | Send usage/configuration questions or feature requests to: |
Aug 02 13:36:01 DietPi vaultwarden[1618]: | https://vaultwarden.discourse.group/ |
Aug 02 13:36:01 DietPi vaultwarden[1618]: | Report suspected bugs/issues in the software itself at: |
Aug 02 13:36:01 DietPi vaultwarden[1618]: | https://github.com/dani-garcia/vaultwarden/issues/new |
Aug 02 13:36:01 DietPi vaultwarden[1618]: \--------------------------------------------------------------------/
Aug 02 13:36:01 DietPi vaultwarden[1618]: [INFO] No .env file found.
Aug 02 13:36:01 DietPi vaultwarden[1618]: [2022-08-02 13:36:01.678][_][WARN] Detected TLS-enabled liftoff without enabling HSTS.
Aug 02 13:36:01 DietPi vaultwarden[1618]: [2022-08-02 13:36:01.678][_][WARN] Shield has enabled a default HSTS policy.
Aug 02 13:36:01 DietPi vaultwarden[1618]: [2022-08-02 13:36:01.678][start][INFO] Rocket has launched from https://127.0.0.1:8001
Snippet from the install
Configuration file '/mnt/dietpi_userdata/vaultwarden/vaultwarden.env'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
==> Keeping old config file as default.
Configuring vaultwarden service user ...
usermod: no changes
Set vaultwarden userdata owner ...
Configuring vaultwarden systemd service ...
Created symlink /etc/systemd/system/multi-user.target.wants/vaultwarden.service → /lib/systemd/system/vaultwarden.service.
It actually looks all good, the old config file is in place (untouched) and the service seems to be running. Can you check:
ss -tlpn | grep 8001
… Ah, https://127.0.0.1:8001 listening on localhost only. I need to add a patch to the postinst script to cover pre-v1.25.0 installs:
GCI_PRESERVE=1 G_CONFIG_INJECT 'ROCKET_ADDRESS=' 'ROCKET_ADDRESS=0.0.0.0' /mnt/dietpi_userdata/vaultwarden/vaultwarden.env
systemctl restart vaultwarden
LISTEN 0 1024 127.0.0.1:8001 0.0.0.0:* users:(("vaultwarden",pid=1618,fd=38))
Is it something I can easily fix or should I restore from a backup?
The fix has been posted above already
1 Like
I saw the recently released DietPi 8.8 and wanted to check if it fixed my web vault problem.
- I updated DietPi from 8.6 to 8.8
- I updated Vaultwarden
- Web vault access was working, but I could not login “Network error when attempting to fetch resource”
- I rebooted
- Tried web vault again, but this time it would not load, browser reports “Unable to connect”
- I finally decided to just paste the fix previously described “GCI_PRESERVE=1 …” and everything is working.
So whilst the fix works, it’s integration as a part of the whole update process isn’t. At this stage, probably not worth chasing down since it looks like I’m the only one who has the problem!
Thank you all again for all the effort and hard work.
There is no real relation between Valtwarden and DietPi version as we moved Valtwarden into an own Debian package that is created separately. 
The fix you execute was to change the LISTEN address Valtwarden is running on. Due to a change done by Valtwarden, instances are LISTEN to localhost only. Therefore, you were not able to connect. The fix changed this back to LISTEN to all interfaces/addresses. This should just impact versions pre-v1.25.0. Do you recall the Valtwarden version you where running on before?
I don’t recall the exact version, but it was the latest version (1.24?) before the memory compilation issues (RPi3).
The point of my post is that the DietPi 8.8 release notes says that the web vault is fixed. But in my case, it was still broken after updating.
@MichaIng can you have a look. I guess you implemented the fix to the Debian package to change LISTEN address. Isn’t it?
Ah, I guess I need to clear the Cloudflare cache. Please try the reinstall now. The package should have a raised build suffix in the version string.