Contenu | Rechercher | Menus

Annonce

L'équipe des administrateurs et modérateurs du forum vous invite à prendre connaissance des nouvelles règles.
En cas de besoin, vous pouvez intervenir dans cette discussion.

Ubuntu 18.04 LTS
Ubuntu-fr propose des clés USB de Ubuntu et toutes ses « saveurs » ainsi qu'un magnifique t-shirt pour cette toute nouvelle version d'Ubuntu !

Si vous avez des soucis pour rester connecté, déconnectez-vous puis reconnectez-vous depuis ce lien en cochant la case
Me connecter automatiquement lors de mes prochaines visites.

À propos de l'équipe du forum.

#1 Le 13/02/2018, à 15:50

golgoth63

modification fstab en toute sécurité : méthodologie

Bonjour,

Dernière modification par golgoth63 (Hier à 18:05)


Kubuntu 18.04 LTS / KDE neon 5.12 LTS  / Oracle Solaris 11.3
Ne vous offusquez pas pour des insultes, c'est le langage de ceux qui n'ont rien à dire d'intelligent.
forum ubuntu, un forum ou un épicier vous insulte et va vous apprendre l'informatique !

Hors ligne

#2 Le 13/02/2018, à 18:23

DonutMan75

Re : modification fstab en toute sécurité : méthodologie

Bonjour,
merci pour le partage smile

Par contre le "sudo gedit" pique les yeux...
https://doc.ubuntu-fr.org/sudo

Hors ligne

#3 Le 13/02/2018, à 18:36

Hizoka

Re : modification fstab en toute sécurité : méthodologie

Salut,
n'hesite pas à mettre à jour la doc : https://doc.ubuntu-fr.org/mount_fstab

Hors ligne

#4 Le 13/02/2018, à 19:27

Naziel

Re : modification fstab en toute sécurité : méthodologie

golgoth63 a écrit :

D- Est ce que mes posts intéressent du monde ? Pas convaincu.

Bah si smile . C'est le genre de fil pratique dont on peut donner le lien pour aider une personne qui a des problèmes avec son fstab, donc je considère ton fil comme utile.
Contribuer à la doc, c'est pas forcément écrire des pages et des pages, ça peut être simplement corriger des trucs par ci par là (c'est ce que je fais personnellement)

Hors ligne

#5 Le 13/02/2018, à 20:17

Hizoka

Re : modification fstab en toute sécurité : méthodologie

C'est dommage de ne pas tenir à jour la doc.
c'est un travail commun smile

Hors ligne

#6 Le 14/02/2018, à 11:03

kholo

Re : modification fstab en toute sécurité : méthodologie

la doc devrait être théorique avec des cas pratiques dans le forum.
ça c'est la théorie...
d'une façon générale on trouve tout entre la doc et le forum...
ce pourquoi j'alimente essentiellement le forum.
ensuite on peut juste mettre des liens dans la doc avec un simple résumé.
par exemple la post installation, point 4 voir ici
on peut mettre un lien vers un fil complet ou vers un post en particulier.

Hors ligne

#7 Le 14/02/2018, à 12:19

moko138

Re : modification fstab en toute sécurité : méthodologie

golgoth63,
Tu montres l'utilité de commencer par faire une copie de sécurité ;
Tu indiques une méthode sans  {sudo + commande graphique} ;
Bien !

  Mais surtout, je trouve ton exposé :

  • particulièrement astucieux dans le contenu
      je pense à l'idée du fichier intermédiaire dans le home,
    qui permet le test sans modifier fstab d'emblée,
      puis, après la réussite du test, l'injection du contenu du fichier intermédiaire dans le fstab :
    c'est l'élégance même !
      - -

  • et très pédagogique dans la présentation,

en particulier l'art et la manière d'utiliser sa copie de sécurité en cas de pépin.


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#8 Le 14/02/2018, à 18:13

ar barzh paour

Re : modification fstab en toute sécurité : méthodologie

pour avoir une procédure correcte il faudrait ajouter dans le post #1 la création du point de montage
on ne peut pas faire mount si le point de montage n'existe pas et n'est pas vide

EDIT  d'après un post qui suit (#30) je rectifie en supprimant "et n'est pas vide"
mais je rajoute "en général" il faut mieux qu'il soit vide (j'ai fait l'essai réel)

