0 votes

Remplacement de la batterie de la tablette et échec de alloc_device_open ?

J'ai dû effectuer un remplacement de batterie sur une tablette Android 4.x Denver TAC-97032.

La batterie a été obtenue du fabricant en tant que pièce de rechange, mais elle n'est pas de la même taille que la batterie d'origine.

Pourtant, j'ai ouvert la table, dessoudé l'ancienne pile et soudé la nouvelle ; le comportement est ensuite le même :

  • Si je branche simplement le chargeur, j'obtiens l'animation Android "la batterie se remplit" pendant un moment, l'animation montre la charge, puis elle disparaît, comme d'habitude. Bon - signifie que la batterie est détectée et qu'elle est montée correctement.
  • Si je démarre avec Power + Vol Up, j'arrive à la récupération, qui ici montre juste l'image "Android mort" ; il n'y a pas de menus supplémentaires pour le sideload ADB ou similaire, donc en fait il reste juste là ; adb peut également voir un dispositif de "récupération", et adb reboot est également reconnu et travaille
  • Si je démarre avec seulement Power : d'abord le splash DENVER s'affiche, puis un écran splash Android s'affiche, puis l'écran devient noir (mais il y a encore du rétro-éclairage il semble) ; l'appareil semble mort, mais si je maintiens Power pour forcer l'arrêt, à la fin un clic du haut-parleur est entendu et un flash de l'écran est vu - ce qui signifie que l'appareil a également fonctionné sous l'écran noir.

Sur l'écran noir, j'ai essayé adb - et heureusement, ça a marché :

