After a turbulent week I finally have some time for the hobby again.
However, there is a hardware problem with my build machine. The CPU fan
failed and for some reason the warning for it was disabled in the bios.
I didn't notice it until the machine just crashed with an overheated
CPU while compiling. Cost me some sstate cache and I have to get a
replacement for the fan. I had done some tests with sysvinit and this
commit before. So far it looks like busybox/sysvinit has no major
problems with the change. However, it is of course possible that such
an invasive change could affect workflows that I didn't think of or
overlooked to change one or the other line.
In case the commit message gave the wrong impression, I would like to
explain that it was not my intention to push a change here just because
I like systemd. My logic was something like this:
Glib-2.0 uses ptest to ensure that /tmp is not a symlink. I am inclined
to believe that this is intended and not a bug in the test. Based on
this assumption, there are not many options. You could either make sure
that no symlink is created for ptests, which I don't think is a good
idea. Strictly speaking, this would undermine the test by creating a
different environment for it than exists on the target. It would be
more honest to simply ignore the test for that case.
So I thought it would be best to fulfill glibs needs and remove the
/tmp symlink everywhere. That's when systemd came into play because I
thought if you have to make such an invasive change anyway, you should
first see how systemd would expect it. That would be correct if you
agree that systemd should set the default.
If not, I could also send a variant where only the /tmp symlink is
replaced by a directory that has a mounted tmpfs but doesn't remove
/var/volatile/tmp. That might be a bit less invasive, but we would have
the problem that directory structure under sysvinit is fundamentally
different from that under systemd. In any case, even with this
approach, I couldn't 100% rule out that it could affect
sysvinit/busybox or even systemd based images or one or the other
workflow. But at least I tried my best not to break sysvinit.
If I need to run any specific tests I can do that as soon as my CPU
cools down again
On Fri, Mar 17 2023 at 07:10:36 PM +0000, Alexander Kanavin
<[email protected]> wrote:
I think it would help to at least take this through a-full so we have
a higher degree of knowledge in what breaks and what doesn’t.
I didn’t look at the patch in detail and won’t be able to for a
few more days. We definitely need to understand how it affects other
init systems, but it is totally doable, there is only a limited
number of them and how they handle tmp directories and what they
expect from them is tractable research. As long as no one expects RP
to do that.
Alex
On Fri 17. Mar 2023 at 17.31, Markus Volk <[email protected]
<mailto:[email protected]>> wrote:
Am Fr, 17. Mär 2023 um 11:53:17 +0000 schrieb Richard Purdie
<[email protected]
<mailto:[email protected]>>:
It would help me if adverse effects are mentioned in commit
messages.
In this case I can spot it easily enough but I don't always
know/spot
all the issues.
It would be too harsh to say that I don't care about sysvinit. Of
course, if something breaks as a result of this commit, I'm willing
to take care of it if I can help. It's just that I don't personally
use it, so I haven't identified any other issues that might be
relevant to sysvinit. Other than the obvious that anything that
would write directly to '/var/volatile/tmp' would break.
At least I checked that sysvinit images could still boot. I have
successfully run core-image-ptest-glib-2.0 with this patch applied.
If I knew of any problems with sysvinit I would have pointed them
out, but unfortunately I have no further findings yet
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#178953):
https://lists.openembedded.org/g/openembedded-core/message/178953
Mute This Topic: https://lists.openembedded.org/mt/97667591/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
