Il vous faut une clé USB que vous pouvez écraser.

Récupérez le fichier ISO bootable depuis le site de support Lenovo. Pour obtenir votre numéro produit :

sudo dmidecode -t system | grep Product

Pour vérifier la version installée du BIOS: sudo dmidecode -t bios

Récupérez le programme geteltorito depuis vos paquets, ou téléchargez le :

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

Extraire le fichier img depuis l’ISO :

./geteltorito -o bios.img gruj09us.iso

Copier le fichier img sur le périphérique (vérifiez que sdb est bien votre clé USB !!) :

sudo fdisk -l /dev/sdb #vérifiez la taille du disque
sudo dd if=bios.img of=/dev/sdb

Voila. Démarrez sur la clé USB et suivez les instructions pour mettre à jour le BIOS.

Il vous faut:

• 2 clés USB live (ou cds)
• Pour un transfert plus rapide: des bons câbles ethernet (un seul câble entre les 2 ordis suffit), ou un disque usb avec une GROSSE partition ext4. Vous pouvez essayer en Wifi, mais ça risque d’être lent.

1. Démarrer les machines source et cible sur live USB/CD

N’importe quel clé USB ou CD devrait faire l’affaire.
Sur l’ordinateur cible, vous aurez besoin d’un outil pour partitionner votre disque dûr, comme gparted.
rsync est également nécessaire pour le transfert de données : il est inclus dans la plupart des systèmes live.

Exemples de live USB/CDs : Ubuntu, Manjaro

2. Partitionnez votre disque cible

Utilisez un outil comme gparted pour partitionner votre disque cible, avec les mêmes partitions que votre système source (slash, swap, home…).
Je vous recommande d’affecter des LABELs / étiquettes à vos partitions : c’est plus simple que les UUIDs pour la fstab.

3. Monter toutes les partitions sur les 2 machines

Sur les 2 systèmes, ouvrez un terminal root. Pour chaque partition de données (on ignore la swap) :

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

Si vous avez une partition home:

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

4. Transférer les données (réseau ou usb)

Cette partie peut être complexe. Choisissez la méthode que vous préférez.

Réseau

1. Configurez le réseau. Testez la connectivité avec la commande ping.
   Le plus simple est de brancher les PCs sur un réseau DHCP (comme la box de votre FAI) pour obtenir des adresses IP automatiques. Si vous reliez les 2 pcs avec un seul cable, vous devrez configurer les IPs avec NetworkManager (ips statiques ou réseau adhoc).
2. Sur le système source, en root, créez un fichier /etc/rsyncd.conf :

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

3. Lancez le démon serveur rsync : rsync --daemon
4. Sur le PC cible, pour chaque partition :

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

   N’oubliez pas les ‘/’ à la fin des chemins. -a pour conserver plusieurs attributs comme propriétaire et permissions, -H pour conserver d’éventuels liens en dûr, -X pour conserver les attributs étendus comme setuid. Vous pouvez également ajouter -A si vous utilisez des acls. L’avantage de rsync, c’est que vous pouvez arrêter et relancer le transfert quand vous voulez.

USB

Préparez un disque USB avec une GROSSE partition ext4.

1. Montez la partition USB sur le système source (mount /dev/sdbX /mnt/usb)
2. Pour chaque partition :

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

3. Démontez (umount), débranchez et remontez le disque USB sur le système cible.
4. Pour chaque partition :

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

5. Changer la fstab sur le système cible

En tant que root, éditez /mnt/slash/etc/fstab
Pour chaque partition (swap y compris), remplacez le 1er champ avec le nouvel UUID ou LABEL (plus simple avec les LABELs) :
UUID=the-long-uuid, or LABEL=yourlabel

2 méthode pour obtenir les UUIDs / LABELs :

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

6. Réinstaller Grub

Nous allons utiliser un chroot (environnement avec racine changée) pour lancer l’install grub à l’intérieur du système migré.

Tout d’abord, monter (bind) les répertoires systèmes requis par grub. Lancer ensuite le 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

Enfin, installer grub dans la zone d’amorçage (Master Boot Record) de votre disque dûr, et mettre à jour le fichier de configuration de grub (avec les nouveaux uuids…) :

grub-install /dev/sda
update-grub

7. Redémarrer la machine cible

Voila ! Votre système devrait fonctionner sur le nouvel ordinateur.
N’hésitez pas à commenter en cas de problème.

Utilisé sur mon Raspberry Pi pour lancer des commandes MPD (Music Player Daemon), pour utilisé la souris comme télécommande.

Je n’ai pas encore trouvé comment isolé les événements de la molette souris, pour pouvoir régler le volume. Quelqu’un a une idée ?

Sous Archlinux, vous pouvez ajouter la commande suivante dans /etc/rc.local pour le lancer au boot :

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

Si elle convient il y a la solution de l’UID unique. Tous les clients accèdent aux fichiers avec le même UID utilisateur. Seulement on ne sais pas qui fait quoi. Et les utilisateurs ne peuvent pas gérer finement leurs droits.

Problème : le umask par défaut est TOUJOURS 0022, ce qui fait que tout fichier créé aura les droits rw– r–– r––. Seul le propriétaire peut écrire et personne d’autre.
Pour partager les fichier, un groupe doit aussi pouvoir écrire.

On peut changer ce umask. Pour la ligne de commande, ça se passe dans les fichiers .bashrc ou .profile, ou dans /etc/profile pour tous les utilisateurs. Pour un partage SFTP, on s’en sort avec un bricolage. Pour le serveur Apache, on s’en sort avec le fichier /etc/apache2/envvars sous Debian.

Si le partage de fichier se fait via un seul service, c’est simple de changer le umask, sinon, c’est compliqué. Et même en changeant tous les umask de tous les services, tout n’est pas parfait : par exemple, Nautilus via SFTP n’en fait qu’à sa tête. Certains clients posent le fichiers et font un chmod derrière : l’enfer. Il y a aussi la puissance des ACL POSIX qui permettent de forcer les droits. Mais là encore, certains clients vous poserons problème.

Enfin, on ne souhaite pas forcément que tous les fichiers soient posés avec l’écriture pour le groupe. On peut souhaiter une meilleure granularité.

D’expérience, j’ai abandonné l’idée du correctif à la source pour me tourner vers un bricolage agissant APRÈS la création du fichier.
La solution la plus simple est bien sûr la tâche cron, qui toutes les X minutes fait un chmod -R g+w sur un dossier. Déjà la solution n’est pas immédiate car désynchronisée de la création de fichiers, et elle rajoute une (très) petite charge supplémentaire à votre système.

Je propose une solution à base d’inotify, qui force les droits dès qu’un fichier est créé :

aptitude install inotify-tools

Et la commande magique :

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

MAJ 2010-10-30
Pour gérer les espaces en fin de fichiers, et les antislashs :

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

Merci à vitoreiji (voir commentaires)

La commande inotifywait écoute les événements du dossier /tmp/mytest. Dès qu’un fichier est créé, il est affiché sur la sortie standard. Chaque ligne-fichier est ensuite lue par la boucle while et les droits sont changés. Le g=u donne au groupe les mêmes droits que l’utilisateur (avec g+w, si l’utilisateur pose un fichier rw– ––– –––, les droits deviendraient rw– –w– –––).

Vous pouvez maintenant tester la création/copie de fichiers/dossiers. Même un mkdir -p a/b/c/d/e doit fonctionner.

Pour terminer, on ajoutera tout cela dans un script de démarrage :

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

:

(sous Debian)

update-rc.d inotifywait.sh defaults

Note : un inconvénient : il y a une limite sur le nombre de fichier surveillés, voir l’option -r dans man inotifywait.

Et enfin la touche finale qui est utile pour que les fichiers créés conservent le groupe du dossier parent : le bit setgid au groupe pour tous les dossiers.

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

Liens :

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

Si comme moi vous rencontrez des problème de performance dans certains jeux en 3D comme Quake 3 ou TCE / Enemy Territory, essayez de désactiver KMS.
Le problème peut aussi se manifester sur la souris par de forte lenteurs, du retard, ou un manque de précision.

Grub 2

Ajoutez nomodeset dans /etc/default/grub puis lancer la commande update-grub.

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

Grub 1

Ajoutez nomodeset à la fin de la ligne # kopt puis lancer update-grub.

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

On m’a raconté aussi que désactiver KMS corrigeait certains problèmes de lenteur Javascript sous Firefox (Yahoo Mail…).

Sur une installation Linux par défaut, le processeur de mon T43 fait 46°C en moyenne, et le GPU 49°C pour une température extérieure de 19°C.

L’algorithme de gestion du ventilateur par le BIOS est très mauvais, si bien qu’après un démarrage à froid, le ventilateur se met à tourner sans arrêt après quelques minutes d’utilisation.

Fort heureusement, il est possible d’utiliser des programmes pour prendre le contrôle du ventilateur à la place du BIOS.

Pour commencer, le module thinkpad_acpi doit nous autoriser à changer la vitesse du ventilo :

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

Au choix, vous pouvez recharger le module, ou relancer votre système.

# rmmod thinkpad_acpi
# modprobe thinkpad_acpi

Vous pouvez désormais prendre le contrôle de votre ventilo :

# cat /proc/acpi/ibm/fan
# echo level 0 > /proc/acpi/ibm/fan
# echo level 7 > /proc/acpi/ibm/fan # pleine puissance !!
# echo level auto > /proc/acpi/ibm/fan # retour à la normale, on laisse le BIOS prendre la main

Maintenant, rendez-vous ici et copiez le contenu du script dans /usr/local/bin/tp-fancontrol.

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

Ensuite, pour tester le script :

# tp-fancontrol
# tp-fancontrol -s 5 # pour un ventilo qui démarre plus tard

Afin de lancer le script au démarrage, on récupère aussi, sur la même page, le script tp-fancontrol.init.debian. On l’ajoute au démarrage du système.

# 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 : on peux aussi n'ajouter que les liens "start"

La touche finale est de modifier le script afin de changer les seuils minimum de déclenchement du ventilateur, de manière à ce qu’il se déclenche plus tard quand le système commence à chauffer :

# vi /usr/local/bin/tp-fancontrol
MIN_THRESH_SHIFT=5
INTERVAL=10 # on peut aussi augmenter l'intervalle de mise à jour de la vitesse

Une augmentation de 5 secondes permet au ventilateur de redevenir silencieux quand l’ordinateur ne fait plus rien.

Références :

• 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]

Il faut changer les droits du fichier /dev/ptmx :

# 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

Sous Ubuntu, le problème était absent, les droits étant déjà positionnés :

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

Références :

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

Réponse : C’est impossible.

Avec le programme cron par défaut sous Debian, c’est codé en dûr dans le code de cron :

Dans le fichier source do_command.c :

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);

Vos deux disques étant en mirroir, il peut être utile de « casser » le RAID pour pouvoir disposer librement du stockage sur le deuxième disque, ou encore, dans le cadre d’une refonte, d’installer un tout nouveau système sur le deuxième disque, qui remplacera le premier à l’avenir.

En premier lieu, quelques commandes utiles en tout temps pour le diagnostic :

mdadm, le couteau suisse du RAID logiciel :

cat /proc/mdstat
mdadm --detail /dev/md0

La batterie de commandes LVM2 :

pvdisplay
pvs
vgdisplay
vgs
lvdisplay
lvs

La manipulation ne coule pas de source. En voici les étapes :

cat /proc/mdstat montre les deux disques actifs (U pour Up). On marque le deuxième disque (/dev/hdc1) comme défectueux puis on l’enlève de la séquence de RAID pour pouvoir l’utiliser librement :

mdadm --manage --set-faulty /dev/md0 /dev/hdc1
mdadm -r /dev/md0 /dev/hdc1

L’objectif maintenant est de remonter la deuxième moitié du RAID/LVM de manière indépendante, mais sans perdre les données dupliquées présentes.

Il faut donc créer une nouvelle séquence RAID identique à la première en partant du deuxième disque. L’initialisation de /dev/md1 se fait comme suit :

mdadm --create --verbose /dev/md1 --level=mirror --force --raid-devices=1 /dev/hdc1

cat /proc/mdstat doit montrer les deux séquences.

