You will need a USB key you can erase.

First Get the bootable ISO file from Lenovo support website. To get your product number:

sudo dmidecode -t system | grep Product

To check your BIOS version: sudo dmidecode -t bios

Get the geteltorito program from your packages or download it:

cd /tmp/
wget http://userpages.uni-koblenz.de/~krienke/ftp/noarch/geteltorito/geteltorito
chmod +x geteltorito

Extract the img from the ISO:

./geteltorito -o bios.img gruj09us.iso

Copy the img to the USB key (make sure sdb is you USB key!!):

sudo fdisk -l /dev/sdb #at least check that device size is right
sudo dd if=bios.img of=/dev/sdb

That’s it. Boot on USB stick and follow the instructions to update your BIOS.

What you need:

• 2 live USB keys (or cds)
• To speed up data transfer: good quality ethernet cables (one cable between the 2 computers is OK), or a usb key/drive with a BIG ext4 partition. You can try over wifi, but it may be slow.

1. Boot source and target machines on live USB/CD

Any live USB/CD should be OK.
On the target computer, you will need a tool to partition your hard drive, like gparted.
rsync is also required for data transfer: it’s included in many live systems.

Ubuntu live cd is OK, Manjaro live cd too.

2. Partition your target hard drive

Use a tool like gparted to partition the target hard drive, with the same partitions as your source system (slash, swap, home…).
I recommend you to assign LABELs to your partitions: for the fstab, it’s easier than UUIDs.

3. Mount all partitions on both machines

On both systems, open a root terminal. Then, for each data partition (you can ignore swap):

mkdir /mnt/slash
mount /dev/sdaX /mnt/slash

If you have a home partition:

mkdir /mnt/home
mount /dev/sdaY /mnt/home

4. Transfer the data (network or usb)

This part may be tricky. Choose the method you prefer.

Network

1. Setup the network. Test the connectivity with ping command.
   The easier is to plug the PCs on a DHCP network (like your ISP box) so that you get automatic IP addresses. If you linked the 2 pcs with a single cable, you’ll have to setup the IPs with NetworkManager (static ips, or adhoc network).
2. On source system, as root, create a simple /etc/rsyncd.conf file:

   uid = root
   gid = root
   use chroot = no
   
   [all]
       path = /
   

3. Then start the rsync daemon server: rsync --daemon
4. On target PC, for each partition:

   rsync -avHX SOURCE_IP::all/mnt/slash/ /mnt/slash/
   

   Don’t forget ‘/’ at the end of paths. -a will preserve many file attributes like owner and permissions, -H will preserve hardlinks if any, -X will preserve extended attributes like setuid. You may also add -A if you are using acls. What is good with rsync is that you can stop and restart the transfer whenever you want.

USB

Prepare a USB drive with a BIG ext4 partition.

1. Mount the USB partition on source system (mount /dev/sdbX /mnt/usb)
2. For each partition:

   rsync -avHX /mnt/slash/ /mnt/usb/slash/
   

3. umount, unplug and remount the USB disk on the target system.
4. For each partition:

   rsync -avHX /mnt/usb/slash/ /mnt/slash/
   

5. Change fstab on target system

As root, edit /mnt/slash/etc/fstab
For each partition (including swap), replace the first field with the new UUID or LABEL (it’s straightforward with LABELs):
UUID=the-long-uuid, or LABEL=yourlabel

2 ways to get the UUIDs / LABELs:

ls -l /dev/disk/by-uuid/
blkid /dev/sdaX

6. Reinstall Grub

We will use a chroot (changed root environment) to be able to call the grub install inside the migrated system.

First, bind mount some system directories needed by grub, then chroot:

mount --bind /proc /mnt/slash/proc
mount --bind /sys /mnt/slash/sys
mount --bind /dev /mnt/slash/dev
mount --bind /run /mnt/slash/run
chroot /mnt/slash

Then install grub in the Master Boot Record of your hard drive, and update grub config file (with the new uuids…):

grub-install /dev/sda
update-grub

7. Reboot target machine

That’s it! Your system should be working on the new computer now.
Feel free to comment if you encounter problems.

Can be used for example on the Raspberry Pi to run mpd commands, to use a mouse as a remote control.

I didn’t find how to isolate the wheel events in order to control the volume. Any idea somebody?

In Archlinux, you can add the following command in /etc/rc.local to start it at boot time:

