Bug 31299

Created attachment 13588 [details]
journalctl -b (output)

(In reply to Elmar Stellnberger from comment #0)
>  As recommended by the upgrade procedures for Mageia 8->9 the
> network.service and network-up have been masked with systemctl and
> NetworkManager has been enabled.
Please, please, please don't mix different topics and procedures.
There is no upgrade procedure which recommends to mask this two services.


One procedure is the switch to networkmanger (which indeed recommends to mask this two services):
https://wiki.mageia.org/en/Switching_to_networkmanager

And the other procedure is the upgrade to cauldron:
https://wiki.mageia.org/en/Cauldron

Two different topics which don't have anything common...

This is of concern here as the default systemd-networking scripts are currently broken with Mageia 9 Alpha 1: Bug 32195.

* Bug 31299 may be related.
* This bug was tested with LXDE and the x32 Gericom SilverSeraph.

Oops, comment #4 belongs to the other report, namely Bug 32195 from comment #3. I don´t know why it can not be clicked here so here is its full URL: https://bugs.mageia.org/show_bug.cgi?id=31295

Elmar, having started this bug with an error message, can you please say what the problem actually is; for example:
- you have to do something by hand to repair the situation; and if so, what?
- the message is uncomfortable but has no consequences.
Clarification, to see the wood for the trees.

CC: (none) => lewyssmith
Source RPM: qemu-7.2.0-1.mga9.src.rpm => systemd-252.3-1.mga9.src.rpm

I must confess that I have not tested Qemu on the old PentiumIV i586 x32 SilverSeraph. The machine seemed a bit low of resources for qemu-ing. However with the right distribution it would be possible to test Qemu-networking even on that computer since Linux still runs on an 80486 computer. Nonetheless I had decided to keep that report open till I have Mageia 9 running on a newer machine.

Please answer comment 6.

I have filed the report because of the error message in the boot log.

Understood; but still not saying whether it caused a problem, or is just a cosmetic thing.

The virbr0 network interface is created by the package libvirt-utils

After installing the package and rebooting I get ...
[root@x9v ~]# journalctl -b --no-h|grep virbr0
Dec 20 15:45:32 NetworkManager[805]: <info>  [1671569132.5466] manager: (virbr0): new Bridge device (/org/freedesktop/NetworkManager/Devices/3)
Dec 20 15:45:32 systemd-udevd[581]: virbr0: Process 'net_create_ifcfg' failed with exit code 1.
Dec 20 15:45:33 avahi-daemon[737]: Joining mDNS multicast group on interface virbr0.IPv4 with address 192.168.122.1.
Dec 20 15:45:33 avahi-daemon[737]: New relevant interface virbr0.IPv4 for mDNS.
Dec 20 15:45:33 avahi-daemon[737]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0497] device (virbr0): state change: unmanaged -> unavailable (reason 'connection-assumed', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0523] device (virbr0): state change: unavailable -> disconnected (reason 'connection-assumed', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0557] device (virbr0): Activation: starting connection 'virbr0' (f35b75a3-d3c4-45fb-9f9f-cbe0f5dc2942)
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0565] device (virbr0): state change: disconnected -> prepare (reason 'none', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0641] device (virbr0): state change: prepare -> config (reason 'none', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0650] device (virbr0): state change: config -> ip-config (reason 'none', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0678] device (virbr0): state change: ip-config -> ip-check (reason 'none', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0723] device (virbr0): state change: ip-check -> secondaries (reason 'none', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0732] device (virbr0): state change: secondaries -> activated (reason 'none', sys-iface-state: 'external')
Dec 20 15:45:33 NetworkManager[805]: <info>  [1671569133.0781] device (virbr0): Activation: successful, device activated.
Dec 20 15:45:33 dnsmasq-dhcp[1301]: DHCP, sockets bound exclusively to interface virbr0
Dec 20 15:45:34 avahi-daemon[737]: Withdrawing address record for 192.168.122.1 on virbr0.
Dec 20 15:45:34 avahi-daemon[737]: Registering new address record for 192.168.122.1 on virbr0.IPv4.

This is in a vb guest install, so I can't test it to see if it stops virtmanager
from working, though from the messages it's likely just a cosmetic error as
the device does get activated ok.

I think the error message is a result of
/usr/lib/udev/rules.d/81-net.rules which runs /usr/sbin/mdv-network-event
which has changed quite a bit since Mageia 8.
The mdv-network-event script is from the package initscripts.

Assigning to all packages. cc to ovitters who made the most recent changes.

Assignee: bugsquad => pkg-bugs
CC: (none) => davidwhodgins, olav

> The virbr0 network interface is created by the package libvirt-utils
I wondered, could not find it. Thanks.

CC: lewyssmith => (none)
Source RPM: systemd-252.3-1.mga9.src.rpm => libvirt-8.10.0-1.mga9.src.rpm, initscripts-10.04-2.mga9.src.rpm

Original error message "'net_create_ifcfg' failed" stays the same with qemu-7.2.0-2.mga9. However if you look at the syslog it says "(virbr0): Activation: successful, device activated." which indicates that the device should still be ready to use (for the old, originally reported for as well as the new qemu).