Monthly Archives: August 2011

Fix inspiron N7110 ALPS Touchpad in Ubuntu

Linux, , , , , , , ,

I recently purchased a new dell inspiron N7110. The laptop is great and Ubuntu 11.04 works quite well but there is one important problem.

The problem with most touchpads on laptops is that you'll often touch them accidentally while typing, this gets recorded as a tap/click and the typing cursor might move to another location and thus you might and up tying to a whole different place.

With synaptics touchpads or ALPS touchpads ( this is what N7110 has - ALPS Glidepoint) you can use syndaemon, a program that would run in background, monitor the keyboard and disable the touchpad while you type. But this program only works for touchpads which are being recognized as synaptics or ALPS touchpads. The touchpad on N7110 was recognized as a simple mouse, Xorg loaded the evdev driver instead of synaptics.

So I thought that maybe I can modify syndaemon to make it work with mice too. And I did. I noticed a lot of other people have the same problem so this could be useful even if you have a different touchpad that's also recognized as a mouse.
Download the patch for syndaemon here:
[download id="32"]

To apply the patch:

  1.  

The patch adds a new option to syndaemon to tell it to disable the mouse instead of a touchpad, without this the program will just exit when it can't find the touchpad.

  1.  

Don't forget to start it every time you start X.

Of course this is more like a quick hack then a real fix. A real fix would make Xorg or the kernel ( not sure exactly where the problem really is ) recognize this touchpad as a touchpad not as a mouse.

How to restore mysql replication

databases, , ,

Something went wrong and your mysql replication broke, I'm talking here about problems with the sql thread, not connection problems.

The sql thread shows you an error, what do you do to fix it and resume replication?

Here are 3 ways to fix it, each has advantages and disadvantages, pick the one that fits best to your problem.

1. Skip over the problem

You can try to just skip over the statement that broke the replication by changing the position in log file.

There are two ways to do this:

a) you can skip gradually

slave stop;
SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
slave start;
show slave status \G

That would skip the next 1 statement but you can set the counter higher to skip more the one.
Do it until the slave status shows the SQL thead is running.

b) skip to the current position

Use this is the first method keeps showing other statements that break replication and you don't have time to gradually skip statements.

First go on the master and type: show master status to find which is the current bin log file and the current position within the file.

Then go on the slave, stop it with "slave stop" and change the file name and position. Something like:

slave stop; 
CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001958', MASTER_LOG_POS=52562937;
slave start;

But do that with your own file name and position taken from the master.

Check the replication status with "show slave status".
If the results are good ( both Slave_IO_Running and Slave_SQL_Running are Yes ) then you can go to the next step otherwise skip to next methods.

At this point you have a working replication but probably the data on the slave is not the same as on master since you skipped a few sql statements.

To fix it you can use maakit ( mk-table-checksum and mk-table-sync )

2. Full Dump and Restore

Connect to master, dump everything in a sql file, copy to replication slave and load it in mysql.

Use --master-data so the replication position is set in the dump file and the slave will know where to start.

Use --disable-keys so the slave will not try to build indexes after each insert and only built them at the end of the import.

Use --add-locks to surround each table dump with lock table/unlock table - this makes the inserts faster in the slave.

Problem:
--master-data will put a read lock on tables so operations on your master will lock waiting for the dump to finish. On large databases this can take a long time and it's unacceptable.

Possible fix:
If you have innodb tables add --single-transaction so a single global lock will be used only for a short time at the beginning of the transaction.

The problem is not so big if you can have filesystem snapshots on the master like the ones created by lvm.

3. Inconsistent Full Dump

This is just another fix for the problem at #1. Dump the data just like before but without using --master-data. This means no locks so the master can still work normally.
But because you don't use --master-data you will have to set the position in the slave yourself.
on the master type:

show master status \G

Take the file name and position and use them in the CHANGE MASTER statement on the slave ( after you load the dump file ) . Something like:

CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.001958', MASTER_LOG_POS=52562937;

Of course all of this will create an inconsistent slave but you can fix this easily with maakit.

If you know other methods I'd love to hear about them. Let me know in the comments.

Wammu backup to CSV for Gmail

Linux, , , ,

This is a modification to the wammu2csv.pl script that you can still find in google cache if you look for it.

The problem with the original script was that wammu ( version 0.35 anyway ) seems to generate backup files encoded in UTF-16 and the regular expressions in that script will not work unless the content is first converted from UTF-16.

Another benefit of the modified script is that now you don't have to convert the backup file from DOS to UNIX anymore.

To use this script:

  1. Connect to your phone using wammu
  2. Retrieve contacts from phone and save them in a file using the backup function
  3. download [download id="31"] and run:
    ./wammu2csv.pl <your-backup-file> > <your-csv-file>

    This will generate a CSV file that you can import in Gmail