Debian Debian-France Debian-Facile Debian-fr.org Debian-fr.xyz Debian ? Communautés

Debian-facile

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

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

#1 Autres » [RÉSOLU] Erreur xfce4-panel à l'ouverture d'une session » 19-07-2020 19:12:56

31hud
Réponses : 0
Bonjour,

Je ne sais pas trop si je dois ouvrir ce sujet dans la section installation ou xfce.
Sur une installation toute fraîche de Debian 10, le premier démarrage de session se passe sans encombre avec la création des éléments du bureau.
Mais lors du redémarrage et à chaque ouverture de session suivante (déconnexion, redémarrage...), j'ai deux fenêtres qui s'ouvrent avec (titre, message en gras, phrase explicative) :

Question
Aucune instance de xfce4-panel n'a été trouvée
Voulez-vous démarrer le tableau de bord ? Si oui, veillez à ce que la session soit enregistrée lors de la déconnexion, de sorte que le tableau de bord soit relancé à la prochaine ouverture de session.


et


Avertissement
Modification du tableau de bord interdite
Le tableau de bord est en cours d’exécution en mode restreint, vous n’êtes donc pas autorisé à apporter des modifications à la configuration du tableau de bord en tant qu’utilisateur normal.


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.

#2 Re : Système » Perte de données sous linux » 19-07-2020 14:47:29

smolski a écrit :

Ajout de ce post vers le wiki de fsck :
https://debian-facile.org/doc:systeme:f … de-donnees

wink

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.

#3 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 19-07-2020 12:39:42

Suivi après absence : la sauvegarde n'a posé aucun problème avec la dernière version stable de CloneZilla (2.6.7-28). J'ai demandé un fsck interactif mais aucun message n'est apparu, c'est passé directement à la création des images de partitions avec partclone et la vérification dit "restaurable" pour toutes.

Je créerai un nouveau sujet pour tirer au clair cette histoire de partitions mal créées / mal alignées. Un grand merci à raleur pour son aide sans relâche !

#4 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 05-07-2020 13:27:11

Bonjour raleur,

J'ai fait un peu le même genre de recherches et je rejoins ta conclusion : l'auteur / dev / mainteneur de Clonezilla dit à des utilisateurs qui ont ce genre de souci avec un SSD ou androidX86 (fork ext4 un peu particulière) sur SourceForge d'utiliser une version plus récente en raison du noyau ou d'utiliser l'option fsck (mais on l'a déjà fait à côté et ça ne résout pas le problème). Ça me paraît être la bonne piste ; merci à toi pour tes recherches wink

#5 Re : Matériel » RESOLU résolution écran » 04-07-2020 20:46:01

Bonjour Croutons,

Croutons a écrit :

J'ai la même carte graphique

Argument de poids smile

Croutons a écrit :

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 tongue

#6 Re : Matériel » RESOLU résolution écran » 04-07-2020 20:19:12

Bonsoir dstc,

Question bête, mais es-tu allé voir dans les paramètres / réglages, section "Affichage", si d'autres résolutions ne seraient pas proposées dans un ascenseur ? Il se peut que ton environnement de bureau soit resté sur la résolution maximale du grub ou de la fenêtre de connexion. Juste une idée comme ça wink

#7 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 04-07-2020 18:57:34

neutral Bon, ben je n'ai pas eu plus de succès : toujours les deux mêmes messages en rouge avec "bitmap error at 125 group" et "bitmap error at 25 group" ; et le log de partclone n'est pas bavard (presque vide) :

/Media/sda1# cp /var/log/partclone.log partclone.log

suivi de

/Media/sda1# nano partclone.log

Partclone v0.2.49 http://partclone.org
Starting to check image (-)
The Image magic error. This file is NOT partclone Image

J'aurai au moins appris que Clonezilla contient nano ; j'obtiens la même chose avec un cat /var/log/partclone.log

#8 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 04-07-2020 14:57:00

