FS#54943 - [systemd] [qemu] [libvirt] Two or more conflicting lines for kvm configured, ignoring.

Attached to Project: Arch Linux
Opened by Stefan (steinwanderer) - Thursday, 27 July 2017, 13:33 GMT
Last edited by Eli Schwartz (eschwartz) - Monday, 18 December 2017, 17:27 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To Anatol Pomozov (anatolik)
Architecture All
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 10
Private No

Details

Description:

systemd should not include the hardware access group "kvm" in "/usr/lib/sysusers.d/basic.conf".
"qemu" or "qemu-headless" comes with it own configuration for the "kvm" group. When qemu is installed it leads to the warning message:

Jul 27 15:00:51 systemd-sysusers[179]: Two or more conflicting lines for kvm configured, ignoring.

Removing this line from basic.conf solves this.

Additional info:

I'm not sure which configuration should be removed best, the systemd or the qemu one. I would guess the one that systemd comes with, because when qemu* is not installed, there is (imho) no need for a kvm group.

* package version(s)

systemd 234.11-1
qemu 2.9.0-2
qemu-headless 2.9.0-2

* config and/or log files etc.

Jul 27 15:00:51 systemd-sysusers[179]: Two or more conflicting lines for kvm configured, ignoring.

Steps to reproduce:

install systemd and one of qemu or qemu-headless and boot
This task depends upon

Closed by  Eli Schwartz (eschwartz)
Monday, 18 December 2017, 17:27 GMT
Reason for closing:  Fixed
Additional comments about closing:  qemu 2.11.0-2
libvirt 3.10.0-1
Comment by Stefan (steinwanderer) - Thursday, 27 July 2017, 13:55 GMT
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
Comment by David McAdoo (geecroof) - Thursday, 27 July 2017, 16:31 GMT
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
Comment by Eli Schwartz (eschwartz) - Thursday, 27 July 2017, 16:38 GMT
Please don't create duplicate bugreports, we can reassign this one if needed. End of story.
Comment by David McAdoo (geecroof) - Thursday, 27 July 2017, 16:51 GMT
@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.
Comment by Stefan (steinwanderer) - Thursday, 27 July 2017, 23:15 GMT
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.
Comment by Gustavo Alvarez (sl1pkn07) - Friday, 28 July 2017, 13:55 GMT
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
Comment by David McAdoo (geecroof) - Friday, 28 July 2017, 15:58 GMT
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.
Comment by Anatol Pomozov (anatolik) - Friday, 28 July 2017, 16:08 GMT
Folks, could you please provide patches for the projects mentioned above?
Comment by Eli Schwartz (eschwartz) - Friday, 28 July 2017, 16:18 GMT
Presumably libvirt does that in order to obey the https://wiki.archlinux.org/index.php/DeveloperWiki:UID_/_GID_Database
Comment by David McAdoo (geecroof) - Friday, 28 July 2017, 16:38 GMT
@anatolik I created simple patches for PKGBUILDS
Comment by loqs (loqs) - Friday, 28 July 2017, 17:28 GMT
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
Comment by David McAdoo (geecroof) - Friday, 28 July 2017, 18:02 GMT
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.
Comment by loqs (loqs) - Friday, 28 July 2017, 19:59 GMT
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?
Comment by Eli Schwartz (eschwartz) - Friday, 04 August 2017, 15:20 GMT
  • Field changed: Severity (Very Low → Medium)
loqs, be aware that repeatedly editing the same comment is not the best way to let people know you've said something. ;)

Comment by loqs (loqs) - Friday, 04 August 2017, 18:39 GMT
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.
Comment by David McAdoo (geecroof) - Friday, 04 August 2017, 19:25 GMT
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
Comment by loqs (loqs) - Friday, 04 August 2017, 19:41 GMT
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)
Comment by David McAdoo (geecroof) - Saturday, 05 August 2017, 17:25 GMT
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.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 11 August 2017, 20:02 GMT
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.
Comment by loqs (loqs) - Friday, 11 August 2017, 21:08 GMT
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.
Comment by Giancarlo Razzolini (grazzolini) - Friday, 11 August 2017, 21:21 GMT
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?
Comment by loqs (loqs) - Friday, 11 August 2017, 21:44 GMT
The patches are only against arch supplied files
Comment by Giancarlo Razzolini (grazzolini) - Friday, 11 August 2017, 21:52 GMT
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.
Comment by loqs (loqs) - Friday, 11 August 2017, 22:09 GMT
The patches where to fixup the PKGBUILDS I though that is what anatolik was asking for earlier apologies if I misunderstood.
Comment by loqs (loqs) - Friday, 11 August 2017, 23:10 GMT
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.
Comment by David McAdoo (geecroof) - Monday, 28 August 2017, 19:12 GMT Comment by Giancarlo Razzolini (grazzolini) - Monday, 28 August 2017, 19:39 GMT
I have started working on fixing both our libvirt and qemu packages, should have something ready this week.
Comment by loqs (loqs) - Monday, 28 August 2017, 20:27 GMT
@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?
Comment by Giancarlo Razzolini (grazzolini) - Monday, 28 August 2017, 20:46 GMT
@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.
Comment by loqs (loqs) - Sunday, 08 October 2017, 16:46 GMT
@grazzolini as systemd issue 6639 is now fixed with the systemd 235 now in testing can this issue now receive patching?
Comment by Anatol Pomozov (anatolik) - Friday, 17 November 2017, 18:47 GMT
Giancarlo, what is the status of this bugfix? Do you have a fix available or should we go with patches from Ioqs?
Comment by loqs (loqs) - Friday, 17 November 2017, 20:16 GMT
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
Comment by Tom Yan (tom.ty89) - Saturday, 18 November 2017, 11:05 GMT
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)
Comment by loqs (loqs) - Saturday, 18 November 2017, 13:50 GMT
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.
Comment by loqs (loqs) - Saturday, 18 November 2017, 14:13 GMT
$ 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
Comment by loqs (loqs) - Saturday, 18 November 2017, 19:56 GMT
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.
Comment by loqs (loqs) - Sunday, 19 November 2017, 22:42 GMT
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?
Comment by loqs (loqs) - Sunday, 19 November 2017, 23:32 GMT
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
Comment by loqs (loqs) - Monday, 20 November 2017, 00:33 GMT
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
Comment by Gene (GeneC) - Wednesday, 13 December 2017, 13:02 GMT
FYI - Still happening with systemd 235.38-4


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

Comment by Anatol Pomozov (anatolik) - Wednesday, 13 December 2017, 22:58 GMT
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.
Comment by loqs (loqs) - Thursday, 14 December 2017, 11:50 GMT
libvirt 3.10.0-1 qemu vm works on this system no errors or warnings.

Loading...