An image updater usually needs two partitions, one for the rootfs and another one for maintenance. In order to do the update the target needs to boot into the maintenance partition and overwrite the rootfs partition and then boot in the new rootfs. There is need a way to provide this swap in the bootloader and also the capability to verify if the update failed (the new rootfs doesn't boot)
In order to do this there is need to add two features to the current grub recipe: loadenv and test. These two features are needed to implement scripts at boot time and to modify the grubenv (this is needed to save states between boots)
Created attachment 4385 [details] Patch version 0.1 Use these in your local.conf file. MACHINE ?= "qemux86" MACHINE_FEATURES += "pcbios efi" IMAGE_FSTYPES += "wic" WKS_FILE = "directdisk-multi-rootfs.wks.in" EFI_PROVIDER = "grub-efi" IMAGE_INSTALL_append = " \ grub \ grub-efi \ " IMAGE_INSTALL_append = " grub-multibootconf-cntr-rst " EXTRA_IMAGEDEPENDS += "ovmf" PREFERRED_RPROVIDER_virtual/grub-bootconf = "grub-multibootconf" Then: $ bitbake core-image-minimal $ runqemu wic kvm ovmf
Hi, I've have a patch which is ready for testing and evaluation. In order to build the qemu wic image you need to apply the patch (Patch version 0.1) and then add these to the end of your local.conf file. MACHINE ?= "qemux86" MACHINE_FEATURES += "pcbios efi" IMAGE_FSTYPES += "wic" WKS_FILE = "directdisk-multi-rootfs.wks.in" EFI_PROVIDER = "grub-efi" IMAGE_INSTALL_append = " \ grub \ grub-efi \ " IMAGE_INSTALL_append = " grub-multibootconf-cntr-rst " EXTRA_IMAGEDEPENDS += "ovmf" PREFERRED_RPROVIDER_virtual/grub-bootconf = "grub-multibootconf" Then build the core-image-minimal image (that's the only one I've tried). If the build ends without errors then load the image with: $ runqemu wic kvm ovmf You can debug the grub bootloader script by setting the 'GRUB_DEBUG = 1' flag in poky/meta/recipes-bsp/grub/grub-multibootconf_1.00.bb. Anyway, I've tried to document most of the stuff I've done, if you need any more details then poke me. Regards, Dimitris
Forgot to mention that in the local.conf I've added this recipe IMAGE_INSTALL_append = " grub-multibootconf-cntr-rst " This is a service that resets the boot counter when the OS loads. This is meant only for testing, therefore if you remove that then the boot counter will increment until reaches the max limit and then Grub will fallback to the rescue partition. Therefore, if you want to test that it works properly you need to either disable the init/service or remove it from the IMAGE_INSTALL. Also the counter timeout value is set in `poky/meta/recipes-bsp/grub/grub-multibootconf_1.00.bb` with the GRUB_BOOT_TRIES variable. Regards, Dimitris
Hi, Sorry this has fallen through the cracks, it looks like really good work! Did you post this patch to the mailing list? I think that is why it hasn't been noticed, I couldn't immediately spot it in the list archives. Normally the final step in the development process is to send the patch to the list for peer review and testing. Some quick comments from reading through the patches: You re-purpose directdisk-multi-rootfs.wks, I'm not sure if other code would be relying on that wks file. Is it safe to replace it or should we create a new wks file for the purposes of this recipe? There also aren't any tests here for this code. It would be really great if there was something added to the code in meta/lib/oeqa/selftest/cases/wic.py or somewhere else, wherever makes sense which added a test case for this code. Once agin, I do think this kind of functionality is important and its great to see this! Lets see what we can do to get this reviewed/merged! Cheers, Richard
Hi Richard, thanks for the feedback! I've sent the patches in the yocto mail list, but I wouldn't be surprised if I've done something wrong in the process :/ > You re-purpose directdisk-multi-rootfs.wks, I'm not sure if other code would > be relying on that wks file. Is it safe to replace it or should we create a > new wks file for the purposes of this recipe? You're right, I don't even understand why I did this. That was silly. I guess I've based on it and forgot to undo the changes and create a new wks.in file. > There also aren't any tests here for this code. It would be really great if > there was something added to the code in meta/lib/oeqa/selftest/cases/wic.py > or somewhere else, wherever makes sense which added a test case for this > code. I wasn't aware of this test feature. I'll have a look, but in the meantime what this test should do? Cheers, Dimitris
(In reply to comment #6) > Hi Richard, > > thanks for the feedback! > I've sent the patches in the yocto mail list, but I wouldn't be surprised if > I've done something wrong in the process :/ The patches would need to go to the openembedded-core list. I'm guessing that is why they've been overlooked :(. > > You re-purpose directdisk-multi-rootfs.wks, I'm not sure if other code would > > be relying on that wks file. Is it safe to replace it or should we create a > > new wks file for the purposes of this recipe? > > You're right, I don't even understand why I did this. That was silly. I > guess I've based on it and forgot to undo the changes and create a new > wks.in file. Hopefully easily fixed! > > There also aren't any tests here for this code. It would be really great if > > there was something added to the code in meta/lib/oeqa/selftest/cases/wic.py > > or somewhere else, wherever makes sense which added a test case for this > > code. > > I wasn't aware of this test feature. I'll have a look, but in the meantime > what this test should do? Showing the configuration needed to build it and testing that it builds is the first step. Second step would be to test it boots. Third step would be to put it through some failed boot/recovery type scenarios using both partitions. Each step gets harder to implement but is also more rewarding. I'd be happy to see any testing to be honest!
Hi Richard, I've fixed the wks file. I've also done all the testing for the different cases and it seems that it works ok (I've tried only with qemu). All needed steps are documented also in the comments here. The problem is that I couldn't see how to use any of the test cases to implement this (the wic tests are definitely don't help). So, I probably need to write a new test script for that. This wouldn't be much of a problem I guess, just a bit time consuming, though. I'll try to make up something. Regards, Dimitris
Any update Dimitris? Unassigning since it's been idle for a while but feel free to take it back if you're going to work on the enhancement. Thanks.
Hi Randy, at that time this solution was working, but there was a test missing which I wasn't able to create. I think it can be remain unassigned until someone can take over and write a test.
Still need a test.
Hi Dimistris/Randy I am a new comer and I would like to test the senarios. Can you breif me about the senarios which need to be test ? Thanks Sanjay :)
Still need a test case.