[OE-core] [PATCH 1/1] systemd: add back alternatives for init utitilies

Hongzhi, Song hongzhi.song at windriver.com
Mon Oct 22 07:20:38 UTC 2018



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 at 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
>




More information about the Openembedded-core mailing list