logo Debian Debian Debian-France Debian-Facile Debian-fr.org Forum-Debian.fr Debian ? Communautés logo inclusivité

Debian-facile

Bienvenue sur Debian-Facile, site d'aide pour les nouveaux utilisateurs de Debian.

Vous n'êtes pas identifié(e).

#1 17-10-2024 09:15:02

Sven
Membre
Inscription : 16-10-2024

RPI-Clone : disparition de ma clé de boot après clonage

Bien le bonjour
là j’ai besoin d’un coup de main car j’ai fait une c*nnerie mais je ne sais pas laquelle.
J’avais installé rpi-clone et lancé

sudo rpi-clone mmcblk0


pour cloner ma clé USB sur laquelle est installée l’OS, sur la SDCard.

Je redémarre et là : je me retrouve à booter sur ma SDCard et plus rien sur ma clé USB !
Comme si le contenu avait été transféré.
Je n’y comprends rien.
De quelles informations auriez-vous besoin pour me sortir de ce mauvais pas?

Dernière modification par Sven (17-10-2024 09:32:22)


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#2 17-10-2024 10:07:02

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

Salux,

Selon la document de rpi-clone https://github.com/billw2/rpi-clone

billw2 a écrit :

...
5. USB boot clone back to SD card slot that preserves SD card to USB boot setup:
    $ rpi-clone -l mmcblk0
...

Pour conserver le boot sur ta clé USB.

Pour savoir ce qu'il y a maintenant sur ta clé USB, commence par donner le retour de

fdisk -l


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#3 17-10-2024 10:07:33

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : RPI-Clone : disparition de ma clé de boot après clonage

hello
de ce que j'ai lu rpi-clone ne transfert pas, ta clé usb est vide?
vu que c'est un clone rpi peut boot sur la cle ou la carte SD maintenant, la caret SD est peut etre avant dans l'ordre de préférence
essai voir sans la carte SD voir si ça boot sur ta clé USB
https://github.com/billw2/rpi-clone

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#4 17-10-2024 10:34:26

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

billw2 a écrit :

...
5) Clone l'USB de boot vers la carte SD, qui préserve la configuration de démarrage de la carte SD vers USB :

$ rpi-clone -l mmcblk0

...
5) Clonage vers des cartes SD dans l'emplacement pour carte SD à partir de démarrages USB
Que le démarrage se fasse à partir d'un Pi3 directement sur USB ou d'une carte SD sur USB, la carte SD n'est pas utilisée et peut donc être clonée librement. Cela crée une carte SD bootable autonome :

$ rpi-clone mmcblk0

Cependant, dans le cas où le démarrage s'est fait à partir de la carte SD vers l'USB, cela détruit la capacité de la carte SD à démarrer sur l'USB. Pour conserver cette configuration de démarrage à partir de la carte SD vers l'USB, exécutez :

$ rpi-clone -l mmcblk0

  • La carte SD est clonée comme avant. Elle dispose désormais du fichier USB /boot/cmdline.txt.

  • Mais l'option -l empêche de modifier ce cmdline.txt pour référencer la carte SD. Il est laissé tel quel afin qu'il fasse toujours référence à la partition racine USB. Ainsi, le clone a créé une sauvegarde du disque USB sur la carte SD tout en préservant la configuration de démarrage de la carte SD sur USB. Sur la carte SD, une sauvegarde cmdline.boot est créée et modifiée pour référencer la carte SD. Cette sauvegarde peut être déplacée vers cmdline.txt pour rendre la carte SD amorçable de manière autonome si jamais vous souhaitez le faire. Ou vous pouvez simplement cloner sur la carte SD sans utiliser -l.

  • Les deux commandes de clonage mmcblk0 ci-dessus s'appliquent que vous utilisiez PARTUUID ou des noms de périphériques. Lorsque vous utilisez des noms de périphériques et que vous effectuez un clonage sur des cartes SD, rpi-clone sait que les noms de périphériques fstab doivent être modifiés, donc « -e mmcblk0p » est supposé. La carte SD peut maintenant être laissée en place de manière permanente et clonée périodiquement pour les sauvegardes et les redémarrages sur USB fonctionneront comme vous le souhaitez. Ou d'autres cartes SD peuvent être insérées pour créer un ensemble de sauvegardes. Si vous créez un clone pour un autre Pi qui sera amorçable sur carte SD, n'utilisez pas -l.

  • Attention : cela fonctionne si la configuration de démarrage d'origine de la carte SD vers USB a modifié le fichier USB /etc/fstab pour référencer les partitions USB comme le fait rpi-clone lors de la création d'un disque de démarrage USB avec -l. Si vous avez une configuration de démarrage de la carte SD vers USB existante où cela n'a pas été fait, alors votre démarrage USB a probablement la partition /boot de la carte SD montée, la carte SD est en cours d'utilisation et l'utilisation de rpi-clone pour un clonage vers l'emplacement de la carte SD ne fonctionnera pas.


