I would suggest that you build core-image-sato-sdk with this change, but with three different options for INIT_MANAGER: INIT_MANAGER = "sysvinit" INIT_MANAGER = "systemd" INIT_MANAGER = "mdev-busybox"
Then run bitbake -c testimage for each of them. If it does not fail, then submit the patch again with a revised commit message, and then someone could take it through the full test matrix. I can do it. Systemd nowadays sets the de facto standards in these matters in mainstream distros, and other upstreams (e.g. glib) will make assumptions based on that, because most people develop on a mainstream distro, and all of them are using systemd. I'd say that in itself is a reason to align other init systems to match - if they aren't opinionated about it. Alex On Wed, 22 Mar 2023 at 20:00, <[email protected]> wrote: > > 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]> wrote: >> >> Am Fr, 17. Mär 2023 um 11:53:17 +0000 schrieb Richard Purdie >> <[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 (#178954): https://lists.openembedded.org/g/openembedded-core/message/178954 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]] -=-=-=-=-=-=-=-=-=-=-=-
