Re: [PATCH v20 3/5] arm64: kdump: reimplement crashkernel=X
On 2022/2/14 15:53, Leizhen (ThunderTown) wrote:
>
>
> On 2022/2/14 11:52, Baoquan He wrote:
>> On 01/24/22 at 04:47pm, Zhen Lei wrote:
>> ..
>>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>>> index 6c653a2c7cff052..a5d43feac0d7d96 100644
>>> --- a/arch/arm64/mm/init.c
>>> +++ b/arch/arm64/mm/init.c
>>> @@ -71,6 +71,30 @@ phys_addr_t arm64_dma_phys_limit __ro_after_init;
>>> #define CRASH_ADDR_LOW_MAX arm64_dma_phys_limit
>>> #define CRASH_ADDR_HIGH_MAXMEMBLOCK_ALLOC_ACCESSIBLE
>>>
>>> +static int __init reserve_crashkernel_low(unsigned long long low_size)
>>> +{
>>> + unsigned long long low_base;
>>> +
>>> + /* passed with crashkernel=0,low ? */
>>> + if (!low_size)
>>> + return 0;
>>> +
>>> + low_base = memblock_phys_alloc_range(low_size, CRASH_ALIGN, 0,
>>> CRASH_ADDR_LOW_MAX);
>>> + if (!low_base) {
>>> + pr_err("cannot allocate crashkernel low memory
>>> (size:0x%llx).\n", low_size);
>>> + return -ENOMEM;
>>> + }
>>> +
>>> + pr_info("crashkernel low memory reserved: 0x%llx - 0x%llx (%lld MB)\n",
>>> + low_base, low_base + low_size, low_size >> 20);
>>> +
>>> + crashk_low_res.start = low_base;
>>> + crashk_low_res.end = low_base + low_size - 1;
>>> + insert_resource(_resource, _low_res);
>>> +
>>> + return 0;
>>> +}
>>> +
>>> /*
>>> * reserve_crashkernel() - reserves memory for crash kernel
>>
>> My another concern is the crashkernel=,low handling. In this patch, the
>> code related to low memory is obscure. Wondering if we should make them
>> explicit with a little redundant but very clear code flows. Saying this
>> because the code must be very clear to you and reviewers, it may be
>> harder for later code reader or anyone interested to understand.
>>
>> 1) crashkernel=X,high
>> 2) crashkernel=X,high crashkernel=Y,low
>> 3) crashkernel=X,high crashkernel=0,low
>> 4) crashkernel=X,high crashkernel='messy code',low
>> 5) crashkernel=X //fall back to high memory, low memory is required then.
>>
>> It could be me thinking about it too much. I made changes to your patch
>> with a tuning, not sure if it's OK to you. Otherwise, this patchset
>
> I think it's good.
>
>> works very well for all above test cases, it's ripe to be merged for
>> wider testing.
>
> I will test it tomorrow. I've prepared a little more use cases than yours.
After the following modifications, I have tested it and it works well. Passed
all the test cases I prepared.
>
> 1) crashkernel=4G //high=4G,
> low=256M
> 2) crashkernel=4G crashkernel=512M,high crashkernel=512M,low //high=4G,
> low=256M, high and low are ignored
> 3) crashkernel=4G crashkernel=512M,high
> //high=4G, low=256M, high is ignored
> 4) crashkernel=4G crashkernel=512M,low
> //high=4G, low=256M, low is ignored
> 5) crashkernel=4G@0xe000 //high=0G,
> low=0M, cannot allocate, failed
> 6) crashkernel=512M //high=0G,
> low=512M
> 7) crashkernel=128M //high=0G,
> low=128M
> 8) crashkernel=512M@0xde00//512M@3552M
> //high=0G, low=512M
> 9) crashkernel=4G,high
> //high=4G, low=256M
> a) crashkernel=4G,high crashkernel=512M,low //high=4G,
> low=512M
> b) crashkernel=512M,high crashkernel=128M,low //high=512M,
> low=128M
> c) crashkernel=512M,low
> //high=0G, low=0M, invalid
>
>
>>
>> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
>> index a5d43feac0d7..671862c56d7d 100644
>> --- a/arch/arm64/mm/init.c
>> +++ b/arch/arm64/mm/init.c
>> @@ -94,7 +94,8 @@ static int __init reserve_crashkernel_low(unsigned long
>> long low_size)
>>
>> return 0;
>> }
>> -
>> +/*Words explaining why it's 256M*/
>> +#define DEFAULT_CRASH_KERNEL_LOW_SIZE SZ_256M
It's an empirical value.
94fb9334182284e8e7e4bcb9125c25dc33af19d4 x86/crash: Allocate enough low memory
when crashkernel=high
When the crash kernel is loaded above 4GiB in memory, the
first kernel allocates only 72MiB of low-memory for the DMA
requirements of the second kernel. On systems with many
devices this is not enough and causes device driver
initialization errors and failed crash dumps. Testing by
SUSE and Redhat has shown that 256MiB is a good default
value for now and the discussion has lead to this value as
well. So set this default value to 256MiB to make sure there
is enough memory available for DMA.
>> /*
>> * reserve_crashkernel() - reserves memory for crash kernel
>> *
>> @@ -105,10 +106,10 @@ static int __init reserve_crashkernel_low(unsigned
>> long long low_size)
>> static void __init reserve_crashkernel(void)
>> {
>> unsigned long long crash_base,
Re: [PATCH] arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges
Hi Will, On Tue, Feb 15, 2022 at 04:44:23PM +, Will Deacon wrote: > On Wed, Feb 09, 2022 at 09:26:42AM +, Huang Shijie wrote: > > The following interrelated ranges are needed by the kdump crash tool: > > MODULES_VADDR ~ MODULES_END, > > VMALLOC_START ~ VMALLOC_END, > > VMEMMAP_START ~ VMEMMAP_END > > > > Since these values change from time to time, it is preferable to export > > them via vmcoreinfo than to change the crash's code frequently. > > Please can you explain _why_ they are needed? The current Crash code is still based at kernel v4.9. The virtual memory layout looks like this: ++ |KASAN | MODULE | VMALLOC | | VMEMMAP | ++ The Crash uses MODULES range to set the VMALLOC ranges. If the ranges are wrong, Crash will _NOT_ works well for some latest kernel ,such as v5.11 later. (Please correct me if I am wrong). It seems the VMEMMAP range is less important. I list all the changes since v4.9 to now: 1.) The current crash code is based at kernel v4.9. The virtual memory layout looks like this: ++ |KASAN | MODULE | VMALLOC | | VMEMMAP | ++ The macros are: #define MODULES_VADDR (VA_START + KASAN_SHADOW_SIZE) #define MODULES_END (MODULES_VADDR + MODULES_VSIZE) #define VMALLOC_START (MODULES_END) #define VMALLOC_END (PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K) #define VMEMMAP_START (PAGE_OFFSET - VMEMMAP_SIZE) 2.) In the kernel v5.0, the patch will add a new BFP JIT region: "91fc957c9b1d arm64/bpf: don't allocate BPF JIT programs in module memory" The virtual memory layout looks like this: ++ | KASAN | BPF_JIT | MODULE | VMALLOC | | VMEMMAP| ++ The macros are: #define MODULES_VADDR (BPF_JIT_REGION_END) #define MODULES_END (MODULES_VADDR + MODULES_VSIZE) #define VMALLOC_START (MODULES_END) #define VMALLOC_END (PAGE_OFFSET - PUD_SIZE - VMEMMAP_SIZE - SZ_64K) #define VMEMMAP_START (PAGE_OFFSET - VMEMMAP_SIZE) The layout does not changed until v5.4. 3.) In the kernel v5.4, several patches changes the layout, such as: "ce3aaed87344 arm64: mm: Modify calculation of VMEMMAP_SIZE" "14c127c957c1 arm64: mm: Flip kernel VA space" and the virtual memory layout looks like this: ++ | KASAN | BPF_JIT | MODULE | VMALLOC | | VMEMMAP| ++ The macros are: #define MODULES_VADDR (BPF_JIT_REGION_END) #define MODULES_END (MODULES_VADDR + MODULES_VSIZE) #define VMALLOC_START (MODULES_END) #define VMALLOC_END (- PUD_SIZE - VMEMMAP_SIZE - SZ_64K) #define VMEMMAP_START (-VMEMMAP_SIZE - SZ_2M) 4.) In the kernel v5.11, several patches changes the layout, such as: "9ad7c6d5e75b arm64: mm: tidy up top of kernel VA space" "f4693c2716b3 arm64: mm: extend linear region for 52-bit VA configurations" and the virtual memory layout looks like this: ++ | BPF_JIT | MODULE | VMALLOC || VMEMMAP| ++ The macros are: #define MODULES_VADDR (BPF_JIT_REGION_END) #define MODULES_END (MODULES_VADDR + MODULES_VSIZE) #define VMALLOC_START (MODULES_END) #define VMALLOC_END (VMEMMAP_START - SZ_256M) #define VMEMMAP_START (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT))) #define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE) 5.) In the kernel v5.16, after the patch "b89ddf4cca43 arm64/bpf: Remove 128MB limit for BPF JIT programs" the virtual memory layout looks like this: ++ | MODULE | VMALLOC | | VMEMMAP| ++ The macros are: #define MODULES_VADDR (_PAGE_END(VA_BITS_MIN)) #define MODULES_END (MODULES_VADDR + MODULES_VSIZE) #define VMALLOC_START (MODULES_END) #define VMALLOC_END (VMEMMAP_START - SZ_256M) #define VMEMMAP_START (-(UL(1) << (VA_BITS - VMEMMAP_SHIFT))) #define VMEMMAP_END (VMEMMAP_START + VMEMMAP_SIZE) BTW:I am
[PATCH 2/4] kexec, KEYS, arm64: Make use of platform keyring for signature verification
commit 278311e417be ("kexec, KEYS: Make use of platform keyring for signature
verify")
adds platform keyring support on x86 kexec but not arm64.
Add platform keyring support on arm64 as well.
Fixes: 278311e417be ("kexec, KEYS: Make use of platform keyring for signature
verify")
Cc: kexec@lists.infradead.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Michal Suchanek
---
arch/arm64/kernel/kexec_image.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 1fbf2ee7c005..3dee7b2d8336 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -133,9 +133,17 @@ static void *image_load(struct kimage *image,
#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
static int image_verify_sig(const char *kernel, unsigned long kernel_len)
{
- return verify_pefile_signature(kernel, kernel_len,
- VERIFY_USE_SECONDARY_KEYRING,
- VERIFYING_KEXEC_PE_SIGNATURE);
+ int ret;
+
+ ret = verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_SECONDARY_KEYRING,
+ VERIFYING_KEXEC_PE_SIGNATURE);
+ if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING)) {
+ ret = verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_PLATFORM_KEYRING,
+ VERIFYING_KEXEC_PE_SIGNATURE);
+ }
+ return ret;
}
#endif
--
2.31.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 1/4] Fix arm64 kexec forbidding kernels signed with keys in the secondary keyring to boot
commit d3bfe84129f6 ("certs: Add a secondary system keyring that can be added
to dynamically")
split of .system_keyring into .builtin_trusted_keys and
.secondary_trusted_keys broke kexec, thereby preventing kernels signed by
keys which are now in the secondary keyring from being kexec'd.
Fix this by passing VERIFY_USE_SECONDARY_KEYRING to
verify_pefile_signature().
Cherry-picked from
commit ea93102f3224 ("Fix kexec forbidding kernels signed with keys in the
secondary keyring to boot")
Fixes: 732b7b93d849 ("arm64: kexec_file: add kernel signature verification
support")
Cc: kexec@lists.infradead.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Michal Suchanek
---
arch/arm64/kernel/kexec_image.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c
index 9ec34690e255..1fbf2ee7c005 100644
--- a/arch/arm64/kernel/kexec_image.c
+++ b/arch/arm64/kernel/kexec_image.c
@@ -133,7 +133,8 @@ static void *image_load(struct kimage *image,
#ifdef CONFIG_KEXEC_IMAGE_VERIFY_SIG
static int image_verify_sig(const char *kernel, unsigned long kernel_len)
{
- return verify_pefile_signature(kernel, kernel_len, NULL,
+ return verify_pefile_signature(kernel, kernel_len,
+ VERIFY_USE_SECONDARY_KEYRING,
VERIFYING_KEXEC_PE_SIGNATURE);
}
#endif
--
2.31.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
[PATCH 3/4] kexec, KEYS, s390: Make use of built-in and secondary keyring for signature verification
commit e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
adds support for KEXEC_SIG verification with keys from platform keyring
but the built-in keys and secondary keyring are not used.
Add support for the built-in keys and secondary keyring as x86 does.
Fixes: e23a8020ce4e ("s390/kexec_file: Signature verification prototype")
Cc: Philipp Rudo
Cc: kexec@lists.infradead.org
Cc: keyri...@vger.kernel.org
Cc: linux-security-mod...@vger.kernel.org
Cc: sta...@kernel.org
Signed-off-by: Michal Suchanek
---
arch/s390/kernel/machine_kexec_file.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/s390/kernel/machine_kexec_file.c
b/arch/s390/kernel/machine_kexec_file.c
index 8f43575a4dd3..fc6d5f58debe 100644
--- a/arch/s390/kernel/machine_kexec_file.c
+++ b/arch/s390/kernel/machine_kexec_file.c
@@ -31,6 +31,7 @@ int s390_verify_sig(const char *kernel, unsigned long
kernel_len)
const unsigned long marker_len = sizeof(MODULE_SIG_STRING) - 1;
struct module_signature *ms;
unsigned long sig_len;
+ int ret;
/* Skip signature verification when not secure IPLed. */
if (!ipl_secure_flag)
@@ -65,11 +66,18 @@ int s390_verify_sig(const char *kernel, unsigned long
kernel_len)
return -EBADMSG;
}
- return verify_pkcs7_signature(kernel, kernel_len,
- kernel + kernel_len, sig_len,
- VERIFY_USE_PLATFORM_KEYRING,
- VERIFYING_MODULE_SIGNATURE,
- NULL, NULL);
+ ret = verify_pkcs7_signature(kernel, kernel_len,
+kernel + kernel_len, sig_len,
+VERIFY_USE_SECONDARY_KEYRING,
+VERIFYING_MODULE_SIGNATURE,
+NULL, NULL);
+ if (ret == -ENOKEY && IS_ENABLED(CONFIG_INTEGRITY_PLATFORM_KEYRING))
+ ret = verify_pkcs7_signature(kernel, kernel_len,
+kernel + kernel_len, sig_len,
+VERIFY_USE_PLATFORM_KEYRING,
+VERIFYING_MODULE_SIGNATURE,
+NULL, NULL);
+ return ret;
}
#endif /* CONFIG_KEXEC_SIG */
--
2.31.1
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH] arm64: crash_core: Export MODULES, VMALLOC, and VMEMMAP ranges
On Wed, Feb 09, 2022 at 09:26:42AM +, Huang Shijie wrote: > The following interrelated ranges are needed by the kdump crash tool: > MODULES_VADDR ~ MODULES_END, > VMALLOC_START ~ VMALLOC_END, > VMEMMAP_START ~ VMEMMAP_END > > Since these values change from time to time, it is preferable to export > them via vmcoreinfo than to change the crash's code frequently. Please can you explain _why_ they are needed? Will ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V6] panic: Move panic_print before kmsg dumpers
On Mon 2022-02-14 11:13:09, Guilherme G. Piccoli wrote: > The panic_print setting allows users to collect more information in a > panic event, like memory stats, tasks, CPUs backtraces, etc. > This is an interesting debug mechanism, but currently the print event > happens *after* kmsg_dump(), meaning that pstore, for example, cannot > collect a dmesg with the panic_print extra information. > > This patch changes that in 2 steps: > > (a) The panic_print setting allows to replay the existing kernel log > buffer to the console (bit 5), besides the extra information dump. > This functionality makes sense only at the end of the panic() function. > So, we hereby allow to distinguish the two situations by a new boolean > parameter in the function panic_print_sys_info(). > > (b) With the above change, we can safely call panic_print_sys_info() > before kmsg_dump(), allowing to dump the extra information when using > pstore or other kmsg dumpers. > > The additional messages from panic_print could overwrite the oldest > messages when the buffer is full. The only reasonable solution is to > use a large enough log buffer, hence we added an advice into the kernel > parameters documentation about that. > > Cc: Feng Tang > Cc: Petr Mladek > Acked-by: Baoquan He > Signed-off-by: Guilherme G. Piccoli Makes sense and looks good to me. Reviewed-by: Petr Mladek Best Regards, Petr ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [RFC PATCH] kdump: Add support for crashkernel=auto
Hi Petr,
On Fri, 4 Feb 2022 06:34:19 +0100
Petr Tesařík wrote:
> Hi Philipp,
>
> Dne 31. 01. 22 v 11:33 Philipp Rudo napsal(a):
> > Hi,
> >
> > On Fri, 28 Jan 2022 11:31:49 +0100
> > Petr Tesařík wrote:
> >
> >> Hi Tiezhu Yang,
> >>
> >> On Jan 28, 2022 at 02:20 Tiezhu Yang wrote:
> >>> [...]
> >>> Hi Petr,
> >>>
> >>> Thank you for your reply.
> >>>
> >>> This is a RFC patch, the initial aim of this patch is to discuss what is
> >>> the proper way to support crashkernel=auto.
> >>
> >> Well, the point I'm trying to make is that crashkernel=auto cannot be
> >> implemented. Your code would have to know what happens in the future,
> >> and AFAIK time travel has not been discovered yet. ;-)
> >>
> >> A better approach is to make a very large allocation initially, e.g.
> >> half of available RAM. The remaining RAM should still be big enough to
> >> start booting the system. Later, when a kdump user-space service knows
> >> what it wants to load, it can shrink the reservation by writing a lower
> >> value into /sys/kernel/kexec_crash_size.
> >
> > Even this approach doesn't work in every situation. For example it
> > requires that the system has at least twice the RAM it requires to
> > safely boot. That's not always given for e.g minimalistic VMs or
> > embedded systems.
>
> If you reserve more RAM for the panic kernel than for running your
> actual workload, then you definitely have very special needs, and you
> should not expect that everything works out of the box.
That was basically the point I was trying to make. There is always a
scenario with special needs so that is is basically impossible to find
that one solution that works for everybody.
> > Furthermore the memory requirement can also change during runtime due
> > to, e.g. workload spikes, device hot plug, moving the dump target from
> > an un-encrypted to an encrypted disk, etc.. So even when your user-space
> > program can exactly calculate the memory requirement at the moment
> > it loads kdump it might be too little at the moment the system panics.
> > In order for it to work the user-space would constantly need to monitor
> > how much memory is needed and adjust the requirement. But that would
> > also require to increase the reservation during runtime which would be
> > extremely expensive (if possible at all).
> >
> > All in all I support Petr that time travel is the only proper solution
> > for implementing crashkernel=auto. But once we have time travel I
> > would prefer to use the gained knowledge to fix the bug that triggered
> > the panic rather than calculating the memory requirement for kdump.
>
> Yeah, long live patching! :-)
>
> >> The alternative approach does not need any changes to the kernel, except
> >> maybe adding something like "crashkernel=max".
> >
> > A slightly different approach is for the user-space tool to simply set
> > the crashkernel= parameter on the kernel commandline for the next boot.
> > This also works for memory restrained systems. Needs a reboot though...
>
> The downside is that if you remove some memory while your system is off,
> then a reservation calculate for the previous RAM size may no longer be
> possible on the next boot, and the kernel will boot up without any
> reservation. That's where "crashkernel=max" would come in handy. Let me
> send a patch and see the discussion.
True, in that situation our approach will fail. I'm looking forward to
see your patch.
Thanks
Philipp
> >>> A moment ago, I find the following patch, it is more flexible, but it is
> >>> not merged into the upstream kernel now.
> >>>
> >>> kernel/crash_core: Add crashkernel=auto for vmcore creation
> >>>
> >>> https://lore.kernel.org/lkml/20210223174153.72802-1-saeed.mirzamohamm...@oracle.com/
> >>>
> >
> > The patch was ultimately rejected by Linus
> >
> > https://lore.kernel.org/linux-mm/20210507010432.in24pudkt%25a...@linux-foundation.org/
> >
> > Thanks
> > Philipp
> >
> >>>
>
> > [...]
> > diff --git a/kernel/crash_core.c b/kernel/crash_core.c
> > index 256cf6d..32c51e2 100644
> > --- a/kernel/crash_core.c
> > +++ b/kernel/crash_core.c
> > @@ -252,6 +252,26 @@ static int __init __parse_crashkernel(char
> > *cmdline,
> > if (suffix)
> > return parse_crashkernel_suffix(ck_cmdline, crash_size,
> > suffix);
> > +
> > + if (strncmp(ck_cmdline, "auto", 4) == 0) {
> > +#if defined(CONFIG_X86_64) || defined(CONFIG_S390)
> > + ck_cmdline = "1G-4G:160M,4G-64G:192M,64G-1T:256M,1T-:512M";
> > +#elif defined(CONFIG_ARM64)
> > + ck_cmdline = "2G-:448M";
> > +#elif defined(CONFIG_PPC64)
> > + char *fadump_cmdline;
> > +
> > + fadump_cmdline = get_last_crashkernel(cmdline, "fadump=",
> > NULL);
> > + fadump_cmdline = fadump_cmdline ?
> > + fadump_cmdline + strlen("fadump=") : NULL;
> > +
Re: Is it possible to use a stream for initrd=
Hi, thanks for your answers, would be really cool if someone could implement it. Would help my Arch Linux project to save even more RAM. https://wiki.archlinux.org/title/Archboot greetings tpowa Am Di., 15. Feb. 2022 um 11:27 Uhr schrieb Philipp Rudo : > > Hi Tobias, > > On Wed, 9 Feb 2022 10:32:24 +0100 > Tobias Powalowski wrote: > > > Sorry you misunderstood, I don't want to create the initrd.img file. > > I want to pass the zstd directly to kexec initrd= option. > > sorry, that is not possible. The kexec-tools expect a file name with > --initrd. Simply passing a binary blob to be used as initrd isn't > implemented. > > Thanks > Philipp > > > greetings > > tpowa > > > > Am Mi., 9. Feb. 2022 um 10:28 Uhr schrieb Baoquan He : > > > > > > On 02/09/22 at 10:16am, Tobias Powalowski wrote: > > > > Hi, > > > > I have a tmp directory with all files placed in: > > > > find . -mindepth 1 -printf '%P\0' | sort -z | LANG=C bsdtar --uid 0 > > > > --gid 0 --null -cnf - -T - |\ > > > > LANG=C bsdtar --null -cf - --format=newc @- | zstd -T0 > /initrd.img > > > > > > > > and this initrd.img I want to write into kexec without creating the > > > > initrd file. > > > > > > > > kexec -l /vmlinuz-linux --initrd=/initrd.img --reuse-cmdline > > > > systemctl kexec > > > > > > See manpage of kexec, the EXAMPLE part: > > > > > > kexec -l /boot/vmlinux --initrd=/boot/initrd --reuse-cmdline > > > kexec -e > > > > > > > > -- Tobias Powalowski Archlinux Developer & Package Maintainer (tpowa) https://www.archlinux.org tp...@archlinux.org St. Martin-Apotheke Herzog-Georg-Str. 25 89415 Lauingen https://www.st-martin-apo.de i...@st-martin-apo.de ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: Is it possible to use a stream for initrd=
Hi Tobias, On Wed, 9 Feb 2022 10:32:24 +0100 Tobias Powalowski wrote: > Sorry you misunderstood, I don't want to create the initrd.img file. > I want to pass the zstd directly to kexec initrd= option. sorry, that is not possible. The kexec-tools expect a file name with --initrd. Simply passing a binary blob to be used as initrd isn't implemented. Thanks Philipp > greetings > tpowa > > Am Mi., 9. Feb. 2022 um 10:28 Uhr schrieb Baoquan He : > > > > On 02/09/22 at 10:16am, Tobias Powalowski wrote: > > > Hi, > > > I have a tmp directory with all files placed in: > > > find . -mindepth 1 -printf '%P\0' | sort -z | LANG=C bsdtar --uid 0 > > > --gid 0 --null -cnf - -T - |\ > > > LANG=C bsdtar --null -cf - --format=newc @- | zstd -T0 > /initrd.img > > > > > > and this initrd.img I want to write into kexec without creating the > > > initrd file. > > > > > > kexec -l /vmlinuz-linux --initrd=/initrd.img --reuse-cmdline > > > systemctl kexec > > > > See manpage of kexec, the EXAMPLE part: > > > > kexec -l /boot/vmlinux --initrd=/boot/initrd --reuse-cmdline > > kexec -e > > > > ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
