LVM chiffré et passage de Wheezie à Jesssie.

Le
Randy11
Bonjour,

Désolé de recommencer un nouveau fil de discussion sur le même sujet,
mais ma configuration est au tas :-(

Je vous prie d'excuser la présentation des informations, je dois
recopier ce qui est présent sur l'écran du PC que j'essaye de mettre à jour.

J'apprécierais toute suggestion qui m'éviterai de perdre toutes mes
données, même si j'ai eu la prudence de sauvegarder les données cryptées
avant de tenter la mise à jour.


Voici les évènements :


À partir d'une configuration avec Wheezy qui comporte des partions
Windows et LVM dont 2 partitions LVM chiffrées, j'ai voulu passer de
Wheezy à Jessie par une installation complète de Jessie et non une mise
à jour - ma config Wheezy avait été un trop bricolée.

Disque /dev/sda :
/dev/sda1 100G NTFS
/dev/sda2 250G NTFS
/dev/sda3 30.3G FAT32
/dev/sda4 1.5T Extended
/dev/sda5 1.5T Linux LVM

Dans /dev/sda5, il y a 8 partitions LVM.

/etc/fstab de l'installation d'origine en Wheezy :
=
/dev/mapper/vg-lv--01 / ext4 errors=remount-ro 0 1
/dev/mapper/vg-lv--03_crypt /home ext4 defaults 0 2
# /dev/mapper/vg-lv--04 /mnt/video ext4 defaults 0 2
/dev/mapper/vg-lv--04 /mnt/video ext4 rw,user,noauto 0 2
/dev/mapper/vg-lv--02_crypt none swap sw 0 0
/dev/mapper/vg-lv--08 none swap sw 0 0
/dev/mapper/vg-lv--06 /mnt/divers ext4 defaults 0 0 2
/dev/sr0 /media/cdrom0 udf,iso9660 user,noauto 0 0

Pour installer Jessie, j'ai seulement pris :
- lv--01 pour /
- lv--05 pour /var
- lv--08 pour swap

La reconnaissance des partions LVM étaient bonne lors de l'installation.
Je n'ai identifiée aucune partition comme chiffrée.
Je comptais modifier le /etc/fstab après pour les monter.

J'ai essayé 2 méthodes pour installer Grub :

En mode "rescue", dans le menu, j'ai choisis "Réinstallation du
programme de démarrage GRUB". Les messages d'erreur sont :

grub-installer: File descriptor 3 (/dev/pts/0) leaked on vgs on
invocation. Parent PID
grub-installer: File descriptor 4 (/dev/pts/0) leaked on vgs on
invocation. Parent PID
grub-installer: File descriptor 5 (/dev/pts/0) leaked on vgs on
invocation. Parent PID
grub-installer: File descriptor 6 (/dev/pts/0) leaked on vgs on
invocation. Parent PID
grub-installer: File descriptor 4 (/dev/pts/0) leaked on vgs on
invocation. Parent PID
[]
grub-install: info: warning: your core.img is unusually large. It won't
fit in the embedding area.
grub-install: info: error: embedding is not possible, but this is
required for RAID and LVM install


En mode "rescue", message d'erreur en faisant un "chroot" avec lv--01
montée et avec un "update-grub" suivi d'un "grub-install" :
grub-install: info: Scanning for lvm device on distk hostdisk://dev/sda
grub-install: info: no LVM signature found.
grub-install: info: Scanning for DISKFILTER device on disk
hostdisk//dev/sda
grub-install: info: Partition 0 starts from 63.
grub-install: info: Partition 1 start from 209728575.
grub-install: info: Partition 2 start from 734025915.
grub-install: info: Partition 4 start from 797515776
grub-install: info: guess root_dev `lvmid//../' from dir
`/boot/grub/i386-pc'
grub-install: info: setting the root device to `lvmid///'.
grub-install: info: warning: your core.img is unusually large. It won't
fit in the embedding area.
grub-install: info: error: embedding is not possible, but this is
required for RAID and LVM install

Après chaque boot, je me trouve fasse au prompt de grub :
GRUB loading
Welcome to GRUB!

error: file not found.
Entering rescue mode
grub rescue>


Merci pour votre aide.
Randy11
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Pascal Hambourg
Le #26391684
Randy11 a écrit :

À partir d'une configuration avec Wheezy qui comporte des partions
Windows et LVM dont 2 partitions LVM chiffrées, j'ai voulu passer de
Wheezy à Jessie par une installation complète de Jessie et non une mise
à jour - ma config Wheezy avait été un trop bricolée.

Disque /dev/sda :
/dev/sda1 100G NTFS
/dev/sda2 250G NTFS
/dev/sda3 30.3G FAT32
/dev/sda4 1.5T Extended
/dev/sda5 1.5T Linux LVM

Dans /dev/sda5, il y a 8 partitions LVM.


(...)
Pour installer Jessie, j'ai seulement pris :
- lv--01 pour /
- lv--05 pour /var
- lv--08 pour swap



Avis personnel : donner des noms génériques aux volumes logiques
constitue une négation d'un des avantages de LVM, à savoir de pouvoir
donner aux volumes logiques des noms signifiants et non de simples
numéros comme les partitions.

En mode "rescue", message d'erreur en faisant un "chroot" avec lv--01
montée et avec un "update-grub" suivi d'un "grub-install" :
grub-install: info: Scanning for lvm device on distk hostdisk://dev/sda
grub-install: info: no LVM signature found.
grub-install: info: Scanning for DISKFILTER device on disk
hostdisk//dev/sda
grub-install: info: Partition 0 starts from 63.
grub-install: info: Partition 1 start from 209728575.
grub-install: info: Partition 2 start from 734025915.
grub-install: info: Partition 4 start from 797515776
grub-install: info: guess root_dev `lvmid/....../...../' from dir
`/boot/grub/i386-pc'
grub-install: info: setting the root device to `lvmid/.../.../'.
grub-install: info: warning: your core.img is unusually large. It won't
fit in the embedding area.
grub-install: info: error: embedding is not possible, but this is
required for RAID and LVM install



En clair :

Le contenu de /boot est dans un volume logique LVM, ce qui induit deux
contraintes contradictoires sur l'image core de GRUB :
1) Elle doit intégrer le module lvm lui permettant de lire le LV, ce qui
augmente sa taille.
2) Elle doit être installée dans l'espace réservé entre le MBR et la
première partition, les listes de blocs n'étant pas utilisables avec LVM.

