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.stojsavlje...@gmail.com>
>>> *An:* "Moritz Porst" <moritz.po...@gmx.de>
>>> *Cc:* "Yocto Project" <yocto@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.po...@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).
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
> 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.
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@yoctoproject.org
>>>> https://lists.yoctoproject.org/listinfo/yocto
>
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
