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
[email protected]
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
_______________________________________________
Tails-dev mailing list
[email protected]
https://www.autistici.org/mailman/listinfo/tails-dev
To unsubscribe from this list, send an empty email to
[email protected].
