* [linux-next-20250212] syscall kexec_file_load not available @ 2025-02-13 15:04 Venkat Rao Bagalkote 2025-02-14 3:44 ` Sourabh Jain 2025-02-14 6:32 ` Hari Bathini 0 siblings, 2 replies; 8+ messages in thread From: Venkat Rao Bagalkote @ 2025-02-13 15:04 UTC (permalink / raw) To: linux-kernel, linuxppc-dev; +Cc: Sourabh Jain Greetings!!! From kernel next-20250210, I am observing syscall kexec_file_load not available, there by kdump service is failing to start. Logs: [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c Warning: append= option is not passed. Using the first kernel root partition Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c-d479-48b3-90e2-744a2fd05667 [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s syscall kexec_file_load not available. [root@ltc-zzci-1 ~]# kexec -v kexec-tools 2.0.27 [root@ltc-zzci-1 ~]# uname -r 6.14.0-rc2-next-20250212 Regards, Venkat. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-13 15:04 [linux-next-20250212] syscall kexec_file_load not available Venkat Rao Bagalkote @ 2025-02-14 3:44 ` Sourabh Jain 2025-02-14 6:32 ` Hari Bathini 1 sibling, 0 replies; 8+ messages in thread From: Sourabh Jain @ 2025-02-14 3:44 UTC (permalink / raw) To: Venkat Rao Bagalkote, linux-kernel, linuxppc-dev Hello Venkat, On 13/02/25 20:34, Venkat Rao Bagalkote wrote: > Greetings!!! > > From kernel next-20250210, I am observing syscall kexec_file_load not > available, there by kdump service is failing to start. > powerpc do have support for kexec_file_load system. Seems like there is an issue. Thanks for reporting the issue. I will debug and find what went wrong with next-20250210 or the kexec you used to load the kdump kernel. Thanks, Sourabh Jain > > Logs: > > [root@ltc-zzci-1 ~]# kexec -p > --initrd=/boot/initramfs-6.14.0-rc2-next-20250212kdump.img > /boot/vmlinuz-6.14.0-rc2-next-20250212 -c > Warning: append= option is not passed. Using the first kernel root > partition > Modified cmdline: elfcorehdr=311424K > root=UUID=b5b1f89c-d479-48b3-90e2-744a2fd05667 > [root@ltc-zzci-1 ~]# kexec -p > --initrd=/boot/initramfs-6.14.0-rc2-next-20250212kdump.img > /boot/vmlinuz-6.14.0-rc2-next-20250212 -s > syscall kexec_file_load not available. > [root@ltc-zzci-1 ~]# kexec -v > kexec-tools 2.0.27 > [root@ltc-zzci-1 ~]# uname -r > 6.14.0-rc2-next-20250212 > > > Regards, > > Venkat. > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-13 15:04 [linux-next-20250212] syscall kexec_file_load not available Venkat Rao Bagalkote 2025-02-14 3:44 ` Sourabh Jain @ 2025-02-14 6:32 ` Hari Bathini 2025-02-14 6:40 ` Venkat Rao Bagalkote 2025-02-14 6:45 ` Sourabh Jain 1 sibling, 2 replies; 8+ messages in thread From: Hari Bathini @ 2025-02-14 6:32 UTC (permalink / raw) To: Venkat Rao Bagalkote, linux-kernel, linuxppc-dev; +Cc: Sourabh Jain On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote: > Greetings!!! > > From kernel next-20250210, I am observing syscall kexec_file_load not > available, there by kdump service is failing to start. > > > Logs: > > [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- > next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c > Warning: append= option is not passed. Using the first kernel root > partition > Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- > d479-48b3-90e2-744a2fd05667 > [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- > next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s > syscall kexec_file_load not available. > [root@ltc-zzci-1 ~]# kexec -v > kexec-tools 2.0.27 > [root@ltc-zzci-1 ~]# uname -r > 6.14.0-rc2-next-20250212 > Is the kernel built with CONFIG_KEXEC_FILE ? - Hari ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-14 6:32 ` Hari Bathini @ 2025-02-14 6:40 ` Venkat Rao Bagalkote 2025-02-14 6:45 ` Sourabh Jain 1 sibling, 0 replies; 8+ messages in thread From: Venkat Rao Bagalkote @ 2025-02-14 6:40 UTC (permalink / raw) To: Hari Bathini, linux-kernel, linuxppc-dev; +Cc: Sourabh Jain Yes Hari, its built with CONFIG_KEXEC_FILE=y Regards, Venkat. On 14/02/25 12:02 pm, Hari Bathini wrote: > > > On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote: >> Greetings!!! >> >> From kernel next-20250210, I am observing syscall kexec_file_load >> not available, there by kdump service is failing to start. >> >> >> Logs: >> >> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c >> Warning: append= option is not passed. Using the first kernel root >> partition >> Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- >> d479-48b3-90e2-744a2fd05667 >> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s >> syscall kexec_file_load not available. >> [root@ltc-zzci-1 ~]# kexec -v >> kexec-tools 2.0.27 >> [root@ltc-zzci-1 ~]# uname -r >> 6.14.0-rc2-next-20250212 >> > > Is the kernel built with CONFIG_KEXEC_FILE ? > > - Hari > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-14 6:32 ` Hari Bathini 2025-02-14 6:40 ` Venkat Rao Bagalkote @ 2025-02-14 6:45 ` Sourabh Jain 2025-02-14 7:08 ` Hari Bathini 2025-02-14 14:43 ` Sourabh Jain 1 sibling, 2 replies; 8+ messages in thread From: Sourabh Jain @ 2025-02-14 6:45 UTC (permalink / raw) To: Hari Bathini, Venkat Rao Bagalkote, linux-kernel, linuxppc-dev Hello Hari, On 14/02/25 12:02, Hari Bathini wrote: > > > On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote: >> Greetings!!! >> >> From kernel next-20250210, I am observing syscall kexec_file_load >> not available, there by kdump service is failing to start. >> >> >> Logs: >> >> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c >> Warning: append= option is not passed. Using the first kernel root >> partition >> Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- >> d479-48b3-90e2-744a2fd05667 >> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s >> syscall kexec_file_load not available. >> [root@ltc-zzci-1 ~]# kexec -v >> kexec-tools 2.0.27 >> [root@ltc-zzci-1 ~]# uname -r >> 6.14.0-rc2-next-20250212 >> > > Is the kernel built with CONFIG_KEXEC_FILE ? I am able to reproduce it with CONFIG_KEXEC_FILE enabled. Seems like there is something went wrong in next-20250210 and next-20250212. kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250210kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250210 -d -s Try gzip decompression. Try LZMA decompression. [ 3375.712319] kexec_file: kernel: 00000000e539303c kernel_size: 0x2cdacf0 [ 3375.717022] ima: kexec measurement buffer for the loaded kernel at 0x0. [ 3375.717076] kexec_elf: Loaded the kernel at 0x0 [ 3375.717094] kexec_elf: Loaded purgatory at 0x0 [ 3375.717104] Loaded the backup region at 0x0 [ 3375.717130] crash_core: Crash PT_LOAD ELF header. phdr=000000004720e656 vaddr=0xc000000000000000, paddr=0x0, sz=0x10000 e_phnum=18 p_offset=0x0 [ 3375.717156] crash_core: Crash PT_LOAD ELF header. phdr=0000000005eb3f14 vaddr=0xc000000000010000, paddr=0x10000, sz=0xfff0000 e_phnum=19 p_offset=0x10000 [ 3375.717174] crash_core: Crash PT_LOAD ELF header. phdr=000000000ec70071 vaddr=0xc00000001ec20000, paddr=0x1ec20000, sz=0x13e0000 e_phnum=20 p_offset=0x1ec20000 [ 3375.717192] crash_core: Crash PT_LOAD ELF header. phdr=00000000b66c9c25 vaddr=0xc000000050000000, paddr=0x50000000, sz=0x3b0000000 e_phnum=21 p_offset=0x50000000 [ 3375.717215] Loaded elf core header at 0x0, bufsz=0x1000 memsz=0x80000 [ 3375.717229] kexec_elf: Loaded initrd at 0x0 [ 3375.718043] Memory node path: /memory@0 [ 3375.722854] kexec_elf: Loaded device tree at 0x0 syscall kexec_file_load not available. Kernel is reporting that all kexec segments are getting loaded at 0x0. Running kexec with strace shows that kexec_file_load system return -1 EINVAL. kexec_file_load(3, 4, 1, "\0", KEXEC_FILE_ON_CRASH) = -1 EINVAL (Invalid argument) Based on the logs printed on the console and kexec_file_load return value. I am suspecting kexec_file_load returned early form sanity_check_segment_list() because the segment is 0x0. I am investigating further to find how segment.mem for all segment is 0x0. Thanks, Sourabh Jain ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-14 6:45 ` Sourabh Jain @ 2025-02-14 7:08 ` Hari Bathini 2025-02-14 7:21 ` Sourabh Jain 2025-02-14 14:43 ` Sourabh Jain 1 sibling, 1 reply; 8+ messages in thread From: Hari Bathini @ 2025-02-14 7:08 UTC (permalink / raw) To: Sourabh Jain, Venkat Rao Bagalkote, linux-kernel, linuxppc-dev On 14/02/25 12:15 pm, Sourabh Jain wrote: > Hello Hari, > > > On 14/02/25 12:02, Hari Bathini wrote: >> >> >> On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote: >>> Greetings!!! >>> >>> From kernel next-20250210, I am observing syscall kexec_file_load >>> not available, there by kdump service is failing to start. >>> >>> >>> Logs: >>> >>> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >>> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c >>> Warning: append= option is not passed. Using the first kernel root >>> partition >>> Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- >>> d479-48b3-90e2-744a2fd05667 >>> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >>> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s >>> syscall kexec_file_load not available. >>> [root@ltc-zzci-1 ~]# kexec -v >>> kexec-tools 2.0.27 >>> [root@ltc-zzci-1 ~]# uname -r >>> 6.14.0-rc2-next-20250212 >>> >> >> Is the kernel built with CONFIG_KEXEC_FILE ? > > I am able to reproduce it with CONFIG_KEXEC_FILE enabled. > > Seems like there is something went wrong in next-20250210 and > next-20250212. > > kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250210kdump.img / > boot/vmlinuz-6.14.0-rc2-next-20250210 -d -s > > Try gzip decompression. > Try LZMA decompression. > [ 3375.712319] kexec_file: kernel: 00000000e539303c kernel_size: 0x2cdacf0 > [ 3375.717022] ima: kexec measurement buffer for the loaded kernel at 0x0. > [ 3375.717076] kexec_elf: Loaded the kernel at 0x0 > [ 3375.717094] kexec_elf: Loaded purgatory at 0x0 > [ 3375.717104] Loaded the backup region at 0x0 > [ 3375.717130] crash_core: Crash PT_LOAD ELF header. > phdr=000000004720e656 vaddr=0xc000000000000000, paddr=0x0, sz=0x10000 > e_phnum=18 p_offset=0x0 > [ 3375.717156] crash_core: Crash PT_LOAD ELF header. > phdr=0000000005eb3f14 vaddr=0xc000000000010000, paddr=0x10000, > sz=0xfff0000 e_phnum=19 p_offset=0x10000 > [ 3375.717174] crash_core: Crash PT_LOAD ELF header. > phdr=000000000ec70071 vaddr=0xc00000001ec20000, paddr=0x1ec20000, > sz=0x13e0000 e_phnum=20 p_offset=0x1ec20000 > [ 3375.717192] crash_core: Crash PT_LOAD ELF header. > phdr=00000000b66c9c25 vaddr=0xc000000050000000, paddr=0x50000000, > sz=0x3b0000000 e_phnum=21 p_offset=0x50000000 > [ 3375.717215] Loaded elf core header at 0x0, bufsz=0x1000 memsz=0x80000 > [ 3375.717229] kexec_elf: Loaded initrd at 0x0 > [ 3375.718043] Memory node path: /memory@0 > [ 3375.722854] kexec_elf: Loaded device tree at 0x0 > syscall kexec_file_load not available. > > Kernel is reporting that all kexec segments are getting loaded at 0x0. > > Running kexec with strace shows that kexec_file_load system return -1 > EINVAL. > > kexec_file_load(3, 4, 1, "\0", KEXEC_FILE_ON_CRASH) = -1 EINVAL (Invalid > argument) > > Based on the logs printed on the console and kexec_file_load return > value. I am suspecting > kexec_file_load returned early form sanity_check_segment_list() because > the segment is 0x0. > > I am investigating further to find how segment.mem for all segment is 0x0. > Interesting. Thanks for the update, Sourabh. I believe the error "syscall kexec_file_load not available." is inappropriate and misleading. That should be fixed too. - Hari ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-14 7:08 ` Hari Bathini @ 2025-02-14 7:21 ` Sourabh Jain 0 siblings, 0 replies; 8+ messages in thread From: Sourabh Jain @ 2025-02-14 7:21 UTC (permalink / raw) To: Hari Bathini, Venkat Rao Bagalkote, linux-kernel, linuxppc-dev On 14/02/25 12:38, Hari Bathini wrote: > > > On 14/02/25 12:15 pm, Sourabh Jain wrote: >> Hello Hari, >> >> >> On 14/02/25 12:02, Hari Bathini wrote: >>> >>> >>> On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote: >>>> Greetings!!! >>>> >>>> From kernel next-20250210, I am observing syscall kexec_file_load >>>> not available, there by kdump service is failing to start. >>>> >>>> >>>> Logs: >>>> >>>> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >>>> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c >>>> Warning: append= option is not passed. Using the first kernel root >>>> partition >>>> Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- >>>> d479-48b3-90e2-744a2fd05667 >>>> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >>>> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s >>>> syscall kexec_file_load not available. >>>> [root@ltc-zzci-1 ~]# kexec -v >>>> kexec-tools 2.0.27 >>>> [root@ltc-zzci-1 ~]# uname -r >>>> 6.14.0-rc2-next-20250212 >>>> >>> >>> Is the kernel built with CONFIG_KEXEC_FILE ? >> >> I am able to reproduce it with CONFIG_KEXEC_FILE enabled. >> >> Seems like there is something went wrong in next-20250210 and >> next-20250212. >> >> kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250210kdump.img / >> boot/vmlinuz-6.14.0-rc2-next-20250210 -d -s >> >> Try gzip decompression. >> Try LZMA decompression. >> [ 3375.712319] kexec_file: kernel: 00000000e539303c kernel_size: >> 0x2cdacf0 >> [ 3375.717022] ima: kexec measurement buffer for the loaded kernel at >> 0x0. >> [ 3375.717076] kexec_elf: Loaded the kernel at 0x0 >> [ 3375.717094] kexec_elf: Loaded purgatory at 0x0 >> [ 3375.717104] Loaded the backup region at 0x0 >> [ 3375.717130] crash_core: Crash PT_LOAD ELF header. >> phdr=000000004720e656 vaddr=0xc000000000000000, paddr=0x0, sz=0x10000 >> e_phnum=18 p_offset=0x0 >> [ 3375.717156] crash_core: Crash PT_LOAD ELF header. >> phdr=0000000005eb3f14 vaddr=0xc000000000010000, paddr=0x10000, >> sz=0xfff0000 e_phnum=19 p_offset=0x10000 >> [ 3375.717174] crash_core: Crash PT_LOAD ELF header. >> phdr=000000000ec70071 vaddr=0xc00000001ec20000, paddr=0x1ec20000, >> sz=0x13e0000 e_phnum=20 p_offset=0x1ec20000 >> [ 3375.717192] crash_core: Crash PT_LOAD ELF header. >> phdr=00000000b66c9c25 vaddr=0xc000000050000000, paddr=0x50000000, >> sz=0x3b0000000 e_phnum=21 p_offset=0x50000000 >> [ 3375.717215] Loaded elf core header at 0x0, bufsz=0x1000 memsz=0x80000 >> [ 3375.717229] kexec_elf: Loaded initrd at 0x0 >> [ 3375.718043] Memory node path: /memory@0 >> [ 3375.722854] kexec_elf: Loaded device tree at 0x0 >> syscall kexec_file_load not available. >> >> Kernel is reporting that all kexec segments are getting loaded at 0x0. >> >> Running kexec with strace shows that kexec_file_load system return -1 >> EINVAL. >> >> kexec_file_load(3, 4, 1, "\0", KEXEC_FILE_ON_CRASH) = -1 EINVAL >> (Invalid argument) >> >> Based on the logs printed on the console and kexec_file_load return >> value. I am suspecting >> kexec_file_load returned early form sanity_check_segment_list() >> because the segment is 0x0. >> >> I am investigating further to find how segment.mem for all segment is >> 0x0. >> > > Interesting. Thanks for the update, Sourabh. > I believe the error "syscall kexec_file_load not available." is > inappropriate and misleading. That should be fixed too. Agree. It is happening because kexec is handling ENOSYS, EINVAL, ENOEXEC, and ENOTSUP as a single case and printing "syscall kexec_file_load not available". I will send a fix for kexec tool to avoid this confusing error message. Thanks, Sourabh Jain ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [linux-next-20250212] syscall kexec_file_load not available 2025-02-14 6:45 ` Sourabh Jain 2025-02-14 7:08 ` Hari Bathini @ 2025-02-14 14:43 ` Sourabh Jain 1 sibling, 0 replies; 8+ messages in thread From: Sourabh Jain @ 2025-02-14 14:43 UTC (permalink / raw) To: Hari Bathini, Venkat Rao Bagalkote, linux-kernel, linuxppc-dev Hello, On 14/02/25 12:15, Sourabh Jain wrote: > Hello Hari, > > > On 14/02/25 12:02, Hari Bathini wrote: >> >> >> On 13/02/25 8:34 pm, Venkat Rao Bagalkote wrote: >>> Greetings!!! >>> >>> From kernel next-20250210, I am observing syscall kexec_file_load >>> not available, there by kdump service is failing to start. >>> >>> >>> Logs: >>> >>> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >>> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -c >>> Warning: append= option is not passed. Using the first kernel root >>> partition >>> Modified cmdline: elfcorehdr=311424K root=UUID=b5b1f89c- >>> d479-48b3-90e2-744a2fd05667 >>> [root@ltc-zzci-1 ~]# kexec -p --initrd=/boot/initramfs-6.14.0-rc2- >>> next-20250212kdump.img /boot/vmlinuz-6.14.0-rc2-next-20250212 -s >>> syscall kexec_file_load not available. >>> [root@ltc-zzci-1 ~]# kexec -v >>> kexec-tools 2.0.27 >>> [root@ltc-zzci-1 ~]# uname -r >>> 6.14.0-rc2-next-20250212 >>> >> >> Is the kernel built with CONFIG_KEXEC_FILE ? > > I am able to reproduce it with CONFIG_KEXEC_FILE enabled. > > Seems like there is something went wrong in next-20250210 and > next-20250212. > > kexec -p --initrd=/boot/initramfs-6.14.0-rc2-next-20250210kdump.img > /boot/vmlinuz-6.14.0-rc2-next-20250210 -d -s > > Try gzip decompression. > Try LZMA decompression. > [ 3375.712319] kexec_file: kernel: 00000000e539303c kernel_size: > 0x2cdacf0 > [ 3375.717022] ima: kexec measurement buffer for the loaded kernel at > 0x0. > [ 3375.717076] kexec_elf: Loaded the kernel at 0x0 > [ 3375.717094] kexec_elf: Loaded purgatory at 0x0 > [ 3375.717104] Loaded the backup region at 0x0 > [ 3375.717130] crash_core: Crash PT_LOAD ELF header. > phdr=000000004720e656 vaddr=0xc000000000000000, paddr=0x0, sz=0x10000 > e_phnum=18 p_offset=0x0 > [ 3375.717156] crash_core: Crash PT_LOAD ELF header. > phdr=0000000005eb3f14 vaddr=0xc000000000010000, paddr=0x10000, > sz=0xfff0000 e_phnum=19 p_offset=0x10000 > [ 3375.717174] crash_core: Crash PT_LOAD ELF header. > phdr=000000000ec70071 vaddr=0xc00000001ec20000, paddr=0x1ec20000, > sz=0x13e0000 e_phnum=20 p_offset=0x1ec20000 > [ 3375.717192] crash_core: Crash PT_LOAD ELF header. > phdr=00000000b66c9c25 vaddr=0xc000000050000000, paddr=0x50000000, > sz=0x3b0000000 e_phnum=21 p_offset=0x50000000 > [ 3375.717215] Loaded elf core header at 0x0, bufsz=0x1000 memsz=0x80000 > [ 3375.717229] kexec_elf: Loaded initrd at 0x0 > [ 3375.718043] Memory node path: /memory@0 > [ 3375.722854] kexec_elf: Loaded device tree at 0x0 > syscall kexec_file_load not available. > > Kernel is reporting that all kexec segments are getting loaded at 0x0. > > Running kexec with strace shows that kexec_file_load system return -1 > EINVAL. > > kexec_file_load(3, 4, 1, "\0", KEXEC_FILE_ON_CRASH) = -1 EINVAL > (Invalid argument) > > Based on the logs printed on the console and kexec_file_load return > value. I am suspecting > kexec_file_load returned early form sanity_check_segment_list() > because the segment is 0x0. > > I am investigating further to find how segment.mem for all segment is > 0x0. Posted a fix upstream: https://lore.kernel.org/all/20250214125402.90709-1-sourabhjain@linux.ibm.com/ Thanks, Soiurabh Jain ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2025-02-14 14:43 UTC | newest] Thread overview: 8+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2025-02-13 15:04 [linux-next-20250212] syscall kexec_file_load not available Venkat Rao Bagalkote 2025-02-14 3:44 ` Sourabh Jain 2025-02-14 6:32 ` Hari Bathini 2025-02-14 6:40 ` Venkat Rao Bagalkote 2025-02-14 6:45 ` Sourabh Jain 2025-02-14 7:08 ` Hari Bathini 2025-02-14 7:21 ` Sourabh Jain 2025-02-14 14:43 ` Sourabh Jain
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).