Arch Linux

Same goes for shadow 4.4-3 and systemd 234.11-1. Both come with a configuration for "lastlog", with difference in group owner. One is ignored with a warning message, like above.

systemd 234.11-1:

/usr/lib/tmpfiles.d/var.conf
f /var/log/lastlog 0664 root utmp -

shadow 4.4-3:

/usr/lib/tmpfiles.d/lastlog.conf
f /var/log/lastlog 0644 root root

I think that issue belongs to qemu, not systemd. "basic.conf" file us provided by upstream systemd build process while qemu.conf is added downstream in Arch. Also in cases as such systemd always took precedence. See situation for shadow you mentioned which is fixed in testing (by deleting file belonged to shadow). I created bugreport for qemu which is closed now as duplicate of this but as I stated above it should be the other way.

https://bugs.archlinux.org/task/54945

Please don't create duplicate bugreports, we can reassign this one if needed. End of story.

@eschwartz I would never created it if I knew about this one before but for some reason I didn't found it. Anyway I did your job by assigning it to the right place so it would be easier and faster if you follow my advice.

EDIT: I see it's assigned now, thanks.

It looks like "lastlog.conf" for "shadow" is also added downstream (as far as i can tell from the PKGBUILD) and to stay close to upstream, I like to suggest removing "/usr/lib/tmpfiles.d/lastlog.conf" from the package "shadow" as well.

edit: nevermind, i overread, that it is already fixed, sorry for the noise.

libvirt is also affected

/usr/lib/sysusers.d/basic.conf create the kvm group without predefined number

then in the libvirt pkgbuild need change https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/libvirt#n121

from:

chown -R 0:78 "$pkgdir"/var/lib/libvirt/qemu

to

chown -R 0:kvm "$pkgdir"/var/lib/libvirt/qemu

right?

EDIT: also this line:

https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/libvirt#n86

greetings

Yeah, it should be fixed too. It's weird that it uses digits instead of names.

I'm not sure if this bug current priority set as very low is adequate because when starting from fresh install systemd creates kvm group with random ID then libvirt creates folder with hardcoded group ID set to 78 which is linked to nothing.

Folks, could you please provide patches for the projects mentioned above?

Presumably libvirt does that in order to obey the https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database

@anatolik I created simple patches for PKGBUILDS

The problem with the libvirt_PKGBUILD.patch is using "chown -R root:kvm" that will use the gid of kvm on the build system
which will then be stored in the package but on the system installing the package /usr/lib/sysusers.d/basic.conf
"g kvm - - -" meaning kvm can have any numeric value so the entries can end up being owned by a random group or no group.
Using a tmpfiles.d snippet to change the ownership on install should avoid that issue.
The qemu_PKGBUILD.patch does not delete qemu.sysusers.
Edit:
Possibly (untested)
z /var/lib/libvirt/qemu/ 0770 - kvm - -
Edit2:
or do not package /var/lib/libvirt/qemu/ and then use
d /var/lib/libvirt/qemu/ 0770 - kvm - -
or change the ownership and access permissions in the .install file

Maybe we should patch systemd basic.conf by adding numeric group ID to kvm. Then we can get rid of qemu.sysusers in qemu package and leave libvirt untouched.

