I suspect that this is a library problem, as more than systemd is affected, and the bottom 16 bit of the lr are suspiciously similar -- this is one library that is mapped into different processes at different addresses (but with at least page granularity).
When doing a chroot to the installed partition it was functional but I found using apt or other tools in the list crashed. When booting it directly it immediately crashed on systemd and could go no further.
Yes, these are normal as far as I know. Installer packages are never manually chosen (so the Description isn't needed) and are installed from a consistent set (so the Architecture isn't needed). The Pre-Depends errors are likely from the debootstrap run -- in principle a Pre-Depends on an Essential package should be treated like a Depends here, but this is one of these problems that aren't really worth solving.
I expected that to be the case. To the untrained eye it may
look a bit sloppy all these issues installing packages and
seeming errors popping up. But it is a complicated process
that's constantly evolving with each update of the install
process.
Mar 11 17:13:54 kernel: journalctl[8546]: illegal instruction (4) at 3fff95032000 nip 3fff95032000 lr 3fff95033234 code 1 Mar 11 17:13:54 kernel: journalctl[8546]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX Mar 11 17:13:54 kernel: journalctl[8546]: code: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX <7f454c46> 02020100 00000000 00000000That's an ELF header -- the program counter is at the beginning of a mapped binary, not at the beginning of the code contained in it. My suspicion is that someone makes an assumption that function pointers are the same size as normal pointers. The C library generally does this right, but there are various plugins loaded from there like NSS and PAM modules.
Mar 11 17:13:54 in-target: Illegal instruction
Simon
You're right. I just realised the "7f" was
the leading byte in the ELF header. Like an obvious riddle with
an answer hidden in plain sight. I can't get used to lower hex
produced by C format. But the X's around don't help either. I
read something about hiding machine code in crash dumps for
security so thought it may crossed out for that reason. So this
makes me think if a conflict in ABI is involved? Like a mismatch
between function descriptor and function pointer.
Further tests suggest a kernel conflict. I
tested booting it with a long term kernel 5.10.235 and it was
able to boot. I was unable to login as it rejected my password
so possibly the password setup from installer corrupted. But I
am able to chroot to it and fix that as well as update and
install packages.