another detail wrong... see below
On Thu, Jun 22, 2023 at 10:16:14AM +1000, Ralph Ronnquist wrote:
> On Thu, Jun 22, 2023 at 10:10:06AM +1000, Ralph Ronnquist wrote:
> > On Wed, Jun 21, 2023 at 08:32:00PM +0100, Adam Sampson via Dng wrote:
> > > Didier Kryn <kryn@???> writes:
> > >
> > > >> # chroot /mnt /bin/bash
> > > >
> > > > Maybe I'm going crazy but this is absolutely impossible. You must not
> > > > only enter the new filesystem, you must also change the cpu. You need
> > > > qemu for this, certainly not a bare chroot.
> > >
> > > It's not impossible, but it does require some setup first. There's a
> > > userspace-only version of qemu that translates target-machine system
> > > calls into native system calls, and you can set up Linux's support for
> > > custom binary formats so qemu-user gets invoked automatically when you
> > > try to run a non-native executable. The emulation's not as good as
> > > qemu's full-machine emulation (in particular, it tends to have limited
> > > support for recently-added system calls), but it usually works well
> > > enough for bootstrapping.
> > >
> > > The Debian wiki has some notes on how to set it up:
> > > https://wiki.debian.org/QemuUserEmulation
> >
> > Using plain multiarch setup did indeed come into play fairly recently;
> > might have been 2017 or so when I "discovered" it. Before that one
> > needed a complete filesystem with a qemu-static setup, or, as Didier
> > suggests, a separate VM already in the target architecture.
> >
> > We, toddlers of today, use multiarch; it's two simple commands:
> >
> > # dpkg --add-architecture armhf
> > # apt-get update
>
> Sorry; it of course needs a third command, to install libraries in
> armhf as well:
>
> # apt-get upgrade
>
> Ralph.
>
> >
> > and then the (amd64) system is all setup to run armhf binaries via the
> > automatic emulation (using binfmt I believe). You do not need an armhf
> > kernel to run armhf binaries.
> >
> > Obviously those binaries are executed with respect to the host machine
> > hardware which very likely is different from the target machine
> > hardware. But it's generally good enough for both spinning up a target
> > filesystem, and for building a kernel for a target filesystem. (The
> > latter is partly made possible with how target hardware nowadays is
> > separated out with DTB declarations, which provide hardeware ABI
> > descriptions for kernel software).
> >
> > Thus, following those two commands, you may spin up a target
> > filesystem, e.g., the way I did it:
> >
> > # debootstrap --variant=minbase --no-merge-usr --arch armhf \
> > chimaera /mnt http://deb.devuan.org
should be "--no-merged-usr"
Ralph.
> >
> > That was they way I set up the two armhf build hosts I'm providing for
> > devuan package building.
> >
> > Some hardware modules I got from a near-miss Armbian version; this was
> > a year ago but afair my hosts are 805 cpus that needed something
> > special for networking.
> >
> > You might have similar success with getting a working Armbian
> > boot+filesystem for your hardware and then just replace the filesystem
> > with a Devuan debootstrapped filesystem. It's easier if you don't need
> > to compile the kernel yourself.
> >
> > Ralph.
> >
> > >
> > > --
> > > Adam Sampson <ats@???> <http://offog.org/>
> > > _______________________________________________
> > > Dng mailing list
> > > Dng@???
> > > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> > _______________________________________________
> > Dng mailing list
> > Dng@???
> > https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
> _______________________________________________
> Dng mailing list
> Dng@???
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
::
Re: [DNG] [rrq@mail.rrq.id.au: Re: …
