[SOLVED] login prompt keeps coming back to itself

[akrmn24]

I built an ARM64 system in a chroot inside an ARM64 VPS. The kernel and firmware I compiled for raspberry pi. The raspi boots, openrc goes through all the stages, but at the boot (autologin) prompt it keeps complaining about respawning (doesn't give me access). If I switch to another tty I see the login prompt. I put the user root and password. Then it just goes back to asking for user and password, and it never ends. It's like it keeps automatically logging me off. I know the password is correct because if I put the wrong password it gives a message about incorrect password.

This only occurs when I build the system in a chroot and then I try to boot that built image from my raspberry pi.

If I build everything inside the Pi, I don't see this problem.

I am working on a Gentoo based distribution, so it would be good to solve this problem so that people could preview an already built system without installing from source, or if they want to compile on another machine.

[pingtoo]

How you got the VPS chroot content on to the raspi?

One possible debug method is run in single user mode. This is accomplished by append "single" to the end of cmdline.txt

Once you are in the system, check if you have /dev/ content or if your root account home directory exist and have correct permission.

[akrmn24]

[akrmn24]

I start my init from my initramfs
exec /bin/busybox switch_root /mnt/root /sbin/init

I tried with /sbin/init single and this works and let me login. But when I startx I see complaints about DBUS, and when I start the dbus service, it fails. So not sure if everything can work from this mode.

[pingtoo]

[akrmn24]

OK I think I found the problem.

I realized that the system works if I don't install it (in VPS chroot) with --deep. So I thought first the elogind is the problem. But then when trying to start openbox, I noticed 'illegal instruction', which made me realize that I am building it on a VPS with -march=native, so the raspberry pi cannot understand some of the binary...So now installing it without -march=native, and I will let you know how it goes.

[karimali]

It seems like a mismatch between the chroot environment and the Pi. Here is what you can check:

/etc/securetty: Ensure TTYs (e.g., tty1, tty2) are listed for root login.
PAM Config: Verify /etc/pam.d/login to avoid login loops.
Permissions: Check /etc/passwd and /etc/shadow have correct root:root ownership.
Library Mismatch: Use ldd to ensure no missing or incompatible libraries for /bin/login or /bin/bash.
Logs: Review /var/log/auth.log or syslog for errors.
Rebuild Key Packages: Try rebuilding openrc, shadow, or util-linux on the Pi.

[akrmn24]

Removing -march=native from the compiler flags did the trick. I just marked it as solved.

[Hu]

To be clear, the problem is that you built with -march=native on a system with capabilities that the Pi lacked, then installed those binaries on the Pi, right? Such a setup would fail when the Pi fails to provide the capabilities that -march=native enabled. If the Pi builds for itself using -march=native, that ought to work, since it ought not enable features that it cannot use.

[akrmn24]

yes -march=native should work on the pi if I build it on the pi. The ampere CPU on the VPS is a bit different, so created binaries that are not comprehensible to the pi.