@neilwhitlow Yes, they are still current.
Installation on SD card work fine but fail on NVMe drive
The DD command work OK: the nvme hold all partitions and files\folders
But the installation on nvme fail at:
sudo chroot /mnt
The output error is:
chroot: failed to run command â/bin/bashâ: Accessing a corrupted shared library
Retry with new SD card and new NMVE M2
Flash the SD card with:
wget http://cdimage.ubuntu.com/ubuntu/releases/21.04/release/ubuntu-21.04-preinstalled-server-riscv64+unmatched.img.xz
unxz ubuntu-21.04-preinstalled-server-riscv64+unmatched.img.xz
sudo dd if=ubuntu-21.04-preinstalled-server-riscv64+unmatched.img of=/dev/mmcblk0 bs=1M status=progress
Boot SD card without problem but again the installation on nvme fail at âsudo chroot /mntâ with the same error message
Any help will be greatly appreciate.
Iâd recommend you try re-downloading the image and redoing the dd
command with the re-downloaded image. That error message implies that something didnât get copied properly, either while downloading the image, decompressing it, or writing it to the NVMe.
Also just to be sure, the NVMe is plugged into the Unmatched while youâre doing the chroot, correct? You can only chroot into a RISC-V root using a RISC-V system. There are ways to work-around the chroot, but if /bin/bash
canât be loaded your system wonât be usable either way.
And since is this the most recent ubuntu thread and the topic is somewhat generic:
is there any active development on this right now? Where/by whom? i.e. patching in latest changes of the Freedom Unleashed SDK (including 1.2 [or more] GHz) ?
Yes we are still actively developing Ubuntu on RISC-V and for the Unmatched specifically. @xypron is leading that effort, and changes to packages can be observed on Launchpad: OpenSBI, U-Boot.
I know weâve discussed the CPU speed issue but Iâm not 100% sure where it stands in development. Other developments weâre working on are booting with grub, and toolchain improvements (such as in golang and javascript).
I have unofficial Ubuntu u-boot and kernel builds here.
https://forums.sifive.com/t/latest-ubuntu-u-boot-and-kernel-images/
Thanks for the reply and in particular your efforts!
It would be great to stay posted somewhere here about the status/news.
Hello Martin,
I assume that you relate to the patches in
Unfortuntately these are not in sync with the patches that have been sent upstream. Take for instance 0002-riscv-sifive-unmatched-update-for-16GB-rev3.patch. Some of the changes are in an accepted upstream patch d09560435cb7 (âriscv: dts: fix memory size for the SiFive HiFive Unmatchedâ).
If you think patches are missing in the Ubuntu kernel, please, open an issue on launchpad.net indicating the upstream patches either by commit ID or by the URL on lore.kernel.org.
Best regards
Heinrich
Just FYI, thereâs a new patch set for the 5.13.x kernel.
The 0002-riscv-sifive-unmatched-update-for-16GB-rev3.patch file is still out of sync though.
Yes
I did it: downloaded from 2 differents sources, use 2 different USB SD card reader, use SD card not the same size and brand. I always get the same âchroot: failedâ message.
I also try âsudo chroot /mntâ on the SD card from SiFive (Xfce4) and I get also the message:
chroot: failed to run command â/bin/bashâ: Accessing a corrupted shared library
The default shell on Xfce4 is bash (and work fine). How can the library be corrupted ?
Probability that error come from OS on the SD is then very lowâŠ
Is my firmware corrupted ?
@JawnSmith I see that there is now a 20.04.03 image up:
https://wiki.ubuntu.com/RISC-V
Is there any benefit to running this? Outside of general LTS/non-LTS considerations. E.g. more packages built, fixes or later bootloader etc.
@AndrewBack The general LTS/non-LTS considerations hold true here. There are more packages built, bugfixes, and recent bootloader on the development version, 21.10 that will be releasing on October 14. The beta is already available at https://cdimage.ubuntu.com/ubuntu/releases/21.10/beta/ubuntu-21.10-beta-preinstalled-server-riscv64+unmatched.img.xz
Oh, that is great news! Assuming that 21.10 will have general updates (like 1.2 or more Ghz) as well.
Clock speed is purely firmware on the Unmatched, so the only reason newer Ubuntu images clock the core faster is because they have newer firmware baked into the pre-built images (and that Linux distributions continue to go down the route of providing an SD card image, rather than leaving firmware completely separate and shipping a generic USB stick image so theyâre completely decoupled like FreeBSD (and, now, Haiku) does). It has nothing to do with the actual OS (beyond the usual improvements that can come from kernel updates on any hardware).
We set the clock speed during the boot process with u-boot. The version in impish sets it to 1.2 GHz.
Thatâs what I said. Itâs just the version that Ubuntu happens to ship with on the different versions differing in their clock speed configurations.
Yes thatâs correct. I wasnât disagreeing, just adding some detail and confirming that 21.10 is set to 1.2GHz.
Hi all,
I am just trying to set up Ubuntu 21.10 from here:
https://cdimage.ubuntu.com/ubuntu/releases/21.10/release/
I ddâd the image to SD via:
sudo dd if=ubuntu-21.10-preinstalled-server-riscv64+unmatched.img of=/dev/mmcblk0 bs=1M status=progress
And before I booted with the new SD, I renamed the /boot/extlinux/extlinux.conf on the nvme to avoid launching the freedom OS from former nvme install.
However I receive (via console usb connection) some of those during boot:
âA start job is running for /dev/mmcblk0p3 (15s / 1min 30s)â
then after a while among other messages these fails:
â[DEPEND] Dependency failed for Local File Systems.â
âŠ
â[FAILED] Failed to start Console System Startup Logging.â
âŠ
"You are in emergency mode. After logging in, type âjournGive root password for maintenanceâ.
There Iâm stuck. CTRL+D loops back to this request and I wouldnt even know the ubuntu root passâŠ
Is this behavior somehow known or what went wrong here?
Any help is highly appreciated.
Thanks in advance!
Itâs hard to tell exactly whatâs going on without full logs, but it looks to me like the freedom OS is still attempting to boot. The Ubuntu images shouldnât even have a /dev/mmcblk0p3, so thatâs likely the freedom OS trying to boot and not finding a partition that itâs expecting to find.
You can force boot from mmc0 by hitting any key when you see the âHit any key to stop autobootâ message on the serial console, and then type ârun bootcmd_mmc0â. Renaming the nvme extlinux.conf file should work for freedom-u-sdk, but maybe there is something different about the boot flow for Ubuntu that prevents that from working.