I have searched the existing open and closed issues
Required Information
DietPi version | G_DIETPI_VERSION_CORE=9
G_DIETPI_VERSION_SUB=18
G_DIETPI_VERSION_RC=1
G_GITBRANCH=‘master’
G_GITOWNER=‘MichaIng’
G_LIVE_PATCH_STATUS[0]=‘applied’
Distro version | trixie 0
Kernel version | Linux DietPi 6.12.47+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.47-1+rpt1 (2025-09-16) aarch64 GNU/Linux
Architecture | arm64
SBC model | RPi 3 Model B+ (aarch64)
Power supply used | (5V 1A RAVpower)
SD card used | SanDisk ultra
Additional Information (if applicable)
Software title | Baikal
Was the software title installed freshly or updated/migrated? Freshly installed
Can this issue be replicated on a fresh installation of DietPi? Don’t know
← If you sent a “dietpi-bugreport”, please paste the ID here →
Bug report ID | echo $G_HW_UUID
Steps to reproduce
Try to login into Baikal-Server after upgrade from Bookworm to Trixie
…After Updating from Bookworm to Trixie, everything works fine, except Baikal-Server
…
Expected behaviour
Login into a new database works fine
…
Actual behaviour
could not find driver in /var/www/baikal/Core/Frameworks/Flake/Core/Database/Sqlite.php…
…
Extra details
After multiple attempts the solution was: “sudo apt install php8.4-sqlite3”, the package, that was obviously missing. After that: “sudo phpenmod sqlite3 pdo_sqlite”, and finally "sudo systemctl restart php8.4-fpm,
sudo systemctl restart apache2. Last step: I copied the “old” database db.sqlite to /var/www/baikal/Specific/db/
After that, I could login and everything was in place as expected.
We should probably mention such more prominently with some prompt at the end of the installation, linking our docs. I can imagine many might not even know that we have specific docs for each software title with by times first run setup steps. And in case of database usage, usually SQLite is preconfigured, since it does not require any additional info but works OOTB.
Otherwise, when manually installing PHP applications, same as with Python projects, it is expected that dependency modules need to be installed again for the new PHP/Python version. In case of PHP and SQLite, these two steps should be sufficient:
The package installation should enable the modules automatically. The webserver is unrelated and does not need to be restarted. And not sure what you meant with “old database”, and why you needed to copy it around? The distro upgrade does not change the Baïkal install and config, and hence should not have any effect on the path of the SQLite database.
honestly, I can’ t remember, since I use this setup for a couple of years now. But I’ve never seen an option, as far as I remember, using MariaDB as database. There was always the choice between MYSQL and SQlite, when setting up Baikal.
I have two almost identical Raspberry devices, one for “productive” purposes, the other one for testing. Every two years when a new Debian edition comes out, I use the testing device to see if everything works with the new Debian and if so, they sooner or later change places and I simply have to change the IP for the local DNS within the router. Since everything works fine now with Trixie, the time has come to change the devices. Basically they run Nextcloud, Baikal, Pihole and unbound.
When I ran into this issue with Baikal on the Testing-Trixie-Installation, I uninstalled and reinstalled Baikal from your software repository with no effect and SQlite displayed the same errors. (Still there was no option for MariaDB). So I did some research and came up with the solution I described in my post.
By the way, there is a mariadb service running on both devices, but I can’t remember for what purpose
A few years ago for some reasons I had to use a newer version of Baikal than the one in your repository and presumeably that was the point, where I did an manual installation, but I can’t remember.
If there are serious reasons for using MariaDB instead of SQlite I will do so, provided someone tells me how to do so. On the other hand: “never change a running system”
Ah yeah sorry, MariaDB = MySQL essentially, just fully FLOSS, forked by original MySQL founder after Oracle started to ruin MySQL from free software POV.
SQLite is easy, but not well suited for larger databases or concurrent accesses, since it means an individual process to access an on-disk file on every query, without any memory caching outside of plain filesystem cache. It works for smaller databases and low amount of clients, so for a home Baïkal instance it should work okay. But MariaDB, as true database server, meant for high concurrency handling with proper caching. Since you use Nextcloud, you have MariaDB installed and in use anyway, so not much reason to not use it with Baïkal as well.
Since you did set it up with SQLite, the question only is how to migrate the database. Both SQL dialects are not 100% compatible … let’s see, can be tested without much risk. But at best do on the test instance, and connect with a test client, to see whether all calendar and contact entries are still present as expected, without errors thrown by PHP etc:
cd /tmp
sqlite3 /var/www/baikal/Specific/db/db.sqlite .dump > baikal.sqlite
# The following can take some minutes, depending on database size
curl -F 'files[]=@baikal.sqlite' 'https://www.rebasedata.com/api/v1/convert?outputFormat=mariadb&errorResponse=zip' -o output.zip
apt install unzip # just in case not installed yet
unzip output.zip
sudo mysql baikal < data.sql
Then, in Baïkal web UI, database settings, adjust things according to the docs. Connect with a client to sync, and verify everything got migrated, and PHP does not throw errors:
many thanks for this extended support. Yes, my main question was, how to convert databases from SQlite to MariaDB.
The whole process is a bit of a challenge, but I will do so on my test device. And in Thunderbird/Betterbird I can set up an additional connection to that second DAV-calendar and addressbook, to see how it works.
Yeah, sadly does neither SQLite have a feature to export a database into a different (well-known) SQL dialect, nor has MariaDB such import feature. Searching the web about how to migrate from SQLite to MariaDB covers only a small number of needed syntax adjustments, while the very first line of the .dump in my case was incompatible already, and not covered. There are migration tools like in Python etc, but the web API seem to work sort of reliable, without the need to install anything else. Not awesome, but worked for me.
Another approach is to just leave the MariaDB database empty, and let a client sync everything back. Then no migration is needed. But I would be afraid that some client syncs the empty calendar and contact list from the server, instead of the full ones to the server. Since we cannot be sure how different clients behave, better go with the migration, which at best means that no client needs to sync anything as they all face the exact same data at the server than before.
My first try was to setup a new addressbook and a new calendar in Betterbird and connected it with the newly setup empty MYSQL-database on the test instance. Exported addressbook and Calendar from the current device and reimported it into the new addressbook and calendar. Immediately the addressbook was synchronized but the calendar throwed several errors during import and stopped. Manually I edited the ics-calendar file and deleted double UIDs with no effect. Still a lot of errors. Seems to me that mysql ist much more sensitive against database inconsistencies than sqlite.
Since my e-mail provider “Posteo” offers online calendars and addressbooks I was curious what would come out if I imported those ics and csv files. It worked with no errors. So now I have those identical online calendar and addressbook. But that was not the idea. I re-exported from posteo, hoping it might change anything. But still the same errors.
So for now, I gave up. Since I changed from sqlite to mysql on the test instance, I don’t want to mix things up using your rebasedata script.
Since sqlite works well on the test instance, the question is, if there is any need to do all this extra work with no satisfiying outcome. In the meantime I could have setup the new calendar manually, copying piece by piece from the old calendar.
I assume those errors were at BaiKal, not at rhe database backend. So it most likely would have failed with SQLite as well. The database table structures and which columns need to be unique is independant of the backend.
The problem is that CalDAV is not a 100% consistent standard. So some clients may generate ICS exports a way that some servers do not accept. Not sure whether BaiKal itself can generate an ICS export?
Did you try the online converter for the SQL dump?
Yeah, I was already wondering, but it was just <foo> brackets being interpreted as HTML tags and hence not visible in the message unless code-wrapped.
So generally appending ?export is correct: iCalendar Export Plugin - sabre/dav
I just wonder where authentication happens, probably just plain HTTP auth?
If you get a certificate issue: you have HTTPS enabled and use the correct hostname, i.e. the same as for Nextcloud? Else try with http:// and LAN IP. In browsers, you can usually ignore plain HTTP and cert warnings. But if you have a public HTTPS-enabled hostname, of course that would be preferred.
The Calendar Export Plugin solved the problem. I appended the code to cal.php as described in the document and could then export the calendar.ics. This time the import to the empty MySQL-database worked and I can proceed to plan the switch to the trixie-device. Calendar dates are exported only from no on. But there is a date parameter to include former events too for my next try.
The Calendar Export Plugin solved the problem. I appended the code to cal.php as described in the document and could then export the “calendar.ics”. This time the import to the empty MySQL-database worked and I can proceed to plan the switch to the trixie-device.
(Calendar dates are exported only from now on= made a mistake-not true)
Instead:
To avoid database inconsistencies I changed the date-parameter to “not before 2023”
Interesting, based on some related issue at Baikal GitHub I got the impression it is included OOTB. It is a dedicated sabre/dav plugin, but Baikal uses sabre/dav and can hence choose which plugin to add/enable.
A big problem is that Baikal has essentially no documentation (that I could fine), minimal install instructions without any mention of plugins, and no usage docs. It states to be based on sabre/dav which does have a documentation, but it is not obvious how and with which plugins sabre/dav is implemented, whether or how its API is wrapped etc.
To clarify about your two posts: So by default, without start= query parameter, it exports the whole calendar, or from now on?
Might be worth it to add/enable this plugin OOTB when installed via dietpi-software? When it is added manually, otherwise it needs to be repeated manually after every update.
. As if