Je n'ai pas ré-essayé, je peux le faire. Peux tu m'indiquer comment je peux récupérer le contenu du log dans un fichier depuis la ligne de commande de clonezilla ? Un cp peut-être mais je ne sais pas si nano est installé (j'ai plus l'habitude qu'avec vim). Merci pour ta réponse.

#9 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 04-07-2020 13:34:54

Bon, ça a été rapide (l'avantage des SSD), je l'ai fait sur le PC depuis lequel j'écris (en e-sata, les partitions sont démontées) :

fsck -f /dev/sdb6

fsck de util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/sdb6 : 192619/1283632 fichiers (0.3% non contigus), 1659646/5126912 blocs

fsck -f /dev/sdb7

fsck de util-linux 2.29.2
e2fsck 1.43.4 (31-Jan-2017)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
/dev/sdb7 : 39760/2744320 fichiers (2.0% non contigus), 1122879/10961664 blocs

Ç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).

#10 Re : Système » Je dois sécuriser deux uc Debian... face à un admin réseaux. » 01-07-2020 08:18:13

Bonjour,

Un truc qui pourrait le dissuader de jouer aux plus malins : https://www.legifrance.gouv.fr/affichCo … e=20110316 .
Si les preuves d'accès et de modifications sont réunies, il aura beaucoup de mal à défendre sa position.

#11 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 30-06-2020 08:51:08

Bon, j'ai pu faire un fsck sur /home (sda7) depuis le mode rescue en faisant un umount avant, il est clean. Pour / (sda6), il le remonte systématiquement, j'ai préféré laisser tomber. En cherchant un peu, j'ai vu qu'il y avait la possibilité d'effectuer un systemd-fsck au démarrage en ajoutant une ligne au grub et en faisant un update-grub ( https://manpages.debian.org/jessie/syst … .8.en.html  et  https://www.freedesktop.org/software/sy … rvice.html ). La méthode décrite ici https://debian-facile.org/doc:systeme:fsck dans le Wiki au paragraphe "Démarrage" (création d'un fichier /forcefsck) n'est plus en vigueur depuis l'introduction de systemd.

Il me faudrait donc ajouter en fin de ligne 'fsck.mode=force' mais j'hésite pour 'fsck.repair= ' : il propose "preen" par défaut pour une réparation de ce qui peut l'être de façon sûre ou répondre toujours "oui" ou "non".

#12 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 29-06-2020 21:44:18

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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é).

#13 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 29-06-2020 13:34:46

Bonjour raleur,

Désolé pour la réponse tardive, mais il fallait que je reproduise mes manips pour noter les messages d'erreur. Pour DiskImage v1.6 c'est vite vu : il retourne juste "Failure: Image Creation Failed". Dans le fichier img créé, j'ai :

Nom       Taille         Format                 Offset         Primaire   CHS début   CHS fin
0.ntfs    361880064      NTFS                   32256          +          0-1-1       43-254-63
1.ntfs    79842792960    NTFS                   361912320      +          44-0-1      534-254-63
2.img     3999268864     Solaris / Linux-swap   101205409792   -          16-48-33    502-103-49
3         44900024320                           105204678656          
4         99954589696                           150104702976

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).

#14 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 28-06-2020 15:26:18

hmm La sauvegarde a échoué : j'ai fait deux tentatives, l'une avec DiskImage de Roadkil présent sur le Hiren's Boot CD et l'autre avec Clonezilla qui se plaint que sdb6 et sdb7 contiennent des erreurs. Du coup j'hésite à me lancer dans cette rectification des partitions, je voulais au moins avoir une image complète du disque pour pouvoir revenir en arrière en cas d'échec. Je vais surtout sauvegarder mes données personnelles tant que j'ai un système fonctionnel et aviser ensuite.

#15 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 27-06-2020 17:56:07

Et j'ai avancé à tout petits pas pour ne pas aggraver la situation, je te remercie pour ta patience et le temps passé. Je passe le sujet en [RÉSOLU] et j'en ouvrirai un autre pour rectifier l'ordre logique / physique des partitions. Là, je vais faire chauffer le 2To et une cafetière complète (je te dois au moins ça, sauf si tu bois du thé). Tu m'as tiré d'un mauvais pas.

