-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Gap discovered for installing QM in OSTREE image type, during setup #367
Comments
@Yarboa it seems similar we talked right ? |
unping, just saw it's related. |
reproduced locally:
Let me start investigate this one. |
no actions needed from @ericcurtin but adding him in the loop as he is one of the maint. of ostree project. He might have some ideas out of the box. |
Questions I'd ask is do we need to do this?
And is this referring to the /etc directory inside the container or outside the container: "/etc/localtime"? Poke around both just to be sure. |
This is the TZ thing in podman code:
But the thing is, this may be the behaviour we actually want in QM, it's supposed to be restricted. |
Similarly:
I suspect in QM the container store is in an alternate place? Maybe we should open an issue with: https://github.com/containers/storage/issues . The above code is from there. to see if we can configure that non-standard place. It is a bug regardless, because even without that imageStore directory it should be still be printing things like:
just panicing and showing nothing else, I dunno, it could show at least the stuff it knows about without that directory. |
And are both these things seen in OSTree images or Regular ones also? |
This shouldn't be run on a running OSTree system, I suspect that is the root cause of everything: https://github.com/containers/qm/blob/main/setup This script has to be run during osbuild, during some osbuild stages or be run as part of the rpm install stage. I suspect this script was being run on a "regular" system as quick and dirty way and to showcase the design, with the intent to integrate it with the composition of the image at build time later. |
I was wondering the same. Should be running in the osbuild-auto I guess? :)
Agreed. |
That's sounds reasonable.
|
@ericcurtin @dougsland But on the build of ostree we cannot run setup script. AFAIR, you can not run the script during the build, |
Hi @ericcurtin , forgot to answer this one, just ostree.
I was wondering something like below, please correct me if I am wrong. org.osbuild-auto.qm.setup.
of course, there is no chance to run setup manually to do more tests in ostree distro based as there is no dnf tool and that's what we want to solve in the first place. |
I believe we can run setup during the osbuild-auto stage. At least, that's what I am trying right now. |
This looks like you are on the right track @dougsland . There are points during osbuild where the system is completely malleable for this kind of thing. Then it gets hardened and read only. It might take some time to figure out the kinks but you should do this during osbuild. This is somewhat similar to what you were doing for initoverlayfs-install @dougsland . But just keep in mind how the end user will use this. I'm not close enough to qm to know how end users will use it. |
> @ericcurtin @dougsland But on the build of ostree we cannot run setup script. We could use prepared config files, copy it through osbuild pipeline , is not it ?
>
> AFAIR, you can not run the script during the build,
I believe we can run setup during the osbuild-auto stage. At least, that's what I am trying right now.
No currently we setup qm manually in osbuild, you can't run "random" script in
osbuild
|
Yes, I am aware of qm.ipp.yml, I was just looking to see if setup could do something missing. Thanks for the heads up. Going to execute more tests. |
For test only, I have removed https://github.com/containers/qm/blob/main/qm.container#L41 and qm is up again. I am wondering if it's something podman should WARN instead of ERROR. Also, @rhatdan do you have a suggestion? |
You should not run the setup script on a read-only /usr, even if we did something with /etc/localltime within the QM environment. Some of the scripts could try to do some modification of /usr within the QM. |
|
@rhatdan I can think of few workarounds for that, such as containers.conf or volume mount |
/etc is read-writable only sort of. Anything that gets written there won't persist after reboot. Maybe we just have to rewrite the script in an osbuild stage format so it's built as part of the OSTree image. /var is read-writable but is not atomically updatable like /usr . |
Interesting,
this one gives the following
I changes quadlet file to use this
Thu Apr 25 18:01:49 jst 2024 I will propose the TZ in qm.container ad ToBeFixed |
Hi Yariv, Agreed, this could be a good workaround until we figure out what happened with Timezone=local. On the other hand, setting empty TZ environment like Environment=TZ (the system interprets this as defaulting to Coordinated Universal Time (UTC)) or setting values like jst, America/New_York (Environment=TZ=America/New_York) etc make everything work again (autosd ostree and regular). output from the test
Anyway, we need to explore why Timezone=local is failing with podman/quadlet in a different issue as we discussed (in parallel) and avoid block the release. First question I would like to make is: downgrade/upgrade podman versions make this issue disappear? |
In recent tests with ostree + quadlet environment the QM service was not able to work correctly, podman failed to remove /etc/localtime affecting the QM service. This patch is a workaround to Timezone=local which uses Environment=TZ to set the default timezone to UTC until we work in root cause. More information: #367 Fixes: #367 Signed-off-by: Douglas Schilling Landgraf <[email protected]>
As we have the workaround, further investigation will continue here: #394 |
Currently QM is not up, due to TZ changes in qm boot
--tz=local tries to change RO file under /etc/qm
Need to apply changes similar to QM setup
https://github.com/containers/qm/blob/main/setup#L91-L105
The text was updated successfully, but these errors were encountered: