slack a écrit 349 commentaires

S'il s'agit de fichiers personnels, tu dois pouvoir brancher une clé usb sur un port libre de ton pc puis y lire/sauvegarder des fichiers comme s'il s'agissait d'un disque dur.

S'il s'agit de modifier des fichiers de configuration de slax, il faudra modifier ta clé qui contient ton système.

Je n'ai pas utilisé cette distribution depuis des années. Si elle est toujours basée sur slackware et que tu souhaites toujours sauvegarder des fichiers sur une clé au shutdown, tu devras modifier le fichier /etc/rc.d/rc.0 mais cela demande des connaissances en script bash.

Par manque d'informations, il est difficile d'être plus précis.

Bonjour

Voici une piste qui permet de conserver les noms des répertoires et des fichiers.

Sous windows, crée une archive zip contenant une copie des répertoires et des fichiers que tu veux conserver. Sauvegarde l'archive sur clé usb. Puis lance ta machine avec le live usb et essaye de désarchiver l'archive zip.

Merci

lors desinstalle totalement les pilotes que tu as precedemment installé, et installe ceux du constructeur via rpm2tgz

Pour configurer cups, je pointe mon navigateur web à l'adresse 127.0.0.1:631

Lorsque un essais est infructueux , je supprime dans cups l'imprimante.

Enfin je suis sur d'avoir désinstallé le pilote compilé à la main avant d'installer les paquets rpm.

sinon pour repondre à quelqu'un il faut cliquer sur "repondre" sous son texte et pas sur "envoyer un commentaire" qui repond à ton post initial.

Merci :-)

P.S. je continue mes instigations

Bonjour

Slackware fournit dans le paquet rpm2tgz des scripts rpm2tgz et rpm2txz qui permettent la conversion des paquets debian en paquets slackware.

Merci à tous pour vos remarques.

Ce disque sent vraiment le moisi, mais il n'est pas le seul responsable des dysfonctionnements. J'ai rencontré les mêmes problèmes de plantages après avoir remplacé le disque dur par celui d'un autre PC où il fonctionne très bien.

Sur le PC problématique avec le disque sain, voici ce que me renvoie grep BUG /var/log/syslog après la compilation d'un noyau qui a fini par planter :

Aug 30 22:12:32 PC kernel: [ 937.038959] BUG: Bad page map in process as pte:80000000292f4067 pmd:22c9a067
Aug 30 22:12:32 PC kernel: [ 937.039749] BUG: Bad rss-counter state mm:f65421c0 idx:0 val:-1
Aug 30 22:12:32 PC kernel: [ 937.039806] BUG: Bad rss-counter state mm:f65421c0 idx:1 val:1
Aug 30 22:12:32 PC kernel: [ 937.076074] BUG: Bad page state in process cc1 pfn:292f4
Aug 30 22:12:33 PC kernel: [ 937.554192] BUG: Bad page map in process cc1 pte:800000003014a067 pmd:1d922067
Aug 30 22:12:33 PC kernel: [ 937.555876] BUG: Bad page state in process cc1 pfn:3014a
Aug 30 22:12:34 PC kernel: [ 938.456396] BUG: Bad page map in process cc1 pte:8000000003f0e067 pmd:1d922067
Aug 30 22:12:34 PC kernel: [ 938.459442] BUG: Bad page state in process cc1 pfn:03f0e
Aug 30 22:13:29 PC kernel: [ 993.830485] BUG: Bad page map in process cc1 pte:80000000152ee067 pmd:1d922067
Aug 30 22:13:29 PC kernel: [ 993.925038] BUG: Bad rss-counter state mm:f66eefc0 idx:0 val:-1
Aug 30 22:13:29 PC kernel: [ 993.925039] BUG: Bad rss-counter state mm:f66eefc0 idx:1 val:1
Aug 30 22:14:26 PC kernel: [ 1050.791509] BUG: Bad page map in process cc1 pte:8000000028d2a067 pmd:1d922067
Aug 30 22:14:26 PC kernel: [ 1050.804518] BUG: Bad rss-counter state mm:f66eefc0 idx:0 val:-1
Aug 30 22:14:26 PC kernel: [ 1050.804519] BUG: Bad rss-counter state mm:f66eefc0 idx:1 val:1
Aug 30 22:16:08 PC kernel: [ 1153.114947] BUG: Bad page state in process umount pfn:152ee

Je vous fait grâce des rapports complets de plantages du noyau dans le fichier /var/log/syslod.

Je pense pour un problème d'alimentation : après avoir été arrêté, ce PC n'a pas voulu redémarrer. Il a fallu couper la multiprise quelques minutes pour qu'il se relance, toujours aussi instable.

Prochainement, je lancerai memtest et j'échangerai les RAM des deux PC.

Et encore merci pour votre aide.

Slack

Merci pour les précisions données.

Slack

s/sont propre/son propre/

s/les enfants adore/les enfants adorent/

As-tu testé les cartes beagleboard ?
http://beagleboard.org

J'ai acheté la version beaglebone qui consomme 5 W, offre une connecteur ethernet 100, un port USB, plein de GPIO (ports série, SPI, I2C …) mais pas de port ide ou sata.

Graveen

Je ne comprends pas l'exemple donné dans le lien.

Voici où j'en suis :
* désarchivage des sources du noyau 3.2.18 sur la microsd de la carte.
* compilation sur la carte dans le répertoire des sources Documentation/spi des exécutables spidev_test et spidev_fdx.
* relier les broches 29 et 30 du port P9 (MISO et MOSI)
* lancer spidev_test -D /dev/spidev2.0
* lancer spidev_fdx -D /dev/spidev2.0

Ces dernières montrent que la carte reçoit sur l'entrée MISO les données envoyées sur la sortie MOSI.

Il reste à comprendre le fichier spidev_test.c et à utiliser un microcontrôleur msp430 comme esclave pour maîtriser complètement la mise en œuvre du protocole SPI avec la carte beaglebone.

Merci pour ton coup de main.

Jean-Baptiste

Merci pour ce mémo très instructif.

Au cours de la lecture de ton document avec firefox 9.0.1, les liens "Top", "Previous" et "Next" fonctionnent correctement. Par contre, le bouton "reculer d'une page" de ce navigateur ne fonctionne pas comme prévu à partir d'une sous page : le navigateur n'affiche pas la page précédente mais la page consultée avant l'index !

Par exemple, si je consulte les pages :
http://jeanbaptiste-bourgoin.com/index.html
http://jeanbaptiste-bourgoin.com/informatique/autohebergement/dreamplug1.html
http://jeanbaptiste-bourgoin.com/informatique/autohebergement/dreamplug1.html#sec-1-1

puis si je clique sur le bouton "reculer d'une page", firefox affiche la page http://jeanbaptiste-bourgoin.com/index.html et non la table des matières.

Cordialement

Slack

facile à construire à partir d'un script facilement compréhensible et adaptable à souhait ?

Après avoir copié le module dans le répertoire
/lib/modules/2.6.33.3/kernel/drivers/usb/serial

lance la commande depmod -a pour mettre à jour la liste de modules disponibles.

Ensuite, la commande modprobe cm15a doit pouvoir charger le module.

Pour udev, je ne sais pas faire et cela dépend de ta distribution (à préciser).

Bon courage.

Slack

Bravo pour ta réussite.

nfs : le système hôte ne m'autorisait pas exécuter les binaires présents

Il y a deux causes possibles :
* un problème de configuration sur le serveur (une piste : les options du fichier /etc/exports sur le serveur)
* les options utilisées par la commande mount sur le client ( l'option noexec interdit de lancer les binaires, utilise l'option exec)

