Vous n'êtes pas identifié(e).
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
...
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
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
Hors ligne
-->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
...
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 mmcblk0Cependant, 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
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.
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
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
Hors ligne
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
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
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.
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 :
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
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
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
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
Cela m'apprendra à donner conseil pour utiliser un outil sorti de github.com
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
-->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
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
La liberté est gratuite et accessible à tous. Sinon ça n'en est pas.
Hors ligne
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
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
# 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) :
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) :
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
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
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
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
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
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
-->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
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
ou
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).
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é !
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
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 ?
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
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=0xf41L’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
?
Pour changer le BOOT_ODER le plus simple doit être de passer par
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
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
-->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
$ 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