Mini+ sur stretch instable?

joc · Septembre 29, 2020, 10:46

Salut,

j’utilise ma jeedom mini+ depuis quelques années, et ma carte SD vient de me lâcher. j’ai réinstallé la version « stretch » officielle sur une carte neuve et restauré un backup, mais ma jeedom est devenue extrèmement lente ! (genre 5-6min pour afficher une page).

En ajustant la swap 1G / swappiness (20), et en supprimant quelques services inutiles, j’arrive à la faire marcher un peu mieux, mais ça swap toujours beaucoup, et surtout ça plante en kernel panic au bout de quelques heures.

Est-ce que je m’acharne à la refaire marcher, ou il faut changer vers du raspberry PI4 ?

Est-ce qu’il y a une image pour réinstaller Jessie et voir si ça ne va pas mieux ? (mais je risque de ne pas pouvoir passer en v4 si j’ai bien compris ?)

J’ai l’impression que le passage nginx → apache le rend incompatible avec 500Mo de RAM. Est-ce que quelqu’un a déjà essayé jeedom avec lighthttpd ou équivalent ?

Mips · Septembre 29, 2020, 10:58

Bonjour,
Il existe une image mini+ officielle complète (Linux + jeedom); installes cette image plutôt.

Tu trouveras les images dans la doc officielle

akenad · Septembre 30, 2020, 6:56

Bonjour,

utiliser une SD de bonne qualité et
Voir ici : [Présentation] akenad - #10 par akenad

akenad

joc · Septembre 30, 2020, 8:44

J’ai utilisé l’image de la Doc officielle : https://doc.jeedom.com/fr_FR/installation/mini
jeedom_jeeboard_3.3.24_stretch.zip du 12/10/2019

mais elle ne marche pas très bien, s’il y en a d’autres, je suis preneur

Mips · Septembre 30, 2020, 8:48

c’est-à-dire ?

akenad · Septembre 30, 2020, 8:55

L’explication est dans le lien que j’ai indiqué plus haut.

akenad

joc · Octobre 1, 2020, 7:04

J’ai 2 soucis avec cette image:

elle consomme beaucoup de RAM, et du coup ça swap à mort, l’interface est presque inutilisable.
elle « kernel panic » (sur des CRC ext4, probablement lié au fait que le swap est écrite en permanence) au bout de quelques heures, pour de la domotique c’est pas super pratique.

J’ai vu que d’autres utilisateurs ont également des soucis avec le passage à stretch sur jeedom mini+, du coup je me demandai si c’était vraiment utilisable.

pour info j’ai ce genre de kernel « oops » et la board fini par freezer complètement:

Oct  1 02:13:09 localhost kernel: [16853.965405] CPU: 0 PID: 15788 Comm: modprobe Tainted: G      D         4.9.150-imx6-sr #1
Oct  1 02:13:09 localhost kernel: [16853.992419] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
Oct  1 02:13:09 localhost kernel: [16854.016062] task: cda64b00 task.stack: c7812000
Oct  1 02:13:09 localhost kernel: [16854.035631] PC is at ext4_dirent_csum_verify+0x3c/0xfc
Oct  1 02:13:09 localhost kernel: [16854.056385] LR is at __ext4_read_dirblock+0x108/0x3bc
Oct  1 02:13:09 localhost kernel: [16854.076864] pc : [<c02cc06c>]    lr : [<c02cc234>]    psr: a00f0013
Oct  1 02:13:09 localhost kernel: [16854.076864] sp : c7813d70  ip : 00000ff4  fp : cbad5000
Oct  1 02:13:09 localhost kernel: [16854.120505] r10: 00000000  r9 : c0a0b9d8  r8 : 00000000
Oct  1 02:13:09 localhost kernel: [16854.141198] r7 : 00000000  r6 : c662fb18  r5 : cbad5000  r4 : 00000000
Oct  1 02:13:09 localhost kernel: [16854.164441] r3 : cba69480  r2 : 00000ff4  r1 : 00000000  r0 : c662fb18
Oct  1 02:13:09 localhost kernel: [16854.187648] Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Oct  1 02:13:09 localhost kernel: [16854.212063] Control: 10c53c7d  Table: 17804059  DAC: 00000051
Oct  1 02:13:09 localhost kernel: [16854.813291] [<c02cc06c>] (ext4_dirent_csum_verify) from [<c02cc234>] (__ext4_read_dirblock+0x108/0x3bc)
Oct  1 02:13:09 localhost kernel: [16854.841388] [<c02cc234>] (__ext4_read_dirblock) from [<c02cca98>] (htree_dirblock_to_tree+0x48/0x1d0)
Oct  1 02:13:09 localhost kernel: [16854.869217] [<c02cca98>] (htree_dirblock_to_tree) from [<c02cd930>] (ext4_htree_fill_tree+0x94/0x2f0)
Oct  1 02:13:09 localhost kernel: [16854.897110] [<c02cd930>] (ext4_htree_fill_tree) from [<c02bb138>] (ext4_readdir+0x63c/0x92c)
Oct  1 02:13:09 localhost kernel: [16854.923482] [<c02bb138>] (ext4_readdir) from [<c024fbfc>] (iterate_dir+0x14c/0x194)
Oct  1 02:13:09 localhost kernel: [16854.948299] [<c024fbfc>] (iterate_dir) from [<c02502c8>] (SyS_getdents64+0x8c/0x144)
Oct  1 02:13:09 localhost kernel: [16854.973307] [<c02502c8>] (SyS_getdents64) from [<c0107860>] (ret_fast_syscall+0x0/0x48)
Oct  1 02:13:09 localhost kernel: [16855.020795] ---[ end trace a9a8242142eb02d4 ]---

et quand je suis loggé en ssh, ca vient d’apache2 :

Message from syslogd@localhost at Oct  1 06:59:52 ...
 kernel:[16908.212488] Internal error: Oops: 5 [#20] SMP ARM
Message from syslogd@localhost at Oct  1 06:59:52 ...
 kernel:[16908.601193] Process apache2 (pid: 18070, stack limit = 0xcae7a210)
Message from syslogd@localhost at Oct  1 06:59:52 ...
 kernel:[16908.623627] Stack: (0xcae7bd70 to 0xcae7c000)

pourtant la SDCard est toute neuve, et je n’ai pas d’I/O error (comme ce qui est arrivé à ma SD Card précédente).

Je peux même pas aller dans l’onglet « santé », j’ai juste une page blanche.

joc · Octobre 5, 2020, 9:03

Bon finalement j’ai laissé tombé stretch, j’ai réessayé plusieurs fois l’installation, et toujours le même souci.

J’ai dumpé (avec dd ) ma carte SD corrompue sur la carte SD neuve, un petit e2fsck, et ça remarche nickel sous Jessie. (donc c’est pas un souci matériel)