Hello,

i have following problem: I installed XOOPS 2.0.9.2. The installation finished successfully (setup told me that). I klicked on the "Here" link but then I only got the banner and the footline (xoops copyright). No menu and no login. Thats not good, because not really usefull

OK, because i worked with XOOPS before and because I searched in this forum before writing this, I logged in using directly the user.php script. After that, I manually called the admin.php script.

In the admin section I called "Blocks" and there are no blocks! I called "Groups" but all Blocks are available for the Webmaster Group.

Please, Help me! Where are my blocks? What can I do?

More infos:
- I tried all possible debug-modes, but there are no infos
- I changed the theme (and deleted content of template_c before)
- I use: PHP 4.3.18-12, MySQL 4.0.22, Apache 1.3.33 on Debian
- I have not the same error as: https://xoops.org/modules/newbb/viewtopic.php?topic_id=19621&forum=1&post_id=117047
https://xoops.org/modules/newbb/viewtopic.php?topic_id=29061&forum=7&post_id=126759


Update:
I found the error! Now it works!
For people who have a problem like this, read here:
I watched with "tail -f /var/log/mysql/mysql.log" what happens if I call the startpage. Very interesting are all the lines with a SELECT order to the XOOPS database in that moment when I call my xoops-Startpage.
After that, I tried to run this SELECT orders in my phpMyAdmin.The first three SELECT orders works fine but the fourth one told me an error: MySQL was not able to write a file in the /tmp directory. I´m wondering, why MySQL tries to write there. But for a test I changed the permissions to 777. And then, it works.
Funny: After that I set the permissions to the old value, and it still works. (Im wondering about that). It seems, that MySQL usually writes in a different directory than in /tmp but sometimes (why?) it tries to do this there.

I hope, this will be a helfull info for people with the same problem.

If I recall there was a block problem in 2.0.9 but Mith resolved it and released 2.0.9.2.

If it's a new install, just try again. You may just have had a faulty installation.

I found the error! Now it works!
For people who have a problem like this, read here:
I watched with "tail -f /var/log/mysql/mysql.log" what happens if I call the startpage. Very interesting are all the lines with a SELECT order to the XOOPS database in that moment when I call my xoops-Startpage.
After that, I tried to run this SELECT orders in my phpMyAdmin.The first three SELECT orders works fine but the fourth one told me an error: MySQL was not able to write a file in the /tmp directory. I´m wondering, why MySQL tries to write there. But for a test I changed the permissions to 777. And then, it works.
Funny: After that I set the permissions to the old value, and it still works. (Im wondering about that). It seems, that MySQL usually writes in a different directory than in /tmp but sometimes (why?) it tries to do this there.

I hope, this will be a helfull info for people with the same problem.

Hot damn, you fixed my problem !
https://xoops.org/modules/newbb/viewtopic.php?topic_id=29459&start=0#forumpost129924
https://xoops.org/modules/newbb/viewtopic.php?topic_id=29539&start=0#forumpost129925

Mine was a case of an invalid temp path in MYSQL. Thanks for the info it put me in te right place

uhh i have same problem but i am not exactly sure what you guys said you did to fix it.

My TEMP directory which was set in MySQL was invalid. It pointed to a directory that didn't actually exist on my HDD exist.

After I changed it to a valid existing directory, XOOPS worked fine.

I used MySQL Administrator and went to SETUP VARIABLES and looked under the GENERAL PARAMETERS tab for "temp Directory" and changed it.

Of course this could be done by editing the MySQL configuration directly.

Does that help at all?

My interpretation of the issue here is;

Like one of my sites having the same issue, we are using shared hosting, and do not have access to the setup variables, just basic DB administration; empty, drop, check , repair, etc. (this is my case, I am assuming that this is the same situation for the other people with the problem)

Leading us to: How does one do that, without access to the setup variables?

Is there a query that can be run that accomplishes the same thing?

I'm sort of stuck, and not too terribly interested in learning mySQL. The last time I uninstalled everything to 'start over', there were a couple of module folders and thumbnail folders that were created by the module install process that were owned by 'root', so I couldn't delete them. All I could do was rename the top folder in the tree, ensuring a fresh install.