Partition / défectueuse ? Désactivée manuellement dans fstab?

Support Debian
#1

Bonjour,

La suite des pannes de ma machine.

Le technicien qui a travaillé sur ma machine m’indique que l’origine du démarrage en mode “dépannage” est due à un problème au niveau de la partition /.
Il est intervenu dans le fichier fstab.

Un problème au niveau de la partition / ne permettait plus le démarrage de gnome, mais est également à l’origine du non fonctionnement de connecteurs USB et du graveur DVD connecté en USB interne à la machine.
Il a “désactivé” la ligne correspondant à la partition / (comment ?) puis a relancé la machine pour réinstaller Debian et là, le dvd a bien voulu booter et l’installation de Debian 10 s’est déroulée sans problème.

Ma question :
Alors que la défaillance au niveau d’une barrette de ram est avérée, que mes problèmes au démarrage sont apparu progressivement (barrette ram ?), je m’interroge sur la cause de la “modification” survenue dans la partition / qui empêche le bon fonctionnement de ma machine.
Est- possible qu’à la fermeture (et/ou au démarrage) de la machine, quelque chose soit écrit dans la partition / sans que l’utilisateur n’en soit averti ?

J’espère avoir été clair dans ces explications.

Merci.

#2

Bonjour,

Je me réponds à moi-même avec les infos complémentaires reçues ce matin.

Dans mon ordi capricieux, il y a 2 HDD internes et, chose curieuse, chacun a une partition “amorçable”. Cela fait de nombreux mois que cette situation existe sans que cela me cause le moindre problème jusqu’aux jours derniers où ça a commencé à foirer de plus en plus jusqu’à l’interruption du mode graphique (gnome) en ne laissant que le mode “dépannage” accessible.

Le technicien a “désactivé” la partition “amorçable” du second HDD (ma machine boote sur le premier HDD !) dans le fichier fstab et maintenant, j’ai récupéré ma machine qui refonctionne comme avant.

Je ne sais toujours pas le pourquoi ni le comment de ces deux partitions “amorçables”, une sur chacun de mes disques durs. Il est probable que j’ai fait une fausse manœuvre lors du partitionnement du second HDD, mais c’est tellement loin déjà que je ne m’en souviens plus.

