Retour vers le Hub.
Cette page énumère les problèmes les plus fréquents et propose des solutions.
Voir RPi_Bugs pour les problèmes qui sont des bogues.
- 1 Alimentation / Démarrage
- 1.1 État normal des DEL
- 1.2 La DEL rouge d'alimentation ne s'allume pas, aucun affichage
- 1.3 La DEL rouge d'alimentation clignote
- 1.4 La DEL rouge d'alimentation est allumée, la DEL verte ne clignote pas, rien à l'affichage
- 1.5 La DEL verte clignote selon un motif particulier
- 1.6 Écran d'accueil coloré
- 1.7 Kernel Panic au démarrage
- 1.8 Le Raspberry Pi s'éteint (ou redémarre) peu de temps après avoir démarré
- 1.9 Le Pi démarre quelques fois mais pas toujours
- 2 Clavier / Souris / Périphériques d'entrée / Webcams
- 2.1 Le R-Pi ne réagit pas à la pression d'une touche / Le clavier répète l'appui sur des touches de manière aléatoire
- 2.2 Perturbations entre clavier / souris et périphérique USB WiFi
- 2.3 Problème de clavier sans fil
- 2.4 Remapper le clavier avec Debian Squeeze
- 2.5 Lenteur du mappage clavier
- 2.6 Aucun périphérique USB ne fonctionne, malgré une alimentation, une carte SD et un clavier reconnus comme étant utilisables
- 2.7 Webcam
- 3 Mise à jour du micrologiciel
- 4 Cartes SD
- 5 Réseau
- 5.1 La connexion Ethernet est perdue lors du branchement d'un périphérique USB
- 5.2 L'Ethernet se connecte à 10M au lieu de 100M
- 5.3 Connexion ssh impossible sur le Pi
- 5.4 La puce réseau/USB devient chaude au toucher
- 5.5 Le réseau ne fonctionne plus quand j'échange la carte SD entre deux Raspberry Pis
- 5.6 Un plantage se produit en cas de forte charge réseau
- 5.7 La connexion réseau ne fonctionne plus lorsque j'utilise une interface graphique utilisateur
- 6 Mots de passe
- 7 Son
- 8 Affichage
- 8.1 Le démarrage de startx échoue
- 8.2 L'écran n'est pas de la bonne couleur
- 8.3 Lecture vidéo très lente ou impossible
- 8.4 Seule la résolution 800x480 peut être obtenue dans LXDE (Arch linux)
- 8.5 Larges bordures noires encadrant une petite image sur des moniteurs HD
- 8.6 L'affichage déborde de l'écran sur des moniteurs HD
- 8.7 Interférences visibles sur des moniteurs HDMI ou DVI
- 8.8 Pas de sortie du tout en HDMI
- 8.9 Aucune image en vidéo composite
- 8.10 Affichage d'une image uniquement en noir et blanc en vidéo composite
- 8.11 Adaptateurs HDMI -> VGA
- 9 GPIO
- 10 Général
- 11 Dépannage des problèmes d'alimentation
- 12 Versions/révisions matérielles
- 13 Références
Alimentation / Démarrage
Une bonne alimentation qui fournit 5 volts et au moins 1 ampère (5V 1A) est essentielle. Une alimentation 5 volts 2 ampères peut contribuer à rendre certains adaptateurs wifi USB plus stables. Pour plus d'informations, voir #Dépannage_des_problèmes_d'alimentation.
Remarquez que le Pi n'a pas de BIOS, par conséquent rien ne s'affichera à l'écran à moins qu'il ne démarre correctement !
État normal des DEL
Cinq DEL sont présentes près du connecteur USB.
|ACT||verte||état de la carte||clignote selon l'activité de la carte SD|
|PWR||rouge||alimentation||ALLUMÉE de manière stable quand le Pi est alimenté|
|FDX||orange||full duplex||allumée quand la connexion Ethernet est bidirectionnelle|
|LNK||orange||liaison||allumée si l'Ethernet est branché|
|100||orange||100 Mbps||allumée si la connexion est à 100 Mbps, éteinte si 10 Mbps|
Voir les sections suivantes pour savoir comment interpréter les autres états.
La DEL rouge d'alimentation ne s'allume pas, aucun affichage
L'alimentation n'est pas branchée correctement.
La DEL rouge d'alimentation clignote
La DEL rouge d'alimentation ne devrait jamais clignoter car elle est directement câblée sur la piste de l'alimentation 3.3V. Si elle clignote néanmoins, comme un utilisateur nous l'a signalé, cela signifie que l'alimentation 5V connaît des baisses de tension. Utilisez-en une autre.
La DEL rouge d'alimentation est allumée, la DEL verte ne clignote pas, rien à l'affichage
Note: A faintly glowing steady green LED means no boot code has ever been executed, as almost the first thing the boot code does is to turn the faint glow off! When flashing/blinking the green LED should be as bright as the red LED.
- The Raspberry Pi cannot find a valid image on the SD card. Turn the board over to check that the card is inserted correctly; the insertion force is much larger than for some laptops.
- Check that you have correctly written a Raspberry Pi image to the card by using a MAC or PC and browse for the following files:
- start.elf amongst others
- Did you have admin rights when you used the SD-card writer software? Without it the software might go through the motions without actually doing anything!
- Older images do not load boot code for revB boards with the Hynix chip. Use release 2013-02-09 (?) or later. (I observe a single blip on the green activity LED)
- It is also possible that the image you are writing to the card is corrupt, as downloads do occasionally end up corrupted or truncated. You can check with a checksum utility to verify the integrity of the download.
- Check that you have correctly written a Raspberry Pi image to the card by using a MAC or PC and browse for the following files:
- The SD card may itself have an issue. See Known SD Cards.
- Try with no cables connected except the USB power lead, and SD card inserted. You should see flashing of the OK light for ~20 seconds. If that helps, plug in cables one at a time to identify which is interfering with boot.
- Confirm the USB cable is properly seated in the power slot. The red power LED does not necessarily mean it is fully connected.
- The voltage is too low (below 5 V), try a different power supply and/or cable. The R-Pi needs a supply rated for 700 mA or more. Some supplies labeled as such cannot actually provide their rated current while maintaining 5V. See also, #Troubleshooting_power_problems.
- There may be a bug in the distributed version of bootcode.bin which causes problems with some sdcards. Try this version: https://github.com/raspberrypi/firmware/blob/234c19de7cbaaf4997671d61df20a05759066295/boot/bootcode.bin. Please let us know if it "fixes" your non-working SD card (or, more importantly, if it doesn't). This can also manifest itself as intermittent booting, or only booting when cold.
- (unlikely) hardware abuse, for example by connecting a 7 V supply to a 3v3 GPIO output pin or powering up the board after a solder splash shorts some traces.
- Look at the SD card holder on the Raspberry Pi carefully. At first glance it may look fine but the contacts must be springy and they must protrude at least 2mm as measured from the lower edge of the holder to the top of the contact bulge. This happens due to the solder process and the type of holder used. Some of the solder residue falls into the contact cavity restricting the springiness and the height that the contact protrudes. You can fix this yourself but remember you can void your warranty. The contacts are delicate so be carefull. Insert a needle pin under the contact bulge and pull lightly up until the one end of the contact unclips. Clean the cavity where the contact unclipped from of any solder or other residue by blowing into the cavity. Clip the contact back into the cavity by lightly pushing it into the cavity. Do this for all the contacts. Look at these photos. Media:SDcardHolder.JPG, Media:UnclipContact.JPG, Media:UnclippedContact.JPG
- Ensure that when your SD Card is fully inserted that the longer metal spring contacts (one clearly visible on the end of the slot, and one hidden in the side nearest the power connector) are closed. These are used to detect the presence of an SD Card therefore if no contact is made then the Raspberry Pi won't attempt to access the the card.
- Check carefully for any cracks or damage to the SD Card slot, if the sides are damaged then the card may not be making proper contact with the pins (can usually confirm this if your Raspberry Pi boots if you manually hold the SD Card in position). For ways to resolve this, see PiHardware - SD Card slot fixes for more info.
- If for whatever reason the main polyfuse F3 has been overheated previously it may happen that it hasn't completely recovered, in which case, if you turn the PI on, a considerable amount of energy from the power supply is lost in the fuse and doesn't reach the PI. Try if the polyfuse seems hot. For this problem too read #Troubleshooting_power_problems.
- Some problems have been reported if the ambient temperature is low that might be related to micro-fractures, fissures in solder or other issues. Try warming the Raspberry Pi with a hair dryer for just a few seconds (do not use excessive heat or you may cause irreversible damage!) and reconnect the power. Check this video http://www.youtube.com/watch?v=AwF6v-4NFdg
La DEL verte clignote selon un motif particulier
D'après ce message du forum, la lumière verte clignotera d'une certaine manière pour indiquer certains types d'erreurs :
- 3 flashs : loader.bin introuvable
- 4 flashs : loader.bin pas démarré
- 5 flashs : start.elf introuvable
- 6 flashs : start.elf pas démarré
- 7 flashs : kernel.img introuvable
Le micrologiciel depuis le 20 octobre 2012 n'a plus besoin de loader.bin, et les flashs indiquent :
- 3 flashs : start.elf introuvable
- 4 flashs : start.elf pas démarré
- 7 flashs : kernel.img introuvable
Si start.elf ne veut pas démarrer, c'est peut-être parce qu'il est corrompu.
Écran d'accueil coloré
With recent firmware, a coloured splash screen (actually its just four pixels "blown up" by the GPU to full screen) is displayed after GPU firmware (start.elf) is loaded. This should be replaced by linux console a second later. However if the coloured screen remains, it suggests the kernel.img file is failing to boot. Try replacing it with a known good one.
Immediately after displaying the splash screen, the PI starts consuming a little more current, if the PI resets at that moment its an indication that the power supply isn't able to deliver the full current your PI requires, but dips its output voltage below a minimum when loaded with the full current the PI needs.
Kernel Panic au démarrage
Du texte apparaît à l'écran, puis se bloque avec des messages de débogage. Cela peut être provoqué par des périphériques USB comme des claviers. Réessayez sans rien de branché sur l'USB.
Le Raspberry Pi s'éteint (ou redémarre) peu de temps après avoir démarré
Cela est provoqué par une alimentation qui produit une tension insuffisante. Voir #Dépannage_des_problèmes_d'alimentation.
Le Pi démarre quelques fois mais pas toujours
With a known good power supply and known good SD card, the R-Pi boots occasionally, but other times shows only a tiny green flicker from the "OK" LED and it fails to start, even with no USB devices and no Ethernet. This has been reported several times   and remains an open issue. Low voltage or an improper SD card can cause it. Some SD cards will work until they warm up slightly, and then fail. When exposed to 21 C room temperature the warmest part of an uncased working R-Pi should be 41 C. The wiki has a list of working SD cards. Buy from a reliable vendor as it has been claimed that 1/3 of all "Sandisk" labelled memory cards are counterfeit.
- It could be that the SD memory card is not making proper contact with the Raspberry Pi. Look at the SD card holder on the Raspberry Pi carefully. At first glance it may look fine but the contacts must be springy and they must protrude at least 2mm as measured fron the lower edge of the holder to the top of the contact bulge. This happens due to the solder process and the type of holder used. Some of the solder residue falls into the contact cavity restricting the springiness and the height that the contact protrudes. You can fix this yourself but remember you can void your warranty. The contacts are delicate so be carefull. Insert a needle pin under the contact bulge and pull lightly up until the one end of the contact unclips. Clean the cavity where the contact unclipped from of any solder or other residue by blowing into the cavity. Clip the contact back into the cavity by lightly pushing it into the cavity. Do this for all the contacts. Look at these photos. Media:SDcardHolder.JPG, Media:UnclipContact.JPG, Media:UnclippedContact.JPG
Clavier / Souris / Périphériques d'entrée / Webcams
Le R-Pi ne réagit pas à la pression d'une touche / Le clavier répète l'appui sur des touches de manière aléatoire
note:during entering the password most linux distro's wont show that you typed in anything (not even "*" characters) this is normal behaviour, try the keyboard while entering the user name!
This is most often caused by inadequate power. Use a good power supply and a good power cable. Some cheap cables that work with a cell phone, cannot fully power the R-Pi. Some USB devices require a lot of power: most will have a label showing the voltage and mA requirements. They should be 5v 100mA each max, any more than this they must be used with a powered USB hub. Try unplugging every USB device except the keyboard (you should also note that some keyboards have built in hubs and can try to draw 150mA (Pi can only handle 100mA per USB slot without a hub)). Also, use the latest software. Forum user MrEngman reported some keyboard repeats and wireless hangs until upgrading to the debian6-19-04-2012 kernel, which he reports stable with no problems even with a low TP1-TP2 voltage of 4.65 - 4.68 volts.
Some users have reported that their keyboards work fine on Arch linux, but on Debian distro's, their keyboards become erratic (repeats and/or skips key presses). One suggested remedy to this, which has some positive feedback, is to adjust the USB bus speed. To do this, you need to edit the cmdline.txt file, and add "dwc_otg.speed=1" (without quotes) to the end of the file (found in the /boot directory).
Worst case scenario, some (advanced) keyboards, such as the Roccat Arvo, have kernel modules that need activating. If you have access to another keyboard temporarily, you will need to modprobe the relevent driver. Or if this is not possible, you can rebuild the kernel (instructions available on the wiki page) with the modules installed. (to find the drivers for keyboards etc, you need to find "Device Drivers -> hid Devices".)
As a workaround you can use programs kbdrate and xset to tune the keyboard repeat rate:
kbdrate -r 2.0 -d 1000
on the console and
on the desktop (xset is available with: sudo apt-get install x11-xserver-utils)
Perturbations entre clavier / souris et périphérique USB WiFi
Connecting a keyboard and/or mouse while a USB WiFi device is connected, may cause one or both devices to malfunction. On April 30 2012, there was a bugfix relating to USB sharing between high-speed (eg. WiFi) and full/low-speed devices (eg. keyboard/mouse). User spennig reports this patch did not fix the Mouse/WiFi conflict. On 2012-05-12, user spennig was pleased to confirm that wifi was working with a USB keyboard and mouse, as long as the Raspberry Pi had a good PSU and a powered hub. Even so, some experimentation was needed, e.g. USB WiFi connected to the device, and the keyboard and mouse connected to the powered hub. Some experimentation may be necessary to find a working combination; however a good power supply is essential.
My experience regarding this issue point to interferences in the 2.4 GHz frequency band in which both WiFi sticks, as well as USB keyboards transmit data. Changing the channel on the wireless access point fixed the problem completely. In my case (Belkin N150 + Logitech K260/M210) I switched from channel 1 to channel 13, which results in a frequency shift of 50 MHz. Possibly enough to not affect the keyboard/mouse receiver.
Problème de clavier sans fil
Il a été rapporté que certains claviers sans fil, comme le Microsoft Wireless Keyboard 800 par exemple, ne fonctionnent pas même si l'intensité nécessaire à l'adaptateur sans fil ne dépasse pas les 100 mA conformément aux spécifications USB du R-Pi. Il pourrait s'agir d'un problème de pilote logiciel.
Remapper le clavier avec Debian Squeeze
Si les lettres qui apparaissent à l'écran sont différentes de celles que vous tapez, vous devez reconfigurer les paramètres de votre clavier. Sous Debian, depuis la ligne de commande, tapez :
sudo dpkg-reconfigure keyboard-configuration
Suivez les instructions. Redémarrez ensuite votre RasPi.
Tapez en ligne de commande :
sudo nano /etc/default/keyboardPuis recherchez où il est écrit
XKBLAYOUT=”gb”et remplacez gb par le code sur deux lettres de votre pays. 
Lenteur du mappage clavier
Si vous avez remappé votre clavier et que le mappage du clavier prenne vraiment beaucoup de temps au démarrage, tapez une fois pour toutes la commande suivante après vous être logué :
Aucun périphérique USB ne fonctionne, malgré une alimentation, une carte SD et un clavier reconnus comme étant utilisables
There has been more than one report of a R-Pi booting but not getting USB input, using a known-good power supply, SD card, and keyboard. The more common cause for no USB devices working is low power supply voltage from bad PSU, cable, or USB hub, but in this case the problem was no clock signal present at the LAN9512 USB/Ethernet chip "IC3", and the solution was to reflow the solder on the 25 MHz crystal "X1" on the bottom side of the board. Or return the board for a replacement, but before making this conclusion, confirm known good peripherals. A significant number of USB keyboards are not compatible with R-Pi. As of June 1 2012, Eben reported that only about 1 in 1000 shipped R-Pi boards have been found to have a hardware fault of any kind.
sudo apt-get install guvcview
Use the excellent guvcview program to test your webcam and to change the capture settings. You can improve the frame rate to a great extent by changing the settings.
hub ou usb intégré
It is possible that your camera will only work on an internal usb port and not on the hub.
If you are experiencing freezes or timeout errors while using a webcam this script may help:
#!/bin/bash sudo rmmod uvcvideo sudo modprobe uvcvideo nodrop=1 timeout=5000 quirks=0x80
(quirks=0x80 is a bandwidth quirk, the necessary bandwidth will be estimated by the uvcvideo driver instead of using the one proposed by the camera)
Mise à jour du micrologiciel
Vérifier la version de votre micrologiciel
Utiliser la version la plus récente du micrologiciel peut résoudre divers problèmes de compatibilité avec l'affichage ou la carte SD. Vérifiez la version du noyau :
uname -a Linux RPi 3.1.19 #1 PREEMPT Fri Jun 1 14:16:38 CEST 2012 armv6l GNU/Linux
Et celle du micrologiciel du GPU avec :
/opt/vc/bin/vcgencmd version May 31 2012 13:35:03 Copyright (c) 2012 Broadcom version 317494 (release)
Récupérer la dernière version du micrologiciel
The GPU firmware and kernel can be updated with Hexxeh's rpi-update tool.
However this requires the Pi to be successfully booted. With sdcard problems, you may not get that far, so can try a manual udpate. If you have a Linux machine, rpi-update can be run on that in an offline mode, and will update your sdcard from the Linux machine.
Otherwise, on a Windows computer, you will see the "/boot" partition appear as the contents of SD card. You can download the latest GPU firmware version here. Click on view raw, then save it, and put the new start.elf file on the sdcard replacing the existing one. Similarly, the latest kernel is here. After updating these files you should be able to boot. You still need to run rpi-update to update the kernel modules (in /lib/modules) and the GPU libraries (in /opt/vc).
Choisir la bonne répartition entre mémoire ARM et GPU
There is a choice of how the 256M/512M of RAM is divided between the ARM and GPU:
gpu_mem=16 : 16M GPU, 240M/496M ARM split : Maximum ARM memory. Good for ARM desktop use. No accelerated video or 3D possible. gpu_mem=64 : 64M GPU, 192M/448M ARM split : Reasonable ARM memory. Simple video (omxplayer) or 3D (quake) is possible. This is the default. gpu_mem=128 : 128M GPU, 128M/384M ARM split : Use this for heavy 3D work, or 3D plus video. Needed for XBMC.
To switch, edit the gpu_mem= setting in your config.txt and reboot.
Note: other amounts are also possible, but setting gpu_mem=32 is usually the wrong choice. gpu_mem=16 is almost always a better choice.
Also note that before the release of the 51MB PI a different method was used based on splitting the 256MB RAM in a part for the CPU and GPU. As this noting system was causing trouble if the amount of RAM was not always the same. the above new method was adapted.
Make sure your editor doesn't change the first letter of the line into an uppercase letter, as some editors do. The entry is case sensitive.
- If you have problems, check you have latest firmware version (described above)
- Some SD cards do not work on the R-Pi, so check the list of known SD cards.
- If you are having problems setting up your SD card you might want to start by erasing it completely - especially if it has been used elsewhere and still contains data / partitions.
- Windows and Mac users can download a formatting tool from the SD Association: https://www.sdcard.org/downloads/formatter_3/
- Reformatting cards is also easy to do in a digital camera.
- After writing the image to the SD card, verify that you can see the boot partition when you insert the SD card into your computer. The partition should contain a number of files, including start.elf and kernel.img. If you do not see these files on the SD card, you have made an error writing the image file.
- If you are manually preparing your SD card on Linux or Mac OS using the dd command, this operation will completely erase any existing data and partitions. Make sure you write to the whole card (e.g. /dev/sdd) and not to an existing partition (e.g. /dev/sdd1).
- If you have an sdcard that doesn't work with latest firmware, head over here.
- If you put the SD card into your PC in an attempt to write the R-Pi operating system onto it, and the PC tells you the card is write-protected, even with the write-protect tab in the correct, forward position, then you may have a faulty SD-card rewriter. There's a common fault with many SD-card rewriters - The write-protect tab is detected by a very thin, narrow metal strip, that is part of a switch. When the card is inserted, the write-protect tab is supposed to push the strip and make/break the contact, as needed. Unfortunately, these strips have a habit of getting stuck, because they are mounted in a thin plastic channel, and only need to be deformed slightly sideways to get jammed.
Luckily, if you have this problem, most built-in card readers are easy to pull apart and repair; some users have even reported succesfully unjamming the switch with a blast of compressed air from a can into the SD-card slot without having to dismantle anything. You may also be able to temporarily get round the problem by putting the write-protect tab in a half-way position - this pushes on a different part of the strip and may break the contact - it's worth trying a few, slightly different positions. You could also use a USB-SD card adaptor, which are cheap to buy.
Conseils sur les cartes SD(DC|DX] de classes 6 et 10
La connexion Ethernet est perdue lors du branchement d'un périphérique USB
This is often caused by inadequate power. Use a good power supply and a good power cable. Some cheap cables that work with a cell phone, cannot fully power the R-Pi. Some USB devices require a lot of power (>100 mA), so they must be used with a powered USB hub. Some cheap USB hubs suck power from the Raspberry Pi even if a USB power supply is connected. (More often than not, however, the reverse is true with cheap hubs—the Pi draws just enough power backwards from the powered hub to unsuccessfully attempt booting.)
There is an ongoing issue with the Ethernet connection being lost when low-speed devices, such as mice or keyboards are connected via a powered USB hub. The simplest way to solve this is to connect your mouse and keyboard directly into the 2 USB ports on the R-Pi (assuming they draw less than 100 mA apiece).
L'Ethernet se connecte à 10M au lieu de 100M
The LED in the corner of the board labelled "10M" is mislabeled on the rev 1.0 PC board. It is correctly labeled "100" on the rev 2.0 PC board. When that LED is on, RasPi is connected at 100 Mbps. You can confirm the true transfer rate using a network benchmark such as iperf. You can also read the current network speed with:
Connexion ssh impossible sur le Pi
In the Debian image, ssh is disabled by default. Boot commands are taken from /boot/boot.rc if that file present. There is an example file named boot_enable_ssh.rc that enables ssh. So:
sudo mv /boot/boot_enable_ssh.rc /boot/boot.rc
and reboot should enable ssh. (password as below)
La puce réseau/USB devient chaude au toucher
This is normal. In open air at 24 C, the LAN9512 Ethernet/USB chip reaches about 52 C after some time. This is too hot to touch for more than a few seconds, but it is not unusually hot for the chip.
The LAN9512 data sheet in Table 4.1 on p.40 says it comes in two versions, rated for operation at an ambient temperature in still air (Ta) of 70 C (commercial) or 85 C (industrial). It uses 763 mW at 3.3V with maximum traffic on 100baseT and both USB ports (Table 4.3.4, p. 42).
There is a study of RasPi heat profiles by "Remy" at ¿Se calienta el ordenador Raspberry Pi? Estudio de sus temperaturas en funcionamiento (Is the Raspberry Pi computer getting hot? A study of its operational temperature.) The Spanish article has numerous color temperature images of RasPi in various operational modes, with the highest LAN9512 case temperature measured as 64.5 C.
Le réseau ne fonctionne plus quand j'échange la carte SD entre deux Raspberry Pis
In some distributions, /etc/udev/rules.d/70-persistent-net.rules remembers which MAC address is associated with eth0, so each new device will be assigned as a different interface (eth1, eth2, etc.) due to the different MAC addresses. Editing /etc/udev/rules.d/70-persistent-net.rules to remove the invalid rules and rebooting may help fix the problem.
Un plantage se produit en cas de forte charge réseau
The USB driver allocates memory from the kernel, and when traffic is very high (e.g. when using torrents/newsgroup downloads) this memory can be exhausted causing crashes/hangs. (Crashes with high network load can also be related to your power supply, try a powered usb hub.) You should have a line like:
vm.min_free_kbytes = 8192
in /etc/sysctl.conf. Try increasing that number to 16384. If that doesn't work, try adding to /boot/cmdline.txt
which will reduce network throughput, but has improved stability issues for some.
If the above fixes do not work, you can prevent the crashes by limiting the bandwidth (This is also working sometimes if the crashes are related to power supply.):
wondershaper wlan0 1500 1500
This bandwidth (~150k/s) is enough to stream video with flvstreamer and omxplayer.
(wondershaper is available in raspian: sudo apt-get install wondershaper. You could also test limiting the bandwidth in advance with wget --limit-rate=150)
La connexion réseau ne fonctionne plus lorsque j'utilise une interface graphique utilisateur
The network connection may fail when the command startx is used to enter a Graphical User Interface. This is caused by a bug in the USB driver related to certain types of USB mouse.
As of 1 September 2012, this fault is fixed in the latest firmware. To load the latest firmware, see http://elinux.org/R-Pi_Troubleshooting#Updating_firmware
Mots de passe
Je ne connais pas le mot de passe pour me connecter
Veuillez consulter la page http://www.raspberrypi.org/downloads pour connaitre les noms d'utilisateur et mot de passe corrects de chaque image.
Voici les combinaisons utilisateur/mot de passe les plus utilisés :
- Raspian "wheezy" pi/raspberry
- Debian après février 2012 : pi/raspberry
- Debian 17 février 2012 : pi/suse
- Arch : root/root
- Bodhi : pi/bodhilinux
Certains programmes refusent mon mot de passe
Lors de l'utilisation de Debian, certains programmes peuvent demander votre mot de passe mais refusent de le considérer comme valide.
Il s'agit d'une erreur dans les anciennes images Debian antérieures à septembre 2012. Si vous utilisez une image comportant cette erreur, mettez à jour votre image avec une plus récente ou entrez les commandes suivantes en ligne de commande.
gconftool-2 --type bool --set /apps/gksu/sudo-mode true
Veuillez faire attention en saisissant cette commande, les espaces sont importants. Elle devrait être acceptée sans message ni erreur.
Je ne connais pas le mot de passe root
Aucun mot de passe root n'est défini par défaut sous Debian. Tout devrait être fait par l'intermédiaire de sudo. Vous pouvez néanmoins en définir un avec "sudo passwd root" - assurez-vous seulement de bien savoir ce que vous faites avec un compte administrateur.
Le son ne fonctionne pas avec des moniteurs HDMI
This is caused by some computer monitors which select DVI mode even if an HDMI cable is connected. This fix may be necessary even if other HDMI devices work perfectly on the same monitor (or TV)!
Edit the configuration file - see the instructions at R-Pi_ConfigurationFile.
Add the following line to the configuration file:
This will force it to select HDMI mode.
More reasons why sound does not work with an HDMI monitor
With an HDMI connection it might be possible to hear:
Firstly, it seems that some HD TVs mute audible sound output when there is no digital input, and slowly fade the sound up and down at the start and end of digital input. This means that short duration sounds will not be heard. A work around is to play longer duration wav files.
Secondly, it seems that some HD TVs mute audible sound output when there is only one channel of digital input. So, as the file Front_Center.wav is mono, it might not be heard. ALSA aplay uses the file information header to configure its digital output. And the aplay -c 2 option does not over-ride the settings aplay picks up from the file information header. So, if your HD TV doesn't accept just one channel of digital input, you cannot use aplay to hear a mono wav file. However, with the command speaker-test, the -c2 option does work, and sets 2 channels in the digital stream. So speaker-test can be used to hear the file Front_Center.wav in either the left or right speaker using the -s option 1 or 2. For example
Speaker-test -c 2 -s 1 -t wav -W /usr/share/sounds/alsa -w Front_Center.wav
should be heard on the left speaker. But note that the command speaker-test seems only to like mono wav files, and seems not to play stereo wav files.
The command aplay plays 2 channel stereo wav files in stereo sound without problem (provided they last longer than the time it takes the TV to unmute and remute). A helpful example I found is the stereo file LRMonoPhase4.wav at the Kozco web site 
Le son ne fonctionne pas dans certaines applications, voire pas du tout
Enter the command 'alsamixer' and use the control to check that the volume is up (arrow keys) and that the output is not muted (M key).
In Debian Squeeze, sound is disabled by default because the ALSA sound driver is still "alpha" (not fully tested) on the R-Pi. To install support for sound, type the following from a command line (from the command prompt before "startx" or in a terminal window)
sudo apt-get update sudo apt-get upgrade sudo apt-get install alsa-utils sudo modprobe snd_bcm2835
On Debian Wheezy, snd_bm2835 is enabled by default, so the 'modprobe' step is not necessary. Next try:
By default output will be automatic (hdmi if hdmi supports audio, otherwise analogue). You can force it with:
amixer cset numid=3 <n>
where n is 0=auto, 1=headphones, 2=hdmi.
If you have pulseaudio installed you need to also specify the card number:
amixer -c 0 cset numid=3 <n>
With recent firmware, you can build hello_audio with:
cd /opt/vc/src/hello_pi/ ./rebuild.sh cd hello_audio
With older firmware
cd /opt/vc/src/hello_pi/hello_audio make
to test analogue output:
to test HDMI.
Also note that you may have to add your user to the 'audio' group to get permission to access the sound card.
Following this setup, you should be able to play wav files with the command
aplay "my file.wav"
Other command features can be found with
You will find numerous test files under /usr/share/scratch/Media/Sounds/ .
Suppression de l'installation de pulseaudio
Between December 2012 and February 2013 the standard raspbian wheezy distribution, and apt-get upgrade, included pulseaudio. Forum posts suggest that pulseaudio can break alsa. Whilst some members identify various workarounds, others find only removal of pulseaudio restores sound output.
sudo apt-get --purge remove pulseaudio
Lecture de fichiers MP3
L'app alsa présente dans la distribution standard lit les fichiers wav. Si vous souhaitez lire des fichiers mp3, tapez ceci pour installer un lecteur mp3 (après avoir installé alsa-utils) :
sudo apt-get update sudo apt-get upgrade sudo apt-get install mpg321
Vous pouvez lire les fichiers mp3 avec la commande
mpg321 "my file.mp3"
Les autres options de la commande sont obtenues avec
Le support mp3 de cette app est achevé mais non robuste.
Le démarrage de startx échoue
If you just get errors instead of a desktop when typing
you may be out of storage space on the SD card. By default there are only a few hundred MB free in the 2 GB main partition, which can quickly fill up if you download files. Make sure there is some space free (gparted can expand a partition, if the SD card is > 2GB). Also, installing some software may incorrectly create or modify a .Xauthority file in your home directory, causing startx to fail, according to this thread. Temporarily renaming, moving, or deleting that file may fix the problem.
L'écran n'est pas de la bonne couleur
Regardez et vérifiez si le câble DVI est bien vissé. Si ça ne fonctionne toujours pas, reportez-vous à cette section.
Lecture vidéo très lente ou impossible
Le seul lecteur vidéo avec accélération matérielle est dans la distribution XBMC et sa variante en ligne de commande omxplayer. H264 est l'unique codec avec accélération matérielle, pour la lecture. Il n'y a pas d'encodage matériel. Aucun autre codec n'a été acheté car le coût des licences aurait augmenté le prix du R-Pi.
Seule la résolution 800x480 peut être obtenue dans LXDE (Arch linux)
Known issue with distro package as of 17th April 2012 - there's some missing boot config information. Creating a suitable cmdline.txt fixes it - type the following at the Raspberry Pi command line:
sudo echo "dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 root=/dev/mmcblk0p2 rootfstype=ext3 rootwait" >/boot/cmdline.txt
Larges bordures noires encadrant une petite image sur des moniteurs HD
Out of the box, R-Pi graphics don't necessarily fill the whole screen. This is due to something called "Underscan", and it can be fixed easily.
Note: the best solution is to disable overscan on the TV/monitor. Check the display menu options (it may be called "just scan", "screen fit", "HD size", "full pixel", "unscaled", "dot by dot", "native" or "1:1"), then use the disable_overscan=1 option.
Edit the configuration file, see the instructions at R-Pi_ConfigurationFile.
Add the following lines to the configuration file...
If your display has no overscan:
or if your display has some overscan:
overscan_left=-20 overscan_right=-20 overscan_top=-20 overscan_bottom=-20
Making the R-Pi graphics fill the screen is a matter of experimenting with the numbers you put in the config.txt file. Change the numbers – try jumps of 5 or 10 at a time. Bigger negative numbers reduce the black borders (so -40 means less black border than -20). The numbers do not all have to be the same; you can use this feature to centre the display on the screen.
This only affects the framebuffer (e.g. console or X). It doesn't affect hardware layers (like video/3D). You can make it apply to hardware layers with:
L'affichage déborde de l'écran sur des moniteurs HD
Out of the box, R-Pi graphics may be larger than the 1080p (ie Full HD) screen. This is due to something called "Overscan", and it can be fixed easily by creating a simple text file on the R-Pi SD card by using Notepad on your PC.
Follow the instructions in the section "Big black borders around small image on HD monitors", but use positive numbers for the overscan settings, for example
overscan_left=20 overscan_right=20 overscan_top=20 overscan_bottom=20
Interférences visibles sur des moniteurs HDMI ou DVI
This may be caused by loss of signal on long video cables. The signal level may be increased by changing a configuration parameter.
Edit the configuration file, see the instructions at R-Pi_ConfigurationFile.
Add the following line to the configuration file
You may experiment with different values of config_hdmi_boost. Value 1 is used for very short cables, value 7 is used for very long cables. At your own risk, you can go up to 11, but risk frying a sensitive monitor.
Note that various adapters, such as HDMI-to-DVI, can also cause power loss and therefore require high values of config_hdmi_boost even with short cables.
This option can also help when there is no display output at all, the display periodically blanks, or colours are wrong/inverted.
This symptom can also be caused by RasPi +5V (measured from TP1 to TP2) falling too low. See Troubleshooting Power Problems.
Pas de sortie du tout en HDMI
First make sure the display is powered on and switched to the right input before booting Pi.
If you have the Rasbian Wheezy image (recommended) then try
Which will force the PI to boot in "safe mode".
For a quicker way to force wheezy into booting in safe mode, which doesn't need editing config.sys, you can also try to boot while holding the GPIO header P1-pin-5 (GPIO 1, SCL) low. This pin is normally held high with a pullup, but if you place a jumper between pin 5, (GPIO 1) and pin 6, (GND) of the GPIO header it will force the PI to boot in safe mode, which will force a 640x480 VGA screen mode, which any HDMI device should be able to display. Be very careful not to connect any other pins, especially not pins 1 and 2 (3V3 and 5V) as doing so, with power on, will damage your PI!
Otherwise, try adding the following line to the configuration file (similar to interference case above)
Your monitor/cable may not be asserting the hotplug signal. You can override this with:
A similar problem has occured following the installation of Rasbian Wheezy image "2013-02-09-wheezy-raspbian" - the hotplug signal appeared to be no longer detected when a HDMI 3 Port Switcher was in use for the Pi running from that image. An older, but updated and upgraded image still worked, as did a similar image on the other Pi connected to the switch, but, unless the above override was implemented, the Pi with the new image would only provide a HDMI display when directly connected to the monitor. The same problem has re-occurred when using that wheezy image with a new (in March 2013) "Model A" Pi.
Also try the following video options:
which resolved an issue with DVI monitor reporting "input signal out of range"
As a last resort, try deleting (rename to keep backup) config.txt from the SD card.
Also check that the RasPi +5V voltage (measured from TP1 to TP2) is in the correct range. One user found that his DVI-D monitor blanked out when +5V was too low. See Troubleshooting Power Problems.
Here's a rare cause: A standard HDMI cable has five individual ground wires plus a shield. Some cheap HDMI cables do not implement the individual grounds and just have a common foil shield that's connected to the HDMI plug shells at both ends. This works OK in most HDMI applications since most HDMI sources (like RasPi) and most monitors connect the shells to circuit ground. However, some HDMI or DVI monitors may requires individual ground lines. You can tell if an HDMI cable implements the individual grounds by checking for continuity using an Ohmmeter or multimeter. You can find the HDMI pinout for full-size connectors at Wikipedia.
Aucune image en vidéo composite
The output display will default to HDMI if a HDMI display is connected, and composite if not. Make sure there isn't a HDMI cable connected when you want to use composite output.
Also, check that your TV is set to the correct input, normally marked "AV". If your TV has multiple AV inputs, try all of the inputs, normally by pressing a button marked "AV" or "Input" or "Source" or "->O" on the remote control.
Affichage d'une image uniquement en noir et blanc en vidéo composite
The composite display defaults to NTSC (American) output. Most TVs will show an image with that, but older PAL (European) televisions may display only back and white or no image. To fix this:
Edit the configuration file, see the instructions at R-Pi_ConfigurationFile.
Add the following line to the configuration file
(You can try other values: 0 is NTSC, 1 is Japanese NTSC, 2 is PAL, 3 is Brazilian PAL)
Adaptateurs HDMI -> VGA
Some good information can be found here:
- (RPi forum) Serious HDMI Problems. What's that smell? Burning Raspberry!
Remember that the GPIO pins are 3.3V logic level only, and are NOT 5V tolerant.
If you momentarily shorted the two end GPIO pins together (+3.3V and +5V), or a supply pin to ground, and the Pi appears to be dead, don't panic. The input polyfuse may have tripped. It is self-resetting after it cools down and the polymer re-crystallizes, which can take several hours. Set the Pi aside and try again later.
The GPIO pins connect directly into the core of the ARM processer, and are static-sensitive, so you should avoid touching the pins wherever possible. If you are carrying a static charge, for example by taking off an acrylic pullover, or walking across a nylon carpet, touching the GPIO pins could destroy your R-Pi, so always earth yourself before touching the pins or anything connected to them.
L'heure n'est pas correcte
Si l'heure est décalée de plusieurs heures, tapez en ligne de commande :
sudo dpkg-reconfigure tzdata
Le R-Pi n'a pas d'horloge temps-réel, donc à moins d'accéder à un serveur de temps via le réseau lors du démarrage, ou de saisir l'heure manuellement, les date/heure reprendront à partir de l'heure d'ouverture de la dernière session.
Un morceau s'est cassé
The silver cylinder near the microUSB power input is a 220 uF capacitor ("C6" on schematic). It sticks up and due to the small surface-mount pads, it is easy to break off; several people have done so. This is a power supply filter capacitor which reduces any noise and spikes on the input +5V power. If you like, you can solder it back on, or just leave it off. If you do solder it back on, take care to observe the correct polarity with the black stripe towards the board edge. This part, C6 is a "just in case" component which is good design practice to include, but as it turns out most power supplies still work OK without this part installed. This part is also discussed here.
Impossible d'installer de nouveaux logiciels
Quand vous essayez d'installer un paquet (avec la commande sudo apt-get install xxxx) vous pouvez rencontrer l'erreur
Package yyyy is not available
Cette erreur indique que votre liste de logiciels n'est pas à jour. Avant de tenter une installation, vous devez toujours vous assurer d'utiliser la liste la plus récente grâce aux commandes
sudo apt-get update sudo apt-get upgrade
Dépannage des problèmes d'alimentation
If you think you have a problem with your power supply, it is a good idea to check the actual voltage on the Raspberry Pi circuit board. Two test points labelled TP1 and TP2 are provided on the circuit board to facilitate voltage measurements.
Use a multimeter which is set to the range 20 volts DC (or 20v =). You should see a voltage between 4.75 and 5.25 volts. Anything outside this range indicates that you have a problem with your power supply or your power cable.
If you have not used a multimeter before, see these [basic instructions]
Note: Even if the multimeter shows the correct voltage, you may have some power supply problems. A multimeter only displays the average voltage. If there are very short-lived dips or spikes in the voltage, these will not be shown by the multimeter. It is best to measure voltage when Pi is busy.
If your voltage is low, it could be:
- The power supply produces too low a voltage
- The power supply cannot supply enough current, which results in a voltage drop. Make sure Power supply is labelled as at least 700mA. (Some cheap power supplies don't deliver what is labelled).
- The Micro USB power cable is low quality. Some Micro USB cables have very thin conductors, resulting in enough voltage drop for RasPi to fail even if the power supply itself is fine. For details, see On_the_RPi_usb_power_cable.
- Attached USB devices want too much power. The Pi is only designed for up to 100mA USB devices. A USB device wanting more that that will cause a voltage drop.
- The F3 Polyfuse could be blown or bad, see below for how to test.
Note: keyboards with LCD displays, built in USB hubs, backlights, etc are likely to be problematic. Try to use a basic one. Wifi dongles are also unlikely to work when directly connected. Connect high powered USB devices to a powered USB hub.
Try booting without HDMI, ethernet or USB deviced plugged in, and see if the voltage improves. See also: Power Supply Problems
How to test the F3 polyfuse
- Remove all the things plugged into your Raspberry Pi, including SD card.
- Locate the TP2 test point on the top of the board.
- Turn your board over and find the TP2 test point on the bottom of the board. One lead of your multi-meter will always be on the TP2 point on the bottom of the board for all tests.
- Plug your power supply into the micro usb port and power your board.
- Place one lead of your multi-meter on the TP2 point on the bottom of the board and one lead on the side of the F3 fuse closest to the edge of the board. Note the voltage. This is the voltage coming into your RPi from your power supply.
- Keeping one lead on TP2, move the other lead to the side of F3 closest to the SD card slot. This is the voltage coming out of the F3 fuse.
If the voltage is different by more than about 0.3v you probably have an issue with the F3 fuse.
When polyfuses "blow" their resistance increases dramatically, there by limiting the voltage that can pass through them. If your power problem suddenly appeared after your board was known to be working fine, it is probable the fuse is just "blown" and will return to normal. Polyfuses recover from the tripped state to near their normal value in a few minutes, but do take some hours to fully recover so leave it unpowered and check it again in a little while. If your power problem has been since the first time you plugged in your board, the fuse was probably bad when it arrived and should be returned to place you purchased it.
Also, on a related issue, do note that if you do not power the PI in the "official manner", that is through it's micro-USB port, but use any alternative way (such as through the GPIO header, the test points TP1 and TP2), but also by back-powering it, you are actually bypassing the PI's input polyfuse protection device! This can have extreme consequences if ever you manage to put more than 6V on the PI, even for a very short period. As this causes the overvoltage device D17 on the the PI to trigger and short the 5V supply! Without the polyfuse limiting the current through D17, it will burn out, probably melting the PI's enclosure with it, (if you have any) and possibly causing a fire-hazard. It will probably also create a permanent short of the 5V supply! So be warned, and if you use back power make sure your hub or its PSU has a fuse to prevent this from happening. If not, add your own fuse.
If you prefer to make your own PSU - see: Power Supply construction - HowTo
Several different boards have been found probably from different assembly lines, and the following tables try to help you identify your board for better troubleshooting.Look for the date of manufacturing printed with the year and week. In this example year (2012) and week (18th):
For what we can see for model B boards there are mainly two versions that differ on the type RAM used, Samsung (S) and Hynix (H).
For Board ver. we used: <model><RAM Maker><production date> (ex.: BS1218 is "Model B, Samsung RAM, 18th week of 2012")
See a complete list and user feedback here: RaspberryPi Boards