$ ./adb.exe logcat
--------- beginning of /dev/log/main
I//system/bin/e2fsck(   67): e2fsck 1.41.11 (14-Mar-2010)
I//system/bin/e2fsck(   67): /dev/block/nande: clean, 5183/76800 files, 205676/307200 blocks
I/logwrapper(   67): /system/bin/e2fsck terminated by exit(0)
I//system/bin/e2fsck(   72): e2fsck 1.41.11 (14-Mar-2010)
I//system/bin/e2fsck(   72): /dev/block/nandh: clean, 15/20496 files, 2623/81920 blocks
I/logwrapper(   72): /system/bin/e2fsck terminated by exit(0)
--------- beginning of /dev/log/system
I/USB3G   (   85): usb 3g monitor v0.1 start
I/USB3G   (   85): event { 'add', '/devices/platform/sw_hcd_host0/usb1', 'usb', '', 189, 0 }
I/USB3G   (   85): event { 'add', '/devices/platform/sw-ehci.1/usb2', 'usb', '', 189, 128 }
I/USB3G   (   85): event { 'add', '/devices/platform/sw-ohci.1/usb3', 'usb', '', 189, 256 }
I/Netd    (   80): Netd 1.0 starting
I/Vold    (   79): Vold 2.1 (the revenge) firing up
D/Vold    (   79): Volume sdcard state changing -1 (Initializing) -> 0 (No-Media)
D/Vold    (   79): Volume extsd state changing -1 (Initializing) -> 0 (No-Media)
D/Vold    (   79): Volume usbhost1 state changing -1 (Initializing) -> 0 (No-Media)
D/Vold    (   79): Volume sdcard state changing 0 (No-Media) -> 1 (Idle-Unmounted)
I/SurfaceFlinger(   81): SurfaceFlinger is starting
I/SurfaceFlinger(   81): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
E/[Gralloc-ERROR](   81): int alloc_device_open(const hw_module_t*, const char*, hw_device_t**):436 UMP open failed with 1
E/FramebufferNativeWindow(   81): couldn't open framebuffer HAL (Operation not permitted)
E/[Gralloc-ERROR](   81): int alloc_device_open(const hw_module_t*, const char*, hw_device_t**):436 UMP open failed with 1
E/FramebufferNativeWindow(   81): couldn't open gralloc HAL (Operation not permitted)
E/SurfaceFlinger(   81): Display subsystem failed to initialize. check logs. exiting...
I/        (   82): ServiceManager: 0xf958
I/AudioFlinger(   82): Loaded primary audio interface from sunxi audio HW HAL (audio)
I/AudioFlinger(   82): Using 'sunxi audio HW HAL' (audio.primary) as the primary audio interface
I/CameraService(   82): CameraService started (pid=82)
I/AudioFlinger(   82): AudioFlinger's thread 0x1c7b0 ready to run
W/AudioFlinger(   82): Thread AudioOut_1 cannot connect to the power manager service
I/AudioPolicyService(   82): Loaded audio policy from LEGACY Audio Policy HAL (audio_policy)
I/SurfaceFlinger(  129): SurfaceFlinger is starting
I/SurfaceFlinger(  129): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
I/[Gralloc](  129): using (fd=10)
I/[Gralloc](  129): id           =
I/[Gralloc](  129): xres         = 1024 px
I/[Gralloc](  129): yres         = 768 px
I/[Gralloc](  129): xres_virtual = 1024 px
I/[Gralloc](  129): yres_virtual = 1536 px
I/[Gralloc](  129): bpp          = 32
I/[Gralloc](  129): r            = 16:8
I/[Gralloc](  129): g            =  8:8
I/[Gralloc](  129): b            =  0:8
I/[Gralloc](  129): width        = 163 mm (159.568100 dpi)
I/[Gralloc](  129): height       = 122 mm (159.895081 dpi)
I/[Gralloc](  129): refresh rate = 60.12 Hz
D/libEGL  (  129): loaded /system/lib/egl/libEGL_mali.so
D/libEGL  (  129): loaded /system/lib/egl/libGLESv1_CM_mali.so
D/libEGL  (  129): loaded /system/lib/egl/libGLESv2_mali.so
E/SurfaceFlinger(  129): couldn't find an EGLConfig matching the screen format
W/SurfaceFlinger(  129): ro.sf.lcd_density not defined, using 160 dpi by default.
I/SurfaceFlinger(  129): EGL informations:
I/SurfaceFlinger(  129): # of configs : 21
I/SurfaceFlinger(  129): vendor    : Android
I/SurfaceFlinger(  129): version   : 1.4 Android META-EGL
I/SurfaceFlinger(  129): extensions: EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_gl_texture_2D_image EGL_KHR_gl_texture_cubemap_image EGL_KHR_gl_renderbuffer_image EGL_KHR_fence_sync EGL_ANDROID_image_native_buffer
I/SurfaceFlinger(  129): Client API: OpenGL ES
I/SurfaceFlinger(  129): EGLSurface: 5-6-5-0, config=0x0
I/SurfaceFlinger(  129): OpenGL informations:
I/SurfaceFlinger(  129): vendor    : ARM
I/SurfaceFlinger(  129): renderer  : Mali-400 MP
I/SurfaceFlinger(  129): version   : OpenGL ES-CM 1.1
I/SurfaceFlinger(  129): extensions: GL_OES_byte_coordinates GL_OES_fixed_point GL_OES_single_precision GL_OES_matrix_get GL_OES_read_format GL_OES_compressed_paletted_texture GL_OES_point_size_array GL_OES_point_sprite GL_OES_texture_npot GL_OES_query_matrix GL_OES_matrix_palette GL_OES_extended_matrix_palette GL_OES_compressed_ETC1_RGB8_texture GL_OES_EGL_image GL_OES_draw_texture GL_OES_depth_texture GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_OES_framebuffer_object GL_OES_stencil8 GL_OES_depth24 GL_ARM_rgba8 GL_OES_EGL_image_external GL_OES_EGL_sync GL_OES_rgb8_rgba8 GL_EXT_multisampled_render_to_texture GL_OES_texture_cube_map GL_EXT_discard_framebuffer GL_EXT_robustness
I/SurfaceFlinger(  129): GL_MAX_TEXTURE_SIZE = 4096
I/SurfaceFlinger(  129): GL_MAX_VIEWPORT_DIMS = 4096 x 4096
I/SurfaceFlinger(  129): flags = 00000000
D/display (  129): ####disp_init, mode:0,out_type:1,tv_mode:0,app_width:1024,app_height:768
D/DisplayDispatcher(  129): display dispatcher enabled

