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.

On Mon, 17 Jan 2022 11:48:05 +0000, pinnerite wrote:
> 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?

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.

On 17/01/2022 12:26, Bit Twister wrote:
> 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

On 17.01.2022 12:48, pinnerite wrote:
> 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.

> 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"

On Mon, 17 Jan 2022 15:03:46 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:

> On 17.01.2022 12:48, pinnerite wrote:
> > 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.
>
> > 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.

On 17.01.2022 17:57, pinnerite wrote:
> 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

On Tue, 18 Jan 2022 10:44:47 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:

> On 17.01.2022 17:57, pinnerite wrote:
> > 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.

On 18.01.2022 13:48, pinnerite wrote:
>
> 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.

On Tue, 18 Jan 2022 15:26:18 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:

> On 18.01.2022 13:48, pinnerite wrote:
> >
> > 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.

On 1/18/2022 7:48 AM, pinnerite wrote:
> On Tue, 18 Jan 2022 10:44:47 +0100
> Axel Schwenke <axel.schwenke@gmx.de> wrote:
>
>> On 17.01.2022 17:57, pinnerite wrote:
>>> 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
jstucklex@attglobal.net
==================

TLDR :-)-O

AKA Generation Z :-)-O

el

On 18/01/2022 22:49, Jerry Stuckle wrote:
> On 1/18/2022 7:48 AM, pinnerite wrote:
>> On Tue, 18 Jan 2022 10:44:47 +0100
>> Axel Schwenke <axel.schwenke@gmx.de> wrote:
>>
>>> On 17.01.2022 17:57, pinnerite wrote:
>>>> 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'

On 18.01.2022 17:40, pinnerite wrote:
> Axel Schwenke <axel.schwenke@gmx.de> wrote:
>
>> 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.

> 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

On 1/19/2022 5:29 AM, Dr Eberhard Lisse wrote:
> TLDR :-)-O
>
> AKA Generation Z :-)-O
>
> el
>
> On 18/01/2022 22:49, Jerry Stuckle wrote:
>>
>> 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
jstucklex@attglobal.net
==================

On Wed, 19 Jan 2022 17:43:45 +0100
Axel Schwenke <axel.schwenke@gmx.de> wrote:

> On 18.01.2022 17:40, pinnerite wrote:
> > Axel Schwenke <axel.schwenke@gmx.de> wrote:
> >
> >> 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.
>
> > 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.

That would make it even more difficult for the Generation Z'ers.

el

On 20/01/2022 00:15, Jerry Stuckle wrote:
> On 1/19/2022 5:29 AM, Dr Eberhard Lisse wrote:
>> TLDR :-)-O
>>
>> AKA Generation Z :-)-O
>>
>> el
>>
>> On 18/01/2022 22:49, Jerry Stuckle wrote:
>>>
>>> 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'

On 20.01.2022 13:44, pinnerite wrote:
> On Wed, 19 Jan 2022 17:43:45 +0100
> Axel Schwenke <axel.schwenke@gmx.de> wrote:

>> 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.

> I could not change it to the correct one.

Because you didn't try it the correct way. RTFM on CHANGE PASSWORD!

> 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

On 1/20/2022 8:30 AM, Dr Eberhard Lisse wrote:
> 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
jstucklex@attglobal.net
==================