Reprise du message précédent :

Merci pour tes explications, je comprends maintenant.
 
Tes 3 commandes là, je crois que j'avais déjà essayé et la réponse ne t'eut pas convenu    
 
=> ls/dir: Cannot open directory blk0(1)(2) - No mapping    
 
J'en avais déduit qu'ils sont "là", mais non "mounted" <= j'ai bon ?
J'avais donc continué avec "MAP" et là, ça me sort les 3 premières lignes => gnagnagna blockdevice gné - Alias (null) taglesaleté grrr  

En fait je me suis planté la commande c'est :
ls blk0:\
 
mais je pense que tu vas avoir un résultat du genre:
ls: File Not Found - 'blk0:'
 
parce le type de partition n'est pas reconnu
 

 
En fait ils sont là parce qu'on les voit sous Puppy/Gparted, mais ce qui se passe sous le shell EFI m'échappe un peu.
 
La commande map, dans ton cas, montre bien les 3 disques (blk0, blk1, blk2 qui correspondent à mmcblk1, mmcblk1boot0, mmcblk1boot1 de la commande lsblk sous Puppy/linux), mais le shell EFI ne voit pas les partitions (comme si les disques étaient en RAW), alors que sur blk0 il devrait voir 5 partitions (ça voudrait pas dire pour autant qu'il saurait les lire, mais au moins la partition EFI en FAT, celle qui est normalement mappé en FS0, il devrait a voir et pouvoir la lire)
... C'est à se demander si ton firmware n'est pas corrompu et que ton shell EFI serait pas en mode dégradé
 
 
 
On va essayé un truc : lancer un autre shell EFI que celui de ton bios.
 
Pour ça il faut que tu fasses un clé USB avec rEFind (soit à partir de l'image CD et tu transfères l'ISO sur la clé avec Rufus, soit en téléchargeant l'image USB et tu transfères l'IMG contenu dans le zip sur la clé USB avec Etcher)
 
Une fois fait, sur le QNAP tu bootes sur la clé USB.
Dans le menu de rEFind, avec de la chance tu devrais voir une entrée qui correspond à ton QNAP.EFI, qui devrait te permettre de booter l'OS  
 
Edit: Si ça fonctionne faudra se pencher sur la MAJ du bios du QNAP je pense

Ce "mapping", il est défini où? C'est un truc que le BIOS/UEFI autodétecte ou un réglage ou codé "en dur" dans le firmware ou ... ?  
 
En effet ça ne sent pas super bon tout ça.

Je pense pas que ce mapping soit défini réellement. C'est juste une vue des périphériques de stockage que le shell/os en cours d’exécution construit en fonction de ses capacités de base et des pilotes qui sont chargés.
 
Faut voir ça comme un gestionnaire de disques qui ne ferait que du reporting.  
Le truc c'est qu'un gestionnaire de disques implique d'avoir un gestionnaire de partitions, qui lui implique d'avoir une gestionnaire de volumes/système de fichiers.
 
Là, sous le shell EFI, on a l'impression qu'il n'y a que le gestionnaire de disques, sans la gestion des partitions, ni des volumes.
Par contre en bootant sous Puppy/Windows ou autre, on a un gestionnaire de disque complet et tout est accessible.
 
C'est pas normal que le gestionnaire de disque (enfin la commande map), ne gère pas les partitions/les volumes. J'ai pas beaucoup bricolé avec l'EFI, mais je suis jamais tombé sur un cas comme ça    
 
L'autre truc qui m'inquiète c'est que j'ai l'impression que QNAP n'a prévu de système de MAJ du firmware qu'en passant par leur OS ... C'est très très con si c'est le cas.
Bon ça sera surement possible flasher le bios autrement, via un linux, un programmateur d'EEPROM ou autre, mais va encore falloir trouver tâtonner  pour y arriver  

Soit via Linux et flashrom (risqué), soit en désoudant la puce pour la programmer avec un machin CH431(??) ou similaire. Par contre le soucis sera de trouver le bon fichier à flasher... La prog' en soit c'est pas bien compliqué - si on a le matos, la encore vaudra voir avec Aline.

EDIT: Au risque de passer pour un idiot, mais tu (Aline) as tenté de tapper "help" dans ce shell mystérieux?

C'est exactement à ça que je pensais pour reflasher le BIOS, mais bon c'est pas normal de devoir en arriver là quand le système est encore à peu près fonctionnel.
 
Pour le firmware d'après ce que j'ai compris, il est contenu dans l'image de l'OS du QNAP. Faudrait que j'essaie d'extraire le contenu d'une de ces images, mais on verra ça plus tard si y'a vraiment besoin.
 
Pour le help, y'a pas de masses de commandes :
 

 
Y'a pas grand chose d'utile tant que les partitions/volumes ne sont pas reconnues
 
Edit : devtree à la limite ... chez moi ça me liste bien les partitions de boot/EFI formatées en FAT

Y'a une tonne de trucs à télécharger chez QNAP pour ce modèle, mais à priori pas d'image BIOS/UEFI. https://www.qnap.com/fr-fr/download [...] y=firmware
EDIT: https://www.qnap.com/en/how-to/tuto [...] a-qnap-nas

EDIT2: SI! https://eu1.qnap.com/Storage/BIOS/TS-X53B/QY47AR58.zip

EDIT3 : et le fichier .bin est à première vue une image qu'on pourrait au pire flasher directement avec un CH341 ou similaire (si la puce fait bien 8Mo).

J'ai bien entendu essayé "help", mais je n'ai pas trouvé le switch pour afficher page par page, comme on le faisait
autrefois sous MSDOS => dir /p je crois.
 
Avec "map", j'ai réussi à associer mmblk0 avec fs0, mais ça ne permet pas de lister son contenu = message d'erreur.

Ok, j'ai fait la clef et j'ai booté dessus. Tu veux que je regarde quoi exactement ?

Pour le firmware/.bin j'avais compris qu'il était contenu dans le .img du DOM, mais je suis sur de rien, j'ai pas encore vérifé
 
Aline, y'a pas de page par page, par contre tu peux scroller avec PageUp/PageDown  
 
Comment t'as réussi à associé mmblk0 et fs0 ?

 
Déjà nous dire ce que tu vois à l'écran ...  
 
Ensuite lancer le shell EFI à partir du menu (sur la seconde ligne, t'as une icône comme le command-prompt de windows) et voir si dans le résultat de la commande tu as FS0 et FS1 (FS0 devrait être la partition EFI de la clé USB et FS1 celle du DOM, ou l'inverse)

J'ai pas "démonté" le firmware, mais un rongeur m'a dit que ce n'est pas le cas. Il y a par contre un lien direct et officiel plus haut (mes EDIT).
 
Ah et d'ailleurs, DOM c'est quoi??? (dans notre contexte)

j'avais pas vu les edit avec le firmware  
 
DOM normalement c'est Disk On Module (USB ou SATA), mais pour le TS-453Be c'est un abus de langage de QNAP car l'eMMC est soudé à la carte-mère, du coup on est pas vraiment sur un module. Enfin on s'en fout le DOM=eMMC=BLK0 dans le cas qui nous intéresse

Bon, j'essaie de suivre les deux passionnés là    
 
Comment j'ai associé blk0 et fs0 ? J'ai demandé l'aide de "map", puis j'ai tapé un truc du style : map blk0 fs0
Ca a donné ceci :

 
 
Quand je bricole avec rfind efi machin :
 

 
et
 

 
 
@RdC :
je regarde les liens que tu as donné, et je voudrais tenter => https://www.qnap.com/en/how-to/tuto [...] a-qnap-nas
 
Mais il y a quelque chose qui ne va pas dans la partie 2...
a - ok, ça c'est bon, j'ai pris un bios autre que ceux que j'ai déjà  
b- décompresser le fichier => bah là, c'est un zip, et dedans, y'a un fichier .IMG
c- et donc, bah je peux pas faire le c
 
Car plus loin, ils font un dir, et on voit plusieurs fichiers : or moi, je n'ai qu'un img alakon...

Euh... non. Si tu cliques sur le lien que j'ai mis tu auras un zip avec dedans:

@Aline  
 
Ouais ben rEFInd voit pas plus les partitions et les volumes que ton BIOS    
 
A part reflasher le BIOS et/ou reconstruire l'eMMC (mais ça je pense que tu l'as déjà fait hier) en espérant que ça change qqchose, j'ai plus trop d'idées  