Or cet espace est très réduit sur ton disque puisque la première
partition commence au secteur 63, ce qui laisse 62*5121744 octets ou
31 Kio.

A noter que depuis un certain temps les programmes de partitionnement
actuels, y compris l'installateur Debian, ont déplacé à 2048 secteurs (1
Mio) le début de la première partition pour d'autres raison (alignement
avec les tailles de blocs des disques durs au format avancé et des SSD).
Le partitionnement de ce disque a donc dû être fait avec un programme de
partitionnement assez ancien, ce qui est contradictoire avec sa capacité
respectable d'au moins 2 To.

Et comme tout logiciel, GRUB a tendance à grossir au fur et à mesure des
versions. Je viens de regarder sur un disque avec LVM contenant à la
fois Wheezy et Jessie :
- sur Wheezy, /boot/grub/core.img = 28779 octets
- sur Jessie, /boot/grub/i386-pc/core.img = 31956 octets, soit
légèrement plus que l'intervalle post-MBR de ton disque.

Dans ces conditions, l'image core de GRUB ne peut plus être installée
sur ton disque.

Après chaque boot, je me trouve fasse au prompt de grub :

GRUB loading
Welcome to GRUB!

error: file not found.



Normal, c'est l'image core de GRUB de Wheezy qui est encore présente,
qui se lance et ne trouve plus ses fichiers dans le LV racine.

Solutions possibles :
- Créer une petite partition (5 Mo devraient suffire) formatée en ext2 à
monter sur /boot/grub, ce qui au mieux réduira suffisamment la taille de
l'image core pour qu'elle contienne dans l'espace post-MBR en évitant
l'intégration du module lvm, et au pire permettra à grub-install avec
l'option --force d'utiliser les listes de blocs.

