Oh, now I see. I always had the serial console attached while kwbooting. This is what made the copy of the boot image so slow. Now I tried with console detached and the upload works.
2 Likes
@mbehun Ok, progress. Now I can boot into U-boot. With 2022 U-Boot, the bootloader cannot read the mSATA drive because of Don't get my Turris Omnia to boot from mSATA SSD . With 2015 U-Boot, the bootloader can read it, but obviously it can’t boot from it because the devicetree and other stuff already expects new U-Boot. What are the next steps? I’ll start looking for an mSATA-USB converter to repartition the SSD and use the workaround from the referenced post, but I’d rather get it working with my current partition setup.
@mbehun: EDIT, got it working. The BTRFS load error mentioned in my previous post can be resolved by slightly enlarging the boot partition.
My previous partitioning was:
/dev/sda1 : start= 2048, size= 33554432, type=83
/dev/sda2 : start= 33556480, size= 188743680, type=83
/dev/sda3 : start= 222300160, size= 12141488, type=83
With this partitioning, Omnia could not boot from the mSATA SSD.
I’ve enlarged the boot partition by 4096 sectors and recreated/moved the other partitions to fit and now I can boot flawlessly:
/dev/sda1 : start= 2048, size= 33558529, type=83
/dev/sda2 : start= 33562624, size= 188743681, type=83
/dev/sda3 : start= 222308352, size= 12133296, type=83
If you don’t want to use an mSATA->USB converter for this, it can be done from emergency mode (7-LEDs). First, make sure you have the new UBoot (2022) flashed to NOR. With that in place, the 7-LED emergency mode works (yaaaay, finally my IGG omnia with SSD boot can use the life-saving buttons again). In the emergency mode, use fdisk to repartition the boot drive. FIRST BACK UP THE WHOLE DRIVE!!!, or at least the partition table (first 2048 sectors) and the boot partition (/dev/sda1). You can e.g. connect a USB drive with medkit, boot from the USB and do the backup from there. With backups ready, just delete all partitions in fdisk and recreate them again, giving size 4096 sectors larger than was before. The first partition’s filesystem will work out of the box. If you had some data on the other partitions and you don’t want to lose them, you’ll have to somehow move them to the right and shrink the last partition. I did not have anything valuable on these partitions (swap and backups), so I just trashed them.
With BTRFS from SSD booting, I’ve tried the new MCU goodies, but to no avail. The MCU firmware was still the old one (even though I had the new package list enabled and installation finished without issues). Manually installing omnia-mcutool and running omnia-mcutool --upgrade finally gave me the new firmware. Gamma correction works, poweroff works, wakeup works.
To sum up my experience with 2015 Omnia with dead eMMC, booting from mSATA SSD configured according to the old tutorial:
- Installation of the “Latest firmware” package list went without issues and took ~4 minutes to finish.
- After reboot, the router did not even reach U-Boot. How could this happen? Was the NOR flashed wrongly?
- After manually flashing the 2022 U-Boot to NOR, I got the the U-Boot menu, but it could not boot from the SSD. This was due to Don't get my Turris Omnia to boot from mSATA SSD . It seems something needs to be fixed so that all partition layouts are valid. That something is most probably U-Boot BTRFS implementation.
- After getting a bootable system, the MCU firmware was still old. What is supposed to do the actual MCU firmware update? Is the the install of the package list itself, or was there a cron job for it or what?
- After manual update of the MCU firmware, all works well
(EDIT: except wifi, see my later post). - As a present, rescue modes via n-LED reset work again even with the SSD boot. This was not possible before with the old U-Boot. Yay!
The bold parts are things Turris Team needs to resolve before launching this update into the wild (eh, HBS).
5 Likes
ah another update to LEDs ? thats good reminder for me to disable autoupdate of my omnia during christmas. Honestly i dont see the point…
3 Likes
Oh, the update changed Wifi PCI addresses! So after finishing the update of my 2015 Omnia as described above, I had no wifi at all!
New paths:
config wifi-device 'radio0'
option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:01:00.0'
config wifi-device 'radio1'
option path 'soc/soc:pcie/pci0000:00/0000:00:03.0/0000:02:00.0'
Old paths:
config wifi-device 'radio0'
option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:02:00.0'
config wifi-device 'radio1'
option path 'soc/soc:pcie/pci0000:00/0000:00:03.0/0000:03:00.0'
The update also tried some weird (migration?) stuff, but unsuccessfully. It has added the following sections to /etc/config/wireless:
config wifi-device 'radio3'
option type 'mac80211'
option path 'soc/soc:pcie/pci0000:00/0000:00:02.0/0000:01:00.0'
option channel '36'
option band '5g'
option htmode 'VHT80'
option disabled '1'
config wifi-iface 'default_radio3'
option device 'radio3'
option network 'lan'
option mode 'ap'
option ssid 'Turris'
option encryption 'none'
It seems radio3 address was a correctly updated one, but the update did not figure out that I already had that card configured as radio0. (from before, I also had a deactivated and almost empty radio2 interface that was a leftover of swapping the wifi card to another slot).
Reset of wifi fixed the issue, but this is definitely another thing that can’t get into HBS. If support is interested, I can provide the schnapps diffs. But I’ve described most of the issues in this post.
6 Likes
For many years, TOS updates have brought a peaceful and quiet Christmas into our homes. Please release it on time. I think TOS 6.5 will take its place of honor here.
Otherwise, I’m looking forward to a secure u-boot update. Owners of the original Turris Omnia have been waiting for it for years, and I think there have been a number of interesting threads on the subject.
1 Like
Some could not bear the suspense:
root@turris:~# strings /dev/mtd0 | grep 'U-Boot 20'
U-Boot 2022.10-rc4-OpenWrt-r16653+119-44ce70f0e2 (Sep 15 2022 - 18:21:35 +0000)
and went and updated by hand 
(this is on a crowdfunded omnia)
P.S.: I think I was poked to update by a thread about this topic you had started before
3 Likes
Here comes RC2 of Turris OS 6.5. One minor but long awaited change is switching to upstream packaging of lighhtpd, that we finally got to do. It is the same version and over the years we got with our configuration really close, so we beleive it shouldn’t cause any issues. Apart from that and kernel updates, new RC brings more things to experiment with. As with firmware update, those things are optional and experimental, so you don’t have to install them, but if you get bored over the Christmas, you have few toys ready. Speaking of firmware-upgrade, we split it into several options, so you can choose how adventurous do you feel. Safest one is updating factory system, the most risky one is U-Boot update.
Other new features includes Bird integration into LuCI. It is something we are experimenting with and the goal is not to have a full administration interface for Bird, but easy setup of few most common and interesting configurations. And it is the first version, our Bird colleagues have a long list of features that we are still missing, but we want to let you play with it and collect more feedback.
We also prepared experimental Knot Resolver 6 package, so you can help our colleagues to test it in the wild. Configuration changed quite a lot, so if you have some custom settings outside of reForis, it might need manual adjustment.
What I lest out from the first post is full changelog, so here it is now and it is probably the final one:
New Features
• pkglist: Add option to update the firmware to the latest version
• kernel: Support for new features in MCU firmware
• kernel: Turris 1.x is now using 5.15 kernel
• ipv6: Little tweaks to the default configuration (does not affect existing networks)
• ipv6: Support pref64 (RFC 8781)
• easycwmp: Improve integration - fix Wi-Fi information and serial number/software version getters
• easybird: Support for simple Bird configuration in LuCI
• knot-resolver6: Preview of Knot Resolver 6 available for testing
Updates
• kernel: Updated to version 5.15.142
Bug Fixes
• modem-manager-autosetup: Detect and don’t break 3G setups
• mwan3: Enable configuration by default
• foris-controller-openvpn: Fix configuration when when router is both VPN server and client
3 Likes
6.5.0 RC1 → 6.5.0 RC2 update ok (no new problems introduced), no unintended cable/wifi or internet downtime. Restart needed.
Turris Omnia 2017, 1 GB RAM, dead eMMC, system running from mSATA SSD, original wifi cards. Storage plugin enabled, LXC containers, tor relay, USB HDD shared over samba4 and minidlna, SQM, Hardwario gateway + MQTT IoT bridge, OpenVPN, PPtP VPN, morce.
I’ve enabled the kresd6 package and it seems to be running fine. However, I don’t see any supervisord process in htop. So does kresd run in some other way in TOS? (is that related to the notice in package lists “Currently without manager module”?)
And where is the YAML config? I don’t see this file referenced from /etc/config/resolver, so does it mean kresd just reads the default path /etc/knot-resolver/config.yaml? My old /etc/kresd/custom.conf still seems to get included in the final config used by kresd.
Also, kresctl is not installed (again, is it because manager is not yet present)?
How should I understand this?
Does the top-level checkbox mean all three subitems are enabled? When I explicitly checked them, it resulted in no updater action.
So thats why the wakeup option was not working for me. I will check it out again.
Yes, for now we are including just a binary. Old way of configuration still works similarly to the old way, although some modules are completely different - like the policy module and the configuration is bound to break at some moment. This is an early demo, we plan to package the rest of the tools as well, it will just take some time. But we wanted to release it early for some preliminary testing.
Top level checkbox allows you to enable the lower ones, and only enabling the lower ones will actually do something. The top level checkbox installs the script that handles those updates, lower level ones enables the functionality and installs relevant dependencies. For Factory update, you have all dependencies in the base system already. For U-Boot and MCU, it will install some dependencies. Apart from that, all those checks/updates are run after update. So if you have Latest firmware enabled already and enable only Factory image, it wouldn’t do anything till the next update. Seems like I should describe how it works in our documentation.
1 Like
It was there since first RC, but it wasn’t available in 6.4
I did check the (only) checkbox on RC1 and this is what I had after updating to RC2. But as I said, checking the 3 boxes after update did not result in any updater action. So if the sub-items would lead to installing dependencies, the updater should have uninstalled them during the update, and install them back once I checked the boxes. But this did not happen. Anyways, this is probably a non-issue as it only affects people who had RC1 installed, which is probably not too many.
And where is TOS 8 please?
And what about the YAML configs? Can they already be used?
Strange issue on MOX once Latest firmware enabled
Updater execution failed:
INFO:Target Turris OS: 6.5.0
line not found
line not found
line not found
line not found
line not found
ERROR:
inconsistent: Requested package omnia-mcu-firmware that is not available.
Better then bricked router.
3 Likes
inconsistent: Requested package omnia-mcu-firmware that is not available.
Weird… MOX shouldn’t need that…
Not yet. We need to properly package the manager for that.
1 Like
I concur, will look into that.
1 Like
As most people would have guessed, not in 6.5 rc
7 Likes