!
 

 
 
?
 

 
 
 

Ils ont dû merder en fabriquant leur .bin, mais vu qu'il y a une tonne de 0xFF (autrement dit rien du tout) c'est pas un soucis et visiblement ça a fonctionné.
 
Donc redémarrage (encore) et voir ce que ça donne.

C'est fait, comme ils le disent, j'ai tout débranché, 220 V compris.
 
Ca a bien du prendre 5 bonnes minutes, le temps de poster mes photos, et puis j'ai rebranché.
 
ET C'EST TOUT PAREIL QU'AVANT      
 
Absolument rien n'a changé, même pas le bios
 
 
Mais y'a un truc qui est louche : ça dit "que le fichier sera pas écrit en entier, parce qu'il est plus grand que la place disponible"  

Pas sur que tu ai le bon firmware
 
Celui du zip c'est pour un TS-453B et toi tu as un TS-453Be ... Je sais pas si ce sont les mêmes
 
Si pourtant c'est le bon

J'ai pu me tromper mais je crois que j'ai pris le bon lien. Au pire si quelqu'un veut revérifier...  
 
On parle de quelque dizaines d'octets et que des 0xFF en trop, donc ce point me paraît pas critique.
 
Aline, sur le site du fabriquant ça parlait de F7 pour démarrer un shell pour la màj, il se passe quoi si dans ce même shell tu tappes map etc ?

