Installation failed on eMMC Odroid H4+

TrueNAS General
,
1

Hi

I’m trying to install TrueNAS EE on Odroid H4+ on eMMC (256GB).
This is a fresh installation - new hardware.
I’m getting error:

Failed to find partition number 2 on mmcblk0

Anyone know how to proceed with TrueNAS installation?

3 Likes
2

Hey @mykindofit

I’ll have to go digging for the other time I saw this happen, but if I recall correctly the mmcblkN devices on the ODROID hardware present the same unique identifiers.

Are you getting this error during install, or post-install on first boot?

3

This is the error I’m getting during the install.

4

Have you found solution to this?
I am having the same issue.

5

I had the same issue with 24.10. I downloaded 24.04 and it installed. I upgraded the the latest 24.04 and then to 24.10. So far so good.

1 Like
6

Thanks God found this thread, had the same issue, did the same sequence installed Dragonfish version first 24.04 without error message and later updated to latest 24.10

8

Sorry for reviving this topic, but I wanted to clarify which version of 24 you used to install on the eMMC drive. Since 24.04 has several variants, do you think using 24.04.2.5 will work, or should I opt for 24.04.0 instead?

9

Also if you don’t mind, how big is the emmc module and did you created a swap partition when installing TN, I’m thinking in getting one pretty soon

10

Stumbled on the same error during installation on TrueNAS 25.04 on GMKTec NucBox G9 NAS.
It turned out that the error was due to the boot partitions mmcblk0boot0 and mmcblk0boot1 switched into read-only mode.
I fixed the issue by following the recipe in kernel org note mmc-dev-parts.txt

In the boot menu select shell

List your block devices

$ lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
...
mmcblk0      179:0    0 58.2G  0 disk 
├─mmcblk0p1  179:1    0    1M  0 part 
├─mmcblk0p2  179:2    0  512M  0 part 
└─mmcblk0p3  179:3    0 57.7G  0 part 
mmcblk0boot0 179:256  0    4M  1 disk 
mmcblk0boot1 179:512  0    4M  1 disk 
...

Disable read-only access

$ echo 0 > /sys/block/mmcblk0boot0/force_ro
$ echo 0 > /sys/block/mmcblk0boot1/force_ro

then restart and run the installation once again.

2 Likes
11

I tried the above and did not work for me using the same hardware and software. Also tried ElectricEel-24.10.2.1 which eventually worked by repeating the install process (and subsequent failures) for 10 or 11 attempts. Found this links which assisted in the eventual success:

I tried all the “workarounds” listed, but after a few attempts on #1, didn’t think much of it… After many attempts #2 gave up and went to #3 and still nothing. Something in my brain said try #1 again MORE than 10 times and the it worked - go figure…

FYI in workaround #2, you need to remove certain SPACES from the command:
Was:

sgdisk -a 4096 -n 1:0:+1024K   -t 1:EF02 -A 1:set:2 /dev/mmcblk0

Should be:

sgdisk -a4096 -n1:0:+1024K   -t1:EF02 -A1:set:2 /dev/mmcblk0

soz - could not find a way to advise the OP of the link through the Atlassian site…

1 Like
12

TL;DR: Look at the “Workaround” section at the bottom.

I think I have figured out the cause of the problem and a reliable workaround thanks to the previous research by

  • Oleksandr Liutyi, author of
  • @seekee (with finding the post of Liutyi), and
  • @dameb10129 (with bringing my focus to the /sys/block system).

Issue

I am also running an Odroid H4+ with an eMMC (64GB) and encountered the exact same error behaviour as described by OP while trying to install TrueNAS SCALE 25.04.0

Retrying ~30 times in total and the other workarounds suggested by dameb and Liutyi did not help for me.

Investigation

During my investigation I primarily looked at the python snippet identified by Liutyi (format_disk function at truenas-installer/truenas_installer/install.py at TS-25.04.0 · truenas/truenas-installer · GitHub) and the function get_partitions called from this code site (truenas-installer/truenas_installer/utils.py at TS-25.04.0 · truenas/truenas-installer · GitHub).

From what I can tell it’s a combination of the long time it takes the new partitions to show up in /dev (which I have not observed directly but rather inferred from my knowledge of the code and the system behaviour during my debugging attempts) and the MMC boot partitions (special to eMMC devices) that evidently have not been anticipated during the implementation of the installer.

So the format_disk function looks fine - it relies on the get_partitions function to do it’s job and wait for up to 30s to find the correct partition devices - neither of which it accomplishes in this case.

The issues seem to lie in the main loop of the get_partitions function:

for _try in range(tries):
    if all((disk_partitions[i] is not None for i in disk_partitions)):
        # all partitions were found on disk
        return disk_partitions

    try:
        with os.scandir(f"/sys/block/{device}") as dir_contents:
            for partdir in filter(lambda x: x.is_dir() and x.name.startswith(device), dir_contents):
                with open(os.path.join(partdir.path, 'partition')) as f:
                    try:
                        _part = int(f.read().strip())
                        if _part in partitions:
                            # looks like {1: '/dev/sda1', 2: '/dev/nvme0n1p2'}
                            disk_partitions[_part] = f'/dev/{partdir.name}'
                    except (OSError, ValueError):
                        # OSError: [Errno 19] No such device was seen on
                        # our internal CI/CD infrastructure for reasons
                        # not understood...
                        continue
    except FileNotFoundError:
        continue

    await asyncio.sleep(1)