...


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#5 17-10-2024 10:47:49

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

Croutons a écrit :

de ce que j'ai lu rpi-clone ne transfert pas, ta clé usb est vide?

Comme toi, je ne pense pas que la clé soit vide.
... Elle ne doit plus être montée.

Croutons a écrit :

essai voir sans la carte SD voir si ça boot sur ta clé USB

Il me semble que rpi à besoin de la carte SD pour démarrer.

@Sven: Peux-tu aussi donner le retour de /etc/fstab

cat /etc/fstab


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#6 17-10-2024 11:13:18

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Ouf ouf…. merci beaucoup pour vos réponses
Je démarre bien sur la carte SD et si je l’enlève : zéro, nada… pas de boot

commence par donner le retour de fdisk -l


Disk /dev/ram0: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram13: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram14: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram15: 4 MiB, 4194304 bytes, 8192 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/loop0: 59.77 MiB, 62676992 bytes, 122416 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop1: 3.3 MiB, 3461120 bytes, 6760 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/loop2: 33.71 MiB, 35344384 bytes, 69032 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mmcblk0: 119.25 GiB, 128043712512 bytes, 250085376 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x6a6abc39

Device         Boot  Start       End   Sectors  Size Id Type
/dev/mmcblk0p1        8192    532479    524288  256M  c W95 FAT32 (LBA)
/dev/mmcblk0p2      532480 250085375 249552896  119G 83 Linux


Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk model:  2.5 240GB
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 33553920 bytes
Disklabel type: gpt
Disk identifier: E667DB57-03E5-4D83-BEEE-46BAD1BA3064

Device     Start       End   Sectors   Size Type
/dev/sda1   2048 468860927 468858880 223.6G Microsoft basic data


Disk /dev/sdb: 119.51 GiB, 128320801792 bytes, 250626566 sectors
Disk model: Flash Drive FIT
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


~ $ cat /etc/fstab



proc            /proc           proc    defaults          0       0
PARTUUID=6a6abc39-01  /boot           vfat    defaults          0       2
PARTUUID=6a6abc39-02  /               ext4    defaults,noatime  0       1
# ajout du disque USB externe dans le dossier /usb/media
#UUID="15F2-445F" BLOCK_SIZE="512" TYPE="exfat" PARTUUID="c2281d86-e330-68c3-1cca-4d4d22d805c8"
#UUID=15F2-445F /usb/media exfat defaults,auto,rw,nofail,errors=remount-ro 0 1
UUID=15F2-445F    /home/doudou/usb/media               exfat    defaults,auto,rw,nofail,errors=remount-ro 0       1
UUID=4CE1-0294   /home/doudou/sdcard/media               exfat    defaults,auto,rw,nofail,errors=remount-ro 0       1
#UUID=4CE1-0294   /home/doudou/usb/media               exfat    defaults,auto,rw,nofail,errors=remount-ro 0       1
# a swapfile is not a swap partition, no line here
#   use  dphys-swapfile swap[on|off]  for that


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#7 17-10-2024 12:35:10

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

J'ai profité de cet incident pour faire ma veille Rpi (je ne dispose que de plusieurs Rpi 1/1B+ et 2B).

agp91 a écrit :

Il me semble que rpi à besoin de la carte SD pour démarrer.

... Depuis Rpi 3B/3B+, une Rpi peut démarrer sans sa carte SD.


