Discussion:
Cannot remove MySQL completely
(too old to reply)
pinnerite
2022-01-17 11:48:05 UTC
Permalink
Recent posts have culminated in my not being able to remedy a corruption in the user table.

I decided to remove MySQL and reinstall.

First I did:

$ sudo apt purge mysql*
$ sudo apt autoremove
$ sudo apt update

When I reinstalled, the corrupt user table was still there.

I tried again from Synaptic.

Same result.

How can I resolve this?
--
Mint 20.3, kernel 5.4.0-95-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of DRAM.
Bit Twister
2022-01-17 12:26:04 UTC
Permalink
Post by pinnerite
Recent posts have culminated in my not being able to remedy a corruption in the user table.
I decided to remove MySQL and reinstall.
$ sudo apt purge mysql*
$ sudo apt autoremove
$ sudo apt update
When I reinstalled, the corrupt user table was still there.
I tried again from Synaptic.
Same result.
How can I resolve this?
Sounds like the removal does not delete the basic database.

Why not just delete all records in the desired table.

FYI: I tried your sql command you gave trying to change password checking
and did not find anything at all.

Other option is uninstall again, delete the database and see if pkg install
recreates it.

Read the last four lines of this post I'll wait . . . . . . . . . . . . . .
--
The warranty and liability expired as you read this message.
If the above breaks your system, it's yours and you keep both pieces.
Practice safe computing. Backup the file before you change it.
Do a, man command_here or cat command_here, before using it.
The Natural Philosopher
2022-01-17 13:22:51 UTC
Permalink
Post by Bit Twister
Other option is uninstall again, delete the database and see if pkg install
recreates it.
yup. delete package and /var/lib/mysql...
--
“it should be clear by now to everyone that activist environmentalism
(or environmental activism) is becoming a general ideology about humans,
about their freedom, about the relationship between the individual and
the state, and about the manipulation of people under the guise of a
'noble' idea. It is not an honest pursuit of 'sustainable development,'
a matter of elementary environmental protection, or a search for
rational mechanisms designed to achieve a healthy environment. Yet
things do occur that make you shake your head and remind yourself that
you live neither in Joseph Stalin’s Communist era, nor in the Orwellian
utopia of 1984.”

Vaclav Klaus
Axel Schwenke
2022-01-17 14:03:46 UTC
Permalink
Post by pinnerite
Recent posts have culminated in my not being able to remedy a corruption in the user table.
I decided to remove MySQL and reinstall.
This is not Windows. Your cannot solve problems by reinstalling software. Or
rebooting your computer.
Post by pinnerite
When I reinstalled, the corrupt user table was still there.
Because the data directory is not auto-removed. This is for safety. A fresh
datadir is only created if none exists.

Now: what "corruption" do you have in the `user` table? Keep in mind that
you should not operate on the user table with UPDATE and DELETE statements.
There are dedicated CREATE user and DROP user statements. Read the manual on
"Access Control and Account Management"
pinnerite
2022-01-17 16:57:50 UTC
Permalink
On Mon, 17 Jan 2022 15:03:46 +0100
Post by Axel Schwenke
Post by pinnerite
Recent posts have culminated in my not being able to remedy a corruption in the user table.
I decided to remove MySQL and reinstall.
This is not Windows. Your cannot solve problems by reinstalling software. Or
rebooting your computer.
Post by pinnerite
When I reinstalled, the corrupt user table was still there.
Because the data directory is not auto-removed. This is for safety. A fresh
datadir is only created if none exists.
Now: what "corruption" do you have in the `user` table? Keep in mind that
you should not operate on the user table with UPDATE and DELETE statements.
There are dedicated CREATE user and DROP user statements. Read the manual on
"Access Control and Account Management"
Thank you. Slightly too late - this time. I have completely restored MySQL.
The corupt data is gone.

At the moment I can only get int MySQL from a root prompt.

Otherwise it asks for the root password which I have not set(?).
--
Mint 20.3, kernel 5.4.0-95-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of DRAM.
Axel Schwenke
2022-01-18 09:44:47 UTC
Permalink
Post by pinnerite
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!

Read also the Debian README. Package maintainers often add extra $FOO to
packages. In the past Debian used to ask for a password for account name
'root' (which is traditionally the Superuser account). Now this is no longer
neccessary because socket authentication helps with identification of users.

Normally the first thing you do is create an account for yourself. If you
are connecting remotely (that means: the client is not running on the same
machines than the server) it includes setting a password.

And if you are running an application using the database (i.e. MythTV) then
it's highly recommended to create a MySQL account that is restricted to the
tables for that application.


