Hello.
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 00000000
Mar 11 17:13:54 in-target: Illegal instruction
That'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.
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.
-- My regards, Damien Stewart.
