Questions about kexec-tools (resend to list)

[Philip Prindeville]

> On Mar 8, 2017, at 4:33 AM, Pratyush Anand <panand at redhat.com> wrote:
> 
> 
> 
> On Wednesday 08 March 2017 05:04 AM, Philip Prindeville wrote:
>> 
> 
> [...]
> 
>> 
>> Tried something like that:
>> 
>> root at PowercodeBMU:/# kexec -p /boot/vmlinuz --reuse-cmdline --append="irqpoll maxcpus=1 reset_devices 1"
>> Cannot get kernel page_offset_base symbol address
> 
> That you can ignore.
> Following patch will change this error message into warning:
> http://lists.infradead.org/pipermail/kexec/2017-March/018299.html


Done.  Thanks!


> 
>> Cannot load /boot/vmlinuz
> 
> Humm..can you pl run with -d and share debug output.

Sure thing:

root at PowercodeBMU:/# file /tmp/boot/boot/vmlinuz 
/tmp/boot/boot/vmlinuz: Linux kernel x86 boot executable bzImage, version 4.4.14 (philipp at ubuntu16) #10 Wed Mar 8 17:19:10 UTC 2017, RO-rootFS, swap_dev 0x2, Normal VGA
root at PowercodeBMU:/# 
root at PowercodeBMU:/# kexec -d -p /tmp/boot/boot/vmlinuz --reuse-cmdline --append="irqpoll maxcpus=1 reset_devices 1"
Try gzip decompression.
Try LZMA decompression.
lzma_decompress_file: read on /tmp/boot/boot/vmlinuz of 65536 bytes failed
kernel: 0x7f18b2596020 kernel_size: 0x27af20
MEMORY RANGES
0000000000000100-0000000000099bff (0)
0000000000099c00-000000000009ffff (1)
00000000000e0000-00000000000fffff (1)
0000000000100000-00000000cc309fff (0)
00000000cc30a000-00000000cc310fff (3)
00000000cc311000-00000000cc946fff (0)
00000000cc947000-00000000ccb5bfff (1)
00000000ccb5c000-00000000db8b4fff (0)
00000000db8b5000-00000000db957fff (1)
00000000db958000-00000000db96dfff (2)
00000000db96e000-00000000dbac3fff (3)
00000000dbac4000-00000000dbffefff (1)
00000000dbfff000-00000000dbffffff (0)
00000000dd000000-00000000df1fffff (1)
00000000f8000000-00000000fbffffff (1)
00000000fec00000-00000000fec00fff (1)
00000000fed00000-00000000fed03fff (1)
00000000fed1c000-00000000fed1ffff (1)
00000000fee00000-00000000fee00fff (1)
00000000ff000000-00000000ffffffff (1)
0000000100000000-000000041fdfffff (0)
CRASH MEMORY RANGES
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (3)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (2)
0000000000000005-ffffffffffffffff (3)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (1)
0000000000000005-ffffffffffffffff (0)
0000000000000130-00007f18b2a21938 (0)
Cannot get kernel page_offset_base symbol address
kernel symbol _stext vaddr =      a0000000005
kernel vaddr = 0xffffffff81000000 size = 0x818000
Memmap after adding segment
0000000000000000-000000000009ffff (0)
Cannot load /tmp/boot/boot/vmlinuz
root at PowercodeBMU:/# 

-Philip



> 
>> root at PowercodeBMU:/#
>> 
> 
> [...]
> 
>>> "crashkernel=" *must* *not* be passed to crash kernel. It is only for the primary kernel.
>> 
>> 
>> Okay.  And --reuse-cmdline takes care of stripping that out for you, it looks like.  That option isn’t discussed in Documentation/kdump/ but it might be handy to add something about it.
> 
> You should see about it in kexec-tools doc.
> 
> man kexec
> 
>> 
>> 
>> 
>>> 
>>>> 
> 
> [...]
> 
>>>> And assuming that you’re using the same kernel, etc. how does the init.d scripting on the crashdump (2nd instance of the kernel) know that it’s not the nominal kernel?  Do we use /sys/kernel/kexec_loaded for this purpose?  Or do we just look for the existence of /proc/vmcore?
>>> 
>>> Yep, you can find /proc/vmcore in 2nd kernel but not in 1st kernel.
>>> /sys/kernel/kexec_crash_loaded  should have 1 in 1st kernel while 0 in crash kernel.
>> 
>> 
>> So far I’m seeing the opposite:
>> 
>> root at PowercodeBMU:/# cat /proc/cmdline
>> BOOT_IMAGE=/boot/vmlinuz block2mtd.block2mtd=/dev/sda2,65536,rootfs,5 root=/dev/mtdblock0 rootfstype=squashfs rootwait console=tty0 console=ttyS0,115200n8r noinitrd crashkernel=64M
>> root at PowercodeBMU:/# cat /sys/kernel/kexec_crash_loaded
>> 0
> 
> Because your kexec -p did not succeed yet.
> 
> ~Pratyush