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!
