Warning: Attempt to read property "taxonomy" on null in /homepages/39/d85700215/htdocs/esquimo.org/blog/v3/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 155

Warning: Attempt to read property "taxonomy" on null in /homepages/39/d85700215/htdocs/esquimo.org/blog/v3/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 184

Warning: Attempt to read property "taxonomy" on null in /homepages/39/d85700215/htdocs/esquimo.org/blog/v3/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 190
Informatique et technique – Eskimo'z Blog
Warning: Attempt to read property "taxonomy" on null in /homepages/39/d85700215/htdocs/esquimo.org/blog/v3/wp-content/plugins/wordpress-seo/src/presentations/indexable-term-archive-presentation.php on line 222

update TP-Link wifi drivers after rpi-update

Il y des update réguliers sur le firmware du Pi, et à chaque fois les drivers wifi sautent.
Voici ce qu’il faut faire pour que ça se fasse sans douleur

root@raspberrypi:~# rpi-update

*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom

*** Performing self-update

*** Relaunching after update

*** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom

#############################################################

This update bumps to rpi-4.1.y linux tree

Be aware there could be compatibility issues with some drivers

Discussion here:

https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=113753

##############################################################

*** Downloading specific firmware revision (this will take a few minutes)

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current

                                 Dload  Upload   Total   Spent    Left  Speed

100   168    0   168    0     0    364      0 –:–:– –:–:– –:–:–   481

100 49.2M  100 49.2M    0     0   247k      0  0:03:23  0:03:23 –:–:–  362k

*** Updating firmware

*** Updating kernel modules

*** depmod 4.1.17-v7+

*** depmod 4.1.17+

*** Updating VideoCore libraries

*** Using HardFP libraries

*** Updating SDK

*** Running ldconfig

*** Storing current firmware revision

*** Deleting downloaded files

*** Syncing changes to disk

*** If no errors appeared, your firmware was successfully updated to 2ea8550c0fc6f4b916b3698fad857138d8a2da64

*** A reboot is needed to activate the new firmware

root@raspberrypi:~# uname -a

Linux raspberrypi 4.1.15+ #830 Tue Dec 15 16:58:28 GMT 2015 armv6l GNU/Linux

 

On vient donc de passer du 4.1.15 #830 au 4.1.17 qui est le #834

Se rendre sur

https://www.raspberrypi.org/forums/viewtopic.php?p=462982#p462982

Pour récupérer le lien vers l’installeur du dongle wifi (à lancer après le reboot ost update)

Copier le nom du fichier et le coller dans une barre d’adresse après le début suivant :

https://dl.dropboxusercontent.com/u/80256631/

et donc 8188eu-20160201.tar.gz

Soit dans notre exemple https://dl.dropboxusercontent.com/u/80256631/8188eu-20160201.tar.gz

root@raspberrypi:~/wifi/834# wget https://dl.dropboxusercontent.com/u/80256631/8188eu-20160201.tar.gz

–2016-02-18 21:13:03–  https://dl.dropboxusercontent.com/u/80256631/8188eu-20160201.tar.gz

Resolving dl.dropboxusercontent.com (dl.dropboxusercontent.com)… 108.160.173.5

Connecting to dl.dropboxusercontent.com (dl.dropboxusercontent.com)|108.160.173.5|:443… connected.

HTTP request sent, awaiting response… 200 OK

Length: 415459 (406K) [application/octet-stream]

Saving to: `8188eu-20160201.tar.gz’

100%[========================================================================================================================================================================>] 415,459     1021K/s   in 0.4s    

2016-02-18 21:13:10 (1021 KB/s) – `8188eu-20160201.tar.gz’ saved [415459/415459]

 Lancer l’installation

root@raspberrypi:~/wifi/834# tar -xzvf 8188eu-20160201.tar.gz

8188eu.ko

8188eu.conf

install.sh

root@raspberrypi:~/wifi/834# ./install.sh

sudo cp 8188eu.conf /etc/modprobe.d/.

sudo install -p -m 644 8188eu.ko /lib/modules/4.1.17+/kernel/drivers/net/wireless

sudo depmod 4.1.17+

Reboot to run the driver.

