On 1/18/26 15:22, n9iu7pk wrote:
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.
Ah yeah, I see, of course.
> 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.
Probably because of the license change? There was also ongoing
discussion to drop it in Debian because of that, I know the Tails
maintainers are aware of this.
Thus I finally build up the RPi5 build machine with a headless rasbian,
which is neither optimal nor a stable/valid solution, but worked.
This is how I got the first working prototype of Tails for arm64! You
can also run the test suite on an RPi5 + Raspbian (although it spits out
quite a few errors and you must rerun it multiple times to get all tests
passing).
> 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.
Indeed.
> 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).
Yeah, it happens to me too sporadically (e.g. on updates of Debian
stable), and when it does I throw away the apt_cacher-ng disk image and
let the build system create a new one.
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
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].
