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.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:
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.
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
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.
The eMMC target had a linux partition set up, but it was empty.
I tried this a few times, with the āserverā verision, too. Each time the same thing happened.
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.