Assigned to the package maintainer.

(Please set the status to 'assigned' if you are working on it)

Source RPM: (none) => wine-6.0-3.mga8.src.rpm
Assignee: bugsquad => rverschelde

I think this faild because

/proc/sys/fs/binfmt_misc/windows

already exists because of:

proc-sys-fs-binfmt_misc.automount and qemu installed on this system for aarch build ISO tests...
So the wine initscript should fail gracefully instead of report an error.

The initscript file, /etc/rc.d/init.d/wine should be removed from the package
as registering the binary format is the sole purpose of the script duplicating
the effect of /usr/lib/binfmt.d/wine.conf from the same package.

Lowering the priority as the impact is cosmetic.

Workaround is to run as root "chkconfig wine off" for those who do not want
systemd status showing degraded as it's status.

For now, I recommend removing the file /etc/rc.d/init.d/wine from the package
in svn and waiting for the next wine update for it to be distributed.

Priority: Normal => Low
CC: (none) => davidwhodgins

 I use the solution posted at the end of Alex Gromnitsky's blog 
https://gromnitsky.blogspot.com/2017/03/how-to-prevent-wine-from-auto-running.html :

# ln -s /dev/null /etc/binfmt.d/wine.conf
# systemctl restart systemd-binfmt

This seems to avoid all issues with wine service:

# systemctl status wine.service
● wine.service - LSB: Allow users to run Windows(tm) applications
     Loaded: loaded (/etc/rc.d/init.d/wine; generated)
     Active: active (exited) since Wed 2021-06-30 12:51:39 EEST; 12h ago
       Docs: man:systemd-sysv-generator(8)
      Tasks: 0 (limit: 19093)
     Memory: 0B
        CPU: 0
     CGroup: /system.slice/wine.service

Jun 30 12:51:39 ryzen-ux systemd[1]: Starting LSB: Allow users to run Windows(tm) applications...
Jun 30 12:51:39 ryzen-ux wine[2912]: Starting wine: [  OK  ]
Jun 30 12:51:39 ryzen-ux systemd[1]: Started LSB: Allow users to run Windows(tm) applications.

# systemctl status systemd-binfmt.service 
● systemd-binfmt.service - Set Up Additional Binary Formats
     Loaded: loaded (/usr/lib/systemd/system/systemd-binfmt.service; static)
     Active: active (exited) since Wed 2021-06-30 12:51:37 EEST; 12h ago
       Docs: man:systemd-binfmt.service(8)
             man:binfmt.d(5)
             https://www.kernel.org/doc/html/latest/admin-guide/binfmt-misc.html
             https://www.freedesktop.org/wiki/Software/systemd/APIFileSystems
   Main PID: 684 (code=exited, status=0/SUCCESS)
      Tasks: 0 (limit: 19093)
     Memory: 0B
        CPU: 0
     CGroup: /system.slice/systemd-binfmt.service

Regards.

CC: (none) => arusanu

The problem is caused by the wine package using both an init script and
systemd-binfmt to register the the binary formats. One or the other should
be used, not both.

Note that systemd-binfmt is used by packages other then wine, so I think it's
preferable to remove the init script.

(In reply to Dave Hodgins from comment #5)
> The problem is caused by the wine package using both an init script and
> systemd-binfmt to register the the binary formats. One or the other should
> be used, not both.
> 
> Note that systemd-binfmt is used by packages other then wine, so I think it's
> preferable to remove the init script.

Agree.

Priority: Low => Normal
Summary: wine.service failed at boot time, results systemd status degraded => Wine package should not have init.d script and a systemd-binfmt: wine.service failed at boot time
Status comment: (none) => Potential fix in Comment 5

Not directly related to this issue, but for the record: I picked up maintainership of the wine package when damsweb retired IIRC, but I've never been its most active maintainer (that's more tv).

I re-assigned the wine package to `nobody` as I'm not active enough to fulfill the needs for this package. I might still poke at some bugs as time permits but can't make any promise.

Re-setting assignee to pkg-bugs@, but feel free to snatch it up Thierry if you're up for it :)

CC: (none) => thierry.vignaud
Assignee: rverschelde => pkg-bugs

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

CC: (none) => pealfa

Also agree with Dave.  I guess care needs to be taken to have the updated package run 'chkconfig --del wine' so as not to leave old broken symlinks around, probably in a %triggerun scriplet.

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

CC: (none) => egc

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

CC: (none) => mageia

(In reply to David Walser from comment #9)
> Also agree with Dave.  I guess care needs to be taken to have the updated
> package run 'chkconfig --del wine' so as not to leave old broken symlinks
> around, probably in a %triggerun scriplet.

I think this part was ignored in the currently "fixed" wine packages...

I think it's not needed because the package removes the init script in it's %preun script.

So by dropping %post and %preun scripts in new version, the old bugged wine version removes the init script by itself.

I upgraded to local build version and didn't get a problem, tell me if you have trailing wine stuff in /etc/rc?.d/*wine ?

Best regards

For me the only remaining action is to pass the package from updates_testing to updates (and issue errata ?).

This script from previous version should handle init script removal :
%preun -n %{wine}
%_preun_service %{name}

We still need a list of the srpm/rpm packages, an advisory stating what the
purpose of the update is, and the bug assigned to qa before it can be
validated for moving from updates testing to updates.

I have uploaded a fixed package for Mageia 8.

You can test this by installing and see that it don't have a failing sysv init script anymore.

Suggested advisory:
========================

Updated wine packages fix failing sysv init script:

Wine sysv init fail since registering binfmt windows and windowsPE is already done by systemd-binfmt.service with /usr/lib/binfmt.d/wine.conf config rile.

This update just drop script and triggers, old package will drop the service itself.

References:
https://www.mageialinux-online.org/forum/topic-28733+wine.php
========================

Updated packages in core/updates_testing:
========================
In armv7hl and i586 arch:
wine-6.0-4.1.mga8
wine-devel-6.0-4.1.mga8
wine32-6.0-4.1.mga8

In aarch64 and x86_64 arch:
wine64-6.0-4.1.mga8
wine64-devel-6.0-4.1.mga8

Source RPMs: 
wine-6.0-4.1.mga8.src.rpm

MGA8-64 Plasma on Lenovo B50
This laptop did not have wine installed before.
No installation issues, i.e. no feedback on any problem.
Run winefile OK, so OK for me.

CC: (none) => herman.viaene
Whiteboard: (none) => MGA8-64-OK

Before installing the update ...
[root@x3 ~]# chkconfig 2>/dev/null|grep wine
wine            0:off   1:off   2:on    3:on    4:on    5:on    6:off
[root@x3 ~]# ls -l /etc/rc.d/rc3.d/S99wine 
lrwxrwxrwx 1 root root 14 Sep 13 14:19 /etc/rc.d/rc3.d/S99wine -> ../init.d/wine*

After installing the update ...
[root@x3 ~]# chkconfig 2>/dev/null|grep wine
[root@x3 ~]# ls -l /etc/rc.d/rc3.d/S99wine 
ls: cannot access '/etc/rc.d/rc3.d/S99wine': No such file or directory

Validating the update.

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2021-0185.html

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