Je suis en train d'installer debian sur un ordi qui avait précedamment
windows 7. Avant d'installer j'ai fait un tour dans windows pour voir
les données que j'allais devoir récupérér. Il y avait une partition C:
avec le système et quelques données, sur laquelle il restait 5 Go de
libre. Le système prenant environ 50 Go, je me suis dit que j'allais
gagner de la place. Il y avait aussi une partition D: pleine de données
raz la gueule.
J'ai installé en faisant une swap de 4 Go, une partition root de 20 Go
et une partition /home a laquelle j'ai donné tout le reste de la place.
Bilan : 5 Go de libre + 50 Go de windows - 4 Go de swap - 20 Go de
debian, je pensais qu'une fois le /home rempli toutes les donnés il y
resterait une trentaine de Go de libre.
Et c'est bien ce que me dit gparted :
/dev/sda3 ext4 /home taille 572,11 Gio utilisé 541,36 Gio inutilisé
30,75 Gio
Par contre j'ai des messages d'alerte "attention la partition /home n'a
plus que 2,2 Go d'espace libre" et c'est aussi ce que me dit df -h :
/dev/sda3 ext4 taille 563G utilisé 532G dispo 2,2G 100% /home
Du coup je comprend pas ou sont passés les 28 Go manquants. Ca fait
raler que les memes donnés prennent plus de place sur du ext4 que sur du
ntfs…
Mais finalement, peut-être qu'on pourrait directement utiliser le fichier bloc stockant /home tel que rapporté par la commande `df`, plutôt que d'aller voir dans le fichier fstab, si d'aventure il devait ne pas être à jour ? (À moins bien sûr que ce ne soit à dessein.) #!/bin/bash set -e homedevice="$( df /home | grep -v '^Filesystem' | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Attention, si le /home n'est pas sur une partition séparée,
A tester auparavant avec mountpoint.
Oh la jolie petite commande bien pratique ! Merci pour l'information, on ne fait pas assez de publicité à son sujet. :) Bien à vous, -- Étienne Mollier
Pascal Hambourg, au 2019-04-06 :
Le 04/04/2019 à 23:21, Étienne Mollier a écrit :
> Mais finalement, peut-être qu'on pourrait directement utiliser
> le fichier bloc stockant /home tel que rapporté par la commande
> `df`, plutôt que d'aller voir dans le fichier fstab, si
> d'aventure il devait ne pas être à jour ? (À moins bien sûr que
> ce ne soit à dessein.)
>
> #!/bin/bash
> set -e
> homedevice="$(
> df /home
> | grep -v '^Filesystem'
> | cut -f1 -d' '
> )"
> tune2fs -m 0 "$homedevice"
>
> Attention, si le /home n'est pas sur une partition séparée,
A tester auparavant avec mountpoint.
Oh la jolie petite commande bien pratique !
Merci pour l'information, on ne fait pas assez de publicité à
son sujet. :)
Bien à vous,
--
Étienne Mollier <etienne.mollier@mailoo.org>
Mais finalement, peut-être qu'on pourrait directement utiliser le fichier bloc stockant /home tel que rapporté par la commande `df`, plutôt que d'aller voir dans le fichier fstab, si d'aventure il devait ne pas être à jour ? (À moins bien sûr que ce ne soit à dessein.) #!/bin/bash set -e homedevice="$( df /home | grep -v '^Filesystem' | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Attention, si le /home n'est pas sur une partition séparée,
A tester auparavant avec mountpoint.
Oh la jolie petite commande bien pratique ! Merci pour l'information, on ne fait pas assez de publicité à son sujet. :) Bien à vous, -- Étienne Mollier
Stephane Ascoet
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
Il faut tout réinstaller (maudit copyright).
Bonjour, ce n'est pas qu'une question de copyright, mais aussi de conception merdique. Meme un deplacement a l'identique du dossier d'un utilisateur d'un ordinateur a l'autre ne fonctionne pas... alors que c'est une operation presque de routine sous GNU/Linux... Par contre, dans la technique "transfert de Debian", la partie Grub peut etre galere, surtout avec UEFI :-( Hamster:
D'un autre coté utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien dit.
Non, si /home n'est pas un point de montage, il n'a pas de raison d'apparaitre en sortie de df.
Je note le lien. J'ai déjà fait des recherches de tutos pour faire des scripts shell mais comme souvent je me suis perdu dans la profusion.
Je trouve les documentations en ligne bien moins pratiques que les livres pour ma part :-( Et, par rapport a une autre remarque, j'ai du mal a me passer des bashismes. C'est deja tellement rustique, alors si en plus on doit se limiter a la syntaxe sh, ne pas utiliser d'outils GNU ajoutes apres 1992... au secours.
Mon doigt a glissé et comme le h est juste a coté du f c'est lui qui a pris.
Bepoiste? ;-) Pascal:
Non, tu as bien compris. Par défaut un système de fichiers ext* réserve 5% de l'espace à son utilisateur créateur, c'est-à-dire root la plupart du temps. Concrètement, cela signifie que quand l'espace utilisé atteint 95%, les autres utilisateurs ne peuvent plus allouer d'espace.
Je n'utilise pas Ext, mais du coup je me demande, pour les adeptes de cette famille de FS, l'affichage de df change t-il selon qui est connecte? Ou alors on peut continuer a ecrire en root alors que la place disponible indiquee est nulle? Yann Serre:
Sans volonté particulière de raviver ce sujet, en ce moment je lis et j'entends 9 GAFA pour 1 GAFAM (sans doute moins encore).
Je confirme :-( -- Cordialement, Stephane Ascoet
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
Il faut tout réinstaller (maudit copyright).
Bonjour, ce n'est pas qu'une question de copyright, mais aussi de
conception merdique. Meme un deplacement a l'identique du dossier d'un
utilisateur d'un ordinateur a l'autre ne fonctionne pas... alors que
c'est une operation presque de routine sous GNU/Linux...
Par contre, dans la technique "transfert de Debian", la partie Grub peut
etre galere, surtout avec UEFI :-(
Hamster:
D'un autre coté
utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien
dit.
Non, si /home n'est pas un point de montage, il n'a pas de raison
d'apparaitre en sortie de df.
Je note le lien. J'ai déjà fait des recherches de tutos pour faire des
scripts shell mais comme souvent je me suis perdu dans la profusion.
Je trouve les documentations en ligne bien moins pratiques que les
livres pour ma part :-( Et, par rapport a une autre remarque, j'ai du
mal a me passer des bashismes. C'est deja tellement rustique, alors si
en plus on doit se limiter a la syntaxe sh, ne pas utiliser d'outils GNU
ajoutes apres 1992... au secours.
Mon doigt a glissé et comme le h est juste a coté du f c'est lui qui a pris.
Bepoiste? ;-)
Pascal:
Non, tu as bien compris. Par défaut un système de fichiers ext* réserve 5% de l'espace à son utilisateur créateur, c'est-à-dire root la plupart du temps. Concrètement, cela signifie que quand l'espace utilisé atteint 95%, les autres utilisateurs ne peuvent plus allouer d'espace.
Je n'utilise pas Ext, mais du coup je me demande, pour les adeptes de
cette famille de FS, l'affichage de df change t-il selon qui est
connecte? Ou alors on peut continuer a ecrire en root alors que la place
disponible indiquee est nulle?
Yann Serre:
Sans volonté particulière de raviver ce sujet, en ce moment je lis et j'entends 9 GAFA pour 1 GAFAM (sans doute moins encore).
Bonjour, ce n'est pas qu'une question de copyright, mais aussi de conception merdique. Meme un deplacement a l'identique du dossier d'un utilisateur d'un ordinateur a l'autre ne fonctionne pas... alors que c'est une operation presque de routine sous GNU/Linux... Par contre, dans la technique "transfert de Debian", la partie Grub peut etre galere, surtout avec UEFI :-( Hamster:
D'un autre coté utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien dit.
Non, si /home n'est pas un point de montage, il n'a pas de raison d'apparaitre en sortie de df.
Je note le lien. J'ai déjà fait des recherches de tutos pour faire des scripts shell mais comme souvent je me suis perdu dans la profusion.
Je trouve les documentations en ligne bien moins pratiques que les livres pour ma part :-( Et, par rapport a une autre remarque, j'ai du mal a me passer des bashismes. C'est deja tellement rustique, alors si en plus on doit se limiter a la syntaxe sh, ne pas utiliser d'outils GNU ajoutes apres 1992... au secours.
Mon doigt a glissé et comme le h est juste a coté du f c'est lui qui a pris.
Bepoiste? ;-) Pascal:
Non, tu as bien compris. Par défaut un système de fichiers ext* réserve 5% de l'espace à son utilisateur créateur, c'est-à-dire root la plupart du temps. Concrètement, cela signifie que quand l'espace utilisé atteint 95%, les autres utilisateurs ne peuvent plus allouer d'espace.
Je n'utilise pas Ext, mais du coup je me demande, pour les adeptes de cette famille de FS, l'affichage de df change t-il selon qui est connecte? Ou alors on peut continuer a ecrire en root alors que la place disponible indiquee est nulle? Yann Serre:
Sans volonté particulière de raviver ce sujet, en ce moment je lis et j'entends 9 GAFA pour 1 GAFAM (sans doute moins encore).
Je confirme :-( -- Cordialement, Stephane Ascoet
ajh-valmer
On Tuesday 09 April 2019 17:04:34 Stephane Ascoet wrote:
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
M$-Windows : Il faut tout réinstaller (maudit copyright).
ce n'est pas qu'une question de copyright, mais aussi de conception merdique. Meme un deplacement a l'identique du dossier d'un utilisateur d'un ordinateur a l'autre ne fonctionne pas... alors que c'est une operation presque de routine sous GNU/Linux...
Surtout pour raisons financières :-) empêcher de réinstaller windows sur un autre ordinateur. On a le droit de changer d'ordinateur, de disque dur... et de garder windows dont on a une licence. Merdique aussi, car même si c'était possible, il faut tout réinstaller windows depuis zéro, alors que sous Linux, il suffit de réinstaller avec rsync et on retrouve son linux au complet.
On Tuesday 09 April 2019 17:04:34 Stephane Ascoet wrote:
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
> M$-Windows : Il faut tout réinstaller (maudit copyright).
ce n'est pas qu'une question de copyright, mais aussi de
conception merdique. Meme un deplacement a l'identique du dossier d'un
utilisateur d'un ordinateur a l'autre ne fonctionne pas... alors que
c'est une operation presque de routine sous GNU/Linux...
Surtout pour raisons financières :-)
empêcher de réinstaller windows sur un autre ordinateur.
On a le droit de changer d'ordinateur, de disque dur... et de garder
windows dont on a une licence.
Merdique aussi, car même si c'était possible,
il faut tout réinstaller windows depuis zéro,
alors que sous Linux, il suffit de réinstaller avec rsync
et on retrouve son linux au complet.
On Tuesday 09 April 2019 17:04:34 Stephane Ascoet wrote:
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
M$-Windows : Il faut tout réinstaller (maudit copyright).
ce n'est pas qu'une question de copyright, mais aussi de conception merdique. Meme un deplacement a l'identique du dossier d'un utilisateur d'un ordinateur a l'autre ne fonctionne pas... alors que c'est une operation presque de routine sous GNU/Linux...
Surtout pour raisons financières :-) empêcher de réinstaller windows sur un autre ordinateur. On a le droit de changer d'ordinateur, de disque dur... et de garder windows dont on a une licence. Merdique aussi, car même si c'était possible, il faut tout réinstaller windows depuis zéro, alors que sous Linux, il suffit de réinstaller avec rsync et on retrouve son linux au complet.
Pascal Hambourg
Le 09/04/2019 à 17:04, Stephane Ascoet a écrit :
Hamster:
utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien dit.
Non, si /home n'est pas un point de montage, il n'a pas de raison d'apparaitre en sortie de df.
De l'aveu même de son auteur, le script fourni dans le message auquel Hamster répondait se contente d'extraire le périphérique contenant /home, sans vérifier le point de montage. Je le remets : #!/bin/bash set -e homedevice="$( df /home | grep -v '^Filesystem' | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Au passage, la méthode pour écarter la ligne d'en-têtes n'est pas fiable car elle dépend de la langue d'affichage. Il aurait mieux valu utiliser tail pour extraire la dernière ligne.
Le 09/04/2019 à 17:04, Stephane Ascoet a écrit :
Hamster:
utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien
dit.
Non, si /home n'est pas un point de montage, il n'a pas de raison
d'apparaitre en sortie de df.
De l'aveu même de son auteur, le script fourni dans le message auquel
Hamster répondait se contente d'extraire le périphérique contenant
/home, sans vérifier le point de montage. Je le remets :
Au passage, la méthode pour écarter la ligne d'en-têtes n'est pas fiable
car elle dépend de la langue d'affichage. Il aurait mieux valu utiliser
tail pour extraire la dernière ligne.
utiliser la sortie de df risque de faire agir sur / comme tu l'a si bien dit.
Non, si /home n'est pas un point de montage, il n'a pas de raison d'apparaitre en sortie de df.
De l'aveu même de son auteur, le script fourni dans le message auquel Hamster répondait se contente d'extraire le périphérique contenant /home, sans vérifier le point de montage. Je le remets : #!/bin/bash set -e homedevice="$( df /home | grep -v '^Filesystem' | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Au passage, la méthode pour écarter la ligne d'en-têtes n'est pas fiable car elle dépend de la langue d'affichage. Il aurait mieux valu utiliser tail pour extraire la dernière ligne.
=c3
Pascal Hambourg, au 2019-04-09 :
Au passage, la méthode pour écarter la ligne d'en-têtes n'est pas fiable car elle dépend de la langue d'affichage. Il aurait mieux valu utiliser tail pour extraire la dernière ligne.
Oui, une autre solution aurait pu aussi consister à s'en tenir à la locale C : #!/bin/bash set -e export LANG=C homedevice="$( df /home | grep -v '^Filesystem' | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Amicalement, -- Étienne Mollier Ce qui est bien, c'est qu'il y a plein de manières de faire. Ce qui est terrible, c'est qu'il y a encore plus de manières de se prendre les pieds dans le tapis.
Pascal Hambourg, au 2019-04-09 :
Au passage, la méthode pour écarter la ligne d'en-têtes n'est
pas fiable car elle dépend de la langue d'affichage. Il aurait
mieux valu utiliser tail pour extraire la dernière ligne.
Oui, une autre solution aurait pu aussi consister à s'en tenir à
la locale C :
Ce qui est bien, c'est qu'il y a plein de manières de faire.
Ce qui est terrible, c'est qu'il y a encore plus de manières de
se prendre les pieds dans le tapis.
Au passage, la méthode pour écarter la ligne d'en-têtes n'est pas fiable car elle dépend de la langue d'affichage. Il aurait mieux valu utiliser tail pour extraire la dernière ligne.
Oui, une autre solution aurait pu aussi consister à s'en tenir à la locale C : #!/bin/bash set -e export LANG=C homedevice="$( df /home | grep -v '^Filesystem' | cut -f1 -d' ' )" tune2fs -m 0 "$homedevice" Amicalement, -- Étienne Mollier Ce qui est bien, c'est qu'il y a plein de manières de faire. Ce qui est terrible, c'est qu'il y a encore plus de manières de se prendre les pieds dans le tapis.
hamster
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
Après, je copie Debian à partir d'un de mes 3 ordinateurs, et j'adapte fstab, toujours sous slitaz et grub avec Super Grub Disk . Reboot, et je me retrouve avec un système Debian complet prêt à l'emploi.
Ca veut dire que tu a un nom d'utilisateur identique sur tous les ordis que tu installe ? Si non, comment tu gère le renommage ?
Le 04/04/2019 à 20:30, ajh-valmer a écrit :
Après, je copie Debian à partir d'un de mes 3 ordinateurs,
et j'adapte fstab, toujours sous slitaz et grub avec Super Grub Disk .
Reboot, et je me retrouve avec un système Debian complet prêt à l'emploi.
Ca veut dire que tu a un nom d'utilisateur identique sur tous les ordis
que tu installe ? Si non, comment tu gère le renommage ?
Après, je copie Debian à partir d'un de mes 3 ordinateurs, et j'adapte fstab, toujours sous slitaz et grub avec Super Grub Disk . Reboot, et je me retrouve avec un système Debian complet prêt à l'emploi.
Ca veut dire que tu a un nom d'utilisateur identique sur tous les ordis que tu installe ? Si non, comment tu gère le renommage ?
hamster
Le 06/04/2019 à 10:40, Pascal Hambourg a écrit :
Ceci étant, quand on a des liens symboliques, c'est un peu dommage de ne pas s'en servir, il est tout à fait possible d'appliquer le `tune2fs` directement sur le disque par UUID. Le système se charge de résoudre le lien symbolique vers le fichier bloc correspondant pour l'opération : homedevice="/dev/disk/by-uuid/$homeUUID"
Encore plus simple : comme mount, tune2fs accepte directement la syntaxe UUID=<uuid> ou LABEL=<uuid> à la place du nom de périphérique. On ne lit pas assez attentivement les pages de manuel. Mais attention : 1) Vérifier que le système de fichiers est ext?, sinon la commande tune2fs ne fonctionnera pas. 2) L'identification du système de fichiers à monter sur /home ne se fait pas forcément par UUID. Ou bien si c'est un volume logique LVM ou un volume chiffré, l'installateur utilise /dev/mapper/<volume>. Ou bien l'administrateur a pu la remplacer par LABEL, PARTLABEL ou PARTUUID.
Attention, si le /home n'est pas sur une partition séparée,
A tester auparavant avec mountpoint
Au final j'en arrive a ca : #!/bin/bash set -e if ! mountpoint -q /home then echo "/home n'est pas sur une partition separee" exit 1 fi if [[ "$(grep "/home" /etc/mtab | cut -d" " -f3)" = "ext?" ]] then echo "la partition /home n'est pas au format ext" exit 2 fi tune2fs -m 0 "$( grep "/home" /etc/mtab | cut -d" " -f1 )" exit 0 Ca n'agit que si /home est sur une partition dédiée au format ext?, ca agit sur le truc qui est monté sur /home au moment ou on exécute le script, quel que soit sa désignation. Et au passage j'ai beaucoup progressé en scriptage. Merci a tous.
Le 06/04/2019 à 10:40, Pascal Hambourg a écrit :
Ceci étant, quand on a des liens symboliques, c'est un peu
dommage de ne pas s'en servir, il est tout à fait possible
d'appliquer le `tune2fs` directement sur le disque par UUID. Le
système se charge de résoudre le lien symbolique vers le fichier
bloc correspondant pour l'opération :
homedevice="/dev/disk/by-uuid/$homeUUID"
Encore plus simple : comme mount, tune2fs accepte directement la
syntaxe UUID=<uuid> ou LABEL=<uuid> à la place du nom de périphérique.
On ne lit pas assez attentivement les pages de manuel.
Mais attention :
1) Vérifier que le système de fichiers est ext?, sinon la commande
tune2fs ne fonctionnera pas.
2) L'identification du système de fichiers à monter sur /home ne se
fait pas forcément par UUID. Ou bien si c'est un volume logique LVM ou
un volume chiffré, l'installateur utilise /dev/mapper/<volume>. Ou
bien l'administrateur a pu la remplacer par LABEL, PARTLABEL ou PARTUUID.
Attention, si le /home n'est pas sur une partition séparée,
A tester auparavant avec mountpoint
Au final j'en arrive a ca :
#!/bin/bash
set -e
if ! mountpoint -q /home
then
echo "/home n'est pas sur une partition separee"
exit 1
fi
if [[ "$(grep "/home" /etc/mtab | cut -d" " -f3)" = "ext?" ]]
then
echo "la partition /home n'est pas au format ext"
exit 2
fi
Ca n'agit que si /home est sur une partition dédiée au format ext?, ca
agit sur le truc qui est monté sur /home au moment ou on exécute le
script, quel que soit sa désignation.
Et au passage j'ai beaucoup progressé en scriptage. Merci a tous.
Ceci étant, quand on a des liens symboliques, c'est un peu dommage de ne pas s'en servir, il est tout à fait possible d'appliquer le `tune2fs` directement sur le disque par UUID. Le système se charge de résoudre le lien symbolique vers le fichier bloc correspondant pour l'opération : homedevice="/dev/disk/by-uuid/$homeUUID"
Encore plus simple : comme mount, tune2fs accepte directement la syntaxe UUID=<uuid> ou LABEL=<uuid> à la place du nom de périphérique. On ne lit pas assez attentivement les pages de manuel. Mais attention : 1) Vérifier que le système de fichiers est ext?, sinon la commande tune2fs ne fonctionnera pas. 2) L'identification du système de fichiers à monter sur /home ne se fait pas forcément par UUID. Ou bien si c'est un volume logique LVM ou un volume chiffré, l'installateur utilise /dev/mapper/<volume>. Ou bien l'administrateur a pu la remplacer par LABEL, PARTLABEL ou PARTUUID.
Attention, si le /home n'est pas sur une partition séparée,
A tester auparavant avec mountpoint
Au final j'en arrive a ca : #!/bin/bash set -e if ! mountpoint -q /home then echo "/home n'est pas sur une partition separee" exit 1 fi if [[ "$(grep "/home" /etc/mtab | cut -d" " -f3)" = "ext?" ]] then echo "la partition /home n'est pas au format ext" exit 2 fi tune2fs -m 0 "$( grep "/home" /etc/mtab | cut -d" " -f1 )" exit 0 Ca n'agit que si /home est sur une partition dédiée au format ext?, ca agit sur le truc qui est monté sur /home au moment ou on exécute le script, quel que soit sa désignation. Et au passage j'ai beaucoup progressé en scriptage. Merci a tous.
Cette expression n'est pas assez sélective. Elle prend en compte n'importe quel montage contenant "/home" dans le point de montage (/home/data) ou le périphérique (/dev/vg/home).
Cette expression n'est pas assez sélective. Elle prend en compte
n'importe quel montage contenant "/home" dans le point de montage
(/home/data) ou le périphérique (/dev/vg/home).
Cette expression n'est pas assez sélective. Elle prend en compte n'importe quel montage contenant "/home" dans le point de montage (/home/data) ou le périphérique (/dev/vg/home).
Cette expression n'est pas assez sélective. Elle prend en compte n'importe quel montage contenant "/home" dans le point de montage (/home/data) ou le périphérique (/dev/vg/home).
Très juste. Je pense que rajouter des espaces résout le problème : if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]
Cette expression n'est pas assez sélective. Elle prend en compte
n'importe quel montage contenant "/home" dans le point de montage
(/home/data) ou le périphérique (/dev/vg/home).
Très juste. Je pense que rajouter des espaces résout le problème :
if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]
Cette expression n'est pas assez sélective. Elle prend en compte n'importe quel montage contenant "/home" dans le point de montage (/home/data) ou le périphérique (/dev/vg/home).
Très juste. Je pense que rajouter des espaces résout le problème : if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]
Cette expression n'est pas assez sélective. Elle prend en compte n'importe quel montage contenant "/home" dans le point de montage (/home/data) ou le périphérique (/dev/vg/home).
Très juste. Je pense que rajouter des espaces résout le problème : if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]
C'est mieux, et probablement suffisant. Pour provoquer un faux positif il faudrait un chemin contenant des espaces, ce qui n'est pas courant.
Cette expression n'est pas assez sélective. Elle prend en compte
n'importe quel montage contenant "/home" dans le point de montage
(/home/data) ou le périphérique (/dev/vg/home).
Très juste. Je pense que rajouter des espaces résout le problème :
if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]
C'est mieux, et probablement suffisant. Pour provoquer un faux positif
il faudrait un chemin contenant des espaces, ce qui n'est pas courant.
Cette expression n'est pas assez sélective. Elle prend en compte n'importe quel montage contenant "/home" dans le point de montage (/home/data) ou le périphérique (/dev/vg/home).
Très juste. Je pense que rajouter des espaces résout le problème : if [[ "$(grep " /home " /etc/mtab | cut -d" " -f3)" = "ext?" ]]
C'est mieux, et probablement suffisant. Pour provoquer un faux positif il faudrait un chemin contenant des espaces, ce qui n'est pas courant.
