[SOLVED] - Extroot - (expanding Turris package space)


#21

The other way is to configure extroot as you would normally do, but add this start script to the extroot system:

cat <<EOF > /etc/rc.d/S01mount-rom
/usr/bin/mount -o remount,rw /rom
/usr/bin/mount --bind /rom/boot /boot
/usr/bin/mount --bind /rom/lib/modules /lib/modules
/usr/bin/mount --bind /rom/etc/modules.d /etc/modules.d
/usr/bin/mount --bind /rom/etc/modules-boot.d /etc/modules-boot.d
EOF

chmod +x /etc/rc.d/S01mount-rom

This will make to mount bind all kernel related folders very early, so extroot system will always update kernel and modules on mmc.


#22

thank you so so much! i never thought that forums can be so helpful but seemingly I was. i found the answers to my questions simply by searching and reading through your posts! thanks a lot guys! sitting home doing nothing but checking https://musclegurus.com/ offers the opportunity to learn more seemingly! i wanted to ask you, do you mind if i am going to have some questions for you a bit later in case there is still going to be something i would like to ask you about?


#23

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:

  1. how to change this u-boot variable?
  2. can it be /dev/sda1?
  3. I have no subvolumes, I assume it is necessery to create one.
  4. how to copy entire filesystem to mSATA? rsync?

Thanks in advance.


#24

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.

  1. This should work but with will require some changes to the variables.

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

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


#25

Hi,

very inspiring thread. Could you be more specific for us - n00bish - users please? :slight_smile: or you would not recommend it at all ?

For example I have trouble with very first command - fw_printenv - I got response:

Cannot parse config file: No such file or directory


#26

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.

It should probably have this content:

/dev/mtd0 0xC0000 0x10000 0x10000

#27

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


#28

Most of things i do are far of from “official” or even simple. I try to keep things safe most of the time but bad things happen quite often.


#29

thats ok when you know what to do :slight_smile: but why there’s uboot-envutils package installed but no /etc/fw_env.config - it’s bug or “feature”?


#30

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.

http://docs.khadas.com/bootcamp/BootingCardVsBurningCard/