Je ne suis pas sûr que le bios gère les partitions GPT : c'est du matériel qui date d'il y a 10/12 ans, avant l'arrivée des UEFI.

#16 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 27-06-2020 17:32:25

woohoo.gifmerci.gifmerci.gifmerci.gif

Le grub réapparaît comme avant et tout semble normal dans ma session. Je suis déjà super content, tu ne peux pas imaginer à quel point ! T'es vraiment un chef yes.gif

#17 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 27-06-2020 17:14:48

Ok, merci pour tes explications. Je ne connais pas l'EBR et du coup je ne comprenais pas le pourquoi de ces différences.
Je disais "corrompue" parce que la création de la partition avec diskmgmt a dû être interrompue et qu'elle est reconnue comme FAT16 ou "format inconnu" par les différents outils.

Voici le retour de

sfdisk --no-act --no-reread --no-tell-kernel --wipe-partitions never /dev/sdb < table

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).

>>> Script d’en-tête accepté.
>>> Script d’en-tête accepté.
>>> Script d’en-tête accepté.
>>> Script d’en-tête accepté.
>>> Création d'une nouvelle étiquette pour disque de type DOS avec identifiant de disque 0xabcd1234.
/dev/sdb1: Une nouvelle partition 1 de type « HPFS/NTFS/exFAT » et de taille 345,1 MiB a été créée.
La partition #1 contient une signature ntfs.
/dev/sdb2: Une nouvelle partition 2 de type « HPFS/NTFS/exFAT » et de taille 74,4 GiB a été créée.
La partition #2 contient une signature ntfs.
/dev/sdb3: Une nouvelle partition 3 de type « Extended » et de taille 65,1 GiB a été créée.
/dev/sdb4: Une nouvelle partition 4 de type « HPFS/NTFS/exFAT » et de taille 77,7 GiB a été créée.
/dev/sdb5: Une nouvelle partition 5 de type « Linux swap / Solaris » et de taille 3,7 GiB a été créée.
La partition #5 contient une signature swap.
/dev/sdb6: Une nouvelle partition 6 de type « Linux » et de taille 19,6 GiB a été créée.
La partition #6 contient une signature ext4.
/dev/sdb7: Une nouvelle partition 7 de type « Linux » et de taille 41,8 GiB a été créée.
La partition #7 contient une signature ext4.
/dev/sdb8: Terminé.

Nouvelle situation :

Périphérique Amorçage     Début       Fin  Secteurs Taille Id Type
/dev/sdb1    *               63    706859    706797 345,1M  7 HPFS/NTFS/exFAT
/dev/sdb2                706860 156649814 155942955  74,4G  7 HPFS/NTFS/exFAT
/dev/sdb3             156651518 293173247 136521730  65,1G  5 Étendue
/dev/sdb4             293173248 456056831 162883584  77,7G  7 HPFS/NTFS/exFAT
/dev/sdb5             197666816 205477887   7811072   3,7G 82 partition d'échang
/dev/sdb6             156651520 197666815  41015296  19,6G 83 Linux
/dev/sdb7             205479936 293173247  87693312  41,8G 83 Linux

Les entrées de la table de partitions ne sont pas dans l'ordre du disque.
La table de partitions n’est pas modifiée (--no-act).

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 :

La table de partitions a été altérée.

Y'a plus qu'à tester.

#18 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 26-06-2020 09:08:04

Ok, merci pour tes indications.

J'ai refait des calculs basés sur ce que donne Gparted dans "Informations" (message #17 page 1) et je ne trouve pas les mêmes secteurs de début pour root et home :

/dev/sdb1   WinRE   pri (7), bootable
sect début: 63
sect fin:   706859
taille en s: 706797

/dev/sdb2   Windows pri (7)
sect début: 706860
sect fin:   156649814
taille en s:155942955

/dev/sdb3   extended
sect début: 156651518
sect fin:   293173247
taille en s:136521730

/dev/sdb4   stockage pri (7)
sect début: 293173248
sect fin:   456056831
taille en s:162883584

/dev/sdb5   linux-swap x (82)
sect début: 197666816
sect fin:   205477887
taille en s:7811072

/dev/sdb6   root       x (83)
sect début: 156651518
sect fin:   197666815
taille en s:41015298

/dev/sdb7   home       x (83)
sect début: 205477888
sect fin:   293173247
taille en s:87695360

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.

#19 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 25-06-2020 13:27:06

Question subsidiaire : le fichier table, je le place où ? Et est-ce que je dois spécifier son chemin complet dans la commande sfdisk ?

#20 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 25-06-2020 11:46:49

raleur a écrit :

Ç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. big_smile

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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.

raleur a écrit :

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.

#21 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 25-06-2020 10:24:21

Au moment de l'installation, je passe toujours une vingtaine de minutes à réfléchir à la taille des partitions pour éviter autant que possible d'avoir à y revenir par la suite. Sur cette installation-ci, je suis très probablement revenu en arrière avant la création de la table des partitions, ce qui explique peut-être l'incohérence de leur ordre physique / logique.

Je vois qu'on arrive au moment de prendre une décision : dans l'idéal, je préfère rétablir la suite des partitions comme elles étaient avant, au moins par ensembles, c'est-à-dire les partitions Windows en premier, suivies des partitions Linux dans la partition étendue et la partition de stockage supplémentaire en dernier (au format NTFS). Peu importe l'ordre des partitions au sein d'un groupe (Windows / Linux) du moment que leurs tailles ne varient pas trop ; et la partition swap est vide a priori, donc pas grave du tout si elle est reformatée. Et j'avais prévu de laisser 16Go pour la réaffectation de cellules défectueuses au cas où. Je ne sais pas si ça t'aide à comprendre ce que j'ai en tête.

Donc ça donnerait quelque chose comme :
sdx*1   WinRE amorçable
sdx2    Windows system
sdx3    Partition étendue
sdx4    root, home ou swap au choix
sdx5    root, home ou swap au choix
sdx6    root, home ou swap au choix
sdx7    espace de stockage au format NTFS (75 Gio environ) dans la partition étendue ou en dehors, peu importe, mais en laissant 16Go de réserve derrière

* Le disque est /dev/sdc tant que je le branche sur cet ordi depuis lequel j'écris, il se nomme /dev/sdb dans sa machine d'origine (et j'ai la possibilité de le brancher ici en interne à la place du sdb actuel s'il faut).

#22 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 25-06-2020 08:49:43

Bonjour raleur,

Le voici :

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system>                           <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sdb6 during installation
UUID=4dcc098d-0e0a-4401-bbd1-0b472c815b39 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sdb7 during installation
UUID=f77cfb28-8e78-471b-8eae-75bb16b7f4c7 /home           ext4    defaults        0       2
# swap was on /dev/sdb5 during installation
UUID=bcb69c1c-3f0f-4120-bc1a-9ba1f99be96e none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

#23 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 24-06-2020 19:56:57

Oui, je me suis sûrement mal exprimé : ce que je voulais dire, c'est que j'avais un doute quant au fait que tmp et var aient été des partitions séparées à l'installation mais il semble bien qu'il n'y ait que root, home et swap-linux. Absolument pas grave si la partition swap perd 2 secteurs (elle est vide de toute manière de ce que j'ai compris), et j'utilise vm.swappiness=1 au cas où ça importerait.

Voici les retours de dumpe2fs avec le -h (bien moins longs en effet) :

dumpe2fs -h /dev/sdc6


dumpe2fs 1.43.4 (31-Jan-2017)
Filesystem volume name:   <none>
Last mounted on:          /
Filesystem UUID:          4dcc098d-0e0a-4401-bbd1-0b472c815b39
Filesystem magic number:  0xAB12
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1283632
Block count:              5126912
Reserved block count:     256345
Free blocks:              3497555
Free inodes:              1091245
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8176
Inode blocks per group:   511
Flex block group size:    16
Filesystem created:       Fri Nov 29 09:28:54 2019
Last mount time:          Fri May 29 16:49:15 2020
Last write time:          Fri May 29 18:49:15 2020
Mount count:              147
Maximum mount count:      -1
Last checked:             Fri Nov 29 09:28:54 2019
Check interval:           0 (<none>)
Lifetime writes:          36 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      5a119dac-4210-7492-cbdf-6357f58aacec
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x99155034
Fonctionalités du journal :  journal_incompat_revoke journal_64bit journal_checksum_v3
Taille du journal :         128M
Longueur du journal :      32768
Séquence du journal :      0x0002d51f
Début du journal :         0
Type de csum du journal:   crc32c
Csum du journal:          0x81267454