Puisque cette partition du second HDD est inutile, y a-t-il un moyen simple de la supprimer ou bien GParted et reformater entièrement ce HDD (qui ne contient que les sauvegardes automatiques de mon “home” ?
Quelle est la moins pire des solutions ?

Merci.

#3

Voici le retour de fdisk :

/home/guy# /sbin/fdisk -l
Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : ST1000DM003-1ER1
Unités : secteur de 1 × 512 = 512 octets
Taille de secteur (logique / physique) : 512 octets / 4096 octets
taille d'E/S (minimale / optimale) : 4096 octets / 4096 octets
Type d'étiquette de disque : dos
Identifiant de disque : 0x000e5530

Périphérique Amorçage Début        Fin   Secteurs Taille Id Type
/dev/sdb1    *         2046 1953523711 1953521666 931,5G  5 Étendue
/dev/sdb5              2048 1953523711 1953521664 931,5G 83 Linux

La partition 1 ne commence pas sur une frontière de cylindre physique.


Disque /dev/sda : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
Modèle de disque : WDC WD1002FAEX-0
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 : 0x0002da7d

Périphérique Amorçage     Début        Fin   Secteurs Taille Id Type
/dev/sda1    *             2048  409601657  409599610 195,3G 83 Linux
/dev/sda2             409602048  450562047   40960000  19,5G 82 partition d'écha
/dev/sda3             450562048 1953523711 1502961664 716,7G 83 Linux

C’est au niveau de sdb1 que se situerait le problème qui a causé mes déboires, d’après le technicien qui a remis ma machine en route.

Le retour de df :

/home/guy# df
Sys. de fichiers blocs de 1K   Utilisé Disponible Uti% Monté sur
udev                 4036156         0    4036156   0% /dev
tmpfs                 811200      9736     801464   2% /run
/dev/sda1          200536140   7734980  182544788   5% /
tmpfs                4055984         0    4055984   0% /dev/shm
tmpfs                   5120         4       5116   1% /run/lock
tmpfs                4055984         0    4055984   0% /sys/fs/cgroup
/dev/sdb5          961301832 162605676  749841732  18% /mnt/interne
/dev/sda3          739557344 192331868  509635052  28% /home
tmpfs                 811196        40     811156   1% /run/user/1000

A+

#4

Bonjour

…
Disque /dev/sdb : 931,5 GiB, 1000204886016 octets, 1953525168 secteurs
…
/dev/sdb1    *         2046 1953523711 1953521666 931,5G  5 Étendue
/dev/sdb5              2048 1953523711 1953521664 931,5G 83 Linux
…

Effectivement, une partition de type étendue
ne peux pas être utilisée comme une partition amorçable
puisque ce type de partition n’est pas destiné à contenir un système de gestion de fichiers,
mais seulement d’autres partitions (de type logique).

#5

En effet. Comme j’utilisais plus de 4 partitions, je devais créer une partition étendue.
Mais comment est-elle devenue “amorçable” ???
Et surtout comment se fait-il que cela a fonctionné de très très longs mois sans problème avant la panne ???

Les mystèèèèères insondaaaaables de l’informatique :grin::thinking:

Merci pour ton intervention.

#6

Ça ne tient pas la route. Soit tu as mal compris les explications du technicien, soit il t’a pipeauté.

Un problème sur la racine ne se résoud pas en modifiant /etc/fstab car la racine est initialement montée en lecture seule par l’initramfs à partir des options de la ligne de commande du noyau passées par le chargeur d’amorçage (root, rootflags, rootfstype) et non de /etc/fstab. Ce n’est que dans un second temps, quand l’initramfs a passé la main à l’init du système (sysvinit ou systemd), que la racine est remontée en lecture-écriture et les options de montage définies pour la racine dans /etc/fstab sont appliquées.

Commenter la ligne correspondant à la racine dans /etc/fstab ne fait qu’empêcher d’appliquer les options de montage définies dans le fichier. D’autre part, c’était parfaitement inutile si le système a été ensuite réinstallé, puisque la racine a été écrasée. Et je ne vois pas le rapport avec le non fonctionnement des ports USB, surtout au démarrage alors que Debian n’est pas lancé.

Et c’est normal, c’est une situation parfaitement banale.

La présence d’une partition “amorçable” (boot flag) sur chaque disque est une situation parfaitement normale.

Là encore, soit tu as mal compris soit le technicien t’a pipeauté. Un partition amorçable ne se désactive pas dans /etc/fstab. Le drapeau amorçable se trouve dans la table de partition, pas dans /etc/fstab, et le montage d’une partition dans /etc/fstab n’a rien à voir avec la présence ou l’absence de ce drapeau.

Bien sûr que si. Le premier secteur d’une partition étendue, appelé EBR (extended boot record) a la même structure que le MBR du disque et peut parfaitement contenir un programme d’amorce.

Aucun rapport avec l’incapacité à contenir un système de fichiers, tout comme un disque entier partitionné.

#7

Merci pour ces précision PascalHambourg,

Pour infos, voici le contenu de ce fstab :

# /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/sdc1 during installation
UUID=10b4c5f0-743b-4a4b-932e-2b12d188fcc4 /               ext4    errors=remount-ro 0       1
# /Back_Up_Interne was on /dev/sdb5 during installation
UUID=df2e3ab0-10f3-4c11-b358-d541737461be /mnt/interne ext4    defaults        0       2
# /Back_Up_Seagate was on /dev/sda1 during installation
#UUID=8a545573-927b-4395-91ce-4d6257e99b01 /mnt/seagate ext4    defaults        0       2

# /Back_Up_Interne was on /dev/sdb5 during installation
#UUID=df2e3ab0-10f3-4c11-b358-d541737461be /Back_Up_Interne ext4    defaults        0       2
# /Back_Up_Seagate was on /dev/sda1 during installation
#UUID=8a545573-927b-4395-91ce-4d6257e99b01 /Back_Up_Seagate ext4    defaults        0       2

# /home was on /dev/sdc3 during installation
UUID=ae2dcc93-c083-4f76-82c8-d49ad1f2a820 /home           ext4    defaults        0       2

# swap was on /dev/sdc2 during installation
UUID=1a0a4238-7dd7-4557-9566-cfe296d4ef3d none            swap    sw              0       0
/dev/sr0        /media/cdrom0   udf,iso9660 user,noauto     0       0

On peut remarquer qu’il y a deux fois le même groupe de lignes :

# /Back_Up_Interne was on /dev/sdb5 during installation
#UUID=df2e3ab0-10f3-4c11-b358-d541737461be /Back_Up_Interne ext4    defaults        0       2
# /Back_Up_Seagate was on /dev/sda1 during installation
#UUID=8a545573-927b-4395-91ce-4d6257e99b01 /Back_Up_Seagate ext4    defaults        0       2

et que dans la première occurrence, la seconde ligne (UUID=8a5455…) n’est pas commentée alors qu’elle l’a été dans la seconde.
C’est après avoir commenté cette ligne dans la seconde occurrence que cela a refonctionné normalement.
Pourquoi deux fois le même ensemble de lignes ?
Encore un mystère. C’est la première fois que je constate cela.

A+

#8

Merci pour l’info concernant l’EBR
Désolé d’avoir écrit tout ça sans prendre le temps nécessaire de vérifier.:face_with_hand_over_mouth:

#9

Non, les deux groupes ne sont pas identiques : les points de montage sont différents.

Si, elle est commentée. C’est la première ligne (UUID=df2e3ab0…) qui ne l’est pas.

Attends, je ne comprends pas. Plus haut tu as écrit que le technicien avait complètement réinstallé Debian, et maintenant tu dis qu’il a suffi de modifier /etc/fstab ? On pourrait savoir ce qui a été fait exactement à la fin ?

Manifestement, /etc/fstab a été édité manuellement et les points de montage ont été modifiés :

  • /Back_Up_Interne a été remplacé par /mnt/interne
  • /Back_Up_Seagate a été remplacé par /mnt/seagate

(au passage, c’est une mauvaise idée de définir des points de montage permanents dans /mnt qui est prévu pour les montages temporaires manuels).

Ce fichier fstab mentionne trois disques alors que fdisk n’en recense que deux. Qu’est devenu le disque manquant ? Si un disque référencé par fstab est manquant, pas étonnant que le système ne démarre pas normalement.

On peut voir la sortie de blkid ?

#10

Bonjour PascalHambourg,

Merci pour ton intervention.

Je n’ai aucun souvenir d’une intervention manuelle de mon propre chef de ma part dans ce fichier. J’y connais tellement peu que je ne m’y aventurerai jamais.

Je me souviens que j’ai eu, un moment donné, un problème avec un HDD interne de sauvegarde qui a été réglé sur ce site. Et actuellement, la sauvegarde auto fonctionne toujours normalement (j’ai vérifié les noms de fichiers de sauvegarde sur le HDD en question). En effet, nous avons modifié le nom des HDD pour plus de simplicité. Cela a été fait en ligne de commande selon des “directives” reçues sur ce site. Et cela a bien fonctionné puisque les sauvegardes se font normalement :wink:

Ce fichier fstab mentionne trois disques alors que fdisk n’en recense que deux. Qu’est devenu le disque manquant ?

C’est normal, le 3° disque est un HDD externe connecté en USB que j’ai enlevé quand les problèmes de démarrage sont apparu. Il recevait une autre sauvegarde hebdomadaire de mes données.

La sortie de la commande :

/home/guy# /sbin/blkid
/dev/sda1: UUID="10b4c5f0-743b-4a4b-932e-2b12d188fcc4" TYPE="ext4" PARTUUID="0002da7d-01"
/dev/sda2: UUID="1a0a4238-7dd7-4557-9566-cfe296d4ef3d" TYPE="swap" PARTUUID="0002da7d-02"
/dev/sda3: UUID="ae2dcc93-c083-4f76-82c8-d49ad1f2a820" TYPE="ext4" PARTUUID="0002da7d-03"
/dev/sdb5: LABEL="Back-up" UUID="df2e3ab0-10f3-4c11-b358-d541737461be" TYPE="ext4" PARTUUID="000e5530-05"

Une réinstallation complète de Debian avec formatage de la partition / ne serait-elle pas profitable, préférable à des tentatives de manipulations diverses ? Ce genre d’action ne me pose habituellement pas de gros problème.

A+

#11

Si le montage automatique au démarrage de ce disque n’a pas été commenté dans /etc/fstab en même temps, enlever ce disque provoque l’entrée systématique en mode dépannage (emergency shell). Maintenant le contenu de /etc/fstab est en conformité avec les volumes présents et le démarrage peut se poursuivre normalement.

Quels problèmes reste-t-il encore ?
En tout cas les problèmes d’USB que tu évoquais dans ton message initial n’ont rien à voir avec /etc/fstab.

#12

Bonjour PascalHambourg,

Merci pour toutes ces infos rassurantes.

Mon ordi fonctionne maintenant tout à fait normalement depuis que j’ai remplacé la face avant qui contenait les prises USB défaillantes ainsi qu’une barrette de ram elle aussi défectueuse.

Je me posais la question d’une réinstallation à cause de mon ignorance à propos de ces fichiers très spécifiques (fstab et autres) dont je ne sais pratiquement rien :wink:

Tes infos et celles des autres intervenants m’ont été d’une très grande utilité pour en savoir un (tout) petit plus sur le fonctionnement de Débian.

Merci.