- Convertir la table de partition au format GPT avec gdisk et créer une
petite partition (1 Mo) de type "BIOS boot" où grub-install pourra
installer l'image core. Mais si le disque contient une installation de
Windows, ce dernier ne pourra plus démarrer. Ce problème peut néanmoins
être contourné avec un MBR hybride créé au moyen de gdisk.

- Si la machine a un firmware UEFI, activer l'amorçage en mode UEFI,
créer une partition système EFI (500 Mo recommandés, mais 5 Mo
suffisent) formatée en FAT à monter sur /boot/efi, installer
grub-efi-amd64 pour un firmware 64 bits ou grub-efi-ia32 pour un
firmware 32 bits. Exécuter "grub-install --removable" si nécessaire.
Mais à nouveau, une installation de Windows ne pourra plus démarrer en
dual boot avec Debian. Il faudra restaurer l'amorce de Windows dans le
MBR et sélectionner l'OS via le mode d'amorçage du firmware, UEFI pour
Debian et legacy pour Windows.
Pascal Hambourg
Le #26391725
Randy11 a écrit :
On 05/03/2016 22:48, Pascal Hambourg wrote:
Randy11 a écrit :

Pour installer Jessie, j'ai seulement pris :
- lv--01 pour /
- lv--05 pour /var
- lv--08 pour swap



Avis personnel : donner des noms génériques aux volumes logiques
constitue une négation d'un des avantages de LVM, à savoir de pouvoir
donner aux volumes logiques des noms signifiants et non de simples
numéros comme les partitions.



Bonne remarque. C'est une habitude d'un collègue que j'ai reprise. Je aivais
choisi ces noms pour avoir le moins de partitons facilement identifiables
puisque j'ai certaines sont chiffrées : ne pas faciliter les choses.



C'est un point de vue. Mais ne pas faciliter les choses pour qui ? Pour
un administrateur que cela ne va pas aider à s'y retrouver, c'est sûr.
Pour un éventuel attaquant qui peut de toute façon assez facilement
savoir ce que contiennent les volumes, sur quoi ils sont montés et à
quoi ils servent, j'ai des doutes. On n'est pas loin de la sécurité par
l'obscurité.

L'installation date de la première version de Wheezy.



L'installateur de Wheezy créait déjà des partitions alignées sur des
blocs de 1 Mio (2048 secteurs de 512 octets). D'ailleurs on voit bien
que le début de la partition LVM est aligné sur cette taille.

Par contre ce n'est pas le cas des partitions NTFS et FAT qui sont
alignées "à l'ancienne" sur des pistes ou cylindres (63 secteurs/piste
pour la première, multiples de 255 têtes x 63 secteurs/piste pour les
deux suivantes). Comment ont-elles été créées ? Sauf erreur,
l'installateur de Windows Vista applique aussi l'alignement "moderne".

Solutions possibles :
- Créer une petite partition (5 Mo devraient suffire) formatée en ext2 à
monter sur /boot/grub, ce qui au mieux réduira suffisamment la taille de
l'image core pour qu'elle contienne dans l'espace post-MBR en évitant
l'intégration du module lvm, et au pire permettra à grub-install avec
l'option --force d'utiliser les listes de blocs.



J'ai déjà 3 partitions Windows et 1 "extended"/LVM. Si les choses n'ont
pas trop évoluées, il je ne peux plus créer de 4ème partition
primaire.



La partition n° 4 est une partition étendue qui contient actuellement
uniquement la partition logique n° 5 servant de PV LVM, mais elle peut
contenir un nombre arbitraire de partitions logiques. Il suffit qu'il
reste un tout petit peu d'espace non alloué, même non aligné, à la fin
du disque ou au début de la partition étendue.

Dans le cas contraire, tu dois bien pouvoir réduire un poil le PV LVM et
la partition logique n° 5 qui le contient.

- Convertir la table de partition au format GPT avec gdisk et créer une
petite partition (1 Mo) de type "BIOS boot" où grub-install pourra
installer l'image core. Mais si le disque contient une installation de
Windows, ce dernier ne pourra plus démarrer. Ce problème peut néanmoins
être contourné avec un MBR hybride créé au moyen de gdisk.



