On 10/22/2018 03:01 PM, ChenQi wrote:
On 10/21/2018 05:37 AM, Richard Purdie wrote:
On Fri, 2018-10-19 at 13:19 +0800, Chen Qi wrote:
Add back alternatives for init utilities to avoid regression.
These alternatives were removed when upgradeing systemd to 239.
They were removed out of the logic that init utitilies should be
bound to init manager. However, it turned out that two use cases
were not covered.
1) initramfs using commands like 'reboot' from busybox.
2) Users use customized busybox defconfig which enables init
utilities.
The first use case caused a regression bug in yocto.
https://bugzilla.yoctoproject.org/show_bug.cgi?id=12914
Patches were sent to fix the reboot problem.
But this is not enough. As we may have the second use case. In such
situation, users will find themselves having regression error when
using 'busybox + systemd' (and busybox is installed after systemd,
overriding the systemd symlinks).
So in order to avoid regression, add back these alternatives.
Signed-off-by
There is something odd going on which this change since it triggers:
https://autobuilder.yoctoproject.org/typhoon/#/builders/35/builds/95/steps/7/logs/step7c
I've isolated it to this change having initially thought it was Mark's
systemd change...
Cheers,
Richard
Hi Richard,
I saw all those reverts and tests about master-next on oe mailing list
and I really feel sorry for causing autobuilder failures.
Before I sent out the patch, I did do testimage test with
'core-image-minimal + systemd + ssh + package-management' and things
were working well.
Back to this failure, after some investigation, I finally found the
root cause. It's about udev-extraconf.
Before my patch, udev-extraconf actually does not work as originally
designed. Check the following codes in mount.sh from udev-extraconf.
BASE_INIT="`readlink "/sbin/init"`"
INIT_SYSTEMD="/lib/systemd/systemd"
if [ "x$BASE_INIT" = "x$INIT_SYSTEMD" ];then
# systemd as init uses systemd-mount to mount block devices
MOUNT="/usr/bin/systemd-mount"
UMOUNT="/usr/bin/systemd-umount"
[snip]
In our system, what we have is:
root@qemux86-64:~# ls -l /sbin/init
lrwxrwxrwx 1 root root 22 Oct 22 04:00 /sbin/init ->
../lib/systemd/systemd
As '../lib/systemd/systemd' does not equal to '/lib/systemd/systemd',
the mount.sh is not using systemd-mount.
When checking links, we should use `readlnk -f' instead of just
'readlink'. In other words, things happen to succeed for
core-image-sato because of some error in the mount.sh script from
udev-extraconf.
My patch links /sbin/init to /lib/systemd/systemd and that makes the
mount.sh start to work, thus revealing the error.
In fact, besides the dev-vda.mount problem, I also got
media-run-hdc.mount failure on core-image-sato. They are both caused
by the udev-extraconf.
I'm going to remove the 'init' from alternatives and send out V2. But
udev-extraconf also needs to be fixed.
(CC Hongzhi who did the change.)
Richard, what do you think we should do about the automount udev rule
from udev-extraconf?
I'd suggest that we do not install the automount udev rule in case of
systemd. I think the mount.sh script is likely to cause conflicts and
failures unless it's constructed very carefully in case of systemd.
Unfortunately, I don't think that script could be easily made
reliable, considering all the possible .mount and .automount units
that users may add as custom configuration.
Hongzhi, what's your opinion?
Hi all,
I am so sorry for causing failures. I will send patch to fix the issue
as soon as possible.
I agree with Chen Qi's suggestions. The "mount.sh" is out-of-date.
--Hongzhi
Best Regards,
Chen Qi
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
