[LEDE-DEV] Supporting crashdumps w/ kexec

[Philip Prindeville]

Inline…


> On Mar 9, 2017, at 12:35 PM, monster_philip at redfish-solutions.com wrote:
> 
> 
>> On Mar 8, 2017, at 8:32 PM, Luiz Angelo Daros de Luca <luizluca at gmail.com> wrote:
>> 
>> 1st: Is where does /boot get unmounted, and is there an easy way to
>> keep it around a bit longer, at least until the init.d scripts have
>> finished running?
>> A: /boot (aka sda1) is never mounted on x86/x86_64. It could but it is
>> simply unnecessary. grub is the only one that reads it (for loading
>> grub confs and the kernel)


Okay, but if I wanted to have it be mounted (in the correct place), as part of the unionfs how would that happen?

Because kexec needs to see the replacement (crash-dump) kernel.  Ideally as /boot/vmlinuz

Also, is there a way to identify the boot partition reliably?  There doesn’t seem to be a make variable that points to it at build-time (unless CONFIG_TARGET_ROOTFS_PARTNAME).  What about a UUID or LABEL?

I’m trying to write the kexec init.d script so that it’s architect agnostic.


>> 
>> 2nd: Or what if I want to configure an extra menuentry in /boot/grub/grub.cfg?
>> A: If you need to add extra kernel parameters, you simply need to
>> mount sda1 somewhere (like /boot) and do as you would in a normal
>> linux. You can edit grub conf there.


That’s less than ideal.  Because on the FS, the path is boot/vmlinuz … so if I mount it as /mnt/boot then the full path will be /mnt/boot/boot/vmlinuz …  Or, I suppose I could mount it that way and then do a remount (using --bind or --move) to move the mount-point… Sigh.



>> 
>> 3rd: how does a regular package force these kernel options?
>> A: you can depend on a kernel config just like you depend on any other
>> kernel config. CONFIG_KERNEL_XXX becomes CONFIG_XXX in kernel config.
>> See procd makefile for reference. However, note that any selecting the
>> package is enough to enable the config for any kernel compiled, even
>> those that do not install your package.


And having:

PKG_CONFIG_DEPENDS := CONFIG_KERNEL_SMP

unsets CONFIG_SMP, right?



>> 
>> 4th:  Is there an easy way to have the image include a 3rd partition
>> for collecting crash dumps?
>> A: your kexec package could configure the mounting. I don't know where
>> is the best place for mounting, if /etc/fstab, /etc/config/fstab or
>> mounting with a custom /etc/init.d/kexec service


On second thought, maybe this is an orthogonal issue…

Too bad fstab gets run as S40… that’s pretty late.  If the boot process is causing the crash itself, then having the hooks in place to capture the crash should be at the earliest possible…



>> 
>> 5th: what would be involved in mashing /dev/sda1 into the root unionfs?
>> A: kernel could live inside rootfs. There is even an existing menu
>> option (TARGET_ROOTFS_INCLUDE_KERNEL) for it (but not for x86). I
>> guess grub2 can read files both from squashfs and ext4. Grub just need
>> to look for the kernel there (you need to change the target partition
>> from sda1 to sda2) and you must put the kernel inside sda2 and not
>> sda1 during image build. The only drawback is that even if you change
>> the kernel (writing to overlayfs), grub would still read from pristine
>> squashfs. I don't know if this is really a problem because in
>> LEDE/OpenWRT, you normally change kernel reflashing your system and
>> not updating kernel.


That would also mean that the system kernel that grub loads would be different from the crash kernel that kexec loaded…


>> 
>> I did some code (CC era) in order to put the kernel inside rootfs. It
>> was used for a A/B upgrade strategy. grub conf was changed to boot
>> either sda2 or sda3 rootfs. sysupgade could replace only the other
>> rootfs partition or the whole system (boot+rootfs). It still misses
>> some kind of hardware watchdog (I used a human watchdog). If there is
>> interest for this particular A/B image solution (only for x86/x86_64
>> and no watchdog), I can spend some time to bring it to LEDE trunk,


Thanks, let me think about that.

-Philip


>> 
>> Regards,
>> 
>> ---
>>    Luiz Angelo Daros de Luca, Me.
>>           luizluca at gmail.com
>> 
>> _______________________________________________
>> Lede-dev mailing list
>> Lede-dev at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>