Olivier a écrit 890 commentaires

Adepte inconditionnel de grub1, et notamment du mini-shell que l'on a en pré-boot avant le chargement des OS, je dois avouer que j'ai vu son arrivée il y plus de 2 ans, sur Debian Testing, avec une certains crainte.

Mais franchement, il n'y a pas de quoi faire un plat.

La syntaxe du grub.cfg est différente du menu.lst ? La belle affaire, ce n'est qu'une syntaxe.

Réinstallation de grub from scratch, notamment après des manips "foireuse" du genre effacement du MBR par un Windows fraichement installé ?

Il y a plusieurs méthodes:
- la technique "old school" : copier-coller d'un /boot/grub venant d'une autre machine, et lancement d'un "grub-install /dev/sdxx". Quand au /boot/grub/grub.cfg, il s'édite à la main sans problème

• la méthode "dans les règle de l'art" (les commandes sont pour une Debian/Ubuntu)
  • boot sur un live CD
  • montage du "/" defectueux en /mnt/casse
  • montage en bind des répertoires système: mount -o bind /dev /mnt/casse/dev mount -o bind /proc /mnt/casse/proc mount -o bind /sys /mnt/casse/sys
  • chroot: chroot /mnt/casse
  • restauration du mbr, création du /boot/grub/grub.cfg update-grub dpkg-reconfigure grub-pc
  • démontage des "bind" et de la partition
  • reboot sur le disque dur

Enfin, grub2 permet des trucs réellement sympa, comme le boot à travers une image ISO, sans avoir besoin de la décomprésser (*). C'est idéal pour avoir plusieurs distribs linux sur une même clé USB. Il suffit simplement de copier/coller l'image iso, en temps que fichier simple.

(*): Exemple pour de l'Ubuntu:
menuentry "Ubuntu 11.10 - Desktop - i386" {
insmod ext2
insmod loopback
insmod iso9660
set isofile="/iso/ubuntu-11.10-desktop-i386.iso"
loopback loop $isofile
linux (loop)/casper/vmlinuz locale=fr_FR bootkbd=fr console-setup/layoutcode=fr iso-scan/filename=$isofile boot=casper file=/cdrom/preseed/ubuntu.seed noprompt quiet splash --
initrd (loop)/casper/initrd.lz
}

Bref, grub2 c'est bon !

Cela n'a (presque) rien à voir avec le tatouage, mais un des effet de ces "protection" de Windows est d'insérer des signature dans la région du MBR et de celle de la piste 0.

Or, ce sont deux régions qui peuvent être modifiées par GRUB/LILO afin d'insérer leur propre mécanisme de boot.

Ainsi, après avoir installé un Linux, le Windows pourra ne plus booter parce qu'il ne trouve pas cette signature qui a été écrasé par GRUB/LILO. On retrouve dans ces signatures des informations diverses, comme des copie de zone du MBR, la taille des partitions, le nom du constructeur, etc…

La solution pour éviter ce genre de problème est de ne pas installer GRUB/LILO, mais de laisser au mécanisme de boot de Windows la sélection de l'OS : http://doc.ubuntu-fr.org/tutoriel/comment_amorcer_ubuntu_avec_bootmgr .

Evidement, il y a un effet de blue pill http://en.wikipedia.org/wiki/Blue_Pill_%28software%29 … :=(

Ton Windows ayant une carte réseau, il présente tous ses port sensibles (SMB, RDP, UPnP, etc…) sur le réseau local. De ce fait, si un autre Windows se connecte sur ton réseau local (soit par le fil, soit par le wifi), il y a risque d'attaque.

Autre vecteur possible : La Debian. A priori, un programme exécuté sur la Debian a accès aux port du Windows, et donc il peut l'attaquer.

De même qu'un programme fonctionnant sur la SFRBox peut accéder aux ports ouverts du Windows. C'est peu probable, mais je ne doute pas que la SFRBox puisse recevoir les messages de broadcast du Windows, l'UPnP, ou toute autres protocoles d'auto-découverte de ce type.

Enfin, à propos de ta phrase:
> qui au passage ne se connecte pas au web
J'en déduits donc que tu:
- as désactiver les services DNS et DHCP du Windows
- as configuré en IP statique le Windows
- n'a pas renseigné les adresses de DNS et de passerelle
n'est-ce pas ?