dumpe2fs -h /dev/sdc7


dumpe2fs 1.43.4 (31-Jan-2017)
Filesystem volume name:   <none>
Last mounted on:          /home
Filesystem UUID:          f77cfb28-8e78-471b-8eae-75bb16b7f4c7
Filesystem magic number:  0xBC23
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal ext_attr resize_inode dir_index filetype extent 64bit flex_bg sparse_super large_file huge_file dir_nlink extra_isize metadata_csum
Filesystem flags:         signed_directory_hash
Default mount options:    user_xattr acl
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              2744320
Block count:              10961664
Reserved block count:     548083
Free blocks:              9830457
Free inodes:              2704058
First block:              0
Block size:               4096
Fragment size:            4096
Group descriptor size:    64
Reserved GDT blocks:      1024
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         8192
Inode blocks per group:   512
Flex block group size:    16
Filesystem created:       Fri Nov 29 09:28:55 2019
Last mount time:          Fri May 29 16:49:16 2020
Last write time:          Fri May 29 16:50:43 2020
Mount count:              147
Maximum mount count:      -1
Last checked:             Fri Nov 29 09:28:55 2019
Check interval:           0 (<none>)
Lifetime writes:          67 GB
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:           256
Required extra isize:     32
Desired extra isize:      32
Journal inode:            8
Default directory hash:   half_md4
Directory Hash Seed:      f250b9f1-5c04-b12a-15ea-bffbd1df7440
Journal backup:           inode blocks
Checksum type:            crc32c
Checksum:                 0x841af063
Fonctionalités du journal :  journal_incompat_revoke journal_64bit journal_checksum_v3
Taille du journal :         256M
Longueur du journal :      65536
Séquence du journal :      0x000582bc
Début du journal :         0
Type de csum du journal:   crc32c
Csum du journal:          0xc7006e03

(UUIDs, magic numbers et hash seeds bidons)

#24 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 23-06-2020 17:07:26

Oh, joli ! Les partitions Linux sont accessibles : la partition de 45GiB est bien /home et celle de 21GiB la racine contenant les répertoires boot, tmp et var "en dur" (pas de raccourci). Donc c'est une install classique racine et home séparé wink Je commence à reprendre espoir avec le dossier boot accessible (mais je ne sais pas quoi en faire). Je ne pousse pas encore le "ouf" de soulagement mais pas loin !

#25 Re : Système » [RÉSOLU] Récupération de partitions perdues suite à grub rescue » 23-06-2020 16:58:40

Pas de souci, je sais ce que c'est d'avoir une logique en tête et sauter des étapes qui semblent aller de soi wink Et on a tous une vie et nos occupations.
Les retours des 6 premières commandes (delpart, addpart et blockdev) se sont bien passés : vides (pas de nouvelle, bonne nouvelle).

blkid /dev/sdc[5-7]


/dev/sdc5: UUID="bcb69c1c-3f0f-4120-bc1a-9ba1f99be96e" TYPE="swap" PARTUUID="a1b2c3d4-05"
/dev/sdc6: UUID="4dcc098d-0e0a-4401-bbd1-0b472c815b39" TYPE="ext4"
/dev/sdc7: UUID="f77cfb28-8e78-471b-8eae-75bb16b7f4c7" TYPE="ext4"

(les UUID sont fictifs) Il semble reconnaître du format ext4, bon signe ?

file -s /dev/sdc5


/dev/sdc5: Linux/i386 swap file (new style), version 1 (4K pages), size 976383 pages, no label, UUID=bcb69c1c-3f0f-4120-bc1a-9ba1f99be96e

Pied de page des forums

Propulsé par FluxBB