[Solved] persisting qemu binpkg for qemu chroot

[brendlefly62]

For a variety of arm and arm64 SBCs, I have been using the techniques described at the https://wiki.gentoo.org/wiki/Crossdev and https://wiki.gentoo.org/wiki/Embedded_Handbook articles. My projects use both "crossbuild" and "qemu-chroot" phases. The crossbuild phase is often much faster than work can be done natively on the TARGET SBCs, and the qemu-chroot phase is necessary to build what can only be compiled "natively"

I now have a "stockpile" of complete images that have since been deployed to real platforms, and I can easily "spin up" one of these images, and update it as described above more efficiently that doing the update on a disadvantaged platform ... but I'd like advice on one challenge I have run into --

Background: the qemu chroot paradigm involves placing a build-host binary (e.g. qemu-system-arm) inside the TARGET's root file system. Example for a raspberry pi b system image on an x86_64 development workstation:

Code: Select all

   $ file /usr/armv6j-unknown-linux-gnueabihf/usr/bin/qemu-system-arm
 
   /usr/armv6j-unknown-linux-gnueabihf/usr/bin/qemu-system-arm: \
      ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV), \
      dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for \
      GNU/Linux 3.2.0, stripped

When this image is mounted and I have "qemu-chrooted" into it, I would like to run a basic update sequence involving emerge -uavDN @world; dispatch-conf; emerge -av --depclean; revdep-rebuild; and so on.

Challenge: (1) the emerge --depclean will remove the app-emulation/qemu package [it is only needed in the target to enable the qemu-chroot]. I could prevent its removal by adding it to the TARGET's world set with emerge --noreplace, but then (2) a subsequent emerge world update will try to rebuild it as a TARGET_ARCH (arm) binary instead of the x86_64 binary that is needed to enable the qemu-chroot, and it would also "pull in" all of that package's dependencies...

Is there a way to protect this "foreign-arch" package (as just such) in the TARGET root_fs w/o confusing the TARGET system as to its purpose? (i.e. can I prevent it from being removed by this kind of update process?

How have you or others dealt with this in embedded/SBC projects?

[pingtoo]

I think you are looking https://wiki.gentoo.org/wiki//etc/porta ... e.provided
I believe once you place package.provided in your qemu-chrooted environment you don't need to have it in world file.

[pingtoo]

I am curious why app-emulation/qemu in the target? why not just place a statically linked binary qemu-system-arm in the targets /usr/bin and be done with it.

[brendlefly62]

Thanks for the assistance, Pingtoo -

I am curious why app-emulation/qemu in the target? why not just place a statically linked binary qemu-system-arm in the targets /usr/bin and be done with it.

I don't "include" it in the target, I just observe that once I am chrooted into the target and run an update cycle, depclean will want to remove it. I have assumed that depclean has identified it as installed and not needed...

as further background --

When I started working on this a few years ago, I originally followed the process described at https://wiki.gentoo.org/wiki/Cross_build_environment (an article that has since been nominated for deletion). That involved these steps --
Install QEMU on the host:

Code: Select all

emerge --ask app-emulation/qemu

Prepare QEMU for the target (in this case for the ARM architecture):

Code: Select all

QEMU_USER_TARGETS="arm" QEMU_SOFTMMU_TARGETS="arm" USE="static-user static-libs" emerge --ask --buildpkg --oneshot qemu

Install QEMU to the build environment:

Code: Select all

cd /usr/<TARGET> && ROOT=$PWD/ emerge --ask --usepkgonly --oneshot --nodeps qemu

A first test:

Code: Select all

/etc/init.d/qemu-binfmt start && cd /usr/<TARGET> && chroot . /bin/bash --login

Note: this way, "emerge" installed the needed qemu binary on the target, and a normal "chroot /mountpoint /bin/bash --login" gets you in ...

I have noted that my current *primary reference (https://wiki.gentoo.org/wiki/Embedded_H ... ser_chroot) does things a little different --
(After installing qemu on the host)
To use an aarch64 chroot environment at /mnt/gentoo-aarch64:

Code: Select all

cp /usr/bin/qemu-aarch64 /mnt/gentoo-aarch64/usr/bin

Chrooting Once the environment has been prepared, sys-apps/arch-chroot can be used:

Code: Select all

arch-chroot /mnt/gentoo-aarch64

Note: I have not yet changed my practice to adopt this precisely different method because - well - the "old" way worked...

Can I gather correctly from your question -- you are advising me that I would not *have the challenge cited in my OP if I were to do so?? (except, to be consistent with my example, I would copy /usr/bin/qemu-arm to the target)

Related question: will it also be important to "get with the program" and use arch-chroot as well?

[pingtoo]

brendlefly62,

When you build qemu with USE flag "static-user" you got "qemu-arm" (The user program, not qemu*-system which is the VM emulator) and you can verify that it is statically linked by ldd /usr/bin/qemu-arm. which should tell you it is not a dynamic linked program.

And yes if you did cp /usr/bin/qemu-arm to <TARGET-chroot>/usr/bin/qemu-arm and your that /proc/sys/fs/binfmt_misc/register have entry for arm and a file with something you can read in /proc/sys/binfmt_misc/qemu-arm you are good to go. (I think this is the qemu-binfmt service (OpenRC) or systemd-binfmt (systemd) do.)

And with the copy static linked binary method, you don't need to worry about dep-clean will remove it and you don't need package.provided to fool emerge.

[brendlefly62]

Thank again, Pingtoo. Confirmed; marking [solved].