nohup /usr/local/bin/mpd_mouse.sh > /tmp/mpd_mouse.log 2>&1 &

#!/bin/sh
# This script listen to mouse events with the mev command using gpm.
# Can be used for example on the Raspberry Pi to run mpd commands, to use a mouse as a remote control.
# You can start it as a daemon with:
# nohup /usr/local/bin/mpd_mouse.sh > /tmp/mpd_mouse.log 2>&1 &

# start gpm if not already started
gpm -m /dev/input/mice -t imps2

# unset TERM variable, otherwise mev refuses to start when detecting xterm
unset TERM

echo "Listening to mouse events..."

# we use script to fake a tty for mev, otherwise it exits (note: mev logs errors in syslog)
script -qc "mev -E" /dev/null </dev/null | grep --line-buffered -v "mouse-movement" | while read LINE
do
        echo
        echo "$LINE"

        EVENT=$(echo "$LINE" | cut -d' ' -f1 | cut -d'(' -f2)

        if [ "$EVENT" = "down-mouse-1" ]
        then
                echo mpc stop
                mpc stop
        elif [ "$EVENT" = "down-mouse-2" ]
        then
                echo mpc toggle
                mpc toggle
        elif [ "$EVENT" = "down-mouse-3" ]
        then
                echo mpc next
                mpc next
        else
                echo "nothing"
        fi

done

If using a unique UID is not a problem, it’s the most simple solution. All clients access files with the same UID. This way you cannot know who does what, and users cannot fine tune access rights.

The problem: default umask is ALWAYS 0022, so that any created file will get rw– r–– r–– permissions. Only the owner can write. Nobody else. To share files, a group must have write access.

You can change the umask. For command line, you set it in .bashrc or .profile, or /etc/profile for all users. For a SFTP share, you can set it with a trick. For Apache HTTP server, you can set it with /etc/apache2/envvars under Debian.

If file sharing is only done via on service, changing umask is simple, otherwise it’s not that easy. And even if you change umask for all services, nothing is perfect: for example it doesn’t work with Nautilus and SFTP. Some clients drop files and issue a chmod right after: the hell. You can also try the power of POSIX ACL to force permissions. But problems still remain with some clients.

And for the umask, maybe you don’t want all files to be dropped group writable. Maybe you want more granularity on permissions.

So I abandonned the idea of fixing the problem at the source in favor of some trick AFTER file creation.
The most simple solution is the cron task: every X minutes, run chmod -R g+w on the directory. This way permissions are not fixed immediately, but asynchronously. And it adds a (very) little more load to your system.

My solution uses inotify to listen for file changes and force permissions when files are created:

aptitude install inotify-tools

And the magical command:

inotifywait -mrq -e CREATE --format %w%f /tmp/mytest/ | while read FILE; do chmod g=u "$FILE"; done

UPDATE 2010-10-30
To support spaces at the end of filenames, and backslashes, use:

inotifywait -mrq -e CREATE --format %w%f /tmp/mytest/ | while IFS= read -r FILE; do chmod g=u "$FILE"; done

Thanks to vitoreiji (see comments)

inotifywait listens for events in the /tmp/mytest directory. When a file is created, it’s displayed on standard output. Then each fileline is read by the while loop and permissions are changed. g=u gives the group the user’s permissions (with g+w, if the user drops a file with rw– ––– –––, permissions will be rw– –w– –––).

You can now test file/directory creation and copy. mkdir -p a/b/c/d/e shoud also work.

Finally, add it in a boot script:

vi /usr/local/bin/inotifywait.sh && chmod +x /usr/local/bin/inotifywait.sh
#!/bin/sh
# Take the directory name as argument

inotifywait -mrq -e CREATE --format %w%f "$1" | while read FILE
do
	chmod g=u "$FILE"
done

vi /etc/init.d/inotifywait.sh && chmod +x /etc/init.d/inotifywait.sh
#! /bin/sh

case "$1" in
  start|"")

	rm -f /tmp/inotifywait.log
	/usr/local/bin/inotifywait.sh /path/to/dir/ >/tmp/inotifywait.log 2>&1 &
	
	;;
  restart|reload|force-reload)
	echo "Error: argument '$1' not supported" >&2
	exit 3
	;;
  stop)
	# killall inotifywait ???
	;;
  *)
	echo "Usage: inotifywait.sh [start|stop]" >&2
	exit 3
	;;
esac

:

(Debian way)

