Description of problem: After upgrading a non-graphical Mageia 4 install to Cauldron via urpmi no SysV service script is being executed at boot, nor can it be somehow enabled. This includes the "network" script, which means that any network interface is not being brought up. The reason for this seems to be related to the default systemd target: - The default target for systemd on non-graphical installs is multi-user.target - The systemd-sysv-generator unit generator program only generates scripts for the runlevelX aliases, as seen in the /run/systemd/generator.late/ directory. - Changing the /etc/systemd/system/default.target symlink to point to /lib/systemd/system/runlevel3.target (which itself points to multi-user.target) fixes the problem. This situation can be especially troubling for remote server installations where graphical components are often not installed, as it requires console access to recover. Version-Release number of selected component (if applicable): Mageia 4 -> Cauldron upgrade How reproducible: Always Steps to Reproduce: 1. Install mga4 without any graphical components and do NOT configure a graphical environment. 2. Verify that the default runlevel is multi-user.target 3. Upgrade to Cauldron using urpmi as per https://wiki.mageia.org/en/Cauldron 4. Reboot 5. Use `ifconfig' to check the network interface state 6. Use `systemctl status' to check the state of other SysV services Reproducible: Steps to Reproduce:
CC: (none) => mageia, rverschelde
CC: mageia, sysadmin-bugs => (none)Component: Release (media or process) => RPM PackagesAssignee: bugsquad => mageiaSource RPM: (none) => systemd
Colin Guthrie (coling) found the following commit which seems to support the root cause guess from the problem description: http://cgit.freedesktop.org/systemd/systemd/commit/?id=d5d8429a12c4b1ef0dcd226c0904f00f4fa4898a In addition, I performed a clean non-graphical Cauldron install using boot.iso which initially seemed to _not_ display this problem. A diff check between my two installs led me to systemd-resolved.service, which is an LLMNR resolver. That service is enabled by default on new Cauldron installs, but not on upgrades from Mageia 4. Disabling it causes the problem to appear even on a clean install.
Priority: Normal => release_blockerBlocks: (none) => 14069
I verified that graphical installs of both Mageia 4 and Cauldron default to runlevel5.target, rather than graphical.target. Moreover, disabling Xorg-on-boot via MCC switches that to runlevel3.target, rather than multi-user.target. It seems, therefore, that the SysV service issue by default only affects non-graphical Mageia 4 installs that have been upgraded to Cauldron.
Colin anything we can do here ? or add something in errata ?
CC: (none) => ennael1
I think this should be put in the errata and then priority can be decreased. Docteam, could you handle that?
CC: (none) => doc-bugs
(In reply to Rémi Verschelde from comment #4) > I think this should be put in the errata and then priority can be decreased. > Docteam, could you handle that? No, i don't fully understand this bug Is the following OK: Upgrading a non-graphical Mageia 4 install to Cauldron disables all SysV services You can workaround this problem by running sytemctl start systemd-resolved.service ???
CC: (none) => marja11
(In reply to Marja van Waes from comment #5) > (In reply to Rémi Verschelde from comment #4) > > I think this should be put in the errata and then priority can be decreased. > > Docteam, could you handle that? > > No, i don't fully understand this bug > > Is the following OK: > edited slightly: > Upgrading a non-graphical Mageia 4 install to Mageia 5 might disable all SysV > services > You can workaround this problem .... ... by changing the /etc/systemd/system/default.target symlink to point to /lib/systemd/system/runlevel3.target (which itself points to multi-user.target) to mitigate the problem. As long as there's no fix from upstream, this should be OK for errata.
Priority: release_blocker => NormalCC: (none) => doktor5000Severity: normal => major
Thx, Florian, will do
Whiteboard: (none) => 2ADD2ERRATA
Whiteboard: 2ADD2ERRATA => FOR_ERRATA
added to errata
Whiteboard: FOR_ERRATA => Errata
Whiteboard: Errata => IN_ERRATA
Hm, I just upgraded a live mga4 server to mga5, and did not hit this issue... And I _never_ use any graphical stuff on my servers...
CC: (none) => tmb
(In reply to Thomas Backlund from comment #9) > Hm, > > I just upgraded a live mga4 server to mga5, and did not hit this issue... > > And I _never_ use any graphical stuff on my servers... Does that mean I can remove it from the errata? Users running servers will know how to do some troubleshooting and how to search bugzilla, in case something in their setup is similar to Theodoros's, and they hit this issue
Summary: Upgrading a non-graphical Mageia 4 install to Cauldron disables all SysV services => Upgrading a non-graphical Mageia 4 install to Cauldron might disable all SysV services
Actually correction... I checked wrong system :/ I can reproduce this one... And it's bad for those doing a remote upgrade and they'll realize they lost access after re-boot since network is not started...
Summary: Upgrading a non-graphical Mageia 4 install to Cauldron might disable all SysV services => Upgrading a non-graphical Mageia 4 install to Cauldron disables all SysV services
(In reply to Thomas Backlund from comment #11) > > And it's bad for those doing a remote upgrade and they'll realize they lost > access after re-boot since network is not started... remote as in hundreds of km away... hadn't thought of that :-/ So this'll affect Mageia, too, when servers in Marseille are upgraded to Mageia 5.
Ok, so upstream fix referenced in comment 1 fixes the issue here
fix tested on 3 different systems, and all works... Fix pushed to release as of: systemd-217-11.mga5 Feel free to drop from errata
Status: NEW => RESOLVEDResolution: (none) => FIXED
And dropped from errata
Whiteboard: IN_ERRATA => (none)
Is bug 14106 a duplicate?
*** Bug 14106 has been marked as a duplicate of this bug. ***
CC: (none) => martin.schmitz