Par contre,
Mauvaise nouvelle pour ta clé USB, il semblerait qu'il n'y est effectivement plus rien dessus.
Deux choix s'offrent à toi :

  • Tenter de restaurer la table des partition avec un outil à installer.

  • Utiliser rpi-clone pour cloner la carte SD vers la clé USB



La seconde solution est probablement la meilleure et la plus simple.

rpi-clone sdb

Devrait le faire.


Remarques :
La carte SD et la clé USB du même constructeur indiquant (sur le papier) avoir le même taille.
N'est pas le cas :

Sven a écrit :

fdisk -l

...
Disk /dev/mmcblk0: 119.25 GiB, 128043712512 bytes, 250085376 sectors
..
Disk /dev/sdb: 119.51 GiB, 128320801792 bytes, 250626566 sectors
...

La clé USB est d'environ 36Mo plus grande.

[edit]
Si tu fais le second choix et que tu as redémarrer depuis que tu as retourné la sortie de fdisk, contrôle que ta clé se nomme toujours sdb.

Dernière modification par agp91 (17-10-2024 12:43:46)


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#8 17-10-2024 13:36:09

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Bon. Il y a du neuf !
Après

rpi-clone sdb


et la réponse :

$ sudo rpi-clone sdb
Error: /dev/sdb: unrecognised disk label

Booted disk: mmcblk0 128.0GB               Destination disk: sdb 128.3GB
---------------------------------------------------------------------------
Part      Size    FS     Label           Part   Size  FS  Label
1 /boot   256.0M  fat32  --
2 root    119.0G  ext4   --
---------------------------------------------------------------------------
== Initialize: IMAGE partition table - partition number mismatch: 2 -> 0 ==
1 /boot               (30.0M used)   : MKFS  SYNC to sdb1
2 root                (1.9G used)    : RESIZE  MKFS  SYNC to sdb2
---------------------------------------------------------------------------
Run setup script       : no.
Verbose mode           : no.
-----------------------:
** WARNING **          : All destination disk sdb data will be overwritten!
-----------------------:

Initialize and clone to the destination disk sdb?  (yes/no): y
Optional destination ext type file system label (16 chars max):

Initializing
  Imaging past partition 1 start.
  => dd if=/dev/mmcblk0 of=/dev/sdb bs=1M count=8 ...
  Resizing destination disk last partition ...
    Resize success.
  Changing destination Disk ID ...Re-reading the partition table failed.: Device or resource busy

  => mkfs -t vfat -F 32  /dev/sdb1 ...
  => mkfs -t ext4  /dev/sdb2 ...

Syncing file systems (can take a long time)
Syncing mounted partitions:
  Mounting /dev/sdb2 on /mnt/clone
  => rsync // /mnt/clone with-root-excludes ...
  Mounting /dev/sdb1 on /mnt/clone/boot
  => rsync /boot/ /mnt/clone/boot  ...

Editing /mnt/clone/boot/cmdline.txt PARTUUID to use c9e7f686
Editing /mnt/clone/etc/fstab PARTUUID to use c9e7f686
===============================
Done with clone to /dev/sdb
   Start - 14:09:36    End - 14:11:19    Elapsed Time - 1:43

Cloned partitions are mounted on /mnt/clone for inspection or customizing.

Hit Enter when ready to unmount the /dev/sdb partitions ...
  unmounting /mnt/clone/boot
  unmounting /mnt/clone
===============================


après avoir redémarré je ne boote plus sur quoi que ce soit.

Par chance j’ai sur ma machine Windows ext2explore, qui comme son nom l’indique me permet de voir le contenu des partoches Linux.

Bref, j’ai accès à la carte Sd (/dev/si2) et à la clé USB (/dev/sh2) mais je ne peux rien en faire, ces fichiers n’étant pas éditables sous Windows (à ma connaissance).
Ce que je pige pas c’est qu’en dépit de message

Done with clone to /dev/sdb


sdb est devenu sh2.

Dernière modification par Sven (17-10-2024 13:38:34)


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#9 17-10-2024 13:43:49

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Ah ! J’oubliais : mon épouse a un vieux mac (un autre que moi donc) qui traîne.
Je peux peut-être remettre d’applomb la clé USB grâce à lui, non ?
Si oui, comment ?

