Re: [LEDE-DEV] Supporting crashdumps w/ kexec
Inline… > On Mar 9, 2017, at 12:35 PM, monster_phi...@redfish-solutions.com wrote: > > >> On Mar 8, 2017, at 8:32 PM, Luiz Angelo Daros de Luca >> 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. >> luizl...@gmail.com >> >> ___ >> Lede-dev mailing list >> Lede-dev@lists.infradead.org >> http://lists.infradead.org/mailman/listinfo/lede-dev > ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Supporting crashdumps w/ kexec
> On Mar 8, 2017, at 8:32 PM, Luiz Angelo Daros de Luca > 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) > > 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. > > 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. > > 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 > > 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. > > 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, > > Regards, > > --- > Luiz Angelo Daros de Luca, Me. >luizl...@gmail.com > > ___ > Lede-dev mailing list > Lede-dev@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/lede-dev ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Supporting crashdumps w/ kexec
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) 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. 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. 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 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. 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, Regards, --- Luiz Angelo Daros de Luca, Me. luizl...@gmail.com ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Supporting crashdumps w/ kexec
> On Mar 8, 2017, at 10:23 AM, David Woodhouse wrote: > > On Wed, 2017-03-08 at 10:20 -0700, Philip Prindeville wrote: >> >> Then… grub reads the raw file system? > > Well, grub has to load the kernel before the kernel is running…. So, what would be involved in mashing /dev/sda1 into the root unionfs? I’m looking at /lib/functions/preinit.sh trying to understand the delta to get this to happen, but it’s a little voodoo to me. I’m thinking that the ramoverlay stuff in preinit.sh along with /lib/preinit/20_check_iso is similar to what we want to do. Crispin? Daniel? Felix? Florian? Can you provide some guidance here, please? -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Supporting crashdumps w/ kexec
On Wed, 2017-03-08 at 10:20 -0700, Philip Prindeville wrote: > > Then… grub reads the raw file system? Well, grub has to load the kernel before the kernel is running smime.p7s Description: S/MIME cryptographic signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Supporting crashdumps w/ kexec
> On Mar 8, 2017, at 1:12 AM, David Woodhouse wrote: > > On Tue, 2017-03-07 at 17:40 -0700, Philip Prindeville wrote: >> >> First, obviously, is that kexec needs access to the boot partition to >> reuse the kernel (since most of our architectures support relocatable >> images, there’s no reason that the system kernel and the crash dump >> kernel can’t be one in the same). 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? > > Hm, /boot doesn't ever get mounted at all, does it? Then… grub reads the raw file system? Hmm… Okay, that would explain why I couldn’t find references to /boot in preinit, etc. What do I do to make /boot be mounted then? Thanks, -Philip ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
Re: [LEDE-DEV] Supporting crashdumps w/ kexec
On Tue, 2017-03-07 at 17:40 -0700, Philip Prindeville wrote: > > First, obviously, is that kexec needs access to the boot partition to > reuse the kernel (since most of our architectures support relocatable > images, there’s no reason that the system kernel and the crash dump > kernel can’t be one in the same). 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? Hm, /boot doesn't ever get mounted at all, does it? smime.p7s Description: S/MIME cryptographic signature ___ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
