Turris Omnia- Brick Help

I have a bricked Turris Omnia. It was exhibiting hardware issues that were not consistent. I had put in a help request weeks ago but never got anything back. It got bad enough that I used another router hoping to get some support. Anyway, I had factory reset a couple of times but the wi-fi would continue to drop and even disappear.

I downloaded the omnia-medkit-latest.tar.gz and decided to see if I could help it with a firmware update, or really a clean installation. I followed the directions and watched the Youtube video. It resulted in a unit that would not allow any connections and no longer showed LAN cable connected on any port!

I did some more Googling and found directions for one that the thumbdrive needed to be formatted to ext4. Ok, did that. Now the LEDs are all flashing blue, all the time.

Is this recoverable? If so, how?

Thank you.

Best bet for troubleshooting is perhaps through UART serial cable/console https://docs.turris.cz/hw/serial/#turris-omnia to discover what goes wrong, unless you got an Omnia 2019 and newer (board revision CZ11NIC23) which supports https://docs.turris.cz/hw/omnia/rescue_modes/#unsecure-ssh-on-19216811

Thanks. My Omnia is indeed newer. I got it in January of 2020. I’ll try and follow the information in the link…

So nothing but getting the 5 LEDs works. I’m in a shell but now what? I’ve run schnapps and attempted to list the btrfs snapshots. I get:

ERROR: not a valid btrfs filesystem: /

ls: /mnt/.snapshots/*.info: No such file or directory

Help?

Indicates that either filesystem or the partition table for the eMMC drive is probably corrupted.

If you want to investigate further you could use the tools provided through the rescue shell.

If instead you prefer a fast path to just recovery of the device into an operational state you could try https://docs.turris.cz/hw/omnia/rescue_modes/#flash-from-the-internet, just mind

To use this mode, you need to plug your Turris Omnia to a network where it can get internet connection using DHCP.

Thanks @anon82920800. I have tried that. I have also downloaded the omnia-medkit-latest.tar.gz and attempted to re-flash. It always ends up with all LEDs flashing blue.

Is it possible that I have a bad eMMC drive? What can I ‘investigate further’ from the shell in this state?

That is one possibility, could be also some other component malfunctioning.


To really investigate it would require

As for the rescue shell and checking on the eMMC there is this thread eMMC is broken? that might provide some help, basically:

  • check the eMMC partition table with what the fdisk tool provides
  • try formatting the OS partition with mkfs.btrfs -f /dev/mmcblk0p1
  • use the btrfs tool (if available) to check the filesystem
  • there might also the mmc tool available

Another way to go about, if the issue is caused by the eMMC, is to deploy the OS from

As far as I know

The partition didn’t report any errors. I went ahead an reformatted the the partition with the btrfs command:

mkfs.btrfs -f /dev/mmcblk0p1

No errors. finished with:

ID 1
SIZE 7.28GiB
PATH /dev/mmcblk0p1

I then tried to re-flash the unit with a thumbdrive. It went back to flashing all blue LEDs.

I have another router in place right now. I’ve attempted to do an internet flash by hooking an ethernet cable from the WAN port to my temporary router. Is there anything I’m missing here? It just won’t re-install. It seems to take about 10 seconds before all LEDs start flashing blue non-stop.

What does the flashing indicate?

I’ve used a lot of Linux (since kernel .82). It seems the bootloader is not functioning. It always returns to a the power and PCI2 LEDs solid and nothing more.

Flashing patterns


Without logs for the 4- | 6-LED flash modes it is not possible to say - I know it is repetitive but

Common mishap for 4-LED not working is faulty USB drive and/or incorrect formatting of the USB drive, e.g.

Cannot say for the 6-LED method since being a recent introduction and currently only available for that specific board revision.


Which could explain the matter.

There could be three potential issues with u-boot

  1. the environmental variables got somehow borked - which you could try to reset to default through the 5-LED ssh connection with
    fw_setenv bootcmd 'env default -f -a; saveenv; reset'
    and then try the 4-LED medkit again.
  2. u-boot image got corrupted, though it seems unlikely since the u-boot rescue shell works apparently. It would be recoverable https://docs.turris.cz/hw/omnia/serial-boot/ but requires UART serial cable/console. Also the u-boot image that shipped with your board does not seem available for public download - only the older version which would work with your board but lacking those 5- | 6-LED modes
  3. MTD partition table is corrupted, though it seems unlikely since the u-boot rescue shell works

found it? I’ve had the case off twice since purchasing. Once to verify the antennae leads were connected correctly when I reached out to support, the second today…


Scratch my previous thought about this being board susbtrate. After carefully removing material, it appears to be some other foreign material. I have found a few other smaller pieces in the case (flecks really).

I am reaching out for a unit replacement.

So, while I wait for the powers to decide my fate, I’ve reconnected the unsecure ssh. I have been looking around a bit more. It seems that the partition table is boinked for a boot partition.

Disk /dev/mmcblk0boot1 doesn't contain a valid partition table
Disk /dev/mmcblk0boot0: 4 MB, 4194304 bytes, 8192 sectors...

Seeing if I can find the correct partition information to reformat…

Does not look healthy. The curious thing is that on other board revisions those devices are not showing as partitions (cat -A /proc/partitions | fdisk -l) but as disks instead, e.g.

lsblk -o +size,phy-sec,log-sec /dev/mmcblk0boot1

NAME         MAJ:MIN RM SIZE RO TYPE MOUNTPOINT SIZE PHY-SEC LOG-SEC
mmcblk0boot1 179:16   0   4M  1 disk              4M     512     512

And there is some other oddity, least I would have expected /dev/mmcblk0boot1 correlating with /dev/mtd1

cat -A /proc/mtd

dev:    size   erasesize  name$
mtd0: 00100000 00010000 "U-Boot"$
mtd1: 00700000 00010000 "Rescue system"$

but maybe that has changed between board revisions or is otherwise somehow inverted.


Only what fdisk provides on this board

Disk /dev/mmcblk0boot0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x31aed529

:warning: At own risk and note sure whether it works (or solves the matter); you could try with fdisk to repair the partition table for /dev/mmcblk0boot1. It may or may not render the u-boot image inaccessible, if so it would require re-flashing the image which comes with caveats:

vs. https://docs.turris.cz/hw/omnia/serial-boot/#nor-recovery

Make sure you don’t mix old U-Boot with new rescue system or new U-Boot with old Turris OS, it might not work, try to keep everything on the latest version if you are reflashing.

Therefore it would probably best practise to backup the u-boot image first with the du tool as mentioned here https://openwrt.org/docs/guide-user/installation/generic.backup, which though would require that rescue shell provides access to the MTD partitions (not sure it does), perhaps try/see with mount tool. If not perhaps the sf and/or sspi tool(s) may provide such functionality (never tried my end).

For the storing/restoring the image backup you would need to mount the /dev/mmcblk0p1 partition.

Also the image restoring part does not seem trivial with the sf tool since the mtd tool/command may not be available through the rescue shell.

@anon82920800- after reading through your post and links, I’ve reconsidered diving in. I reached out to support and the reseller here.

I’d rather not totally brick the hardware. If I am directed by support, I’ll follow through.

Thank you for sharing your knowledge.