I have a few questions.
Because I have no guarantee that some of software running on omnia writes to mmc (lxc containers are on mSATA, but there is more software installed, some of them may not use only /tmp and /var), I consider moving entirely to mSATA in your way.
So:
how to change this u-boot variable?
can it be /dev/sda1?
I have no subvolumes, I assume it is necessery to create one.
fw_printenv shows it and fw_saveenv allows changes. Be sure to have a backup of /dev/mtd0. Alternative approach: clearenv to remove automatically generated variables, loadenv to get the ones from flash, setenv to change them and saveenv to save them back and reboot to try it in u-boot will do the same thing.
This should work but with will require some changes to the variables.
There is always a toplevel subvolume with id 5. If you donāt give one then it should work. On the other hand creating a subvolume is simple and gives the option to switch the used subvolume with the change of one variable, holding the reset key or even using a switch on the extension header (to be implemented later). I saved the subvolume name to one variable in u-boot and only have to change it in the boot prompt to switch to a backup snapshot.
btrfs-send ... | btrfs-receive ... may be a better option. This does not only copy data and permissions but also internal attributes like no-cow and compressed and part of its metadata like data-dedup.
It is specially a bit cryptic to not have some n00bish user do it without thinking about the consequences and risks.
Some for reference:
wrong or missing bootloader settings (fixable with the internal serial port)
killed bootloader (may require JTAG)
even worse thingsā¦
It seems /etc/fw_env.config is missing.
WIthout any warranty: Content of /etc/fw_enc.config
I donāt know if the mtd is correct for TurrisOS. The flash sector size may also be different. Be sure to have backups of the mtd device and the environment after reading works. You will need them on another device if something goes wrong.
Thanks, Iāll probably let it go for now (I wanted to use sata ssd instead of flash safest possible way - with working updates) but Iām not experienced enough for it.
I thought fw_* was āofficialā or working by default but it doesnāt seem so.
when creating /etc/fw_env.config with values you provided I just got:
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200
so I donāt think it would be wise to proceed any further - I would be just āspammingā you or someone else after each step
A month back i bought a Khadas VIM2 MAX as i was looking for a SoC that could decode x265 for KODI. They have a AWESOME feature.
As it has the ability to run dual-OS from eMMC, it also gives the possibility to run even a triple OS using a SDCard. Here they have a feature that if a Micro-sdcard is plugged in that contains a OS, it will automatically boot from that micro-sdcard. So why is this a awesome feature? Well the wear leveling can sooner or later be a fact on the eMMC. It could be 10 yearsā¦20 yearsā¦i do not know. However many of us havenāt bought the Turris Omnia for 2-3 years, rather a investment for the future (replacing wifi cards, Antennaās, SSD-drive, USB dongles/drives, etcā¦). When the eMMC of the Omnia has left us, logically thinking it would mean the Omnia is ready for the junkyard right? Or used as a simple hub as the switch functionality wouldnāt even work as there is no software controlling it. So having the ability to put the WHOLE Turris OS on a SSD-drive would be a good alternative right?
Do correct me if i have said something incorrectly or give your additions to what i have come up with.
So I come back to playing with Omnia and what do I see? This is now officially supported! \o/
If youāve ended up here because this is top search result when looking how to set up the router from external drive, you need to fetch the medkit and follow the official documentation. Still, there are two things Iād like to mention.
UUID
First of, it is possible to use UUIDs instead of device names (which are not stable and change based on what drives are attached to the router). To do this, run fdisk -l /dev/sda and take note of the āDisk identifierā.
# fdisk -l /dev/sda
Disk /dev/sda: 55.9 GiB, 60022480896 bytes, 117231408 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xe17eb372
Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 117231407 117229360 55.9G 83 Linux
In the listing above, the id weāre after is e17eb372 (note 0x prefix is stripped). Now, when changing bootargs (as documented), use root=PARTUUID=e17eb372-01 instead of root=/dev/sda1 (where e17eb372 is the identifier of your disk).
/var
Second of, one of the reasons I wanted to use external disk is so that I can persist all the data. For example all the log files saved to /var/log. To achieve that, Iāve figured Iāll modify the root file system by dropping the /var symbolic link (which points to /tmp) and make it into a directory (i.e. rm /mnt/ssd/@/var; mkdir /mnt/ssd/@/var). Unfortunately, after that change, the router no longer boots and hands after printing procd: - ubus -.
Anyone has any ideas how this can be addressed? Or do I need to manually configure everything I want to write data someplace outside of /var?
or you would not recommend it at all ?
but why thereās uboot-envutils package installed but no /etc/fw_env.config - itās bug or āfeatureā?