... et ici logcat s'arrête - il n'y a pas d'autres messages.

Donc, l'erreur principale semble être "Display subsystem failed to initialize", et cela explique l'écran noir ; cependant je ne peux pas vraiment dire :

  • Est-ce une cause matérielle : peut-être que pendant le remplacement de la batterie, j'ai accidentellement déconnecté une broche de l'écran, de sorte que même si j'obtiens des écrans d'accueil affichés au démarrage, il y a une erreur plus tard lorsque le fonctionnement normal est initialisé ?
  • Il y a très peu de ressources en ligne mentionnant cette erreur, et je pense que je suis arrivé à un journal de chat IRC, où une réinitialisation d'usine était recommandée pour une erreur comme celle-ci. J'imagine qu'il y a peut-être une sorte d'ID sur la batterie, et comme il a été modifié par rapport à l'original, le système d'exploitation voit cela comme une erreur et refuse de continuer. Évidemment, je ne veux PAS faire une réinitialisation d'usine - parce qu'alors, je perds toutes les données de l'appareil (je ferais une réinitialisation d'usine). adb mais cela déclenche généralement une invite sur le périphérique, et comme l'écran ne fonctionne pas, je n'aurais pas pu l'autoriser même si le système avait démarré dans un état où il aurait affiché l'invite).

Donc, mes questions sont :

  • Est-ce que quelqu'un sait ce qui est le plus probable comme cause de ump_open erreur : mauvaise connexion des fils du matériel, ou peut-être une identification différente de la batterie ?
  • Est-il réaliste d'espérer qu'une réinitialisation d'usine puisse résoudre ce problème ?
  • Si j'ai besoin de faire une réinitialisation d'usine, y a-t-il un moyen de sauvegarder ce dispositif uniquement à partir d'adb (mais sans utiliser d'éléments de l'interface graphique sur le dispositif cible) ?
  • Logcat dit : "Le sous-système d'affichage n'a pas réussi à s'initialiser. Vérifiez les journaux". - Y a-t-il d'autres journaux que Logcat que je pourrais vérifier et si oui, lesquels ?
  • Y a-t-il autre chose que je puisse essayer pour que cette tablette démarre complètement ?

1 votes

La tablette fonctionnait-elle parfaitement avant le remplacement de la batterie ? En ce qui concerne la check logs Je suppose qu'il s'agit d'une sortie générique d'un pilote développé pour Linux. Il est possible qu'il ne soit pas du tout applicable sur Android.

0 votes

Merci @Robert - la tablette fonctionnait en effet parfaitement avant, mais elle était éteinte depuis plusieurs mois avant la tentative de remplacement de la batterie d'aujourd'hui. Merci pour le check logs commentaire, c'est logique.

1voto

sdaau Points 171

Eh bien, c'était un doozy pour moi...

Tout d'abord, j'ai découvert que l'état précédent de cette tablette ne fonctionnait pas tout à fait - la vieille batterie a fini par se décharger complètement ; après cela, le fait de brancher le chargeur n'a fait qu'afficher l'écran d'accueil "charge de la batterie", mais l'appareil a refusé de démarrer ; et à ce moment-là, elle a été rangée - jusqu'à maintenant.

Quoi qu'il en soit, tout d'abord, comme documenté ici Pourquoi Android répertorie-t-il certains fichiers qui ne sont pas accessibles (erreur E/S) ? j'ai découvert que certains fichiers système étaient à l'origine de l'erreur E/S. Cela m'a fait penser qu'il y a une possible corruption du /system partition flash - dans ce cas, une réinitialisation d'usine serait effectivement utile.

Tout d'abord, les montages visibles en ce moment via adb (à l'heure actuelle, je l'exécute toujours à partir d'un dossier sous MSYS2 bash, d'où les doubles barres obliques) étaient :

