@xnox, the unlock must happen for the root filesystem during dump,
independently from where it's going to dump to, though default
configuration is into local /var/crash/.
And even if the memory parameter is picked up depending on the system
size and crashkernel does that too, crashkernel takes memory out of the
system that cannot be used during production.
My opinion is that even we could tell how much memory would be necessary
for dumping, this is a matter of policy. A user with 2GiB can easily
unlock an Argon2i encrypted root filesystem with memory parameter close
to 1GB during boot. But would such user would be surprised to have now
only half of that memory available after boot because the other half was
reserved? Maybe the user only needed 1GiB for production and added the
extra 1GiB for crashkernel. Maybe the user didn't expect that.
Fortunately, the option is configurable. Unfortunately, we don't have an
easy way to advise the user how much memory will be necessary and it can
even change when system configuration changes. And I wouldn't still just
change the parameter without telling the user.
So, my suggestion here is that we try to improve the defaults, consider
changing s390x to match other arches that change that depending on
system memory size. In the future, we could have some tool that advise a
different setting. But right now, users are supposed to test that the
current setting works for them, change it to a working setting, maybe
consider changing their VM size because of that.
So, I am closing this issue as "Won't Fix".
Cascardo.
** Changed in: makedumpfile (Ubuntu Groovy)
Status: Incomplete => Won't Fix
** Changed in: makedumpfile (Ubuntu Focal)
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1877533
Title:
[20.10 FEAT] Increase the crashkernel setting if the root volume is
luks2-encrypted
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
