Hello, I’ve seen in the latest release Armbian now supports installing to UFS but can’t really see much information about going about this? I boot into the SD card and I’ve tried both installing a new copy to the UFS, which seems to do something but booting only gets as far as initramfs, and copying existing install from SD card which just fails with the following:

“No bootable install method is available for /dev/sda on this system (no EFI firmware, no
GRUB, and no board u-boot support).”

 

I have tried both Debian and Ubuntu minimal images on vendor and current kernels.

I did have a FriendlyElec image on there before but used Rkdevtool to erase the UFS module prior to trying again with Armbian. I’m wondering if anyone has had success with this? I saw a thread with someone struggling with Btrfs but I’m not able to get ext4 working.

Any help or instructions is appreciated, thanks

Edited August 21Aug 21 by Onion32

We ran into both of these bringing up UFS on our own RK3576 boards — they're separate problems:

Stuck at initramfs: nine times out of ten the root= device name didn't follow the move.
Drop to the busybox prompt and check cat /proc/cmdline — if root= still points at
/dev/mmcblk... while the UFS shows up as /dev/sda1, the kernel simply can't find the
rootfs. Fix is a one-liner in /boot/armbianEnv.txt (or the U-Boot env). If U-Boot gets
far enough to hand off to initramfs, the loader itself is fine, so don't re-flash
anything yet. "No bootable install method ... no board u-boot support": that message comes from the
armbian-install board database — NanoPi M5 isn't wired up for a UFS write target yet
(SD/eMMC paths exist, UFS doesn't). Copying the SD install won't work until that's added.
The workaround is manual: dd idbloader/u-boot.itb to the UFS at the correct offsets for
RK3576 (the loader layout on UFS differs from eMMC, so don't reuse eMMC offsets). One caution on RKDevTool:

erasing from it doesn't always clear the RK private header/IDB residue, which can leave a half-valid parameter block that confuses a later install.
rkdeveloptool with an explicit erase 0x0 of the first blocks is more reliable. Try the armbianEnv.txt root= fix first — it's the cheap one and probably gets you booting.

Hi,

 

I'd like to understand how you're installing the system on UFS. The steps are simple: put an image on an SD card and insert it into the NanoPi M5; then, when you run the `armbian-install` command, UFS should appear, and from there it should install the bootloader and move the filesystem to UFS. Once that's done, you need to switch the physical switch to UFS.

 

If it doesn't start, please also list the type of kernel you're using and the armbian-install logs, because the binaries it's supposed to install are present on the board configuration.

 

In any case, I'll try again to go through the entire process to see if something has gone wrong with the releases so I can fix it in the next ones.

Same problem here ...

 

NanoPi M5, Armbian 26.8.1 Gnome

 

Installed Armbian on SD-card; NanPi boots fine (with hardware switch  on UFS/SD)

 

Opened a terminal and ran armbian-install :

2 options :

- Install Armbian to a disk (SD/eMMc/NVMe/Sata/USB)

- Flash / update the  bootloader (u-boot) only

 

First option gives a choice of sda, sdb, sdc, sdd

 

sda results in above error message : 

“No bootable install method is available for /dev/sda on this system (no EFI firmware, no
GRUB, and no board u-boot support).”

 

(also, there is no mention of UFS anywhere, but from the Blog/Newsletter I understood that this may be related to Rockwell, who still refers to it as SATA ?)

UFS is presented as SCSI /dev/sdX kernel names and is not related to SATA (also USB-stick would appear as /dev/sdX name). NVME and SD-card/eMMC both use different names. I see from the script in https://forum.armbian.com/topic/60020-nanopi-m5-2651-ufs-install-btrfs-root-does-not-boot-and-manual-partition-layout-is-not-available

that bootfs and rootfs is not special compared to just SD-card, but U-Boot seems different although all covered by the standard Armbian U-Boot install script function.

 

The confusion might be, also for me as I don't own UFS, is the four different sdX devices. I have a similar issue with my NanoPi-R6C where, in the eMMC, there is also 2 extra bootX block devices that can be used for bootloader objects (A and B schemes etc). They are normally not used, but now for UFS maybe, I don't know for real, but from the script one can derive certain things. Also I have not looked into the mentioned 26.8.1 GNOME image w.r.t. the write_uboot_platform_ufs in /usr/lib/u-boot/platform_install.sh, but that is needed if I would own a M5.

 

At the moment, I think more of the 4 sda, sdb, sdc, sdd devices (what is what), kernel might do random order, at least Debian based distros do that, I know openSUSE usually has the device named sda, so the first, for the OS and other HDD's or so in a computer sdb, sdc, sdd, etc. But to have it more predictable, there is:

 

root@rock5b:/dev/disk# l
total 0
drwxr-xr-x  9 root root  180 Oct 26 16:23 ./
drwxr-xr-x 20 root root 4.5K Oct 26 18:27 ../
drwxr-xr-x  2 root root  880 Oct 26 18:27 by-diskseq/
drwxr-xr-x  2 root root 2.0K Oct 26 18:27 by-id/
drwxr-xr-x  2 root root  160 Oct 26 18:27 by-label/
drwxr-xr-x  2 root root  240 Oct 26 18:27 by-partlabel/
drwxr-xr-x  2 root root  620 Oct 26 18:27 by-partuuid/
drwxr-xr-x  5 root root 1.2K Oct 26 18:27 by-path/
drwxr-xr-x  2 root root  240 Oct 26 18:27 by-uuid/

Example, yesterday, I had to use a 'by-partuuid' path for iSCSI target in my ROCK5B as the underlying Samsung SSD is virtualized now (so /dev/vda instead of /dev/sda) and the 'by-id' is empty then.

 

Edited Tuesday at 08:56 AM5 days by eselarm

Dear @eselarm,

 

Thank you for thinking along.

 

First, I would like to mention that I date from before MS-DOS 1.0, therefore my somewhat rusty brain has an older model CPU (no cores, or if you like, 1 core A-1 running at a clock frequency of max 1200 Hz), and that all this tends to go a little bit over my head, even though over the many years I did encounter quite a few Unix, Linux and other systems ....

 

1. my reference to SATA was merely related to the mention of SATA in the Armbian blog post of last May 27; armbian-config and armbian-install only refer to SD, eMMC, NVMe, SATA and USB, but not to UFS or SCSI at all (?),

 

2. the script you refer to is from someone who had a problem installing on a btrfs file system, but I understand that btrfs is not supported (at least not for the boot partition ...). This may be a separate problem ?

 

In any case, I do not have such advanced needs, am happy to stick with ext4 and would like to keep btrfs issues separate, 

 

3. I now realize that in my original post I should have provided more information :

 

a) UFS not virgin : I previously installed a standard Ubuntu Gnome image from Friendlyelec (some time ago, do not recall how but it must have been one of the procedures mentioned in their Wiki}. This works : using the Friendlyelec image, system boots from UFS and appears to work fine (and still does; so far I can run Armbian from SD only).

 

I do not know whether their procedure (their ¨USB-images¨, integrated with their eFlasher, etc) may have any effect on partitions etc ?

 

b) what is sure from a) above is that UFS is there and works. Also if I go to :

 

