System on mSATA disk

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.

2 Likes

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.

4 Likes

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…

3 Likes

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.

2 Likes

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 https://doc.turris.cz/doc/en/howto/omnia_booting_from_external_storage).
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.

4 Likes

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:

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).

1 Like

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