Analyse de la cause racine de la boucle de démarrage à partir de console-ramoops-0 (& logcat)

Résumé - Mise à jour 2 :
Je ne supprime pas le contenu de la question, pour préserver l'historique (mais un administrateur peut le supprimer si nécessaire), mais les choses ont changé depuis. Un jour après avoir rencontré l'erreur TWRP createTarFork() 255 mentionnée ci-dessous, j'ai réussi à restaurer les données de /data à partir d'une sauvegarde Nandroid TWRP. Le problème survient lors de la 2e installation de la même ROM stock - je me retrouve dans une boucle de démarrage. La sauvegarde TWRP elle-même provenait d'une partition chiffrée restaurée sur une autre partition (chiffrée ou non, peu importe). En essayant de résoudre la boucle de démarrage et de trouver un moyen de restaurer mon /data, j'ai joint ci-dessous des journaux de démarrage défectueux et normaux.

C'est de l'ancien historique. Vous pouvez passer directement à la mise à jour 1 ci-dessous, en sautant cela :
Boucle de démarrage et coincé sur le logo "Powered by Android". Logcat n'a pas été très utile. Je veux savoir ce qui cause le blocage. Tout ce que j'ai est issu de /sys/fs/pstore/console-ramoops-0

'android.frameworks.sensorservice@1.0::ISensorManager/default': Aucun fichier ou dossier de ce type

Je joins l'intégralité de /sys/fs/pstore/console-ramoops-0

quel est le problème ?
J'ai des sauvegardes TWRP de vendeur, système, démarrage avec lesquelles j'ai tenté des restaurations. Sans succès. Il s'agit d'une ROM MIUI stock avec TWRP comme base de récupération donc après avoir flashé dm-verify-no encrypt.zip (je ne me rappelle pas exactement du nom) + certification.zi & permssiver, j'arrive au logo MIUI mais je boucle maintenant sur le logo "Powered by android".

Résultats de fsck

    olivelite:/ # e2fsck /dev/block/mmcblk0p60
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p60: propre, 4614/65536 fichiers, 184349/262144 blocs
olivelite:/ # fsck /dev/block/mmcblk0p60
/sbin/sh: fsck: introuvable
127|olivelite:/ # e2fsck -v /dev/block/mmcblk0p60
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p60: propre, 4614/65536 fichiers, 184349/262144 blocs
olivelite:/ # e2fsck -v /dev/block/mmcblk0p59
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p59: propre, 4547/262144 fichiers, 680379/1048576 blocs
olivelite:/ # e2fsck -v /dev/block/mmcblk0p62
e2fsck 1.43.3 (04-Sep-2016)
data: propre, 62826/1389536 fichiers, 3383723/5667584 blocs
olivelite:/ # e2fsck -v /dev/block/mmcblk0p57
e2fsck 1.43.3 (04-Sep-2016)
/dev/block/mmcblk0p57: propre, 33/98304 fichiers, 22707/98304 blocsentrer 

fsck semble propre pour toutes les partitions
Voici le **logcat** & voici **dmesg** dans logcat il pourrait s'agir d'un problème de décryptage. Mais ce n'est que pour le démarrage twrp demande un schéma et décrypte bien. Pourquoi cela ne se produit-il pas lors du démarrage - c'est mon intuition sur le problème. Je n'essaie pas de vous diriger dans cette direction. Comme Mikko l'a dit, pratiquement tout semble crier, donc il est difficile d'attraper le coupable. Je vais essayer une sauvegarde /data effacement et restauration voyons voir...
. Mise à jour
comme je le soupçonnais, il semble que ce soit lié au chiffrement. L'installation réussie précédente avait une serrure de modèle (à l'époque où cette installation a été construite, j'ai flashé - permissiver.zip, certificate.zip & dm-verity-force-encryption w default ops to disable verity & disable forced encryption) - mais la sauvegarde TWRP nandroid elle-même n'a jamais été chiffrée. Quand j'ai essayé de la restaurer, j'ai toujours fini avec l'erreur TWRP createTarFork() 255 qui est une erreur très générique - avec plusieurs RAI. Dans mon cas, cela se produit immédiatement (les données précédentes ont été effacées & formatées sur toutes les partitions pertinentes. La seule façon dont j'ai réussi à restaurer avec succès était d'utiliser flashtool (qui exécute des commandes fastboot en dessous) pour installer stock -> fastboot twrp & patched magisk boot install et ensuite restaurer /data (après avoir exécuté magisk & tenté dm verity de restaurer twrp) - dans ce cas, la restauration a été un succès. Donc, avec les étapes ci-dessus, j'ai pu restaurer avec succès /data mais ce /data restauré se retrouvera bloqué dans une boucle de démarrage (si les sauvegardes twrp ne sont pas chiffrées, pourquoi alors une simple effacement & formatage ne permet-il pas la restauration TWRP ? seul flashtool de-novo stock installation va permettre la restauration ? J'ai lu qu'un bogue dans twrp ne permettra pas la restauration de la sauvegarde d'une partition chiffrée sur une non chiffrée ... ok donc j'ai aussi chiffré une installation stock de-novo avec le même modèle & après avoir réussi à restaurer /data je me suis retrouvé dans la même boucle de démarrage à nouveau).
même si j'utilise cette installation stock de-novo en ce moment avec des applications 'kit de survie à bas niveau'. Je pourrais extraire les journaux d'un démarrage réussi pour comparer avec les boucles de démarrage après la restauration de /data que j'ai téléchargées plus tôt (comme suggéré par Mikko - il faut des journaux de démarrage mauvais et normaux pour comparer).
Donc la grande question
est comment diable puis-je récupérer /data à partir de ma sauvegarde Nandroid sans boucle de démarrage
J'ai téléchargé ceci :
Démarrage normal pmsg-ramoops , dmesg, ramoops (les 2 derniers sont pratiquement identiques - si vous lisez ramoops - c'est bon), logcat Inutile de dire que la restauration est tentée sur la même ROM stock