v1 modifies the directory permissions using tmpfiles.d with z /var/lib/libvirt/qemu/ 0770 - kvm -
v2 deletes the directory then recreates it using tmpfiles.d with d /var/lib/libvirt/qemu/ 0770 - kvm -
v3 modifies the directory ownership from libvirt.install directory access permissions modified by PKGBUILD as before
v4 as v1 but creates the group libvirt with sysusers.d
v5 as v2 but creates the group libvirt with sysusers.d
v6 as v3 but creates the group libvirt with sysusers.d
qemu.patch as geecroof's but deletes qemu.sysusers
Edit:
Do any other packages depend upon kvm having the gid 78?
The patches I have proposed so far assume there is nothing else that requires kvm to have that gid.
As geecroof suggests systemd could be altered to assign kvm the gid 86 or remove the kvm entry from systemd.
Edit2:
removing the kvm entry from systemd would cause /usr/lib/udev/rules.d/50-udev-default.rules to break
see https://github.com/systemd/systemd/commit/5a664ca10f38dbf66c07961707dafed66382caec
this also raises another point the first lines of 65-kvm.rules is now unnecessary
Edit3:
qemu.v2.patch removes mentioned entry from 65-kvm.rules assuming the kvm entry is still needed in qemu.install
Edit4:
@geecroof it seems for other sysuders.d entries systemd creates without a specific numeric id that arch
wants to assign an id to the filesystem package is used. New installs have the entry in /etc/group
upgrades use the install file that uses addgroup to manually add it so no sysusers.d conflict.
Edit5:
libvirt.v7.patch creates the group libvirt with sysusers.d assumes kvm will retain gid 78
realized libvirt patches v1-v6 missed sed -i 's|#group =.*|group="78"|' src/qemu/qemu.conf
it appears group can be specified as a string as well as numeric so will create new v1-v6 with that change.
Edit6:
libvirt.v#.2.patch uses string for group in src/qemu/qemu.conf
Edit7:
filesystem.patch to patch the filesystem package to assign kvm gid 78
Edit8:
If kvm retains gid 78 possibly add something to detect cases where is has been assigned a different gid
by the systemd sysusers.d conf such as the following to qemu or libvirt's .install file install function
test "$(getent group kvm | cut -d: -sf3 - )" != 78 && (echo kvm is expected to have gid 78)
Edit9:
The patches against libvirt will need reworking as a new release but I do not wish to waste effort on that if the proposed solutions are not acceptable.
Also https://bbs.archlinux.org/viewtopic.php?pid=1728380#p1728380 / https://bbs.archlinux.org/viewtopic.php?id=228785
demonstrates new installations are starting to experience breakage because of kvm's gid change.
Could the priority be raised to medium and also assigned against libvirt as it is now causing breakage?

loqs, be aware that repeatedly editing the same comment is not the best way to let people know you've said something. ;)

Thanks for the reminder eschwartz, I was trying to avoid bumping the topic missed that that particular rule is only for the forums.
Is there any arch policy relating to if kvm has keep gid 78 as it has already been assigned that gid on https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
If it has to keep that gid then could this bug also be assigned to the filesystem package as that appears to be where other such gids are fixed.

As all users who used systemd <234 with qemu have kvm group bind to 78 it should stay there, otherwise it will bring further breakages with packages like libvirt which used hardcoded GID

The libvirt.v2.*.patch I provided made the adjustments to libvirt for that.
To keep it at gid 78 qemu.v2.patch and filesystem.patch should accomplish that.
libvirt.v7.patch creates the group libvirt with sysusers.d assumes kvm will retain gid 78 but could be addressed as a separate issue.
Does leave the question if gid is left at 78 should any .install file detect systems where it is not with something like
test "$(getent group kvm | cut -d: -sf3 - )" != 78 && (echo kvm is expected to have gid 78)

Related issues already started appearing on forums:

https://bbs.archlinux.org/viewtopic.php?pid=1728382#p1728382
https://bbs.archlinux.org/viewtopic.php?pid=1728452#p1728452

It really need to be fixed soonish.

Ok. As far as I can tell this affects anyone who have installed qemu *after* systemd 234. We use fixed GID's because some package do require them. But for others it is mostly a convention to do so. Keep the id's under 1000 and all. I don't think qemu needs fixed GID at all. I think we could keep the systemd basic.conf file as is and change it on the qemu package. As for other packages affected by this, we need first to make sure they can work without fixed GID and, we could prepare a todo for all of them requiring them to not assign fixed UID's/GID's anymore.

The second approach would be to patch systemd and remove that file, but I'm not 100% sure about this.

systemd does not need to be patched for the second approach if filesystem supplies gid 78 kvm similar to it does for other groups specified in systemd sysusers.d entries.
patches for that second approach would be qemu.v2.patch and filesystem.patch plus possibly add in one of packages install files test "$(getent group kvm | cut -d: -sf3 - )" != 78 && (echo kvm is expected to have gid 78)
for systems already affected by the issue.
For the first approach looking at other packages depending upon qemu those should be the only ones depending upon kvm gid 78 as thats what has been proving it its gnome-boxes qtemu spice and libvirt.
libvirt does need patching for it to be dynamic ( patches already supplied ) the others do not seem to to need kvm gid 78.

I suggest you send those patches upstream, I don't think we should patch for this on our package. As I also don't think we should patch it on systemd. I do agree this is an issue for everyone that installs qemu after 234. Can you please send those patches to libvirt and paste here the link for your bug request there?

The patches are only against arch supplied files

If libvirt can run just fine without fixed GID, then I don't see the point for the patches, we simply drop fixed GID from qemu/libvirt and use only usernames and group names.

