Rock Pi E Slarm64 (aarch64 unofficial slackware)

installation README.TXT
kernel 5.19.0

slarm64-current-aarch64-server-rock_pi_e-5.19.0-build-20220805.img.zst
slarm64-current-aarch64-server-rock_pi_e-5.19.0-build-20220805.img.zst.sha256

installation README.TXT
kernel 5.19.12

slarm64-current-aarch64-server-rock_pi_e-5.19.12-build-20220930.img.zst
slarm64-current-aarch64-server-rock_pi_e-5.19.12-build-20220930.img.zst.sha256

installation README.TXT
kernel 6.0.0

slarm64-current-aarch64-server-rock_pi_e-6.0.0-build-20221010.img.zst
slarm64-current-aarch64-server-rock_pi_e-6.0.0-build-20221010.img.zst.sha256

Hi mara, I would like to ask a few (dumb) questions, if I may. I have been running slarm64 server on a Rock PI E for quite a while now. I use it as my router/server. (You may recall that it was after my post asking about more functionality that you started creating a ā€˜serverā€™ instead of a ā€˜baseā€™ version). So, finally I bought an eMMC module and transfered my system with the ā€˜transfer-to-diskā€™ command. After a reboot, it was going fine, except the date was set to 2029, and would not reset. rc.ntpd was running but the connection was constantly rejected, and would not correct the date. So I disabled it, and the only way I could maintain correct time is to run ntpdate -u us.pool.ntp.org as a cron job every 5 minutes, otherwise the date would reset to 2029 again and again. Does this board have a harware clokc? If it does, it is not being recognised, hwclock command times out waiting for /dev/rtc0. Does my problem ring a bell with a solution? If not, thatā€™s ok. Thanks for this slackware, I love it, and serves me well.

Cheers,
Karl

There is no default hardware clock on this board. I have a script /etc/cron.d/fakehwclock that updates the date in cron, try deleting it and restarting cron.

That fixed it!
Thank you mara!

installation README.TXT
kernel 6.2.2

slarm64-current-aarch64-core-rock_pi_e-6.2.2-build-20230306.img.zst
slarm64-current-aarch64-core-rock_pi_e-6.2.2-build-20230306.img.zst.sha256
slarm64-current-aarch64-server-rock_pi_e-6.2.2-build-20230306.img.zst
slarm64-current-aarch64-server-rock_pi_e-6.2.2-build-20230306.img.zst.sha256

Hi mara,

I have been using your images on my rock-pi-e for a while, and though to try out the latest, slarm64-current-aarch64-core-rock_pi_e-6.2.2-build-20230306.img.zst. It did not quite work. This is what happened:

  1. It booted from the SD card, and I was able to log in as root. It prompted to set the root password, and set up a non-root account.

  2. After that, I was unable to log in a second time, neither as root, nor a regular user. This is what happened when I tried to log in:

~$ ssh karl@192.168.2.225
(karl@192.168.2.225) Password:
client_loop: send disconnect: Broken pipe

  1. While I was still logged in through the first login, I started the ā€˜transfer-to-diskā€™ process. It started, and confiremed the source and target, then displyed the message ā€œdisk preparation in progressā€¦ā€ for a short while, then stopped.

  2. The eMMC target had a linux partition set up, but it was empty.

  3. I tried this a few times, with the ā€˜serverā€™ verision, too. Each time the same thing happened.

  4. Finally I put back an SD card with an older version that I used before, and I was able to successfully transfer that onto the eMMC module.
    This working version is:
    uname -a:
    Linux rock-pi-e 5.16.9 #1 SMP PREEMPT Mon Feb 14 06:28:23 EET 2022 aarch64 GNU/Linux

Karl

Hi @boltran,

Regarding the transfer, the behavior of e2fsck has changed, this has already been fixed.
Šœy board generally behaves strangely, after loading, after some short time, a kernel panic occurs, this happens with any distribution kit.

try new images

installation README.TXT
kernel 6.2.8

slarm64-current-aarch64-core-rock_pi_e-6.2.8-build-20230325.img.zst
slarm64-current-aarch64-core-rock_pi_e-6.2.8-build-20230325.img.zst.sha256
slarm64-current-aarch64-server-rock_pi_e-6.2.8-build-20230325.img.zst
slarm64-current-aarch64-server-rock_pi_e-6.2.8-build-20230325.img.zst.sha256

I tried this, too, and had the same ssh problem:

~$ ssh karl@192.168.2.116
(karl@192.168.2.116) Password:
client_loop: send disconnect: Broken pipe

~$ ssh root@192.168.2.116
(root@192.168.2.116) Password:
client_loop: send disconnect: Broken pipe

I did not try ā€˜transfer-to-diskā€™

what type of network connection?

On my LAN, a wifi-connected laptop, but (if I remember correctly) I tested from a wired PC, too. Iā€™ll double-check that. However, I never had this ssh failure with the working, older version on the rock-pi-e.

Tested it again from a wired host. Same thing. Broken pipe, unable to log in.

the new kernel has a wifi driver rtw88_8723du and 8723du not included in the kernel.
now Iā€™m testing, and I donā€™t find what causes the system to kernel panic.

FYI, I am using only the eth0 and eth1 ports on the rock-pi-e. It does not have a wifi port.

my board has wifi realtek 8723du
you can try to change port eth0 to eth1 and see what happens

Actually, I did enable both ports, eth0 using DHCP, eth1 set to a static IP, disabled rc.networkmanager, and restarted rc.inet1. I checked that both ports were enabled and active, and could be pinged, before I tried to log in via eth1, and it failed the same way, after entering the password.

@boltran
I remembered everything (you need to add this during assembly), make a UsePAM yes parameter or put no in sshd_config

installation README.TXT
kernel 6.2.8

slarm64-current-aarch64-core-rock_pi_e-6.2.8-build-20230326.img.zst
slarm64-current-aarch64-core-rock_pi_e-6.2.8-build-20230326.img.zst.sha256
slarm64-current-aarch64-server-rock_pi_e-6.2.8-build-20230326.img.zst
slarm64-current-aarch64-server-rock_pi_e-6.2.8-build-20230326.img.zst.sha256

I changed ā€˜UsePAM yesā€™ to ā€˜UsePAM noā€™ in /etc/ssh/sshd_config, and now I can log in. Thank you for the suggestion.

I have not tried to use ā€˜transfer-to-diskā€™ yet.