Rock64 fail to boot after update

[mcloaked]

I had a rock64 working perfectly from an original install using the file:

-rw-r--r-- 1 mike mike 389M May 2 2018 ArchLinuxARM-aarch64-latest.tar.gz

After that I used to regularly pacman update without issues. However after moving home in 15 months ago I didn't use the rock64 until today, and I booted it up and logged in without any problems. However after running a pacman update which included a new kernel the rock64 would not allow me to ssh in once I had rebooted.

In the end I decided to re-install - and followed the same method from the page at https://archlinuxarm.org/platforms/armv ... hip/rock64 that I had used originally - but once the install was complete and I transferred the sd card back into the rock64 it would again not allow ssh in once booted.

So I did a complete re-install again from scratch, but this time instead of using the current ArchLinuxARM-aarch64-latest.tar.gz file, I used the original file I had in backup from May 2 2018, and once this was done and the sd card was reinserted into the rock64 it would boot up and allow me to ssh in without any problems.

So I dare not do a pacman update because it will presumably then fail to boot or if the boot does complete it won't allow me to ssh in! Does anyone know what has broken recently for the rock64 in terms of which package might cause the problem and what is the best way to update but still have a working machine?

Thanks.

[moonman]

Please do not post the same thing in multiple sections of the forum.

You can have a backup "dropbear" running on a different port to have a backup connection as it doesn't really depend on any other package, given that your device actually boots up and ssh is the only problem.

[mcloaked]

My apologies for posting twice to the two sections. Since the only option I have for access is via ssh, I can't be sure that the boot completes unless I can ssh in and run diagnostics. I will have to look at dropbear to see how that is set up. I also have an odroid-c2 which was again running without issues and pacman updates were never problematic, but again running the pacman update after a long period without using it, left the odroid-c2 also with no ability for me to ssh in. So I don't know if there are issues with the addressing, or it the boot did not complete. I could not see any ip addresses listed as connected to the ethernet in the LAN once the units were 'booted' up, as listed in the routers. So it is an odd problem and I don't know how to diagnose or get diagnostic data if I can't connect to either unit.

Edit: I wonder if the problem with the rock64 is related to this issue:

viewtopic.php?f=67&t=14341#p63297

[Kabbone]

I was wondering that too, but this would assume, that u-boot got updated too.
If you only were changing the Archlinux.tar.gz and ssh stopped working this can't be related to each other as long as you don't execute the dd commands on the instructions.

I didn't use my rock64 for 1-2 month, but I could boot it up later and do a pacman update.

Btw: Did you restart the rock64/sshd daemon after the update unable to login?
https://www.archlinux.org/news/sshd-nee ... nssh-82p1/

EDIT: Just updated, no problems here. The only thing which is not upstream repo on my system is u-boot with ddr frequency, but as I said, if this would be your problem also the old image shouldn't work if the bootloader (all dd at the instructions) keeps the same

[mcloaked]

The restart of sshd would not impact whether or not sshd was started after reboot? Provided sshd is enabled it should restart when the machine reboots, but it seemed not to. However I will check whether sshd is enabled before reboot. I also think I will try the suggestions in the link in my previous post - to switch the processor frequency to the lower value, and then run the pacman update, and then check sshd is enabled, and then finally reboot and hope that I will then be able to ssh in. the rock64 has no monitor or keyboard and so is totally headless - the only access I have to it is ssh. Once I have tried changing processor frequency by removing the microsd card and making the changes as per

