On Wed, Jun 2, 2010 at 9:47 AM, Matt Graham <danceswithcrows@usa.net> wrote:
From: Mark Phillips <mark@phillipsmarketing.biz>
> On Wed, Jun 2, 2010 at 8:41 AM, Matt Graham <danceswithcrows@usa.net>
wrote:
>> The post-install script should've chowned the mysql log files to mysql.

[[It did, /etc/passwd and /etc/group are OK in the chroot]]

>>> It looks like you have all binaries & libraries installed, but some
>>> post-installation tasks have failed to complete.  You might try
>>> starting mysql yourself, and see if that gives you any more clues
>>> about what's wrong.
>> Yeah.  And if that gives you no useful info, there's always the nuclear
>> option:  "strace -ff /etc/init.d/mysql start > strace.log 2>&1"
> write(1, "\7/usr/bin/mysqladmin: connect to "..., 62)
> write(1, "error: 'Can't connect to local My"..., 94)
> write(1, "Check that mysqld is running and "..., 88)

Translation:  The local socket (probably in /var/run/mysqld/mysqld.sock )
doesn't exist for some reason.  Lots of things, including the Debian start
script, like to have that socket there so they can talk to mysqld.  Make sure
the my.cnf file says where the socket should be, and make sure that
/var/run/mysqld/ in the chroot is owned by mysql .

my.cnf in the chroot is just the stock my.cnf from the install. It says -
socket          = /var/run/mysqld/mysqld.sock

Does it have to read
socket          = /opt/chroot/lenny-i386/var/run/mysqld/mysqld.sock

the full path to the chroot var/mysqld? I thought everything in the chroot only knew about the chroot and could not look past it. So, if anyone (root, mysql, etc.) within the chroot went to /var/run it would be the /var/run in the chroot and not the /var/run in the bigger world of 64 bits on squeeze. Is this correct, or do I need to change paths within the my.cnf to reflect the global path of /opt/chroot/lenny-i386?

> stat64("/usr/local/sbin/logger", 0xfffa2798) = -1 ENOENT
> stat64("/usr/local/bin/logger", 0xfffa2798) = -1 ENOENT
> stat64("/usr/sbin/logger", 0xfffa2798) = -1 ENOENT
> stat64("/usr/bin/logger" = 0

So logger exists in /usr/bin/ , which makes me think it's trying to use logger
to write to some sort of syslog daemon at some point.  I would install a
syslog daemon (syslog-ng or metalog or something....) in the chroot and run it
just to see if other junk is going on in there.  At the very least, you'd
probably get some junk in various logfiles, which would probably help diagnose
whatever other problems might crop up.

I think the logger setup is correct. When I search for logger on my computer, there are only 2 - the chroot and the main system
/opt/chroot/lenny-i386/usr/bin/logger
/usr/bin/logger

both are in bin/logger.

> connect(1, {sa_family=AF_FILE, path="/dev/log"...}, 110) =
> -1 ENOENT (No such file or directory)

I think that socket is maintained by syslog.

> I mounted /proc and /dev/pts from the 64 bit system to the chroot. Do I
need
> to do that for other file systems, or was that wrong? Too many different
> chroot 'recipes" out there!

You need /proc/ and /dev/pts mounted.  That should be OK.

>> make sure you don't have the old ib_logfile* files sitting in the data
dir.
> No tables copied over from 64 bit system.

That makes things a bit easier.

--
Matt G / Dances With Crows
The Crow202 Blog:  http://crow202.org/wordpress/
There is no Darkness in Eternity/But only Light too dim for us to see

---------------------------------------------------
PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss