Pascal, did you see that there are already threads for this issue: i.e.  Error during update to Filr 24.1 on Filr and Index Appliance 

My information is that there are heavy efforts in the background to fix it and offer a patch for 24.1 - hopefully in the next few days ...

Hi Diethmar, indeed i noticed that, helps me feel less alone ;-)
but didn't find out "same" behaviour.

X fingers on support team, then

I have queued updates for some customers awaiting this patch. On the other side some others updated without any issues (i.e. mine). I did not find a reason why it happened.

Yesterday there was the GroupWise webinar. It was more or less a discussion how to run an environment. Filr has been mentioned there including this update issue. However support solved their problem. Therefore support is working on a (general) patch for fixing it. for us too. 

In general I'm seconding Diethmar :).

However: since all service are running and you get a login page but cannot log in I have to ask the one basic question I stumblen on a few times with Filr: Have you cleared your browser cache?
I have seen time and time again that the JS code fo the authentication in Filr was changed and I had to either clear the cache or "Shift-Reload" in my browser. The case that the admin could not log in was there for me after the jump to 23.x.
As for the branding: if that persists after cache-clearing, look in the network console of your browser and check if the branding is asked for and if so, what error code it get's. 404? 403? 500?

HTH!

Good point, Christian!

In one of my update scenarios I had exactly this situation. I assumed that another update failed but then I used a "private" browser window. Unexpectedly Filr was okay.

With this experience I returned to some of my failed updates hoping for a solution. Unfortunately these filr updates still stuck ...

Nevertheless my list of waiting updates was shorter 

Thank you Christian,

I did a test with a private browser session.

I retest just now and received a failing page, then I notice both services : filr.service and  novell-famtd.service, are "suddenly"  : Active: inactive (dead)

So I have now join the "other" "failure group"

let's X-fingers on a quick resolution

In case you are not watching te other thread, there's an Update: it seems there is a field patch available from the Knowledge Base: https://portal.microfocus.com/s/article/KM000026572 .

HTH!

It seems the real culprit was disk space on root partition.
/ had 3.3 G free out of 50G, but seems not enough for the system to run quietly.
Support redirects me to this conversation :
community.microfocus.com/.../new-issue-small-deployment-shuts-down-after-15-minutes

While checking usage (with du), I didn't find that much of "big" directories...
But noticed root is BTRFS now (who did take such decision?) and while looking snapper, I noticed 67 snapshots,
from September 2022 till today. Deleting some of them provides me with more than 10G (total 13G),
after that I restart everything and both Filr and famtd services are stable now (for a day).

Note : tell developers to add/document a procedure to clean that garbage out

Ah, ok. So the assumption about the failure group you were in was a bit hasty. But good to know, thanks for the update.

As for the btrfs thing: I also wondered about that for some time, especially with the other related issues we see, like the quota pains and such.
I think I have gathered enough bits and pieces from some webinars on different products in our space to hazard a guess.(Btw, no matter if Filr, GW, ZEN,... - and hopefully maybe a vibe one when the someone at the company finally "gets it" - they are all to be recommended if only to keep informed about what's going on.)
It has been said that keeping an appliance model up to date, fresh and current for multiple products is a lot of work, especially on the testing side. When Filr was still SLE12-based, it had a history of coming from JEOS (Just Enough-OS) and was very slim and lean, but needed a load of work to keep it that way. Also, having to test every SUSE-patch thoroughly before taking it in is a workload that can't be skimped on, really, having seen that SUSE CIFS-changes broke CIFS on OES a few times already and OES is a staple backend for Filr. It seems to me that with resources in terms of people-hours being sparse everywhere, and with the change to SLE15 being a boatload of work in an as of itself (if you include the SP level changes, few bricks are in the same place they were before), it looks to me that the Filr appliances are now based on a standard, default SLE installation that is not especially slimmed down. This can be seen if you look at the list of OS patches for the recent update, they have loads of WiFi firmware updates in them, and if someone can explain to me why a Filr Virtual Appliance needs WiFi firmware packages they will get a candy bar from me when (or if) we meet.
The "standard SLE15" of course includes the default choice of btrfs for the root file system as well as the default snapper integration of zypper (pre- and post-snapshots) as well as the defautl quota settings. I could go on a rant about btrfs being the wrong FS of choice for a use case where a set of zypper pre/post snapshots changes the Database through posttrans-scripts, but the changed database is not part of the snapshot, or where user and subvolume quota management would make sense to keep logs in check, but not if logs are saved in an ext3/4 volume somewhere else. Btfrs does have its place, but that place is where it is properly configured, managed, and above all fully understood by the admin working the system. In my opinion a virtual appliance that is to be run black box-style is not that place.

I see two ways to get the garbage out for good: a)configure snapper properly and b) on the next appliance drop, change the root file system type. A third way would be full of weeds and thorns: change all file systems in Filr to btrfs, including vastorage and var disks, and make snapshots have a value. Of course, this way is moot on a virtualisation platform that already provides snapshots :).

Have a nice week!

With that been said, why not :

- either document the BTRFS aspect in the documentation

- add a BTRFS management menu (snapper command) in the VA administration main page

In other OpenText product, we are encountering same kind off issue with Docker used for "everything" without managing it correctly, but that's off topics .