I agree that the crashkernel size has especially an impact on smaller system. And right now the size is with 128MB obviously mainly optimized for smaller system, but does not really take the needs of bigger ones into account. However, this is done in a better way on other platforms, where we have a setting that is based on ranges, which provides more flexibility, I think.
So I would suggest to introduce such a staged, range-based approach for s390x too, like "crashkernel=384M-1G:128M,1G-3G:256M,3G-:512M" The crashkernel setting is of course configurable, but hitting slightly better values by default would improve the user experience and reduce the need for manual adjustments - instead of having to adjust it 'all the time' (which of course a bit overdrawn). And btw. I would estimate that an avg. s390x system has nowadys about 4GB RAM; and with the new installer I guess we even have a slightly higher minimal req. for RAM anyway (and not much people will install with a higher RAM footprint and reduce it post-install - and I'm also not sure if it's possible to install on a system with only 384MB RAM these days ...). So could such a range-based setting become a valid compromise? -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to makedumpfile in Ubuntu. https://bugs.launchpad.net/bugs/1877533 Title: [20.10 FEAT] Increase the crashkernel setting if the root volume is luks2-encrypted Status in Ubuntu on IBM z Systems: Incomplete Status in linux package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Incomplete Status in linux source package in Focal: Invalid Status in makedumpfile source package in Focal: Won't Fix Status in linux source package in Groovy: Invalid Status in makedumpfile source package in Groovy: Won't Fix Bug description: Description: In case the volume containing the root filesystem is encrypted using LUKS2 the memory used while unlocking the volume may exceed the size allocated to the kdump kernel. This will lead to a failure while processing kdump and the dump file will not be stored. Unfortunately, this condition may not be detected by a client before a problem occurs. The request is to have the kdump package installation script check for LUKS2 encryption (more precisely for Argon2i PBKDF, which is the root cause of the high memory usage). If the condition is met, the installation procedure should increase the crashkernel parameter to a higher value (>=512M)or issue a warning, if the system memory is insufficient to reserve enough crashkernel memory. Business Case: Pervasive Encryption and Secure Execution require encryption of the filesystems in order to keep customer data secure at all times. With the increasing usage of these technologies, the number of kdump will rise too, typically at inconvenient times, when the kdump is triggered due to a real customer issue. With the suggested change, the number of customer complaints and effort to handle them will be reduced. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
