On 05/16/2017 at 02:19 AM, Benjamin Berg wrote:
Hey,
On Tue, 2017-05-16 at 00:38 +0800, Xunlei Pang wrote:
> We've merged several fixes lately about not always mounting the root
> fs,
> does the latest kexec-tools(2.0.14-11) work for you?
A quick test suggests the issue persists. But I only upgraded kexec-
tools and dracut on the same machine. So it may be worth trying again
on a newer installation installation.
Hi Benjamin,
Updated kexec-tools and dracut should be enough.
Looks like it's not due to mount, maybe due to the encrypted device is discovered,
in case of ssh dumping, you can try to add "dracut_args -o crypt" or
"dracut_args -o lvm"
in /etc/kdump.conf, restart kdump service to see if it works?
I think you also can create a bug describing the steps how to reproduce it.
Thanks,
Xunlei
Benjamin
> On 05/15/2017 at 09:54 PM, Benjamin Berg wrote:
>> Hi,
>>
>> I was trying to configure kernel dumping (on a Fedora 25 machine).
>> In
>> this case the installation is encrypted using LUKS so to make
>> things
>> work I decided to dump to /boot instead.
>>
>> Now, I do understand prompting for the LUKS password if the dump
>> path
>> is on an encrypted device (which mkdumprd helpfully warns about).
>>
>> But I don't see why dumping to e.g. an unencrypted partition like
>> /boot
>> instead (or through ssh) should even try to open any LUKS devices.
>> There is no warning generated in that case but I still get a prompt
>> for
>> the password and dumping will only proceed afterwards.
>>
>> This seems odd. Mounting anything other than the dump location
>> should
>> not be necessary for the dumping processes. So the LUKS device
>> should
>> not be opened in this particular case. It should only happen if the
>> user selected an encrypted volume as the dump target.
>>
>> Benjamin
>> _______________________________________________
>> kexec mailing list -- kexec(a)lists.fedoraproject.org
>> To unsubscribe send an email to kexec-leave(a)lists.fedoraproject.org
>