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

Mon Jun 17 05:13:50 PDT 2019

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190617/41ba6b03/attachment.html>