Re: Debian installer for ppc64 and related packages are broken by crashing binaries

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.