I have done the migration yesterday. A useful note: If you use dd to copy eMMC to mSATA, you need to run btrfstune -u /dev/sda1 before any mounting tentative or reboot. Else the system will get confused of the same BTRFS UUID on both partitions and you will be unable to change anything.
An additional note: I did not had any change to do to the /etc/config/wireless file as it was not specifying hardware paths (I am using latest Turris OS 4.0 beta).
Your scripts donât include the âsaveenvâ & âbootâ commands like on the official docs. Will the commands in the scripts persist then?
The docs also write to issue those commands for disc preparation, should those commands issued after fw_setenv?
echo s > /proc/sysrq-trigger
echo b > /proc/sysrq-trigger
How are these commands different from just typing ârebootâ? Sorry for beeing quite a noob in this regards but my btrfs already failed once on eMMC and want to prevent eMMC from completely wearing out
Saveenv is called by fw_setenv at end. So if you set each variable individually, environment is rewritten 3 times. Batch mode (provided script) sets all 3 variables at once, then environment is written to chip once and thatâs all.
Boot is not required - weâre not in U-boot command line. System is up and running.
Disc preparation is still required. You need to prepare new disk to have working system on it.
I do not know whatâs the difference between reboot and triggering /proc/sysrq-trigger.
Both works for me.
I see. But another question, is there a possibility to verify current eMMC settings with fw_printenv? It reports for me bad crc and prints some nonsense values. You wrote that you got the values from there and I wonder especially if âroot=b301â is the same on all HW versions of turris omnia. Therefore I wanted to actually print my env to know what to put there in case I need to go back (which would require a cable then of course if booting fails) or will uboot commands âenv default -aâ and âsaveenvâ in uboot cli also reset everythint back to booting from eMMC?
Default environment is empty.
Then U-boot uses hardcoded variables, but does not shows them.
If You want to get output from fw_printenv You need to reset U-boot envoronment via serial cable.
@n8ver says, it is possible to reset variables via fw_setenv, but I cannot confirm this - have never tested that approach.
If You have serial cable - You can reset to defaults via mentioned commands. That was tested:)
It was not me really
Nonetheless, fw_printenv only works properly via UART serial
I cannot find the commit right now but at least TOS5.x ships with /etc/fw_env.config (this is for TO only! Not T 1.x or Mox!).
cat /etc/fw_env.config
/dev/mtd0 0xC0000 0x10000 0x40000
and fw_printenv works also via ssh then
Ok, I tried setting the uboot values today to the ones the would boot from ssd through fw_setenv ssd script values posted above and rebooted. Unfortunately the TO didnât boot. Stuck in only 2 leds blinking. So to regain internet I grabbed my mobile and searched all throughout the nearby city for a serial cable and luckily I found one.
So I connected it and output was
U-Boot 2015.10-rc2 (Aug 18 2016 - 20:43:35 +0200), Build: jenkins-omnia-master-23
SoC: MV88F6820-A0
Watchdog enabled
I2C: ready
SPI: ready
DRAM: 2 GiB (ECC not enabled)
Enabling Armada 385 watchdog.
Disabling MCU startup watchdog.
Regdomain set to **
MMC: mv_sdh: 0
SF: Detected S25FL164K with page size 256 Bytes, erase size 64 KiB, total 8 MiB
PCI:
00:01.0 - 168c:0040 - Network controller
PCI:
01:00.0 - 11ab:6820 - Memory controller
01:01.0 - 168c:002e - Network controller
Model: Marvell Armada 385 GP
Board: Turris Omnia SN: 0000000B0000F2FD
Regdomain set to **
SCSI: MVEBU SATA INIT
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs
Net: neta2
Hit any key to stop autoboot: 0
Setting bus to 1
BOOT eMMC FS
scanning bus for devicesâŠ
Device 0: (0:0) Vendor: ATA Prod.: KINGSTON SMS200S Rev: 60AA
Type: Hard Disk
Capacity: 114473.4 MB = 111.7 GB (234441648 x 512)
Found 1 device(s).
BtrFS init: Max node or leaf size 16384
2822912 bytes read in 161 ms (16.7 MiB/s)
BtrFS init: Max node or leaf size 16384
17306 bytes read in 71 ms (237.3 KiB/s)
Kernel image @ 0x1000000 [ 0x000000 - 0x2b1300 ]Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Device Tree to 7fb3f000, end 7fb46399 ⊠OKStarting kernel âŠ
So it was stuck loading the kernel. I then restored emmc values with âenv default -f -aâ & âsaveenvâ and it came back to life.
I then again checked if the /boot directory was ok and did contain a valid zImage but all was fine. So I did it by the book as described in the docs from turris guys and again went into uBoot prompt and set all values line by line as itâs printed in the docs.
Rebooted and all of a sudden it was working.
So something wasnât okay when trying to use fw_setenv -s script where script contained the 3 lines with the uBoot values as you posted it. Maybe a single char, a tab, a control character or whatever. I couldnât find out by trying to compare the docs with your lines. However copying it from this post fucked up uBoot in a way that it wasnât able to load the kernel. I still have no clue why but it did.
Ok. I think that saveenv is the key.
I asumed that non-defined variables would be taken from defaults, but it looks that is does not work that way.
So there may be two approaches:
In both cases, having serial cable somewhere around is not a bad idea.
Setting bus to 1
BOOT eMMC FS
scanning bus for devicesâŠ
Device 0: (0:0) Vendor: ATA Prod.: Samsung SSD 860 Rev: RVT4
Type: Hard Disk
Capacity: 953869.7 MB = 931.5 GB (1953525168 x 512)
Found 1 device(s).
btrfs probe failed
** Unrecognized filesystem type **
btrfs probe failed
** Unrecognized filesystem type **
Kernel image @ 0x1000000 [ 0x000000 - 0x689b30 ]
Flattened Device Tree blob at 02000000
Booting using the fdt blob at 0x2000000
Loading Device Tree to 0fff8000, end 0ffff83c ⊠OKStarting kernel âŠ
The SSD and its various btrfs partitions are working just peachy otherwise, no defects with various inspection tools.
What I could think of why it does not work:
Reading this somwhat would indicate this being a problem, albeit it refers to mounting the OS image file and not booting itself
Yep, currently there is no proper GPT disk support.
Whilst u-boot source code supports GPT (probably since around 2012) it seems that downstream OpenWrt sadly does not and thus booting from GPT disk does not work - it would have been helpful if such would be mentioned in the Turris KB article.
is it possible to use SSD (NAS perk - using sata controller or what was that) instead of mSATA/USB for system? in the documentation are only 2 options ⊠mSATA or USB 
Hi there:
I have the system on a mSATA disk and I would like to upgrade my turris from 3.11 to 5.0 branch. I already created a medkit using schnapps but Iâm worried that something fails after the update.
Anyone knows if after the update u-boot must be reconfigured to use external storage?
My recommendation is donât try to update it using automatic upgrade. my sata installation wasnât booting anymore after the upgrade because the switch was not properly initialized and so no network was accessible and so far nobody actually posted a solution. You could try a fresh installation maybe that works but have a serial cable ready in case it fails. The downside of trying a fresh installation is that you cannot go back. When you try to upgrade your installation you can always use schnapps to go back to 3.11 through serial cable.
Thank you for your reply!
Finally I took your advice and did a fresh installation. I did also a medkit of the 3.11 version in case I need to revert the changes but until now everything is working great.
I did the same as well meanwhile. A fresh installation of a medkit on mSATA works as expected, I think you can take any medkit no matter if itâs 3.11 or 5.1.x however I didnât try creating one one emmc and restore it on mSATA.
But the automatic in-place update however kills the mSATA installation I tried it 3 times where I did some cleanups in-between like removing VLANs, special network interfaces but not luck. The switch (4-ports) was never properly initialized and network was down. It seems the in-place update works for eMMC but not on mSATA.
I (more or less) successfully migrated 3->5 inplace with a system on mSATA (on pre-2019 Omnia). At least the switch config migration worked for me, all LAN and WAN interfaces instantly working.
Thatâs so weird. So for some people it works for others it doesnât. I also have a pre-2019 Omnia. Actually a very old one from the crowdfunding campaign.
I read that a u-boot upgrade will be deployed in the future for our routers, keep an eye to changelogs because when it occurs we will need to tweak it to boot again from the ssd.
I also discovered in the upgrade process (because I attached the serial adapter) that sometimes the router refuses to boot (but it resets after 1 or 2 minutes) and the uboot gives the following error:
Run_alg: tuning failed 0
DDR3 run algorithm - FAILED 0x1
DDR3 Training Sequence - FAILED
I contacted tech support and told me that this is a known issue that they are trying to fix with the help of dram manufacturer. So if anyone gets this error donât worry: there is nothing wrong with your hardware.
Thatâs why I delayed the installation of upgrades for 2 days. Hopefully after 2 days we have the new instructions on how to boot again from msata after u-boot upgrade. About the DRAM issue - never noticed this but usually I donât boot with serial attached and I also donât reboot the router that often as itâs very stable. And I also keep regularly created schnapps medkit files which are exported to USB & synced via SSH. So I should be safe even when I would have to go back for emmc for some days. But I will keep an eye on this thread. I think I also read somehwere that with new u-boot you cannot do a ârun rescuebootâ anymore. The commands are different to get into failsafe mode.