I have a self hosted install that I have been running for many years, and as per alot of these things, with all good intensions, it hasnt been kept up to date, its been doing the job and turned into one of those classic “ill update that at some point when i get time” but has never happened… Anyway, years have gone past, and have recently upgraded my local virtual server, so have been moving all my services etc across..
Thought this would be a good time to update to most recent version of farmos at the same time, problem I have is the old server was on a much older version of PHP (7.3 i think but not got it booted currently to check), and much older version of linux (Ubuntu Server 16 i think), the new host is running Ubuntu Server 24.04 and PHP 8, but unfortantly havent been able to get it going by overwriting a backup of my old files and SQL database.
I imagine this is just because im skipping so many versions and its such a big change… My question is, ideally id rather run the docker container as its advised and easier to manage, but my question would be, if i fire up the official docker container, which is no problem, how can I go about importing my existing sql / data with it being from a much older version? Any advise much appreiciated as have spent quite a bit of time trying to get it going again!
Also to add a bit of context, I have tried spinning up a new docker, pointing it to the old database, and copying the old “sites” older across, and then I just get the error:
Error I get in the docker log when trying to run the update.php:
“
10.0.0.136 - - [12/Dec/2025:11:36:48 +0000] “GET /update.php HTTP/1.1” 500 284 “-” “Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/143.0.0.0 Safari/537.36”
[Fri Dec 12 11:36:48.893934 2025] [php:notice] [pid 22:tid 22] [client 10.0.0.136:56106] Symfony\\Component\\DependencyInjection\\Exception\\ServiceNotFoundException: You have requested a non-existent service “access_check.db_update”. in /opt/drupal/vendor/symfony/dependency-injection/ContainerBuilder.php on line 993 #0 /opt/drupal/vendor/symfony/dependency-injection/ContainerBuilder.php(568): Symfony\\Component\\DependencyInjection\\ContainerBuilder->getDefinition(‘access_check.db…’)\n#1 /opt/drupal/vendor/symfony/dependency-injection/ContainerBuilder.php(531): Symfony\\Component\\DependencyInjection\\ContainerBuilder->doGet(‘access_check.db…’, 1)\n#2 /opt/drupal/web/core/lib/Drupal/Core/Update/UpdateKernel.php(185): Symfony\\Component\\DependencyInjection\\ContainerBuilder->get(‘access_check.db…’)\n#3 /opt/drupal/web/core/lib/Drupal/Core/Update/UpdateKernel.php(102): Drupal\\Core\\Update\\UpdateKernel->handleAccess(Object(Symfony\\Component\\HttpFoundation\\Request))\n#4 /opt/drupal/web/core/lib/Drupal/Core/Update/UpdateKernel.php(76): Drupal\\Core\\Update\\UpdateKernel->handleRaw(Object(Symfony\\Component\\HttpFoundation\\Request))\n#5 /opt/drupal/web/update.php(27): Drupal\\Core\\Update\\UpdateKernel->handle(Object(Symfony\\Component\\HttpFoundation\\Request))\n#6 {main}”
Ah OK - if you were running Drupal 7 then that is farmOS v1. That is old!
And more complicated to update from… the jump from v1 to v2 was a “migration” moreso than an “update”, because we basically rewrote farmOS from scratch on Drupal 9 (because the jump from Drupal 7 to Drupal 8 was equally disruptive for everyone - a very large sea-change modernization of the architecture).
Also, it is not possible to update from v1 to v3. You have to migrate to v2 first, and then update to v3. So what this means is you’ll need to set up a new v2 instance first. That’s your first step. I would recommend doing it in a Docker container with a PostgreSQL database.
The nice thing about the v1->v2 migration is it doesn’t make any changes to your v1 database. You set up your v2 instance alongside it and run the migration to copy data into it (and you’ll copy files manually - per the docs). This means you can test it out and get it working without disrupting your v1 workflow, and once you’ve tested it all you can wipe the v2 database and run a “final” migration, make v2 your new “canonical” database moving forward, and archive your v1 database as a backup.
Then, you can update to v3, and that is a much easier process. Documented here: Updating farmOS | farmOS
Good luck! Happy to answer questions as you dig into it. It’s been a little while since I’ve done a v1->v2 migration, so my memory is a bit stale, but I did enough of them that I can probably still give advice.
Also worth mentioning: we are getting close to the first release of farmOS v4! So this is a good time to get started on the update process. The update from v2->v3 and v3->v4 is much easier than the migration from v1->v2, so once you’re over that hurdle it should be pretty smooth sailing.
I’m not sure what all the [warning]s are from, but it does look like the migration is working… it successfully migrated the settings (system of measurement + timezone), roles, users, and most of the files. But it failed on 2 of the files.
See Migrating from farmOS v1 | farmOS for how to view a list of messages from the farm_migrate_file migration to see what’s wrong, address it, then reset the status and re-run the migration.
Tried running through each step manually, all fine until i get to the migrate_log, it starts doing it, and then stops… then i tried running the messages command, results of both are below, any thoughts?
From a quick google almost seems maybe like one of the field maps has a border that touchs itself somewhere? But errors dont show which one is the issue…
Yep one (or more) of the logs has an invalid geometry saved to it. farmOS v1’s geometry validation wasn’t perfect, and that sometimes resulting in invalid data getting saved to the database. You’ll need to figure out which one(s) it is and manually fix it.
Each log type has its own migration, so there is no farm_migrate_log migration.
Use this to see a list of all the migrations, and the status of each:
Then I would suggest rolling back that specific migration (drush migrate:rollback [migration_id]) and re-running the log migration group (drush migrate:import --group=farm_migrate_log).
Once you get all of this working, I would recommend wiping your new v2 database and doing the whole thing again from scratch. Then you can be confident that everything migrated smoothly, and the errors didn’t have any unforeseen impact.
Would seem its “farm_migrate_input_log” its stalling on, as others all say idle when i run that command, but that one ays importing…. How on earth am i meant to figure out which log has a problematic bit of data saved with it….
Managed to sort it, I suddenly thought, back in the day I used to import a KML from AgOpenGPS with all my sprayer / fert records, and thought i bet its one of these thats messed, there all from many years ago so just deleted the records enirelyt as not eneded now, did a clean docker install again and tried again and its all migrated. So for anyone else reading, step 1 from V1-V2 is complete. Hopefully the posts above may help someone else, now to attempt to upgrade to V3…..