Si tu veux limiter la casse pour ton Windows:
- désactive tout les services inutiles du Windows, afin de fermer un maximum de port. Sous windows, la commande "netstat -an" te dira quels sont les ports ouverts
- mets en place un firewall sur le Windows. A voir si le firewall intégré à Windows est suffisant.

Essayes d'augmenter la verbosité des logs, histoire d'avoir une idée de la cause du plantage :
ssh -vvv user@host

C'est assez ridicule de dire qu'il faut préférer Chrome parce qu'il intègre Flash nativement : Chrome utilise le plugin flash développé par Adobe, et non pas un exécutable "maison".
Donc Chrome est autant affecté que Firefox par l'arrêt de développement de Flash sous Linux.
Pour ce qui est du support de Flash, la seule différence entre que Chrome et Firefox, c'est que l'un intègre par défaut le plugin, alors que l'autre non.
Mais les distributions Linux proposent généralement des mécanismes permettant d'installer flash simplement via un paquet (deb/rpm/autre).
Sous Debian par exemple, il s'agit de flashplugin-nonfree

Le "Microsoft Security Bulletin MS12-020" dont il est question ici impacte toutes les versions de Windows, depuis XP à Seven.
Le lien indiqué plus haut ( http://technet.microsoft.com/en-us/security/bulletin/ms12-020 ) le dit clairement.

Le test sur un XP est donc valable.

J'ai testé les scripts avec une VirtualBox de Windows XP + S3, en prenant bien soin de faire un snapshot juste avant.

• Les scripts 1 et 3 mettent le CPU de Windows à 100% pendant quelques dizaines de secondes
• Le script 2 ne semble pas faire grand chose
• Par contre, en utilisant les scripts 1 ou 3, puis le script 2, le Windows s'arrête immédiatement. Effet collatéral regrettable, il ne veut pas redémarrer, sauf en mode sans échec… ;)
• Une fois le patch MS appliqué, le précédent test est sans effet, et le "eventvwr" affiche une trace de ta tentative d'intrusion.

La restauration du snapshot permet de revenir à l'état normal.

Conclusion : Il vaut mieux désactiver le remote desktop, voire mieux, ne pas avoir de Windows du tout ! ;)

D'après la vidéo, l'Ubuntu embarqué a accès aussi bien aux photos, vidéos, contacts, applications Android, etc..., qui sont stockés dans l'Android. Comment est-ce que cet accès est-il possible ? Comment l'Android export-il son FS vers l'Ubunu ? Via un partage réseau du style NFS ou SMB ?

Je ne dis pas que le créateur du site est même que le compte de ce journal.

Ce que je dis, c'est que le compte "Marc Letigre" est très probablement bidon, tout aussi inutile que son contenu de ce journal.

Bref, un journal de pseudo-pub sans intérêt.

GRUB peut s'amuser à chercher à un lecteur de disquette lors du boot. Si celui-ci n'existe pas, ou que le lecteur est vide, il y a un perte significative de temps lors du boot.

Autre hypothèse : la configuration de GRUB fait qu'il cherche une partition qui n'existe plus. Regarde dans le /boot/grub/menu.lst (GRUB1) ou /boot/grub/grub.cfg (grub2), et recherche :

• soit des noms de disques (/dev/hda, /dev/sda, ...) ou de partions (/dev/hda1, /dev/sda1, ...), qui n'existent pas
• soit des identifiants de disques (UUUID) qui ont disparus. Sous linux, la commande:

blkid

permet d'afficher la liste des partitions

Enfin, il est possible que ton grub/linux ait changé la manière d'accéder aux disques : de /dev/hda il est passé à /dev/sda . Auquel cas, il est nécessaire de revoir la configuration de /boot/grub/menu.lst (GRUB1) ou /boot/grub/grub.cfg (grub2).

Il est amusant que le pseudo "Marc Letigre" soit aussi proche d'un article de 2009 du site "Le tigre", qui dévoile la vie d'un "Marc L.", qui laissait trainer toutes ses informations personnelles sur Internet : http://www.le-tigre.net/Marc-L.html

