To be more specific, drakx-installer-images BR's dhcp-client, libguestfs BR's and Requries's dhcp-client, and clusterscripts-server-pxe and pxe Requires dhcp-server.

Source RPM: dhcp-4.4.3-2.mga9.src.rpm => dhcp-4.4.3P1-1.mga9.src.rpm

Given the elements luigi cites, assigning this to the tools group.

As I need a DHCP server for my env, I've started to work on adding the kea server to mga8, writing the spec file, based on the Fedora one. We miss some other packages so this will take a bit of time before it's ready.

However, I wonder whether we should now drop dhcpd. THe announce dates from the 5th of october. If a group of volunteers jump on the maintenance, we could still keep it, as it's too early to say. Considring how widely that server is used, I'd be surprised everybody moves just like that. Non talking of the conf file modifications that could make the replacement difficult (especially when updating a package). Have not looked at that yet.

CC: (none) => bruno

I use it too, but we can't just assume someone will maintain it for the life of Mageia 9.  Remember if that changes it could be revived later.

Ping!

CC: (none) => fri

i am packaging kea for mageia

Status: NEW => ASSIGNED
CC: (none) => mageia

I have updated the installer and drakx-net to use dhcpcd by default, and have changed the Recommends in initscripts. I have removed the BuildRequires dhcp-client from drakx-installer images, which wasn't needed anyway (stage1 has its own standalone dhcp client implementation).

For dhcp-client, that leaves libguestfs with a BuildRequires and vpnpptp with a Recommends, and resolvconf, compute-image-packages, ntp, chrony, cloud-init, and dhcp putting dhclient hooks in /etc.

Reassigning to all packagers for the remaining cleanup.

Assignee: mageiatools => pkg-bugs
CC: (none) => mageia

I guess we should write something in release notes.
Suggestion?

Keywords: (none) => FOR_RELEASENOTES9

my kea package is almost done. 

I can finish it tomorow

Should we write

  "DHCP is EOL and will be replaced by kea some time after Mageia 9 release."

?

We can't replace it after the release.  It's now or never.

Now or never for mga9 i suppose you mean :)
RC seem to be very soon, so looks like never.
The switch will be for mga10 it seems, correct me if wrong.

We do not yet have a tracker bug for packages to remove for 10 nor a FOR_RELEASENOTES10 flag.

Temporarily removing those from mga9 and also release blocker level so it gets off mga9 radar.

Blocks: 30163 => (none)
Priority: release_blocker => High
Status comment: (none) => For rel notes 10 and packages to remove in 10
Keywords: FOR_RELEASENOTES9 => (none)
Target Milestone: Mageia 9 => Mageia 10

Added to the tracker for mga10

Status comment: For rel notes 10 and packages to remove in 10 => For rel notes 10
Blocks: (none) => 32127

As discussed on the qa-discuss ML, the change from dhcp-client to dhcpcd broke the ability of the classical ISO to start networking when updating a Mageia 8 system that was configured to use the legacy network scripts. Whilst investigating this it was also noticed that when using the legacy network scripts, the DHCP client is selected in the ifcfg files, so any attempt to obsolete dhcp-client would also have to update those files.

As we are too close to the Mageia 9 release to properly fix these issues, the changes to the installer/drakx-net/initscripts/meta-task have been reverted to again default to using dhcp-client.

So what is the status of this now in mga10/Cauldron?

Keywords: (none) => FOR_RELEASENOTES10
Status comment: For rel notes 10 => (none)

Status? - target is set for Mageia 10, release blocker.

Because ISC kea has been mentioned in this context I want to note that while the ISC dhcpd server included a client component the ISC kea server does not. ISC kea has been packaged for a little while now in cauldron but once again, there is no client component so it cannot help with this problem.

Fedora mentions two options that they looked (or were looking) at. One is dhcpcd as mentioned above and the other is a dhcp client implementation built into network-manager. They did say that they preferred network-manager but that there were differences with how the latter worked compared to dhclient. I don't know at this point what they ended up using or what it took to fix their tooling.

https://fedoraproject.org/wiki/Changes/dhclient_deprecation

CC: (none) => mhrambo3501

Could be more easy use systemd-networkd?
https://serverfault.com/questions/1108989/isc-dhcp-client-dhclient-alternative

Change keyword to flag status

Keywords: FOR_RELEASENOTES10 => (none)
Flags: (none) => in_release_notes10?

At least on RHEL, it just uses the dhcp client built into NetworkManager, so I would guess Fedora did the same thing.  We already have dhcpcd packaged and have support for it in our tools/installer, so we could just default to that instead of dhclient.

I considered suggesting we just switched to NetworkManager, but AFAIK it requires systemd, so won't work in the installer. IMO changing the installer to use systemd is too big a step if we want to release Mageia 10 soon.

I tried switching the default to dhcpd for Mageia 9, but see comment 14. We would need to change the DHCP_CLIENT setting all the user's ifcfg scripts during an upgrade. That's the bit I'm not confident about doing correctly myself, which is why I asked for help on the dev ML.

