Le 21/06/2023 à 14:27, Ralph Ronnquist a écrit :
> (I messed up and sent a direct reply :()
>
> ----- Forwarded message from Ralph Ronnquist <rrq@???> -----
>
> Date: Wed, 21 Jun 2023 22:25:54 +1000
> From: Ralph Ronnquist <rrq@???>
> To: Didier Kryn <kryn@???>
> Subject: Re: [DNG] Devuan armhf / armel for my Samsung / Google Chromebook
> model XE303C12 "Snow" ?
> Message-ID: <ZJLsUNhj9sZ4GlT2@localhost>
>
> On Wed, Jun 21, 2023 at 02:09:53PM +0200, Didier Kryn wrote:
>> Le 21/06/2023 à 12:13, Ralph Ronnquist a écrit :
>>> It also works fine using "multiarch" (in which case the architecture
>>> transition is seamless). I.e., set up your system to have armhf
>>> (and/or armel) as additional "foreign" architecture(s) and then a
>>> plain debootstrap will be fine.
>> multiarch makes sense for i386 and x86-64 (amd64) and for powerpc 32 and
>> 64, because the cpus are able to execute instructions of both arches. I
>> would be extermely surprised if it worked for amd64 and armhf.
> Yes it did surprise me too :) Works fine for my amd6 laptop; a bit
> slow, but that's no different from a "proper" qemu VM. (The multiarch
> approach is basically the same as running a foreign qemu-static within
> a foreign filesystem). But "seamless"; doesn;t need chroot.
>
> Ralph.
>
>
Yes, an amd64 can run i386 instructions (by design) and a ppc64 can
run ppc32 instructions, also by design. I dunno if there are multiarch
capibilities within arm architectures, but you can certainly not mix a
random combination of architectures, like amd64 and armhf. Hence the
need for qemu.
-- Didier
::
Re: [DNG] [rrq@mail.rrq.id.au: Re: …