root@android:/ # mount
mount
rootfs / rootfs rw 0 0
tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0
devpts /dev/pts devpts rw,relatime,mode=600,ptmxmode=000 0 0
proc /proc proc rw,relatime 0 0
sysfs /sys sysfs rw,relatime 0 0
tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0
tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0
/dev/block/nandd /system ext4 rw,nodev,noatime,user_xattr,barrier=0,data=ordered 0 0

Cool, donc on sait maintenant nandd est le /system partition. Vérifions tous les périphériques de bloc :

root@android:/ # ls /dev/block
loop0
loop1
loop2
loop3
loop4
loop5
loop6
loop7
nanda
nandb
nandc
nandd
nande
nandf
nandg
nandh
nandi
nandj
ram0
ram1
vold

( vold est un vieil init Android, qui n'apparaît, semble-t-il, que lorsqu'il y a une opération "normale". adb connexion - pas en cas de récupération).

J'ai donc pensé que je devais essayer de faire une sauvegarde et vérifier s'il n'y avait pas de corruption ; j'ai d'abord essayé ceci pour la sauvegarde :

$ ./adb.exe backup -apk -shared -all -f /c/BACKUP/2021_06_26_DENVER_TAC_97032.ab
WARNING: adb backup is deprecated and may be removed in a future release
Now unlock your device and confirm the backup operation...

... mais cela nécessite une interface graphique active pour la confirmation - et mon écran ne démarre pas... donc pas de chance.

Puis j'ai trouvé https://github.com/TissueFluid/yaffs2-recovery ce qui m'a fait essayer :

$ ./adb shell 'nandread -d /dev/block/nandd -f /dev/tty' > nandd.bin

Le problème étant que je n'ai pas vraiment d'espace disque disponible à ce stade, j'ai donc essayé de rediriger vers /dev/stdout (pour que je puisse sauvegarder le flux sur le PC) mais il n'existait pas ; et finalement j'ai essayé /dev/tty - mais je n'ai obtenu que des messages d'erreur dans le fichier de sortie : " failed get mtd info for /dev/block/nandd, Not a typewriter ".

Ok, alors j'ai pensé, laissez-moi vérifier la corruption :

root@android:/ # e2fsck /dev/block/nandd
e2fsck /dev/block/nandd
e2fsck 1.41.11 (14-Mar-2010)
e2fsck: Device or resource busy while trying to open /dev/block/nandd
Filesystem mounted or opened exclusively by another program?

root@android:/ # umount /system
umount /system
failed: Device or resource busy

Eh ouais, on ne peut pas vraiment démonter les /system partition, lorsqu'il s'agit du système utilisé...

Puis j'ai trouvé ça : https://superuser.com/questions/401217/how-to-check-Root-partition-with-fsck - aucune si elle est vraiment applicable ici.

Puis j'ai fait une mauvaise erreur : j'ai découvert qu'il existe un programme directiotest - J'ai donc pensé, qu'est-ce qui pourrait mal tourner, c'est un "test" des dispositifs de bloc ? MAUVAIS erreur :

root@android:/ # /system/xbin/directiotest
/system/xbin/directiotest
Usage: directiotest blkdev_path

1|root@android:/ # /system/xbin/directiotest /dev/block/nandd
/system/xbin/directiotest /dev/block/nandd
Starting test
Testing area 8192/8192 (100.00% complete)
Test complete

root@android:/ # ls -la /system/xbin
ls -la /system/xbin

Aïe ...

$ ./adb logcat
- exec '/system/bin/sh' failed: No such file or directory (2) -

Oups ... le tout le site /system le système de fichiers a disparu ! En regardant la source après coup https://Android.googlesource.com/platform/system/extras/+/master/tests/directiotest/directiotest.c - il s'avère qu'il "teste" en écrivant des octets dans la mémoire Flash, puis en les lisant ; ce qui (maintenant) provoque évidemment l'effacement de tout le contenu !

Oh mince, il ne reste plus qu'à essayer de récupérer : éteindre la tablette ; Power + Vol Up pour arriver au splash "dead droid" ; et le Power + Vol Up + Vol Down (ou une autre combinaison) - et je pourrais voir ça /sdcard Les fichiers étaient toujours en ligne et répertoriés ! Bon sang, je ferais mieux de sauvegarder ça... mais si je n'ai pas pu le faire avec... adb backup plus tôt, je serais encore moins capable de l'utiliser maintenant ...

