> On 19/04/2023 11:02, Pelle Windestam wrote:
>> Any ideas? I do not know where to continue troubleshooting from here. Is
>> it possible to "debug" the postinstall scriptlet in the environment that
>> it is running in?
>>
> It's a shell script. You can add pwd, ls, echo commands, and
> whatever else you would do during debugging. set -x comes to my
> my mind although I don't remember having done that. I see no
> reason why it would not work. Whether there is a way to do it
> more interactively I don't know.
>
> The output will be in the log file, I'd assume (although I have
> not had to debug any scriptlet recently). You could also use
> output redirection.
I tried adding some echo commands to the postinst template in
systemd.bbclass, but all that produced was some really weird build
errors. As far as I could figure out bitbake calls okpg which in turn
calls the post-install scriptlet, and bitbake then parses the output
(looking at the bitbake code it doesn't look like outputting some
arbitrary text would make it fail, but I'm no expert).
One interesting discovery from the build log when comparing to the
working application shows that the working application creates a link to
the systemd service, while the non-working application does not:
Installing B on root
Downloading file:[...]/B.ipk.
Configuring B.
B.postinst returned 1, marking as unpacked only, configuration required
on target.
WARNING: B.postinst returned 1, marking as unpacked only, configuration
required on target.
Installing A on root
Downloading file:[..]/A.ipk.
ln -s /lib/systemd/system/A.service
[..]/rootfs/etc/systemd/system/gateway.target.requires/A.service
Configuring A.
I guess that the missing link is what causes
systemctl ${OPTS} enable "$service"
in the postinstall scriptlet to fail. Given that these applications have
identical bitbake recipes except for the names, I do not understand why
this is happening.
//Pelle
The information contained in this email is intended solely for the use of the
individual or entity to whom it is addressed and may contain information that
is confidential. Please delete and notify the sender if received in error. SKF
does not accept liability for any damage arising from this email.
For information on SKF’s processing of your personal data, please visit SKF’s
Privacy Policy available via
www.skf.com<https://www.skf.com/us/footer/privacy-policy>.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59730): https://lists.yoctoproject.org/g/yocto/message/59730
Mute This Topic: https://lists.yoctoproject.org/mt/98362025/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