Lorsque tu lances le "tcpdump" depuis la session interaxtive, tu le fais avec quelque chose du style "tcpdump -i eth0" ?

Essayes plutôt un "tcpdump -n -i eth0" : Cela évitera à tcpdump à associer un nom DNS aux adresses IP qu'il affiche.

Dans ce cas, si la connexion est de nouveau lente pour les machines en interne, c'est que tu as un problème lié aux DNS

De plus, je vois dans ta configuration un "other ports domain:tcp". Or, généralement les machines connectées à internet utilise de l'UDP pour faire la résolution nom/adresse IP (ie: ce qui doit s'appeler ici "domain").

Essayes donc avec un "other ports domain:udp"

L'image défie à mon avis les lois de la physique : Du fait de la gravité, les trajectoires verticales (montée & descente) devraient être plus longues que les trajectoires horizontales (vers la gauche et la droite).

J'ai plusieurs machines en Debian Testing, et sur certaines d'entre elle, depuis le passage à des kernel > 2.6.26, quelles unes ne peuvent plus booter.

Le problème vient de la synchronisation SATA, mais je l'ai aussi retrouver sur du SCSI.

La solution est de passer le paramètre suivant au boot, afin de forcer l'usage d'une certaine vitesse du contrôleur disque dur :

libata.force=noncq,1.5Gbps

Si nécessaire, on peut aussi tester avec
acpi=off

Il y a plusieurs mois, j'ai observé le même phénomène sur Debian Testing.

J'ai résolu en parti les problème en installant HAL (qui n'était plus utilisé par Debian), et en rajoutant mon utilisateur au group "powerdev".

Cependant, il y avait toujours quelques problèmes, et j'ai fini par trouver sur divers site que le problème vient de conflit entre slim + XFCE + polkit.

La solution la plus simple à été de virer slim, et d'installer gdm (2).

Depuis, plus de problème.

L'adoption par le grand public nécessiterait une interface plus... moderne ?

Je rejoins les commentaires ci-dessus. Personnellement, au boulot je suis capable d'utiliser un Windows XP et un Office < 2007 pratiquement uniquement au clavier, en utilisant les raccourcis claviers et les déplacement à travers les menus grâce aux touches (ctrl, alt, tab, fleches, ...).

Depuis le passage obligé à Seven et Office 2010, j'ai perdu cette possibilité (même la navigation à travers le simple "explorer" est devenu une horreur), et je suis obligé d'utiliser la souris. Résultat : Perte d'efficacité, je suis moins rapide pour toutes les opérations.

Bonsoir,

à priori, le hard reset de la Freebox c'est de la débrancher 5 fois, et non pas 4.

Peut-être que la box a un "vieux" firmware, et que comme tu ne l'as jamais redémarré 5 fois, elle n'a jamais téléchargé un plus récent ?

Ma recommandation est que tu procèdes à 5 reboots, afin d'être sûr que la box download un "bon" firmware. Dur le "hard reboot", on voit clairement que la boxe se connecte une 1ère fois à Internet, download le firmware, puis se reconnecte à nouveau.

Il y a des années, j'avais entendu un problème de ce type chez un ami. L'explication aurait été que de multiples et brèves déconnexions électriques forcent la box à se mettre dans un mode par défaut, c'est à dire en mode bridge.

La solution serait alors de :
- vérifier qu'il n'y ait pas de saut de tentions coté EDF. Voir, d'installer un boîtier de filtrage/parafoudre sur les prises 220v ET téléphonique
- et/ou vérifier qu'il n'y a pas de faux contact sur la prise électrique. Voir, de changer la multiprise
- de coupler la box à un onduleur ?
- de vérifier aussi si la prise téléphonique est "clean". Chez moi, j'ai découvert que les fils étaient oxydés au niveau de la prise en "T". J'ai tout supprimé, et refais les connexions avec de la soudeur à l'étain.

A priori, le "+fast-redirects" a des problèmes avec le paramètre "&ie=xxxxxxxxxxxxxxx" que Google rajoute. On corrige le problème par un double filtrage:

# 2011/11/26: Prevent Google to monitor clicked html links
{ +redirect{s@&ei=.*@@} }
.google.*/url\?
{+fast-redirects{check-decoded-url}}
.google.*/url\?