The patches where to fixup the PKGBUILDS I though that is what anatolik was asking for earlier apologies if I misunderstood.

Just started a kvm/qemu vm under libvirt with kvm having gid 993 so for me it works but this was far from a complete test.

More users reporting issues:
https://www.reddit.com/r/archlinux/comments/6wfe2u/fix_for_libvirt_failed_to_initialize_kvm/

I have started working on fixing both our libvirt and qemu packages, should have something ready this week.

@grazzolini the patches I provided did not work for you (would expect the libvirt ones to need rebasing as there has been a new release with this bug outstanding) ?
Which approach have you decided to use keep kvm using gid 78 or make it dynamic?

@loqs
The patches do work, but I first tried a systemd approach. In the process I have uncovered a systemd bug as well:

https://github.com/systemd/systemd/issues/6639

But after discussing with Dave, the better approach is to fix qemu/libvirt and make them GID agnostic, and use the group's name. I have tried your patches and I'm working on some changes to them and hopefully I'll be able to push the changes soon.

@grazzolini as systemd issue 6639 is now fixed with the systemd 235 now in testing can this issue now receive patching?

Giancarlo, what is the status of this bugfix? Do you have a fix available or should we go with patches from Ioqs?

qemu.v3.patch drop qemu.sysusers which provided 'g kvm 78 -' on new installs by lexical sorting qemu.conf loses to basic.conf so it has no effect on existing install sysusers will not modify an existing entry.
libvirt.v8.patch change group used by qemu.conf from its old gid of 78 to its name of kvm do not package /var/lib/libvirt/qemu let tmpfiles.d create it with correct permissions if it does not exist.
libvirt.additional change creation of the libvirt group to use sysusers

What's the libvirt group for btw? Why not a libvirt user as well? Would a libvirt user having libvirt group as its user group and kvm as its supplementary group work (and make more sense)? We may even be able to drop the latter in the future because of this:

https://github.com/systemd/systemd/commit/b8fd3d82205f632ce001fade74fed287e1564a1a

(or even implement it downstream now with the build option)

the libvirt group was added by https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/libvirt&id=eaab0c904d57f0e0557901ef90b50cd8517139b2
however it is referenced in the initial commit https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/libvirt&id=a51c8ab113f7351acfb05635b8399c19d5a06e68
so perhaps was it moved from somewhere else or previously it was created manually. It is used for https://wiki.archlinux.org/index.php/Libvirt#Set_up_authentication

On the topic the the kvm group https://libvirt.org/drvqemu.html#securitydac the PKGBUILD uses --with-qemu-user=nobody and --with-qemu-group=nobody
then changes /etc/libvirt/qemu.conf to enable the group=78 so qemu as run by the livirt system instance will use root:78 or root:kvm if patched
/run/libvirt/qemu/ is owned root:root but I believe this still works because of the 755 permissions.
/var/lib/libvirt/qemu/ is owned root:78 with permissions 0770 on executing libvirt ownership is changed to nobody:kvm
/var/cache/libvirt/qemu is owned root:root with permissions 0755 on executing libvirt ownership is changed to nobody:kvm

So do not package /var/cache/libvirt/qemu either?
The changing of ownerships by libvirt seems to contradict the behaviour described on the linked web page indicating libvirt should instead fail.

$ sudo rm -rf /var/run/libvirt/qemu /var/lib/libvirt/qemu /var/cache/libvirt/qemu/
$ stat /var/run/libvirt/qemu /var/lib/libvirt/qemu /var/cache/libvirt/qemu/
stat: cannot stat '/var/run/libvirt/qemu': No such file or directory
stat: cannot stat '/var/lib/libvirt/qemu': No such file or directory
stat: cannot stat '/var/cache/libvirt/qemu/': No such file or directory
$ systemctl start libvirtd.service
$ stat /var/run/libvirt/qemu /var/lib/libvirt/qemu /var/cache/libvirt/qemu/
File: /var/run/libvirt/qemu
Size: 40 Blocks: 0 IO Block: 4096 directory
Device: 14h/20d Inode: 49178 Links: 2
Access: (0755/drwxr-xr-x) Uid: ( 0/ root) Gid: ( 0/ root)
Access: 2017-11-18 14:07:01.753295521 +0000
Modify: 2017-11-18 14:07:01.603292179 +0000
Change: 2017-11-18 14:07:01.603292179 +0000
Birth: -
File: /var/lib/libvirt/qemu
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fe00h/65024d Inode: 5376670 Links: 8
Access: (0755/drwxr-xr-x) Uid: (65534/ nobody) Gid: ( 995/ kvm)
Access: 2017-11-18 14:07:01.603292179 +0000
Modify: 2017-11-18 14:07:01.753295521 +0000
Change: 2017-11-18 14:07:01.753295521 +0000
Birth: -
File: /var/cache/libvirt/qemu/
Size: 4096 Blocks: 8 IO Block: 4096 directory
Device: fe00h/65024d Inode: 7210971 Links: 3
Access: (0755/drwxr-xr-x) Uid: (65534/ nobody) Gid: ( 995/ kvm)
Access: 2017-11-18 14:07:01.603292179 +0000
Modify: 2017-11-18 14:07:01.623292626 +0000
Change: 2017-11-18 14:07:01.623292626 +0000
Birth: -