La difficulté désormais est de faire en sorte que le système voie les deux VGs de manière indépendante, car toute commande LVM affiche désormais un avertissement du style :

Found duplicate PV LbpGyrR4uvsZivUwqnJQMYoZbCPTCpgu: using /dev/md1 not
/dev/md0

Le soucis est que les deux PVs sur les deux raids possèdent le même UUID, du coup LVM utilise le PV qui n’est pas celui du système actuel. Le problème est ici assez insoluble. Le seul moyen de s’en sortir est d’utiliser la commande pvcreate pour attribuer un nouveau UUID.
D’autre part, impossible d’utiliser cette commande sur un PV qui contient des LVs actifs (pvcreate refuse).

Ajouter des filtres sur /dev/md0 ou /dev/md1 dans /etc/lvm/lvm.conf ne donne rien non plus car pvcreate ne les verra pas.

Voici donc la manipulation :

Vérifiez la présence d’un fichier /etc/lvm/backup/NOM_DU_VG, ou faite en une sauvegarde à l’aide de la commande vgcfgbackup.

Initialisez un volume physique (PV) vierge sur /dev/md1 en forçant la création :

pvcreate -ff /dev/md1

Puis un VG :

vgcreate vg2 /dev/md1

Copiez le fichier /etc/lvm/backup/NOM_DU_VG et éditez le :

cp /etc/lvm/backup/vg /tmp/vg2
vi /tmp/vg2

Modifiez tous les UUID du fichier de sauvegarde. Il suffit par exemple, dans chaque UUID, de modifier un chiffre. Modifiez aussi le nom du vg. Pour le UUID du PV, mettez celui du PV récemment initialisé sur /dev/md1 (commande pvdisplay).

Il est maintenant possible de restaurer la sauvegarde :

vgcfgrestore --file /tmp/vg2 vg2

Si tout s’est bien passé, on peut ensuite activer les LVs puis les monter :

vgchange -a y vg2
mount /dev/vg2/LV /mnt/test/

La Livebox que j’utilise pour me connecter en Wifi me pose le problème suivant :

Le serveur DHCP envoie sa propre adresse 192.168.1.1 comme serveur DNS… logique, me direz-vous, sauf que la boîboîte est incapable de répondre aux requêtes DNS inverses, utilisées par pas mal d’applications. Dès qu’une de ces requêtes est envoyées, donc, l’application en question gèle pendant quelques secondes jusqu’à un certain délai.

$ time nslookup 74.125.43.147 192.168.1.1
;; connection timed out; no servers could be reached

real    0m15.028s
user    0m0.016s
sys     0m0.000s

Alors qu’en utilisant un serveur DNS qui fonctionne :

$ nslookup 74.125.43.147 80.10.246.2
Server:         80.10.246.2
Address:        80.10.246.2#53

Non-authoritative answer:
147.43.125.74.in-addr.arpa      name = bw-in-f147.google.com.

Authoritative answers can be found from:

Jusqu’à maintenant, j’avais ajouté les serveurs DNS à la main dans /etc/dhcp3/dhclient.conf
en utilisant la directive prepend domain-name-servers 80.10.246.2.

Oui mais voila, à chaque fois que me connecte sur un autre réseau Wifi non Livebox, les serveurs DNS (du réseau Livebox) ne sont plus accessibles, et du coup il fallait modifier le resolv.conf à la main pour retirer lesdits serveurs DNS.

Solution

Ajouter un script bien placé, qui vérifie si on est derrière une Livebox pour modifier le fichier resolv.conf comme il se doit.

Le script est à placer dans /etc/network/if-up.d/fixdns avec le contenu suivant :

#!/bin/sh
# script pour ajouter d'autres serveurs dns derrière une livebox
# si on reconnait la livebox, on fait la modif dans le resolv.conf

if arp "$DHCP4_DHCP_SERVER_IDENTIFIER" | grep -q 00:1b:bf:3d:21:49
then
        cp /etc/resolv.conf.livebox /etc/resolv.conf
fi

Et voila, le tour est joué ! Cette solution a le mérite de fonctionner avec NetworkManager, qui n’exécute pas les scripts de /etc/dhcp3/dhclient-enter-hooks.d/.