Checksum changed without reason

I have a changelog that worked just fine, now for no reason (at least one I can find) all the changesets have changed checksum. The checksum I describe below went from 2:079b940a8b8a1c413e80abe52447f4c4 to 3:2bf92b9e42fc2473a299f83497eadf2f  and all the checksum from the other 91 changesets used to start with 2: and now start with 3:

  1.  91 change sets check sum
  2.           base_dbchanges.xml::base_1::ricardo is now: 3:2bf92b9e42fc2473a299f83497eadf2f

would appreciate any help.

Im working on Ubuntu inside a VM

sorry, I forgot to login before posting

Any comment, this has happened to me again

What is the new checksum you are seeing? And have you done a liquibase update between changes?


No changes. I’ve "solved the problem by adding  

  1. 3:2bf92b9e42fc2473a299f83497eadf2f

 to the changeset, buut it doenst explain why the change from 

  1. "2:f8310d57a12885d0d6895bfa0c506175"
  1. 3:2bf92b9e42fc2473a299f83497eadf2f


have you been able to figure out what caused the checksum change?


what other stuffs could affect a checksum to make it change?

Thanks totalylou…, it helps alot. I’m just wondering what could cause this change in the checksum, before just reseting it. My changeSets do not contain elements, no liquibase updates in between, and they look alike between branches. 

We ran a git-merge-conflict-resolution in between thou, so I’m trying to figure out what we could go wrong.

Thanks again.


have you heard about issues like this? Could line-breaks mess-up the checksum?

Thanks in advance.

We are using version 2.0.3.

Im no expert, just a user But if I had to guess, my bet would be on file encoding. me and my associate use different OS (Mac and Linux) and I believe the file encoding  (maybe the line break)  can be an issue that can cause this problem.

Anyway, I solved my problem with ValidChecksum and moved on

No I wasnt, But I started using (with the new checksum)

I havent had that problem again

Hop this helps

Yes, It seems we are going to take same road. 

Nevertheless, I think I have read that XML is normalized prior checksum calculation ( .

Also, the enconding of both version of the file are in utf-8.


There is sometimes a checksum change when upgrading liquibase because of changes in the algorithm, otherwise we do try to normalize as best as possible. If you are using changelog parameters the value of them are taken into account, so that may make a difference if the values change. 

If you run liquibase with --logLevel=debug it will output the strings that are checksum’ed which may help you see what may have changed.


Hi everyone!

I recently started to use liquibase 3.0.2, and I was very surprised to notice that running liquibase status against database managed so far with liquibase 2.0.x lead to silently convert all the changeset checksums.

With 2.0.x checksums look like Cheers, Gilles

Sorry, forgot to login before writing comment above. I didn’t wanted to make it anonymously…

Thank you Nathan for very fast answer. Sorry that I’ve missed this link to v3_upgrade note from (I searched for “checksum” on the blog post).

Notes (please tell me if you prefer that I shift this stuff to a separate forum thread): 

  • In my experience, running again "liquibase status" with 2.0.x (tested with 2.0.3 and 2.0.5) did not recompute the checksums, but generate checksum mismatch alarm. I'll give a second try (maybe I should put/remove an option).
  • I also noticed that some DATABASECHANGELOG.checksum fields are empty after the upgrade... and it looks not very good to me. What do you think? (I have no access now to the data, but I can provide more information in the next days)
Again, thanks a lot :-)


Yes, the checksum algorithm changed from 2.x to 3.x and so Liquibase updates them. I had added a note on about how the runOnChange logic was affected by the changing checksum, but I’ll add some more checksum-specific explanation.

If you downgrade to 2.x, it should “fix” the checksums back, it just can’t tell if there are changes due to the incompatible checksum versions.


I think it makes sense that status gives checksum mismatch alarms. I don’t think it should just fix them on a status, but it should also handle it better. I created to track that feature.

The checksum fields should not end up empty. They get cleared out but then should get repopulated. Can you let me know if you are seeing them end up null and what commands you ran to get them like that?


If the checksum algorithm has changed again for 3.1.1 -> 3.2.0 (?) then Liquibase should also update them again.