So even if the directories do not exist libvirt will create and own them to its liking

Similar finding for /run/libvirt
$ sudo rm -rf /run/libvirt/
$ systemctl start libvirtd.service
$ ls -la /run/libvirt
total 0
drwxr-xr-x 8 root root 260 Nov 18 19:38 .
drwxr-xr-x 27 root root 740 Nov 18 19:38 ..
drwxr-xr-x 2 root root 40 Nov 18 19:38 hostdevmgr
srwx------ 1 root root 0 Nov 18 19:38 libvirt-admin-sock
srwxrwxrwx 1 root root 0 Nov 18 19:38 libvirt-sock
srwxrwxrwx 1 root root 0 Nov 18 19:38 libvirt-sock-ro
drwxr-xr-x 2 root root 40 Nov 18 19:38 lxc
drwxr-xr-x 2 root root 60 Nov 18 19:38 network
drwxr-xr-x 2 root root 40 Nov 18 19:38 qemu
drwxr-xr-x 2 root root 40 Nov 18 19:38 storage
drwxr-xr-x 2 root root 40 Nov 18 19:38 uml-guest
srw-rw-rw- 1 root root 0 Nov 18 19:38 virtlockd-sock
srw-rw-rw- 1 root root 0 Nov 18 19:38 virtlogd-sock

So libvirtd does not appear to need /run/libvirt to be present to function either also the current libvirt.tmpfiles.d only covers
four of the six directories libvirtd creates, missing hostdevmgr and storage in addition the uml directory appears to have become uml-guest

So the tmpfiles.d snippet could be dropped and /var/cache/libvirt/qemu removed from packaging along with /var/lib/libvirt/qemu
or adjust the tmpfiles.d snippet to create what libvirtd will create itself.

Rather than deleting "$pkgdir"/var/cache/libvirt/qemu and "$pkgdir"/var/lib/libvirt/qemu so they are not packaged can the options=('emptydirs') be dropped?

Meant options=('!emptydirs') libvirt empty directories.txt contains a list of the directories that would no longer be packaged
Leaving only "$pkgdir"/etc/sysconfig containing files so still needs rm -rf ( "$pkgdir"/etc/rc.d appears to no longer be supplied by upstream )
this also means libvirt.tmpfiles.d no longer needs to be shipped
--with-qemu-group=kvm means the config file no longer has to be modified and can be shipped as is

Using options=('!emptydirs') fails because /var/log/libvirt/qemu/ is not automatically created

So libvirt.v10.patch --with-qemu-group=kvm means the config file no longer has to be modified and can be shipped as is
do not package $pkgdir"/var/lib/libvirt/qemu or $pkgdir"/var/cache/libvirt/qemu libvirtd will create them itself with the correct ownership
do not rm -rf "$pkgdir"/etc/rc.d directory does not exist
remove the tmpfiles.d snippet as libvirtd will create all the entries itself
not implemented possibly do not package $pkgdir"/var/lib/libvirt/ instead of just $pkgdir"/var/lib/libvirt/qemu
similarly for $pkgdir"/var/cache/libvirt/ instead of $pkgdir"/var/cache/libvirt/qemu
consider switching creation of libvirt group to using sysusers see https://bugs.archlinux.org/task/54943#comment163489

FYI - Still happening with systemd 235.38-4


systemd-sysusers[28388]: Two or more conflicting lines for kvm configured, ignoring.

Ioqs, thanks a lot for your work! I merged your patches to libvirt/qemu and pushed updated packages to [testing] repositories. Please update the packages and let me know if you see any issues with users/groups/permissions.

libvirt 3.10.0-1 qemu vm works on this system no errors or warnings.