Firefox on CentOS 7 thinks Firefox on CentOS 6 is old or not compatible.
I have a dual-boot workstation with CentOS 6 and CentOS 7. Both installations have the same version of Firefox, v68.2.0esr and both systems are fully updated. When I boot CentOS 7 after running CentOS 6, Firefox insists on making a new profile because it thinks it can't use the old profile. That requires me to sync, customise, set preferences, et cetera. That's a PITA.
วิธีแก้ปัญหาที่เลือก
You can compare the compatibility.ini file in a profile used with Firefox on both OSs to see in what way they differ.
อ่านคำตอบนี้ในบริบท 👍 0การตอบกลับทั้งหมด (5)
Firefox stores the installation path of the Firefox version that last used this profile as a hash in profiles.ini and in installs.ini as a backup, so if you start Firefox in another OS then the path doesn't match and Firefox does complain.
See also:
That was an interesting link and I think I understood some of it. But does it still make sense when the CentOS 6 and CentOS 7 installations are exactly the same version? Furthermore, why does it insist on a new profile only when going from C6 to C7 and not the other way? If all that still makes sense to you, I guess my bottom line is what kind of hackery can I perform to keep the C7 instance from demanding a new profile? FWIW, the currently used profile (on C6 at the moment) is vhaajjg6.default-default-2.
วิธีแก้ปัญหาที่เลือก
You can compare the compatibility.ini file in a profile used with Firefox on both OSs to see in what way they differ.
I have now booted CentOS 7 and built a new profile for firefox (lyt9l8r1.default-default-3). Here is the compatibility file from CentOS 6: [Compatibility] LastVersion=68.2.0_20191101125725/20191101125725 LastOSABI=Linux_x86_64-gcc3 LastPlatformDir=/usr/lib64/firefox LastAppDir=/usr/lib64/firefox/browser
And from CentOS 7: LastVersion=68.2.0_20191023183522/20191023183522 LastOSABI=Linux_x86_64-gcc3 LastPlatformDir=/usr/lib64/firefox LastAppDir=/usr/lib64/firefox/browser
And the diff: < LastVersion=68.2.0_20191101125725/20191101125725 --- > LastVersion=68.2.0_20191023183522/20191023183522
Okay, I think I've identified a bug. I booted back to CentOS 6 and sure enough, FF uses the same profile that C7 FF created, but stuck its own version/buildID into the LastVersion param of the compatibility.ini file. So I booted back to C7, and hacked the compatibility.ini file for that profile to change the LastVersion param to that of the C7 FF. Then FF started up without carps. So I take that to mean that the version comparison logic in the profile selection process is broken. I'm guessing it's comparing the whole version/buildID string and not just the version part. Thanks for giving me the clues to run that down.