MariaDB recovery and Stretch => Buster => Bullseye upgrade #4511
Labels
Comments
|
Hi, pls provide following information however the status doesn't looks good
|
|
Additionally to verify whether there is actual filesystem corruption: |
|
hey, the systemctl restart mariadb.service is already there, for the rest: |
|
Okay, it seems to be only a database-wise corruption. Please try the following:
Which software uses MariaDB in your case? |
|
I tired step 3 untill iteration 20... I think this is going nowhere :( So I stoped and didnt do step 4 or 5. I am using nextcloud. As I am using a VM I did a snapshot before the update. So if I can help you finding the reason to prevent this for others and make the update more stable, please let me know what to do :) |
|
To be honest, this has nothing to do with DietPi update function. You got a corrupted database file. This could have multiple reasons. At least on a VM we probably could exclude file system issue. But maybe unclean poweroff could lead to this. What you could try is to restore the snapshot, perform an |
|
OK, I will restore the snapshot, test and feedback :) |
|
You are right Joulinar! I did restore the snapshot, performed an Everything working now. And you were right with your idea. There really was a poweroff here in my region so that could be the cause. Sorry guys for taking your time and thanks for helping me! :) |
|
you are welcome, better to check on such issues. 😃 Btw: you should think of migrating to Debian Buster as you still running Stretch. Sooner or later Nextcloud might gonna drop support for old MariaDB version 10.1. As well next Debian version Bullseye will be released soon and Stretch become oldold. |
Valid levels are only 1-6 😉. Good idea to recover a backup/snapshort, I totally forgot to ask about that, great that it worked 👍. |
"Migration" sounds so nice and easy :D I think this would mean to setup everything from For me that would mean 2 weeks of work ;D But having snapshots as a backup makes it possible to give it a try |
TL;DR: Definitely worth to give it a try! Based on my Wheezy => Jessie => Stretch distro upgrade experiences, I would have assumed to same, that it most likely fails at some point, but I am surprised that in every case where we got a feedback about the upgrade Stretch => Buster, it went well. I personally upgrade my systems directly to the new testing suite, after a release, when there is not difference between release and testing yet, so cannot say something about Stretch => Buster => Bullseye, but it seems to have improved a lot, hence became a quite reliable alternative to setup from scratch 🙂. |
|
Yes you could update from Stretch to Buster without performing a reinstall. Just have a look to following forum post https://dietpi.com/phpbb/viewtopic.php?p=18988#p18988 But we can't give a guarantee 😉 |
|
Just as a feedback: instructions on https://dietpi.com/phpbb/viewtopic.php?p=18988#p18988 worked with no issues 👍 |
|
Awesome, many thanks and great to know. I feel quite confident that we can guide Stretch users through a distro upgrade when dropping Stretch support. Plan is to migrate Stretch systems to a "stretch" branch first, to block DietPi updates to newest incompatible version, which was one purpose of the updater change with DietPi v7.0. There we add a script which guides or performs an interactive distro upgrade (interactive, so that all APT questions need to be answered/confirmed interactively) and, when succeeded, migrates them back to the master branch to update to latest DietPi version. |
|
thx for sharing. So basically you are ready to update to Bullseye that might be released end of July 2021 🤣 |
|
One thing we should take care of: When PHP was installed, Ondrej's repo should be removed revert to the PHP version from the main Debian repository. There are too many reports of users, when installing the PHP meta packages, ending up with PHP 8 (unintentionally), two parallel PHP instances, and will then get additionally PHP 8.1 once release 😄. @Phil1988 rm /etc/apt/sources.list.d/dietpi-php.list
rm /etc/apt/trusted.gpg.d/dietpi-php.gpg
rm /etc/apt/preferences.d/dietpi-php
rm /etc/apt/preferences.d/dietpi-openssl
/boot/dietpi/func/dietpi-set_software apt-cache clean
apt update
apt upgradeIt is possible that the |
|
currently I am using: I have not seen a problem since the upgrade so far. I already did a Should I perform anyways? and to @Joulinar: |
|
let's wait for @MichaIng before doing any further steps. But in theory you could use same procedure to update to Bullseye. It's already possible and there shouldn't be any surprises as Bullseye is already in a freeze mode and there is no major development happen anymore. |
|
Jep, upgrade to Bullseye works the same way. If you do so, Ondrej's repository needs to be removed and PHP and the webserver need to be reinstalled, as Bullseye does not ship PHP7.3 anymore but PHP7.4 instead. Also on Buster, just as a pre-caution against unintended PHP upgrades, I'd do the steps to remove Ondrej's repository: This was only added to maintain support for Debian Stretch, else most PHP application would have needed to be disabled, as most of them dropped support for PHP7.2 and below for a while. |
|
Well I am not able to do it as I am not confident enough to try and error :D 1 . I am still not sure if I should perform 2 . I am not sure, where I added ondrejs php repo (but I am pretty sure that I did that). It might also work to just 3 . For the update to Bullseye: 4 . To install PHP and the webserver, should I just and install the webserver from the dietpi-software? Sorry for those questions and many thanks for your help! |
|
You already have Apache2 installed. Therefore no need to install any other web server. For the update to Bullseye, it should looks like this it needs to be a But first, let's ask @MichaIng if he could help to ensure using correct PHP package 😃 |
|
And yes, please do the |
|
Hmmm... well the ppa stuff would be handy, as I dont know, where the created php (ondrej) files are sitting :D I did the following so far: Logfile attached. Click to expand!The bullseye upgrade: Logfile attached. Click to expand!This window appeared and I said "Ja" (yes): continued with: now the full upgrade Logfile attached. Click to expand!The I autopurged it: Logfile attached. Click to expand!and finally: What works now is:
Not working is the nextcloud. Interesstingly, the nextcloud seems to be uninstalled: |
|
can you check if the database is running What happen if you do It looks like MariaDB meta package has been removed |
|
Thank you Jouinar for editing my post to make collapsable spoilers (I'll remember this from now). for MariaDB: soo kind of "broken".... so this is not anymore soo off-topic :D Nextcloud: So at least mariaDB is missing and I think that the nextcloud can be reactivated with your knowledge, but all the data might be gone right? |
|
Sorry there was a typo
|
|
@MichaIng |
|
I've done this already and added Bullseye => Buster fallback when this was not found. So checking the But I guess many repos will start supporting Bullseye soon, so this needs to be reviewed. |
|
Ok great! So I hope this have not been too much information/command line copys, but I rather prefer to have it documented a little too much then not enough :) A and the
maybe considerable of you install it right away if NC is installed. Btw: I installed the brave browser just for your project and I hope I can tip you by that. The only thing that is still questionable from my side is, why there is no NC update visible. |
|
What is the version of NC you are running at the moment? |
|
I'm on Nextcloud 20.0.11
|
|
Let it run over night. Hope it's gonna change 😃 |
|
Haha ok! |
|
@MichaIng it would require as well |
|
Also good find (in the forum) about the security suite naming change, I totally forgot about that one (not relevant on Raspbian): sed -i 's|bullseye/updates|bullseye-security|' /etc/apt/sources.listAh yes we found that automatic This again depends on whether we want to install the deflate module by default on Bullseye or not. It's for compressed file transfer, so HTML, text, CSS and JavaScript files (by default) are compressed on the server, sent to the client, decompressed there. Less/faster data transfer but a little additional processing/CPU time on server and client. For removal: sed -i '/^compress\./d' /etc/lighttpd/lighttpd.conf
sed -i '/"mod_compress"/d' /etc/lighttpd/lighttpd.conf
systemctl restart lighttpdFor migration the lines above should be removed as well, then: apt install lighttpd-mod-deflate
lighty-enable-mod deflate
systemctl restart lighttpdAnother issue is that on Bullseye, even the SSL/TLS module is not present by default. That needs to be integrated into apt install lighttpd-mod-opensslEDIT: Regardless whether we install it by default, it makes sense that ... dietpi-software reinstall 84We could then even include the removal of those lines. |
|
@MichaIng
|
|
The second. I mean the first works as well, so does |
|
Hey! does the lighttpd also affect me? For let's encrypt (which I am using), its recommended to Ah and by the way: |
|
You are running Apache web server. Therefore |
|
Probably switching to Nextcloud beta branch will offer you the latest version. There is currently no beta version so the latest one it can offer you is a stable one. After the update, you can switch back to stable branch. |
|
Yes, that did it. Not automatically (I waited almost 3 hours) , but I had to push this: After this: |
|
I got some hints on the settings overview. Solving Nextcloud warning messagesFirst I did Then this remained which I solved by adding These have been pretty persistent Because I was sure I had to include this "somewhere" :D So first I included it here Later I booted my brain and thought about restarting apache2 to load the config. So adding to with an Last hint was about the "well loved" imagick. I hada a look at the supported formats: And saw no So I installed
But I still cant see any updates for Nextcloud at the stable channel . When I switch again to the beta channel I can see NC 22.0.0 I'm not sure if NC 22.0.0 is beta or stable (for me it seems to be stable, as I can download that version directly from nextcloud). |
|
NC 22 is stable, else the version string would be prefixed with beta or RC. As always, Nextcloud offers the updates in waves, so for NC 22 it is perfectly possible that you do not receive it when on stable channel. But for NC 21 this was strange 🤔. |
|
Ahh ok! I will have a look at this and if I dont get any updates, I may open a new issue during the next year :D |
|
We created an article about upgrading from Buster to Bullseye: https://dietpi.com/blog/?p=811 I'll mark this issue hence as closed, which was a great resource to catch upgrading issues and hence required steps. |
|
Great article! Very clear written with a good overview and good information 👍 BTW: Is there a bullseye realease coming out for VMware in the near future? (no pushing.. just as an information. Its ok that its done, when done ;) ) |
|
you could migrate existing VMWare Buster image to Bullseye |
|
Many thanks for your feedback. Yes I'll update all VM images the next days. |
|
Thanks for that! I am looking forward to it :) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Creating a bug report/issue
Required Information
DietPi version
G_DIETPI_VERSION_CORE=7
G_DIETPI_VERSION_SUB=2
G_DIETPI_VERSION_RC=3
G_GITBRANCH='master'
G_GITOWNER='MichaIng'
Distro version
stretch
Kernel version
Linux DietPi 4.9.0-16-amd64 #1 SMP Debian 4.9.272-1 (2021-06-21) x86_64 GNU/LinuxSBC model |
Virtual Machine (x86_64)
Additional Information (if applicable)
echo $G_HW_UUIDSteps to reproduce
Update from 7.1.2 to 7.2.3
Actual behaviour
mariadb doesnt start.
At bootup I get:
[FAILED] Dietpi-Services start : mariadbExtra details
Checked the ownership for mysql files but everything is ok
I hope you have ideas :)
The text was updated successfully, but these errors were encountered: