TeamWorks Migration / upgrade fails "Failed to mount /vataemp"

During migration the appliance console displays:

 

"EXT4-fs (sdb1): couldn't mount as ext3 due to feature incompatibilities"

"Failed to mount /vatemp"

If you need to export the DB and import it to a new instantiation of an VA.  Be warned that if this is done on a small, all-in-one appliance, any attachments and avatars will not come across as they are stored on /vastorage.  In this case you will also need to get what is under /vastorage/esn/filerepository/kablink

 1. from the original system I copied this data from the ssf-ext.properties file:

kablink.encryption.key=MTg5OTUwNjM2MQ==

 kablink.encryption.key.initial=MTg5OTUwNjM2MQ==

 2. Export the DB and copy to a local drive pg_dump –U username dbname > dbexport.pgsql

                pg_dump --username=postgres --dbname=esn > 81dbexport.pgsql

 3a. tar zcvf kablink.gz /vastorage/esn/filerepository/kablink and copy it to a local drive

3b. tar zcvf cachefilestore.gz /vastorage/esn/cachefilestore/ and copy it to a local drive

 4. shutdown the .81 source

 5. installed a new instance of .81 with build 289

 6. stepped through the 9443 wizard which created the DB

 7a. Either drop the Tables and Sequences in the teamworks DB or drop the entire DB and create a new teamworks DB

                DROP DATABASE dbname;

                CREATE DATABASE dbname;

                CREATE ROLE role;

                ALTER ROLE role WITH CREATEDB;

                ALTER ROLE role WITH INHERIT;

                ALTER ROLE role WITH LOGIN;

7b. Import the new DB from the export in step 2, psql –U postgresUsername dbName < dbexport.pgsql

                psql --username=postgresUsername --dbname=dbName < dbexported.pgsql

 8. imported the new schema:

                Under /esninstall/db Open the postgres properties files and change the encrypted passwords to novell or whatever the DB password is.

                sh manage-database.sh postgresql updateDatabase

 9. cp of ssf-ext.properties file to ssf-ext.orig

 10. changed encryption key values at the bottom of ssf-ext.properties to the original values copied from step 1 above.  (If you migrate this same server again, you may need to modify this encryption key once more in the ssf-ext.properties file)

 11. change the encrypted value in the ssf-ext.properties value of the database.password= userPasswrod or whatever the TeamWorks user password is in for the DB

 ***NOTE*** you may need to change the /opt/novell/esn/apache-tomcat/conf/Catalina/localhost/ssf.xml file so the db and db user are the same as the imported DB & /esninstall/installer.xml

 12a. tar zxvf the kablink.gz file from step 3 into the target /vastorage/esn/filerepository/kablink

                You may have to force this untar on the target system or just untar to a tmp directory and then manually cp –R the contents of the untarred kablink directory

12b. tar zxvf cachefilestore.gz /vastorage/esn/cachefilestore/

 13. import a new license (if needed)

 14. Restart postgresql

 15. ***May not be necessary – see step 18 below

 run /opt/elasticsearch/plugins/search-guard-5/tools/hash.sh tw-admin and again for tw-user and. . .

1.       Specify the passwords for each when prompted – set it to “novell” as this was the hard coded value in the db at the time this particular migration process was done in 2018.

2.       Copy the hash of each and paste it their key value pairs in /opt/elasticsearch/plugins/search-guard-5/sgconfig/sg_internal_users.yml

3.       Run /opt/elasticsearch/plugins/search-guard-5/tools/sgadmin_esn.sh

4.       Restart elasticsearch

 16. Restart tomcat

 17. Login to 8443 as admin and re-index the entire site

 The following steps proved to not be necessary and were only run because I had initially forgotten to run step 11 above

***18. this step may or may not be necessary: “update SS_LdapConnectionConfig set credentials = null;”

If it is necessary then step 15 will apply as well.

 ***19. (see step 18.) Re-enter the LDAP passwords for the LDAP server in the 8443 > administration Console > LDAP > Server Information > Password setting

The EXT4 file system is not expected during a migration because the default appliance file type is EXT3.   If the file system type was manually changed to EXT4 during the previous installation then you will see this problem when migrating to a new appliance.