Vous n'êtes pas identifié(e).
et
Si je clique sur 'Exécuter', la barre de tâches et le dock se lancent et je peux les modifier sans difficulté, donc juste ces deux fenêtres au démarrage.
En cherchant un peu, j'ai lu que certains conseillent de créer un profil (session) supplémentaire ; j'ai créé un profil 'temp' qui ne pose aucun de ces soucis.
Je n'ai pas fait grand chose lors de la première session : j'ai débranché le câble ethernet pour tourner en Wi-Fi (firmware non-free fourni lors de l'installation) et désactivé les mises en veille et extinction d'écran automatiques (je gère tout ça manuellement).
Des idées sur l'origine possible du problème ?
Édit : Résolu ! Il suffisait apparemment de supprimer le contenu de .cache/sessions du dossier personnel.
Ajout de ce post vers le wiki de fsck :
https://debian-facile.org/doc:systeme:f … de-donnees
Bonjour,
Je me permets de faire remonter ce sujet à propos de la page Wiki de fsck. J'ai eu à m'en servir récemment (voir ce message : https://debian-facile.org/viewtopic.php … 01#p337401 ) et il faudrait modifier le paragraphe "Au démarrage". La méthode consistant à créer un fichier forcefsck à la racine du disque n'est plus applicable depuis l'introduction de systemd dans Debian.
J'ai la même carte graphique
Argument de poids
apt install firmware-linux-nonfree
Dans ce cas, il faudrait vérifier que /etc/apt/sources.list contienne bien non-free, non ? Edit: zut, tu as édité juste à temps
suivi de
J'aurai au moins appris que Clonezilla contient nano ; j'obtiens la même chose avec un cat /var/log/partclone.log
Ça a l'air clean (j'ai eu une coupure de courant cette semaine et il a lancé un fsck au démarrage sur sdb6, clean aussi).
Que dit le log ?
Je n'ai pas pensé à le relever / consulter, je ne sais pas comment faire. Il va falloir que je recommence je pense mais je ne pourrai pas avant la fin de semaine. C'est sous forme de LiveCD (qui s'éjecte une fois que l'image système est chargée en mémoire), donc je me doute que le fichier n'est disponible que temporairement en RAM.
Les partitions sont bien démontées ?
Il me semble que Clonezilla le fait entre le moment où il détecte les partitions existantes et où il lance les outils de sauvegarde (partclone dans le cas présent) mais je n'irais pas le jurer.
Tu as essayé fsck dessus ?
C'est le genre de choses qui ne vient pas spontanément à l'esprit du +/- débutant que je suis : si ça remarche, ne touche à rien. Donc non, je n'ai pas lancé de fsck sur le SSD (Windows a lancé un CHKDSK à son premier redémarrage, ça semble s'être bien déroulé).
Je pense que les tailles et offsets sont exprimés en octets.
Pour Clonezilla, voici ce que j'ai fait :
Que voulez-vous faire ? –> device <–> image
image à créer sur disque 2To (dans un répertoire)
sélection du périphérique source : SSD 250 Go
mode débutant
ne pas vérifier / réparer le système de fichiers
vérifier l'image disque
Je ne lui demande pas de réparer le système de fichiers pour ne rien modifier au disque, je préfère une méthode manuelle avec quelqu'un qui sait ce qu'il fait plutôt que de l'automatique.
Voici ce qu'il retourne :
partitions trouvées : sdb1 sdb2 sdb3 sdb5 sdb6 sdb7
data partitions to be saved : sdb1 sdb2 sdb6 sdb7
swap partition to be saved : sdb5
lancement de partclone v0.2.49 avec pigz - découpage de l'image chaque 2000 MB
Block size 4096 Byte
sdb1 total 88349 blocs used 73096
sdb2 total 19492869 blocs used 9239537
Pour sdb6, j'ai un message en rouge : Un problème a été rencontré !!!
échec après 2 secondes (étape Reading Super Block)
Completed: 60,33%extfsclone.c: bitmap error at 125 group.
Partclone fail, please check /var/log/partclone.log !
Checking the disk space...
(standard_in) 1: syntax error
idem avec sdb7,
Completed: 1.00%extfsclone.c: bitmap error at 25 group.
Ensuite il passe à la vérification des partitions Windows qui n'ont pas échoué et en rouge :
"Cette partition est défectueuse dans l'image: sdb6"
idem pour sdb7
"Des partitions endommagées ont été trouvées, ou bien certaines ne sont pas vérifiables dans cette image: *nom_image_disque*"
Je ne suis pas trop chaud pour utiliser dd parce que j'aurais trop vite fait de faire des dégâts avec une mauvaise commande ou une faute de frappe. Il est capable d'écrire dans un répertoire ? Parce que je n'ai pas vraiment de disque libre de taille identique ou supérieure (le 2To a une erreur CRC au SMART concernant 17 blocs mais pas de secteur défectueux ni ré-alloué ni pending).
Je te fais grâce de la situation antérieure, c'est identique à ce que donnait fdisk page précédente. J'ai renommé en /dev/sdb pour que la machine d'origine retrouve ses moutons. L'identifiant de disque a bien été renseigné dans le fichier table (je ne le reporte pas ici).
Comme c'est identique au tableau que tu as posté, j'ai repassé la même commande sans le --no-act, seule la dernière ligne change :
Y'a plus qu'à tester.
Pour sdb7 / home, tu indiques un début au secteur 205479936 pour une taille de 87693312 secteurs, soit 2048 de moins. La partition swap se termine au secteur 205477887 pour moi.
L'autre différence que je constate, c'est celle de 2 secteurs au début de sdb6 / root : début à 156651520 contre 156651518 pour moi (taille 41015296 vs 41015298) alors que la première méthode était censée ne pas corriger l'anomalie d'alignement. Ça n'aura pas d'impact sur le démarrage ?
Et la 3ème partition NTFS (stockage) est corrompue à mon sens, on peut l'omettre si ça n'a pas de conséquences non plus.
Ça ne sert à rien, c'est du gâchis. Le SSD a déjà sa propre réserve interne pour la réallocation des blocs défectueux.
Sans doute, mais je suis toujours dans cette optique d'avoir une marge de sécurité supplémentaire. Il me semblait avoir lu qu'un SSD pouvait utiliser l'espace non partitionné pour cette réaffectation (c'est que ça écrit vite ces petites bêtes-là !). Et comme il est à base de puces TLC, j'ai tendance à me méfier et à considérer la mémoire comme plus volatile qu'elle n'est. Stupide, mais ça me rassure.
Alors pourquoi a-t-elle un identifiant de type FAT16 ?
Parce que le processus n'a pas pu aller jusqu'à son terme j'imagine. J'avais sélectionné "Volume simple" (maintenant je sais que ça veut dire partition primaire), format NTFS, formatage rapide.
Les trois partitions Linux sont des partitions logiques dans la partition étendue donc elles ne peuvent avoir des numéros inférieurs à 5, les numéros 1 à 4 étant réservés aux partitions primaires.
La partition de stockage est une partition primaire donc son numéro doit être compris entre 1 et 4.
Je savais qu'on ne pouvait créer que 4 partitions primaires par disque ou 3 primaires et une étendue, mais l'incidence sur le lettrage *NIX m'échappait totalement, merci pour la précision.
On pourrait transformer la partition logique racine en partition primaire et reculer le début de la partition étendue derrière elle (nécessitant aussi de reculer la partition de swap pour laisser la place au secteur de partition étendu EBR). Et il faudra réinstaller GRUB à cause du changement de numéro de la racine.
On pourrait aussi transformer la partition de stockage primaire en partition logique et étendre la partition étendue jusqu'à la fin du disque.
Mais on sort un peu du sujet de la simple récupération. Si tu veux faire ça calcule le fichier de table de partition correspondant, je le vérifierai.
Pour l'instant, je crois que je vais restaurer l'état d'avant-boulette (donc avec la bizarrerie et le risque d'erreurs si je manipule les partitions) et faire une sauvegarde complète du disque, chose que j'aurais dû faire bien avant. Je vais me laisser le temps de la réflexion (et de faire les vérifs et manips correspondantes), il sera toujours temps de rectifier le partitionnement par la suite pour avoir quelque chose de propre et refaire une sauvegarde complète.
Concernant la renumérotation par fdisk, c'est hors sujet, à ne pas faire à la légère et inapplicable dans le cas présent.
De toute façon je ne touche à rien tant que je ne suis pas sûr de ne pas faire de bêtise que je regretterai par la suite.
(UUIDs, magic numbers et hash seeds bidons)