Assigning to basesystem@ group as Colin is AWOL ;)

CC: (none) => mageia
Assignee: mageia => basesystem

This seems to be an upstream issue: https://github.com/systemd/systemd/issues/3339
and seems to be fixed by https://github.com/systemd/systemd/commit/acc0269cad31d1aaef2034a055b34c07c88a353d

Tested locally, this fixes the issue. Are there other systemd bugs open for mga6 systemd?

Status: NEW => ASSIGNED
CC: (none) => doktor5000
Assignee: basesystem => doktor5000

(In reply to Florian Hubold from comment #2)
> Tested locally, this fixes the issue. Are there other systemd bugs open for
> mga6 systemd?

I guess you could have a quick look through: https://bugs.mageia.org/buglist.cgi?f1=cf_rpmpkg&list_id=81681&o1=substring&query_format=advanced&resolution=---&v1=systemd

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

CC: (none) => laidlaws

It seems to be fixed for me.  Recently, in 6 Official, I was able to change the default target with no problems.  I had forgotten I even reported it.

I had this bug 5 days ago with an updated system. Still, the default target was changed, as if the segfault happens after the change is done.

CC: (none) => lists.jjorge

Well the segfault should not happen at all. And during my tests the target was unchanged. Anyways, should be fixed with systemd-230-12.1.mga6 which I just submitted to core/updates_testing.


test case as follows:

# query default runlevel (target) - usually graphical.target which equals 5
systemctl get-default
# try to change default runlevel, e.g. to multiuser.target which equals 3
systemctl set-default multi-user.target
# no segfault should be observed
# query default runlevel again, it should reflect to what it has been set to
systemctl get-default


@QA: I believe this should be sufficient for an advisory, feel free to reassign if something is missing.


i586
================
libsystemd0-230-12.1.mga6.i586
libudev1-230-12.1.mga6.i586
libudev-devel-230-12.1.mga6.i586
nss-myhostname-230-12.1.mga6.i586
systemd-230-12.1.mga6.i586
systemd-devel-230-12.1.mga6.i586
systemd-units-230-12.1.mga6.i586

x86_64
================
lib64systemd0-230-12.1.mga6.x86_64
lib64udev1-230-12.1.mga6.x86_64
lib64udev-devel-230-12.1.mga6.x86_64
nss-myhostname-230-12.1.mga6.x86_64
systemd-230-12.1.mga6.x86_64
systemd-devel-230-12.1.mga6.x86_64
systemd-units-230-12.1.mga6.x86_64

src
================
systemd-230-12.1.mga6.src

Component: Backports => RPM Packages
Assignee: doktor5000 => qa-bugs

(In reply to Florian Hubold from comment #7)
> test case as follows:
> 
> # query default runlevel (target) - usually graphical.target which equals 5
> systemctl get-default
> # try to change default runlevel, e.g. to multiuser.target which equals 3
> systemctl set-default multi-user.target
> # no segfault should be observed
> # query default runlevel again, it should reflect to what it has been set to
> systemctl get-default
>

Err, in case this is not obvious afterwards you probably want to switch back the runlevel to the previous value :)

systemctl set-default graphical.target

I have set mine to "runlevel5.target."  Is that a temporary, transitional option?

I tested on both x86_64 qemu_kvm VM and real hardware. Real hardware: systemd already upgraded 3 days ago.
Everything looks ok. No regression found.

Ulrich

I tried to paste the cli output of the test as attechment and upload a file without success.
Here you find the content: http://paste.debian.net/981724/

CC: (none) => bequimao.de

Created attachment 9609 [details]
On behalf of Ulrich Beckmann

(In reply to Ulrich Beckmann from comment #10)
> I tried to paste the cli output of the test as attechment and upload a file
> without success.

Problem fixed.

mga6  x86_64

Ran these commands as root.

# systemctl get-default
graphical.target
# systemctl set-default multi-user.target
Segmentation fault (core dumped)
# systemctl get-default
multi-user.target
# systemctl set-default graphical.target
Segmentation fault (core dumped)
# systemctl get-default
graphical.target

After updating...

# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.

and rebooting...

Deliberately left the runlevel at 3 to make sure that runlevel 5 could be recovered from the command line.  I am not recommending this to any other testers.  Logged in as root in the console after booting and ran the recovery commands.
# systemctl set-default graphical.target
# systemctl default

That brought up the display manager.  Logged in.

$ systemctl get-default
graphical.target

So this is OK for 64-bits.  This is one update which should definitely be tested in 32-bits as well, real hardware.

CC: (none) => tarazed25

Advisory from comments 0  & 7.

Whiteboard: MGA6-64-OK => MGA6-64-OK advisory

MGA6-32 on Asus A6000VM MATE
No installation issues.
Could replicate the problem with the stable SW before installation.
Test with new at CLI:
# systemctl get-default
graphical.target
# systemctl set-default multi-user.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/multi-user.target.
# systemctl get-default
multi-user.target
# systemctl set-default graphical.target
Removed /etc/systemd/system/default.target.
Created symlink /etc/systemd/system/default.target → /usr/lib/systemd/system/graphical.target.
# systemctl get-default
graphical.target

So seems OK.

CC: (none) => herman.viaene, sysadmin-bugs
Whiteboard: MGA6-64-OK advisory => MGA6-64-OK MGA6-32-OK advisory
Keywords: (none) => validated_update

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

http://advisories.mageia.org/MGAA-2017-0063.html

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