Tumbleweed - dracut update on dup tonight failed to start WiFi on reboot?
Devs, Just did a zypper dup on Tumbleweed after removing the openSUSE-repo-xxx packages. openSUSE repos have much improved download speed ~1-5MB/s compare to the less than 100KB/s earlier. Packman still crawls at ~100KB/s, but that's just packman in the US. But dracut was updated, and during reboot I noticed a couple new errors splashed to the screen - too quick to read what they were, but when the desktop started -- it was clear, my WiFi connection was dead. Checking 'ip' it was dead. Going into Yast, the configuration was fine and simply clicking "edit" on my wireless connection and "next", "next", "Accept" brought the wireless connection up without problem. What to check to find the earlier errors and determine why, for the first time since Tumbleweed install, wireless failed to start on boot? Seems likely to be related to dracut or one of the libraries that was updated. -- David C. Rankin, J.D.,P.E.
Op dinsdag 27 augustus 2024 10:45:43 CEST schreef David C. Rankin:
Devs,
Just did a zypper dup on Tumbleweed after removing the openSUSE-repo-xxx packages. openSUSE repos have much improved download speed ~1-5MB/s compare to the less than 100KB/s earlier. Packman still crawls at ~100KB/s, but that's just packman in the US.
But dracut was updated, and during reboot I noticed a couple new errors splashed to the screen - too quick to read what they were, but when the desktop started -- it was clear, my WiFi connection was dead.
Checking 'ip' it was dead. Going into Yast, the configuration was fine and simply clicking "edit" on my wireless connection and "next", "next", "Accept" brought the wireless connection up without problem.
What to check to find the earlier errors and determine why, for the first time since Tumbleweed install, wireless failed to start on boot?
Seems likely to be related to dracut or one of the libraries that was updated.
Probably "journalctl -b" could give you a clue. -- fr.gr. member openSUSE Freek de Kruijf
Am 27.08.24 um 11:17 schrieb Freek de Kruijf:
Op dinsdag 27 augustus 2024 10:45:43 CEST schreef David C. Rankin:
Devs,
Just did a zypper dup on Tumbleweed after removing the openSUSE-repo-xxx packages. openSUSE repos have much improved download speed ~1-5MB/s compare to the less than 100KB/s earlier. Packman still crawls at ~100KB/s, but that's just packman in the US.
But dracut was updated, and during reboot I noticed a couple new errors splashed to the screen - too quick to read what they were, but when the desktop started -- it was clear, my WiFi connection was dead.
Checking 'ip' it was dead. Going into Yast, the configuration was fine and simply clicking "edit" on my wireless connection and "next", "next", "Accept" brought the wireless connection up without problem.
What to check to find the earlier errors and determine why, for the first time since Tumbleweed install, wireless failed to start on boot?
Seems likely to be related to dracut or one of the libraries that was updated.
Probably "journalctl -b" could give you a clue.
If its a wicked network:
.... snip ...... That for example has been reported already as https://bugzilla.opensuse.org/show_bug.cgi?id=1229745
wicked is wrongly starting before dbus-broker and results in not having a network configured.
After the boot, you can "systemctl restart network" or apply the patch which is proposed in https://github.com/openSUSE/wicked/pull/1032 locally to get it faster,
simoN -- www.becherer.de
On 8/27/24 8:39 AM, Simon Becherer wrote:
.... snip ...... That for example has been reported already as https://bugzilla.opensuse.org/show_bug.cgi?id=1229745
wicked is wrongly starting before dbus-broker and results in not having a network configured.
After the boot, you can "systemctl restart network" or apply the patch which is proposed in https://github.com/openSUSE/wicked/pull/1032 locally to get it faster,
If I read the fix correctly, you can patch the wickedd*.service file simply by replacing dbus.service with dbus.socked in the service files. I made a copy of the wickedd*.service files in directory a/ and patched the files in b/, e.g. $ for i in a/*; do sed 's/dbus\.service/dbus.socket/' "$i" > b/"${i##*/}"; done; unset i Then you can simply do (what you are not supposed to) and replace the service files with the patched files in b/ until an update is provided that makes this permanent. If it all fails, then just move the files from a/ back in place. Chime in if there is a better way. -- David C. Rankin, J.D.,P.E.
On 8/27/24 6:48 PM, David C. Rankin wrote:
Then you can simply do (what you are not supposed to) and replace the service files with the patched files in b/ until an update is provided that makes this permanent.
If it all fails, then just move the files from a/ back in place.
Chime in if there is a better way.
I guess the better way is to copy b/* as "Replacement Unit Files" (.service files) to /etc/systemd/system A second, preferred way is to create /etc/systemd/system/unit.d/ and create "Drop-in" unit files (with .conf extension) there with: # systemctl edit unit --drop-in=drop_in_name Either way a # systemctl revert unit will restore the original. Or, just delete the replacement unit files or drop-ins and do # systemctl daemon-reload to scan for unit file changes and reload. -- David C. Rankin, J.D.,P.E.
On 8/27/24 4:17 AM, Freek de Kruijf wrote:
Op dinsdag 27 augustus 2024 10:45:43 CEST schreef David C. Rankin:
Devs,
Just did a zypper dup on Tumbleweed after removing the openSUSE-repo-xxx packages. openSUSE repos have much improved download speed ~1-5MB/s compare to the less than 100KB/s earlier. Packman still crawls at ~100KB/s, but that's just packman in the US.
But dracut was updated, and during reboot I noticed a couple new errors splashed to the screen - too quick to read what they were, but when the desktop started -- it was clear, my WiFi connection was dead.
Checking 'ip' it was dead. Going into Yast, the configuration was fine and simply clicking "edit" on my wireless connection and "next", "next", "Accept" brought the wireless connection up without problem.
What to check to find the earlier errors and determine why, for the first time since Tumbleweed install, wireless failed to start on boot?
Seems likely to be related to dracut or one of the libraries that was updated.
Probably "journalctl -b" could give you a clue.
It's a bug - the dependency bug: Aug 27 03:31:40 wizard systemd[1]: Reached target Socket Units. Aug 27 03:31:40 wizard systemd[1]: D-Bus System Message Bus is inactive. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked network management service daemon. Aug 27 03:31:40 wizard systemd[1]: wickedd.service: Job wickedd.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked DHCPv6 supplicant service. Aug 27 03:31:40 wizard systemd[1]: wickedd-dhcp6.service: Job wickedd-dhcp6.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked network nanny service. Aug 27 03:31:40 wizard systemd[1]: wickedd-nanny.service: Job wickedd-nanny.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked DHCPv4 supplicant service. Aug 27 03:31:40 wizard systemd[1]: wickedd-dhcp4.service: Job wickedd-dhcp4.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked AutoIPv4 supplicant service. Aug 27 03:31:40 wizard systemd[1]: wickedd-auto4.service: Job wickedd-auto4.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Reached target Basic System. -- David C. Rankin, J.D.,P.E.
According to the bugreport, only change: in the file: /usr/lib/systemd/system/wicked.service section [Unit] make a new line: BindsTo=dbus.service solves it for me. simoN ps: sorry for private mail, pressed the wrong button. Am 28.08.24 um 00:57 schrieb David C. Rankin:
On 8/27/24 4:17 AM, Freek de Kruijf wrote:
Op dinsdag 27 augustus 2024 10:45:43 CEST schreef David C. Rankin:
Devs,
Just did a zypper dup on Tumbleweed after removing the openSUSE-repo-xxx packages. openSUSE repos have much improved download speed ~1-5MB/s compare to the less than 100KB/s earlier. Packman still crawls at ~100KB/s, but that's just packman in the US.
But dracut was updated, and during reboot I noticed a couple new errors splashed to the screen - too quick to read what they were, but when the desktop started -- it was clear, my WiFi connection was dead.
Checking 'ip' it was dead. Going into Yast, the configuration was fine and simply clicking "edit" on my wireless connection and "next", "next", "Accept" brought the wireless connection up without problem.
What to check to find the earlier errors and determine why, for the first time since Tumbleweed install, wireless failed to start on boot?
Seems likely to be related to dracut or one of the libraries that was updated.
Probably "journalctl -b" could give you a clue.
It's a bug - the dependency bug:
Aug 27 03:31:40 wizard systemd[1]: Reached target Socket Units. Aug 27 03:31:40 wizard systemd[1]: D-Bus System Message Bus is inactive. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked network management service daemon. Aug 27 03:31:40 wizard systemd[1]: wickedd.service: Job wickedd.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked DHCPv6 supplicant service. Aug 27 03:31:40 wizard systemd[1]: wickedd-dhcp6.service: Job wickedd-dhcp6.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked network nanny service. Aug 27 03:31:40 wizard systemd[1]: wickedd-nanny.service: Job wickedd-nanny.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked DHCPv4 supplicant service. Aug 27 03:31:40 wizard systemd[1]: wickedd-dhcp4.service: Job wickedd-dhcp4.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Dependency failed for wicked AutoIPv4 supplicant service. Aug 27 03:31:40 wizard systemd[1]: wickedd-auto4.service: Job wickedd-auto4.service/start failed with result 'dependency'. Aug 27 03:31:40 wizard systemd[1]: Reached target Basic System.
-- www.becherer.de
On 8/28/24 12:18 AM, Simon Becherer wrote:
According to the bugreport, only change:
in the file: /usr/lib/systemd/system/wicked.service
section [Unit]
make a new line:
BindsTo=dbus.service
solves it for me.
simoN
No worries, Let me read again, I thought Andrei disliked that solution. I was going my his comments: <quote - in Summary> Theoretically wickedd.service will trigger D-Bus startup and so does not even need Requires=dbus.service. Replacing Requisite=sbus.service After=dbus.service with Requires=dbus.socket After=dbus.socket in all wickedd*.service files fixes the startup too and IMHO this is more clean fix than adding Requires=dbus.service to some random unit. </quote> I'll reboot shortly to test. I used the "Replacement Unit Files" approach of modified service files in /etc/systemd/system rather than "Drop-in" .conf files. Will report back if I have any issue. The fix (either way) makes sense. The BindsTo= fix from https://github.com/openSUSE/wicked/pull/1032 also looks simple, but I don't know what all the ramifications are for unit restart, etc.. with that fix. Wonder which one they will ultimately choose? -- David C. Rankin, J.D.,P.E.
On 8/28/24 12:18 AM, Simon Becherer wrote:
According to the bugreport, only change:
in the file: /usr/lib/systemd/system/wicked.service
section [Unit]
make a new line:
BindsTo=dbus.service
solves it for me.
Hey Simon, Can you test this for me with your config. Do # systemctl stop dbus Does your network also get taken down? My reading is that if we do BindsTo=dbus.service in wicked.service than any time dbus.service is stopped or crashes, then wicked.service is also stopped automatically. If that's the case, then I'm not sure we want BindsTo= as a fix. My network is started at boot, it isn't user dependent, so it shouldn't go down if dbus does after it is up and running -- unless there is some other interplay I'm not aware of. -- David C. Rankin, J.D.,P.E.
Am 28.08.24 um 08:08 schrieb David C. Rankin:
On 8/28/24 12:18 AM, Simon Becherer wrote:
According to the bugreport, only change:
in the file: /usr/lib/systemd/system/wicked.service
section [Unit]
make a new line:
BindsTo=dbus.service
solves it for me.
Hey Simon,
Can you test this for me with your config. Do
# systemctl stop dbus
Does your network also get taken down?
My reading is that if we do BindsTo=dbus.service in wicked.service than any time dbus.service is stopped or crashes, then wicked.service is also stopped automatically.
If that's the case, then I'm not sure we want BindsTo= as a fix. My network is started at boot, it isn't user dependent, so it shouldn't go down if dbus does after it is up and running -- unless there is some other interplay I'm not aware of.
Hi david, tested at the moment, but i am not able to shutdown dbus: # systemctl stop dbus # Failed to stop dbus.service: Operation refused, unit dbus-broker.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status dbus.service' for details. simoN -- www.becherer.de
Am 28.08.24 um 08:58 schrieb Simon Becherer:
Am 28.08.24 um 08:08 schrieb David C. Rankin:
On 8/28/24 12:18 AM, Simon Becherer wrote:
According to the bugreport, only change:
in the file: /usr/lib/systemd/system/wicked.service
section [Unit]
make a new line:
BindsTo=dbus.service
solves it for me.
Hey Simon,
Can you test this for me with your config. Do
# systemctl stop dbus
Does your network also get taken down?
My reading is that if we do BindsTo=dbus.service in wicked.service than any time dbus.service is stopped or crashes, then wicked.service is also stopped automatically.
If that's the case, then I'm not sure we want BindsTo= as a fix. My network is started at boot, it isn't user dependent, so it shouldn't go down if dbus does after it is up and running -- unless there is some other interplay I'm not aware of.
Hi david,
tested at the moment, but i am not able to shutdown dbus:
# systemctl stop dbus
# Failed to stop dbus.service: Operation refused, unit dbus-broker.service may be requested by dependency only (it is configured to refuse manual start/stop). See system logs and 'systemctl status dbus.service' for details.
simoN
Here is a nice explanation (i have not thinked about it what the conclusion is for our usecase): https://pychao.com/2021/02/24/difference-between-partof-and-bindsto-in-a-sys... if you figured out a good solution, let me know. simoN -- www.becherer.de
On 8/28/24 2:14 AM, Simon Becherer wrote:
Here is a nice explanation (i have not thinked about it what the conclusion is for our usecase):
https://pychao.com/2021/02/24/difference-between-partof-and-bindsto-in-a-sys...
if you figured out a good solution, let me know.
Yes, It seems dbus.service is set to not allow it to be stopped. That takes care of the BindsTo= problem of taking down wicked if dbus is restarted -- but if it crashes -- I guess you have bigger issues.... Dbus -- flawless software that can't be stopped and never fails -- that just seems like the recipe for regret... Whether they change wickedd.... or use BindsTo=, the folks making the call know more about it than I (at least I hope they do...), so I'm happy with whichever way it goes. -- David C. Rankin, J.D.,P.E.
participants (3)
-
David C. Rankin -
Freek de Kruijf -
Simon Becherer