Fails to update TOS 5.1.x, the TOS webpage keeps showing blank after reboot?

[Gremlin]

btrfs can be shrunk

I know very little about the practical implementation of TOS and new tricks are not my forte these days!
However, I would guess that it is not as simple as this.
The issue, in my mind, is not shrinking btrfs, but in moving it's start point and telling the system where that start point is. If it only concerned one disk it might be doable, but with several disks in a raid formation .....

My experience of "old" raid says it won't be pretty

Edit: Looks like we were cross posting.

[Gremlin]

@TMRoy

Has anyone tried? (Just curious)

[Stephan315]

english below

Hallo,
nachdem ich blauäugig das Online-Backup gestartet hatte, bekam auch ich eine weisse Anmeldeseite mit den hier mehrfach beschriebenen Problemen .
Ich habe nach langem Hin und Her eine Neuinitialisierung über TNAS-PC initiiert .
Die Initialisierung lief automatsch ab und danach startete das System mit der aktuellen Version 5.1.34!
Alle Laufwerke/Dateien sind weiterhin vorhanden .

Hoffe ich kann hiermit einigen Verzweifelten helfen
Gruesse
Stephan

_______________________________________________________________________

Hello,
after I had started the online backup naively, I also got a white login page with the problems described here several times .
After a long back and forth, I initiated a reinitialization via TNAS-PC .
The initialization ran automatically and then the system started with the current version 5.1.34!
All drives/files are still there .

I hope I can help some desperate people here
Greetings
Stephan

[Gremlin]

After a long back and forth, I initiated a reinitialization via TNAS-PC .
The initialization ran automatically and then the system started with the current version 5.1.34!
All drives/files are still there .

I can (sort of) confirm that but from a different perspective.
To try and solve another problem I was told by support to upgrade to 5.1.34 and (against my better judgement) I tried. The update failed in the expected(?) way. No login and a TNAS reporting as uninitialized. At this point I had nothing to lose. Restarted initialisation, but I opted to use the 5.1.34 INSTALLATION package, without wiping the existing disks.

The package ran without issue and I input my previous admin user and password.

TNAS restarted and all my drives/folders/files were there intact.

What didn't work?
The wallpaper reverted to default (big deal!)
Lost my aggregated LAN (bonded) connection (easily fixed)
Lost ALL MY USERS - not such an easy fix.
[I have a stored configuration file which I will try to use to get my user setup back. At the
moment I am backing everything up to a remote store.]

What did I gain:
An 8GB root file system

Well there is a surprise! Can't be done? HUH!

[Gremlin]

Update:

Configuration file uploaded OK.
All users reinstated although permissions need to be reset manually (bugger).
All scheduled tasks reinstated.

No apps were installed at time of update. I cannot recall if they were deleted prior to the configuration
file being saved, but no apps have been "reinstalled".

[topo01]

{L_BUTTON_AT}Gremlin

Thanks for reporting! This sounds very interesting.

However, there remains the question of how have the data on the storage partition survived? Apparently the setup has taken 6GB await from the storage partition and has given it to the system partition. Is my understanding correct?
And if all the old data is still visible how can you be sure it's all intact?

Anyway, even if the data partition was damaged (no one knows yet but seems likely to me) this could be an option to achieve re-partitioning without having to do it on a separate PC.

[Gremlin]

At the moment I suspect that due to boundaries within the partitioning, there was actually some "dead" space between 'root' and 'brtfs'. The installation package has merely used this space and extended the root system to fit.
The root space is actually reporting 7.41GB. But, the original was never exactly 2Gb so there is some overhead there. There may be even more 'dead' space there, but I am not going to remove the disks to check
It may also depend on the way in which the disks were set up in the first place. EXT4 may have a different result. The sizes of the initial install may be a factor as might be the raid system used, if any. I started with 3x2TB TRAID, updated to 3x4TB TRAID.
I will happily accept that Fortune landed butter side up in this case. However, it does suggest that there is more than one way to skin this cat (I do love a mixed metaphor). The fact that support are probably constrained to follow a predictive line means that this has never been considered or explored.

[topo01]

Right. Your cat skinning aspekt is what actually intrigued me.
Another bubble that surfaces in my mind is using a partitioning tool like parted, fdisk (cfdisk) or gdisk. These are generally able to re-size partitions and shift existing data around as needed. Though I haven't further explored along such path to see if the flag would wave in the wind . And I have no clue how this is done on a RAID1 (in my case).
As you said: That would not comply with the preferred Kindergarten birthday party route.

[Gremlin]

Had my attempt failed (as I fully expected at the outset) I was going to take a look via GParted Live - just to see what the potential was. I may well at some time set up a single disk system later and have a look. The main issue over multiple disks would be (if indeed possible) to modify all disks in exactly the same way (since root is mirrored over all drives).

[Gremlin]

Wouldn't it be a 'hoot' if some developer had actualy left an 8Gb partition space in front of data partitions, not used it and not told anyone about it.