Curious. I boot tested my patch on multiple boards and I've built and booted
numerous images on my rock-pi-4b and rock64 boards in the last day or so since
I applied the patch. I'll try some "clean" builds and see if that makes a
difference. I don't doubt your report (especially since Khem confirmed it),
I'd just like to know for myself what's different.

That is really strange. As soon as there are those /dev/sda* entries in my fstab
my rock-pi-4c doesn't boot up anymore. As soon as i comment them out or delete them,
everything is working again.

I wonder if just applying your 2nd patch would be enough (i.e. the one that
removes the /dev/sda* lines from /etc/fstab)? It's odd that the first 6
entries in the wic file would need UUIDs since it's the SoC's ROM firmware
that uses them, and I'm pretty sure the Rockchip firmware isn't using UUIDs
(my guess is it's just blindly grabbing whatever it finds at specific
offsets). The things stored in those partitions are u-boot related bits (atf,
spl, the u-boot binary itself) so by the time Linux starts, those things are
already "behind" us. I can't see how adding UUIDs to the partitions holding
u-boot would affect how the kernel finds the root partition (?).

Applying only the second patch should be enough to hide the problem, but as soon as
one decides to disable WIC_CREATE_EXTRA_ARGS for example because he/she wants /boot to be
mounted automatically, those non working /dev/sda* entries will be written into fstab again.
With the first patch they are included like this and are mountable via fstab:


UUID=0C48-9342	loader1	vfat	defaults	0	0
UUID=C4D3-D17A	reserved1	vfat	defaults	0	0
UUID=8FBE-2551	reserved2	vfat	defaults	0	0
UUID=35FA-8BBB	loader2	vfat	defaults	0	0
UUID=CFF3-5D80	atf	vfat	defaults	0	0
UUID=832C-48C4	/boot	vfat	defaults	0	0


u-boot is able to find its partitons even if '--use-uuid' is set. As you mentioned u-boot doesn't
know about uuid but it seems to be able to find its partitions nevertheless. But if '--use-uuid'
is not set, wic writes /dev/sda* instead of the correct  UUID values to fstab. So its not u-boot that
needs uuid to be set but fstab.
Of course it would be nice, if wic didn't try to add the u-boot partitions to fstab at all.
I guess nobody ever needs to have them mounted into userspace ( except possibly /boot).

Are you using poky or a distro other than "nodistro"? Perhaps other
layers/distros are affecting the build?

Thats not unlikely. I have a long layer-list in bblayers.conf to build my image:

  /home/flk/build/poky/meta \
  /home/flk/build/poky/meta-poky \
  /home/flk/build/poky/meta-yocto-bsp \
  /home/flk/build/poky/meta-rockchip \
  /home/flk/build/poky/meta-rockchip-extras \
  /home/flk/build/poky/meta-wayland \
  /home/flk/build/poky/meta-retro \
  /home/flk/build/poky/meta-retro-wayland \
  /home/flk/build/poky/meta-rauc \
  /home/flk/build/poky/meta-openembedded/meta-oe \
  /home/flk/build/poky/meta-openembedded/meta-multimedia \
  /home/flk/build/poky/meta-openembedded/meta-networking \
  /home/flk/build/poky/meta-openembedded/meta-xfce \
  /home/flk/build/poky/meta-openembedded/meta-gnome \
  /home/flk/build/poky/meta-openembedded/meta-python \
  /home/flk/build/poky/meta-openembedded/meta-filesystems \
  /home/flk/build/poky/meta-arm/meta-arm \
  /home/flk/build/poky/meta-arm/meta-arm-toolchain \
  /home/flk/build/poky/meta-kodi \
  /home/flk/build/poky/meta-browser/meta-chromium \
  /home/flk/build/poky/meta-browser/meta-firefox \
  /home/flk/build/poky/meta-clang \

best regards,

  Markus