A short context:
  • tries is the number of retries i.e. 30
  • disk_partitions is a dictionary that is initialized as {1: None, 2: None, 3: None} in our case
    it’s supposed to end up as {1: "/dev/mmcblk0p1", 2: "/dev/mmcblk0p2", 3: "/dev/mmcblk0p3"} in our case
  • device is a string - the base device name, in our case mmcblk0
  • partitions is simply a numeric list of the partitions we are looking for - basically the keys of disk_partitions, i.e. [1,2,3]

Problems in the loop

The problem here is that for eMMCs with boot partitions there are /sys/block/mmcblkX/mmcblkXbootZ paths in addition and independent from the normal, expected /sys/block/mmcblkX/mmcblkXpY paths.
These do not have a partition file in them as the inner loop that iterates all /sys/block/mmcblkX/mmcblkX* expects!
Unfortunately the open for trying to read the /sys/.../partition file is not protected by the inner try-catch which would only skip the current /sys/block/mmcblkX/mmcblkXbootZ and eventually reach the .../mmcblkXpY paths it expects.
Instead, it is only protected by the outer try-catch which is probably intended as a catch-all in case /sys/block/mmcblkX is completely missing for whatever reason, since it rapidly completes the outer loop by skipping the await asyncio.sleep(1) statement.

So it’s semi-random, dependent on the order that os.scandir returns the directory entries (favorable case: all mmcblkXpY first, all mmcblkXbootZ later), whether the loop completes it’s mission successfully.

The fallback can’t help

There is actually backup code path should the loop fail. This one scans the /dev directory instead of looking in /sys/....
Though from analyzing the code it seems that this one would also get confused by the /dev/mmcblkXbootZ entries and even misidentify them as the /dev/mmcblkXpY it’s actually looking for, in case Z and Y are the same, which is the case on my system for boot1 and p1.
Also due to the missing sleep statements in the prior loop it seems that /dev is not populated by the time this code path is reached.

Conclusion

To resolve this issue permanently, changes to the installer seem to be unavoidable.

Fixing the installer

Since I am not familiar with the code base and my knowledge of Linux internals is very limited, my suggestions will stay vague.

A fix might include:

  • Making sure that the sleep interval between retries is respected even when exceptions occur
  • Making sure that all the paths /sys/block/{device_name}/{device_name}* are traversed even if some do not behave as expected
  • Potentially: Explicit handling for eMMC by skipping boot partitions (and maybe other device partitions if they exist)

Workaround

For now I have found a workaround that allowed me to install TrueNAS successfully:

  1. Open the Shell in the installer

  2. Patch /lib/python3/dist-packages/truenas_installer/utils.py by:

    moving the line await asyncio.sleep(1) right beneath for _try in range(tries):

  3. Hide the /dev/mmcblk0boot* devices that confuse the “last resort” path of the installer by:

    running rm -f /dev/mmcblk0boot0 and rm -f /dev/mmcblk0boot1

  4. exit the shell and run the installer as normal (without rebooting in between)

3 Likes
13

I just created an account to tell you how I solved it.

I just ran a dd if=/dev/zero of=/dev/mmcblk0 count=1024

That wiped out the emmc partition table and then the installer worked fine.

9 Likes
15

Pretty slick. Benigne, Magnus

16

It worked great, @magnus919

Trying to install 25.04 found the same problem.

Thanks.

18

This also worked for me on Bee-Link Me Mini. Thanks!

19

Worked perfectly on my GMK G9 nas thanks, only thing I would add is after going to open and shell and typing in that command and hit escape and back to installing Truenas it came back with that same error message, so I restarted my system and this time going through the normal install set up no errors at all.

20

This does actually work but the instructions are slightly wrong. The read-only parameter is not persisted, meaning that when you restart the device will be read-only again.

If you came from the “shell” menu item in the installer, simply hit ctrl-alt-f6 after executing the two echo echo commands instead of restarting. This will bring you back the installer and you can continue from there.

1 Like
21

I’m running on this same issue (on a UGreen DXP2800). It seems like such a waste for me to install TrueNAS in a decent size M.2 Nvme drive, when you can’t use any of the remaining space (most of my 1TB drive) for anything storage-related, and I’m taking up one of two M.2 drives with the OS, when I could be using that for more much-needed storage or caching/etc (esp. on a small 2-bay DXP2800), etc.

It is really a bad idea to use the internal 32GB eMMC included (mmcblk0) the TrueNAS OS drive? IIUC the OS stores its config data on the storage pool anyway no? So should the eMMC drive fail, I can always reinstall the OS on one of the M.2 drives and carry on like normal? Or would I need something from the eMMC to restore TrueNAS?

22

Maybe a workaround someone suggested if anyone is getting any emmc installation errors with truenas, simply install an earlier version (24.04 think its called dragon) its mentioned here

You can then hit training section and upgrade to latest version, just remember the username is just admin on this version of truenas, and then your password as normal.

Not sure if it will help or not but worth a long shot try, it worked for my emmc installation.

23

The eMMC is not very durable so it will fail earlier than an SSD. Which I think you already know.

As far as I know, this is not the case. If your OS drive does you lose your config with it. You don’t lose any data, but you will have to resetup truenas from scratch.

You would need the config from the eMMC to carry on like normal. In order to backup your config there are a couple of ways to do it. The official way is to use TrueCommand. The perhaps better solution for most people running 1 machine at home is to use Multi-Report written by joeschmuck. It has the ability to email you your config so you can reinstall if needed.

1 Like