Comment # 14 on bug 1204180 from
(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: