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

[ChenQi]

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?

Best Regards,
Chen Qi