I am trying to install the latest manjaro-arm minimal from github for the raspberry pi. It boots into “root (Automatic login)” and asks for the password. I have tried all the usual suspects, and also tried the user “manjaro” with “manjaro” as the password. All without success. Please help.
If it’s relevant, I used the raspberry pi imager to install the image on the SSD.
The imager does not officially support Manjaro - so resist the temptation to use the tool to apply settings to the final image.
I have reproduced your issue - but I am not really sure who in charge of these images
Yes, I am aware of that, and I answered “no” to apply settings. In any case, can you find the person responsible?
usually it is root:manjaro or manjaro:manjaro with the minimal as the exception.
With that one the oem script starts to collect the initial information to setup the system.
You can always use manjaro-arm / applications / manjaro-arm-installer · GitLab which will build the image.
You can target anything that connects to the system - so pay serious attention to the target device - not so long ago I wiped my data device by accident.
Thanks. I’ll try manjaro-arm-installer.
I just tested the installer script - which when executed pulls the rootfs from github.
This affects the sd card the script prepares in the same way as the image you can get from github.
No one is maintaining any of the images since Dan left. It has been a couple of years since I have booted a minimal image on a rpi. If I remember right on first boot it booted straight into a TUI installer script as root. I do not believe that root had a password as one could also ssh to the device headless to set it up with ssh root@the-device's-ip-address then hit the enter key when it asked for the password then the TUI installer script would automatically come up.
That is also what I remember - the current image does not start network so - kind of weird.
Well it definitely boots into root, and then asks for a password. I see that the github weekly minimal images all have different sha256 checksums, but that could be just due to changes in header information, rather than substantive changes to the image.
I have located two issues
My brain is tired now - I will create a couple of merge requests tomorrow
There is two repos involved - manjaro-arm-tools and manjaro-arm-oem-installer.
The rest will have to wait.
Is that possibly related to my issue here with no network on minimal?
If the image is working right there is no wifi on tthe first run; only ethernet. The wifi has to be set up after going through the install TUI and rebooting. We can’t get to the install TUI in this issue.
If by no network you mean wifi - then no - not related.
My tests is with the ethernet on rpi5 - still have to figure out what has changed.
A while back I created [root tip] [How To] Hacking ARM install image to connect to your WiFi
There is several steps involved to patch an existing image.
Open the sdcard’s root filesystem, using your file manager and make a note on the mountpoint.
/run/media/$USER/ROOT_MNJRO
Open a terminal - keep in mind that paths are relative to the mountpoint - create variable to hold the path
ROOT_MNJRO=/run/media/$USER/ROOT_MNJRO
Navigate to the etc/systemd/network folder
cd $ROOT_MNJRO/etc/systemd/network
Create a network definition for your ethernet NIC.
cat << EOF >> end0.network
[Match]
Name=end0
[Network]
DHCP=yes
EOF
Navigate to multi-user.target.wants
cd $ROOT_MNJRO/etc/systemd/system/multi-user.target.wants
And create a symlink to enable systemd-networkd
ln -s /usr/lib/systemd/system/systemd-networkd
Do the same for systemd-resolved
ln -s /usr/lib/systemd/system/systemd-resolved
The buildarmimg for the minimal/server image creates a copy of the file usr/lib/systemd/getty@.service to activate root autologin. This approach no longer works.
Still in the terminal - inside the mounted image - list the files
ls $ROOT_MNJRO/usr/lib/systemd/system/getty@*
You should see two files
Replace the getty@.service with getty@.service.bak
mv $ROOT_MNJRO/usr/lib/systemd/system/getty\@.service.bak $ROOT_MNJRO/usr/lib/systemd/system/getty\@.service
Navigate to the root image etc/systemd/system folder
cd $ROOT_MNJRO/etc/systemd/system
Create a override folder for getty and enter the folder
mkdir getty@tty1.service.d
cd getty@tty1.service.d
Create the autologin.conf in the new folder
cat << EOF >> autologin.conf
[Service]
ExecStart=
ExecStart=-/sbin/agetty -o '-p -f -- \\u' --noclear --autologin root %I $TERM
EOF
To make sure the installer cleans up correctly - navigate to usr/share/manjaro-arm-oem-installer
cd $ROOT_MNJRO/usr/share/manjaro-arm-installer
Edit the installer script
nano manjaro-arm-oem-install
Go to the end of the script
msg "Configuration complete. Cleaning up..."
mv /usr/lib/systemd/system/getty@.service.bak /usr/lib/systemd/system/getty@.service
Amend by commenting the reference to restoring the original getty@.service and instead remove the override in /etc/systemd/system folder
#mv /usr/lib/systemd/system/getty@.service.bak /usr/lib/systemd/system/getty@.service
rm -rf /etc/systemd/getty\@tty1.service.d
Save the file and unmout the partition
In my case, no network comes up. No ethernet or wifi interfaces are listed.
If i plug in a USB network card that shows up.
I’ll have a look through your guide and see if I can find what’s missing.
That is indeed unrelated to this - I say it is a device specific issue - orange pi is not raspberry pi - but I cannot say for sure - I only use raspberry pi
Thank you linux-aarhus for the detailed instructions. It worked well.
One minor typo correction. The command after "Navigate to “multi-user.target.wants” should be:
cd $ROOT_MNJRO/etc/systemd/system/multi-user.target.wants
A little issue. I couldn’t find any way to exit root. I tried exit, CTRL-D, logout. It always come back in root.
It didn’t matter in my case, as I installed a GUI, and I was able to login to my user account from that.
Thanks again.
you are right - that is a typo.
there is no exit root - you mounted the partition - thus eject it using the file manager 