-
Notifications
You must be signed in to change notification settings - Fork 59
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
issues with sysroot.bootprefix: true
#1667
Comments
This reverts commit f5677a3. We're seeing some related problems. Tracked in coreos/fedora-coreos-tracker#1667
revert PR for now: coreos/coreos-assembler#3723 |
This reverts commit f5677a3. We're seeing some related problems. Tracked in coreos/fedora-coreos-tracker#1667
This reverts commit 2a8d1e6. After some further testing this might be what is causing the GRUB failure mentioned in coreos/fedora-coreos-tracker#1667. Let's revert to see if the rawhide pipeline failures clear up.
The s390x coreos-installer failure has cleared up now that we have done coreos/coreos-assembler#3723 The GRUB failure did not clear up, however. I think it's related to coreos/coreos-assembler@2a8d1e6. Revert in coreos/coreos-assembler#3725 |
This reverts commit 2a8d1e6. After some further testing this might be what is causing the GRUB failure mentioned in coreos/fedora-coreos-tracker#1667. Let's revert to see if the rawhide pipeline failures clear up.
Upstream PR: osbuild/osbuild#1574 Right now we set compression to `true` (the default) because I'm still investigating if turning off compression is somehow causing our artifacts to not boot: coreos/fedora-coreos-tracker#1667 (comment)
Upstream PR: osbuild/osbuild#1574 Right now we set compression to `true` (the default) because I'm still investigating if turning off compression is somehow causing our artifacts to not boot: coreos/fedora-coreos-tracker#1667 (comment)
I split out the GRUB failure into a separate issue in coreos/coreos-assembler#3728 |
And drop all patches that have now been upstreamed. The only remaining patches are one to enable s390x builds to work while we figure out [1] and another that adds a log statement when cache eviction happens, which I plan to upstream at some point. [1] coreos/fedora-coreos-tracker#1667
And drop all patches that have now been upstreamed. The only remaining patches are one to enable s390x builds to work while we figure out [1] and another that adds a log statement when cache eviction happens, which I plan to upstream at some point. [1] coreos/fedora-coreos-tracker#1667
And drop all patches that have now been upstreamed. The only remaining patches are one to enable s390x builds to work while we figure out [1] and another that adds a log statement when cache eviction happens, which I plan to upstream at some point. [1] coreos/fedora-coreos-tracker#1667
I've checked the issue on
Probably we could change installer :
Or don't use (By the way in case of installation we already copy&modify /cc @jlebon |
And drop all patches that have now been upstreamed. The only remaining patches are one to enable s390x builds to work while we figure out [1] and another that adds a log statement when cache eviction happens, which I plan to upstream at some point. [1] coreos/fedora-coreos-tracker#1667
There is no need to copy `boot/loader/entries` folder and to create temporary `zipl.conf` , instead we could parse bls config and tell `zipl` which image and disk to use. This also fixes an issue when images comes with `bootprefix`. Issue: coreos/fedora-coreos-tracker#1667
There is no need to copy `boot/loader/entries` folder and to create temporary `zipl.conf` , instead we could parse bls config and tell `zipl` which image and disk to use. This also fixes an issue when images comes with `bootprefix`. Issue: coreos/fedora-coreos-tracker#1667
Should we now close this issue ? |
Yes. This was fixed with coreos/coreos-installer#1422 which landed in coreos/fedora-coreos-config@d517266 in rawhide and we switched over to setting |
ok found a new issue with the length of file paths for the kernel, which bootprefix seems to make worse :( I'll revert the change in COSA for now. |
Workaround an issue we are seeing where apparently the length of the entry in the BLS config is causing systems to not boot. - coreos/fedora-coreos-tracker#1667 (comment) - coreos/fedora-coreos-tracker#1647 (comment)
OK. rather than doing a full revert of coreos/coreos-assembler@a7d4312 I added a commit to coreos/coreos-assembler#3746 to just not set |
Workaround an issue we are seeing where apparently the length of the entry in the BLS config is causing systems to not boot. - coreos/fedora-coreos-tracker#1667 (comment) - coreos/fedora-coreos-tracker#1647 (comment)
We were blocked by coreos/fedora-coreos-tracker#1647 but the 6.9 kernel series doesn't appear to have the same problem. The 6.8 kernel does have the problem but our kernel filenames in stable releases of Fedora (i.e. not `rawhide`) won't be long enough to trigger the bug so we should be able to safely remove this since `rawhide` has moved on to 6.9 rc kernels. This should be the final piece to close out coreos/fedora-coreos-tracker#1667
PR to tie off the remaining loose end here: |
We were blocked by coreos/fedora-coreos-tracker#1647 but the 6.9 kernel series doesn't appear to have the same problem. The 6.8 kernel does have the problem but our kernel filenames in stable releases of Fedora (i.e. not `rawhide`) won't be long enough to trigger the bug so we should be able to safely remove this since `rawhide` has moved on to 6.9 rc kernels. This should be the final piece to close out coreos/fedora-coreos-tracker#1667
I think we are seeing a few problems since we implemented setting
sysroot.bootprefix: true
in coreos/coreos-assembler@f5677a3EDIT: this was unrelated to the sysroot.bootprefix` change. See coreos/coreos-assembler#3728
The first problem is that in the OSBuild workflow (i.e. onrawhide
right now) about half the time we end up with artifacts that fail to boot:but it doesn't appear to be every time, which is suspect. One thing about OSBuild versus non-OSBuild is that we are using
bootupd
to do the bootloader install there.The other issue we are hitting in the non-OSBuild workflow is that
coreos-installer
on s390x appears to not be able to handle this change either (pipeline run link) (at least I suspect the failure is related to the sysroot.bootprefix change).The text was updated successfully, but these errors were encountered: