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
HI Benjamin,
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?
Regards, Xunlei 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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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.
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
On Tue, 2017-05-16 at 15:45 +0800, Xunlei Pang wrote:
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?
If I add "-o crypt" then dracut just hangs there after boot. No password prompt and no dumping either. After quite a while it goes into a loop of saying Warning: dracut-initqueue timeout - starting timeout scripts twice a second for some time and suddenly reboots then (no crash dump was created).
I think you also can create a bug describing the steps how to reproduce it.
Sure, I am happy to do that: https://bugzilla.redhat.com/show_bug.cgi?id=1451717
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject .org
On 05/17/17 at 01:02pm, Benjamin Berg wrote:
On Tue, 2017-05-16 at 15:45 +0800, Xunlei Pang wrote:
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?
If I add "-o crypt" then dracut just hangs there after boot. No password prompt and no dumping either. After quite a while it goes into a loop of saying Warning: dracut-initqueue timeout - starting timeout scripts twice a second for some time and suddenly reboots then (no crash dump was created).
Can you try boot kdump with rd.luks=0 add it in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND
I think you also can create a bug describing the steps how to reproduce it.
Sure, I am happy to do that: https://bugzilla.redhat.com/show_bug.cgi?id=1451717
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedoraproject .org
kexec mailing list -- kexec@lists.fedoraproject.org
Thanks Dave
To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
Hey,
On Thu, 2017-05-18 at 13:51 +0800, Dave Young wrote:
On 05/17/17 at 01:02pm, Benjamin Berg wrote:
[SNIP]
Can you try boot kdump with rd.luks=0 add it in /etc/sysconfig/kdump KDUMP_COMMANDLINE_APPEND
Sorry for not getting back to you earlier. I had just destroyed the installation I used for testing which made it a bit more complicated.
Anyway, seems like it is also prompting for a password if I pass rd.luks.
Benjamin
I think you also can create a bug describing the steps how to reproduce it.
Sure, I am happy to do that: https://bugzilla.redhat.com/show_bug.cgi?id=1451717
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@lists.fedoraproject.org To unsubscribe send an email to kexec-leave@lists.fedorapro ject .org
kexec mailing list -- kexec@lists.fedoraproject.org
Thanks Dave
To unsubscribe send an email to kexec-leave@lists.fedoraproject.org
-
Benjamin Berg -
Dave Young -
Xunlei Pang