ERROR 1146 (42S02) at line 1: Table 'hda_production.settings' doesn't exist

[TheParkerFamily]

I was trying to reinstall Amahi / Fedora on my system and I've run into the following error:

[root@hda ~]# hda-install <mycode>
Verbose log file at '/root/hda-install-161017-112046.log'.
Retrieving install code ...
Install code looks good
Stopping background software updates ...
Background software updates stopped
Installing 1 packages ...
RPM packages installed
Starting MySQL
Initializing MySQL
*************** TBD: Initialize storage pooling ... *******************
Initializing Ruby on Rails and DB
Activating your HDA's settings
ERROR 1146 (42S02) at line 1: Table 'hda_production.settings' doesn't exist
Initializing settings
/usr/share/gems/gems/mysql2-0.4.4/lib/mysql2/client.rb:107:in `_query': Table 'hda_production.settings' doesn't exist (Mysql2::Error)
from /usr/share/gems/gems/mysql2-0.4.4/lib/mysql2/client.rb:107:in `block in query'
from /usr/share/gems/gems/mysql2-0.4.4/lib/mysql2/client.rb:106:in `handle_interrupt'
from /usr/share/gems/gems/mysql2-0.4.4/lib/mysql2/client.rb:106:in `query'
from /usr/bin/hda-install:226:in `get_db_settings'
from /usr/bin/hda-install:848:in `do_full_install'
from /usr/bin/hda-install:1309:in `main'
from /usr/bin/hda-install:1312:in `<main>'
[root@hda ~]#

Now, I see some references where folks had run into this several years ago, but I don't see what was done to resolve it. Any help would be appreciated.

[bigfoot65]

I was trying to reinstall Amahi / Fedora on my system

When you say reinstall, do you mean formatting drive and starting over? If not, reinstall from an existing Amahi installation is not supported. It must be a complete new Fedora and Amahi install.

What install guidance are you following?

[TheParkerFamily]

I was using the Amahi 9 upgrade instructions, as detailed https://wiki.amahi.org/index.php/Amahi_9_Upgrade.

Since it mentions only being tested on a clean system with few mods I uninstalled all my apps first, and attempted to install preserving my drive layout and greyhole config.

I'm mainly looking for general info on how that Error 1146 was resolved previously, as I would really prefer not to have to format the OS and start from scratch.

[bigfoot65]

I was using the Amahi 9 upgrade instructions, as detailed https://wiki.amahi.org/index.php/Amahi_9_Upgrade.

Since you are doing an upgrade, there is no reinstall. It just upgrades to the latest OS and Amahi version.

There is nothing in the upgrade instructions that state to do hda-install. I always stress to users to follow the instructions and don't ad lib. Doing so causes issues and often a reinstall from scratch.

Not sure if you caused any damage to the database or original Amahi install. If things are not working, then you will have to do a clean install.

[TheParkerFamily]

That type of non-answer is tremendously frustrating, in case you were not aware.

Yes, absolutely an erase and install would technically resolve the issue. I also understand that 'erase and install' is the easiest answer from a support perspective. I knew that before I asked the question.

It would also put me back at square one where I have to recreate a drive array I put together a year or two ago, move all the mount points for drives etc as well as recreate the LZ for Greyhole, as well as rebuild my virtual box installation etc. All are technically do-able, but certainly not desirable. (Neither is un-mounting the server from under the stairs and dragging it out to hook a monitor keyboard and mouse to it, but I know that is certainly a possibility.)

Personally, I'd rather attempt to salvage my config, and gain a better understanding of where I might have gone wrong.

If you recall what the problem was that lead to the ERROR 1146, would love to get info on that. If you don't recall, or are unwilling to share the info, then that's ok too.

If all else fails, I can erase and install - or just erase and give an alternative to Amahi a try. ClearOS, OpenMediaVault and FreeNAS are all good solutions too. If I have to start fresh, it might be fun to see how performance on the other platforms compares.

[TheParkerFamily]

oh! I did find this gem in old bug report for same issue (5 yrs ago lol)

https://bugs.amahi.org/issues/840

Unfortunately the Rakefile fix mentioned in it doesn't make that much sense to me (concept makes sense, I just don't know the syntax well enough for the commands it suggests inserting in the Rakefile to be able to modify it to be currently useful.)

[bigfoot65]

That type of non-answer is tremendously frustrating, in case you were not aware.

I disagree. My response was not a non-answer.

Personally, I'd rather attempt to salvage my config, and gain a better understanding of where I might have gone wrong.

It was executing the hda-install <mycode> where you went wrong. You did not follow the upgrade instructions as noted. Executing that command attempts to reset the database and all previous settings will be lost. It will also break Amahi.

If you recall what the problem was that lead to the ERROR 1146, would love to get info on that. If you don't recall, or are unwilling to share the info, then that's ok too.

I do recall and that is what I replied about in my last post. I am trying to help. Executing that command on an existing Amahi server basically renders it broken. The hda-install command is to only be used on a new install of OS and Amahi, not an existing one. Any guidance you find in the forums or old bug reports that is years old is useless.

If I misunderstood what you have done, then please clarify.

[cpg]

There is not enough information in what this procedure is trying to do. However, there are a couple of things to note:

1) Upgrading, as bigfoot65 well pointed out, tries to preserve as much configuration as possible, and definitely *does not include running hda-install* as part of the upgrade. That is because hda-install is a destructive operation in that it re-sets all configuration and settings, clears the the database, etc.

2) Trying to run hda-install in a previously installed system raises a warning and exits. The warning asks the user to explicitly remove a file from the system for it to be able to run, as it will destroy settings in a running system. There is no way a previously installed system would simply run hda-install without bypassing that explicit action. Do you have the output in the screen of when you did this?

3) So, at this point after the above, you were warned about destructive operations you were about to do. If the table hda_production.settings does not exist, then that could mean a couple of things (as bigfoot65 pointed out) -- that the database may be set up, and somehow there are no permissions (strange), or that the format of the database has been altered or corrupted in some way. It may also mean other things. In any case, there is not enough information in your posts to know.

It's quite frustrating for us too to see users struggle and not be able to help. This does appear to be user error and some damage appears to be done somehow. But it's just not something we can diagnose bit by bit, as it could be a lot of things.

You are part of the Pro program, so we will try to help even more than usual, however, it does appear that there is some damage. The only other option is intense custom help in the form commercial support. It may take 2 or 3 hours (estimate) to get it resolved. As a Pro subscriber I will offer the first hour of commercial support free.

To work on this, you should set up ssh access (via port forwarding) and email support the credentials of an admin user (in this case, since your dashboard is not working, it would be your main admin user). You can change credentials before and after with the command "password".

[TheParkerFamily]

I'm sorry, I was attempting brevity, rather than spewing out paragraphs of backstory which will probably just confuse things even more.

You are absolutely correct (of course) in that the hda-install command is not a part of those upgrade instructions. That part actually came later on.. as I was trying to rectify a long and painful series of things that really seemed logical at the time. (My original thought was something like 'Oh, they're testing F24 & Amahi10! Awesome - I have some spare time, I should install and see if I can volunteer to do some testing!'

ORIGINALLY, I was following the upgrade instructions to install F24/Amahi 10 directions posted here: (You know, the ones right under the big warnings that say 'Do not try this at home, idiot!' https://wiki.amahi.org/index.php/Amahi_10

That worked beautifully, excepting that there were no apps available to re-install afterwards other than Plex and GreyholeUI. Both of those worked fine, although I had to reconfigure my shares for greyhole. My first assumption was that I'd missed something, so I tried it again. Same results.

I was then curious as to whether I had done something wrong causing the APP list not to populate so I ran through the clean install directions, after running the migration script to capture my config. What I did not do was to format the OS disk, I was attempting to do a reinstall to repair whatever might have gone wrong. Again, everything worked great but still no apps.

At this point I realized that there were likely no apps because this build is still very much in the development stage, and was torn between deciding to leave well enough as is and wait for Amahi 10 / F24 to move into production (leaving the config as is with the bare minimum setup as all I really needed was already working just fine.) FOOLISHLY, I second guessed myself and tried to remove Amahi, downgrade back to F23 and reinstall Amahi, having saved all of my configuration off on another system where it would be safe.

What I did not take into account, which in retrospect was a big DUR, was that in upgrading Fedora to 24 and Amahi 10, Mariadb would have been upgraded and it's likely that the Amahi installer may have made some necessary changes to tables or permissions.

I was able to successfully downgrade the OS to F23. Once that was done, I attempted reinstalling Amahi which resulted in the error 1146. CRAPOLA. Now Amahi won't even install. So I removed Amahi again, then re-upgraded to F24, hoping to get things back to basic functionality by installing it in it's last working config.

'Silly mortal, you will not get by me that easily!' is what the system said to me as it stubbornly refused to allow the install to complete. NO WORRIES, says I - since everything is still working in the background (Everything in this case being my samba shares, greyhole and PHPVB somehow) I will reach out to the experts and see what triggered this same error message back in the days of yore - as surely the cause would enlighten me as to which particular pooch I had just enscrewed...

In the meantime, lets see if we can pick this knot apart piece by piece and see what is/isn't working. So I notice that the entire ERROR 1146, according to my amahi installer logs, was predicated by a failure in authentication to the mysql database. SWEET! Thinks me, as I can surely just go into mysql/mariadb and reset the password back to defaults and ALL WILL BE WELL. So I do so, reboot and VOILÀ!

Turns out not so much.... sigh. Now my server refused to acknowledge pings and appears to be well and truly borked. (Well - borked to the point where I have no choice but to do a clean install. Which is not really a problem - I just would have preferred to learn something more valuable than 'If it ain't broke - you aren't trying hard enough!'

Short version - thanks for the info, I'll be setting things back to a safe/stable config this evening. Not sure what to do about vbox as it was a pain to setup and define as a webapp and I didn't think to document that part of the build process as it was more of an 'on a whim' add-on to see how performance compared to Windows 2012 hypervisor (very well, btw - much less overhead).

I was also hoping to avoid putting all of the above out there in the forum as I didn't want to lead anyone else down the rabbit hole in testing out something on their system and potentially losing something important. (All my data is untouched so no risk outside of having to put in some extra work reconstructing the configuration itself.)

Should be low risk, as my long winded explanation should cause mere mortals to fall asleep and get qwerty face long before they try to follow any of my ill-advised steps.

Now you have the whole backstory, which hopefully serves to provide at least some humor, as I don't really need the info I'd originally posted to find.

[TheParkerFamily]

Oh - the frustrating part was the focus on the HDA-install command - that was the tail end of the process and least important piece of how I got where I was.

My question was just intended to let me wrap up the thought process as far as 'what could cause this error' prior to moving on and reinstalling. It was never answered either, as you guys got too hung up on the 'why was I running that command' instead of 'what might cause that error'.

To be fair, I think you adequately answered the question at a higher level (Which was: "Because you were obviously doing something you probably shouldn't have"), it's just that I already knew that and was more interested in the technical side of things.

I appreciate the time you both took to answer, however! Feel free to close issue - as the format and install will easily resolve things.