| Summary: | Upgrading from mga4 needs mysql_upgrade | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | Thomas Spuhler <thomas> |
| Component: | RPM Packages | Assignee: | AL13N <alien> |
| Status: | RESOLVED OLD | QA Contact: | |
| Severity: | major | ||
| Priority: | Normal | CC: | davidwhodgins, laidlaws, marja11 |
| Version: | Cauldron | Keywords: | IN_ERRATA5 |
| Target Milestone: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | MGA5TOO | ||
| Source RPM: | mariadb-10.0.17-1.mga5 | CVE: | |
| Status comment: | |||
| Attachments: | Error message | ||
|
Description
Thomas Spuhler
2015-05-03 02:22:16 CEST
Created attachment 6431 [details]
Error message
Error Message attached
I am going to rate this as a release blocker. This is a DB that is used extensively and w/o upgrading we may loose data. Please feel free to rate it differently Priority:
Normal =>
release_blocker whoa... don't exagerrate... there is no losing data here... but the information should be adjusted... there has been upstream some discussion on what type of systemd unit and with automatic upgrade and such, but afaik there is no final version yet... Decreasing priority, this does not affect the installer so it can be fixed after the Mageia 5 release. At this stage, release blockers should only be bugs affecting the installer or that bring severe usability or security issues. Priority:
release_blocker =>
Normal (In reply to AL13N from comment #3) > whoa... don't exagerrate... there is no losing data here... > > but the information should be adjusted... > > there has been upstream some discussion on what type of systemd unit and > with automatic upgrade and such, but afaik there is no final version yet... I am glad there will be no lose of data. But w/o upgrade the logs surely look scary. Just experienced the original bug. Started mysql first and the upgrade ran to conclusion. But it wasn't my real problem. CC:
(none) =>
laidlaws This package has been upgraded, but this bug hasn't been touched.
Samuel Verschelde
2015-05-19 23:45:19 CEST
Whiteboard:
(none) =>
MGA5TOO FOR_ERRATA Can't comment. Haven't had occasion to try again. The README.urpmi has: systemctl stop mysqld.service TMPDIR=/var/tmp mysql_install_db mysql_upgrade --skip-write-binlog Deleting the first line should do it? Should there be an extra / in Line 2 ? I did an update. I just run mysql_upgrade but the server must be running. Would: systemctl stop mysqld.service TMPDIR=/var/tmp mysql_install_db systemctl start mysqld.service mysql_upgrade --skip-write-binlog Be ok? According to https://mariadb.com/kb/en/mariadb/upgrading-from-mariadb-55-to-mariadb-100/ all that is required and recommended is to run: mysql_upgrade some distros do it automatically at upgrade, but I am not in favor of it. The database/sysadmin should decide when to run it. It'd nice from AL13N to comment, we just need to put the relevant instructions in release notes and in the message showed to the user after upgrade. I'm still eager to add this to Errata but I really don't know what to write! (In reply to Samuel VERSCHELDE from comment #13) > I'm still eager to add this to Errata but I really don't know what to write! or release notes The message you need to get across is, IMO, from my Comment 8, that the line: systemctl stop mysqld.service is wrong. If mysqld.service is running, leave it that way. Perhaps change the sentence "So, doing something like this might help you:" to "Mariadb must be running when you do the following: TMPDIR=/var/tmp mysql_install_db mysql_upgrade --skip-write-binlog" but I am not really happy with that either, as a way of putting the message across. added Paragraph to errata. (In reply to Thomas Spuhler from comment #16) > added Paragraph to errata. https://wiki.mageia.org/en/Mageia_5_Errata#Upgrading_Mariadb Thanks, Thomas :-) CC:
(none) =>
marja11 (In reply to Marja van Waes from comment #17) > (In reply to Thomas Spuhler from comment #16) > > added Paragraph to errata. > > https://wiki.mageia.org/en/Mageia_5_Errata#Upgrading_Mariadb > > Thanks, Thomas :-) Are we now happy with ERRATA or are we going to fix this one day? there's discussion on how to fix this upstream with systemd... do you really want to do this automatically? I would prefer to fix the message and then leave it alone. Can it be done automatically if the sql root user has a password, as recommended by /usr/share/doc/mariadb/README.urpmi ? CC:
(none) =>
davidwhodgins I have had this problem only once, and I would be happy with an "errata." I will leave it to the sysadmins to decide. One less fiddle may be welcome to them. actually, if upstream has a clean way of doing this, that would be great, but with auth_pam, a password might not even be needed, for a system account... i would prefer to fix this with upstream and just have a message and wait for them to fix this in a better way... Why don't we fix the error in the README.urpmi and move on. That was my thought from the beginning, but I am not a sysadmin. This bug is set to Version: cauldron, but I understand this is _no_ problem for Mga5=>6, correct? Please set this report to Version: 5, and remove MGA5TOO from the whiteboard if it won't be a mga5->6 upgrade problem. Or, if it will be a problem, either: * add the FOR_ERRATA6 keyword * add the IN_ERRATA6 keyyword and also add a note about it to: https://wiki.mageia.org/en/Mageia_6_Errata#Mariadb Keywords:
(none) =>
IN_ERRATA5 (In reply to Marja van Waes from comment #26) > This bug is set to Version: cauldron, but I understand this is _no_ problem > for Mga5=>6, correct? @ AL13N I suppose you know? > > Please set this report to Version: 5, and remove MGA5TOO from the whiteboard > if it won't be a mga5->6 upgrade problem. > > Or, if it will be a problem, either: > * add the FOR_ERRATA6 keyword > * add the IN_ERRATA6 keyyword and also add a note about it to: > https://wiki.mageia.org/en/Mageia_6_Errata#Mariadb I haven't needed to upgrade for a while. Currently running 6 RC. I make every distro upgrade a reinstall. I delete existing databases, restore them from a backup, grant permissions all over again, and that is all I need to do. Maybe I need to restore the db containing the permissions as well, but I have only two small databases. So I can't really help Marja. Thanks for trying to answer my question, Doug. No one reported that this bug still exists for mga5=>6 upgrades, so closing this bug as OLD. Resolution:
(none) =>
OLD |