Puis j'ai trouvé https://stackoverflow.com/questions/19908641/how-do-you-use-force-adb-to-backup-without-user-confirmation ce qui suggère :

sudo adb shell dd if=/dev/block/bootdevice/by-name/boot > boot.bin

Eh bien, je n'avais pas dd avant, et maintenant je n'ai même pas shell - donc non ...

C'est assez drôle, comme suggéré dans https://stackoverflow.com/questions/10050925/how-do-i-adb-pull-all-files-of-a-folder-present-in-sd-card -- Je pourrais toujours utiliser adb pull pour copier les fichiers de la carte SD ; mais :

$ ../adb pull '//sdcard'
adb: error: cannot create '.\sdcard\Android\data\net.nurik.roman.muzei\cache\artcache\net.nurik.roman.muzei_com.google.android.apps.muzei.gallery.GalleryArtSource\file__external_images_media_16730_a40e97f6903cd2217b225c5fcec4cfcc_6d89a17d2a7ee168c95d93662a817314': Not a directory
pull: building file list...

Donc, cette pourrait ont fonctionné - malheureusement, adb casse le processus à la première erreur, et apparemment aussi /sdcard a été corrompu...

Pour résoudre ce problème, ADB pull s'arrête après la première erreur suggère tar - mais oui, je n'ai pas tar plus, puisqu'il résidait sur l'essuyage /system ... J'ai aussi trouvé une suggestion pour :

$ ../adb-sync --adb=../adb --reverse //sdcard/ .
INFO:root:Sync: local b'.', remote b'//sdcard/'
ERROR:root:Device not connected or not working.

Yup, cela utilise aussi /system les commandes, qui sont maintenant effacées...

Et enfin, cette https://stackoverflow.com/questions/29442630/copy-full-disk-image-from-Android-to-computer aidé :

Comme dit dans le commentaire, adb pull /dev/block/mmcblk0 mmcblk0.img a fonctionné pour moi

Joli :

$ ../adb pull //dev/block/nanda nanda.img
//dev/block/nanda: 1 file pulled, 0 skipped. 5.9 MB/s (16777216 bytes in 2.702s)
...
$ ../adb pull //dev/block/nandj nandj.img
//dev/block/nandj: 1 file pulled, 0 skipped. 4.3 MB/s (5519704064 bytes in 1237.721s)

Yup, j'ai tout nand appareils maintenant ; vérification rapide :

$ for ix in *.img; do echo "$(du -hs $ix); $(file $ix)"; done
16M     nanda.img; nanda.img: , code offset 0x0+3, OEM-ID "        ", sectors/cluster 4, root entries 256, sectors 32768 (volumes <=32 MB), Media descriptor 0xf8, sectors/FAT 32, sectors/track 0, dos < 4.0 BootSector (0x0), FAT (16 bit)
16M     nandb.img; nandb.img: data
32M     nandc.img; nandc.img: Android bootimg, kernel (0x40008000), ramdisk (0x41000000), page size: 2048, cmdline (console=ttyS0,115200 rw init=/init loglevel=8)
512M    nandd.img; nandd.img: data
1.2G    nande.img; nande.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-ffffabf4-655f-ffffbf67-946fc0f9fffff25b (extents) (large files)
16M     nandf.img; nandf.img: data
32M     nandg.img; nandg.img: Android bootimg, kernel (0x40008000), ramdisk (0x41000000), page size: 2048, cmdline (console=ttyS0,115200 rw init=/init loglevel=8)
256M    nandi.img; nandi.img: Linux rev 1.0 ext4 filesystem data, UUID=57f8f4bc-ffffabf4-655f-ffffbf67-946fc0f9fffff25b (extents) (large files)
5.2G    nandj.img; nandj.img: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "android ", sectors/cluster 8, sectors/track 63, heads 64, sectors 10776527 (volumes > 32 MB), FAT (32 bit), sectors/FAT 10504, serial number 0x7d690be0, label: "CRANE      "

