amd64
these are the 3 packages to download for amd64
https://packages.debian.org/buster/amd64/ifupdown/download
https://packages.debian.org/buster/amd64/iproute2/download
https://packages.debian.org/buster/amd64/isc-dhcp-client/download
download them on an USB stick and mount the stick on your DietPi system. Go into the mounted directory and install the packages using dpkg -i *.deb
I hope it is working this way and no other dependency are missing.
1 Like
during installation error come like this image https://pasteboard.co/JZumKhH.jpg
as unfortunately feared, you are missing some dependency.
Basically you would need to go package by package to have them all together 
If you start with iproute2, you would need as well libcap2-bin
please send me the link, i will download it & put in same folder with same procedure
letās do it step by step and create 3 folder. This way we can avoid conflicts between the 3 packages
first one should contain iproute2 + libcap2-bin
https://packages.debian.org/buster/amd64/iproute2/download
https://packages.debian.org/buster/amd64/libcap2-bin/download
out of four given packages three installed properly one again got error āisc-dhcp-client_4ā
these 2 would be needed as well
https://packages.debian.org/buster/amd64/libdns-export1104/download
https://packages.debian.org/buster/amd64/libisc-export1100/download
Thanks @Joulinar with your guidance, i am able to install those packages & network is again up again, thanks you are always so helpful
ok good itās working again. I guess it was better this way than reinstall whole system. And donāt forget to create a backup now 
Here my guess: The Pi-hole uninstall script allows to purge all its dependency packages, looping through them one after another: https://github.com/pi-hole/pi-hole/blob/master/automated%20install/uninstall.sh#L73-L92
This includes iproute2, the very basic network package, all network capabilities are based on. That is very bad and lead already to many broken systems. Iām gonna make this a topic now on the Pi-hole repository, this is long overdue.
Either packages must only be marked as āautoā, which allows them to be autoremoved afterwards, IF not other package requires them. Due to installed āifupdownā, this would not happen with iproute2 then. I guess in your case ārc ifupdownā was in the ādpkg -lā output, as the package got removed (as dependant of iproute2) but the config file remained (ii = installed, rc = only config files still present).
Also Pi-hole aims to make the install and grants great free user support, which addresses especially inexperienced users. But giving them an easy choice to break the system on regular uninstall works completely against that aim 
.
wtf, how could PiHole recommend to remove essential network packages ??
MichaIng
Should we add a notification window on PiHole uninstall to inform user about the package removal and a recommendation to decalin?
They do not recommend to remove those packages. Although: pi-hole/automated install/uninstall.sh at master Ā· pi-hole/pi-hole Ā· GitHub
All dependencies are safe to remove on Raspbian
That statement is dramatically wrong 
.
Iāll open a PR to change this statement into basically the opposite. As I regularly read issues with this in the Pi-hole forum as well, I think it makes much more sense to support/contribute a fix at Pi-hole itself instead of adding another warning only in our (un)installer, especially since users would be faced with two contradicting statements on RPi then.
what a dangerous statement. Letās try to convince PiHole guys to rework this behaviour
Done: https://github.com/pi-hole/pi-hole/issues/3929
I hope it was not to harsh 
. So issue is known and Dan from Pi-hole sees it like us: āShotgun loaded and handed to userā
Iāll open a PR about the sentence, the thing with the dependency package (best solution I can think of) is a little larger and Iām not sure how big the motivation is to integrate this into Pi-hole v5 while Pi-hole v6 branch is already there and would cause merge conflicts.
thx MichaIng
ok best we can do for the moment. And good to keep in mind if some of our users will run into it again.
Next time someone else should open the PR. Itās impossible for me to succeed with any reasonable commit as fast as Dan is involved 
. Hopefully the other Pi-hole devs override his request to turn my PR into a no-op, while on the issue, everyone agreed on much more alreadyā¦ Iām not gonna contribute the extra free spare time to change one PR, open another one, open both against the v6 branch, and still have only the very minimal short-term solution .
I see a close friendship coming 
I have asked for changes as the maintainer of this repo. Iām not expecting pushback for my requests.
well open minded 
Long story already. Also weāre both stubborn, that doesnāt make it easier. Heās like that to others as well, but at least my impression is that itās becoming very unreasonable when itās about a PR or topic started by me.
I think the matter is now on the table and Iāll wait for at least another maintainers statement before thinking about a degraded PR, as then itās nearly not worth the effort, same with little one time coding changes, that are either part of another commit or simply not done (which is totally fine, just hurts my eyes ).
we have something similar on my company. They call it change management. Each change on a system require an own change ticket