System on mSATA disk

Hi guys,

is there a way how to move the system from the internal storage onto mSATA disk? I have one Omnia in a critical place and it already died two times on me - once it was probably because there was a container running on the internal flash, but the second time there was no container and it dies anyway. Even restoring to previous snapshot did not help (unfortunately I could not debug the problem yet, as I was not personally present), but I suspect the internal flash again.
I was wondering if moving the system to mSATA would be possible as I already bought the disk for containers anyway.
Any suggestions? Anyone already done that?


p.s.- you can imagine how embarrassing it is for me when the hardware I recommended to my colleagues fails repeatedly :wink: You would not want to hear the snide remarks :slight_smile: (but I am still convinced Omnia is the best)

See official docs:

If you still have access to your Omnia you could use „schnapps export“ to create a personal medkit file (full backup of your current internal storage) that you can deploy then…

Good luck :smile:

EDIT: I never tried it but I think there are some threads in this forum about it


Great! Thanks for the quick reply and sorry that I did not find it in the docs myself (I honestly tried) .
I will try it on Friday and post my results in this thread for future reference.


I have Omnia running from mSATA.
Installation is quite simple.
You can even do this without connecting serial cable.
Just prepare drive as written in manual and use fw_setenv tool to update u-boot variables.
Afer reboot You’re running from mSATA.


Just quickly getting back - I was able to setup boot from mSATA very quickly and without a hitch.
Before that, I debugged Omnia using an UART cable and it simply got stuck at “Starting kernel” during boot-up and eventually restarting. I would guess that this was probably a sign of an eMMC problem.

1 Like

Well, now I have moved my whole system to SSD, and started to use LXC again, I am getting this warning email:

You are running container nas from internal memory which is not recommended and can severally damage your router! This is not covered by warranty! Please use storage module in Foris to move it somewhere else!

How do I get rid of it?

It is OK … the message appear only the Linux root not moved to USB external device.
Your root is moved by another way to the SSD, so the message not critical for you.

And how are you, Beda?

You should have another partition for /srv (even on the same drive).
Otherwise schnapps backup will soon fill whole drive.
I have 16GB mSata with system and LXC with mysql, that collects lots of data. And few weeks after moving system to mSata, and having LXC on root partition, I ran out of space.
I had to remove schnapps backups, create subvolume for /srv, move data and it runs without issues for another few weeks…


Can you give an example of how to use fw_setenv. It’s a bit critical to have no clear instructions especially when you don’t have serial cable at hand.

And do you know it’s nexessary to have medkit on the ssd or is it possible to use a schnapps export too? I would not like to setup everything on the turris again…

I’ve been jumping from 3.x to 4.x, so can’t tell anything about export. I have used most of config files. But You can try with export.
fw_setenv can work with barch mode - You set all variables at once.

fw_setenv -s script

Script looks like this:

bootargs earlyprintk console=ttyS0,115200 rootfstype=btrfs rootwait root=/dev/sda1 rootflags=subvol=@,commit=5 rw
bootcmd i2c dev 1; i2c read 0x2a 0x9 1 0x00FFFFF0; setexpr.b rescue *0x00FFFFF0; if test $rescue -ge 1; then echo BOOT RESCUE; run rescueboot; else echo BOOT eMMC FS; run scsiboot; fi
scsiboot setenv bootargs "$bootargs cfg80211.freg=$regdomain"; scsi scan; btrload scsi 0:1 0x01000000 boot/zImage @; btrload scsi 0:1 0x02000000 boot/dtb @; bootz 0x01000000 - 0x02000000

It should be the same for 3.x
Most important is good drive preparation. You’ll have only one shot (then You need serial cable to restore defaults and boot mmc).
After moving to ssd You can mount mmc and copy data.

What happens if the boot env gets reset to its default by a some update/upgrade?

It will boot old system from mmc.
Then You’ll have to use fw_setenv once again.
When I need to check something from 3.x branch (for example something that works in 3.x, does not in 4.x), I’m playing with U-boot variables. Effectively I have two system version installed in paralell.

In which case though it would require connectivity via UART? Or you just boot the system on eMMC, connect via W/Lan and run that script again and reboot?

No. As long, as both systems are fully functional, You can use ssh and fw_setenv with proper scripts (You can not issue “env default -a” via fw_setenv, but You can restore variables saved via fw_printenv).
I have two scripts: to switch to SSD or go back to MMC.


Afaik it is possible with with fw_setenv bootcmd 'env default -f -a; saveenv; reset'

Yo @Cabal could you post those scripts somewhere?

Someone from Turris Team said, it is not possible.
For me scripts works as expected.

SSD version is posted above (variable values come from
MMC version:

bootargs earlyprintk console=ttyS0,115200 rootfstype=btrfs rootdelay=2 root=b301 rootflags=subvol=@,commit=5 rw
bootcmd i2c dev 1; i2c read 0x2a 0x9 1 0x00FFFFF0; setexpr.b rescue *0x00FFFFF0; if test $rescue -ge 1; then echo BOOT RESCUE; run rescueboot; else echo BOOT eMMC FS; run mmcboot; fi

It comes from fw_getenv (there are more variables, but only those two needs to be restored).
fw_printenv does not print default variables unless saved, so in default You’ll have empty output.


I understand that it should be OK, I was just worried that I will get those messages each hour, learn to ignore them and the overlook it when something else goes wrong :slight_smile:

Otherwise I am fine - it could hardly be better, thanks. It is good to see that you are still active in the community :+1:

1 Like

Good point, thanks for pointing that out! I hope that I will be able to shrink the BTRFS partition on the fly, because I do not want to again do and physically get the device - it is a pretty inconvenient process which I try to avoid :wink: