Dietpi fail to find eithernet connection at boot time

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.

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 :roll_eyes:

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”

https://pasteboard.co/JZuyaBQ.jpg

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 :wink:

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 :open_mouth:.

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: https://github.com/pi-hole/pi-hole/blob/master/automated%20install/uninstall.sh#L210

All dependencies are safe to remove on Raspbian

That statement is dramatically wrong :thinking:.

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 :roll_eyes:

Done: https://github.com/pi-hole/pi-hole/issues/3929
I hope it was not to harsh :slight_smile:. 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 :frowning:. 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 :roll_eyes:.

I see a close friendship coming :stuck_out_tongue:

I have asked for changes as the maintainer of this repo. I’m not expecting pushback for my requests.

well open minded :rofl:

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 :roll_eyes:).

we have something similar on my company. They call it change management. Each change on a system require an own change ticket :roll_eyes: