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

Mon Jun 17 02:57:02 PDT 2019

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