b1) Apps --> System --> Disks, I get :

256 Gb Disk Btwin <some-long-number>
SD card reader SDABC
17 Mb Block Device /dev/mbdblock0 (I guess this must be the on-board SPI ?)

 

b2) if in a terminal I go to /dev/disk I get output similar to yours.

 

b3) in armbian-config or armbian-install I get :

 

sda   /dev/sda    239 Gb  <some-long-number>
sdb   /dev/sdb     4.0 Mb  <some-long-number>
sdc   /dev/sdc      4.0 Mb  <some-long-number>
sdd   /dev/sdd     8.0 Mb  <some-long-number>

 

Bottom line is that I am still a bit lost ?

I think it is clear now to me how the hardware is, I also took a look at https://www.friendlyelec.com/index.php?route=product/product&product_id=309

(scroll down to the PCB pictures layout and interfaces).

Also your b1) and b3) info points help confirming and I see that this is yet another step in complexity (or just more options, it is great hardware) but I can't find where in Armbian config this is handled in a way similar to the script attached in the other topic related to Btrfs for rootfs. In addition I took a peek at the (for me) banned 'AI-bot' account 'Boardcon_yang' and again see rubbish hallucinations. I understand that Boardcon is a real company, but my take is to avoid that company as a plague because simply this is how they deal with individuals/humans then apparently.