Dernière modification par Sven (17-10-2024 13:44:25)


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#10 17-10-2024 16:59:16

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

Sven a écrit :

après avoir redémarré je ne boote plus sur quoi que ce soit..

Outch !
C'est une catastrophe cet outil...
Cela arrive apprès avoir suivit mes conseils ops.gif
old_geek.gif Cela m'apprendra à donner conseil pour utiliser un outil sorti de github.com mwahaha.gif


D'après la situation que tu d'écris, tu as une machine windows,
Le plus sage est d'utiliser une clé USB pour construire un système live GNU/Linux, pour booter avec (ton windows ne craint rien)
Ainsi, tu pourra explorer ta carte SD et ta clé USB et tenter d'amélioré les choses.

Sinon, est-ce qu'une réinstallation de Raspbian (si c'est le système que tu avais installé) sur ta carte SD n'est pas envisageable ?
Ainsi tu arai un système Rpi pour étudier/réparer ta clé USB.

Dernière modification par agp91 (17-10-2024 17:02:48)


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#11 17-10-2024 17:14:08

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : RPI-Clone : disparition de ma clé de boot après clonage

je crois que l'histoire quand on clone c'est que ça clone avec les même uiid
faudrait changé les uuid des partitions du clone et mettre a jour le fstab du clone ?
oui maintenant que tout est planté faut faire çà depuis un live usb
regarder ce que renvoie

blkid


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#12 17-10-2024 17:32:52

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

Croutons a écrit :

je crois que l'histoire quand on clone c'est que ça clone avec les même uiid

Je pense aussi.
Je suis étonné que l'outil ne gère pas cela.

Dernière modification par agp91 (17-10-2024 17:48:48)


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#13 17-10-2024 17:45:24

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

