I don’t have the Xwiki.Extensions page. What I have after restoring it from recycle bin is /xwiki/bin/viewrev/XWiki/AddExtensions
@mflorea @tmortagne: should we ask Wolfgang for the job log file from the flavor upgrade job to see if XWiki.Extensions was deleted by the job?
@vmassol XWiki.Extensions is the new page. It looks like the upgrade deleted XWiki.AddExtensions page, as it should, but didn’t add the new page XWiki.Extensions (that replaces the old XWiki.AddExtensions). But yes, the upgrade log can help understand the problem. You can find it normally in <permanentDirectory>/jobs/status/distribution.
I’m sorry to say: Where do I find permanentDirectory on my linux host?
Wolfgang
No logfiles in /var/lib/xwiki/data/jobs/status/distribution
Wolfgang
Actually this is only the distribution job. What we need is the install log of the flavor which should be in /var/lib/xwiki/data/jobs/status/extension/action/org.xwiki.platform%3Axwiki-platform-distribution-flavor-mainwiki/wiki%3Axwiki/status.xml (if you are sure /var/lib/xwiki/data/ is your permanent dir).
This log is not really useful as it corresponds to a downgrade from 9.11.7 to 9.11.6. You didn’t mention anything about a downgrade 
About this, maybe we should ask for for a screenshot of the Extension > History view when we’re trying to figure out what happened? I think it could help understand what the user has done.
This propably the log you need (zipped):
status_zip.log (117.3 KB)
I have several snapshots of the vm. This was taken directly after the upgrade to 9.11.7.
The part of the upgrade log that concerns the XWiki.Extensions page is this https://up1.xwikisas.com/#H0JF6p0byfyUOnHhejrbzw .
Failed to install document
Error number 3201 in 3: Exception while saving document xwiki:XWiki.Extensions
Error number 3234 in 3: Exception while saving attachments attachment list of document xwiki:XWiki.Extensions
Error number 3232 in 3: Exception while saving attachment [Attachment xwiki:XWiki.Extensions@icon.png]
Error number 3232 in 3: Exception while saving attachment.
Failure in onRun()
Caused by: com.xpn.xwiki.XWikiException
Error number 0 in 3: Exception while hibernate execute
org.xwiki.store.legacy.store.internal.FilesystemAttachmentStore.saveAttachmentContent(FilesystemAttachmentStore.java:124)
So it looks like saving the XWiki.Extensions page fails because the content of the icon.png attachment could not be saved. It seems the failure is in the FilesystemAttachmentStore. @tmortagne any idea?
Good catch Marius.
BTW the message looks a bit weird since Hibernate is not about Filesystem
Unfortunately TransactionException is a bit special as far as can see (it stores a list of causes instead of using the standard Exception cause field…) and the actual reason why the save failed has not been serialized by the generic exception serializer.
Actually no, it was printed and it’s Error number 0 in 3: Exception while hibernate execute which, I think, means that the hibernate save failed so it canceled the filesystem store. But this is itself supposed to have a cause which is not printed by TransactionException and hidden to the generic exception serializer.
You might want to try to save an attachment in some page and see if it work, if not you should get more details on why it fails.
I just deployed a new version of the TransactionException class. @wolfgangT if you replace in WEB-INF/lib/ the jar xwiki-platform-store-transaction-9.11.7.jar with the last one on http://maven.xwiki.org/snapshots/org/xwiki/platform/xwiki-platform-store-transaction/9.11.8-SNAPSHOT/ (xwiki-platform-store-transaction-9.11.8-20180824.153346-31.jar at least) and retry the upgrade it should put more details in the log.
Here is the most recent log with the new jar in place:status_zip.log (126.0 KB)
Sorry for letting you wait that long, but my witfe prepared a very nice cake…
Wolfgang
lol
So according to the log it fail while saving the attachment history in the database.
This sounds like a bug but I doubt you really intended to store attachments content in the filesystem but attachment history in the database, did you ? What do you have in xwiki.cfg in the store section ?
It’s really a bit weird what I configured:
# xwiki.store.main.hint=hibernate (intended)
xwiki.store.attachment.hint=file (intented)
# xwiki.store.versioning.hint=file (intented)
xwiki.store.attachment.versioning.hint=hibernate (not intended)
# xwiki.store.recyclebin.hint=file (intened)
xwiki.store.attachment.recyclebin.hint=file (intended)
The reason for this setting come from our system. We build production systems for radio stations which include almost anything from planning of shows, audio editing, large file storage, database and a lot of other tools. In our database we have the metadata for the audio files. For the database the audio is kind of attachment which we definitly do not want to store them within the database just because of the size (it’s all linear audio!). We we talk about history of audio data, then we mean that we want to know whether an audio consists of parts of other audio and that for generations of the audio. But that’s all metadata, so no huge amount of data. That in mind I configured file for all attachment. And in terms of history I obviously made a wrong decision because in terms of xwiki the story is totally different.
Can we change that setiing without confusing anything?
Yes AFAIK in the database the version store also store diff between each version so you do end up with stuff as big as what you have on filesystem at least for the first version of the history and then diffs (and from time to time a new full content is stored to speed up version content resolution).
If it was already like this in 8.4.5 and attachments history was working fine it would be great if you could report a BUG issue on https://jira.xwiki.org/browse/XWIKI.
Now changing this property is not a problem in theory because XWiki support mixed storage. In practice this means that it’s indicated for each attachment where XWiki should store the content and the history so this value is just the default to use for new attachments. But if there is a bug in 9.11.7 with the database attachment history it will still affect old attachment which are not going to be moved to filesystem.