XL
pinnerite
2022-01-18 12:48:59 UTC
Permalink
On Tue, 18 Jan 2022 10:44:47 +0100
Post by Axel Schwenke
Post by pinnerite
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!
Read also the Debian README. Package maintainers often add extra $FOO to
packages. In the past Debian used to ask for a password for account name
'root' (which is traditionally the Superuser account). Now this is no longer
neccessary because socket authentication helps with identification of users.
Normally the first thing you do is create an account for yourself. If you
are connecting remotely (that means: the client is not running on the same
machines than the server) it includes setting a password.
And if you are running an application using the database (i.e. MythTV) then
it's highly recommended to create a MySQL account that is restricted to the
tables for that application.
XL
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.

This means that I only have to engage with it once every two or three years.
Although I have textbooks on the subject, they are all obsolete because of the changes that are made between versions.

Changing distros can even mean having to deploy MariaDB, which I did for a few years.

Although I try to resolve my problems without recourse to bothering others, there comes a point when frustration takes over. I had reached that point.

If i had known where the database was held (/var/lib/mysql) earlier, I might have saved myself and others some trouble.

I always record the process of overcoming problems and the related advice in the hope of not making the same mistake more than once but sadly, the ground shifts. It is never exactly the same.

Thanks again, Alan
--
Mint 20.3, kernel 5.4.0-95-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of DRAM.
Axel Schwenke
2022-01-18 14:26:18 UTC
Permalink
Post by pinnerite
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.
Then let's take a step back. Something must have been broken so that you
started digging into MySQL accounts. What was it? Perhaps a broken (or at
least not up-to-date) mythtv package?

That's the whole point of having packages and maintainers. But of course
they need to know something is broken before they can act.
pinnerite
2022-01-18 16:40:16 UTC
Permalink
On Tue, 18 Jan 2022 15:26:18 +0100
Post by Axel Schwenke
Post by pinnerite
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.
Then let's take a step back. Something must have been broken so that you
started digging into MySQL accounts. What was it? Perhaps a broken (or at
least not up-to-date) mythtv package?
That's the whole point of having packages and maintainers. But of course
they need to know something is broken before they can act.
This is the User table prior to wiping out an starting again..
+------------------+------------------------------------------------------------------------+-----------+
| User | authentication_string | Host |
+------------------+------------------------------------------------------------------------+-----------+
| mythtv | *B5BCD029F2268798922CDC55B5253D354B2C0246 | % |
| debian-sys-maint | $A$005$F5%d'zoHMtJEX88t/x1bvIEMnwtseub5Tc7Z02gRpckab8.tZPnvPL5 | localhost |
| mysql.infoschema | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.session | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.sys | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
!ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost |
| root | *2B2E29BFA4C432ED2C7C49E07B175220796B98EE | localhost |
+------------------+------------------------------------------------------------------------+-----------+

Nothing I could do would change the erroneous hashed mythtv password nor could I remove the penultimate row with seemingly no user.

It is history now. I had a couple of weird problems with this version of Linux Mint.
One was solved with a fix.
The other, well that is MythTV but I will get there.

Regards, Alan
--
Mint 20.3, kernel 5.4.0-95-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of DRAM.
Axel Schwenke
2022-01-19 16:43:45 UTC
Permalink
Post by pinnerite
Post by Axel Schwenke
Then let's take a step back. Something must have been broken so that you
started digging into MySQL accounts. What was it? Perhaps a broken (or at
least not up-to-date) mythtv package?
This is the User table prior to wiping out an starting again..
+------------------+------------------------------------------------------------------------+-----------+
| User | authentication_string | Host |
+------------------+------------------------------------------------------------------------+-----------+
| mythtv | *B5BCD029F2268798922CDC55B5253D354B2C0246 | % |
| debian-sys-maint | $A$005$F5%d'zoHMtJEX88t/x1bvIEMnwtseub5Tc7Z02gRpckab8.tZPnvPL5 | localhost |
| mysql.infoschema | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.session | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.sys | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
!ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost |
| root | *2B2E29BFA4C432ED2C7C49E07B175220796B98EE | localhost |
+------------------+------------------------------------------------------------------------+-----------+
I see nothing wrong here.
Post by pinnerite
Nothing I could do would change the erroneous hashed mythtv password nor could I remove the penultimate row with seemingly no user.
I see no row with no user. I see garbled output for whatever reason. What
reports SHOW GRANTS ? And the hash for the 'mythtv' user looks ok. And it
would be a trifle so set it to something else with CHANGE PASSWORD ...

