Debian
Debian-France
Debian-Facile
Debian-fr.org
Forum-Debian.fr
Debian ?
Communautés
Vous n'êtes pas identifié(e).
Pages : 1
sda est mon SSD principal
sdb est un disque HDD de stockage
sdc est le SSD cloné
Où dois-je installer ce grub pour ce SSD cloné ?
Dernière modification par totoZero7 (24-09-2022 20:13:11)
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par totoZero7 (24-09-2022 18:13:39)
Hors ligne
Dernière modification par raleur (24-09-2022 18:22:57)
Il vaut mieux montrer que raconter.
Hors ligne
ça veut dire quoi ?
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Bon, ici debconf montre que /dev/sdc1 est monté sur /boot donc on peut en déduire facilement que le disque à sélectionner est /dev/sdc (SURTOUT PAS /dev/sdc1).
Et ben c'est exactement la bêtise que j'allais faire (cliquer sur sur /dev/sdc1) si je n'avais pas eu de réponse ! car je la trouvais logique dans ma tête. Tu faix bien de le mentionner.
Et j'ai bien fait de poster un message ici. Merci raleur ! again !
Avec ce post, j'ai appris qu'on pouvait ouvrir une deuxième fenêtre de chroot.
Dans mon cas la commande est
J'apprends aussi qu'accumuler des noyaux (installés ou non ?) peuvent poser problème. Heureusement que c'est sur un disque secondaire en chroot sur lequel je le découvre pour ne pas me faire bloquer au démarrage de mon pc principal.
Dans mon cas, j'avais seulement mis 2 noyaux passés en installation manuelle (dans le clone) mais j'ai la même chose sur mon SSD principal sur lequel je n'ai pas eu ce message d'erreur.
La seul différence que je vois pour l'instant, c'est la commande apt autoremove que j'effectue sur le SSD principal et non sur le clone (je pense car je note pas tout !).
Donc faire des apt autoremove ça sert aussi à ne pas se faire saturer en espace dans le système d'amorçage qui fait ~500Mo comme dans cette situation ? c'est exacte ?
ou c'est juste les noyaux installés, qui se logent dans cette partition, qui saturent l'espace ? (je fais mes réglages de nettoyage ou d'ajout système/noyau différemment entre le principal et le clone... il y a donc des nuances entres les deux...)
Ma question est trouble comme ma vision du schmilblick,
Je reformule, qu'est-ce qui s'accumule exactement dans cette partition d'amorçage, importante, qui est bloquée à ~500Mo ? J'aimerais comprendre si ce sont mes 2 noyaux sauvegardés manuellement qui ont joués sur cet état ou si c'est autre chose.
En passant, je mets en résolu avec un grand merci.
Hors ligne
Hors ligne
qu'est-ce qui s'accumule exactement dans cette partition d'amorçage, importante, qui est bloquée à ~500Mo ?
GRUB et les noyaux installés. GRUB occupe environ 15 Mo et chaque noyau occupe quelques dizaines de Mo. C'est l'initramfs qui occupe le plus d'espace, sa taille est variable en fonction des paquets installés et des options de configuration d'initramfs-tools. Lors d'une mise à jour Il faut suffisamment d'espace libre pour installer les nouveaux fichiers avant de supprimer les anciens. Donc on peut dire grosso modo que pour contenir N noyaux il faut une taille au moins égale à 4 fois la taille occupée par un noyau.
J'aimerais comprendre si ce sont mes 2 noyaux sauvegardés manuellement qui ont joués sur cet état
Qu'entends-tu par "sauvegardés manuellement" ?
Qu'est-ce qui a fait sonner l'alerte sur l'emplacement du grub sur ce SSD cloné avec comme intuition de debian: un changement "d'identification unique" comme le dit le message ?
Lors d'une mise à jour du paquet grub-pc,le script de configuration vérifie si l'identifiant /dev/disk/by-id/xxx du périphérique ou GRUB a été installé enregistré dans debconf exist. Si oui, le chargeur d'amorçage est automatiquement réinstallé dans cet emplacement. Sinon, il affiche cet écran.
Il vaut mieux montrer que raconter.
Hors ligne
j'ai changé tous les UUID correctement y compris dans le grub, après avoir cloné le SSD
Qu'entends-tu par "dans le grub" ? Tu as exécuté "dpkg-reconfigure grub-pc" ?
Il vaut mieux montrer que raconter.
Hors ligne
totoZero7 a écrit :J'aimerais comprendre si ce sont mes 2 noyaux sauvegardés manuellement qui ont joués sur cet état
Qu'entends-tu par "sauvegardés manuellement" ?
J'entends la modification du statut qui est en automatique par defaut et le passer en manuel pour qu'il reste installé:
apt-mark manual linux-image-Numero-du-noyau-xx-amd64
totoZero7 a écrit :j'ai changé tous les UUID correctement y compris dans le grub, après avoir cloné le SSD
Qu'entends-tu par "dans le grub" ? Tu as exécuté "dpkg-reconfigure grub-pc" ?
- Oui je l'avait fait.
C'était d'ailleurs la dernière étape à faire, dans les conseils donnés lors du changement des UUID dans l'opération de clonage de SSD.
Et je viens de verifier dans l'historique des commandes du SSD cloné, j'ai bien effectué "dpkg-reconfigure grub-pc" *.
Je remarque aussi qu'on a eu cette discussion sur le même problème avec c'est écran bleu ! Mais je n'ai pas spécifié dans mon commentaire ce que j'avais choisi comme disque.
Lors d'une mise à jour du paquet grub-pc,le script de configuration vérifie si l'identifiant /dev/disk/by-id/xxx du périphérique ou GRUB a été installé enregistré dans debconf exist. Si oui, le chargeur d'amorçage est automatiquement réinstallé dans cet emplacement. Sinon, il affiche cet écran
C'est l'id le probleme !
Toujours dans la même discussion mais plus bas ici
ça parle du problème d'id du SSD clone qui était le même que l'original et qu'il fallait modifier.
(discussion clone SSD)
totoZero7 a écrit :
J'ai ensuite regardé de quoi avait l'air l'identifiant et il se trouve que c'est l'identifiant du cable USB (provisoire donc) qui connecte le SSD au PC
- Est-ce que cela va provoquer des problèmes si il reste ainsi avec cet identifiant ?
Pas tant que le SSD reste connecté de cette façon. Par contre cela peut si grub-pc est mis à jour alors que le SSD est connecté autrement, surtout si un autre disque est connecté via cet adaptateur USB (cela installera l'amorce de GRUB dans le MBR de ce disque).
Dans mes étapes qui ont suivies: j'ai donc branché le SSD directement à la tour en SATA, pour qu'il ait l'id du SSD et non du cable USB, afin de ne pas créer de problème.
Sauf que depuis, (petit oiseau dans ma tête) je fais systématiquement mes mises à jour système en chroot par le cable USB !
Aujourd'hui (enfin hier), j'ai fait la mise à jour du système (qui inclus une nouvelle version de grub ?) avec le cable USB.
C'est probablement cela qui a mis le bazar ?
Si j'execute "debconf-show grub-pc" j'obtiens l'id du cable USB et non du SSD.
Est-ce que ça veut dire, qu'hier j'ai changé l'emplacement du grub et que si je veux lancer mon système clone en le branchant en SATA sur la tour, je vais avoir des problèmes ?
(j'ai pas testé)
Du coup, cela signifie que je ne peux pas faire toutes les mises à jour du clone en chroot par le cable usb, c'est bien ça ?
Hors ligne
apt-mark manual linux-image-Numero-du-noyau-xx-amd64
Avec deux anciens noyaux marqués en manuel et les deux derniers noyaux en automatique, même après autoremove il peut en rester quatre, donc un peu limite dans 500 Mo.
Dans mes étapes qui ont suivies: j'ai donc branché le SSD directement à la tour en SATA, pour qu'il ait l'id du SSD et non du cable USB, afin de ne pas créer de problème.
Sauf que depuis, (petit oiseau dans ma tête) je fais systématiquement mes mises à jour système en chroot par le cable USB !
Donc je suppose que l'identifiant de disque est différent, d'où la question posée à nouveau lors de la mise à jour.
Aujourd'hui (enfin hier), j'ai fait la mise à jour du système (qui inclus une nouvelle version de grub ?)
Effectivement il y a eu une mise à jour de grub2 lors de la récente révision 11.5, puis une autre dans bullseye-updates pour corriger un bug avec Xen.
Est-ce que ça veut dire, qu'hier j'ai changé l'emplacement du grub et que si je veux lancer mon système clone en le branchant en SATA sur la tour, je vais avoir des problèmes ?
Non, l'emplacement effectif n'a pas changé. Tu as seulement changé l'identifiant de disque enregistré dans debconf qui sera utilisé lors de la prochaine mise à jour de grub2. Au pire la question sera à nouveau posée si le disque est branché en SATA lors de cette mise à jour.
Il vaut mieux montrer que raconter.
Hors ligne
Dernière modification par totoZero7 (26-09-2022 22:16:09)
Hors ligne
Dans une debian en VM, j'ai mis 6 noyaux en "manuel" et je n'ai aucun problème.
Avec une partition /boot séparée de 500 Mo et le reste en LVM chiffré (ce qui alourdit l'initramfs) ?
ça serait le fichier 'initramfs-tools' qui serait la cause du manque d'espace dans mon SSD cloné du coup ?
Initramfs-tools est le programme qui génère l'initramfs, le fichier /boot/initrd.img-<version-variante> pour chaque noyau installé. Selon ses options de configuration (MODULES, BUSYBOX, COMPRESS...) et les paquets installés (lvm2, cryptsetup-initramfs, mdadm, ntfs-3g, plymouth, firmwares...) l'initramfs généré est plus ou moins volumineux. Avec les options standard la taille est de l'ordre de 50 Mo pour un noyau amd64. L'image do noyau lui-même (vmlinuz-<version>-<variante>) est beaucoup moins volumineuse (~6 Mo).
Est-ce que cet identifiant "/dev/disk/by-id/xxx" sert à autre chose ou à un autre logiciel que GRUB ? (sous-entendu, qui pourrait me jouer un tour à force de jouer à lancer le système soit en SATA soit via un cable USB)
Pas à ma connaissance, sauf si tu l'as utilisé toi-même par exemple pour identifier un système de fichiers ou swap dans /etc/fstab ou /etc/initramfs-tools/conf.d/resume ou un volume chiffré dans /etc/crypttab, ou bien pour identifier un disque dans une règle udev ou /etc/hdparm.conf.
Dernière modification par raleur (27-09-2022 22:04:58)
Il vaut mieux montrer que raconter.
Hors ligne
Avec une partition /boot séparée de 500 Mo et le reste en LVM chiffré (ce qui alourdit l'initramfs) ?
Bien vu. C'est une installation simple tout dans la même partition et non chiffré. C'est donc pour cela que je peux acculer autant de noyaux que je veux dans cette machine.
raleur trop fort.
Pas à ma connaissance, sauf si tu l'as utilisé toi-même par exemple pour identifier un système de fichiers ou swap dans /etc/fstab ou /etc/initramfs-tools/conf.d/resume ou un volume chiffré dans /etc/crypttab, ou bien pour identifier un disque dans une règle udev ou /etc/hdparm.conf.
J'utilise l'UUID dans le fstab pour ouvrir un autre disque chiffré. Donc pas de problème.
Le numéro UUID ne change pas, sauf si on lui attribue volontairement un autre numéro. Quelle serait la plus value d'identifier par "dev/disk/by-id/xxx" par rapport un UUID ?
Hors ligne
raleur trop fort.
Simple raisonnement.
Le numéro UUID ne change pas, sauf si on lui attribue volontairement un autre numéro.
Pas toujours si volontairement. Par exemple le swap utilisé par un système reformaté lors de l'installation d'un autre système à côté. L'installateur Debian est coutumier du fait.
Quelle serait la plus value d'identifier par "dev/disk/by-id/xxx" par rapport un UUID ?
Quelques exemples :
- pour ne pas être impacté justement quand l'UUID change suite à un reformatage intempestif (cas du swap ci-dessus)
- quand le contenu n'a pas d'UUID, comme par exemple le chiffrement "plain dm-crypt" (sans en-tête LUKS) ; dans le cas d'une partition on peut aussi utiliser le PARTUUID ou PARTLABEL à la place
- pour ne pas être impacté par des collisions d'UUID avec un clone
Dernière modification par raleur (27-09-2022 23:20:23)
Il vaut mieux montrer que raconter.
Hors ligne
- quand le contenu n'a pas d'UUID, comme par exemple le chiffrement "plain dm-crypt" (sans en-tête LUKS)
C'est pour ça que je n'arrive pas à supprimer l'en-tête d'un système, parce-qu'il n'y en pas ! (Je découvre ça).
(je m'écarte du sujet Grub mais tu laches une infos que je cherche depuis des années).
Habituellement, pour aller vite, je supprime l'en-tête d'un container chiffré, ce qui m'évite de shred tout le disque (gros gain de temps). Mais ça ne fonctionne pas avec un système chiffré, ce qui est très agaçant car le système prend tout le disque (qui est généralement bien gros) et c'est méga long à supprimer, surtout si on veut faire plusieurs passes...
Du coup, dans le cadre de supprimer facilement ce qui pourrait ressembler à l'en-tête d'un container mais pour un système, est-ce qu'il y a une technique genre supprimer le dev/disk/by-id avec shred ?
Hors ligne
C'est pour ça que je n'arrive pas à supprimer l'en-tête d'un système, parce-qu'il n'y en pas !
Je doute qu'un système soit installé dans un volume chiffré "plain dm-crypt" (non LUKS). L'installateur Debian supporte "plain dm-crypt" seulement avec une clé aléatoire pour les volumes à usage temporaire comme le swap ou /tmp.
Comment effaces-tu l'en-tête LUKS d'un conteneur chiffré habituellement ? Pas besoin de passer shred sur tout le disque, au pire l'écrasement du début du conteneur sur 2 Mo (là où se trouve l'en-tête LUKS) devrait suffire.
Il vaut mieux montrer que raconter.
Hors ligne
Repérer la ligne : Payload offset: et noter le chiffre (taille de l’en-tête)
ensuite écraser uniquement l’en-tête LUKS (gain de temps)
en tapant la commande qui suit. (Remplacé Offset par la taille de l'en tete)
Une fois fait, vérifier que c'est bien effacé avec la commande :
Hors ligne
Il vaut mieux montrer que raconter.
Hors ligne
Et voici la commande sur un système
Il y a une ligne qui ressemble à 'Payload offset' car c'est marqué 'offset'. Mais le chiffre qui suit est énorme comparé à celui du container.
offset: 16777216 [bytes]
Je ne me souviens plus si j'avais néanmoins testé ou non avec ce chiffre énorme dans la méthode (prise je ne sais où sur le net il y a très longtemps).
Je n'ai pas de note à ce sujet.
J'ai juste indiqué que ma méthode ne fonctionnait pas avec un système et que je ne trouvais pas la ligne 'Payload offset'.
Qu'est-ce qui cloche dans ma méthode avec le système du coup ?
Quelle est la manipulation avec dd pour écrire avec des zéros sur les 2 premiers Mo, soit sur un système, soit sur un container, si il y a une différence entre les deux ?
Dernière modification par totoZero7 (30-09-2022 00:08:46)
Hors ligne
Il y a une ligne qui ressemble à 'Payload offset' car c'est marqué 'offset'. Mais le chiffre qui suit est énorme comparé à celui du container.
offset: 16777216 [bytes]
Il est exprimé en octets alors que l'offset de l'en-tête LUKS1 est exprimé en blocs de 512 octets.
Quelle est la manipulation avec dd pour écrire avec des zéros sur les 2 premiers Mo,
Il vaut mieux montrer que raconter.
Hors ligne
Pages : 1