I think it's a bug that should be fixed before Mageia 6 is released.

CC: (none) => mageia
Target Milestone: --- => Mageia 6
Assignee: bugsquad => mageia

(In reply to Sander Lepik from comment #1)
> I think it's a bug that should be fixed before Mageia 6 is released.

Well assigning it to Colin is maybe not the best way to have it fixed quickly, currently :)

Priority: Normal => High
Assignee: mageia => basesystem
CC: (none) => mageia

Bug still present in last initscripts update:  initscripts-9.55-23.mga6

Bug still present in last initscripts update: initscripts-9.55-24.mga6

Same problem in my Cauldron,not in first time

CC: (none) => jaanus.ojangu

It would be good to add a note about this in the Errata, thus I'm adding the FOR_ERRATA6 keyword.

Once added to https://wiki.mageia.org/en/Mageia_6_Errata please replace FOR_ERRATA6 with IN_ERRATA6.

Keywords: (none) => FOR_ERRATA6

Still present in Mageia 6 initscripts-9.55-24.mga6.src.rpm and in Cauldron initscripts-9.55-26.mga7.src.rpm

Source RPM: initscripts-9.55-22.mga6.src.rpm => initscripts-9.55-24.mga6.src.rpm; initscripts-9.55-26.mga7.src.rpm

I hope it's fixed for cauldron.

Resolution: (none) => FIXED
Status: NEW => RESOLVED

If it's fixed, I'd like to see it proposed as an update to Mageia 6, as I'm also annoyed by this bug.

Status: RESOLVED => REOPENED
Resolution: FIXED => (none)
Version: Cauldron => 6

Still present in Cauldron initscripts-9.78-9.mga7...

Target Milestone: Mageia 6 => Mageia 7
Version: 6 => Cauldron
Source RPM: initscripts-9.55-24.mga6.src.rpm; initscripts-9.55-26.mga7.src.rpm => initscripts-9.55-24.mga6.src.rpm; initscripts-9.78-9.mga7.src.rpm

I'll set it as a release blocker. More and more users are probably switching to NM nowadays and update to initscripts just screws their installation :/

Priority: High => release_blocker

Found network.service and network-up.service enabled in a new Mga8 Cauldron. It is an upgrade from a clone of a Mga7 installation. Both services were disabled at origin.

