** Changed in: ubuntu-z-systems
Status: In Progress => Fix Released
** Changed in: makedumpfile (Ubuntu Focal)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
This bug was fixed in the package kdump-tools - 1:1.6.10ubuntu1
---
kdump-tools (1:1.6.10ubuntu1) jammy; urgency=low
* Merge from Debian unstable. Remaining changes:
- debian/control/tests: sleep while waiting for systemd service.
- Bump amd64 crashkernel from 384M-:128M to
** Changed in: kdump-tools (Ubuntu)
Status: Fix Committed => In Progress
--
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
** Patch added: "fix for jammy"
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+attachment/5563543/+files/kdump-tools_1.6.10ubuntu1.debdiff
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
The build failed on jammy because of a new shellcheck warning, which was
fixed in Debian already. See https://bugs.debian.org/cgi-
bin/bugreport.cgi?bug=1002270.
I have uploaded a merge to a PPA, where it built just fine. I am
attaching the debdiff for that.
Cascardo.
** Bug watch added: Debian
** Changed in: makedumpfile (Ubuntu Groovy)
Status: In Progress => Won't Fix
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
Matching subscriptions: Maintainer
https://bugs.launchpad.net/bugs/1877533
Title:
The attachment "Fix for groovy" seems to be a debdiff. The ubuntu-
sponsors team has been subscribed to the bug report so that they can
review and hopefully sponsor the debdiff. If the attachment isn't a
patch, please remove the "patch" flag from the attachment, remove the
"patch" tag, and if
** Changed in: kdump-tools (Ubuntu)
Status: Invalid => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
Matching subscriptions: Maintainer
https://bugs.launchpad.net/bugs/1877533
Title:
So we have a generic 'Kernel Crash Dump' section in the Ubuntu Server Guide:
https://ubuntu.com/server/docs/kernel-crash-dump
that I may expand with a specific note about this situation, once it's rolled
out.
I agree, that would make sense.
--
You received this bug notification because you are
There is already documentation about it. For example, from
https://ubuntu.com/server/docs/kernel-crash-dump
"If the dump does not work due to OOM (Out Of Memory) error, then try
increasing the amount of reserved memory by editing
/etc/default/grub.d/kdump-tools.cfg. For example, to reserve 512
@cascardo 'ppa:cascardo/kdump2' was okay for me, when I tried it last
time - however, not sure if s/o from IBM tried it, too.
I think that the approach that you've described is totally valid and fine.
And the debdiff looks reasonable and incl. the 2G-4G case).
Since situations where dumps are
This is a debdiff for the proposed solution for kdump-tools, based on
latest version on impish.
** Patch added: "kdump-tools_1.6.9ubuntu1+cascardo1.debdiff"
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1877533/+attachment/5544958/+files/kdump-tools_1.6.9ubuntu1+cascardo1.debdiff
--
You
Aside from the new default crashkernel (or rather, whether to keep the
2G-4G:320M option or simply not setup crashkernel for the 2G-4G case),
how does the new version of kdump-tools on ppa:cascardo/kdump2 work?
To give you an answer, it does upgrade the crashkernel value on
zipl.conf to a new
This ticket is now discussed and worked on in a broader scope and is therefore
dependent on:
→ https://salsa.debian.org/debian/kdump-tools/-/merge_requests/5
→ https://bugs.debian.org/983486
** Bug watch added: Debian Bug tracker #983486
** Changed in: kdump-tools (Ubuntu)
Status: New => Invalid
--
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
** No longer affects: linux (Ubuntu)
** No longer affects: linux (Ubuntu Focal)
** No longer affects: linux (Ubuntu Groovy)
--
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
** Also affects: kdump-tools (Ubuntu)
Importance: Undecided
Status: New
** Changed in: makedumpfile (Ubuntu)
Status: In Progress => Invalid
** Changed in: kdump-tools (Ubuntu Focal)
Status: New => Invalid
** Changed in: kdump-tools (Ubuntu Groovy)
Status: New =>
** Patch added: "debdiff for hirsute"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1877533/+attachment/5457887/+files/zipl_hirsute.patch
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
@mihajlov
that is a good point. When there are less than 4GB of RAM, the default
cryptsetup benchmark should probably be capped at 128M of RAM, rather
than 1-2GB. Will ponder about that.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
https://github.com/snapcore/secboot/pull/127
--
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
Are these installs with zkey/paes or without?
Because, in Ubuntu, when zkey was introduced I have reverted the
s390-tools upstream change to lower the argon2i settings. Due to my lack
of understanding of the security features there. And later, we have made
similar choices for TPM backed
I think 512M for a 2GB system is a little too much to reserve. Can you
double check the details of that LUKS partition? Was it created during
an installation with a 2GB system? Or did you reduce the VM size after
installation?
Can you send the output of cryptsetup luksDump /dev/XXX?
Thanks.
So, it looks like the latest version from the same ppa:cascardo/kdump2
should be working much better now, handling that specific situation from
a new install containing crashkernel=196M. I tested both upgrade paths
from older kdump-tools or new installs, and they are working fine
starting with
So, after some investigation, it looks like the zipl-installer d-i
component is responsible for creating /etc/zipl.conf with the default
crashkernel parameter with value 196M.
With that into consideration, one wonders how kdump-tools would
previously set its default value of "384M-:128M" in
There should be no difference between using di or the new installer,
unless there is something the installer is doing that is causing this.
If you remove the crashkernel line from zipl.conf and run dpkg-
reconfigure kdump-tools, it should add the new configuration value.
Otherwise, it will keep
Where does that 196 value come from? Was it present on zipl.conf after a
pristine install? I wouldn't expect that on a pristine Ubuntu 20.04.1
install, so we would need to investigate where that value comes from. I
know s390-tools itself used to add that crashkernel value there, but
that only
If the user has not changed the value to something else, the size should
be increased after upgrade. If the user has changed, we keep the user's
value.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
I pushed a version for focal on my ppa. It is based on the latest
version found on groovy, so there should be other changes besides the
one for setting a better default of crashkernel on /etc/zipl.conf.
It's at ppa:cascardo/kdump2. Note that if the user has changed the value
from the previous
** Changed in: ubuntu-z-systems
Status: Incomplete => In Progress
--
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
So, of course the patch is useless, as s390x uses zipl. I will work on
upgrade paths during this week, so we can allow upgrades to have the new
setting when the old setting is kept as is.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
** Tags added: patch
--
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
Attached is a fix for s390x that is also built at my
ppa:cascardo/kdump2.
** Patch added: "Fix for groovy"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1877533/+attachment/5398755/+files/makedumpfile_1.6.7-3ubuntu2.debdiff
--
You received this bug notification because you are a
I am going to work out on a change to the default crashkernel value on
s390x to match what we do for ppc64el. That will improve the situation
on default installations.
** Changed in: makedumpfile (Ubuntu Groovy)
Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo)
** Changed
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
@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
** Changed in: ubuntu-z-systems
Status: Triaged => Incomplete
--
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
encrypted volume of the system being dump, or the encrypted volume which
is the target where to store the dump? (and thus more memory is needed
to unlock the drive?)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to makedumpfile in Ubuntu.
** Changed in: ubuntu-z-systems
Status: Incomplete => Triaged
--
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
@fheimes
No, in comment #2 I did not agree to bump the parameter.
@heinz-werner_seeck
My previous comment was not responded to. LUKS2 and Argon2i have no
effect on steady state RAM usage, and thus should not affect crashkernel
memory requirements significantly. Normally, Argon2i decryption has
Hi Thadeu, I was also a bit concerned about the check and I think that bumping
it generally to for example 512 (in addition with some doc) would be a feasible
compromise.
According to comment #2 I assume that Dimitri would agree on that, too.
** Changed in: ubuntu-z-systems
Status:
Setting as Invalid for linux, as this is not a linux bug. Marking as
Confirmed for makedumpfile, where there is a chance this might be fixed.
However, I disagree with checking for a specific module on a specific
architecture to decide crashkernel size.
crashkernel size is a suggestion. Users are
** Information type changed from Private to Public
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1877533
Title:
[20.10 FEAT] Increase the crashkernel setting if the root volume is
42 matches
Mail list logo
