Does not meet the conditions for updating the TOS 5.1?

[t654]

It is possible to resize the system partition if you have multiple disks and are using something like RAID5 for your data, and the filesystem is BTRFS, although I'm sure this method won't be 'supported'.

This is a description of what I did, and not a set of instructions or a recommendation - IF YOU CHOSE TO TRY THIS, DO SO AT YOUR OWN RISK

I recently did this on my F5-221.

The following describes my setup and method, but this may vary depending on how the disks are configured. All commands are executed on the device over ssh, and can be done online. During the process, the TOS GUI will throw up lots of warnings - ignore the GUI.

Its probably quite risky, as a misstep could lead to data loss.

TOS partitions each disk into 4, the last 3 are the ones that need adjustment. Partition 2 contains the OS, so partitions 3 and 4 need to be moved/resized as well. Partition 3 contains swap, and 4 contains all the data - usually the rest of the disk.

The data partition is used along with partition 4 of other similar disks to create a RAID array (in my case RAID5). You can see this with `cat /proc/mdstat`
The raid array (in my case /dev/md1) is then used as a physical volume in the lv0 volume group (See Linux LVM). The volume group then has one logical volume containing all the data (If you have more, I don't think you can continue with this process)

The swap partition uses /dev/md8, and can be easily stopped and resized (later)

The System partition (the one we want to make bigger) is a RAID1 array on /dev/md9

I've only outlined the process and not the commands, as all systems will be different, and copy/paste could be catastrophic.

The process:
reduce the BTRFS filesystem on your data partition (in my case /dev/mapper/vg0-lv0) by a large amount (we want to recover 8 or so GB for the system, but each step is safer (less maths) with a bit of headroom - I reduced it by 2TB). BTRFS allows online shrinking of a filesystem. This puts all the data to the beginning of the logical volume.
resize the logical volume (/dev/vg0/lv0) by a good amount, but less than you did for the filesystem.
resize the physical volume in the volume group BY a value less than you did for the logical volume (use pvdisplay, vgdisplay, lvdisplay to see the setup)
resize the member disks for the raid array for the physical volume (use mdadm) BY a value less than you did for the physical volume. Be careful here, as each member disk doesn't contribute to 100% of the raid array size (see RAID 5)
The idea is to end up with sizes: filesystem < logical volume < physical volume < raid device size
Stop the swap disk to take it offline (swapoff) (precaution)
For one disk, fail all the parttions being used by raid (mdadm <raid device> --fail <disk>)
For the same disk remove the partitions (mdadm --remove) NOTE: I had to do the fail/remove again during the process as TOS hot-added the disk back in.
You will now have degraded arrays, but data will be OK (so long as all the other disks stay OK)
fdisk -l the disk you have just failed, and take a note
fdisk that disk, delete and re-create the partitions 2,3,4. Make 2 10G (for TOS). Make 3 the same as it was before and make 4 the rest (this MUST be the same as or bigger than the size you made the member disks earlier).
use mdadm to add the disks back into their respective arrays. The arrays will rebuild (see cat /proc/mdstat), and may take several hours. THIS MUST COMPLETE BEFORE CONTINUING
Do the same thing for all the disks in the array, so when you fdisk -l on the disks they are the same (again), but with a bigger partition 2
The resizing done earlier can now be reversed.
Use (mdadm -z) to make the member disks of each array the maximum size (new partition sizes will be seen at this point)
resize the system partition. Mine was ext4, so resize2fs /dev/md9 (mounted on / ). You now have a bigger partition for TOS upgrade.
swap should be fine (as the size didn't change, so use swapon to turn it back on)
resize the member disks to max for the data array (mdadm)
resize the physical volume for the data group (vg0) (pvresize)
resize the logical volume for the data group (lv0) - you can see by how much using vgdisplay (free PE)
resize the BTRFS filesystem for your data

Cross your fingers and reboot to test it all out !

Mine was OK, and I've since upgraded by a point release, so I guess TOS didn't mind/notice

[andy]

I have just updated manually to 5.0.176
My system space is 1.8GB

I will never have an option to update to a newer OS?

[Gremlin]

I have just updated manually to 5.0.176
My system space is 1.8GB

I will never have an option to update to a newer OS?

Read the instructions. Do a good backup. Action the instructions. It really is not that difficult. (Some like to make it harder than it is).

[Bernhard.Wuest]

i have two F5-422. The new one came with 4.2.40 and I upgraded using 5.1.24. Now I read that there might be a problem with the memory.
After an additional upgrade i am runnning now 5.1.67 but still having 2GB memory with 84% used. How do I get to 8GB memory. Do I need to downgrade to 5.0.176 which is the lowest number I found starting with 5.0.xx. Will the system by upgrading from 5.0.176 to 5.1.24 automatically increase the size of the memory to 8GB?

I am having an second 1 year old F5-422 with TOS 4.2.40. The procedure here is to go to 5.0.176 as 5.0.120 is not available on the download and then upgrade to 5.1.24??? Will that upgrade the memory to 8GBs?
Have to say for a normal user its a bit confusing, sorry for all the questions?

Doris from the chat wrote that I need to format the discs?? I wanted to avoid that with 30 TB of data.

[DERIKKU]

OK it is possible. Why can't TerraMaster not wrote a script in the update package that will do this, when the system is not 8gb?????

It is possible to resize the system partition if you have multiple disks and are using something like RAID5 for your data, and the filesystem is BTRFS, although I'm sure this method won't be 'supported'.

This is a description of what I did, and not a set of instructions or a recommendation - IF YOU CHOSE TO TRY THIS, DO SO AT YOUR OWN RISK

I recently did this on my F5-221.

The following describes my setup and method, but this may vary depending on how the disks are configured. All commands are executed on the device over ssh, and can be done online. During the process, the TOS GUI will throw up lots of warnings - ignore the GUI.

Its probably quite risky, as a misstep could lead to data loss.

TOS partitions each disk into 4, the last 3 are the ones that need adjustment. Partition 2 contains the OS, so partitions 3 and 4 need to be moved/resized as well. Partition 3 contains swap, and 4 contains all the data - usually the rest of the disk.

The data partition is used along with partition 4 of other similar disks to create a RAID array (in my case RAID5). You can see this with `cat /proc/mdstat`
The raid array (in my case /dev/md1) is then used as a physical volume in the lv0 volume group (See Linux LVM). The volume group then has one logical volume containing all the data (If you have more, I don't think you can continue with this process)

The swap partition uses /dev/md8, and can be easily stopped and resized (later)

The System partition (the one we want to make bigger) is a RAID1 array on /dev/md9

I've only outlined the process and not the commands, as all systems will be different, and copy/paste could be catastrophic.

The process:
reduce the BTRFS filesystem on your data partition (in my case /dev/mapper/vg0-lv0) by a large amount (we want to recover 8 or so GB for the system, but each step is safer (less maths) with a bit of headroom - I reduced it by 2TB). BTRFS allows online shrinking of a filesystem. This puts all the data to the beginning of the logical volume.
resize the logical volume (/dev/vg0/lv0) by a good amount, but less than you did for the filesystem.
resize the physical volume in the volume group BY a value less than you did for the logical volume (use pvdisplay, vgdisplay, lvdisplay to see the setup)
resize the member disks for the raid array for the physical volume (use mdadm) BY a value less than you did for the physical volume. Be careful here, as each member disk doesn't contribute to 100% of the raid array size (see RAID 5)
The idea is to end up with sizes: filesystem < logical volume < physical volume < raid device size
Stop the swap disk to take it offline (swapoff) (precaution)
For one disk, fail all the parttions being used by raid (mdadm <raid device> --fail <disk>)
For the same disk remove the partitions (mdadm --remove) NOTE: I had to do the fail/remove again during the process as TOS hot-added the disk back in.
You will now have degraded arrays, but data will be OK (so long as all the other disks stay OK)
fdisk -l the disk you have just failed, and take a note
fdisk that disk, delete and re-create the partitions 2,3,4. Make 2 10G (for TOS). Make 3 the same as it was before and make 4 the rest (this MUST be the same as or bigger than the size you made the member disks earlier).
use mdadm to add the disks back into their respective arrays. The arrays will rebuild (see cat /proc/mdstat), and may take several hours. THIS MUST COMPLETE BEFORE CONTINUING
Do the same thing for all the disks in the array, so when you fdisk -l on the disks they are the same (again), but with a bigger partition 2
The resizing done earlier can now be reversed.
Use (mdadm -z) to make the member disks of each array the maximum size (new partition sizes will be seen at this point)
resize the system partition. Mine was ext4, so resize2fs /dev/md9 (mounted on / ). You now have a bigger partition for TOS upgrade.
swap should be fine (as the size didn't change, so use swapon to turn it back on)
resize the member disks to max for the data array (mdadm)
resize the physical volume for the data group (vg0) (pvresize)
resize the logical volume for the data group (lv0) - you can see by how much using vgdisplay (free PE)
resize the BTRFS filesystem for your data

Cross your fingers and reboot to test it all out !

Mine was OK, and I've since upgraded by a point release, so I guess TOS didn't mind/notice

[Gremlin]

OK it is possible. Why can't TerraMaster not wrote a script in the update package that will do this, when the system is not 8gb?????

You will have noticed that the post you quoted only contained the process, not the actual commands (very deliberately). I suggested some time ago that this would be possible, but realised (very quickly) that backup and rebuild was much easier/safer in the long run for the majority. I was fortunate in that I was just "testing" the system and had not gone the same route as many that had huge amounts of data and no method (or inclination) to ensure regular backups.

As to automation - imagine how many users there are of TNAS and then imagine how many different variations there are of how those many users have set up their systems. Awkward to say the least Then imagine how many of those users don't really understand the device/software they are using. It is hard enough to get these same users to read the initialisation choices on screen (Yeah, me too!) and use the "custom" build functions

I confess I like the idea of building a larger OS partition (and possibly swap as well, but that is a different discussion). A few GB is nothing in the overall scheme of things - EXCEPT that some of those same users complain if they can't "see" where that couple of GB has "disappeared" to. More choices of how the system is built appear to be coming in TOS6 but we have yet to see an "installation" release, so we will have to wait.

[hooyerd]

For my F-421 it was as simple as removing both drives and externally deleting the 4 partitions (backed up the data of course). Then I installed the latest version of TNAS PC to my desktop. Turned on my F-421 without the drives installed. Launched TNAS PC from my desktop and it found the F-421. Pretty much just followed the steps as directed with installing the drives, it self downloaded the latest TOS 5 version, updates, and setup up the F-421 step by step with new super user and passwords. I then added previous users and restored data from thr above 'before' backup. When all was done it has me sitting on version 5.1.103-00409 with the '/' indicator showing 1.67/7.41(GB) of usage. I'm calling this a relatively easy update/success and ready to move on with my life LOL. The biggest PITA with the ordeal is the web interface login to the TNAS; the crappy resolution 4-digit verification code you can barely make out. I'll probably to hell for all the cussing I do at the screen for getting that stupid number wrong 9 out of every 10 attempts. TerraMaster needs to make that a tad friendlier

[Cis]

Hi,

I was on TOS 5.1.2x or something and hit the update button by mistake, while my System partition was 2GB..

I am now stuck with the "Loading please wait... " and cannot access to TOS UI page

However I noticed that my app and services running on docker are all ok and reachable.. (Plexe, deluge etc..)

I am very concerned I have again to backup and erase all my disks, which I did already for TOS5 !

Please tell me I have a way to either revert to previous situation, or access TOS ui somehow..

[TMzethar]

{L_BUTTON_AT}Cis

You can consider to reinstall the previous version that is compatible with 2GB system partition: viewtopic.php?f=76&t=423

[Cis]

Thanks,

Any hint how to then increase my system partition to more than 2Gb?