Dernière modification par ar barzh paour (Le 16/02/2018, à 16:07)


Ubuntu 16.04 64 bits (depuis juillet 2016) , 18.04 en essai (décembre 2017)
divers versions (peu utilisées maintenant) Ubuntu et Studio 14.04 LTS 64 bits , MATE 16.04
(03/2018) : PC          : Intel(R) Pentium(R) CPU G4600 @ 3.60GHz  + 4GiB RAM DDR4-2400
(06/2017) : Portable : Intel(R) Core(TM)2  Duo CPU     T5750  @ 2.00GHz 3Go de RAM DDR2 667 Mhz

Hors ligne

#9 Le 15/02/2018, à 09:04

ar barzh paour

Re : modification fstab en toute sécurité : méthodologie

non c'est pas ce que je voulais dire , l'idée  est excellente mais

golgoth63 a écrit :

Il s'agit maintenant de tester ce montage.

sudo mount -a --fstab /home/eric/nouveaumedia.fstab

je me trompe peut-être mais ça ne fonctionne pas si le répertoire n'est pas créé et n'est pas vide
(dans l'exemple tu prends /Windows)
reprends-moi si je me trompe

cat nouveaumedia.fstab
UUID=672B204C384159C7 /media/Z fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096  0 0
sudo mount -a --fstab nouveaumedia.fstab
Mot de passe de jpb : 
mount: mount point /media/Z does not exist


là aujourd'hui par contre tu as raison en 16.04

golgoth63 a écrit :

...et le système va planter si ton fstab est modifié et que tu reboot.

mais en 14.04 on obtient un message

une erreur est survenue lors du montage de /media/Z
Appuyer sur S pour passer le montage ou M pour récupération manuelle

Dernière modification par ar barzh paour (Le 15/02/2018, à 09:54)


Ubuntu 16.04 64 bits (depuis juillet 2016) , 18.04 en essai (décembre 2017)
divers versions (peu utilisées maintenant) Ubuntu et Studio 14.04 LTS 64 bits , MATE 16.04
(03/2018) : PC          : Intel(R) Pentium(R) CPU G4600 @ 3.60GHz  + 4GiB RAM DDR4-2400
(06/2017) : Portable : Intel(R) Core(TM)2  Duo CPU     T5750  @ 2.00GHz 3Go de RAM DDR2 667 Mhz

Hors ligne

#10 Le 15/02/2018, à 14:29

ar barzh paour

Re : modification fstab en toute sécurité : méthodologie

golgoth63 post15 a écrit :

PS : avec la 17.10, tu as une erreur si le rép. n'existe pas. tu es sur de l'absence d'erreur avec la 16.04 ? Bizarre.

non ce n'est pas ce que j'ai écrit
c'est en 14.04 qu'il y a demande de confirmation de montage
en 16.04 le systeme plante


autre remarque dans les valeurs de montage je me suis contenté de recopié ce qu'il y avait dans /etc/mtab , (donc je ne suis pas sur que ces valeurs soient correctes)

UUID=672B204C384159C7 /media/Z fuseblk rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096  0 0

EDIT je viens de trouver dans cette doc $2
https://doc.ubuntu-fr.org/tutoriel/mont … atiquement

il peut être nécessaire de modifier la ligne pour faire apparaître le format de la partition à monter. Exemple pour une partition ntfs (cf le TYPE retourné lors de la commande sudo blkid) : /dev/sdX /media/XXX fuseblk rw,nosuid,… devient /dev/sdX /media/XXX ntfs rw,nosuid,….

c'est le cas que j'ai utilisé
il faudrait donc mettre ntfs à la place de fuseblk et je ne suis pas sur des autres paramètres ... je ferai l'essai en réel

UUID=672B204C384159C7 /media/Z ntfs rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other,blksize=4096  0 0

Dernière modification par ar barzh paour (Le 15/02/2018, à 19:59)


Ubuntu 16.04 64 bits (depuis juillet 2016) , 18.04 en essai (décembre 2017)
divers versions (peu utilisées maintenant) Ubuntu et Studio 14.04 LTS 64 bits , MATE 16.04
(03/2018) : PC          : Intel(R) Pentium(R) CPU G4600 @ 3.60GHz  + 4GiB RAM DDR4-2400
(06/2017) : Portable : Intel(R) Core(TM)2  Duo CPU     T5750  @ 2.00GHz 3Go de RAM DDR2 667 Mhz

Hors ligne

#11 Le 15/02/2018, à 14:52

moko138

Re : modification fstab en toute sécurité : méthodologie

[HS]

ar barzh paour a écrit :

c'est en 14.04 qu'il y a demande de confirmation de montage
en 16.04 le systeme plante

...D'où l'utilité, jusqu'à 16.04, de l'option de montage nofail ! (même pour la swap), option qui évite de suspendre le démarrage parce qu'un UUID est erroné ou qu'une ntfs est en hibernation.

À partir de 17.04 (ou 17.10), le système fait comme si l'option nofail était écrite.
                                   [/HS]


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#12 Le 15/02/2018, à 15:44

ar barzh paour

Re : modification fstab en toute sécurité : méthodologie

@moko : ça ne plait pas non plus à 18.04
j'ai mis un mauvais uuid dans fstab (manque le 7 de fin 672B204C384159C7)

UUID=672B204C384159C /media/Z ntfs     defaults       0    0

j'obtiens

févr. 15 14:32:51 jpb-POWERMATE-VL280 systemd[1]: dev-disk-by\x2duuid-672B204C384159C.device: Job dev-disk-by\x2duuid-672B204C384159C.device/start timed out.

et en final plantage (après un temps de recherche qui m'a paru "assez long")
je m'empresse de remettre fstab en ordre !!!

Dernière modification par ar barzh paour (Le 15/02/2018, à 15:56)


Ubuntu 16.04 64 bits (depuis juillet 2016) , 18.04 en essai (décembre 2017)
divers versions (peu utilisées maintenant) Ubuntu et Studio 14.04 LTS 64 bits , MATE 16.04
(03/2018) : PC          : Intel(R) Pentium(R) CPU G4600 @ 3.60GHz  + 4GiB RAM DDR4-2400
(06/2017) : Portable : Intel(R) Core(TM)2  Duo CPU     T5750  @ 2.00GHz 3Go de RAM DDR2 667 Mhz

Hors ligne

#13 Le 15/02/2018, à 16:18

moko138

Re : modification fstab en toute sécurité : méthodologie

"assez long", c'était exactement 90 secondes, dans 16.04.0.


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#14 Le 15/02/2018, à 16:34

ar barzh paour

Re : modification fstab en toute sécurité : méthodologie

en 18.04 d'après journalctl 2mn15 entre le reboot et le rendu de main

févr. 15 14:31:21 jpb-POWERMATE-VL280 kernel: microcode: microcode updated early to revision 0xa4, date = 2010-10-02
...
févr. 15 14:33:36 jpb-POWERMATE-VL280 systemd[1]: Started Stop ureadahead data collection.

Ubuntu 16.04 64 bits (depuis juillet 2016) , 18.04 en essai (décembre 2017)
divers versions (peu utilisées maintenant) Ubuntu et Studio 14.04 LTS 64 bits , MATE 16.04
(03/2018) : PC          : Intel(R) Pentium(R) CPU G4600 @ 3.60GHz  + 4GiB RAM DDR4-2400
(06/2017) : Portable : Intel(R) Core(TM)2  Duo CPU     T5750  @ 2.00GHz 3Go de RAM DDR2 667 Mhz

Hors ligne

#15 Le 16/02/2018, à 10:02

bruno

Re : modification fstab en toute sécurité : méthodologie

golgoth63 a écrit :

A plusieurs reprise, j'ai pu lire :

pour modifier le fstab 
          sudo  gedit  /etc/fstab
et ajouter la ligne
          /dev/xxxx /Windows ntfs rw,nosuid,nodev,allow_other,default_permissions,blksize=4096 0 0

Peut-être parce qu'il manque les options noauto,x-systemd.automount. Il n'y a généralement pas de raison de vouloir monter automatiquement une partition contenant ce type de système de fichiers automatiquement au démarrage.

Avec ces options systemd montera la partition à la demande (à la première tentative d'accès au point de montage).

On peut aussi utiliser ces deux options combinées : nofail,x-systemd.device-timeout=5 Ainsi au lieu du temps d'attente de 90s par défaut (nofail) on aura que 5 secondes de « blocage » au démarrage en cas de souci.

Pour finir là dessus, on peut éventuellement se passer complètement du fichier /etc/fstab et utiliser des unités .mount et .automount de systemd.

Dernière modification par bruno (Le 16/02/2018, à 10:04)

Hors ligne

#16 Le 16/02/2018, à 11:43

bruno

Re : modification fstab en toute sécurité : méthodologie

Je parle aussi de méthodologie wink
La bonne méthode pour ne pas bloquer le démarrage de la machine, c'est d'abord de ne pas monter automatiquement des partitions qui n'en ont pas besoin, me semble-t-il.
L'utilisation des unités systemd est une méthode alternative à l'utilisation du fichier fstab.

Maintenant je trouve ta façon de faire particulièrement alambiquée (ou alors je n'ai rien compris).

Quand on veut modifier un fichier de configuration, on fait toujours au préalable une copie du fichier original.
On teste sa modification et en cas de blocage on revient au fichier original.
Ce qui donne dans le cas du fstab :

sudo cp /etc/fstab /etc/fstab.orig
sudo nano /etc/fstab

on modifie… on enregistre…

On teste :

sudo mount -a

Si après on est bloqué au redémarrage :

root > cp /etc/fstab.orig /etc/fstab

Dernière modification par bruno (Le 16/02/2018, à 11:44)

Hors ligne

#17 Le 16/02/2018, à 12:22

moko138

Re : modification fstab en toute sécurité : méthodologie

bruno a écrit :

Quand on veut modifier un fichier de configuration, on fait toujours au préalable une copie du fichier original. On teste sa modification et en cas de blocage on revient au fichier original.
Ce qui donne dans le cas du fstab :

sudo cp /etc/fstab /etc/fstab.orig

(...)
On teste :
(...)

Bravo ! Très pertinent ! C'est d'ailleurs pour ça que golgoth63 l'avait dit dès le 1er message.


%NOINDEX%
Un utilitaire méconnu : ncdu

Hors ligne

#18 Le 16/02/2018, à 12:43

bruno

Re : modification fstab en toute sécurité : méthodologie

Oui merci j’avais bien lu. Sauf que la copie du fichier d'origine est ce qui devrait être fait en premier e't du coup tout le reste de la procédure me semble inutilement alambiqué…

Hors ligne

#19 Le 16/02/2018, à 14:04

Hizoka

Re : modification fstab en toute sécurité : méthodologie

Perso, j'aime bien cette sécurité aussi.

Merci pour cet explication.

Il vaut mieux prévenir que guérir...

Hors ligne

#20 Le 16/02/2018, à 14:11

FrancisFDZ

Re : modification fstab en toute sécurité : méthodologie

ar barzh paour a écrit :

pour avoir une procédure correcte il faudrait ajouter dans le post #1 la création du point de montage
on ne peut pas faire mount si le point de montage n'existe pas et n'est pas vide

Si, on peut monter une partition sur un répertoire existant non vide, les fichiers pré-existant de ce répertoire ne seront simplement plus accessibles tant que le répertoire sera monté.


-- On peut avoir des raisons de se plaindre et n'avoir pas raison de se plaindre --
[Victor Hugo]

Hors ligne

#21 Le 16/02/2018, à 14:50

bruno

Re : modification fstab en toute sécurité : méthodologie

golgoth63 a écrit :

@bruno

Je reprends ta méthode :
1- copie
2- modification d'un fichier système sans connaitre le résultat
3- test
.... plantage éventuel.....flute panne de courant, l'ordi s'arrête !  Ou papa ! à table ! ....
4- correction.

Pour rappel, tu es sur un système multi utilisateurs, multi process. Entre 3 & 4, c'est dieux pour tous et croise les doigts !


et ma méthode (qui au passage n'est, comme je l'ai indiqué au #1, pas de moi) :
1- création d'un fichier perso
2- test pour voir si le système accepte la modification
...si le système ne retourne pas d'erreur
3- copie de sauvegarde (au passage, ton .ori n'est valable que la première fois, tu modifies peut-être un fichier déjà modifié d'où la date)
4- redirection (pas de saisie au clavier, c'est important) dans le fichier système
5- re test

Je crois que tu n'as pas compris avec ma méthode j'ai :
1. copié un fichier de configuration que je sais fonctionnel (peut importe qu'il ait déjà été modifié ou pas);
2. modifié directement le fichier de configuration sans passer par des opérations compliqués de création d'un autre fichier puis injection de son contenu dans le précédent ;
3. testé la modification en relançant les opérations de montage (comme toi) ;
4. au cas (improbable) où mon système bloque au prochain démarrage je restaure la copie fonctionnelle (comme toi).

Et je comprends absolument pas le sens de tes remarques entre le point 3 et 4.

Maintenant si tu préfères te compliquer la vie, libre à toi wink

Hors ligne

#22 Le 16/02/2018, à 15:18

bruno

Re : modification fstab en toute sécurité : méthodologie

Oui mais je ne comprends pas du tout en quoi ta méthode éviterait cela. Tu peux de la même manière te retrouver avec un système qui ne démarre pas. Ce n'est pas parce que tu as lancé 2 fois un test de montage au lieu d'une que cela change quelque chose…

EDIT : pour ton post #32 il manque probablement une spécificité liée à la livebox que tu utilises (un paramètre d’authentification sec ou un numéro de version SMB, ou autre bizarerie), mais ça tu as du le voir directement en testant avec la commande mount …

Dernière modification par bruno (Le 16/02/2018, à 15:38)

Hors ligne

#23 Le 16/02/2018, à 16:18

ar barzh paour

Re : modification fstab en toute sécurité : méthodologie

@ bruno
peux-tu donner un contre-exemple , j'ai cherché , pas trouvé
j'ai fait des essais avec (l'UUID est correct , ntfs aussi)
UUID=672B204C384159C7 /media/Z ntfs defau  0 0
avec
UUID=672B204C384159C7 /media/Z ntfs 0 0
ces lignes ont toutes marché bien que contenant une erreur , mais n'ont pas fait planté le système

Dernière modification par ar barzh paour (Le 18/02/2018, à 12:16)


Ubuntu 16.04 64 bits (depuis juillet 2016) , 18.04 en essai (décembre 2017)
divers versions (peu utilisées maintenant) Ubuntu et Studio 14.04 LTS 64 bits , MATE 16.04
(03/2018) : PC          : Intel(R) Pentium(R) CPU G4600 @ 3.60GHz  + 4GiB RAM DDR4-2400
(06/2017) : Portable : Intel(R) Core(TM)2  Duo CPU     T5750  @ 2.00GHz 3Go de RAM DDR2 667 Mhz

Hors ligne

#24 Le 16/02/2018, à 16:46

bruno

Re : modification fstab en toute sécurité : méthodologie

Un contre exemple de quoi ?
Je disais juste que la méthode golgoth63 me semblait inutilement compliquée et je proposait une alternative plus simple et strictement équivalente.
Après, golgoth63 me dit que ma méthode n'est pas bonne (cf. #34) parce que je risque d'avoir un système qui ne démarre pas. Mais il n'explique pas en quoi sa méthode permettrait d'éviter cela.

Maintenant si tu écris effectivement une ânerie (par exemple un UUID qui n'existe pas) dans le fstab et que tu redémarres directement avec, le système va bloquer pendant 90s avant d'afficher une invite de commande. D'où ma suggestion en #22 de mettre systématiquement dans les options nofail,x-systemd.device-timeout=5 (ça ne bloquera que pendant 5 secondes.

Si  tu écris effectivement une ânerie dans le fstab et que tu test avant avec la commande (le verbose est facultatif) :

mount -a --verbose

tu auras un message d'erreur, tu corriges ton fstab et tu recommences la boucle.

Si tu n'as pas de message d'erreur et que ta partition est bien montée il me semble assez improbable que la machine bloque au prochain démarrage, mais cela peut arriver quelque soit la méthode utilisée.

Hors ligne

#25 Le 16/02/2018, à 16:49

bruno

Re : modification fstab en toute sécurité : méthodologie

golgoth63 a écrit :

Avec ta méthode tu modifies un fichier système sans aucun test préalable, c'est tout. Poum, j'édite, je sauve ! A chaud et sans préservatif.

Bah je doit être bouché smile
Je ne comprends pas pourquoi je testerai un fichier que je sais être fonctionnel et dont je commence par faire une copie de secours.

Hors ligne