(In reply to Ulrich Beckmann from comment #12)
> Found network.service and network-up.service enabled in a new Mga8 Cauldron.
> It is an upgrade from a clone of a Mga7 installation. Both services were
> disabled at origin.

It is a systemd standard procedure to enable service, 
 even though you disabled it, upon new systemd release.

You have to systemctl mask unit/item_here to disable systemd from enabling
it upon new systemd release.

Should we write more about this in Mageia 7 Release notes= I only find same info in

https://wiki.mageia.org/en/Mageia_7_Release_Notes#Enlightenment

https://wiki.mageia.org/en/Mageia_7_Errata#GNOME


But i think it is not general nor obvious enough?

CC: (none) => fri

I have  now 
initscripts-9.78-14.mga8
installed. No breakage of NetworkManager occurred. The issue seems to be fixed.

Ulrich

(In reply to Ulrich Beckmann from comment #15)
> I have  now 
> initscripts-9.78-14.mga8
> installed. No breakage of NetworkManager occurred. The issue seems to be
> fixed.
> 
> Ulrich

Sorry, wrong info.
I ran systemctl disable network ... after the upgrade.

Ulrich

With this I give up. To run NetworkManager some another distribution is a way to go...

Source RPM: initscripts-9.55-24.mga6.src.rpm; initscripts-9.78-10.mga7.src.rpm; initscripts-9.78-13.mga8.src.rpm => initscripts-9.55-24.mga6.src.rpm; initscripts-9.78-10.mga7.src.rpm; initscripts-9.78-16.mga8.src.rpm

Olivier, do you think you can take a look to this ?

CC: (none) => mageia, mageia

*** Bug 27001 has been marked as a duplicate of this bug. ***

CC: (none) => guillomovitch

See the duplicate bug:
"the posttrans scriptlet force activation of the following services, whatever their current state:
- network
- network-up
- partmon
- netconsole
Updating the package should honour current service activation setting, and not reactive unwanted services."

Can this not be fixed? It is an old issue causing increasing unrest.

Summary: Initscripts update enables network & network-up services although system has switched to use NetworkManager => Initscripts update enables network, network-up, partmon & netconsole services when disabled/de-activated, as when system has switched to use NetworkManager

From initscripts.spec:
> # The restart part in the real _post_service doesn't work with netfs and isn't needed
> # for other scripts
> %define _mypost_service() /sbin/chkconfig --add %{1};
[..]
> if [ $1 -eq 1 ]; then
> 
> %_mypost_service network
> 
> %_mypost_service network-up
> 
> fi
[..]
> %_mypost_service partmon
> 
> %_mypost_service netconsole

I'm working on cleaning up the Mageia initscripts fork. Seems above bit from the spec file is the cause; taking the bug.

I also fixed a few bugs and was worried this was a new bug. It's sort of nice to know I didn't cause any regressions.

Status: REOPENED => ASSIGNED
Assignee: basesystem => olav
CC: (none) => olav

The comment from the initscripts.spec file doesn't apply anymore. When the comment was added there was an netfs service as well. However, the bug will not be fixed by switching over to the %_post_service script. It'll still call pretty much the same command, then it seems it'll restart network, network-up, partmon and netconsole. So in brief: I cannot use %_post_service, it'll be even more buggy.

The upstream/Fedora initscripts make it possible to uninstall these network scripts (they have them in a separate package). Aside from that it also uses the alternative system. So to properly fix this I think Mageia should be closer aligned for how Fedora dealt with this.

Fixing this is quite a bit more involved than it should be. Our initscripts are a fork of Fedora. The fork has quite a lot of old stuff there. It's not easy to figure out what is ancient and what is needed. I wanted to make the switch to a new initscripts easier by releasing a lot of intermediate initscripts versions. However, that'll trigger this bug each and every time.

I need to check if can add a temporary hack.

> I wanted to make the switch to a new initscripts easier by releasing a lot of intermediate initscripts versions. However, that'll trigger this bug each and every time.
No need to waste your time with a temporary hack. We are living with the problem since several years already, it doesn't really matter if the problem is triggered a few times more, as long it get fixed in the end.

Could it be developed and tested incrementally, then we test if it is possible to jump directly from now current to fully fixed, and then release that?

I think I see the cause.

The %_mypost_service macro is called within a %posttrans

This change was made to fix bug 23482. Basically: using %post too much caused bugs during install time. The order of the various scripts are documented here:
  https://docs.fedoraproject.org/en-US/packaging-guidelines/Scriptlets/

There's probably loads of commits, but I see e.g.:
http://svnweb.mageia.org/packages?view=revision&revision=1237259
http://svnweb.mageia.org/packages?view=revision&revision=1237259

From the packaging guideline documentation:
> When scriptlets are called, they will be supplied with an argument. This
> argument, accessed via $1 (for shell scripts) is the number of packages of this
> name which will be left on the system when the action completes, except for
> %pretrans and %posttrans which are always run with $1 as 0.

From the initscripts spec file:
> if [ $1 -eq 1 ]; then
> 
> %_mypost_service network
> 
> %_mypost_service network-up
> 
> fi

At one point various attempts were made to fix this bug and only call chkconfig --add network (and network-up) on initial installation, not on upgrade. This is usually done by code I quoted above ($1 -eq 1). But due to changing the %post to a %posttrans there's no ability to see (in %posttrans) if initscripts was upgraded or not ($1 will always be equal to 1). I cannot move the chkconfig -add code from %posttrans to %post as that will likely reintroduce bug 23482.

Alternatively, I think another "solution" is to do something such as:
> %post
> if [ $1 -eq 1 ]; then
>   mkdir -p -m 700 "/run/rpm-script-hacks/%{name}.install"
> fi
> 
> %posttrans
> if [ -d "/run/rpm-script-hacks/%{name}.install" ]; then
>   %_mypost_service network
>   %_mypost_service network-up
>   rmdir "/run/rpm-script-hacks/%{name}.install"
> fi

Plus move partmon and netconsole inside above check as well.

I need to check if such a "solution" was ever used before and reuse that logic.

There's also complaints about "mandrake_everytime" being re-enabled every time. One thing at a time ;)

A similar "solution" is used in the grub2 package. I think I used it somewhere else, but can't remember where now.

CC: (none) => mageia

Hi Martin,

Thanks, unfortunately I saw that too late. I spend a while using grep and so on.

I found a various other cases where:
- similar workarounds are used
- a similar bug exists (ouch)

To see the other problems I suggest from the 'all packages' directory:
  rg '%posttrans' -A10 --color always --heading |less -R

You'll need ripgrep for this, though it's not unique to ripgrep (I like the speed and way it outputs the matches).

Regarding initscripts and this bug:
I've added something similar to what I found in roundcubemail-plugins-kolab. I've added the fix in initscripts-9.78-19.mga8. I tested the logic with a custom package. I didn't test initscripts-9.78-19.mga8 myself (now doubting myself about that!).

I'm going to mark it fixed. Please reopen if there are problems.

Resolution: (none) => FIXED
Status: ASSIGNED => RESOLVED

Actually, I'd rather question the usefulness of activating any service at installation time for this specific package. The whole justification of this policy ("if a user install package X, it is probably intending to use it") makes sense for specialized package, with a single service, such as a database server, for instance, but far less for such generic set of loosely related services as initscripts. Especially as initscripts is a mandatory depdency of basesystem, and is never intentionally installed.

So, I'd suggest simplifying the problem, ie not activating any service here, and let user manage their system state using their usual configuration tools (drakxservice, chkconfig, whathever).

(In reply to Guillaume Rousse from comment #28)
> Actually, I'd rather question the usefulness of activating any service at
> installation time for this specific package. The whole justification of this

The only bits that really get (forcefully) activated is anything sysvinit. An systemd service relies on the preset functionality. Basically: which service should be started on install time depends on some text files. So the policy isn't coded in the spec file, it's somewhere else. So then a user/admin/distro can easily change the policy. The preset functionality was broken due to this bug though.

Fedora split off a lot of the services into the right packages. I'm going to replicate those changes. It seems best to first replicate moving some files around (and getting feedback on that), before actually switching to the latest initscripts.

For sysvinit the scriptlet seems to always re-enable the service. Stuff that is sysvinit: network, network-up, partmon, netconsole. Some of this might be better off in their own packages. But that's a dev decision.

> So, I'd suggest simplifying the problem, ie not activating any service here,
> and let user manage their system state using their usual configuration tools
> (drakxservice, chkconfig, whathever).

These services do not get magically activated by the installer AFAIK. It'll likely break the whole networking bits. Though maybe I could use "$DURING_INSTALL".

This discussion is more for the dev mailing list though. It's probably the way that it is for a reason, so before changing anything I'd rather have someone confirm. The initscripts maintainer shows as Colin. He hasn't been around in years.