Je n'ai pas encore regarder GPT et gdisk en détail, mais est-ce compatible
avec les partions actuelles



GPT est compatible avec tout type de partition. Il y a suffisamment
d'espace au début du disque pour y loger une table de partition GPT
standard (34 secteurs). Par contre C'est l'amorçage du Windows installé
qui ne sera pas compatible avec GPT.

Et si après je veux changer de version de Windows comment les choses
se passeront ?



Dans l'état actuel, Windows ne peut démarrer depuis un disque au format
GPT qu'en mode UEFI, et doit avoir été installé pour cela. D'où la
suggestion du MBR hybride qui contient une table de partition au format
MSDOS traditionnel.

- Si la machine a un firmware UEFI, activer l'amorçage en mode UEFI,
créer une partition système EFI (500 Mo recommandés, mais 5 Mo
suffisent) formatée en FAT à monter sur /boot/efi, installer
grub-efi-amd64 pour un firmware 64 bits ou grub-efi-ia32 pour un
firmware 32 bits. Exécuter "grub-install --removable" si nécessaire.
Mais à nouveau, une installation de Windows ne pourra plus démarrer en
dual boot avec Debian. Il faudra restaurer l'amorce de Windows dans le
MBR et sélectionner l'OS via le mode d'amorçage du firmware, UEFI pour
Debian et legacy pour Windows.



La partition EFI, peut-elle être prise sur la partie en LVM ?



Non. Les firmwares UEFI ne comprennent pas le format LVM de Linux, il ne
faut pas rêver.

J'ai mentionné les deux dernières solutions pour être complet, mais je
pense que la première est la plus simple, sûre et adaptée à la situation.
Randy11
Le #26391753
On 06/03/2016 13:01, Pascal Hambourg wrote:
Randy11 a écrit :
On 05/03/2016 22:48, Pascal Hambourg wrote:
Randy11 a écrit :
Pour installer Jessie, j'ai seulement pris :
- lv--01 pour /
- lv--05 pour /var
- lv--08 pour swap


Avis personnel : donner des noms génériques aux volumes logiques
constitue une négation d'un des avantages de LVM, à savoir de pouvoir
donner aux volumes logiques des noms signifiants et non de simples
numéros comme les partitions.


Bonne remarque. C'est une habitude d'un collègue que j'ai reprise. Je aivais
choisi ces noms pour avoir le moins de partitons facilement identifiables
puisque j'ai certaines sont chiffrées : ne pas faciliter les choses.


C'est un point de vue. Mais ne pas faciliter les choses pour qui ? Pour
un administrateur que cela ne va pas aider à s'y retrouver, c'est sûr.
Pour un éventuel attaquant qui peut de toute façon assez facilement
savoir ce que contiennent les volumes, sur quoi ils sont montés et à
quoi ils servent, j'ai des doutes. On n'est pas loin de la sécurité par
l'obscurité.



Soit, j'en tiendrais compte pour la suite ;-)

L'installation date de la première version de Wheezy.


L'installateur de Wheezy créait déjà des partitions alignées sur des
blocs de 1 Mio (2048 secteurs de 512 octets). D'ailleurs on voit bien
que le début de la partition LVM est aligné sur cette taille.

Par contre ce n'est pas le cas des partitions NTFS et FAT qui sont
alignées "à l'ancienne" sur des pistes ou cylindres (63 secteurs/piste
pour la première, multiples de 255 têtes x 63 secteurs/piste pour les
deux suivantes). Comment ont-elles été créées ? Sauf erreur,
l'installateur de Windows Vista applique aussi l'alignement "moderne".



Le partionnement a été fait lors de l'installation d'un WindowsXP...
c'est vieux. J'ai gardé
du Windows pour deux raisons : l'acquisition vidéo avec une carte
Hauppauge et la
récupérations de mes parcours enregistrés sur mon GPS Garmin Zumo 350LM.
Le GPS
est la dernière raison pour garder un Windows.


