Hi, everyone! Oh, well… I somehow managed to get my Omnia into such a state none of the reset modes work (not even the rescue shell). I obviously tried reflashing with the latest medkit image, but it didn’t work. However I try to reset it, the result is the same: only the power and pci2 leds come up, the WAN led flashes inconsistently and I have no access to the router (all LAN leds are off). Any ideas/suggestions? Thanks in advance!
Do you have a TTL serial cable to get to the console? That might be your best bet.
Yeah, that will be my course of action. I don’t have a TTL serial cable yet because I wasn’t really expecting to be able to brick the router… I guess now I’ll get both serial and JTAG cables. 
Hello,
Can I know if you had any LXC containers on eMMC? Did you try the latest medkit, when the USB flash stick is formatted to ext2/3/4?
Anyway, the output from serial console will tell us more.
Hi, Pepe! No, I have never used LXC at all. I tried the latest stable medkit on a flash stick formatted to fat32, ext2 and ext4, without success. This problem happened when I tried installing the vanilla OpenWrt snapshot (21st April) on one of my Omnias (not the “production” one, fortunately). After digging in the source, I see the installer makes some changes to the uboot environment, so that’s a smoking gun right there. I already ordered the serial cable, but it will take a couple of weeks to arrive. Meanwhile, I remembered I have an RPi lying around, I’ll see if I can persuade it to talk to the Omnia’s bootloader and reset the configuration. Hopefully afterwards I’ll be able to flash the medkit just fine. 
I also used the latest vanilla openwrt medkit to flash the router to openwrt per the instructions noted at point 1: https://github.com/openwrt/openwrt/commit/9f3f61a0d968fbe7b93899f948f3c34612683ba6
However, afterwards the router won’t boot. Serial console says:
Wrong image format for bootm command
Error: can't get kernel image!
Maybe it has something to do with btrfs?
Thanks to the link to the commit from @rsalvaterra I tried the command run mmcboot.
This command tries to boot the OpenWRT kernel from the address 0x01000000 - 0x02000000 but it hangs on Starting kernel and then just reboots.
Trying to re-flash the original medkit won’t work: the 4 LED method also hangs on the Error: can't get kernel image!
Little too fast. Of course you’ll always find the answer right after posting your question.
First reset uBoot (removing the OpenWRT customizations) with:
env default -a
saveenv
Afterwards the recovery (4 LED method) is working again because the addresses point to the rescue kernel now.
I am still curious how to flash OpenWRT…
1 Like
Did you figure it out? I just flashed OpenWRT today.
You can follow the instructions here:
I used these openwrt snapshot files: (the TO is not yet supported in a stable release)
https://downloads.openwrt.org/snapshots/targets/mvebu/cortexa9/omnia-medkit-openwrt-mvebu-cortexa9-turris-omnia-initramfs.tar.gz
The only caveat is that this medkit does not have the vfat module included, which means you won’t be able to mount a fat32 formated usb stick in the medkit environment in order to copy over the sysupgrade file. I would either format the usb stick with ext4, or better yet just scp the sysupgrade file across:
scp openwrt-mvebu-cortexa9-turris-omnia-sysupgrade.img.gz root@192.168.1.1:/tmp
Let me know if you run into any issues.
1 Like
Heh. I’m still waiting for the serial cable to arrive, can you believe it? Oh, well, that’s AliExpress for you. 
I’m not in that much of a hurry, though, since I have two routers and the “production” one is working fine (with Turris OS). Did you flash using the first method? I’d like to avoid having to set up a TFTP server, if at all possible. Thanks for the heads-up!
I used the first method. Pretty straight forward. I’m so relieved to be running stock openwrt!
Just an FYI, I’ve used this usb-serial cable to console from my Linux workstation to the Turris Omina.
1 Like
I would caution windows users against using PL2303HX/CP2012 USB/TTL cables (especially from HK/China) - FTDI would be more reliable… IMHO worth the extra cost.
I just ordered a 2nd TO because I am fed up with the problems with it due to poor S/W choices by cz.nic:
- uses a different busybox to OpenWrt/LEDE (causing problems with adblock/ddns-scripts)
- forced to use knot resolver instead of dnsmasq (e.g. no CNAMEs)
- out of date packages (e.g. nginx is v1.10, latest is v1.14)
The only thing in the TO branch of OpenWrt/LEDE I really like is btrfs (and thus snapshot support, e.g. for LXC).
Anyway, still waiting fro my 2nd TO to arrive…
This may be a thread hijack, but: how are you finding OpenWrt on TO?
No worries, I got totally rid of Windows about 10 years ago (and have been using Linux since about 1998). 
I have another PL2302 cable which works perfectly on Linux, but has a DB-9 connector (I used it to set up an APU2C4 system, also with OpenWrt), that’s why I ordered a new cable, specifically for my RPi and the Omnia.
Ha! I had an Alix back in the day! Actually, an APU2 running OpenWrt may not have been a bad idea…
I’m in the same boat you are. Some software packages were horrendously out of date. I had built a docker container to build packages that were either out of date or simply non-existent in the TO repos.
For me, I’m a minimalist at heart, and the TO simply came with too much bloat. Although, btrfs + snapshot support was a nice feature.
Openwrt runs like you would expect. The only issue I’ve run into is that some of my devices will not connect to the 5ghz radio on channel 64. I’m using the same wireless configuration I used on the TO. The solution was to bump the channel number down a bit…weird.
The APU2C4 is insanely powerful. If I needed to buy a router today, it would be my first choice.
In other news, my serial cable just arrived, so next Saturday will be fun. 
1 Like
AFAIK they don’t. They just use an old snapshot. Newer one is in development. Are you a tester yet?
They’re upstream of it. They had their reasons to use it. IMHO they respond quite well to bugs etc. You can also still use dnsmasq. FWIW I’m happy with knot.
So you packaged the latest version and sent them a git pull request?
as far I can see there are 4 resolvers in the repo - dsnmasq, bind, knot and unbound. though knot comes pre-installed (if that is the meaning of forced) this can easily be remedied.
unfortunately very true, waiting to TOS 4.0 but that seems still far out.
Regarding using dnsmasq rather than knot resolver, on this thread:
… a cz.nic person said:
Which is - in my experience - true. TO is more flaky, especially with updates, if dnsmasq is used instead of kresd. But that kresd is slower than dnsmasq and doesn’t support CNAMEs.
I’m not bitter about it, it just wasn’t what I expected when I indiegogo’d.
@justsomeguy, @anon50890781 : the real issue is that the TO version of OpenWrt fell off the mainline branch. If it was in sync with OpenWrt/LEDE, then 90% of issues we’ve discussed wouldn’t exist.
Instead of mainlining TO’s OS, they’re tweaking honeypots, and pakon, and their updater, etc.
In the meantime, ddns-scripts was causing my router to crash. It, and adblock have to be the two most popular packages on OpenWrt-based routers, and yet neither works properly:
re: adblock, I modify it thus because TO’s busybox has killall -HUP, and adblock expects kill -s HUP
sed -i '/killall/ s/killall -q -HUP/killall -q -s HUP/' /usr/bin/adblock.sh
re: ddns-scripts, I modify it thus because TO’s busybox has timer -t 2, and ddns-scripts expects timer 2
sed -i '/__RUNPROG/ s/timeout 2/timeout -t 2/' /usr/lib/ddns/dynamic_dns_functions.sh
No, I haven’t offered a pull request for TO (but I have previously for OpenWrt).