Tu veux dire, maintenant qu'on a flashé "on sait pas trop quoi" ?
 
Bah attends, je relance cette chiotte  
 
=> Device mapping table
et les memes infos depuis le début... (blk0, blk1 et blk2, tous en ALIAS NULL comme avant)

Désolé, c'est moi qui me mélange les pinceaux. Le firmware est le bon

Oui, mais à priori, deux possibilités :
- ça a fait semblant de l'ecrire
- on a flashé le même qui était déjà en place
 
Vous avez examiné attentivement les messages "jaunes" de mes écrans ?

Je viens de voir que ton EEPROM ne fait que 8188Kb au lieu des 8192Kb qu'elle devrait faire (en bas de la 1ère photo)
 
Je me trompe ?
 
Edit: Et du coup çà explique le message en jaune ... Forcément ça dépasse  

Comme je disais, cette histoire de taille c'est pas critique sur ce coup. Après oui, on a peut-être reflashé le même (le dernier dispo), mais au moins maintenant on sait que le BIOS/UEFI est ok, du moins au niveau contenu de la puce mémoire.
EDIT: Après en théorie il se pourrait que pour une raison X ou Y la FLASH (pas EEPROM) mémoire soit HS et indique une mauvaise taille en plus de déconner, mais j'y crois pas, dans ce cas l'interface BIOS ne fonctionnerait probablement pas du tout.

