![Firefox logo](https://assets-prod.sumo.prod.webservices.mozgcp.net/media/uploads/products/2020-04-14-08-36-13-8dda6f.png)
Profile changes after update
Hi all, I use to update Firefox with my Linux distribution package: I build the new package then upgrade it on the system. Anytime at the first launch of the new Firefox just installed version, it opens a new blank profile instead of my usual profile. I can set my usual profile as default by launch Firefox Profile Manager. So after update I launch from command line terminal or through launcher bar:
firefox -p
And It starts up profile manager, then I choose my usual profile and check it as default one. After that, when I open Firefox again, it uses my usual profile as expected.
Now the question: - is there a way to automate this procedure so I have not to repeat it anytime after I update the browser?
PS. I noticed my "profiles.ini" file is populated with a lot of profiles sections, likely maybe anytime I update, a new one is added in here. I don't know if it is a regular behavior or not.
Обране рішення
Aha, yes, known issue with the script:
https://gist.github.com/ruario/9672798?permalink_comment_id=3507704#gistcomment-3507704
Lots of subsequent comments, so hopefully something there will help out.
Читати цю відповідь у контексті 👍 0Усі відповіді (12)
In addition to profiles.ini, Firefox uses an installs.ini file to match different "products" to their default profiles. I wonder whether each new build is considered a new product rather than an upgrade to the previous product. Does your installs.ini file have a ton of entries?
P.S. You can change your default profile internally within Firefox by using the about:profiles page (since Firefox 47; if you're a long-time user, you might not have bothered learning about this page, but it's a great way to launch alternate profiles and change the default).
In your desktop launcher shortcut properties for Firefox you could set for the command as /wherefirefoxfolderis/firefox/firefox -P "exactprofilespellingherewithquotes"
This way when you use the launcher it will start up Firefox with the specific Profile each time.
Змінено
Thank you for your replies! My "installs.ini" file is really full of entries... as you supposed. Maybe update procedure through distribution packages upgrade is intended as a new product...
I tried to delete all profiles from profile manager. Can I erase install.ini without any problems?
To be clear, I want to upgrade my Firefox packages time to time, and find my usual profile when I reload Firefox.
I considered the idea to use a "wrapper" that specifies my profile name by "-p" option. But I prefer to "set" my profile as default one, I think it would be a cleaner solution.
I used "about:profiles" page in the past, but It's not so speedy: - open firefox (it use the new profile) - open about:profiles - set my old profile as default - reload firefox
Questions: 1) Is there a "builtin" way to avoid this behavior (change of default profile at update time)? 2) Is there a command line option or command to "set" a specific default profile? 3) Is there a way to set default profile by edit somehow profiles.ini or install.ini or some other config file within my "~/.mozilla/firefox" folder?
Thanks again!
You can remove installs.ini to make Firefox create a new file from the profiles listed in profiles.ini. Firefox uses this file to scan the profiles listed in it and checks the compatibility.ini file in each profile to determine what Firefox version and installation path last used this profile. The current default profile is marked as Default=1 in profiles.ini. Each profile in profiles.ini has its own unique sequence number, so if you edit profiles.ini and decide to remove profiles that aren't present then best is to keep this list (Firefox doesn't seem to care about the order). Easiest is to use the Profile Manager to cleanup the profile list and set the default profile (i.e. let Firefox handle this file). You can launch the Profile Manager by using a shortcut that has a space and "-P" appended to the command-line. See Start the Profile Manager when Firefox is closed:
profiles.ini contains many entries similar to what I find within installs.ini
I tried this procedure:
- remove current installed version (stable channel release 115.0.2) - built a package of an older version of firefox (tried with ESR channel 102.13.0esr) and install it - backup my profile folder ~/.mozilla/firefox/12ab3def.foo-1234567891234 - when I launch firefox it refuses to start with my old profile due to bookmarks corruption risk after downgrading - I force it by launch:
firefox -p -allow-downgrade
- chose my profile and it works properly
Now I can simulate the upgrade after trying to cleanup a bit profiles.ini and remove installs.ini, so:
- move installs.ini to installs.ini.bk and copy profiles.ini to profiles.ini.bk - edit profiles.ini with a text editor and remove all entries but leaving just my default one - try to start firefox again and check if profiles.ini or a new installs.ini are again changed
They are actually changed as follows:
installs.ini
[99EE9573B7C0378A] Default=12ab3def.foo-1234567891234
profiles.ini
[Profile0] Name=foo IsRelative=1 Path=12ab3def.foo-1234567891234 Default=1
[General] Version=2
[Install99EE9573B7C0378A] Default=12ab3def.foo-1234567891234
- at this point tried to upgrade and here what happened
After upgrading and launch firefox without any option, it still creates a new profile called "default-release" and opens up the browser using it as new default, I suppose to preserve a safer config.
Let's see how profiles ad installs changed:
installs.ini
[99EE9573B7C0378A] Default=12ab3def.foo-1234567891234
[8CF9B42AB7B91C9] Default=m0o8933l.default-release Locked=1
profiles.ini
[Profile1] Name=default-release IsRelative=1 Path=m0o8933l.default-release
[Profile0] Name=joe IsRelative=1 Path=12ab3def.foo-1234567891234 Default=1
[General] Version=2
[Install99EE9573B7C0378A] Default=12ab3def.foo-1234567891234
[Install8CF9B42AB7B91C9] Default=m0o8933l.default-release Locked=1
Now I could set my "foo" profile as default from profile manager or by about:config page, but the problem would still persist after next firefox update.
So, nothing solved I would say...
Hints really appreciated, thank again!
Hmm, where are "99EE9573B7C0378A" and "8CF9B42AB7B91C9" coming from?
I think it might be a hash of the install location/path, computed when the new Firefox build starts up for the first time and reads/updates installs.ini and profiles.ini. If you are launching each new build of Firefox in a new directory, maybe that's the problem.
I build firefox packages for Slackware Linux by using a bash script called latest-firefox.sh. It basically download RPM binaries released by mozilla and re-package them to adapt them to Slackware. Here you'll find the script on github page thanks to "ruario":
https://gist.github.com/ruario/9672798
I have to read better all comments under the script, maybe some other user noticed my same issue.
Anyway, I don't know how that hash is generated, but in this case we don't start from firefox source code to build, it's just a repackaged of binaries built and released remotely by mozilla.
Does the build process execute the first run of Firefox from a new path? The reason I focus on the path is that it's mentioned in the comments for the GetInstallHash() function:
https://searchfox.org/mozilla-release/source/toolkit/mozapps/update/common/commonupdatedir.cpp#383
If every build executes firefox.exe from a new path, it would make sense that each gets a unique Install Hash and therefore needs its own profile.
Вибране рішення
Aha, yes, known issue with the script:
https://gist.github.com/ruario/9672798?permalink_comment_id=3507704#gistcomment-3507704
Lots of subsequent comments, so hopefully something there will help out.
Seems you did bingo! Issue depends exactly to the "path" in which is installed firefox binary file.
The script I used creates a package that installs it within a path containing version number of firefox: ``` /usr/lib64/firefox-115.0.2/firefox /usr/lib64/firefox-115.0.2/firefox-bin ``` The hash as you pointed out is generated by that path. When I upgrade that path changes, hash changes and the new firefox create a new profile linked to the new hash (and differs by the old default profile).
By reading latest-firefox.sh gist they have patched this issue, now the path contains the firefox "channel" (latest, esr, beta...). So the path should become something like:
/usr/lib64/firefox-latest/firefox
And it remains the same as far as upgrades belong to the same "channel". If I try to upgrade to a "beta" version that path will change (/usr/lib64/firefox-beta/firefox) and a new profile will be created when FF will be restarted. I think it's a proper solution.
I have to test the patched version of the script and simulate an upgrade from a regular channel version or some time ago link 115.0.0 or a bit older, clean up profiles.ini and install.ini and retry the upgrade.
It works! The above script can build a package for a past version by launch with explicit VERSION set to it, I tried 114.02:
VERSION=114.0.2 latest-firefox.sh
- Installed the package produced (downgrading from previous installed 115.0.2) - removed installs.ini and clean up profiles.ini leaving just my profile section "Profile0". - startup "firefox -allow-downgrade -p", remove all profiles (maybe I did it before this step) except mine - close firefox - installs.ini is populated by a new section with its hash, profiles.ini has one new install section referred to the same hash of installs.ini new file and a new "General" section.
Finally created the new package (this time without force version, it will build the latest regular, 115.0.2 as today):
latest-firefox.sh upgradepkg /tmp/{newpackage...}
And now when I start firefox it opens up my regular profile without creating and setting a new one. Mission complete!
Thanks all for your help!
Thank you for reporting back. This discussion gives me a little more confidence in manually editing installs.ini and profiles.ini going forward.