Update ROCK Pi 4 To Ubuntu 20.04

#1

I was able to update my Rock Pi XU4 from Ubuntu 18.04 to 19.04, but when I tried to move on to Ubuntu 20.04, it seems like the image provided for the 18.04 release has a partition for the /boot directory which is too small for the Ubuntu 20.04 release. I’ve tried to manually re-size the partition and rsync the root partition from a functioning Ubuntu 18.04 SD card, but the system won’t boot from the new card with the larger partition, even after I updated the PARTUUID field to match that of the new SD card.

Has anyone been able to update the XU4 to the Ubuntu 20.04 release? If so, what’s the secret?

#2

Armbian Focal 20.04 is coming soon. There, it will work. There is also no Windows FAT boot partition. Pure Linux :wink:

You can also build it on your own: https://github.com/armbian/build

#3

Igor,
Thanks. I look forward to the release, but will also do a build from the github link you provided.
John

#4

Igor,
I noticed your name came up when doing some of the builds that I did, so I thought I’d pass along a couple of comments. I first tried to build the OS on my RockPi, but soon discovered that I needed to build it on an x86 system. So I moved to my x86 Linux box and first built an odroidu4 system and then a rockpi-4b system. Both builds completed “successfully” but there were a couple potential issues. The file type of the partition in the odroidxu4 wasn’t set, so I was unable to mount it to look at the contents until I ran /sbin/fdisk and gave it a Linux file type. After that things seem to be fine, but I haven’t yet tried to boot the Odroid Xu4 from it. That’s next on the agenda.

For the Rock Pi build, the partition type was set, but the partition was sized to a little over 1GB on a 64 GB sd card. I had to delete the partition, re-create it from the original start point and then run resize2fs to restore the capacity to 64GB. That might have happened on first boot on the RockPi on its own, but I went ahead and re-sized things anyway. Again, I haven’t yet tried to boot the RockPi system yet, but will be doing so soon.

It may be that these are all expected behaviors, and if so, don’t worry about it. But they also might be minor omissions in the build process and that’s why I’m passing the info along. It also might be that I’ve munged things up with these changes and neither system will boot and I’ll have to do it all over again. Time will tell…

John

#5

Igor et al
Well neither system was able to boot with the systems I built. So I went to the Armbian site and downloaded a pre-built image but again had no luck. The original Rock Pi distribution which boots has the following partition table:
partition start end Type
p1 64 8063 Linux
p2 16384 24575 Linux
p3 24576 32767 Linux
p4 32768 262143 EFI
p5 262144 62071775 Linux

whereas both the system that I built for the Rock Pi and the pre-built image that I deployed have a partition table:
p1 32768 6561791 Linux
so the Armbian disk is set up to correspond to the EFI partition but is missing the (apparently necessary) additional support partitions.

The Odroid XU4 distribution also failed to boot, but I was able to upgrade the Odroid XU4 to Ubuntu 20.04 anyway, so I don’t really need to get that operational. I didn’t write down the details, but it looks like there’s a similar attempted alignment with partitions, but in the case of the Droid XU4 the addresses are different.

As a last resort, I can try to run the Ubuntu 18.04 on the RockPi with Ubuntu 20.04 on the other systems by deploying the same version of Open MPI and see if I can make that work (although I may need to re-compile the applications on the different OS versions). But I’ll try to dd the partitions from the SD card that works onto another and capture the Armbian deployed system as well and see if that makes things work.

#6

1G partition is not a bug, but advanced feature which is not present in every amateur based creation. Image and overall OS deployment is faster when srinked down to the actual data size. When you boot the image, its getting resized … also no reboot is needed (like on all others). It just work.

The problem with Rockpi not booting Armbian is bad boot loader on SPI. You need to update it, then it boots properly. Check other threads on the forum - has been discussed many times. Also on the Armbian download pagas you have direct links.

Linux is a community OS. Nobody is more right, correct or original … Its just the way they choose to partition. Armbian has one partition as it has it on all other boards! We choose to have one standard, not several ones which none is working well … not yet.

Armbian does not need any EFI loader. It provides complete firmware.

Give it some more time and check docs before starting … You need to invest a little more then an afternoon if you go your route.

#7

I tried to update the SPI but had no luck in getting things to boot. Then I discovered this page:
https://wiki.radxa.com/Rockpi4/hardware/spi_flash
and looked at the board. Sure enough, my RockPi is V 1.3, so the SPI is not soldered. Unless I want to take a soldering iron to the board, it looks like I’ll need to get an updated RockPi. Looks like I bought a bit too early in the development cycle…

#8

I bought an SPI chip and soldered it in, deployed the various software images to it and finally was able to boot Armbian. Unfortunately, even after building and installing openmpi-4.0.3, the Armbian system is unable to invoke mpirun against the other units running Ubuntu 20.04.

Meanwhile, I also ordered another RockPi version 1.4 so I’ll work with it. I came across a multi-boot script on this forum so I’ll give that a try with the new unit when it comes in and see how things go.