**** BEGIN LOGGING AT Sun Nov 08 03:00:00 2020 Nov 08 18:31:58 so I got the a/b copy swupdate going on the odroid h2+, but it was quite a fight to untagle the grub stuff; basically we have some duplicated functionality and those pieces work past each other Nov 08 18:32:18 there is the wic plugin that writes grub.cfg based on whats set in the wks Nov 08 18:32:42 and then there is the grub-efi-cfg.bbclass which kind of does the same but on the rootfs Nov 08 18:33:00 and the resulting configs don't even match (not that it makes sense to have both anyway) Nov 08 18:33:53 I worked around by not using the wic plugin and by hacknig the bbclass and then telling wic to use contents of my /boot/efi directory to populate a standalone partition; also had to add grubenv generation Nov 08 18:34:19 I am not sure how to go about it cleanly in the sense of submitting something mergable Nov 08 18:53:53 Jin^eLD: did you try using u-boot Nov 08 18:58:37 khem: on the H2+ ? I don't know if that is even possible with an UEFI BIOS? Nov 08 18:59:06 swupdate does support grub env settings though, so swupdate as such is not the issue Nov 08 18:59:54 I started with the odroid-H2 setup from meta-odroid (which uses grub) and went from there Nov 08 19:00:08 ok Nov 08 19:00:35 and in this default setup you have your grub partition with configs created by wic, and then you have a dummy grub config in the rootfs which nobody is using but which is there anyway Nov 08 19:01:14 that's what I meant by wic efi plugin and grub-efi-cfg bbclass working in parallel somehow without being aligned Nov 08 19:01:59 I went with the bbclass in the end because it was easier to extend and I needed to add grub environment support so that swupdate could switch the partition numbers for the next boot after an a/b update Nov 08 19:02:31 it works but is somewhat messy at the moment Nov 08 19:03:17 also grub-efi insisted on naming the bootloader grub-efi-bootsomething and the BIOS did not like the grub-efi prefix at all, so I had to hack that away as well Nov 08 19:12:15 I guess if I wanted to take a step by step approach I'd probably have to first find out why adding the grub prefix was so important that there is even an anonymous python function that is hacking it in; and then cleaning up the bbclass would be next; but I am not sure how it could be aligned with wic, because it basically has a duplicate implementation that works in parallel to Yocto Nov 08 19:12:46 how do you create partitions ? do you let swupdate do it ? Nov 08 19:13:00 or are they fixed with wic image ( factory install ) Nov 08 19:13:39 you need some flashable image to start with, the swu is actually just (one or more) rootfs and you tell it where to go, so you need a booted and running system first Nov 08 19:13:55 my approach usually is to have a wic image with a minimum installer rootfs Nov 08 19:14:46 the installer creates further partitions when started; I know with wic.bmap you could till flash "empty" images quickly, but it does not support flashing from compressed wic files, so you have to unpack it first Nov 08 19:14:55 and its just not practical to ship a 16gb wic file full of zeroes... Nov 08 19:15:25 so I have a tiny wic that can be flashed and boots, then it creates rootA/B whatever is needed, fetches the .swu and flashes the actual root, reboots Nov 08 19:15:47 s/till/still/g Nov 08 19:17:34 another benefit of that approach is, that direct flashing/programming is always expensive in the factory so it has to be as short as possible, and then fetching a bigger image from the net/LAN in a later step is cheap Nov 08 19:47:34 that depends if the device is connected over network or are you also using some USB mechanism to install initially Nov 08 20:00:41 depends; the guys I am helping out now are using stock firmware, no own production, so they have some usb setup for initial flashing (which also takes longer if they'd flash the whole image first), swu is as big as the data, then resize2fs expands it after flashing Nov 08 20:02:11 for places I've been working in the past - they were manufacturing devices in some factory, so there the flash has been programmed directly via a programmer which apparently is expensive (measured in time), then once the device got out of that production line it was cheap to have someone hook it up to flash the rest via a download **** ENDING LOGGING AT Mon Nov 09 03:02:03 2020