Also Armbian should do something about it. Same as AI generated videos/pictures that are on social media (I am not, all blocked, I even do not have a big-tech Microsoft github account), it should be marked as such. Else it will be like email spam boxes: block all except the ones clearly human still or just not use Armbian and this forum anymore. 

 

So back to the issue: Is a matter of what you want or more difficult, what is wanted/done by Armbian and the people/organizations/companies doing the financial backing. There are (I think) 6 Linux block devices that could contain the bootloader or a part of it (a version of U-Boot in this case):

sda

sdb

sdc

sdd

SD-card

SPI-NOR-flash

 

sdd is new to me and don't know what that shall be used for. It can easily take months or years before it is known in general what is a practical way of working for an individual (so non-profit, users at home for example). For professionals/industry there might be a exchange of info under Non-Disclosure-Agreement, so can be all clear, like Android system builders. Those also need large volume management of systems, at least end-users are certainly not the admins of the things they use. It might be even forbidden by law as is known from telcos (depends on country).

 

The question is what the ROM code in the RK3576 does based on how the M5 HW design is, it is usually some signal level that determines which device is read first or check for a bootloader of some stage. You need documentation then, look in schematics of the board, but then still it might be unclear what steps the ROM does at power-on.

 

If you have used the board with other OS earlier, that one might have written a version of its bootloader to SPI-flash (/dev/mtd0) for example. Compared to other already well-know SoCs/boards like ROCK5B, it is clear that SPI-flash offers the best options like we know from PC's: So you have like a BIOS setup as it can store variables about the OS there. I do that on my ROCK5B as it has SPI-flash only (or SD-card). My NanoPi-R6C has no SPI-flash, just soldered eMMC and with the current U-Boot variants does not offer the variable storage, so I need a sort of own hack/method to switch OS.

 

So for the M5, I would boot with Armbian from SD-card, then wipe all (boot) areas from all devices and use a manual method to flash the Armbian U-Boot to SPI-flash. That is different from what is done in the other topic as there a combination of sda and sdb is used and also is in the UFS install script for the M5. But also SPI install method is there. It is in /usr/lib/u-boot/platform_install.sh 

The file for SPI is then /usr/lib/linux-u-boot-current-nanopi-m5/u-boot-rockchip-spi.bin
and command would be: flashcp -v -p --erase-all /usr/lib/linux-u-boot-current-nanopi-m5/u-boot-rockchip-spi.bin

 

BUT I do not own an M5, so it is just based on what I did last week for my ROCK3A a few times with own build U-Boot (with Armbian build framework) and using also various kernels. Everything related to M5 fails for me as I do this trials in a quick container run. You need to read info and as long as it is unclear to you keep studying and/or wait until the armbian-config tool helps you doing it correctly.

 

You are correct that the script in the other topic is mainly an issue about wanting Btrfs for rootfs. You might not need Btrfs for root now, but having it allows you to manage the installation (so Armbian in this case) and especially the sizes of the block devices/partitions all to be done in the running system. That saves you from quite some boot time issues, as for example you don't need another temporary OS/system to boot with, like it is known as 'Live-CD-ROM' for PC's for example. Also saves money as you can fit a lot more on 1 fast UFS or NVME etc. I use it on all computers, even decade old RaspberryPi1, so can do upgrades etc from my desk or while traveling by train remotely, SD-card just stays inserted and also board is kept powered on via PoE as it is outside in difficult place and might be bad weather.