So you are basically complaining about *nothing*. Or - to be more precise -
about things that you don't understand and believe to be erroneous.

<shrug>


XL
pinnerite
2022-01-20 12:44:30 UTC
Permalink
On Wed, 19 Jan 2022 17:43:45 +0100
Post by Axel Schwenke
Post by pinnerite
Post by Axel Schwenke
Then let's take a step back. Something must have been broken so that you
started digging into MySQL accounts. What was it? Perhaps a broken (or at
least not up-to-date) mythtv package?
This is the User table prior to wiping out an starting again..
+------------------+------------------------------------------------------------------------+-----------+
| User | authentication_string | Host |
+------------------+------------------------------------------------------------------------+-----------+
| mythtv | *B5BCD029F2268798922CDC55B5253D354B2C0246 | % |
| debian-sys-maint | $A$005$F5%d'zoHMtJEX88t/x1bvIEMnwtseub5Tc7Z02gRpckab8.tZPnvPL5 | localhost |
| mysql.infoschema | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.session | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
| mysql.sys | $A$005$THISISACOMBINATIONOFINVALIDSALTANDPASSWORDTHATMUSTNEVERBRBEUSED | localhost |
!ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost |
| root | *2B2E29BFA4C432ED2C7C49E07B175220796B98EE | localhost |
+------------------+------------------------------------------------------------------------+-----------+
I see nothing wrong here.
Post by pinnerite
Nothing I could do would change the erroneous hashed mythtv password nor could I remove the penultimate row with seemingly no user.
I see no row with no user. I see garbled output for whatever reason. What
reports SHOW GRANTS ? And the hash for the 'mythtv' user looks ok. And it
would be a trifle so set it to something else with CHANGE PASSWORD ...
So you are basically complaining about *nothing*. Or - to be more precise -
about things that you don't understand and believe to be erroneous.
<shrug>
XL
So you know that the hash for 'mythtv' looks OK. It just happens to be the wrong hash.
I could not change it to the correct one.

So what is the user for: > > !ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost | ?

Anyway it is arbritary as I deleted the database and started again.

Alan
--
Mint 20.3, kernel 5.4.0-95-generic, Cinnamon 5.2.7
running on an AMD Phenom II X4 Black edition processor with 16GB of DRAM.
Axel Schwenke
2022-01-20 15:50:28 UTC
Permalink
Post by pinnerite
On Wed, 19 Jan 2022 17:43:45 +0100
Post by Axel Schwenke
I see no row with no user. I see garbled output for whatever reason. What
reports SHOW GRANTS ? And the hash for the 'mythtv' user looks ok. And it
would be a trifle so set it to something else with CHANGE PASSWORD ...
So you are basically complaining about *nothing*. Or - to be more precise -
about things that you don't understand and believe to be erroneous.
So you know that the hash for 'mythtv' looks OK. It just happens to be the wrong hash.
One can (of course) not see that. That's the reason why the password is
hashed in the first place. But even if you lost the original password in
clear text - it's just that. Not an error in stored MySQL credentials.
Post by pinnerite
I could not change it to the correct one.
Because you didn't try it the correct way. RTFM on CHANGE PASSWORD!
Post by pinnerite
So what is the user for: > > !ug2Ym[S%/K+ca2n7M06VWGOgOzJFxxKkrg/c7pjNT6Dm3n3FzLXm56 | localhost | ?
That is garbled output. It's missing not only a complete field (the
username) but also the table decorations that the client puts around the
data fields. Probably due to unprintable characters.

And again. You are doing the wrong thing.

You should not go and SELECT from the mysql.user table directly (at least
not when you cannot interpret what you get back). Instead you should use
SHOW GRANTS. And yes, RTFM on that too.


XL
Jerry Stuckle
2022-01-18 20:49:08 UTC
Permalink
Post by pinnerite
On Tue, 18 Jan 2022 10:44:47 +0100
Post by Axel Schwenke
Post by pinnerite
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!
Read also the Debian README. Package maintainers often add extra $FOO to
packages. In the past Debian used to ask for a password for account name
'root' (which is traditionally the Superuser account). Now this is no longer
neccessary because socket authentication helps with identification of users.
Normally the first thing you do is create an account for yourself. If you
are connecting remotely (that means: the client is not running on the same
machines than the server) it includes setting a password.
And if you are running an application using the database (i.e. MythTV) then
it's highly recommended to create a MySQL account that is restricted to the
tables for that application.
XL
I appreciate you taking the trouble to reply in detail but you must understand thast I am not a regular user of MySQL and have only ever used it when employing MythTV.
This means that I only have to engage with it once every two or three years.
Although I have textbooks on the subject, they are all obsolete because of the changes that are made between versions.
Changing distros can even mean having to deploy MariaDB, which I did for a few years.
Although I try to resolve my problems without recourse to bothering others, there comes a point when frustration takes over. I had reached that point.
If i had known where the database was held (/var/lib/mysql) earlier, I might have saved myself and others some trouble.
I always record the process of overcoming problems and the related advice in the hope of not making the same mistake more than once but sadly, the ground shifts. It is never exactly the same.
Thanks again, Alan
Alan,

