Skip to content

usr-linux: deploy the user space where the running root is - #47

Merged
daniel-rossier merged 2 commits into
mainfrom
fix/usr-deploy-onto-p2
Sep 25, 2026
Merged

daniel-rossier merged 2 commits into
mainfrom
fix/usr-deploy-onto-p2

Conversation

@daniel-rossier

@daniel-rossier daniel-rossier commented Sep 25, 2026 •

Copy link
Copy Markdown
Contributor

usr-linux:do_deploy now puts the user space where the running root is, in ONE place chosen by IB_RAMFS_SOURCE:

IB_RAMFS_SOURCE apps go to pulled by
"rootfs" (bsp.bbclass default, root=/dev/ram) INTO rootfs.cpio (extract, sudo rsync, re-pack) → embedded in the ITB bsp-linux:do_prepare_initrd (build); depends on rootfs-linux:do_build, after usr-linux:do_build, never touches the boot media
anything else ("initrd", pivot to p2) onto p2, on top of rootfs-linux:do_deploy (sudo rsync, check=True, verdin skipped) bsp-linux:do_deploy (deploy only, no after do_build)

Before: the apps were never on the running root with the default "rootfs" (infrabase copied them — silently failing, unprivileged cp — onto a p2 nobody mounts), and deploy.sh bsp-linux did not deploy them at all. deploy.sh usr-linux now does the right thing in both modes.

Validated with bitbake -g bsp-linux (build + deploy graphs), IB_RAMFS_SOURCE forced to "rootfs" and "initrd". Not run on real media. Same model in so3 (#337), micofe, pos_sol, pos_student and edge-m1.

`deploy.sh bsp-linux` extracted the rootfs onto p2 but never deployed
the user space: bsp-linux:do_deploy depended on rootfs-linux:do_deploy
only, so the apps under linux/usr/build/deploy reached the card only
through a separate `deploy.sh usr-linux`.

- bsp-linux:do_deploy now also depends on usr-linux:do_deploy, which
  itself runs after rootfs-linux:do_deploy: rootfs first, apps on top.
- usr-linux:do_deploy copies with sudo rsync and check=True. p2 is
  written by rootfs-linux:do_deploy with `sudo cp -a` and is root-owned,
  so the unprivileged os.system("cp -r") was denied and its exit code
  ignored: the deploy "succeeded" with no apps on the card. It went
  unnoticed because nothing in a full deploy called this task.
- verdin-imx8mp is skipped like in rootfs-linux:do_deploy (Tezi/HTTP
  storage, no p2 to mount).
- `after do_build` dropped: its stated reason (do_prepare_initrd pulling
  this task early) no longer holds since do_prepare_initrd depends on
  rootfs-linux:do_build. A deploy now only copies what the build
  produced and fails clearly when it is missing, instead of rebuilding
  usr (and linux through do_unpack) on every deploy.
…rwise

Copying the user space onto p2 is right only when p2 is the running
root. With IB_RAMFS_SOURCE = "rootfs" (the bsp.bbclass default) the
kernel runs from the rootfs.cpio embedded in the ITB (root=/dev/ram), so
apps copied onto p2 were never seen by the running system, and the
initrd carried none.

usr-linux:do_deploy now puts the apps in ONE place, chosen by
IB_RAMFS_SOURCE:

- "rootfs": baked INTO rootfs.cpio (extract, sudo rsync, re-pack).
  bsp-linux:do_prepare_initrd pulls it into the build, before gzipping
  the cpio into the ITB; it then depends on rootfs-linux:do_build (never
  on the boot media) and runs after usr-linux:do_build.
- anything else ("initrd", pivoting to p2): copied onto p2 after
  rootfs-linux:do_deploy; bsp-linux:do_deploy pulls it, deploy-only, no
  `after do_build`.

`deploy.sh usr-linux` therefore does the right thing in both modes.
Validated with `bitbake -g bsp-linux` (build and deploy graphs) with
IB_RAMFS_SOURCE forced to "rootfs" and to "initrd".
@daniel-rossier daniel-rossier changed the title usr-linux: deploy the user space onto p2 as part of bsp-linux deploy usr-linux: deploy the user space where the running root is Sep 25, 2026
@daniel-rossier
daniel-rossier merged commit 1312b4f into main Sep 25, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant