On 09/06/21 12:35 am, Kairui Song wrote:
On Wed, Jun 9, 2021 at 2:47 AM Hari Bathini
<hbathini(a)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(a)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