Note: Cela marche si l'ordre des paramètres est "url=yyyyyy&ie=xxxxxx" . Si "url=yyyyyy" est après "ie=xxxxxx",a la redirection échoue (le lien est cassé).

D'après les logs, c'est le module réseau qui a crashé.

Outre un problème lié au code source du driver dans le kernel Linux, le problème est peut-être purement hardware.

L'année dernière, je m'étais acheté une carte réseau gigabyte PCI-expresse pas chère du tout sur eBay. Je me suis rapidement rendu compte que cela rendait le kernel super instable (crash), et aussi que le chipset principale de la carte chauffait beaucoup. Il y n'y avait pas de dissipateur thermique dessus, ce qui explique peut-être les problèmes. En tout cas, j'ai rapidement retiré la carte de ma machine, et depuis, plus de problème.

Par hasard, est-ce que les chipsets north/southbridge ne chauffent pas trop ? Ou alors, un composé commence a vieillir sur la machine (un condensateur par exemple, ce qui fait planter la partie réseau).

Peux-tu désactiver cette carte réseau, et en utiliser une autre ?

Merci pour ce retour d'information. Il est effectivement surprenant que ce type de manipulations de fonctionnent pas.

Quel est l'intérêt d'avoir un "compatible PC" si c'est pour se retrouver avec du hardware qui est verrouillé ?

Après le tatouage de l'OS, les constructeurs de mettent au tatouage du hardware ? C'est assez lamentable... :=(

Il y a quelques temps, depuis le passage dans les derniers kernel 2.6 (je suis en Debian Testing, donc cela évolue régulièrement), j'ai moi aussi vu ce genre de messages lier au disque dur.

Le problème ne vient pas du disque, mais de la manière dont le kernel négocie la vitesse du contrôleur SATA(/PATA). Cela se configure en passant des paramètres au kernel ( http://www.kernel.org/doc/Documentation/kernel-parameters.txt ).

Ce n'est pas super évident à analyser, et il faut faire des tests "jusque cela marche". Avec évidement un reboot pour chaque tests... :=(

Voici les différents combinaisons que j'ai utilisé:
libata.force=noncq
libata.force=noncq,1.5Gbps
libata.force=noncq,3.0Gbps
libata.noacpi
acpi=noirq
acpi=off

La dernière option est un peu une "arme atomique" qui bride pas mal la machine (les modes hibernation/suspend ne marcherons par exemple plus). Mais elle a au moins eu le mérite de marcher dans les conditions les moins favorables.

Plus d'informations ici : http://ubuntuforums.org/showthread.php?t=1014723

Pour info, c'est bien un problème de kernel. En boutant la machine sur un kernel plus ancien, le problème n'apparaît plus. De plus, le problème apparaît sur différentes machines, plus ou moins anciennes, laptop ou desktop.

Bonjour,

la syntaxe ci-dessous fonctionne chez moi (/etc/privoxy/user.action):

# 2011/11/26: Prevent Google to monitor clicked html links
{+fast-redirects{check-decoded-url}}
.google.*/url\?

Le /var/log/privoxy/logfile affiche alors ceci :
Crunch:Redirected:http://www.google.fr/url?...&url=http%3A%2F%2Fwww.lesitevisite.com%2F&...
http://www.lesitevisite.com/

Sur mon précédent laptop de bureau, j'ai remarqué qu'avec le temps la batterie pouvait bouger lorsque je me déplaçais. Ainsi, cela pouvait générer une micro-coupure suffisamment longue pour que la mémoire ne soit plus rafraichit, et que le mode veille tombe.

Aussi, le mode d'hibernation est pratique pour cela : Pas de risque si la batterie se déconnecte.

Comment cela fonctionne t'il en pratique ?

En mode veille, il y a un process Linux qui continue de fonctionner ? Cela me paraît difficile.

Ou alors, c'est le laptop qui se réveille de lui-même. Le Linux se rendant compte que la batterie est en état critique, il bascule de lui-même en hibernation ?

Il faut avoir une sacrée confiance dans l'ACPI pour que cela marche !

Oups, le nouveau site à manger les "#" devant les 2 lignes en gras.