Bien, donc apparemment nandj voici /sdcard ... Maintenant je peux fsck les fichiers images à la place, mais je dois démarrer sur Linux pour cela ...


Bien, donc - selon https://askubuntu.com/questions/1147586/identifying-the-file-system-of-an-img-file-and-mount-it il s'avère que les images qui sont Android bootimg sont montables en sysfs :

$ mkdir /tmp/nandc
$ sudo mount -t sysfs -o loop nandc.img /tmp/nandc
$ ls /tmp/nandc
block  class  devices   fs          kernel  power
bus    dev    firmware  hypervisor  module

$ mkdir /tmp/nandg
$ sudo mount -t sysfs -o loop nandg.img /tmp/nandg
$ ls /tmp/nandg
block  class  devices   fs          kernel  power
bus    dev    firmware  hypervisor  module

Cependant, puisque sysfs est est un pseudo-système de fichiers fourni par le noyau Linux il ne semble pas y avoir de fsck pour cela. Donc, nous pouvons seulement faire une vérification du système de fichiers sur les partitions ext4 et DOS.

$ e2fsck -p -f nande.img
nande.img: Directory inode 61534, block #0, offset 0: directory corrupted

nande.img: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
    (i.e., without -a or -p options)

$ e2fsck -f nande.img
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory inode 61534, block #0, offset 0: directory corrupted
Salvage<y>? 
...

$ e2fsck -y -f nande.img
...
Free inodes count wrong (71634, counted=71639).
Fix? yes

nande.img: ***** FILE SYSTEM WAS MODIFIED *****
nande.img: 5161/76800 files (4.9% non-contiguous), 204247/307200 blocks

$ e2fsck -f nande.img
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
nande.img: 5161/76800 files (4.9% non-contiguous), 204247/307200 blocks

$ e2fsck -y -f nandi.img 
...
nandi.img: ***** FILE SYSTEM WAS MODIFIED *****
nandi.img: 11/16384 files (0.0% non-contiguous), 2089/65536 blocks

$ e2fsck -f nandi.img 
e2fsck 1.45.5 (07-Jan-2020)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
nandi.img: 11/16384 files (0.0% non-contiguous), 2089/65536 blocks

$ fsck.vfat nanda.img
fsck.fat 4.1 (2017-01-24)
nanda.img: 44 files, 4188/8171 clusters

...
  Bad short file name (ö2UF.pAñ).
1) Drop file
2) Rename file
3) Auto-rename
4) Keep it
? 3
...
Orphaned long file name part "img-28773653"
1: Delete.
2: Leave it.
? 2
Reclaimed 98484 unused clusters (403390464 bytes).
Free cluster summary wrong (321342 vs. really 419828)
1) Correct
2) Don't correct
? 1
Perform changes ? (y/n) y
nandj.img: 2483 files, 924607/1344435 clusters

Il y a donc pas mal de corruption - malheureusement, les fsck répétés de nandj ne semblent pas effacer les erreurs ...

Quoi qu'il en soit, j'ai une aussi bonne sauvegarde nand que possible maintenant, donc je peux essayer "wipe data/factory reset" à partir du menu de récupération du système Android <3e> ... Malheureusement, le résultat final est maintenant :

-- Wiping data...
Formatting /data...
Formatting /cache...
E:failed to mount /system (Invalid argument)
Data wipe complete.

Eh, donc apparemment tu ne peux pas récupérer /system sur cet appareil ...

Donc ma meilleure chance maintenant, est de trouver le firmware original à restaurer.

En résumé, l'ancienne batterie, en tombant en panne, a probablement provoqué une corruption du flash, qui s'est révélée lors de l'installation de la nouvelle batterie. En dépit de mon erreur d'effacer /system Il était déjà corrompu, et la réinitialisation d'usine n'aurait pas aidé même si je n'avais pas fait l'erreur de l'effacer.

androidalle.com

AndroidAlle est une communauté de androiders où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X