L'échec d'un premier usage (la raison de l'incident) aurait du me mettre la puce à l'oreille.
... Le retour de fdisk montrait qu'il avait vidé la clé USB de toutes partitions.
Et donc de ne pas conseiller de le réutiliser.

La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#14 17-10-2024 17:58:18

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : RPI-Clone : disparition de ma clé de boot après clonage

vaut mieux cloner avec un outil comme clonezilla

après avoir redémarré je ne boote plus sur quoi que ce soit.


et en branchant qu'un des 2 supports?
ça ne boot pas non plus?

Dernière modification par Croutons (17-10-2024 18:03:41)


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#15 18-10-2024 00:54:31

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

agp91 a écrit :

Croutons a écrit :

je crois que l'histoire quand on clone c'est que ça clone avec les même uiid
faudrait changé les uuid des partitions du clone et mettre a jour le fstab du clone ?

Je pense aussi.
Je suis étonné que l'outil ne gère pas cela.

Pourtant, j'ai regardé dans le script et dans le retour de son exécution
... Il semble géré la modification de PARTUUID dans les  2 fichiers nécessaires :

  • /boot/cmdline.txt

  • Et /etc/fstab

rpi-clone a écrit :

# Fix PARTUUID or device name references in cmdline.txt and fstab
#
fstab=${clone}/etc/fstab
cmdline_txt=${clone}/boot/cmdline.txt

if [ -f $cmdline_txt ]
then
  ...
  if grep -q $src_disk_ID $cmdline_txt
  then
    qecho "Editing $cmdline_txt PARTUUID to use $dst_disk_ID"
    sed -i "s/${src_disk_ID}/${dst_disk_ID}/" "$cmdline_txt"
  ...
if grep -q $src_disk_ID $fstab
then
  qecho "Editing $fstab PARTUUID to use $dst_disk_ID"
  sed -i "s/${src_disk_ID}/${dst_disk_ID}/g" "$fstab"
...



Avant l'usage de rpi-clone (src_disk_ID=6a6abc39) :

Sven a écrit :

cat /etc/fstab

...
PARTUUID=6a6abc39-01  /boot           vfat    defaults          0       2
PARTUUID=6a6abc39-02  /               ext4    defaults,noatime  0       1
...

Retour de l'usage (dst_disk_ID=c9e7f686) :

Sven a écrit :

rpi-clone sdb

...
Editing /mnt/clone/boot/cmdline.txt PARTUUID to use c9e7f686
Editing /mnt/clone/etc/fstab PARTUUID to use c9e7f686
...

Dernière modification par agp91 (18-10-2024 01:28:29)


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#16 18-10-2024 07:59:05

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : RPI-Clone : disparition de ma clé de boot après clonage

agp91 a écrit :

Pourtant, j'ai regardé dans le script et dans le retour de son exécution
... Il semble géré la modification de PARTUUID dans les  2 fichiers nécessaires :

    /boot/cmdline.txt

    Et /etc/fstab



c'est bien ce qui me semblait voir dans le suivis des opérations
mais je ne parlais pas de cela , je voulais dire changer l'UUID des partitions, mettre à jour les fichier correspondant

tune2fs /dev/sdb(1 et 2) -U "nouvelleUUID"

Dernière modification par Croutons (18-10-2024 08:00:19)


-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#17 18-10-2024 08:05:03

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Hello hello
c’est infernal rpi-clone, non ?
bon je vais repartir de zéro en installant de nouveau le RPI OS legacy 64bits.
Et tout de suite après je vais installer "micro" Editor parce que nano c’est vraiment pas mon truc.

Après comme

Croutons a écrit :

vaut mieux cloner avec un outil comme clonezilla

je vais tenter le coup du clonage avec ça.

Comme ça je vais repartir sur de bonnes bases.
Merci du support les gars.


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#18 18-10-2024 11:15:24

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Décidément quand ça veut pas !

Je me suis réinstallé l’OS sur ma clé USB.
Pas de problème ?
Si !!
Si j’insère la carte SD (reformaté en ExFat) dans le slot je ne peux plus booter !
Il n’y a rien dessus.
Je l’ai reformaté 2 fois et vérifié avec ValiDrive : il n’y a pas d’erreur.
Qu’est-ce qui se passe ? Je deviens dingue ?

RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#19 18-10-2024 12:38:16

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Je résume le truc :
- la carte est vierge
- insérée au démarrage elle empêche le boot. Et en + la RPI s’éteint d’elle même au bout de quelques instants.
- insérez après le boot elle est reconnue. Je viens même de la déclarer dans fstab. Donc pas de souci de lecture.

Je sais plus : un souci matériel ? Un truc que je vois pas ?

RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#20 18-10-2024 14:21:57

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : RPI-Clone : disparition de ma clé de boot après clonage

au niveau des UUId ça donne quoi? cle usd et carte SD ça donne quoi?

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#21 18-10-2024 21:24:31

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

Sven a écrit :

c’est infernal rpi-clone, non ?

C'est pire que cela,
Jusqu'à son nom est mensonge.
Il berne tout le monde et tout ceux qui ont écrit un tuto sur lui.
Ce n'est en rien un outil de clonage, il ne réalise pas de clone.

Un clone est un clone ! C'est l'identique de l'original.
Lorsqu'on clone un disque, l'intégralité du disque source est copié dans dans le disque de destination (MBR/PMBR compris).
Si la destination est un fichier, le fichier obtenu est nommée image.
Un clone peut aussi être obtenu par : Disque source > image disque > disque de destination .
Nous pouvons aussi cloner une partition dans une autre partition (ou en réaliser une image).

Il est plus sage de ne pas cloner un disque ou une partition lorsqu'il/elle est utilisée. Afin de ne pas obtenir un clone corrompu au cas où le contenu est changé durant le clonage.
-> On ne  clone pas un disque qui contient un système en court d'usage sans risque !
(en) Disk cloning > Drive in use (wikipedia)

C'est pour cela que Clonezilla qui est un cloneur, est un liveUSB qui permet de booter dessus, afin de réaliser clones et images.
Un clone, peut être aussi réalisé manuellement avec la commande dd. Exemple pour cloner le disque sdb ver sdd

dd if=/dev/sdb of=/dev/sdd

ou

dd if=/dev/sdb of=/chemin/fichier_image
dd if=/chemin/fichier_image of=/dev/sdd



Cela me tracassais, que rpi-clone propose de cloner le disque système (en court d'usage) vers un autre disque.
Alors j'ai lu le script et la doc (après traduction).

billw2 a écrit :

Clone by initialization
An initialization clone starts by imaging the source disk partition table to the destination disk This is is a convenience that gets the destination disk partitioned so you can avoid manual partitioning. Partitions are then cloned by making destination file systems matching the source file system types followed by file system syncs to the destinations. Initialization clones are used when the source file system types or number of partitions do not match the destination.

Traduction :
Cloner par initialisation
Un clone d'initialisation commence en créant une image de la table de partition du disque source sur le disque de destination. Il s’agit d’une commodité qui permet de partitionner le disque de destination afin d'éviter le partitionnement manuel. Les partitions sont ensuite clonées en créant des systèmes de fichiers de destination correspondant au type de système de fichiers source, suivis de la synchronisation des systèmes de fichiers de destination.

Il est remarquable qu'ici soit réalisé une image sans fichier.
Qu'une partition soit clonée en la formatant et en remplissant de son contenu par copie de la source.
Ce sont des aberrations de langage (un mauvais usage de la terminologie).

Après lecture du script, rpi-clone utilise rsync pour copier le contenu des partions qu'il a formaté avec mkfs.
Si une partition de swap existe, mkswap est utilisé sur la partition du disque de destination.
Toute fois, il est remarquable que s'il existe des partions non montées sur le disque source, elle sont clonées avec dd dans le disque de destination.
De plus rpi-clone (qui devrait être nommé rpi-sync) peut modifier la taille des partitions, afin de les adapter au disque de destination (s'il est plus petit ou plus grand que le disque source).

... Nous pouvons donc vraiment pas parler de clonage !

Rappel :

  • UUID : Est un identifiant unique, basé sur le système de fichier. L'UUID d'une partition change à chaque fois qu'elle est formatée.

  • PARTUUID : Est un identifiant utilisé par les disques utilisant GPT, ils identifient les partitions dans la table des partions.  Les PARTUUID ne changent pas à chaque formatage.

Le noyau crée des PARTUUID "synthétiques" pour permettre aux disques disposant d'un partitionnement de type DOS d'en disposer.
Ils sont alors créés avec l'ID du disque (différents pour chaque disque) suivit du numéro de la partition.

Avec un disque cloné, pas de problème d'UUID, ni de PARTUUID si le partitionnement du disque est de type GPT.
Avec un partitionnent de type DOS, les PARTUUID du disque changent (puisque constitué de l'ID disque, différent pour chaque disque).

Du coups, avec rpi-clone, en plus de perdre leur PARTUUID (par défaut, Raspbian utilise un partitionnent de type DOS), les partitions système perdent aussi leurs UUID.


Et haha, comme nous l'a montré cet incident, il ne fait pas le taf !
Ce truc est donc à oublié !
old_geek.gif Non, il n'est pas à oublier, il faut ce souvenir de ne pas l'utiliser.

Dernière modification par agp91 (19-10-2024 00:20:06)


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#22 18-10-2024 23:58:30

agp91
Membre
Distrib. : GNU Debian stable
(G)UI : xfce
Inscription : 12-02-2023

Re : RPI-Clone : disparition de ma clé de boot après clonage

Sven a écrit :

Décidément quand ça veut pas !

Je me suis réinstallé l’OS sur ma clé USB.
Pas de problème ?
Si !!
Si j’insère la carte SD (reformaté en ExFat) dans le slot je ne peux plus booter !
Il n’y a rien dessus.
Je l’ai reformaté 2 fois et vérifié avec ValiDrive : il n’y a pas d’erreur.
Qu’est-ce qui se passe ? Je deviens dingue ?

Sven a écrit :

Je résume le truc :
- la carte est vierge
- insérée au démarrage elle empêche le boot. Et en + la RPI s’éteint d’elle même au bout de quelques instants.
- insérez après le boot elle est reconnue. Je viens même de la déclarer dans fstab. Donc pas de souci de lecture.

Je sais plus : un souci matériel ? Un truc que je vois pas ?


Ce qui suis est pour moi de la théorie (de la lecture) car je ne possède pas de Rpi supérieur 2B.

Par défaut ton Rpi4 semble etre configuré pour démarrer sur la carte SD, si elle n'est pas trouvée il boot sur l'USB

framboise314.fr a écrit :

La commande vcgencmd bootloader_config affiche les options de boot dont vous trouverez la description en détail sur la page du blog. Le résultat (avec le boot USB activé) est celui-ci :

[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
BOOT_ORDER=0xf41

L’ordre de boot : BOOT_ORDER contient par 0xf41  (c’est en hexadécimal)  et indique que le boot commence par la carte SD puis passe au port USB si la carte n’est pas trouvée.

BOOT_ORDER
Voici les autres codes : La propriété BOOT_ORDER définit la séquence pour les différents modes de démarrage. Jusqu’à 8 chiffres peuvent être définis dans la séquence de boot.

0x0 – NONE (arrêt avec motif d’erreur)
0x1 – CARTE SD
0x2 – RÉSEAU
0x3 – USB device boot usbboot – Module CMx uniquement.
0x4 – Démarrage sur stockage de masse USB
0xf – RESTART (boucle) – recommencer avec le premier champ dans l’ordre de démarrage.

On lit de droite à gauche. Ici on a f41 => Boot Carte SD, si pas de carte SD Boot sur USB si pas d’USB on recommence au début (f).

Si on avait 0xf21 => SD carte – Si absente : Démarrage réseau (Boot PXE) puis (c’est ce qu’il y a par défaut actuellement)

Source : (fr) Boot du Raspberry Pi 4 sur un disque SSD en USB3 (framboise314.fr)

Si je comprend bien pour booter uniquement sur  USB, il te faudrait un BOOT_ORDER à 0xf4.
Que dit la commande

vcgencmd bootloader_config

?
Pour changer le BOOT_ODER le plus simple doit être de passer par

raspi-config

Puis : 6 Advanced Options > A6 Boot Order
Mais il te faut un bootloader à jour (ce qui devrait être le cas si ton Rpi est récent)

(en) Raspberry Pi boot EEPROM (raspberrypi.com)
(en) Boot diagnostics on the Raspberry Pi 4 (raspberrypi.com)
(en) Raspberry Pi bootloader configuration (raspberrypi.com)
(fr) Démarrer Raspberry Pi 4 et 5 depuis disque dur, SSD, clé usb (antoinelounis.com)

Dernière modification par agp91 (19-10-2024 00:00:51)


La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.

Hors ligne

#23 19-10-2024 07:24:03

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Ouha la la ! Quelle histoire !

vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0


sudo blkid
/dev/sda1: LABEL="WDGreen" UUID="141A-3492" BLOCK_SIZE="512" TYPE="exfat" PARTUUID="c2281d86-e330-68c3-1cca-4d4d22d805c8"
/dev/sdb1: LABEL_FATBOOT="bootfs" LABEL="bootfs" UUID="95B8-58CA" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="47e90d30-01"
/dev/sdb2: LABEL="rootfs" UUID="806b710e-cfd3-408c-a27c-5128465dc18f" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="47e90d30-02"
/dev/mmcblk0p5: LABEL="SDCard" UUID="04BC-7C58" BLOCK_SIZE="512" TYPE="exfat" PARTUUID="6a6abc39-05"


ls -l /dev/disk/by*
/dev/disk/by-id:
total 0
lrwxrwxrwx 1 root root  9 Oct 19 08:10 ata-WD_Green_2.5_240GB_223901A0127A -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 19 08:10 ata-WD_Green_2.5_240GB_223901A0127A-part1 -> ../../sda1
lrwxrwxrwx 1 root root 13 Oct 19 08:17 mmc-ED4QT_0xe41d57c5 -> ../../mmcblk0
lrwxrwxrwx 1 root root 15 Oct 19 08:17 mmc-ED4QT_0xe41d57c5-part1 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Oct 19 08:17 mmc-ED4QT_0xe41d57c5-part5 -> ../../mmcblk0p5
lrwxrwxrwx 1 root root  9 Oct 19 08:10 usb-Samsung_Flash_Drive_FIT_0376218120006373-0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 Oct 19 08:10 usb-Samsung_Flash_Drive_FIT_0376218120006373-0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 19 08:10 usb-Samsung_Flash_Drive_FIT_0376218120006373-0:0-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 Oct 19 08:10 usb-WD_Green_2.5_240GB_012345678999-0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 19 08:10 usb-WD_Green_2.5_240GB_012345678999-0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root  9 Oct 19 08:10 wwn-0x5001b448bdb1d7b8 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 19 08:10 wwn-0x5001b448bdb1d7b8-part1 -> ../../sda1

/dev/disk/by-label:
total 0
lrwxrwxrwx 1 root root 10 Oct 19 08:10 bootfs -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 19 08:10 rootfs -> ../../sdb2
lrwxrwxrwx 1 root root 15 Oct 19 08:17 SDCard -> ../../mmcblk0p5
lrwxrwxrwx 1 root root 10 Oct 19 08:10 WDGreen -> ../../sda1

/dev/disk/by-partuuid:
total 0
lrwxrwxrwx 1 root root 10 Oct 19 08:10 47e90d30-01 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 19 08:10 47e90d30-02 -> ../../sdb2
lrwxrwxrwx 1 root root 15 Oct 19 08:17 6a6abc39-01 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Oct 19 08:17 6a6abc39-05 -> ../../mmcblk0p5
lrwxrwxrwx 1 root root 10 Oct 19 08:10 c2281d86-e330-68c3-1cca-4d4d22d805c8 -> ../../sda1

/dev/disk/by-path:
total 0
lrwxrwxrwx 1 root root  9 Oct 19 08:10 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1:1.0-scsi-0:0:0:0 -> ../../sdb
lrwxrwxrwx 1 root root 10 Oct 19 08:10 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1:1.0-scsi-0:0:0:0-part1 -> ../../sdb1
lrwxrwxrwx 1 root root 10 Oct 19 08:10 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:1:1.0-scsi-0:0:0:0-part2 -> ../../sdb2
lrwxrwxrwx 1 root root  9 Oct 19 08:10 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0 -> ../../sda
lrwxrwxrwx 1 root root 10 Oct 19 08:10 platform-fd500000.pcie-pci-0000:01:00.0-usb-0:2:1.0-scsi-0:0:0:0-part1 -> ../../sda1
lrwxrwxrwx 1 root root 13 Oct 19 08:17 platform-fe340000.mmc -> ../../mmcblk0
lrwxrwxrwx 1 root root 15 Oct 19 08:17 platform-fe340000.mmc-part1 -> ../../mmcblk0p1
lrwxrwxrwx 1 root root 15 Oct 19 08:17 platform-fe340000.mmc-part5 -> ../../mmcblk0p5

/dev/disk/by-uuid:
total 0
lrwxrwxrwx 1 root root 15 Oct 19 08:17 04BC-7C58 -> ../../mmcblk0p5
lrwxrwxrwx 1 root root 10 Oct 19 08:10 141A-3492 -> ../../sda1
lrwxrwxrwx 1 root root 10 Oct 19 08:10 806b710e-cfd3-408c-a27c-5128465dc18f -> ../../sdb2
lrwxrwxrwx 1 root root 10 Oct 19 08:10 95B8-58CA -> ../../sdb1


Une anomalie quelque part ?


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

#24 19-10-2024 07:42:56

Croutons
Membre
Distrib. : Debian12
Noyau : Linux 6.1.0-13-amd64
(G)UI : Fluxbox(NakeDeb)
Inscription : 16-12-2016

Re : RPI-Clone : disparition de ma clé de boot après clonage

tu n'as pas d'option BOOT_ORDER=0xf41, je sais pas si on peut le rajouter voir ce que cela donne

-->les cahiers du debutant<--      WikiDF-->Découvrir les principales commandes Linux<-- 
L' expérience, c'est le nom que chacun donne à ses erreurs. Oscar Wilde

En ligne

#25 19-10-2024 07:56:15

Sven
Membre
Inscription : 16-10-2024

Re : RPI-Clone : disparition de ma clé de boot après clonage

Je l’ai :

$ vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0

[all]
BOOT_ORDER=0xf14


Je redémarre et… (roulements de tambour)
ça plante !
EDIT : il a l’air bizarre ce config non ?
Il y a 2 [All]

Dernière modification par Sven (19-10-2024 07:58:20)


RPI IV 8 Gb avec :
- une clé USB3 de Samsung de 128Gb sur laquelle il boote
- une SDCard du même constructeur et de la même taille
- un disque USB3 de WD de 240Gb

Hors ligne

Pied de page des forums