Uboot configuré avec des erreurs à la base (ARCH_NUMBER incorrect, ce qui empêchait le boot de mon nouveau noyau uImage fraichement compilé

l'ARCH_NUMBER doit être modifié en fonction du noyau à lancer. Pour une raison qui m'échappe, il change suivant que l'on utilise le noyau fourni par le fabricant ou un noyau vanilla. Cela ne semble pas être une erreur de configuration d'uboot.

un guruplug qui présente de nombreux problèmes de fabrication: problème thermique

Comment solutionne-tu le problème ?

j'en ai quand même fumé 1. Plus moyen d'avoir uBoot au démarrage lol.

Est-ce l'alimentation qui a laché ou bien la carte électronique ? As-tu essayé avec la sonde jtag ? Quid de la garantie ?

Encore bravo et merci pour ton partage d'expérience.

Slack

Je ne connaissais pas ces machines. Merci pour l'information.

J'ai utiliser un ordi comme ça,

Merci pour le partage d'expérience. As-tu le souvenir du modèle ?

Je connaissais ce type de modules mais vu la taille du site, je ne pense pas que le système et le site tiendront dans 4Mo.

Merci pour l'idée.

mrproper

OUi. Je me suis trompé. En fait je récupère la config après avoir fait du ménage avec mrproper.

Lance mrproper avant de copier la configuration du noyau en fonctionnement.

récupération de la configuration du noyau d'origine ###

Attention, lorsque tu fais :

 Compilation du nouveau noyau
 #cp -p /proc/config.gz /mnt/nfs/linux-2.6.33.3/.config
 #cd /mnt/nfs/linux-2.6.33.3
 #make config
 #make (*)
 #make modules_install

tu recopies la configuration compressée du noyau en fonctionnement que tu recopies
dans les sources du nouveau noyau. Il faut impérativement décompresser le fichier .config.gz dans les sources sinon, le système de construction du noyau ne reconnait pas le fichier .config.gz et utilise une configuration par défaut. C'est pour cette raison que tu es obligé de lancer

make config

Normalement, un simple

make oldconfig

devrait suffire. Relis attentivement mon précédent post où les étapes sont commentées.

Conseil : sauvegarde quelque part les fichiers .config utilisés (celle de ton noyau d'origne, celle des noyaux que tu compiles) et compare ces fichiers avec la commande

diff -u fichier1 fichier2

pour vérifier que d'un noyau à un autre, certaines options n'ont pas été involontairement modifiées.

uImage

Le format de noyau uImage est celui utilisé par u-boot. Il est indispensable.

compilation du pilote cm15

Je te conseille de compiler le nouveau noyau, de compiler les modules, d'installer les modules puis de booter sur le nouveau noyau.
Ensuite, tu pourras compiler le pilote pour ton cm15.

Vu les erreurs de la compilation du pilote, l'usb n'est pas configuré correctement dans ton noyau.

Cordialement

Je n'ai pas de guruplug donc je n'ai pas d'expérience à partager sur ce matériel.

Tu as fait :

cp -p /proc/config.gz /mnt/nfs/linux-2.6.33.2/.config
cd /mnt/nfs/linux-2.6.33.2
make mrproper
make menuconfig (mais j'ai tout laissé par défaut)
/!\ J'ai bien essayé le make oldconfig mais il fallait renseigner trop de chose manuellement, j'ai laissé tombé..
make

Tu récupères une configuration avant de l'effacer avec make mrproper !
Je te conseille :

# récupérer une configuration de noyau
cp -p /proc/config.gz /mnt/nfs/linux-2.6.33.2/.config.gz
# la désarchiver
cd /mnt/nfs/linux-2.6.33.2
gunzip .config.gz
# l'adapter à ton noyau
make oldconfig
make menuconfig
# compiler le noyau
make uImage
# installer les modules
make modules_install

Comment as-tu fait pour réinstaller le noyau d'origine (l'Uimage + rootfs.ubi...) ?
Quelles commandes as-tu lancé ?

Pour booter sur le nouveau noyau, il faut configurer u_boot. As-tu le module jtag ? Je te conseille de faire une synthèse des liens suivants :
http://www.forum-plugcomputer.net
http://www.forum-plugcomputer.net/viewtopic.php?f=5&t=137&sid=ad0c0059add68624d7d90a5096de1ff6
ftp://ftp.armedslack.org/armedslack/armedslack-13.37/INSTALL_KIRKWOOD.TXT
http://sheeva4ever.over-blog.com/ext/http://www.cyrius.com/debian/kirkwood/sheevaplug/unpack.html

Bon courage

Pour progresser, voici quelques questions :

• Utilises-tu la distribution fournie avec le guruplug ou bien une autre (à préciser) ?

• quel accessoire cm15 utilises-tu ? Est-ce
  http://www.edomotique.com/vproduit--cm15-pro-interface-pc-programmable--X10--cm15--09793--0-0-0-719219.aspx
  ou un produit équivalent ? Sur quel port se branche-t-il ?

• quel pilote utilises-tu ? A quelle adresse as-tu trouvé les sources ?

• Pourquoi affirmes-tu que la compilation échoue ? Dans ton premier post, je ne vois pas d'erreur. Dans ton second compte rendu d'erreur, pourquoi lances-tu make dans le répertoire iplc/driver/linux-2.6/cm15a.d et non dans le répertoire iplc/driver/linux-2.6 ?

• As-tu besoin des patchs :

  • 0002-Driver-for-Marvell-Libertas-8688-SDIO-micro-AP-suppo-2.6.37-v2.patch
  • 0003-Initial-defconfig.patch
  • mvsdio-2.patch

Quelques indications :

• S'il est présent, le fichier /proc/config.gz contient une copie du fichier .config utilisé pour la compilation du noyau en fonctionnement.

• Si tu peux compiler un noyau fonctionnel, tu auras la preuve que tous les outils nécessaires sont installés.

Un pilote est compilé pour le noyau courant et les sources du pilote ont besoin des sources du noyau courant. Je te conseille :

• de télécharger les sources d'un noyau sur le site de globalscale,

• de les compiler sans patch,

• d'installer les modules par make install_modules,

• de booter ton guruplug avec ce noyau,

• de conserver les sources du noyau et de remonter ta clé usb sur le même répertoire : dans le répertoire des modules, les deux liens symboliques build et source doivent pointent respectivement vers les répertoires des objets et des sources du noyau courant,

• et enfin de compiler ton pilote pour le noyau courant.

Bon courage

* solution de dépannage :

tu peux configurer ton système pour qu'il interroge un serveur dns ouvert de google.

Dans le fichier resolv.conf ajoute au tout début la ligne :
nameserver 8.8.8.8


* Comment est configuré ton système ? Vu ton fichier resolv.conf , ton ordinateur semble lancer un serveur dns comme bind ou dnsmasq au boot.

De plus quel est ton FAI ? Curieusement, ses dns n'apparaissent pas dans ce fichier

Bon courage

Je n'ai pas testé mais il semble que le logiciel xpra convienne :

http://linuxfr.org/forums/41/26140.html


J'ai déjà vu un équivalent de screen pour X mais je n'arrive pas à le retrouver :-(

Bon courage

- le modèle de carte blacfin (processeur, ram ...);
- la distribution utilisée sur ton pc;
- la documentation utilisée;
- les étapes suivies avant l'erreur de compilation ?

Je ne connais pas ce type de carte. As-tu besoin d'un compilateur croisé ? Dans l'affirmative, utilises-tu un paquet tout fait ou bien l'as-tu compilé toi même ?

Quelle version du noyau utilises-tu ? A-t-il été configuré correctement ?

As-tu déjà compilé un noyau avec succès pour un système embarqué ?

Bon courage.

J'utilise un noyau 2.6.32.2 compilé par mes soins sur une distribution slackware 12.2 et mes partitions sont formatées en reiserfs. Donc je ne pas réaliser de tests pour toi.

Sur quel disque ta partition racine se trouve-t-elle ? De nombreuses écritures sur cette partition freezent-elles ton système ?

Peux-tu remonter ta partition lvm en changeant les options de montages ?
ATTENTION, d'après linux magazine n°122 de décembre 2009, activer l'option journal_checksum peut provoquer des corruptions sur les noyaux 2.6.31 et 2.6.32.

Deux patches concernant ext4 ont été ajoutés depuis le tout nouveau 2.6.32.3. Je ne sais pas si cela solutionnera tes problèmes, mais tu peux tester ce dernier noyau.

peux-tu préciser ta configuration ?

Quelle distribution utilises-tu ? Utilises-tu le noyau fourni par cette dernière ou bien un noyau que tu as configuré ?
As-tu réinstallé ton système ou bien as-tu fais une mise à jour ?

Ton périphérique LVM dm-0 est-il créé dans une partition de disque dur ou bien au dessus d'un raid ?

Ensuite, peux-tu donnez le partitionnement du périphérique dm-0 et enfin préciser pour chaque partition, le système de fichiers utilisé, l'endroit où il est monté et les options de montage?


L''un des treads noyau flush-254:0 ou jbd/2 semble vouloir écrire des données et faire appel à l'autre thread et cela semble bloquer le système.

Utilises-tu un système de fichiers journalisé ? J'ai vu dernièrement qu'il y a des problèmes avec ext4.

Peux-tu rebooter sur une version du noyau plus ancienne ? Le problème est-il toujours présent ?

Bon courage.