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