As well as requiring systemd, systemd-networkd would also require a major rework of drakx-net, so that's a non-starter.

Postponing to next release then.

Priority: release_blocker => High
Status comment: (none) => For releaseotes 11 if implemented then
Flags: in_release_notes10? => in_release_notes10-
Target Milestone: Mageia 10 => Mageia 11

(In reply to katnatek from comment #18)
> Could be more easy use systemd-networkd?
> https://serverfault.com/questions/1108989/isc-dhcp-client-dhclient-
> alternative

The link have other alternatives

FTR, in MondoRescue, I've used the dhcpcd client part of busybox for years without issue. Busybox is very small and could be easily include,d providing what we need during early boot stages.

Maybe a crazy idea but as we need also set date & time early bug#34909
Why not force to redo network configuration in upgrades, just getting basic information like hostname from the destination system?

If we want to release Mageia 10 quickly, big changes to the installer and drakx tools are out. For Mageia 11, sure, we need to seriously discuss the future of the Mageia tools. For that we need to start proper release planning as soon as Mageia 10 is released, rather than just drifting along as we have done for the past three releases.

Back to this bug. I'm sure it can be fixed by replacing dhcp-client with dhcpcd, which we already have packaged. But it needs a post-install scriptlet to handle the necessary changes to the user's ifcfg files. I'm not a packager, so I don't want to try doing this myself.

(In reply to Martin Whitaker from comment #26)
> If we want to release Mageia 10 quickly, big changes to the installer and
> drakx tools are out. For Mageia 11, sure, we need to seriously discuss the
> future of the Mageia tools. For that we need to start proper release
> planning as soon as Mageia 10 is released, rather than just drifting along
> as we have done for the past three releases.
> 
> Back to this bug. I'm sure it can be fixed by replacing dhcp-client with
> dhcpcd, which we already have packaged. But it needs a post-install
> scriptlet to handle the necessary changes to the user's ifcfg files. I'm not
> a packager, so I don't want to try doing this myself.

If you give an example of what actions need to be done, perhaps some one jump to do it

(In reply to katnatek from comment #27)
> If you give an example of what actions need to be done, perhaps some one
> jump to do it

See comment 21.

After uninstall dhcp-client and install dhcpcd 

https://serverfault.com/a/1192967
dhcpcd -n eno1
no such user dhcpcd
dhcpcd-10.1.0 starting
/lib64/dhcpcd-hooks/50-ypbind: line 71: syntax error near unexpected token `;'
/lib64/dhcpcd-hooks/50-ypbind: line 71: `       ;'
/lib64/dhcpcd-hooks/50-ypbind: line 71: syntax error near unexpected token `;'
/lib64/dhcpcd-hooks/50-ypbind: line 71: `       ;'
DUID 00:01:00:01:30:ed:ad:cb:e0:69:95:dd:cd:47
eno1: IAID 95:dd:cd:47
eno1: soliciting an IPv6 router
eno1: Router Advertisement from fe80::1250:72ff:fee6:7020
eno1: adding address 2806:104e:1b:5042:154a:d7ff:36d1:af4f/64
eno1: adding route to 2806:104e:1b:5042::/64
eno1: adding default route via fe80::1250:72ff:fee6:7020
eno1: soliciting a DHCP lease
eno1: offered 192.168.1.69 from 192.168.1.254
eno1: probing address 192.168.1.69/24
/lib64/dhcpcd-hooks/50-ypbind: line 71: syntax error near unexpected token `;'
/lib64/dhcpcd-hooks/50-ypbind: line 71: `       ;'


In the line 71 I just see the ;

I'll check the mentioned dhcpcd-base to see what debian do

For the moment I not have issues in my network due I set static address

https://salsa.debian.org/debian/dhcpcd/-/blob/debian/latest/debian/NEWS?ref_type=heads

(In reply to katnatek from comment #29)
> After uninstall dhcp-client and install dhcpcd 
> 
> https://serverfault.com/a/1192967
> dhcpcd -n eno1
> no such user dhcpcd

This is asking for a dhcpcd system user.

> dhcpcd-10.1.0 starting
> /lib64/dhcpcd-hooks/50-ypbind: line 71: syntax error near unexpected token
> `;'
> /lib64/dhcpcd-hooks/50-ypbind: line 71: `       ;'
> /lib64/dhcpcd-hooks/50-ypbind: line 71: syntax error near unexpected token
> `;'
> /lib64/dhcpcd-hooks/50-ypbind: line 71: `       ;'
> DUID 00:01:00:01:30:ed:ad:cb:e0:69:95:dd:cd:47
> eno1: IAID 95:dd:cd:47
> eno1: soliciting an IPv6 router
> eno1: Router Advertisement from fe80::1250:72ff:fee6:7020
> eno1: adding address 2806:104e:1b:5042:154a:d7ff:36d1:af4f/64
> eno1: adding route to 2806:104e:1b:5042::/64
> eno1: adding default route via fe80::1250:72ff:fee6:7020
> eno1: soliciting a DHCP lease
> eno1: offered 192.168.1.69 from 192.168.1.254
> eno1: probing address 192.168.1.69/24
> /lib64/dhcpcd-hooks/50-ypbind: line 71: syntax error near unexpected token
> `;'
> /lib64/dhcpcd-hooks/50-ypbind: line 71: `       ;'
> 
> 
> In the line 71 I just see the ;
> 

That semi-colon needs to change to a full colon (s/;/:/) on line 71. It is basically a no-op statement.

grepping for dhclient I come up with these two files in /etc/sysconfig/network-scripts.

/etc/sysconfig/network-scripts/ifup-eth
/etc/sysconfig/network-scripts/network-functions

/etc/sysconfig/network-scripts/ifup-eth already has support for several dhcp clients including dhcpcd. AFAICS it's ready to go.

network-functions dhclient references appear to be about lease files. I don't know if dhcpcd needs this or not. It could be dhclient specific I guess.

If the semi-colon is changed into a colon and the dhcpd user added all the error message go away. I think my system may have worked on wired ethernet without further change but I was too late in figuring out what was happening to test that.

For wireless it is a different story.

dhclient is also referenced in all the files in

/etc/sysconfig/network-scripts/wireless.d/

and the file

/etc/sysconfig/network-scripts/ifcfg-wlp9s0

on my laptop.

Changing dhclient to dhcpcd in all of these files results in my laptop booting from cold with the network coming up without any interaction (using dhcpcd with the dhcp-common and dhcp-client uninstalled).

I don't know why the wireless files would individually specify a specific dhcp client instead of using some system default, but they do. I haven't figured out yet where that comes from. It looks like Mageia is nearly ready to use dhcpcd for wired connections. Wireless is a different story - and is a show stopper at present. I'm still looking on the wifi problem.

(In reply to Martin Whitaker from comment #21)
> I considered suggesting we just switched to NetworkManager, but AFAIK it
> requires systemd, so won't work in the installer. IMO changing the installer
> to use systemd is too big a step if we want to release Mageia 10 soon.
> 

In case it is relevant, I see slackware uses NetworkManager and they don't have systemd. I also saw mention in a Gnome forum to the same effect. I have no idea if they do anything special to get NM to work without systemd (or conversely whether Mageia has done something to generate the dependency) but it may work fine without.

I have followed the instructions there

https://wiki.mageia.org/en/Switching_to_networkmanager

on all my machines using wifi and it just works. The dhcp-common and dhcp-client rpms can be removed at that point and near as I can tell there is no deficiency. But that is only four laptops - not a very large test pool. I don't have any of the keyfiles Jani mentioned but NM may be using the existing ifcfg files so there is that.

(In reply to Mike Rambo from comment #32)
> (In reply to Martin Whitaker from comment #21)
> > I considered suggesting we just switched to NetworkManager, but AFAIK it
> > requires systemd, so won't work in the installer. IMO changing the installer
> > to use systemd is too big a step if we want to release Mageia 10 soon.
> > 
> 
> In case it is relevant, I see slackware uses NetworkManager and they don't
> have systemd. I also saw mention in a Gnome forum to the same effect. I have
> no idea if they do anything special to get NM to work without systemd (or
> conversely whether Mageia has done something to generate the dependency) but
> it may work fine without.

My (possibly incorrect) understanding is that NetworkManager uses D-Bus, which in Mageia is provided by systemd. On systems that don't use systemd, I believe there is an alternative D-Bus broker.

> I have followed the instructions there
> 
> https://wiki.mageia.org/en/Switching_to_networkmanager
> 
> on all my machines using wifi and it just works. The dhcp-common and
> dhcp-client rpms can be removed at that point and near as I can tell there
> is no deficiency. But that is only four laptops - not a very large test
> pool. I don't have any of the keyfiles Jani mentioned but NM may be using
> the existing ifcfg files so there is that.

Yes, currently Mageia uses the ifcfg-rh backend for NM, so the information is stored in the ifcfg files. This allowed the drakx network management tools to continue to work with minimal changes. I've been using NM in Mageia for many years now, and it has never given me any problem.

dhcpcd-10.1.0-3.mga10 should silence the messages katnatek mentioned in Comment 29.

After additional testing my comments in Comment 31 about needing to change the references to dhclient in

/etc/sysconfig/network-scripts/wireless.d/*

and the file

/etc/sysconfig/network-scripts/ifcfg-wlp9s0

appear to only be valid if we switch to dhcpcd. NetworkManager seems not to care about what DHCP_CLIENT is set to in those files. When I tested dhcpcd my experience was that those parameters had to change for wireless connections to work.

(In reply to Mike Rambo from comment #34)
> dhcpcd-10.1.0-3.mga10 should silence the messages katnatek mentioned in
> Comment 29.
> 
> After additional testing my comments in Comment 31 about needing to change
> the references to dhclient in
> 
> /etc/sysconfig/network-scripts/wireless.d/*
> 
> and the file
> 
> /etc/sysconfig/network-scripts/ifcfg-wlp9s0
> 
> appear to only be valid if we switch to dhcpcd. NetworkManager seems not to
> care about what DHCP_CLIENT is set to in those files. When I tested dhcpcd
> my experience was that those parameters had to change for wireless
> connections to work.

s/connections to work/connections to work without dhclient installed/

@Mike: Are you gathering information or writing a script that would perform these tasks ?

If the former, then I can help you with the later. I think it could be associated as a %post action when we install dhcpcd with mga10 in replacement of dhclient.

But on my system, e.g., dhcpcd i s already installed, so that should also be launched during upgrades of the package.

What do others think ?

In addition the debian link have some recomendations

(In reply to katnatek from comment #30)
> https://salsa.debian.org/debian/dhcpcd/-/blob/debian/latest/debian/
> NEWS?ref_type=heads

 Before (dhclient for IPv4 and kernel SLAAC for IPv6):

    iface lan0 inet dhcp
    iface lan0 inet6 auto

    After (dhcpcd handles DHCPv4, DHCPv6, IPv4LL and SLAAC):

    iface enp4s0 inet dhcp

So If we do specific inet6 lines in our scripts they could be removed

(In reply to katnatek from comment #37)
>  Before (dhclient for IPv4 and kernel SLAAC for IPv6):
> 
>     iface lan0 inet dhcp
>     iface lan0 inet6 auto
> 
>     After (dhcpcd handles DHCPv4, DHCPv6, IPv4LL and SLAAC):
> 
>     iface enp4s0 inet dhcp
> 
> So If we do specific inet6 lines in our scripts they could be removed

What about those of us who explisitly do not want IPv6 configured?

@Mike, yes that generally matches what I found when I tried to make the switch for Mageia 9. NM uses its own dhcp client, so ignores the DHCP_CLIENT line. My possibly faulty recollection is that the ifcfg files for wired connections also contain a DHCP_CLIENT line and needed to be modified for use with dhcpcd.

(In reply to Johnny A. Solbu from comment #38)
> (In reply to katnatek from comment #37)
> >  Before (dhclient for IPv4 and kernel SLAAC for IPv6):
> > 
> >     iface lan0 inet dhcp
> >     iface lan0 inet6 auto
> > 
> >     After (dhcpcd handles DHCPv4, DHCPv6, IPv4LL and SLAAC):
> > 
> >     iface enp4s0 inet dhcp
> > 
> > So If we do specific inet6 lines in our scripts they could be removed
> 
> What about those of us who explisitly do not want IPv6 configured?

I guess this still works

net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.all.disable_ipv6 = 1
 
in /etc/sysctl.d/51-drakx.conf

First, I was seeing some "dhcpcd manager hangup" errors so dhcpcd-10.3.0-1.mga10 is out there now which doesn't seem to do that - or at least so far.

@Johnny - in addition to what katnatek suggested, the arch wiki says noipv6rs and noipv6 in /etc/dhcpcd.conf will disable ipv6. (I haven't personally tested this)

@Bruno - right now I'm just trying to contribute to finding a path to a solution. I know how I would make those changes with a bash script on my machine but I'm not very knowledgeable about such things in a rpm spec file. With NetworkManager we wouldn't even need to worry about it I don't think.

After playing with dhcpcd and comparing with NetworkManager I definitely wish we could do the latter. It feels much cleaner to me and less finicky. My hardware installs appear to start dhcpcd at boot without trouble but my virtualbox VM never does and I cannot figure out why yet.

Martin, I believe you're correct about the DHCP_CLIENT lines.  It should be as simple as doing a sed -i -e 's|DHCP_CLIENT=dhclient|DHCP_CLIENT=dhcpcd|' /etc/sysconfig/network-scripts/ifcfg-* in a scriplet, or something very close to that.  I do wonder what it looks like if someone is using NM's keyfile plugin.

Getting current configurations migrated is not the only problem. Any new connections created via MCC going forward also have to be built with the correct configuration. It looks like this is in the libdrakx-net package. Applying the following to ethernet.pm results wifi config files with dhcpcd instead of dhclient and prompts to install dhcpcd instead dhcp-client if needed.

<diff>
--- /usr/lib/libDrakX/network/connection/ethernet.pm    2026-01-05 19:35:04.950966142 -0500
+++ ethernet.pm 2026-01-05 19:35:53.742476662 -0500
@@ -7,7 +7,7 @@
 use common;
 use network::tools;
 
-our @dhcp_clients = qw(dhclient dhcpcd pump dhcpxd);
+our @dhcp_clients = qw(dhcpcd pump dhcpxd);
 
 sub get_type_name() { N("Ethernet") }
 sub get_type_description() { N("Wired (Ethernet)") }
@@ -318,7 +318,7 @@
 sub install_dhcp_client {
     my ($in, $client) = @_;
     my %packages = (
-        "dhclient" => "dhcp-client",
+        "dhcpcd" => "dhcpcd",
     );
     #- use default dhcp client if none is provided
     $client ||= $dhcp_clients[0];
</diff>

The four dhcp_clients listed are the same four referenced in /etc/sysconfig/network-scripts/ifup-eth. I don't know a great deal about perl but it looks to me like they consider dhclient to the the default in ethernet.pm by virtue of it's place first in the list. When I made the above change on my machine and then deleted and added back the connection via MCC the resulting file in /etc/sysconfig/network-script/wireless.d/ contained the correct DHCP_CLIENT=dhcpcd statement and prompted to install the dhcpcd package.

Moreover, it looks like the files in the files in /etc/sysconfig/network-script/wireless.d/ are the most important because my recreated ifcfg-wlp9s0 file did not contain a reference to DHCP_CLIENT for some reason.

Any ideas on how to confirm this is correct and get decent testing on the changes?

(In reply to Mike Rambo from comment #43)
> Getting current configurations migrated is not the only problem. Any new
> connections created via MCC going forward also have to be built with the
> correct configuration. It looks like this is in the libdrakx-net package.
> Applying the following to ethernet.pm results wifi config files with dhcpcd
> instead of dhclient and prompts to install dhcpcd instead dhcp-client if
> needed.
> 
> <diff>
> --- /usr/lib/libDrakX/network/connection/ethernet.pm    2026-01-05
> 19:35:04.950966142 -0500
> +++ ethernet.pm 2026-01-05 19:35:53.742476662 -0500
> @@ -7,7 +7,7 @@
>  use common;
>  use network::tools;
>  
> -our @dhcp_clients = qw(dhclient dhcpcd pump dhcpxd);
> +our @dhcp_clients = qw(dhcpcd pump dhcpxd);
>  
>  sub get_type_name() { N("Ethernet") }
>  sub get_type_description() { N("Wired (Ethernet)") }
> @@ -318,7 +318,7 @@
>  sub install_dhcp_client {
>      my ($in, $client) = @_;
>      my %packages = (
> -        "dhclient" => "dhcp-client",
> +        "dhcpcd" => "dhcpcd",
>      );
>      #- use default dhcp client if none is provided
>      $client ||= $dhcp_clients[0];
> </diff>
> 
> The four dhcp_clients listed are the same four referenced in
> /etc/sysconfig/network-scripts/ifup-eth. I don't know a great deal about
> perl but it looks to me like they consider dhclient to the the default in
> ethernet.pm by virtue of it's place first in the list. When I made the above
> change on my machine and then deleted and added back the connection via MCC
> the resulting file in /etc/sysconfig/network-script/wireless.d/ contained
> the correct DHCP_CLIENT=dhcpcd statement and prompted to install the dhcpcd
> package.
> 
> Moreover, it looks like the files in the files in
> /etc/sysconfig/network-script/wireless.d/ are the most important because my
> recreated ifcfg-wlp9s0 file did not contain a reference to DHCP_CLIENT for
> some reason.
> 
> Any ideas on how to confirm this is correct and get decent testing on the
> changes?

After do the change reconfigure the current connection, check the generated file not includes old dhcp-client & include dhcpcd, reboot (& optional pray)
If when you reboot have network connection, the maintainer can provide a testing package for wide use/test

(In reply to katnatek from comment #44)
> (In reply to Mike Rambo from comment #43)
> > 
> > Any ideas on how to confirm this is correct and get decent testing on the
> > changes?
> 
> After do the change reconfigure the current connection, check the generated
> file not includes old dhcp-client & include dhcpcd, reboot (& optional pray)
> If when you reboot have network connection, the maintainer can provide a
> testing package for wide use/test

I have already done that testing on the machines I have. But I only have a few with wifi and only one of those is cauldron. On that machine I wiped the configurations for both the wifi and wired connections (separately so I'd have one available if needed) and then added them back. For both wifi and wired connections they were added back correctly and on the first one attempted it downloaded and installed dhcpcd because I has removed that before I started too (along with dhcp-common and dhcp-client). The other machines with wifi and Mageia are all mga9 but I tried one of them too and had a similar result. In all cases the DHCP_CLIENT assignment is for dhcpcd.

My question was more about whether all the bases have been covered - i.e. - have I found everything that needs to change and done it right. A test base of more than two machine would seem advisable too.

(In reply to David Walser from comment #42)
> I do wonder what it looks like if someone is using NM's
> keyfile plugin.

This is verging on off topic for dhcpcd but for a future NetworkManager change it might be relevant.

I have found that 'nmcli connection migrate' would appear to be the ticket. It takes all of the ifcfg- connections and migrates them to files with .nmconnection extension and puts them in /etc/NetworkManager/system-connections/.

What was

HWADDR=e0:d5:5e:a2:de:a4
TYPE=Ethernet
PROXY_METHOD=none
BROWSER_ONLY=no
BOOTPROTO=static
DEFROUTE=yes
IPADDR=192.168.0.52
PREFIX=24
GATEWAY=192.168.0.254
DOMAIN=example.org
IPV6INIT=no
DNS1=192.168.0.52
DNS2=8.8.8.8
DNS3=8.8.4.4
IPV4_FAILURE_FATAL=no
IPV6INIT=no
PEERROUTES=no
NAME="enp0s31f6"
ONBOOT=yes
AUTOCONNECT_PRIORITY=-999
DEVICE="enp0s31f6"

is converted to

[connection]
id=enp0s31f6
uuid=abf4c85b-57cc-4484-4fa9-b4a71689c359
type=ethernet
autoconnect-priority=-999
interface-name=enp0s31f6

[ethernet]
mac-address=E0:D5:5E:A2:DE:A4

[ipv4]
address1=192.168.0.52/24,192.168.0.254
dns=192.168.0.52;8.8.8.8;8.8.4.4;
dns-search=example.org;
ignore-auto-routes=true
method=manual

[ipv6]
addr-gen-mode=stable-privacy
method=ignore
never-default=true

[proxy]

If you try this back up your ifcfg- files first. I think it deletes them.

https://opensource.com/article/22/8/migrate-networkmanager-keyfiles-configuration

My concern was if the DHCP_CLIENT setting was in the configuration and the ifcfg files had already been migrated to keyfile format.  But maybe only network-scripts use the DHCP_CLIENT setting and if you're using NM it doesn't matter?

@David - Martin said in Comment 39 that NetworkManager ignores the DHCP_CLIENT settings if they exist. Fwiw, my experience has indicated the same.

@Martin - so after all of the preceding comments, where does this stand? When I reread the bug I see you already had what I wrote in Comment 43 all the way back in Comment 7. I think David had the other piece of the puzzle in Comment 42 except that it needs to be done in two places, not just the ifcfg files. The second set of files are the wifi configurations in /etc/sysconfig/network-scripts/wireless.d/. All the files in that location are relevant on the machines I've looked at. There will be a few of them if you've connected to very many wifi access points over time.

When someone fixes the dhcpcd package to migrate the connections should dhcp-client be obsoleted or conflicted at the same time?

Has all of this gotten us any closer to the solution?

dhcpcd-10.3.0-2.mga10 is in updates_testing

I added code in %%post to migrate any DHCP_CLIENT=dhclient statements in ifcfg- files to dhcpcd instead of dhclient. The same was done for wifi configurations in /etc/sysconfig/network-scripts/wireless.d except that the action was made conditional on the presence of configurations in that location which would not be the case on a machine with no wifi. Without that there were errors shown at installation.

I also obsoleted dhcp-client per the Mageia policy that the package replacing an old package should be where the old package is obsoleted.

I spent yesterday testing the update and when paired with the minimal changes I wrote in Comment 43 to ethernet.pm in libdrakx-net, the update both migrated existing wired and wireless configurations where the DHCP_CLIENT parameter is present and also created new network device configurations with the correct parameter.

Thanks for working on this Mike. Once the package moves to release, we'll need to reinstate the changes to drakx described in comment 7. I can take care of that.

Should it be assigned to QA ?

Sorry for the spanish text

urpmi https://ftp5.gwdg.de/pub/linux/mageia/distrib/cauldron/x86_64/media/core/updates_testing/dhcpcd-10.3.0-2.mga10.x86_64.rpm


instalando dhcpcd-10.3.0-2.mga10.x86_64.rpm desde /var/cache/urpmi/partial
Preparando...                    #######################################################################################
      1/1: dhcpcd                #######################################################################################
quitando paquete dhcp-client-3:4.4.3P1-4.mga10.x86_64
      1/1: quitando dhcp-client-3:4.4.3P1-4.mga10.x86_64
                                 #######################################################################################

dhcpcd -n eno1
dhcpcd-10.3.0 starting
DUID 00:01:00:01:30:f9:82:1c:e0:69:95:dd:cd:47
eno1: IAID 95:dd:cd:47
eno1: soliciting an IPv6 router
eno1: Router Advertisement from fe80::1250:72ff:fee6:7020
eno1: adding address 2806:104e:1b:3149:e7fa:dc8d:4a5a:e553/64
eno1: adding route to 2806:104e:1b:3149::/64
eno1: adding default route via fe80::1250:72ff:fee6:7020
eno1: soliciting a DHCP lease
eno1: offered 192.168.1.71 from 192.168.1.254
eno1: leased 192.168.1.71 for 43200 seconds
eno1: adding route to 192.168.1.0/24
eno1: adding default route via 192.168.1.254

ifconfig 
eno1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2806:104e:1b:3149:e269:95ff:fedd:cd47  prefixlen 64  scopeid 0x0<global>
        inet6 2806:104e:1b:3149:e7fa:dc8d:4a5a:e553  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::e269:95ff:fedd:cd47  prefixlen 64  scopeid 0x20<link>
        ether e0:69:95:dd:cd:47  txqueuelen 1000  (Ethernet)
        RX packets 116315  bytes 169823472 (161.9 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 51452  bytes 5380570 (5.1 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 20  memory 0xfe500000-fe520000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 40  bytes 3168 (3.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 40  bytes 3168 (3.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I'll will reboot now

Its alive, if it's required I can test the changes for comment 43

Thanks for the tests. Looks like the results were same as mine.

Comment 43 needs to wait until Martin does the changes in drakx (comment 50).

Forgot to add, I've sent an email to the sysadmin list to move the package from updates_testing to release.

RH i686
LC_ALL=C urpmi https://ftp5.gwdg.de/pub/linux/mageia/distrib/cauldron/i686/media/core/updates_testing/dhcpcd-10.3.0-2.mga10.i686.rpm                                                                                              
                                                                                                                          
                                                                                                                          
installing dhcpcd-10.3.0-2.mga10.i686.rpm from /var/cache/urpmi/partial                                                   
Preparing...                     #######################################################################################  
      1/1: dhcpcd                #######################################################################################  
removing package dhcp-client-3:4.4.3P1-4.mga10.i686                                                                       
      1/1: removing dhcp-client-3:4.4.3P1-4.mga10.i686                                                                    
                                 ####################################################################################### 

dhcpcd -n wlp1s0
dhcpcd-10.3.0 starting
wlp1s0: connected to Access Point: INFINITUM98C2_2.4
DUID 00:01:00:01:30:f9:aa:8e:00:23:4e:4f:6d:6a
wlp1s0: IAID 4e:4f:6d:6a
wlp1s0: soliciting an IPv6 router
wlp1s0: Router Advertisement from fe80::1250:72ff:fee6:7020
wlp1s0: adding address 2806:104e:1b:3149:c9a0:607:5f2f:dc40/64
wlp1s0: adding route to 2806:104e:1b:3149::/64
wlp1s0: adding default route via fe80::1250:72ff:fee6:7020
wlp1s0: soliciting a DHCP lease
wlp1s0: offered 192.168.1.72 from 192.168.1.254

ifconfig 
enp2s1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 00:1e:ec:eb:b4:39  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 13296  bytes 1023168 (999.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 13296  bytes 1023168 (999.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.71  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2806:104e:1b:3149:c9a0:607:5f2f:dc40  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::223:4eff:fe4f:6d6a  prefixlen 64  scopeid 0x20<link>
        ether 00:23:4e:4f:6d:6a  txqueuelen 1000  (Ethernet)
        RX packets 42956  bytes 51169640 (48.7 MiB)
        RX errors 0  dropped 1  overruns 0  frame 0
        TX packets 22695  bytes 6030731 (5.7 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

I'll be back after other reboot ;)

Its alive too
When the package arrive to release repositories I'll test a clean install in VM

FYI I see this warning at boot

'iwconfig' uses wireless extensions which will stop working for Wi-Fi 7 hardware; use nl80211

(In reply to katnatek from comment #58)
> FYI I see this warning at boot
> 
> 'iwconfig' uses wireless extensions which will stop working for Wi-Fi 7
> hardware; use nl80211

iwconfig is in the wireless-tools package. That source code doesn't look like it has been updated in quite a while.

(In reply to katnatek from comment #57)
> Its alive too
> When the package arrive to release repositories I'll test a clean install in
> VM

I suggest that you wait for Martin to update the drakx-net package before the clean install. The drakx fixes are needed alongside the new dhcpcd and the drakx fixes will benefit from testing anyway.

Thanks for the QA work.

(In reply to katnatek from comment #58)
> FYI I see this warning at boot
> 
> 'iwconfig' uses wireless extensions which will stop working for Wi-Fi 7
> hardware; use nl80211

iwconfig is EOL upstream and replaced by iw. I have opened bug 34992

CC: (none) => rihoward1

The updated dhcpcd have been moved, so will be soon in all good mirrors

commit 4071f3401b49fd4ce62d094359a054ae546c81cb
Author: Martin Whitaker <mageia@...>
Date:   Fri Jan 16 21:43:19 2026 +0000

    Change default DHCP client to dhcpcd and remove dhclient (mga#30938)
---
 Commit Link:
   https://gitweb.mageia.org/software/drakx-net/commit/?id=4071f3401b49fd4ce62d094359a054ae546c81cb

commit 0be2e8406a93d97ff2ed9be73286807e051baa5f
Author: Martin Whitaker <mageia@...>
Date:   Fri Jan 16 21:36:02 2026 +0000

    installer: change default DHCP client to dhcpcd (mga#30938)
---
 Commit Link:
   https://gitweb.mageia.org/software/drakx/commit/?id=0be2e8406a93d97ff2ed9be73286807e051baa5f

The following packages still require or recommend dhcp-client:

  drakx-installer-images
  libguestfs
  vpnpptp

dhcp-server is still listed in rpmsrate. Despite earlier comments, kea does not appear to have been packaged for Mageia.

kea 3.0.2 is on the mirrors

I didn't do anything with rpmsrate because there had been some objections when I imported the package because it's configuration syntax is very different from dhcpd - most definitely not a drop in replacement even though it is from the same upstream. I imported it and will maintain it but I didn't think it was unilaterally up to me to decide it was the official replacement for dhcpd (dhcp-server).

Go ahead and update rpmsrate, so the correct package is chosen for new installations.  We just can't Obsolete dhcp-server in Kea if it's not a drop-in replacement.  We'll have to put a note in the release notes, so people can migrate manually.

(In reply to Mike Rambo from comment #65)
> kea 3.0.2 is on the mirrors

Ah, my mistake. I must have checked mga9, not cauldron.

I not sure what is wrong but after made one test for bug 34909
I disable the service from the -3 release

And after update cauldron with the netinstall image

I find 

systemctl status dhcpcd
○ dhcpcd.service - A minimalistic network configuration daemon with DHCPv4, rdisc and DHCPv6 support
     Loaded: loaded (/usr/lib/systemd/system/dhcpcd.service; disabled; preset: disabled)
     Active: inactive (dead)


But if I reinstall the package the service is activated as designed by the -4 release

What I not try is make other reboot to see what could happen

I guess I can try with a mageia 9 to cauldron upgrade

Added the issue in Erratas

Flags: (none) => in_errata10+

(In reply to katnatek from comment #68)
> I not sure what is wrong but after made one test for bug 34909
> I disable the service from the -3 release
I mean before here :S , sorry

meta-task-10-0.14.mga10 has rpmsrate updated to reflect kea replacing dhcp-server

I'll look at putting something in release_notes about the replacement too.

FWIW, I have imported keama (migration assistant) which is suppose to help mirgation from the dhcpd.conf format to the new JSON kea format. Not tried yet on my setup, but will.

kea-keama is there. FC had it all in one package so I left it that way. It says 3.0.2 because it is part of the main kea srpm but I'm pretty sure it is actually 4.5.0. It does help in getting an initial skeleton configuration to work with but, at least for me, it took considerable manual intervention afterward. I'd like to hear what you find.

The package meta-task-10-0.14.mga10 is causing an installation issue (see below).

I'm seeing this issue on the two cauldron system I have. One system is a clean cauldron install, and the other is an upgrade from Mageia 9.

Should I open a separate bug report?

"""
# uname -a
Linux jupiter-vm-mageia-cauldron 6.18.6-desktop-1.mga10 #1 SMP PREEMPT_DYNAMIC Sun Jan 18 00:05:26 UTC 2026 x86_64 GNU/Linux
# rpm -q meta-task
meta-task-10-0.14.mga10
# LANGUAGE=C urpmi --auto-update
medium "Core Release" is up-to-date                                                                                                                                                           
medium "Core Updates" is up-to-date                                                                                                                                                           
medium "Core Backports" is up-to-date                                                                                                                                                         
medium "Nonfree Release" is up-to-date                                                                                                                                                        
medium "Nonfree Updates" is up-to-date
medium "Nonfree Backports" is up-to-date
medium "Tainted Release" is up-to-date
medium "Tainted Updates" is up-to-date
medium "Tainted Backports" is up-to-date
medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates" is up-to-date
medium "Core 32bit Backports" is up-to-date
medium "Nonfree 32bit Release" is up-to-date
medium "Nonfree 32bit Updates" is up-to-date
medium "Nonfree 32bit Backports" is up-to-date
medium "Tainted 32bit Release" is up-to-date
medium "Tainted 32bit Updates" is up-to-date
medium "Tainted 32bit Backports" is up-to-date
To satisfy dependencies, the following package is going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release")
  meta-task                      10           0.14.mga10    noarch  
19B of disk space will be freed.
22KB of packages will be retrieved.
Proceed with the installation of one package? (Y/n) 


installing meta-task-10-0.14.mga10.noarch.rpm from /var/cache/urpmi/rpms
Preparing...                     ###################################
Installation failed:    package meta-task-2:10-0.14.mga10.noarch is already installed
# rpm -q meta-task
meta-task-10-0.14.mga10
"""

CC: (none) => mageia

(In reply to PC LX from comment #74)
> The package meta-task-10-0.14.mga10 is causing an installation issue (see
> below).
> 

Remove meta-task from urpmi cache before updating. meta-task's epoch was bumped which caused this issue. Epoch is not included in .rpm file name so urpmi is confused when epoch is bumped, but version and release stays.

(In reply to Jani Välimaa from comment #75)
> (In reply to PC LX from comment #74)
> > The package meta-task-10-0.14.mga10 is causing an installation issue (see
> > below).
> 
> Remove meta-task from urpmi cache before updating.

Thanks, that fixed the issue.

commit 8d562eddbe03c96680bfff7422c609fe0ffee21f
Author: Martin Whitaker <mageia@...>
Date:   Sun Feb 8 08:49:38 2026 +0000

    Restore knowledge of dhclient but keep dhcpcd as default (mga#30938)
    
    dhclient is required by dracut for nfs support in the installer, so
    we can't drop it from the distribution yet.
---
 Commit Link:
   https://gitweb.mageia.org/software/drakx-net/commit/?id=8d562eddbe03c96680bfff7422c609fe0ffee21f