> 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.
But this is only me with my hints.
Zoran
_______
On Mon, Jun 17, 2019 at 11:59 AM Moritz Porst <moritz.po...@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.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).
>
> 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@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
