https://bugzilla.suse.com/show_bug.cgi?id=1204180 https://bugzilla.suse.com/show_bug.cgi?id=1204180#c14 --- Comment #14 from Josef Reidinger <jreidinger@suse.com> --- (In reply to Ignaz Forster from comment #13)
(In reply to Josef Reidinger from comment #12)
2. In previous ages for CAASP product we add that specific call that is called always for kdump, even when kdump is not enabled ( see comment#8 for code ). I am not sure if it is correct to call it always.
I think this code is still needed for openSUSE MicroOS / SLE Micro / ALP, otherwise kdump wouldn't be configured on first boot I guess?
But question is if it is correct to call it even when kdump is disabled? So basically yast knows if kdump is configured and if so, then it ensures that kdump rpm package is installed. But we now call that call unconditionally, which is maybe wrong?
3. I am not sure if `transactional-update kdump` handle disabled kdump. We need to have it when user configure kdump and then change mind. Is it correct to call also `transactional-update kdump` in that case?
Yes, it checks whether the kdump.service is activated and only runs if that is the case. However that check is performed in transactional-update itself, not in /usr/sbin/tu-rebuild-kdump-initrd, the helper script which is called from YaST directly during installation (where Package.IsTransactionalSystem doesn't seem to be true from how I understand the code).
yes, `IsTransactionalSystem` is true only when "/" is ro, but it is not case during installation, when it is open for modification. It is ro only on running system. To be honest I am not sure if `transactional-update kdump` will work in insts-sys where it runs in chroot and "/" is still rw. Well, I revisit code and recheck again logs from my reproduced attempt and 1. kdump is enabled by default on opensuse leap which quite surprise me 2. so I hoped that kdump inform that such packages I needed and looks like it is ignored by autoyast. So it is something to fix 3. if kdump is not configured then call to rebuild-kdump-initrd is skipped so it is no issue. -- You are receiving this mail because: You are on the CC list for the bug.