Solutions possibles :
- Créer une petite partition (5 Mo devraient suffire) formatée en ext2 à
monter sur /boot/grub, ce qui au mieux réduira suffisamment la taille de
l'image core pour qu'elle contienne dans l'espace post-MBR en évitant
l'intégration du module lvm, et au pire permettra à grub-install avec
l'option --force d'utiliser les listes de blocs.


J'ai déjà 3 partitions Windows et 1 "extended"/LVM. Si les choses n'ont
pas trop évoluées, il je ne peux plus créer de 4ème partition
primaire.


La partition n° 4 est une partition étendue qui contient actuellement
uniquement la partition logique n° 5 servant de PV LVM, mais elle peut
contenir un nombre arbitraire de partitions logiques. Il suffit qu'il
reste un tout petit peu d'espace non alloué, même non aligné, à la fin
du disque ou au début de la partition étendue.

Dans le cas contraire, tu dois bien pouvoir réduire un poil le PV LVM et
la partition logique n° 5 qui le contient.



J'ai créer une partition en etx2 /dev/sda6 en réduisant la taille de
mon volume groupe qui prenait toute la partition /dev/sda5.
J'ai sauvegardé toutes les étapes,
je les donnerais après.


Avec la netinstall, j'ai tenté de réinstaller Grub : reinstallation
éffectuée sans
plainte. Au reboot le menu Grub avec les OS à démarrer est présent, mais
message d'erreur :
/boot/vmliuz... non trouvé ???


Les contenu de la partition /boot est :
system.map-3.16.0-4-amd64
config-3.16.0-4-amd64
initrd.img-3.16.0-4-amd64
vmlinuz-3.16.0-4-amd64
grub/
lost+found/

La ligne pour /boot dans /etc/fstab est :
/dev/sda6 /boot ext2 defaults 0 2

Cette fois-ci reprise de l'installation de Grub par "chroot /target"
après le lancement d'un shell.

mount /var
update-grub
Création du fichier de configuration GRUB...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-3.16.0-4-amd64
Image mémoire initiale trouvée : /boot/initrd.img-3.16.0-4-amd64
Wintwos NT/2000/XOP trouvé sur /dev/sda1
fait


Redémarrage, on progresse. Le début de démarrage se fait, mais finit en
échec avec le message :
Welcome to emergency mode ! ... "journalctl -xb"..."systemctl reboot"...
"systemctl default"
...
Give root password for maintenance :

Les dernières étapes en échec sont :
[DEPEND] Dependency failed for /mnt
[DEPEND] Dependency failed for Local File System
[DEPEND] Dependency failed for File System Check on
/dev/mapper/vg-lv--03_crypt
[ TIME ] Timed out waiting for device
dev-mapper-vgx2dlvx2dx2d02_crypt.device.
[DEPEND]Dependency failed for /dev/mapper/vg-lv--02_crypt
[DEPEND]Dependency failed for Swap


J'ai viré les partitions cryptées du fstab, refait une installation de
Grub et rédémarré.

J'ai récupéré une Jessie fonctionnelle !!!!! :-)


C'est bien, mais le problème est que mes partitions cryptées qui doivent
correspondre
à "/home" et "/swap" ne sont pas utilisées.

Y-a-t-il une bonne âme pour m'aider ?

Merci par avance.

P.S.: je vais mettre en forme les infos pour réduire un VG, cela m'a
pris pas mal
de temps, si cela peut en faire gagner à d'autre se sera une bonne chose.

Randy11
Pascal Hambourg
Le #26391757
Le 06/03/2016 23:35, Randy11 a écrit :

On 06/03/2016 13:01, Pascal Hambourg wrote:

- Créer une petite partition (5 Mo devraient suffire) formatée en ext2 à
monter sur /boot/grub, ce qui au mieux réduira suffisamment la taille de
l'image core pour qu'elle contienne dans l'espace post-MBR en évitant
l'intégration du module lvm, et au pire permettra à grub-install avec
l'option --force d'utiliser les listes de blocs.








(...)
J'ai créer une partition en etx2 /dev/sda6 en réduisant la taille de
mon volume groupe qui prenait toute la partition /dev/sda5.