update-rc.d inotifywait.sh defaults

Note: a drawback: there is a limit on the number of tracked files. See -r option in man inotifywait.

Then the final touch in order for the new files to be created with the same group as their parent: setgid bit for all directories.

find /path/to/dir -type d -exec chmod g+s {} \;

Links:

• man inotifywait
• inotify-tools
• http://en.wikipedia.org/wiki/Inotify

If you have performance problems in some games like Quake 3 or TCE / Enemy Territory, try to disable KMS.
The problem can also be with the mouse pointer (slowness, lag, delay or inacuracy).

Grub 2

Add nomodeset in /etc/default/grub then issue the command update-grub.

vi /etc/default/grub
GRUB_CMDLINE_LINUX="nomodeset"
update-grub

Grub 1

Add nomodeset at the end of the # kopt line, then issue command update-grub.

vi /boot/grub/menu.lst
# kopt=root=/dev/sda1 ro nomodeset
update-grub

Someone also told me that disabling KMS solved his Firefox javascript speed problem in Yahoo Mail.

On a default Linux installation, my T43 processor is at about 46°C, and the GPU at about 49°C, for an external temperature of 19°C.

The BIOS fan management algorithm is very bad. After a cold boot, the fan starts running non stop after a few minutes of use.

Fortunately, it is possible to use programs to take control of the fan in place of the BIOS.

To start, the thinkpad_acpi module must allows us to change the fan speed:

# vi /etc/modprobe.d/thinkpad.conf
options thinkpad_acpi fan_control=1 experimental=1

Your choice to reload the module or reboot your system.

# rmmod thinkpad_acpi
# modprobe thinkpad_acpi

Now you can take control of your fan:

# cat /proc/acpi/ibm/fan
# echo level 0 > /proc/acpi/ibm/fan
# echo level 7 > /proc/acpi/ibm/fan # full speed !!
# echo level auto > /proc/acpi/ibm/fan # back to normal, BIOS management

Now go here and copy the content of the script in /usr/local/bin/tp-fancontrol.

# mv index.php /usr/local/bin/tp-fancontrol
# chmod a+x /usr/local/bin/tp-fancontrol

Then, test the script:

# tp-fancontrol
# tp-fancontrol -s 5 # for a fan that starts later

In order to start the script at boot, we also fetch the tp-fancontrol.init.debian script on the same page. We add it at the system boot.

# mv index.php /etc/init.d/tp-fancontrol
# chmod a+x /etc/init.d/tp-fancontrol
# vi /etc/init.d/tp-fancontrol
DAEMON=/usr/sbin/fancontrol
# /etc/init.d/tp-fancontrol start
# /etc/init.d/tp-fancontrol stop
# update-rc.d tp-fancontrol defaults # note: only adding "start" scripts is also possible

The final touch is to edit the script to change the minimum fan triggering tresholds, so that the fan starts later when the system begins to heat:

# vi /usr/local/bin/tp-fancontrol
MIN_THRESH_SHIFT=5
INTERVAL=10 # you can also increase the speed update interval

A 5 seconds increase allows the fan to become quiet again when the computer activity is low.

References:

• http://www.thinkwiki.org/wiki/How_to_control_fan_speed
• http://www.thinkwiki.org/wiki/ACPI_fan_control_script
• http://www.thinkwiki.org/wiki/Problem_with_fan_noise

No more PTYs.
Sorry, could not find a PTY.
[screen is terminating]

You have to change /dev/ptmx file permissions:

# ls -l /dev/ptmx 
crw-r--r-- 1 root root 5, 2 nov 18 23:28 /dev/ptmx
# chmod a+w /dev/ptmx
# ls -l /dev/ptmx 
crw-rw-rw- 1 root root 5, 2 nov 18 23:34 /dev/ptmx

Under Ubuntu, there was no problem. Permissions already set:

$ ls -l /dev/ptmx 
crw-rw-rw- 1 root tty 5, 2 2009-11-18 23:37 /dev/ptmx

References :

• man ptmx
• ubuntu$ ls -l /dev/ptmx

Answer: Impossible.

With Debian default cron program, it’s hard coded in cron :

In do_command.c source file:

fprintf(mail, "From: root (Cron Daemon)\n");
fprintf(mail, "To: %s\n", mailto);
fprintf(mail, "Subject: Cron <%s@%s> %s\n",
  usernm, first_word(hostname, "."),
  e->cmd);