Unmet dependencies on devtools after upgrading

[arkhub]

Creating a bug report/issue

Required Information

• DietPi version | 6.22.3
• Distro version | buster/sid
• Kernel version | SBC device | Linux MyPiHostname 4.14.98-v7+ Request | RT Kernel option #1200 SMP Tue Feb 12 20:27:48 GMT 2019 armv7l GNU/Linux
• Power supply used | 5V 3A
• SDcard used | 32 Gb class 10

Additional Information (if applicable)

• Software title | mopidy
• Was the software title installed freshly or updated/migrated? fresh install after removing it first
• Can this issue be replicated on a fresh installation of DietPi? | never tried
• dietpi-bugreport ID | sed -n 5p /DietPi/dietpi/.hw_model |
  [FAILED] DietPi-Bugreport | Failed to connect to SFTP server. Please try again later or report this to DietPi forum or GitHub repo in the first place.

Steps to reproduce

1. remove mopidy and wireguard
2. run dietpi-cleaner, check Dev, logs, and Apt
3. update dietpi to 6.22.3
4. reboot
5. install mopidy, failed with unmet dependencies on python and libpython-dev like this

The following packages have unmet dependencies:
 libpython-dev : Depends: libpython2.7-dev (>= 2.7.13-1~) but it is not going to be installed
E: Unable to correct problems, you have held broken packages.

oh and also dietpi bugreport shows error (shown in above), and my raspberry pi 3 B+ shown as "unknown device" in dietpi info, but my older raspberry pi 1 B shows the name.

[MichaIng]

@arkhub
Many thanks for your report.

Yeah I was expecting this case. I am afraid this is due to an issue with the previous WireGuard install the lead to a large part of the system being updated to the Debian Sid (unstable) branch where we pull the WireGuard packages from. I was trying to replicate this but it never happened nor did I find a logic way how this can happen, besides you manually install an explicit package that is not available in the Raspbian repo and that depends on many other updated system packages.

• Reported identical issues: DietPi-Software | WireGuard: Prevent accidental "sid" repo installs #2568, DietPi-Software | WireGuard: RPi upgrades to Debian "sid" repo #2581, DietPi-Software | WireGuard: RPi upgrades to Debian "sid" repo (dupe) #2609
• My testing: Image | Testing updated RPi image #2613 (comment)

With v6.22 the way the Sid repo is used is hardened to disallow any package installs from it, even if requested manually, besides the three WireGuard packages themselves. However in your case this seems to have come too late.

This is a state that is very hard to recover. Do you have any backup from before installing WireGuard at best or before the update to v6.22?
If so check cat /etc/os-release. If it contains buster/sid it is already too late, stretch should be found inside instead.

---

I just changed to DietPi update pre-patch file so the Sid repo block will already be applied before any APT command runs: 256ab79
Most likely the upgrade occurred already earlier, however at least it is thinkable that dietpi-update itself causes the distro upgrade when running it's APT commands.

[MichaIng]

Just checked some other guides an not found one that restricts Sid repo stricter. Even repo-wide priority 150 is used in cases: https://github.com/adrianmihalko/raspberrypiwireguard

• Although it does not help if one ran into the issue, at least it tells us that we are not dump 😕.

[arkhub]

This is a state that is very hard to recover. Do you have any backup from before installing WireGuard at best or before the update to v6.22?
If so check cat /etc/os-release. If it contains buster/sid it is already too late, stretch should be found inside instead.

Unfortunately I have clean reinstall my dietpi and now using stretch and I don't have any backup of previous device. as for now it shows my device as Raspberry Pi 3 B+ instead of unknown device.

[MichaIng]

@arkhub
Okay I hope it was not too much hassle. Although the WireGuard install has been hardened to prevent the issue, at best if you want to try it (again), do a dietpi-backup first and check cat /etc/os-release afterwards to verify it's still Stretch. An anormal large number of APT packages being upgraded would also indicate the distro upgrade. So if this happens you can easily revert.

[MichaIng]

I mark this issue as closed now, however feel free to reopen if required.