All of the answers to your questions are in the documentation. It's
quite extensive and complete.

But that's like saying all of the words in the English Language are in
the Oxford English Dictionary. They are - but good luck finding the
right word if you don't know what you're looking for.
--
==================
Remove the "x" from my email address
Jerry Stuckle
***@attglobal.net
==================
Dr Eberhard Lisse
2022-01-19 10:29:15 UTC
Permalink
TLDR :-)-O

AKA Generation Z :-)-O

el
Post by Jerry Stuckle
Post by pinnerite
On Tue, 18 Jan 2022 10:44:47 +0100
Post by pinnerite
At the moment I can only get int MySQL from a root prompt.
Otherwise it asks for the root password which I have not set(?).
This is on purpose. Again: RTFM!
Read also the Debian README. Package maintainers often add extra
$FOO to packages. In the past Debian used to ask for a password for
account name 'root' (which is traditionally the Superuser account).
Now this is no longer neccessary because socket authentication helps
with identification of users.
Normally the first thing you do is create an account for yourself.
If you are connecting remotely (that means: the client is not
running on the same machines than the server) it includes setting a
password.
And if you are running an application using the database (i.e.
MythTV) then it's highly recommended to create a MySQL account that
is restricted to the tables for that application.
XL
I appreciate you taking the trouble to reply in detail but you must
understand thast I am not a regular user of MySQL and have only ever
used it when employing MythTV.
This means that I only have to engage with it once every two or three
years. Although I have textbooks on the subject, they are all
obsolete because of the changes that are made between versions.
Changing distros can even mean having to deploy MariaDB, which I did for a few years.
Although I try to resolve my problems without recourse to bothering
others, there comes a point when frustration takes over. I had
reached that point.
If i had known where the database was held (/var/lib/mysql) earlier,
I might have saved myself and others some trouble.
I always record the process of overcoming problems and the related
advice in the hope of not making the same mistake more than once but
sadly, the ground shifts. It is never exactly the same.
Thanks again, Alan
Alan,
All of the answers to your questions are in the documentation. It's
quite extensive and complete.
But that's like saying all of the words in the English Language are in
the Oxford English Dictionary. They are - but good luck finding the
right word if you don't know what you're looking for.
--
To email me replace 'nospam' with 'el'
Jerry Stuckle
2022-01-19 22:15:38 UTC
Permalink
Post by Dr Eberhard Lisse
TLDR :-)-O
AKA Generation Z :-)-O
el
Alan,
All of the answers to your questions are in the documentation.  It's
quite extensive and complete.
But that's like saying all of the words in the English Language are in
the Oxford English Dictionary.  They are - but good luck finding the
right word if you don't know what you're looking for.
Two short paragraphs are too long? ROFLMAO!

And please learn to follow Usenet posting guidelines - which include
posting your response either inline with the comments or following the
comments (like this one) - not at the top of the page.
--
==================
Remove the "x" from my email address
Jerry Stuckle
***@attglobal.net
==================
Dr Eberhard Lisse
2022-01-20 13:30:34 UTC
Permalink
That would make it even more difficult for the Generation Z'ers.

el
Post by Jerry Stuckle
Post by Dr Eberhard Lisse
TLDR :-)-O
AKA Generation Z :-)-O
el
Post by Jerry Stuckle
Alan,
All of the answers to your questions are in the documentation. It's
quite extensive and complete.
But that's like saying all of the words in the English Language are
in the Oxford English Dictionary. They are - but good luck finding
the right word if you don't know what you're looking for.
Two short paragraphs are too long? ROFLMAO!
And please learn to follow Usenet posting guidelines - which include
posting your response either inline with the comments or following the
comments (like this one) - not at the top of the page.
--
To email me replace 'nospam' with 'el'
Jerry Stuckle
2022-01-20 18:06:37 UTC
Permalink
Post by Dr Eberhard Lisse
That would make it even more difficult for the Generation Z'ers.
el
And obviously too difficult for someone who claims to have a PHD.
--
==================
Remove the "x" from my email address
Jerry Stuckle
***@attglobal.net
==================
Loading...