$this->bbcode_second_pass_code('', '
$ mkimage -n rk3328 -T rksd -d rk3328_ddr_333MHz_v1.13.bin idbloader.img
$ cat rk3328_miniloader_v2.46.bin >> idbloader.img
# dd if=idbloader.img of=/dev/sdx seek=64 conv=notrunc
')

I will put the microsd card back in the rock64 and try to boot.... I will post the result of that test in a day or two.

Edit: that failed at the first hurdle:

$this->bbcode_second_pass_code('', '
[mike@lenovo1 rock64]$ mkimage -n rk3328 -T rksd -d rk3328_ddr_333MHz_v1.13.bin idbloader.img
Error: SPL image is too large (size 0x18000 than 0x7000)
Error: Bad parameters for image type
')

Edit 2:

I ran a pacman update - and during the update there was the following during the post-install output:

$this->bbcode_second_pass_code('', '
:: Running post-transaction hooks...
(1/5) Updating module dependencies...
(2/5) Updating linux-aarch64 module dependencies...
(3/5) Updating linux-aarch64 initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-aarch64.preset: 'default'
-> -k 5.7.2-2-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.7.2-2-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-aarch64.preset: 'fallback'
-> -k 5.7.2-2-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.7.2-2-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: wd719x
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
cp: cannot stat '(builtin)': No such file or directory
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly
(4/5) Updating linux initcpios...
==> Building image from preset: /etc/mkinitcpio.d/linux-aarch64.preset: 'default'
-> -k 5.7.2-2-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux.img
==> Starting build: 5.7.2-2-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [autodetect]
-> Running build hook: [modconf]
-> Running build hook: [block]
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux.img
==> Image generation successful
==> Building image from preset: /etc/mkinitcpio.d/linux-aarch64.preset: 'fallback'
-> -k 5.7.2-2-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux-fallback.img -S autodetect
==> Starting build: 5.7.2-2-ARCH
-> Running build hook: [base]
-> Running build hook: [udev]
-> Running build hook: [modconf]
-> Running build hook: [block]
==> WARNING: Possibly missing firmware for module: wd719x
-> Running build hook: [filesystems]
-> Running build hook: [keyboard]
-> Running build hook: [fsck]
cp: cannot stat '(builtin)': No such file or directory
==> Generating module dependencies
==> Creating gzip-compressed initcpio image: /boot/initramfs-linux-fallback.img
==> WARNING: errors were encountered during the build. The image may not be complete.
error: command failed to execute correctly
')

However according to viewtopic.php?f=65&t=14337 those messages should have been harmless.

I checked that sshd was both running and enabled - and doing systemctl daemon-reload and then restarting sshd I checked that I could still ssh in and it was fine.

I then rebooted and no longer is there any access into the machine and also it is no longer pingable.

$this->bbcode_second_pass_code('', '
$ ssh root@rock64
ssh: connect to host rock64 port 22: No route to host
$ ping -c2 10.0.0.54
PING 10.0.0.54 (10.0.0.54) 56(84) bytes of data.
From 10.0.0.94 icmp_seq=1 Destination Host Unreachable
From 10.0.0.94 icmp_seq=2 Destination Host Unreachable

--- 10.0.0.54 ping statistics ---
2 packets transmitted, 0 received, +2 errors, 100% packet loss, time 1026ms
pipe 2
')

So I am again stuck and will have to install from scratch.

[Kabbone]

I didn't mean you have to restart sshd and reboot, just wanted to make sure you didn't do the update and weren't able to connect to it, but without restarting sshd or rebooting. Are you even able to ping your rock64 after the update? Perhaps it's not even booting up.
What kind of partition scheme do you have and which filesystem? I had another problem with that and a new kernel version, but people following the instructions shouldn't get into this problem (was BTRFS related).

Btw. it's not the processor frequency, it's the RAM frequency.

[mcloaked]

OK - and yes sorry it is RAM frequency, you are right - I edited my previous post rather than add a new post - the partition scheme was untouched from the original from the install instructions so a single /dev/sdc1 (as seen on the microsd card plugged into a separate laptop) partition where the entire file structure resided.

[Kabbone]

so, your problem is not ssh at all, after your update your system is not booting. Probably you need either uart or a Monitor/TV to get some output what the problem is.

[mcloaked]

OK I went right back to scratch and installed as per https://archlinuxarm.org/platforms/armv ... hip/rock64 but using the initial image from March 2018. The system boots up fine, and I can ssh in. I made new users, and the system operates as normal. The only thing I did not do was the final removal of boot.scr and replacing it by pacman -Sy uboot-rock64

If I update the system then it will no longer boot up properly or allow me to ssh in again. I have checked that sshd service is enabled and working. Without updating the system will shut down and reboot normally and allow me to ssh in. If there is anything I can run that could enlighten where the problem lies I would appreciate it.

[Kabbone]

like I said, you can for example try to exclude the kernel from the update.