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 ?
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 ?
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).
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
Ç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é.
# /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.
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.
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
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.
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.
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.
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
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.
