On 09/06/21 12:35 am, Kairui Song wrote:
On Wed, Jun 9, 2021 at 2:47 AM Hari Bathini hbathini@linux.ibm.com wrote:
On 07/06/21 2:24 pm, Kairui Song wrote:
Hi Hari,
Hi Kairui,
On Tue, May 25, 2021 at 5:19 PM Hari Bathini hbathini@linux.ibm.com wrote:
<snip>
Maybe we can figure out a way to simplify it later, like just extract the whole kdump initramfs into a subdirectory, like /kdumproot, and let init-fadump.sh chroot into.
Yeah. I do agree that an approach that has no dependency with squash module is much better. I am experimenting on it. Attached the WIP patch for your inputs. While it does work, there are a couple of open questions.
One, whether it is the optimal approach?
Two, dracut could build image with different compression methods. So, should init-fadump.sh be made to work for all such image types or enforce an image type and only support it. The former method makes maintaining init-fadump.sh tougher while the later method might make kdump service take much longer for fadump case (image build followed by extraction, then a supported compression and another image build..)
Hi Hari,
For the second approach (chroot into /fadumproot), I didn't mean extract the img file on system boot, I mean to extract the kdump initramfs on image build, and include that directory, something like:
cd /tmp/kdumpimg lsinitrd --unpack /boot/initramfs-kdump.img dracut --add zz-fadumpinit -i /tmp/kdumpimg /fadumproot /boot/initramfs.img
Simple chroot may not work as it is restrictive in nature. And switch_root needs a proper mount point to avoid running into weird issues. I need to try a few things to be sure though..
Thanks Hari