[yocto] [meta-swupdate] failed update leads to kernel panic

Mon Jun 17 05:34:06 PDT 2019

> I see the bundle_initramfs task being executed if I do any
> changes. The boot process works without swupdate in the
> image. If anything was wrong with the initramfs the whole
> system shouldn't be able to boot properly. I don't get what
> you suggest me to try.

It is just Divide and Conquer strategy. If you have normal system
working with/transitioning via initramfs, I would assume that there
should be nothing wrong with your initramfs, other than if you cut
power while update is upgrading kernel, and upon (part of kernel
upgrade) it makes/builds new initramfs (it could be very lengthy
process).

My best guess is to exclude from swupdate layer ONLY kernel upgrade,
and see if this helps, and brings you to some better point where you
can understand the problem. Again, Divide and Conquer strategy.

Zoran
_______

On Mon, Jun 17, 2019 at 2:13 PM Moritz Porst <moritz.porst at gmx.de> wrote:
>
> Hi Zoran
>
> On 17.06.19 12:55, Zoran Stojsavljevic wrote:
>
> I have a feeling that I misunderstand something about the ramdisk.
> To my understanding this is the microcode.cpio file which is invoked
> lastly in the grub entry.
>
> Being you, I would for the starters exclude swupdate layer and see if
> everything works without swupdate: does normally work with initramfs
> (from grub). Maybe it works already.
>
> I see the bundle_initramfs task being executed if I do any changes. The boot process works without swupdate in the image. If anything was wrong with the initramfs the whole system shouldn't be able to boot properly. I don't get what you suggest me to try.
>
> Best regards
>
> Moritz
>
> But this is only me with my hints.
>
> Zoran
> _______
>
> On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst <moritz.porst at gmx.de> wrote:
>
> Hi Stefano
>
> On 17.06.19 09:19, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 17/06/19 08:23, Moritz Porst wrote:
>
> Hello Stefano,
> Thanks very much for your answer
>
> On 14.06.19 14:14, Stefano Babic wrote:
>
> Hi Moritz,
>
> On 14/06/19 12:19, Moritz Porst wrote:
>
> (Sorry, the answer should go to everyone)
> Thanks for your response, unfortunately it didn't work out for me.
> Because I am not 100% sure whether I did the correct thing I describe it:
> In my layer I went to recipes-kernel/kernel/files, here I added a file
> defconfig which I filled with the content of your config-initramfs
> my linux-yocto_%.bbappend, residing one level lower (kernel), got this
> file added so it reads (in its entirety):
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
> SRC_URI += "file://0001-sdcard-power-management-off.patch"
> SRC_URI += "file://defconfig"
>
> However I *also* have a file called defconfig in meta-swupdate which is
> basically the swupdate config that comes from menuconfig. I let this
> untouched but since this is not the kernel defconfig I guess you didn't
> mean this file ?
>
> Additionally I can't mount the rootfs with the failed boot so I cannot
> access the dmesg log file. Any advice here ?
>
> Best regards
> Moritz
>
>
>
> *Gesendet:* Freitag, 14. Juni 2019 um 11:00 Uhr
> *Von:* "Zoran Stojsavljevic" <zoran.stojsavljevic at gmail.com>
> *An:* "Moritz Porst" <Moritz.Porst at gmx.de>
> *Cc:* "Yocto Project" <yocto at yoctoproject.org>
> *Betreff:* Re: [yocto] [meta-swupdate] failed update leads to kernel panic
>
> However if I abort the update while running (i.e. simulating a power cut)
> and then reboot I end up in a kernel panic: "Unable to mount rootfs on
> unknown block". My understanding is that I should at least end up in a
> busybox or that the update is retried, but this does not happen.
>
> You missed to attach failed dmesg while the system booted and aborted.
> Nevertheless, I expect problem with your defconfig, which does NOT
> have options set for initramfs. These ones:
> https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/custom/config-initramfs
>
> Please, could you add these one to your current .config, this might
> very well solve your problem.
>
> Best Regards,
> Zoran
> _______
>
> On Fri, Jun 14, 2019 at 10:15 AM Moritz Porst <Moritz.Porst at gmx.de> wrote:
>
> Hello,
>
> I am currently having trouble to get swupdate working properly.
> My problem:
> I can execute swupdate -i normally and if the update fits I have no
>
> problem. However if I abort the update while running (i.e. simulating a
> power cut) and then reboot I end up in a kernel panic: "Unable to mount
> rootfs on unknown block". My understanding is that I should at least end
> up in a busybox or that the update is retried, but this does not happen.
>
> I receive 1 error when updating which does not stop the update: "Could
>
> not find MTD".
>
> My configuration:
> I have a single rootfs and a separate boot partition. I build the
>
> initramfs using:
>
> You have a *single* rootfs, you stop an upgrade (resulting of course in
> a corrupted rootfs or worse), and you wonder that kernel cannot mount
> it....your update concept is broken.
>
> Well conceptually I want to go through the bootloader, I just fail to
> understand how I tell swupdate to do this.
>
> You *must* check the bootloader marker in U-Boot (default is the
> "recovery_status" variable) and you *mus*t start again the updater (the
> ramdisk) until the marker (it is a transaction flag) is set. It is
> erased by SWUpdate only after a successful update. You are now starting
> your board with a half-completed update.
>
> So I configured swupdate in menuconfig to work with grub which I set in
> my machine as "EFI_PROVIDER". Doesn't this single rootfs update strategy
> work with grub ?
>
> Yes, but you have to set / configure yourself how Grub start, that is a
> suitable grub.cfg where variables in grubenv are evalutated (do not
> forget load_env in grub.cfg).
>
> Ok I was not aware about this. my grub.cfg now reads:
> entry {
> load_env
> linux ./bzImage [options...]
> initrd microcode.cpio
> }
>
> The interface between SWUpdate and Grub is grubenv - SWUpdate just sets
> variables, but it is duty of bootloader to evaluated them.
>
> (I prefer to stick to EFI because partitioning of
> images works out of the box with .wic images)
> When you say "you must start again the updater", that's where I'm lost.
> From the documentation I understand that I initiate an update using
> "swupdate -i abc.swu" but this just runs the update without setting any
> flag for the bootloader.
>
> SWUpdate sets
>
> I have an update that is actually too large for the rootfs partition to produce an update failure. SWUpdate then sets recovery_status=failed. On boot I end up in a kernel panic
> If I power off before the update finishes I get no recovery_status in grubenv.
> Manually adding recovery_status=in_progress also does not work (of course maintaining the 1024 file size). "Does not work" means I end up in a kernel panic.
>
>
> One more thing: swupdate complains that there is no grubenv file.
>
> Then it does not work, you have to fix it...
>
> I
> defined a path in the config file and create this file using
> "grub-editenv /path/as/in/config create".
>
> Grubenv is just a simple 1KB file, you can dump it.
>
> swupdate does not give an
> error after I have done this.
>
> If the interface to bootloader (for grub, this means grubenv) is
> specified and correct, SWUpdate will set the variable "recovery_status"
> as transaction flag. You have to evaluate it in grub.cfg and start the
> ramdisk again if the variable is set.
>
> This confuses me. The only way I see of making swupdate set "recovery_status" is to invoke swupdate -i updatefile.swu. However this immediately invokes the update, no chance for me to intercept or "start the ramdisk again".
>
> I have a feeling that I misunderstand something about the ramdisk. To my understanding this is the microcode.cpio file which is invoked lastly in the grub entry. It then should execute the swupdate init scripts I guess ? They again should be able to understand the recovery_status variable and interpret it.
> Is this correct or am I entirely wrong about it ? Sorry for the trouble but I feel a bit lost here.
>
> Best regards
> Moritz
>
> Best regards,
> Stefano Babic
>
> Best regards,
> Stefano Babic
>
> Best regards
> Moritz
>
> ---
> IMAGE_INSTALL = "base-files \
> base-passwd \
> swupdate \
> busybox \
> libconfig \
> util-linux-sfdisk \
> mtd-utils \
> mtd-utils-ubifs \
> ${@bb.utils.contains('SWUPDATE_INIT', 'tiny',
>
> 'virtual/initscripts-swupdate', 'initscripts sysvinit', d)} \
>
> "
> ---
> This is taken from swupdate-image. I include the same packages (via
>
> _append) in my base image, is this necessary ?
>
> I bundle the initramfs with my image using INITRAMFS_IMAGE_BUNDLE = "1"
>
> Can you see a mistake I made ?
>
> Best regards
> Moritz
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto