Hi NoisyCoil,
> Apple Silicon machines do not need to be patched to boot a different OS.
> They need a bootloader to provide UEFI. RPis' boot partitions similarly
Sorry, imprecise / vague wording: UEFI bootloader on mac's m1/m2 need
"some" user action on the machine. An UEFI bootloader isn't present with
an apple m1/2 out of the box and must be placed on a non-removable device.
> On the other hand, linux on Apple Silicon only uses ordinary arm64
I agree, the current state isn't cool.
The Debian raspi project doesn't support the RPi5 yet. I could build an
experimental rpi5 boot image with trixie (bcm 2712 kernel and dtb's)
that failed during the boot process (didn't investigated that further).
Ubuntu LTS 24 doesn't provide an vagrant arm64 apt package. It might
been installed manually from deb's (debian) but vagrant fails at runtime
with version conflicts.
Thus I finally build up the RPi5 build machine with a headless rasbian,
which is neither optimal nor a stable/valid solution, but worked.
> In summary: linux on RPis is (very) much harder than linux on Apple
> Silicon. This is thanks to the Asahi project who documented these
I agree. Anyhow the point regarding platforms like RPi(5) is: All you
need to boot could be placed on a removable medium.
> I don't understand why this was needed, the usual hacks still work
for Strange. From inside the running build vm the outer(host) /etc/hosts
dns "hack" wasn't reacheable without patching the inner(vm) /etc/hosts
too. Same later inside chroot when building the tails image. Sounds like
an isolation issue (libvirt default host-model?).
With apt_cacher-ng I had sporadic trouble, that cached (often 'Release')
files had been corrupt/incomplete, I couldn't find a reason for that so
I switched to a "noproxy" build (and thus the "inner" nginx proxy).
It was a pain, no doubt. Anyhow - it would be much easier without the
nginx proxy (and with tails arm64 debian snapshots)
I'll try to fix the boot issue and then support Debian raspi to enable
debian on RPi5.
PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
https://keys.openpgp.org/search?q=D602E3314D12FFCB
On 1/18/26 10:12, NoisyCoil via Tails-dev wrote:
> On 1/18/26 00:23, n9iu7pk wrote:
>> Hi NoisyCoil,
>> Hi David,imprecise / vague wording
>>
>> > Again, I'd encourage this work to *also* keep an eye to long-term
>> implementation
>> > on Raspberry Pis. Pis are widely available and inexpensive, so
>> supporting them
>>
>> I agree fully. Apples M's have been an important step for arm
>> architectures to move away from iot and smartphones. But unlike Apples
>> M architecture, the RPi's must not be patched to boot a different os.
>
> Apple Silicon machines do not need to be patched to boot a different OS.
> They need a bootloader to provide UEFI. RPis' boot partitions similarly
> must contain early-boot software + firmware, which is provided by
> Raspberry itself in the form of proprietary binary blobs. For Apple
> Silicon, those are "provided" by Apple (really downloaded from Apple's
> servers), in the form of a macOS stub partition + firmware (still
> proprietary). The main differences between Raspberry and Apple in this
> respect are Raspberry documents how to boot an OS, supports direct
> kernel loading and provides customer support to boot different OSes,
> while Apple doesn't.
>
> On the other hand, linux on Apple Silicon only uses ordinary arm64
> software (except for the kernel, the upstreaming of which is wip), while
> linux on RPis often does not, it needs to be pulled from Raspberry's
> archive. The reason why the RPi builds broke immediately upon upgrading
> to Trixie, at variance with the other platforms (generic arm64, Apple
> Silicon, X13s, none of these broke) is because for RPis I had to use
> that repository to make the images work fully. The last time I tried
> using the ordinary Debian archive (except for the custom kernel) for the
> RPis, the RPi 5 couldn't even connect to the internet. AFAIK the RPi5 is
> not even supported by Debian, and at least some other models only have
> partial support. I was also never able to run the Tails test suite on
> the RPi image, while I could do it for every other platform's image.
>
> In summary: linux on RPis is (very) much harder than linux on Apple
> Silicon. This is thanks to the Asahi project who documented these
> platforms and worked in a way to integrate them into the wider arm64
> ecosystem. Raspberry has not done the same work for their boards.
>
>> Boards like RPi5 (Rock's, Hardkernel's, Banana's) are cheaper then
>> Apples M's.
>>
>> NoisyCoil asked
>> > I have one question for the Tails developers/infra maintainers.
>> > Is there any chance Tails could provide time-based and tagged
>> From my point of view - that's also one of the biggest issue towards
>> an RPi5 image.
>>
>> The last weeks I worked to buld a Trixe ARM64 for RPi5 on a RPi5 based
>> on NoisyCoil's repo and branch wip/triie/raspi, see my fork https://
>> gitlab.tails.boum.org/N9iu7pk/rpi-5 from NoisyCoil, branch wip/triie/
>> raspi, commit https://gitlab.tails.boum.org/N9iu7pk/rpi-5/-/
>> commit/31275aaee7ef1af2677b10effa75cf89c9df5640 (not public, you must
>> be logged in)config/chroot_sources/raspi.chroot
>
> I don't understand why this was needed, the usual hacks still work for
> me. I've been building all arm64/asahi 7.x images and I've just built a
> RPi image using them. My current nginx configuration is in attachment.
> Also, config/arm64-disable-tails-upgrade-frontend-wrapper.patch still
> works for me, it seems I haven't changed it since wip/trixie/raspi.
>
> I have now integrated the changes from wip/trixie/raspi into the wip/
> raspi branch and bumped everything to Tails 7.4. Ftr, I haven't built
> the other 7.4 images yet, but I already have working branches.
>
>> It's possible to build images for a RPi5 on a RPi5. The image boots
>> (efi) but currently fails to find the live partition (initram stage).
>
> Confirmed, this is the state in which I left the raspi branches, and one
> can now build Tails 7.4 from wip/raspi.
>
>> It is a very experimental build and should only be used for
>> development purposes:
>>
>> - to get arm64/aarch64 packages NoisyCoil's patch/hack (nginx reverse
>> proxy) was used twice: On the buld "machine" (RPi5) as well as inside
>> of the building virtual machine.
>
> This too, I didn't need any hack inside the virtual machine IIRC.
>
>> - due to this "hack" apt_cache-ng can't be used, the rake build must
>> be started with export TAILS_BUILD_OPTIONS="noproxy"
>> - a newer version of NoisyCoils Tor browser was needed (as 14.5.7
>> wasn't available any more)
>
> Yeah sorry about that, gitlab.com has a storage limit on artifacts and I
> must delete older Tor Browser builds to make room for new ones. As a
> result, only downloading the latest stable or alpha is really supported.
> Fortunately, going forward I will have twice the space I had in the
> past, since I don't need to build alphas anymore.
>
>> - follow the changes in the commit ...
>>
>> I'll provide soon short doc/info for #10972 and try to solve the boot
>> problem.
>
> Looking forward to that!
>
>> Regards N9iu7pk
>>
>> PGP 7426 4598 B5AD 4D12 1699 C710 [ D602 E331 4D12 FFCB ]
>> https://keys.openpgp.org/search?q=D602E3314D12FFCB
>
> Cheers!
>
> _______________________________________________
> Tails-dev mailing list
> Tails-dev@???
> https://www.autistici.org/mailman/listinfo/tails-dev
> To unsubscribe from this list, send an empty email to Tails-dev-unsubscribe@???.