If you have already configured your wifi it should start up and connect to your

wireless network.

If you have not configured your wifi you will need to do that to enable the wifi.

et dernier reboot

En principe le wifi refonctionne correctement, sinon attendre quelques jours voir s’il n’y a pas une mise à jour du driver (ça m’est déjà arriver, j’ai fait l’update juste après la publication)

Mise à jour suite au passage du kernel en 4.4.X, un installeur automatique à été développé.

wget https://dl.dropboxusercontent.com/u/80256631/install-wifi.tar.gz

tar xzf install-wifi.tar.gz

Puis simplement:

./install-wifi

Par contre sur le mien ça ne fonctionne pas vraiment, le driver 8188eu.ko ne veut pas s’inserer dans le kernel (erreur de symbole).
Il faut donc dans ce cas la télécharger et installer wget https://dl.dropboxusercontent.com/u/80256631/8188eu-‘kernel-version’-v7-‘#number’.tar.gz

(ex: wget https://dl.dropboxusercontent.com/u/80256631/8188eu-4.4.7-v7-876.tar.gz)

rapsberry pi wifi dongle tplink setup

Pour faire fonctionner le wifi sur le pi avec le dongle tplink 875n :

Installer « wpa-supplicant »

apt-get install wpasupplicant

Télécharger le driver du dongle

https://github.com/lwfinger/rtl8188eu/raw/c83976d1dfb4793893158461430261562b3a5bf0/rtl8188eufw.bin -O /lib/firmware/rtlwifi/rtl8188eufw.bin

Editer le fichier de conf /etc/wpa_supplicant/wpa_supplican.conf

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev

update_config=1

ap_scan=1

network={

 ssid= »YourSSID »

proto=RSN

key_mgmt=WPA-PSK

pairwise=CCMP

group=CCMP

 psk= »YourPSK »

}

Dans le fichier /etc/network/interfaces

allow-hotplug wlan0

iface wlan0 inet dhcp

wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

iface default inet dhcp

Puis reboot si ca ne fonctionne pas

Synology volume crashed

synology volume crashed

En janvier il m’est arrivé un truc pas drôle du tout !

Un des HDD du nas faisait de temps en temps des siennes, mais rien de bien alarmant jusque là, quelques erreurs « reallocate sector count ».

Et pis un jour … CRACK !! Le disque complètement HS. Ca se met à sonner dans tous les sens, je me connecte, je me dis que ce n’est qu’un petit soucis passager (je venais de passer des semaines à me battre avec le volume raid du fixe qui a définitivement mourru), je clique donc sur réparer.

Ni une ni deux il m’envoie chier et le volume passe de « volume degraded » à « volume crashed ». Tiens j’avais pas eu encore ça, crashed. Un peu inquiet, mais je me dis c’est du solide, ca fait 4 ou 5 ans que je l’ai, et à part remplacer les disques qui meurent je n’ai pas eu beaucoup d’embrouilles avec le nas.

Pour pas tenter le diable et une faiblesse potentielle d’un autre disque, j’éteints tout. Une fois le nous 6To reçu, je charge le bidule, appuie sur power et attends. Longtemps.

Mais je sais qu’en mode degraded ça peut prendre vraiment beaucoup de temps à démarrer. Le lendemain toujours rien, de plus en plus inquiet je regarde ce qu’il se passe. Pas d’accès à l’interface web. Castagnette, j’irais en SSH. Ouf ça passe. Je branche un écran sur le port VGA et redémarre. Rien à l’écran à part le BIOS, et mon accès SSH qui me dit que j’ai pu rien de monté et/ou accessible.

A force d’acharnement, un 2ème disque se met à clignoter en jaune … ouuuuh pas bon ! Parce que un raid 5 avec un disque de moins ça va. Avec 2 disques de moins, ya pu rien !! Et impossible d’initialiser le vieux ou le neuf.

Bref, le deuxième disque semblait fonctionner encore, et après avoir attendu une réponse du servicedesk synology je me lance dans les commandes bizarres, dont la dernière qui a permis de tout réparer (mais elle fait flipper quand même) :

De mémoire avant il faut forcer le montage du volume en RW (c’est à dire faire un arrêt des services en mode debug pour pouvoir garder la main en SSH)

_NAS> fsck.ext4 -yvf -C0 /dev/vg1000/lv
e2fsck 1.42.6 (21-Sep-2012)
1.41.10-1922: recovering journal
Journal transaction 32135694 was corrupt, replay was aborted.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted orphan linked list found. Fix? yes

Inode 54 was part of the orphaned inode list. FIXED.
Deleted inode 55 has zero dtime. Fix? yes

Inode 58 was part of the orphaned inode list. FIXED.
Inode 513294383 was part of the orphaned inode list. FIXED.
Inode 513294384 was part of the orphaned inode list. FIXED.
Inode 513294388 was part of the orphaned inode list. FIXED.
Inode 513294397 was part of the orphaned inode list. FIXED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
/lost+found not found. Create? yes

Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences: -9249 -479135389 -(479150196–479150197) -(479150707–479150772) -479150774 -(479150788–479150852) -(479150854–479150922) -(479150924–479150987) -(479150989–479151052) -(479151054–479151117) -(479151119–479151264) -(479151739–479151775) -(479152273–479152350) -479152352 -(479152862–479152863) -(479153369–479153374) -(479153880–479153885) -(479154391–479154396) -(479154902–479154971) -(479154973–479155036) -(479155038–479155041) -(479155043–479155114) -(479155624–479155690) -(479155692–479155767) -(479155769–479155834) -(479155836–479155953) -(479155955–479155969) -(479155971–479155976) -(479155978–479156051) -(479156053–479156116) -(479156118–479156181) -(479156183–479156247) -(479156249–479156263) -479156265 -(479156330–479156343) -(479156345–479156347) -(479156349–479156350) -(479156353–479156357) -(479156359–479156362) -(479156365–479156406) -(479160320–479160613) -(479160615–479161151) -479161153 -(479161155–479161330) -(479161332–479161348) -(479161399–479161462) -(479161970–479161974) -(2084249418–2084249422) -2084249427 -(3143946240–3143948287) -(3144208384–3144210431) -(3144214528–3144216575) -(3144221696–3144222552) -(3144222720–3144224767) -(3144255488–3144286207) -(3144288256–3144297606)
Fix? yes

Free blocks count wrong for group #0 (125, counted=126).
Fix? yes

Free blocks count wrong for group #14622 (207, counted=2890).
Fix? yes

Free blocks count wrong for group #63606 (2730, counted=2736).
Fix? yes

Free blocks count wrong for group #95945 (1140, counted=3188).
Fix? yes

Free blocks count wrong for group #95953 (1435, counted=5531).
Fix? yes

Free blocks count wrong for group #95954 (653, counted=3558).
Fix? yes

Free blocks count wrong for group #95955 (1523, counted=32243).
Fix? yes

Free blocks count wrong for group #95956 (10130, counted=19481).
Fix? yes

Free blocks count wrong (603623449, counted=568996513).
Fix? yes

Inode bitmap differences: -55 -58 -(513294383–513294384) -513294388 -513294397
Fix? yes

Free inodes count wrong for group #0 (8134, counted=8137).
Fix? yes

Free inodes count wrong for group #62658 (7949, counted=7953).
Fix? yes

Free inodes count wrong (910910945, counted=910899492).
Fix? yes
1.41.10-1922: ***** FILE SYSTEM WAS MODIFIED *****

3622620 inodes used (0.40%, out of 914522112)
53612 non-contiguous files (1.5%)
763 non-contiguous directories (0.0%)
# of inodes with ind/dind/tind blocks: 0/0/0
Extent depth histogram: 3605955/16142/55
3089090911 blocks used (84.45%, out of 3658087424)
0 bad blocks
633 large files

2543334 regular files
1063661 directories
4 character device files
0 block device files
2 fifos
5076 links
15588 symbolic links (431 fast symbolic links)
21 sockets
————
3627686 files
_NAS>

Une fois ceci fait, toujours rien d’accessible. Je me résous à redémarrer à nouveau, et partir pour aller ailleurs. 1h ou 1h30 plus tard je reçois la notification pour me dire qu’il est repassé en mode dégradé. Je me connecte, il detecte des modifications faites hors interface et propose de les réparer, je dis oui. Attends, attends, attends, puis finalement quelques jours plus tard toute cette histoire était dernière nous.

Pour le moment je ne crois pas avoir détecté une perte de fichiers quelconque 🙂

Windows 7 – Persistance du menu contextuel

A force d’en avoir marre, j’ai fini par jeter un œil sur Windows 7 et la saloperie de persistance du menu contextuel.

Pour tout dire, un jour ça commence comme ça

 

menu_contextuel_transparent

 

On clique sur un des menus, et paf

menu_persistant

 

Le bon truc de daube ou on se fait avoir à tous les coups.

Et à priori à part redémarrer, pas de solutions.

 

En fait si, mais efficace a 90% au maximum à priori.

La première technique quand ça arrive c’est de tenter un

net stop uxsms

puis

net start uxsms

Mais voilà, ça ne fonctionne pas à tous les coups

Il y aurait une de ces options qui aideraient à limiter l’apparition du phénomène

Dans Panneau de configuration -> Système -> Paramètres système avancés -> Avancé -> Performance -> Paramètres

options_système

Il faut alors décocher une, deux ou les trois cases entourées.

(fade or slide menus into view, tooltips, menu items after clicking)

Après avoir appliqué les réglages s’il n’y à pas de changement, répéter les commandes au dessus.

Pour le moment ça m’a permis de m’en débarrasser à chaque fois sans avoir à redémarrer.

 

DSM update get ipkg back

Parce que je me fais avoir à chaque mise à jour du DSM synology

wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh

Pour récupérer ipkg et autres paquets installés il faut éditer /root/.profile et y ajouter juste après PATH= /opt/bin:/opt/sbin: 

Comme ça je ne chercherai plus 🙂

 

Et sinon pour le reste de l’installation

1. Within your SSH session, change to a temporary location (note that you will probably need to be logged in as root to do all this)

cd /tmp

2. Download the bootstrap script

wget http://ipkg.nslu2-linux.org/feeds/optware/syno-i686/cross/unstable/syno-i686-bootstrap_1.2-7_i686.xsh

3. Make the file executable

chmod +x syno-i686-bootstrap_1.2-7_i686.xsh

4. Run the script

sh syno-i686-bootstrap_1.2-7_i686.xsh

5. If it all went well, remove the script

rm syno-i686-bootstrap_1.2-7_i686.xsh

6. Update the package list

ipkg update

Comment gagner de l’espace sur le disque système Windows 7 (winsxs cleanup)

J’ai découvert cette semaine qu’il existe un dossier « c:\Windows\winsxs », et qu’il est particulièrement gourmand en espace disque pour peu qu’on fasse quelques mises à jour système.

Sur mon pc fixe le dossier faisait 11,755 Go

winsxs_before

Après avoir exécuté la commande DISM /online /Cleanup-Image /SpSuperseded le dossier ne faisait plus que 8,037 Go, 

winsxs_after

soit une économie de 3.7Go, ce qui est plutôt intéressant. Cette différence n’est pas commune à toutes les installations, entre le portable et un autre fixe le gain est compris entre 2 et 5 Go.

Cette commande nettoie les fichiers d’installation, mais ne permet plus par la suite de désinstaller un Service Pack.

La manipulation dure entre 2 et 10 minutes en fonction de la vitesse du disque.

winsxs command

Limiter le jail ftp à seulement certains utilisateur de proftpd

En fait pas besoin de s’embetter avec des droits de lecture ou d’écriture un peu partout, ou de umask, il suffit de créer un ou plusieurs groupes système, d’ajouter les utilisateurs à ce groupe usermod -a -G admin-group toto, et de jail dans la conf proftpd les utilisateurs qui ne font pas partie de ce groupe:
DefaultRoot /path/to/admin/dir admin-group
DefaultRoot /path/to/special/dir special-group
DefaultRoot ~ # everyone else

Et voila, maintenant l’utilisateur toto a le droit de se balader ou il veut, alors que les autres sont restreints dans leur homedir