Posts made by notverypunny

Are you using the appropriate sysprep switches when preparing the machine to be captured? I never capture a physical machine, but I always use /generalize /shutdown /oobe and /unattend:unattend.xml when capturing my VM builds which are then deployed to laptops and desktops.

@Sebastian-Roth said in FOG 1.5.7 Update Database Issue:

@notverypunny In a test setup I was able to revert back to mysql 5.7 without much trouble. It seems to be able to use the database that mariadb used as well. The only issue I see is that the systemd service files seemed corrupted on my test system:

ls -lah /etc/systemd/system/ | grep -e maria -e mysql
lrwxrwxrwx  1 root root   35 Jul 22 20:10 mysqld.service -> /lib/systemd/system/mariadb.service
lrwxrwxrwx  1 root root   27 Jul 22 21:16 mysql.service -> /lib/systemd/system/mariadb

So I am still wondering if it’s a good idea to simply revert the change back to mysql-client mysql-server or if I need to add a check and if someone is on MariaDB already I just leave it alone?!?

I would add a check, assuming that the logic isn’t too much to code. MariaDB is the better db at this point from what I can see and I should think that most people would prefer it, especially on a new install.

@Sebastian-Roth

With 18.04 being a LTS, I expect that they’ll keep mysql alive and well in their repos, or provide migration / upgrade within the distro’s framework. As such, the project’s (fogproject that is) best track might be to keep existing 18.04 installs on mysql unless there’s a compelling reason to force the migration.

I’m lucky that my fog servers aren’t hosting anything else, but migrating databases if someone has other workloads on the same servers might not be a simple task.

Cheers

Aaand it looks like the same bug is present when updating storage nodes…

Similar process as far as a workaround goes, but without the backup and restore of the fog db as it isn’t part of the storage node.

So for anyone else running into this, or if the devs want to make this work in the script, here’s what I had to do to get this upgrade to work:

• backup fog db
• perform manual install of mariadb-common, mariadb-server and mariadb-client
• reboot (services wouldn’t start and play nice, this was the simplest thing, should also be possible without restarting but I didn’t go there)
• manually create fog db
• restore fog db from backup
• git pull and run bin/installfog.sh

knock wood things are now working as expected and the web interface seems snappier (could just be in my head).

Cheers

My apologies if this ends up as a duplicate post, tried to register and the confirmation email wasn’t getting through the work address… anyways

I’ve got the same issue: Running 1.5.6, trying to upgrade to 1.5.7 on Ubuntu 18.04.2.

Just tried manually installing the appropriate mariadb packages ( -common, -client and -server)

Here’s the problem:

Looks like the script isn’t set up to handle the migration from mysql 5.7 to mariadb given the exception that the package manager throws so it scraps the existing install.

Not sure what avenue you want to take with the script, but it looks like it’s going to break any existing ubuntu installs that are trying to go from mysql to mariadb.

Ping me if you need any more info, I’ll post back if if make any headway on my install.