Markus did split this topic from another one and put up this title, because he thought it has something to do with promoting ipv6 over ipv4. As I mentioned before I am not an IT-guy and I am just doing what you guys tell me to do in the hope to solve this.
But I agree that it could be a DHCP-server problem. No idea how to solve that. So I will stick to my solution mentioned in my first post, although there should be a more elegant way I’m sure.
Oh dear, I hadn’t realized you’re missing ipv4 connectivity, too. Sorry.
Well then, thanks for your help. At least this helped me in getting the ipv6 disable patch done 
You’re welcome to test it once it’s merged … again 
Ok for ipv4 to fail I’m fairly sure it’s an issue with your router (assuming your router is also your dhcp server).
Check your router config on that. Most have an input field for a range of addresses they are to use to assign (IPv4 usually) addresses to clients from and I’d guess that’s missing or has a bad syntax.
And some enforce your client’s MAC address to be known to them. Usually there’s an editable whitelist on your router or at least a kind of setting like ‘allow all new hardware addresses’ or none or just known ones. See if you have something alike.
Happy to help with my limited skills. Concernig the dhcp-server/router I’m pretty sure it is not that simple as the ip-range setting. Like I said my solution of the first post would not work either if that was the case.
To be more precise: Here I found exactly the problem I’ve got:
https://debianforum.de/forum/viewtopic.php?t=173931
I also see a ipv4 address when I apply sudo dhclient -r : DHCPRELEASE of 192.168.178.12 (excactly the ipnr I have reserved in the router)
So it seems that you have a mostly valid dhcp lease and with that command you are releasing it.
Can you translate most important parts? I’d like to know the exact cause so these can be avoided in the future.
Markus is German so I guess he can translate and is more knowledgeable. I am Dutch, so its a little more difficult for me. But if he doesn’t have the time I will.
1 Like
If I got the essence right:
The OP there uses plain debian buster, he does not mention the HW but it’s quite certainly not a RPi.
His problem is that the ifupdown package since version 0.8.35 uses DUID in dhclient, i.e. it runs dhclient with option “-i” and sends a longer CID. That seems to be incompatible with the OP’s network environment (DHCP server). It’s apparently hardcoded in the package so cannot be changed easily.
He also copied ifup from stretch for a test - that then requires an additional auto en32 in the interface definition but works.
Fix for the time being is to install a different DHCP client.
Now that’s fairly deep inside debian/Raspbian so I’m wary to change anything about that on openHABian level.
EDIT: there’s a bug report on this. but it’s a year old and the package version has not changed since (in neither buster nor bullseye/testing nor sid/unstable).
1 Like
Thanks for the translation, @mstormi 
I also think that this doesn’t involve openHABian.
But let me see. I have a spare Rpi 3 and I’ll flash latest buster to it and see what it does.
@Emiks5 what does # ifup -V output on your system?
ifup -V gives ifup version 0.8.35
1 Like
Please do. Just an idea, maybe try force to downgrade to an older version of the ifupdown package ?
I’d guess once installed it would work to upgrade back to buster level.
I’d eventually provide a patch to combine that with no-ipv6 as a sort of “rescue mode” that a user could enforce via openhabian.conf when default install does not work for him.
And just for the first boot?
Because I reproduced your situation that only IPv6 address is acquired. Looks like dhcpcd gets killed during boot because start-job timeout occurs. Something is hogging all the cpu and 3 start jobs run concurrently. One of them is dhcpcd which then gets killed and rest of the jobs finish. For more than 10 minutes the command line is really slow. Even logging in takes about 30 seconds.
systemd-analyze blame shows that apt-daily.service and man-db.service takes 10 minutes each to finish.
Nevertheless after boot has finished even without IPv4 address sudo apt update runs just fine and suggests to update 44 packages.
Hmm, I’m not convinced yet. There’s so little information to support that this is the root cause.
No if I don’t use my fix, like I showed in my first post, I cannot get an ipv4 address I think. But than again I never try that anymore, because I have got this fix which works for me. I could try a newly install Raspian though to check this.
Wow you are on to something. Exaclty what happens here. But in your case the install finishes in one run without a failure?
No i’m just testing with plain buster and not with openHABian.
Just did a restart and it got the IPv4 address but it took 1 minute 20 seconds. 15 seconds before the timeout it finished. 
I have been trying a few things.
-After first install openHABian (and stopping by failure), ifconfig gives a 169.254.x.x address
-After sudo dhclient -v -r ifconfig gives no ipv address anymore
-After sudo dhclient -v ifconfig gives the right 192.168 address
I just installed Raspian Buster but after reboot I did not get a ipv4 nr only ipv6,
after apt update it did indeed suggest update for 44 packages. Si ipv6 is working. But eg ping 8.8.8.8 says network is unreachable.
but dhclient -r and dhclient gives a proper ipv4 address.
What i don’t understand is that sudo ifup eth0 says unkbown interface eth0. Or is that nornal?
-r flag is just for releasing your dhcp lease so this works as expected. You can use these as a one liner:
sudo dhclient -v -r && sudo dhclient -v
Yes. The delay and timeout happens only during boot. I noticed that upgrading all packages reduced dhcpcd.service runtime by a minute.
They are obsolete commands. Same goes for /etc/network/interfaces and it should not be used anymore. FYI if you want a static ip for your raspberry you’re supposed to use dhcpcd.conf. For example here’s part of my config. Raspberry 2 running pihole which is my dns and dhcp server:
interface eth0
static ip_address=192.168.0.252/24
static routers=192.168.0.254
static domain_name_servers=127.0.0.1
Thanks I willl try fiddling with that
Starting to think that I have a defect RPi or my usb stick is failing on me as I’m using USB boot. I noticed that resizing the filesystem times out too at boot. Don’t have another Rpi or a spare SD card to do more testing. @Emiks5 is there a chance that you have some spare devices?
I’ll continue my tests when/if I get a new rpi or somebody has a new idea how to debug.
Hi Miika, I’m sorry but I don’t have a spare one lying around. My other 3 Rpis are running 24/7 as home automation device running Pilight (controlling 433 Mhz devices), camera server running motioneye and dns/vpn server running pihole and openvpn.
With the one I have been testing openHABian I will go ahead running openHABian and trying to connect to the pilight-rpi. The pilight-rpi will eventually only be my 433Mhz-hub for Openhab. Atleast that is the idea.
Nice. I’m running pihole on one Rpi which in fact is also my dhcp sever.
To the point. I found a spare 32GB SD card. I flashed it the same way using Raspbian Lite and Raspberry Pi Imager v1.2. Everything works like a charm and much more faster. After all in my case this was a hardware problem. Hope you can test with a different setup to reproduce this.
PS. Now fighting with ULA addresses 
@Emiks5 mind testing the new openHABian image in your env? It’s based on May’s new Raspi OS so there might have been changes to affect DHCP etc.