Description of problem: In mga3 beta gnome and kde LiveDVD (I don't know about install from dvd), dbus-daemon-launch-helper is installed with group root instead of messagebus -rwsr-x--- 1 root root 307552 janv. 11 18:23 /usr/libexec/dbus-1/dbus-daemon-launch-helper Because of this wrong group, all the services that need servicehelper can't be activated and failed with this message (cf dbus.log in attachment) failed: Failed to execute program /usr/libexec/dbus-1/dbus-daemon-launch-helper eg. bug 8354, 9161 perhaps others If I reinstall dbus by urpmi --replacepkgs ftp://......./dbus-1.6.8-3.mga3... dbus-daemon-launch-helper is correctly reinstalled with messagebus as group, and services are activated without failing (idem if I manually change the group by chown root:messagebus). I don't understand what can happen, because user and group messagebus exist. messagebus user and group should be added by the dbus prein script %pre %_pre_useradd messagebus / /sbin/nologin %_pre_groupadd daemon messagebus I wonder if we can have a bug in installation ordering between dbus and rpm-helper (that provides add-user and add-group helper), because dbus requires are: Requires(post): rpm-helper >= 0.24.8-1 Requires(preun): rpm-helper >= 0.24.8-1 rpm -q --qf='[%{REQUIRES} %{REQUIREFLAGS:deptype}\n]' dbus |grep rpm-helper rpm-helper post rpm-helper preun Shouldn't we have Requires(pre): rpm-helper >= 0.24.8-1 Requires(postun): rpm-helper >= 0.24.8-1 to ensure that rpm-helper is installed before dbus (but if rpm-helper was installed after dbus, how and when messagebus user and group were created ? ) Reproducible: Steps to Reproduce:
Priority: Normal => release_blockerCC: (none) => ennael1, mageia, thierry.vignaud, tmbBlocks: (none) => 8354, 9161
Created attachment 3599 [details] dbus error log with beta 3 LiveDVD journalctl _SYSTEMD_UNIT=dbus.service
Good sluething Luc :) It should certainly have a Requires(pre) for the scripts. I don't know where the user might have been added however - that is a bit of a mystery. That said I've fixed the requires now so this should hopefully be solved and we can just draw a line under it! Probably best to keep this bug open until this is confirmed tho'.
On classic installer dvd i586 default kde install ls -l /usr/libexec/dbus-1/dbus-daemon-launch-helper -rwsr-x--- 1 root messagebus 331940 Jan 11 17:23 /usr/libexec/dbus-1/dbus-daemon-launch-helper* The /usr/libexec/dbus-1/dbus-daemon-launch-helper shows with red background in konsole.
(In reply to Colin Guthrie from comment #2) > > That said I've fixed the requires now so this should hopefully be solved and > we can just draw a line under it! Thanks > > Probably best to keep this bug open until this is confirmed tho'. Yes, something to check in beta 4 Live CD/DVD. >In reply to claire robinson from comment #3) > On classic installer dvd i586 default kde install > > ls -l /usr/libexec/dbus-1/dbus-daemon-launch-helper > -rwsr-x--- 1 root messagebus 331940 Jan 11 17:23 > /usr/libexec/dbus-1/dbus-daemon-launch-helper* > Thanks for the feedback. so installs from classical installer are not affected by this bug.
Still present in 3 beta 4, after install using the x86_64 gnome live dvd. # ll /usr/libexec/dbus-1/dbus-daemon-launch-helper -rwsr-x--- 1 root root 307552 Mar 11 06:10 /usr/libexec/dbus-1/dbus-daemon-launch-helper*
CC: (none) => davidwhodginsWhiteboard: (none) => 3beta4
Assignee: bugsquad => mageia
As this only happens in live environment, I suspect that it is perhaps an issue of getent working (and thus not adding the new user) but the uid not existing in the chroot and thus being owned by root.... That's my current guess.
Using rpm -Vva after booting into a kde live x86-64 dvd, it shows 3734 files have the wrong group, most of which are man pages. One example ... # ls -l /bin/rpm -rwxr-xr-x 1 rpm root 16136 Feb 4 03:30 /bin/rpm* The user and group rpm are in /etc/passwd, shadow and group. "chgrp rpm /bin/rpm" works, so the group is there. As the useradd command works, and the file has the correct owner, it looks like the getent is working properly. Looking more like there is a problem with rpm itself, or the way it's being invoked, and this affects a lot more packages then just messagebus, although for most, it doesn't seem to matter as much. Also noticed the /var/cache/man/* directories are missing.
*** Bug 8354 has been marked as a duplicate of this bug. ***
CC: (none) => eeeemail
(In reply to Dave Hodgins from comment #7) > Using rpm -Vva after booting into a kde live x86-64 dvd, it shows > 3734 files have the wrong group, most of which are man pages. good catch > > As the useradd command works, and the file has the correct > owner, it looks like the getent is working properly. > > Looking more like there is a problem with rpm itself, hum, really not sure about this, as the problem is only with live media. We don't have the problem on systems installed from classical installer. I suspect more a problem on live media build process. I've just mounted all the mageia 3 KDE4 live DVD distrib-lzma.sqfs; they all have this problem since alpha 2 (no problem on mageia 2 live).
Yup, just playing a bit with this and it seems the live CD filesystem itself is wrong. e.g. /usr/libexec/dbus-1/dbus-daemon-launch-helper is owned by root.root. As this is just piped through tar to the installed system, the incorrect ownership is simply mirrored there. So the problem is not specifically related to dbus itself but rather how the LiveCD is created. Can someone who knows this process better please comment on where they think the problem lies?
Source RPM: dbus-1.6.8-3.mga3 => bcd-3.7-3.mga3
Summary: dbus: dbus-daemon-launch-helper installed with wrong group => live media: Live media contains incorrectly owned files which are copied to "installed" system
CC: (none) => mageiaSource RPM: bcd-3.7-3.mga3 => draklive
It seems to be a packaging issue. In /var/lib/draklive/chroot/Mageia-3-beta4-LiveCD-GNOME-int-i586-CD-201303311901/root/drakx/install.log : group messagebus does not exist - using root dbus-1.6.8-4.mga3.i586
Though, rpm-helper has been installed just before dbus.
Created attachment 3676 [details] install.log for a Gnome live build This install.log from a Gnome live build shows many similar errors for other packages.
Some idle musings as I come across them. Running: mkdir foo sudo ./drakx-in-chroot http://a.mirror.for.mageia.org/mageia/distrib/cauldron/x86_64 `pwd`/foo Looking in: /tmp/drakx-in-chroot/tmp/stage2/etc/passwd I see a quite populated file including users for messagebus. But /tmp/drakx-in-chroot/tmp/stage2/etc/group does not exist. Reviewing the log I do not see any errors about users not existing, only groups. I feel the missing group file is likely relevant here....
FWIW, I just ran drakx-in-chroot on my machine and it created an image with correct group ownership. I cannot easily run draklive itself here to try and reproduce fully. Without being able to reproduce things, I'm not sure how I can debug further.
(In reply to Colin Guthrie from comment #14) > Reviewing the log I do not see any errors about users not existing, only > groups. I feel the missing group file is likely relevant here.... Nope, does not help. I manually added the Group file in stage2 on frozen repo I build live images from Before starting a new build, but I get the same missing group errors
(In reply to Colin Guthrie from comment #14) /tmp/drakx-in-chroot/tmp/stage2/etc/{passwd,group} are irrelevant. Those are those of the installing OS Those of the being installed OS would be /tmp/drakx-in-chroot/mnt/etc/{passwd,group} And yes stage2 doesn't include any /etc/group b/c it doesn't need one.
The issue is the same whatever is the installer, setup package is installed too late b/c there's not enough requires on it to get it in the early transactions. On my tests, one hundred packages got installed before it. In fact in the first transaction (glibc+filesytem+dash-static+libgcc1+...), the filesystem package would need setup to be installed b/c of files owned by non root groups. However requiring setup in filesystem means that the first transaction would be 115 packages big and that 12 packages' %post script fails (probably b/c ldconfig is run too late in %posttrans by filetriggers)
A solution could for the installer to dump a minimal /etc/group in chrooted system => bad b/c it would not be overwritten by rpm (to check since it wasn't in rpmdb before) => bad b/c it would be unsynced with setup changes A better solution would be to split setup in setup + setup-minimal. setup-minimal would contains /etc/passwd & /etc/group and would be required by filesystem.
Or drop setup's requires and old %pre/%post for years old tcb migration and years old "new" groups. This isn't actually tested since nobody tries migrating mdv2007.0 http://svn.mandriva.com/viewvc/packages/cooker/setup/current/SPECS/setup.spec?r1=208734&r2=208735&pathrev=616763&
One question... how is it we hit it only with draklive, not with traditional installer isos... ?
In that case, first transaction grows to 9 packages: dash-static glibc run-parts bash lib64termcap2 setup ncurses filesystem lib64ncurses5
Much more packages on live cd, different package sets so maybe setup got pushed farther away from first transactions, after dbus. Anyway those groups errors are easily reproduced with urpmi. Should be fixed in new setup+filesystem. It's in my basesystem-minimal test: no more group errors for filesystem, sysvinit-legacy-tools Please sync repos for draklive (or just filesytem+setup then rerun gendistrib (not genhdlist2!)) then rerun your build script
Status: NEW => RESOLVEDResolution: (none) => FIXED
comment #22 was for #20, comment #23 is for Thomas comment #21.
Looks good. Dropping the old stuff seems sensible :)
(In reply to Thierry Vignaud from comment #23) > Much more packages on live cd, different package sets so maybe setup got > pushed farther away from first transactions, after dbus. Well, a KDE live image is pretty much running boot.iso against full mirror and selecting KDE as desktop, so it should show up there too then... otoh not many users are testing full netinstalls during alpha/beta stage wich could explain lack of reports... > Anyway those groups errors are easily reproduced with urpmi. > Should be fixed in new setup+filesystem. > It's in my basesystem-minimal test: no more group errors for filesystem, > sysvinit-legacy-tools > Please sync repos for draklive (or just filesytem+setup then rerun Yep, will do, thanks for your help. > gendistrib (not genhdlist2!)) then rerun your build script yep, I Always use gendistrib on full tree.
And opening again as filesystem-2.1.9-20.mga3 and setup-2.7.20-4.mga3 are istalled in first transaction, but we still get group XXX does not exist, using root. :/
Status: RESOLVED => REOPENEDResolution: FIXED => (none)
Now we've different behaviour between urpmi --urpmi-root & draklive/drakx-in-chroot
I cannot reproduce with drakx-in-chroot from cauldron.
OK, in cauldron drakx-in-chroot as run by draklive still show those group errors whereas if run manually it doesn't... and the chrooted /var/spool from filesystem is properly owned whith manual drakx-in-chroot, not with one autoinstall one
Blino, can you review the autoinstall file?
On thing I see is that a newly generated auto_inst.cfg.pl has "'blowfish' => 1" instead of "'md5' => 1" + "'local' => 1" in "authentication"
also urpmi initialization in drakx is overridden The "debug_urpmi" option should be used instead
drakx-in-chroot copies /etc/resolv.conf in installer chroot (in case we used a remote DISPLAY or a remote repository). This prevent librpm to load some nss modules, which results in failure to lookup groups when chrooted in the _installed_ system. Fixed
Status: REOPENED => RESOLVEDResolution: (none) => FIXED