Upgraded from fleetdm 4.17.1 > 4.19.0 and had t...
# fleet
j
Upgraded from fleetdm 4.17.1 > 4.19.0 and had to play open heart sql surgery to get it to work ended up with
Copy code
INFO: 12:50:42 Increasing width of software.vendor...
2022/08/29 12:50:43 FAIL 20220818101352_ChangeSoftwareVendorWidth.go (adding new uniquess constraint: Error 1062: Duplicate entry 'openpgm-5.2.122-rpm_packages-2.el7--x86_64' for key 'unq_name'), quitting migration.
Which led to
Copy code
2022/08/29 12:56:43 FAIL 20220818101352_ChangeSoftwareVendorWidth.go (creating temp column for vendor: Error 1060: Duplicate column name 'vendor_wide'), quitting migration.
After deleting the column and row i was able to upgrade.
k
Thanks for bringing this up! We're looking in to it.
m
@Alexander Samrega seeing the same issue?
m
and indeed it breaks at almost every package of which there is a Centos and a Redhat version ...
I tried deleting all Vendor RedHat items as they clash with CentOS , but next up is Oracle that clashes. So waiting for the fix to include vendor in the "key name" as then they will be unique again. 🤞 for osquery to repopulate the items I deleted so far 😉 . Backup not present , I forgot to check beforefacepalm .....
a
Tried to delete manually but there were too many duplicates… I saw duplicates mainly for
vendor
CentOS and Oracle America
m
Yup .. seeing that too after deleting the Red Hat vendor 😉
m
@Jason Roberts @Marc Roelofs @Alexander Samrega Would it help to get folks who are interested on a quick screenshare sometime today to try and figure this out?
m
@mikermcneil I can do that, if thats helpful as the sooner my env works the happier I am. (As my db backup was not done my system is down now 😜). I'm available starting in 1.5 hrs from now from 7PM CET onwards
k
It looks like this may be related to changes to the
vendor
column, which is leading to multiple entries with the same name. I'll get a ticket put together for it now.
m
@Kathy Satterlee , if the db migration would also look at the vendor colum when migrating to the vendor_wide colum it would work as then the software item will be unique again
k
It actually looks like there's a fix merged for this: https://github.com/fleetdm/fleet/pull/7446
m
@Kathy Satterlee Great to hear! Let's cut a patch as soon as possible. @Marc Roelofs Looking forward to joining the call with you and helping get this resolved in your database. For anyone else about to upgrade to the latest Fleet (v4.19.0), note that we're investigating a migration script issue (https://github.com/fleetdm/fleet/issues/7441). I'd recommend waiting for 4.19.1 to upgrade.
k
Awesome. There's a patch release scheduled for today that will include that fix. Meanwhile, we can get together and get you up and running. Grab any time here that works for you and we'll walk through doing the migrations manually: https://calendly.com/d/d4v-gjn-t54/get-fleet-migrations-running
m
But if there is a patch later today and a updated docker image I could simply run that as db prepare job which should do the trick also right ? Happy to do manual labour but if it can be automated thats easier. My env is not that production critical .
k
Absolutely. This Docker image has the fix included if that's the route you'd like to take while waiting for the official patch. Also happy to help you get up and running with that if have any trouble.
m
maybe my bad , I came from v4.13.0 it turns out ..
although upgrading my test env ( it did not have that much software in it) went flawlessly , and no missing migrations there upgrading from 4.13 to 4.19
j
@Marc Roelofs you could just drop the whole software table contents it will get regenerated from clients.
k
It looks like the patch is going to be delayed until tomorrow in order to make sure there won't be additional migration issues moving to v4.20.0. Thanks for bearing with us, y'all.
n
Update: Patch will likely go out tomorrow (2022-09-01)