Perso je vois trois possibilités:
-eMMC HS (->c'est mort )
-partitions boot eMMC HS ou autre config de ces puces bien complexes. A priori ça peut se lire sous Linux, mais faut utiliser des outils dédiés et comme on a pas d'images firmware dont on sait qu'elle sont bonnes on ne pourra pas comparer et/ou reconfigurer/reflasher (?)
-problème de réglage dans le BIOS/UEFI/shell F7. Après ces trucs la moi j'y connais rien.

Je ne vous ai pas dit le pire...
 
L'autre jour, ça m'a tellement énervé que je suis allé jouer avec Gparted. Vu qu'il y avait un gars sur le forum Qnap qui disait
qu'il s'en était servi.
J'ai voulu agrandir les partitions, et pis bah ça a fait un peu du caca    
J'ai réussi à agrandir et déplacer la dernière.
Les deux identiques, je n'ai réussi qu'à les déplacer.
 
Celle du boot proprement dit, y'a un cadenas dessus, je ne peux rien faire avec => je pensais l'agrandir un peu et y coller un boot.efi dessus.
 
Quel rapport ?
Bin...je viens de relancer Puppy : les partoches ont toujours les mêmes tailles qu'après mon bidouillage.
Alors que le flash aurait du les remettre à leur taille pré-définie, non ?
 
Si j'ai une image disque avec 2 partitions dedans, et que je la clone sur un disque qui a déjà 3 partitions, je me retrouverai
avec les 2 partitions de mon image. Donc, pourquoi ça n'a rien fait ici ?  

Ah oui... Tu aurais dû nous dire! En effet, c'est pas bon signe.
 
Perso j'effacerais le eMMC avec dd if=/dev/zero of=/dev/mmcblk1 bs=1M status=progress pour ensuite démarrer depuis clé USB et faire sudo lsblk . Si tu vois toujours les partitions c'est mort.

ok pour la FLASH
 
- l'eMMC HS j'y ai pensé, mais à mon avis si c'était le cas, sous Puppy/gparted on verrait pas non plus les partitions/fichiers
- partition boot eMMC pareil qu'au dessus, non ?
- pb de réglage dans le BIOS => c'est le cas, mais l'entrée manquante dans le bios pour lui indiquer sur quoi booter est définie sous le shell EFI par la commande bcfg à laquelle on passe en paramètre le chemin de la partition EFI (la partition boot/efi en FAT de l'eMMC), sauf que le comme le shell la voit pas, on tourne en rond    
 
Y'aurait peut-être moyen de recréer le contenu de l'eMMC sur une clé USB et de voir si ça boot comme ça, mais c'est pas gagné du tout
 
Edit: Je suis trop lent  

Allez les gars, profitez de votre soirée, ça suffit pour aujourd'hui    
 
Merci encore de vous arracher les cheveux pour moi, mais on reprendra ça demain si ça vous dit  

ok, mais à ta place je suivrais la procédure que t'as filé notre ami juste au dessus et ensuite je ferais une clé USB Live de Ubuntu, booterais dessus, téléchargerais la dernière image QTS => https://eu1.qnap.com/Storage/TS-X53 [...] 4.2596.zip, extrairais le .img et double-cliquerais sur le .img pour restaurer l'image sur l'eMMC
Ensuite reboot en croisant les doigts très fort    
 
Bonne soirée à tous les deux

J'ai tenté quelque chose : j'ai une live clef d'Ubuntu 23.04
Je l'avais déjà essayée il y a un moment, mais ça crashe dès le boot. Mais cette fois-ci, j'ai tenté l'option "safe graphics" et c'est passé.
Le bureau s'affiche alors en 800x600, c'est pas génial mais c'est mieux que rien.
 
Donc, j'ai lancé le Gparted de là, et j'ai supprimé toutes les partitions.
Ensuite, j'ai rebooté dans le shell.efi, et il m'affiche encore et toujours les 3 blk null machin, comme avant en fait.
 
Maintenant, j'ai encore rebooté sous Puppy, et son Gparted me montre que les 3,9 Go de mmcblk truc sont vides, "espace inutilisé".
 
Je m'apprête donc à tenter le double-clic sur l'image QTS comme dit ci-dessus.
 
 
EDITEMENT : et donc, il ne se passe absolument rien.
Cependant, aussi bien sous Ubuntu que Puppy, Gparted me montre que mmcblk0 est entièrement vide, "espace inalloué", et que sa taille est de 4 Go.
 
Puis, j'ai commencé à me dire que le meilleur moyen de savoir si l'eMMC est encore potable, c'est encore de foutre un systeme quelconque dessus.
Ainsi, depuis l'Ubuntu Live, j'ai lancé l'install. Et là, bah il trouve les 4 Go disponibles, mais me dit qu'il lui faut 19 Go...
Hop, encore un coup d'épée dans l'eau.
 
Mais je suis têtu, je vais coller un disque dur dans le nas, et voir si je peux installer dessus  

Bon bon bon...l'experimentateur fou continue ses élucubrations...    
 
J'ai rebooté sur l'Ubuntu Live, et lorsqu'il donne le choix entre "tester" et "installer", j'ai choisi l'install.
J'ignore comment, mais il a trouvé le vieux disque que j'ai mis dedans.
 
"Installation du système" en cours => sur le petit afficheur du nas, j'ai la loupiote verte du disque 3 installé, qui est allumée.
Et j'entends le disque gratter.
 
J'ignore si l'install aboutira, mais en attendant, bah je peux constater que l'interface SATA semble fonctionner.
 
 
Par la suite, je vais sortir mon dock SATA-USB, y coller le même disque (ou un autre, whatever) et y graver l'image de l'EFI de tantôt.
Voilà, j'attends que l'install se termine, puis je regarderai dans Gparted si quelque chose a changé...

Ubuntu n'arrive pas à redémarrer après l'installation, je laisse tomber car je ne sais pas le mettre en "safe graphics".
 
Mais par contre, lorsque je rentre dans le bios du nas (je l'ai laissé éteint plusieurs minutes), bah la date n'est plus 2017
mais 2020    
 
Donc, un truc qu'on a fait n'a pas marché, mais en réalité, il a marché quand même ?  

J'suis chaud bouillant, je continue à essayer un peu tout ce qui me passe par la tête    
 
J'ai découvert un truc : lorsque j'essaie de graver une image DOM avec Rufus, il indique parfois "analyse image impossible".
Aha. Interessant ! Ainsi, toutes les images commençant par "F_TS" sont ok pour lui, alors que celles commençant par "TS_" lui sont illisibles !
 
J'ai donc pris la seule valide que j'aie actuellement : F_TS-X53B_20161212-1.3.0_EFI et l'ai Rufusée sur un disque.
Ensuite, j'ai allumé le nas avec lui dedans => et ainsi, dans le bios, dans les options de boot, j'ai désormais "Qnap OS"    
 
J'ai éteint, tout débranché, et rallumé : il bricole pendant quelques minutes, puis fait un looooong bip que je n'avais jamais entendu.
Et ça correspond aux tutos, ils précisent qu'il doit donc y avoir ce loooong bip et qu'ensuite, le nas est initialisé. Et doit donc etre
visible sur le réseau, et Qnap Finder...
 
Et maintenant, j'arrive sur un écran noir de login, voir photo :

 
Si je tape portnawak, ça me le dit direct.
Comme j'aime lire, je me souviens avoir lu des gars qui en parlaient : et donc, le login est identique au mot de passe => admin.
Mais ça ne prend pas, cf ci-dessus. Doit encore manquer un truc quelque part...
 
Vu que ça donne rien, j'ai rebooté dans le shell efi, et j'ai capturé le mappage. Ici, il y a le disque dur "Qnap" ainsi que la clef Puppy que j'ai
plugguée avant la photo :

et

 
Maintenant, faut que je poste ce message, puis que j'aille sur le nas, faire des captures de Gparted, car ça me semble très interessant. Enfin je crois.
Notez que j'arrive à poster depuis le nas  

Je suis avec Puppy    
 
Le mmcblk truc est toujours vide de chez vide :

 
 
Le disque dur QNAP OS affiche ceci :

 
J'ai fouillé dedans, et il y a aussi un QNAP.EFI dedans.
 
Mon intuition me dit de cloner le HDD sur l'eMMC, mais je ne sais pas faire ça sans un Partition Manager tel que Macrorit
ou Macrium Reflect...
Ce qui met donc un terme à mes expérimentations nocturnes  

Salut,
 
Alors, c'est pas mal tout ça. Tu as fais avec ton hdd ce que je suggérais de tenter avec un clé USB, mais le résultat est le même : ça démarre    
 
Au lieu de cloner le HDD sur l'eMMC, je pense que c'est plus simple de restaurer l'image F_TS-X53B_20161212-1.3.0_EFI.img sur l'eMMC
 
Pour la commande je reprends ce que rat de combat t'avais déjà donnée (vers la fin de la première page du topic)
 
dd if=/chemin/vers/F_TS-X53B_20161212-1.3.0_EFI.img of=/dev/mmcblk1 bs=1M status=progress
 
Proablement avec un sudo su avant
 

 
 
Je crois que j'ai déjà essayé, et ça ne fonctionne pas.
 
Je me suis servi de ça : dd if=/home/user/dom.image of=/dev/sdb2 bs=4096 conv=notrunc,noerror
 
=> https://doc.ubuntu-fr.org/dd

Ca fonctionne pas ? C'est l'écriture sur l'eMMC qui est impossible ?
 
Parce que ta commande c'est la même que la mienne, sauf que tu écrit sur le disque dur, ce qui ne sert plus à grand chose vu que tu l'as déjà fait hier
 
J'ai vu le truc sur la date. La seule explication c'est que la date par défaut dans le nouveau BIOS est plus récente que dans la version d'avant ... Et que personne n'y a fait attention avant.
 
D'ailleurs par curiosité c'était quoi la version du bios d'avant ?
 
Edit: d'ailleurs le noerror dans ta commande est à éviter, puisque que ça permet d'ignorer les erreurs , et le notrunc je suis pas sur de son intérêt dans ce cas là

Si si, ça fonctionne : j'ai pu voir que ca a re-créé les partitions qu'il y avait au début.
Mais dans le boot menu, y'a pas "QNAS OS". Lorsque je le fais depuis un HDD, l'option est bien présente, mais ça arrive sur une demande
de login/password...
 
La version du bios, elle datait de septembre 2017.
Et c'est moi qui déconne, la date a changé parce qu'on a réussi à flasher un bios avec RdC, et je l'avais déjà oublié.    
Après, je suis excusable, parce que je me défonce comme un damné pour remettre ce machin sur les rails.
 
Mais plus on avance, et plus je me dis qu'il doit y avoir un truc de flingué quelque part : avec toutes les tentatives qu'on a fait, ça aurait
déjà du redémarrer correctement.
 
EDITEMENT : je viens donc de restaurer l'image, et c'est toujours pareil, "QNAP OS" n'apparait pas dans le  boot menu.
Y'a "EFI shell" et "disabled", c'est tout.
Ca apparait et ça envoie sur un login, uniquement lorsque l'image est restaurée sur un disque dur.
=> l'eMMC doit être morte ou bancale d'une façon ou d'une autre.

Ah ok, la ré-écrirure du disque fonctionne, mais on retombe au point de départ
 
Pour le BIOS, t'inquiètes moi aussi j'ai du mal à me souvenir de qui a déjà été tenté
 
Pour l'eMMC je commence à penser comme vous (RdC en parlait aussi hier), ou alors il manque le un flag pour indiquer que la partition est bootable ? Je vais voir si y'a pas un piste de ce côté