Archlinux on Rock5b

Did you create a new partition to do this? I can’t overwrite or recreate the root file system because it is mounted and I can’t unmount it, ‘target is busy’. I’m stumped here and missing something 101.

Also providing AUR package(s), to have panfork ‘gofaster’ version with kernel patches would be nice. Any plans regarding this?

Where’s the ‘go-faster’ version? Is it another branch of the panfork repo or a special patchset? I may look into it.

1 Like

I noticed that the dtb files copied are not in the same hierarchy as the kernel is expecting. All rockchip related dtbs should be placed under a ‘rockchip’ directory instead of placed directly under dtbs. This could break devicetreedir option in extlinux.conf and you have to change that file EVERY TIME you update the kernel.

1 Like

From what I’ve understood this is setting env var PAN_MESA_DEBUG=gofaster either temporarily or system wide. We also need the kernel to be patched to take benefit from it

I made an iso file from my working setup:https://mega.nz/file/Uld0CIiA#CItkZNejNcSNvabMJMq2d4986TW9U5D1PeU4b_1lbxw

@Joperfi You can just try that. I’ve tested this image by flashing to an nvme ssd using balenaEtcher.

I used UUID in fstab so you can also use this image on emmc and sdcard.

You will need an 16GB media to flash this image on, and you need to resize the partition yourself if you disk is much larger than this.

My iso is not miminal and has some packages installed like sudo and git. The default user alarm is already in the wheel group and can sudo without a password. If you want to change such behavior you can just visudo by yourself.

The alarm home folder has op’s repo hw_necromancer cloned and rock5 related PKGBUILD are located in hw_necromancer/rock5. You can makepkg the one you want to install/

The boot partition has the dtbs folder changed per This pull request, and the /boot/extlinux/extlinux.conf is modified accordingly. This modification allows me to upgrade kernel and keep the same extlinux.conf file.

5 Likes

@gnattu - Awesome! thanks a bunch. I’ll give it a try soon.

1 Like

@gnattu - Etcher is telling me the disk image is not bootable - missing partition table. It went through the flash process but didn’t boot and nothing appears to be on the disk when I check it with Gparted. I’m trying to flash to an nvme drive with a usb adapter. any ideas? Sorry you have to hand hold here. The Radxa images (Debian & Ubuntu) both booted with this drive previously. Thanks

This works great.

Currently i messing around with the display resolution.
With armbian i needed to compile a dtb overlay.
rk3588-add-hdptxphy_hdmi_clk.dts from amazingfate
If i try to compile with
dtc -O dtb -o ~/rk3588-add-hdptxphy_hdmi_clk.dtbo ~/rk3588-add-hdptxphy_hdmi_clk.dts

i get
Error: /home/alarm/rk3588-add-hdptxphy_hdmi_clk.dts:1.1-2 syntax error FATAL ERROR: Unable to parse input tree

Do you have any advice to compile and use it in archlinux?

Thank you in advance

EDIT: It works the same way as in armbian - i had a typo in my dts file - now it works

Great work.

Made testing so easy :smiley:

I will try to test these pkgbuild on Manjaro Rootfs.

Thanks.

Can’t believe booting archlinux was easy as just replacing rootfs

Once booted tried upgrading packages but got traditional signature errors, as archlinux-keyring provided in archlinuxarm rootfs tarball is very old (from july)

Trying to update it alone but then get invalid or corrupted package (PGP signature). Anyone else with same issue?

Usually I can solve it with a few pacman cache clean/refresh commands but here seems different

pacman-key --init
pacman-key --populate

i think?

I’ve done this before and have had success with:

pacman-key --populate archlinuxarm

1 Like

yeah i think thats because e2e encryption depends on public key part of one’s key pair. So that everyone must create his own to establish trust. One another reason why publishing images can be insecure. Once one of those keys are exposed all of the users connections are also. Or one could decrypt the other ones since somewhere in the FS there should be private key pair, just wanted to note here as an observation without getting sidetracked.

Hmmmm did you unzip the xz tarball before flashing?

i dont flash, partition is already there. i just extract it.

bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C mountpointinfilesystem

as described here. https://archlinuxarm.org/platforms/armv8/generic

If you were to partition, u can use gparted to create an ext4 fs, and then mount it, and extract on it.

Oh Sorry I’m asking @Joperfi about my iso.

That iso is zipped with tar.xz and should be extracted before flashing.

Yes, I’m trying to extract it now in Dolphin but it seems to be taking forever and not completing. I have Ark installed also so I’ll try that. Perhaps should I re-download the file from your link if it doesn’t work?

i think you are using SDCard, but dont use dolphin in your own risk because it may not preserve the file attributes like owner. You need to compile bunch of things in this system so i dont really suggest an sd card. You might have troubles.

I think you can use your old friend cli. tar -xvf to do it in command line. Should not take too long if you have a good enough CPU and not too bad disk.