-
Notifications
You must be signed in to change notification settings - Fork 355
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
Revert the ESP maximum size back to 600MiB #5081
Conversation
This failed, but I think it's okay as the original PR to change the default included a release note. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You might want to drop also LGTM. Thank you for taking care of this!docs/release-notes/bigger-esp.rst
. Otherwise
well, it should probably be amended? The ESP will still be bigger than before we started changing things here, just not so much bigger. |
Oh. I missed that completely, thank you. In that case it's fine. |
I would say it's not completely accurate as written. I would change Description to: "The minimum size of the EFI System Partition (ESP) created by Anaconda has changed from 200 MiB to 500 MiB. The maximum size, which is used in most cases, remains at 600 MiB." |
Want me to update it to that? Im fine if someone wants to rewrite it on merge. |
The original issue was that 200MiB was too small, and we only increased the maximum for people experimenting with UKIs. Seeing as Anaconda chooses the maximum size in more cases than we'd like just drop the maximum size back down to 600MiB which is easily big enough for firmware updates. This should fix several regressions like: * https://bugzilla.redhat.com/show_bug.cgi?id=2212121 * https://bugzilla.redhat.com/show_bug.cgi?id=2214342 Signed-off-by: Richard Hughes <richard@hughsie.com>
b8960ca
to
afe5cef
Compare
Narrator: He did that. |
/kickstart-test --testtype smoke |
/kickstart-test --testtype storage (will need interpretation of results - runs also known failures) |
Interpretation of the storage kickstart tests results:
... I think I see a theme there. Onwards to logs... |
tl;dr I hope the commonality for LVM and part tests is the (explicit) storage layout in these tests, which is no longer valid. For the raid-luks group, it's more mysterious but the installation appears to succeed despite Case by case:
I think this indicates that mostly the tests need rewriting for the new storage layout, but I'll have to verify this manually. Next: Run the same kickstart scenario manually, investigate the VM. @hughsie @AdamWill Is this intended for beta already, or later? From the FE list I gather this is meant to go post-Beta, right? |
/kickstart-test --testtype storage (edit: The same test set failed again.) |
It is in the FE list: https://bugzilla.redhat.com/show_bug.cgi?id=2234951 . I would much prefer this land for Beta, it seems much safer for the behaviour to be the same in Beta and Final than not. |
I agree, probably rhinstaller/kickstart-tests#997 |
Well, duh. I missed that all of the failed tests are manual... they fail without the change as well.
(I think the bit that tripped me is that we usually add the disable-tags at the end of the list, but manual is at front.) |
The original issue was that 200MiB was too small, and we only increased the maximum for people experimenting with UKIs. Seeing as Anaconda chooses the maximum size in more cases than we'd like just drop the maximum size back down to 600MiB which is easily big enough for firmware updates.
This should fix several regressions like:
Thank you for your contribution!
Please check that your PR follows these rules:
Code conventions. tl;dr: Follow PEP8, wrap at 100 chars, and provide docstrings.
Commit message conventions. tl;dr: Heading, empty line, longer explanations, all wrapped manually. If in doubt, write a longer commit message with more details.
Tests pass and cover your changes. You can run tests locally manually, or have them run as part of the PR. A team member will have to enable tests manually after inspecting the PR.
If you don't know how, ask us for help!
Release notes and docs if the PR adds something major or changes existing behavior.
If you don't know how, ask us for help!
RHEL rules: If your PR is for a
rhel-*
branch, pay special attention to commit messages. Make sure all commit messages include a line linking the commit to a bug, such asResolves: rhbz#123456
. For more information, see the complete rules.If you don't know how, ask us for help!
Don't forget - if you don't know how, ask us for help!
And now that you read this all, you can delete it and type your own description of your changes :-)