Il n'était pas nécessaire que la partition contienne tout /boot ;
/boot/grub suffisait et nécessitait une taille plus modeste.

C'est bien, mais le problème est que mes partitions cryptées qui doivent
correspondre à "/home" et "/swap" ne sont pas utilisées.



Le paquet cryptsetup est-il installé ?
As-tu essayé d'ouvrir les volumes chiffrés avec cryptsetup luksOpen... ?
Si cela fonctionne, tu pourras les ajouter au fichier /etc/crypttab (à
moins que tu aies conservé celui de Wheezy) pour les ouvrir
automatiquement au démarrage.
Randy11
Le #26391820
On 07/03/2016 00:37, Pascal Hambourg wrote:
Le 06/03/2016 23:35, Randy11 a écrit :

On 06/03/2016 13:01, Pascal Hambourg wrote:

- Créer une petite partition (5 Mo devraient suffire) formatée en
ext2 à
monter sur /boot/grub, ce qui au mieux réduira suffisamment la
taille de
l'image core pour qu'elle contienne dans l'espace post-MBR en évitant
l'intégration du module lvm, et au pire permettra à grub-install avec
l'option --force d'utiliser les listes de blocs.








(...)
J'ai créer une partition en etx2 /dev/sda6 en réduisant la taille de
mon volume groupe qui prenait toute la partition /dev/sda5.



Il n'était pas nécessaire que la partition contienne tout /boot ;
/boot/grub suffisait et nécessitait une taille plus modeste.

C'est bien, mais le problème est que mes partitions cryptées qui doivent
correspondre à "/home" et "/swap" ne sont pas utilisées.



Le paquet cryptsetup est-il installé ?
As-tu essayé d'ouvrir les volumes chiffrés avec cryptsetup luksOpen... ?
Si cela fonctionne, tu pourras les ajouter au fichier /etc/crypttab (à
moins que tu aies conservé celui de Wheezy) pour les ouvrir
automatiquement au démarrage.




Merci pour les indications, j'ai récupéré l'ancien /etc/crypttab, refait
ma swap cryptée, mis à jour /etc/crypttab avec le nouvel UID et ÇA
MARCHE !!!

Après 15 jours de galère, je récupère enfin mon PC :-)

Un très grand MERCI à tous pour votre aide.

Randy11
Randy11
Le #26391822

C'est bien, mais le problème est que mes partitions cryptées qui
doivent
correspondre à "/home" et "/swap" ne sont pas utilisées.



Le paquet cryptsetup est-il installé ?
As-tu essayé d'ouvrir les volumes chiffrés avec cryptsetup luksOpen... ?
Si cela fonctionne, tu pourras les ajouter au fichier /etc/crypttab
(à moins que tu aies conservé celui de Wheezy) pour les ouvrir
automatiquement au démarrage.




Merci pour les indications, j'ai récupéré l'ancien /etc/crypttab,
refait ma swap cryptée, mis à jour /etc/crypttab avec le nouvel UID et
ÇA MARCHE !!!

Après 15 jours de galère, je récupère enfin mon PC :-)

Un très grand MERCI à tous pour votre aide.

Randy11




On devrait toujours attendre avant de se réjouir :-(
J'allais mettre en veille mon PC quand l'idée m'est venue de faire
"apt-get dist-upgrade", voilà
ce que j'obtiens (ce n'est que la fin) :

Paramétrage de linux-image-3.16.0-4-amd64 (3.16.7-ckt20-1+deb8u4) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-3.16.0-4-amd64
/etc/kernel/postinst.d/zz-update-grub:
Création du fichier de configuration GRUB…
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Image Linux trouvée : /boot/vmlinuz-3.16.0-4-amd64
Image mémoire initiale trouvée : /boot/initrd.img-3.16.0-4-amd64
[ 504.460680] EXT4-fs (sda4): unable to read superblock
[ 504.462564] EXT4-fs (sda4): unable to read superblock
[ 504.464474] EXT4-fs (sda4): unable to read superblock
[ 504.475289] FAT-fs (sda4): bogus number of reserved sectors
[ 504.477480] FAT-fs (sda4): bogus number of reserved sectors
[ 504.487249] qnx4: no qnx4 filesystem (no root dir).
Windows NT/2000/XP trouvé sur /dev/sda1
fait
Paramétrage de openssl (1.0.1k-3+deb8u4) ...
Paramétrage de python-pil:amd64 (2.6.1-2+deb8u2) ...
Paramétrage de python-imaging (2.6.1-2+deb8u2) ...
Traitement des actions différées (« triggers ») pour libc-bin
(2.19-18+deb8u3) .

Pour mémoire, voici le partionnement :
Disque /dev/sda : 1,8 TiB, 2000398934016 octets, 3907029168 secteurs
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 512 octets
taille d'E/S (minimale / optimale) : 512 octets / 512 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x17121712

Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 209728574 209728512 100G 7 HPFS/NTFS/exFAT
/dev/sda2 209728575 734025914 524297340 250G 7 HPFS/NTFS/exFAT
/dev/sda3 734025915 797514794 63488880 30,3G c W95 FAT32 (LBA)
/dev/sda4 797515774 3907028991 3109513218 1,5T 5 Extended
/dev/sda5 797515776 3906828992 3109313217 1,5T 8e Linux LVM
/dev/sda6 3906832384 3907028991 196608 96M 83 Linux



Que cela signifie-t-il ? Est-ce grave docteur ?
Pascal Hambourg
Le #26391821
Randy11 a écrit :

[ 504.460680] EXT4-fs (sda4): unable to read superblock
[ 504.462564] EXT4-fs (sda4): unable to read superblock
[ 504.464474] EXT4-fs (sda4): unable to read superblock
[ 504.475289] FAT-fs (sda4): bogus number of reserved sectors
[ 504.477480] FAT-fs (sda4): bogus number of reserved sectors
[ 504.487249] qnx4: no qnx4 filesystem (no root dir).


(...)
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 209728574 209728512 100G 7 HPFS/NTFS/exFAT
/dev/sda2 209728575 734025914 524297340 250G 7 HPFS/NTFS/exFAT
/dev/sda3 734025915 797514794 63488880 30,3G c W95 FAT32 (LBA)
/dev/sda4 797515774 3907028991 3109513218 1,5T 5 Extended
/dev/sda5 797515776 3906828992 3109313217 1,5T 8e Linux LVM
/dev/sda6 3906832384 3907028991 196608 96M 83 Linux

Que cela signifie-t-il ?



Que sda4 n'est pas une partition ext4, FAT ou QNX. Pas étonnant puisque
c'est une partition étendue.

Est-ce grave docteur ?



Non.
Randy11
Le #26391833
Merci beaucoup !

Je suis vraiment heureux de l'aide qui m'a été apportée.

Bonne journée.

Randy11

On 07/03/2016 23:51, Pascal Hambourg wrote:
Randy11 a écrit :
[ 504.460680] EXT4-fs (sda4): unable to read superblock
[ 504.462564] EXT4-fs (sda4): unable to read superblock
[ 504.464474] EXT4-fs (sda4): unable to read superblock
[ 504.475289] FAT-fs (sda4): bogus number of reserved sectors
[ 504.477480] FAT-fs (sda4): bogus number of reserved sectors
[ 504.487249] qnx4: no qnx4 filesystem (no root dir).


(...)
Device Boot Start End Sectors Size Id Type
/dev/sda1 * 63 209728574 209728512 100G 7 HPFS/NTFS/exFAT
/dev/sda2 209728575 734025914 524297340 250G 7 HPFS/NTFS/exFAT
/dev/sda3 734025915 797514794 63488880 30,3G c W95 FAT32 (LBA)
/dev/sda4 797515774 3907028991 3109513218 1,5T 5 Extended
/dev/sda5 797515776 3906828992 3109313217 1,5T 8e Linux LVM
/dev/sda6 3906832384 3907028991 196608 96M 83 Linux

Que cela signifie-t-il ?


Que sda4 n'est pas une partition ext4, FAT ou QNX. Pas étonnant puisque
c'est une partition étendue.

Est-ce grave docteur ?


Non.

Publicité
Poster une réponse
Anonyme