mpc85xx/p1010 buildboot issue

[Petr Štetiar]

Paweł Dembicki <paweldembicki at gmail.com> [2024-08-23 12:15:03]:

 [ adding Christian and Luiz to the CC: loop ]

Hi,

> Buildbot had some issue with mpc85xx/p1010 subtarget:
> https://buildbot.openwrt.org/images/#/builders/231
> 
> It looks like only `osuosl-vm5-dock-02` can build this subtarget.
> Could someone look at this issue?

seems to be some race condition in the build system being exposed on a boxes with a specific I/O performance?

  [ ! -d "/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da" ] || rm -rf /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  /builder/shared-workdir/build/staging_dir/host/bin/mksquashfs4 /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/target-dir-68b329da /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/root.squashfs+pkg=68b329da -nopad -noappend -root-owned -comp xz -Xpreset 9 -Xe -Xlc 0 -Xlp 2 -Xpb 2 -Xbcj powerpc -b 256k -p '/dev d 755 0 0' -p '/dev/console c 600 0 0 5 1' -no-xattrs
  mkdir /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  [ ! -d "/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da" ] || rm -rf /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  Parallel mksquashfs: Using 6 processors
  Creating 4.0 filesystem on /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/root.squashfs+pkg=68b329da, block size 262144.
  
  Pseudo file "dev" exists in source filesystem "/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/target-dir-68b329da/dev".
  Ignoring, exclude it (-e/-ef) to override.
  [|                                                               ]   0/818   0%cp -fpR /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47/.config /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  mkdir /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da
  rm -f /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.prev
  mkdir: cannot create directory '/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da': File exists
  make[4]: *** [Makefile:24: /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/simpleImage.ws-ap3715i-initramfs.68b329da] Error 1
  make[4]: *** Waiting for unfinished jobs....
  mv /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.old
  mv: failed to access '/builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/linux-6.6.47.68b329da/.config.old': Not a directory
  make[4]: *** [Makefile:27: /builder/shared-workdir/build/build_dir/target-powerpc_8548_musl/linux-mpc85xx_p1010/simpleImage.br200-wp-initramfs.68b329da] Error 1


which leads me to the commit 97fd059e7e6a ("image: respect TARGET_PER_DEVICE_ROOTFS for initramfs") and I would be tempted to fix it via:

  --- a/include/kernel-defaults.mk
  +++ b/include/kernel-defaults.mk
  @@ -158,7 +158,7 @@ endef
 
  define Kernel/PrepareConfigPerRootfs
  	[ ! -d "$(1)" ] || rm -rf $(1)
 -	mkdir $(1)
 +	mkdir -p $(1)
  
  	$(CP) $(LINUX_DIR)/.config $(1)
  endef

but reading the reasoning in the commit:

  "To handle this, we prepare a config for each rootfs and we generate the
   images under lock to prevent problem with parallel execution."

it might not be actually desired, that devices are racing between each other
and doing that "rm -rf $(1)" ? So maybe some additional locking or even better
per device/rootfs directory would make more sense?


Cheers,

Petr