[opensuse-fr] Mélayage de pinceaux !
Salut tout le monde, J’utilise "rsync" pour sauver complètement et occasionnellement mon système utilisé quotidiennement. À priori, je ne le fais que lorsque je veux mettre à jour ou installer des paquets. Bien sûr, je lance l’exécution de rsync après avoir redémarré un système de secours. j’ai une petite partition pour ça sur mon premier disque. Ce système de secours devrait démarrer sur /dev/disk/by-label/2-SSD_sec, mais quelque chose (Grub? Linux?) semble chercher un disque qui ne peut pas exister. On peut lire sur l’image jointe : Loading Linux 4.1.34-33-defaut ... loading initial ramdisk ... [ *] A start job is running for dev-disk-by\x2dlabel-1\x2dst500_sav.device … (NOTE \x2d est un caractère ASCII ’-’ NOTE un device /dev/disk/by-label/1-st500_sav a existé et est toujours listé dans /etc/fstab, mais il n’est pas connecté) J’ai réinstallé grub depuis mon système usuel et redémarré le système de secours une SEULE fois avec succes. Puis j’ai décidé de réinstaller grub depuis ce système de secours (et ayant fait ma sauvegarde !). Mais en essayant de redémarrer à nouveau, ce message apparaît toujours. J’ai retenté depuis mon système courant, mais là, l’erreur persiste. Quelqu’un a-t-il une idée qui pourrait m’aider à résoudre le problème ? Si je ne peux pas faire mieux, et comme je pense avoir mis à jour ce système de secours, je réinstallerai à partir de zéro et ne ferai aucune mise à jour :-/ . Je vous remercie pour l’attention que vous aurez porté à ce courriel. Patrick Serru
In data martedì 24 gennaio 2017 12:06:30, Patrick Serru ha scritto:
Salut tout le monde,
J’utilise "rsync" pour sauver complètement et occasionnellement mon système utilisé quotidiennement. À priori, je ne le fais que lorsque je veux mettre à jour ou installer des paquets. Bien sûr, je lance l’exécution de rsync après avoir redémarré un système de secours. j’ai une petite partition pour ça sur mon premier disque.
Ce système de secours devrait démarrer sur /dev/disk/by-label/2-SSD_sec, mais quelque chose (Grub? Linux?) semble chercher un disque qui ne peut pas exister. On peut lire sur l’image jointe : Loading Linux 4.1.34-33-defaut ... loading initial ramdisk ... [ *] A start job is running for dev-disk-by\x2dlabel-1\x2dst500_sav.device …
(NOTE \x2d est un caractère ASCII ’-’ NOTE un device /dev/disk/by-label/1-st500_sav a existé et est toujours listé dans /etc/fstab, mais il n’est pas connecté)
J’ai réinstallé grub depuis mon système usuel et redémarré le système de secours une SEULE fois avec succes. Puis j’ai décidé de réinstaller grub depuis ce système de secours (et ayant fait ma sauvegarde !). Mais en essayant de redémarrer à nouveau, ce message apparaît toujours. J’ai retenté depuis mon système courant, mais là, l’erreur persiste.
Quelqu’un a-t-il une idée qui pourrait m’aider à résoudre le problème ? Si je ne peux pas faire mieux, et comme je pense avoir mis à jour ce système de secours, je réinstallerai à partir de zéro et ne ferai aucune mise à jour :-/ .
Je vous remercie pour l’attention que vous aurez porté à ce courriel.
Patrick Serru
Bonsoir. Peut-être une question débile, mais, tu viens de 13.2 pour mettre au jour vers 42.1 ou tu veux aller de 42.1 vers 42.2? Le système de secours à été créé originalement en 13.2 et après mis au jours, ou directement avec 42.1? Je demande ceci parce que je pense de me rappeler qu' il y a eu une changement entre 13.2 et 42.1 pour ce qui concerne les noms des disques. Ça fait par contre un baie et donc je me rappelle pas bien sur le coup. -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le mardi 24 janvier 2017, stakanov a écrit :
In data martedì 24 gennaio 2017 12:06:30, Patrick Serru ha scritto:
Salut tout le monde,
J’utilise "rsync" pour sauver complètement et occasionnellement mon système utilisé quotidiennement. À priori, je ne le fais que lorsque je veux mettre à jour ou installer des paquets. Bien sûr, je lance l’exécution de rsync après avoir redémarré un système de secours. j’ai une petite partition pour ça sur mon premier disque.
Ce système de secours devrait démarrer sur /dev/disk/by-label/2-SSD_sec, mais quelque chose (Grub? Linux?) semble chercher un disque qui ne peut pas exister. On peut lire sur l’image jointe : Loading Linux 4.1.34-33-defaut ... loading initial ramdisk ... [ *] A start job is running for dev-disk-by\x2dlabel-1\x2dst500_sav.device …
(NOTE \x2d est un caractère ASCII ’-’ NOTE un device /dev/disk/by-label/1-st500_sav a existé et est toujours listé dans /etc/fstab, mais il n’est pas connecté)
J’ai réinstallé grub depuis mon système usuel et redémarré le système de secours une SEULE fois avec succes. Puis j’ai décidé de réinstaller grub depuis ce système de secours (et ayant fait ma sauvegarde !). Mais en essayant de redémarrer à nouveau, ce message apparaît toujours. J’ai retenté depuis mon système courant, mais là, l’erreur persiste.
Quelqu’un a-t-il une idée qui pourrait m’aider à résoudre le problème ? Si je ne peux pas faire mieux, et comme je pense avoir mis à jour ce système de secours, je réinstallerai à partir de zéro et ne ferai aucune mise à jour :-/ .
Je vous remercie pour l’attention que vous aurez porté à ce courriel.
Patrick Serru
Bonsoir. Peut-être une question débile, mais, tu viens de 13.2 pour mettre au jour vers 42.1 ou tu veux aller de 42.1 vers 42.2?
Le système de secours à été créé originalement en 13.2 et après mis au jours, ou directement avec 42.1? Je demande ceci parce que je pense de me rappeler qu' il y a eu une changement entre 13.2 et 42.1 pour ce qui concerne les noms des disques. Ça fait par contre un baie et donc je me rappelle pas bien sur le coup.
Bonjours Stakanov, Merci pour la réponse. Tous les systems dont il est question ont été installés depuis rien et en Oss 42.1. Cordialement Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
In data martedì 24 gennaio 2017 12:32:37, Patrick Serru ha scritto:
Le mardi 24 janvier 2017, stakanov a écrit :
In data martedì 24 gennaio 2017 12:06:30, Patrick Serru ha scritto:
Salut tout le monde,
J’utilise "rsync" pour sauver complètement et occasionnellement mon
système utilisé quotidiennement. À priori, je ne le fais que lorsque je veux mettre à jour ou installer des paquets. Bien sûr, je lance l’exécution de rsync après avoir redémarré un système de secours. j’ai une petite partition pour ça sur mon premier disque.
Ce système de secours devrait démarrer sur
/dev/disk/by-label/2-SSD_sec, mais quelque chose (Grub? Linux?) semble chercher un disque qui ne peut pas exister. On peut lire sur l’image
jointe : Loading Linux 4.1.34-33-defaut ... loading initial ramdisk ...
[ *] A start job is running for dev-disk-by\x2dlabel-1\x2dst500_sav.device …
(NOTE \x2d est un caractère ASCII ’-’
NOTE un device /dev/disk/by-label/1-st500_sav a existé et est toujours
listé dans /etc/fstab, mais il n’est pas connecté)
J’ai réinstallé grub depuis mon système usuel et redémarré le système
de secours une SEULE fois avec succes. Puis j’ai décidé de réinstaller grub depuis ce système de secours (et ayant fait ma sauvegarde !). Mais en essayant de redémarrer à nouveau, ce message apparaît toujours. J’ai retenté depuis mon système courant, mais là, l’erreur persiste.
Quelqu’un a-t-il une idée qui pourrait m’aider à résoudre le problème
? Si je ne peux pas faire mieux, et comme je pense avoir mis à jour ce système de secours, je réinstallerai à partir de zéro et ne ferai aucune mise à jour :-/ .
Je vous remercie pour l’attention que vous aurez porté à ce courriel.
Patrick Serru
Bonsoir. Peut-être une question débile, mais, tu viens de 13.2 pour mettre au jour vers 42.1 ou tu veux aller de 42.1 vers 42.2?
Le système de secours à été créé originalement en 13.2 et après mis au jours, ou directement avec 42.1? Je demande ceci parce que je pense de me rappeler qu' il y a eu une changement entre 13.2 et 42.1 pour ce qui concerne les noms des disques. Ça fait par contre un baie et donc je me rappelle pas bien sur le coup.
----------------------- Bonjours Stakanov,
Merci pour la réponse. Tous les systems dont il est question ont été installés depuis rien et en Oss 42.1.
Cordialement
Patrick Est-ce que tu peux
cat /etc/fstab ? pour comprendre un peu mieux.... Donc le système ne se mette plus du tous en marche ou le système de sauvetage ne le fait pas? -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le mardi 24 janvier 2017, stakanov a écrit :
In data martedì 24 gennaio 2017 12:32:37, Patrick Serru ha scritto:
Le mardi 24 janvier 2017, stakanov a écrit :
In data martedì 24 gennaio 2017 12:06:30, Patrick Serru ha scritto:
Salut tout le monde,
J’utilise "rsync" pour sauver complètement et occasionnellement mon
système utilisé quotidiennement. À priori, je ne le fais que lorsque je veux mettre à jour ou installer des paquets. Bien sûr, je lance l’exécution de rsync après avoir redémarré un système de secours. j’ai une petite partition pour ça sur mon premier disque.
Ce système de secours devrait démarrer sur
/dev/disk/by-label/2-SSD_sec, mais quelque chose (Grub? Linux?) semble chercher un disque qui ne peut pas exister. On peut lire sur l’image
jointe : Loading Linux 4.1.34-33-defaut ... loading initial ramdisk ...
[ *] A start job is running for dev-disk-by\x2dlabel-1\x2dst500_sav.device …
(NOTE \x2d est un caractère ASCII ’-’
NOTE un device /dev/disk/by-label/1-st500_sav a existé et est toujours
listé dans /etc/fstab, mais il n’est pas connecté)
J’ai réinstallé grub depuis mon système usuel et redémarré le système
de secours une SEULE fois avec succes. Puis j’ai décidé de réinstaller grub depuis ce système de secours (et ayant fait ma sauvegarde !). Mais en essayant de redémarrer à nouveau, ce message apparaît toujours. J’ai retenté depuis mon système courant, mais là, l’erreur persiste.
Quelqu’un a-t-il une idée qui pourrait m’aider à résoudre le problème
? Si je ne peux pas faire mieux, et comme je pense avoir mis à jour ce système de secours, je réinstallerai à partir de zéro et ne ferai aucune mise à jour :-/ .
Je vous remercie pour l’attention que vous aurez porté à ce courriel.
Patrick Serru
Bonsoir. Peut-être une question débile, mais, tu viens de 13.2 pour mettre au jour vers 42.1 ou tu veux aller de 42.1 vers 42.2?
Le système de secours à été créé originalement en 13.2 et après mis au jours, ou directement avec 42.1? Je demande ceci parce que je pense de me rappeler qu' il y a eu une changement entre 13.2 et 42.1 pour ce qui concerne les noms des disques. Ça fait par contre un baie et donc je me rappelle pas bien sur le coup.
----------------------- Bonjours Stakanov,
Merci pour la réponse. Tous les systems dont il est question ont été installés depuis rien et en Oss 42.1.
Cordialement
Patrick
Est-ce que tu peux
cat /etc/fstab ? pour comprendre un peu mieux....
Donc le système ne se mette plus du tous en marche ou le système de sauvetage ne le fait pas?
En fait le système de secours n'est qu'une installation 42.1 minimum. Joindre le ficher va le rendre plus lisible... Seuls les st3500 et samsung sont connectés, en plus du SSD bien sûr. Je me souviens qu'après l'installation, le disque était référencé par son UUID, dans /etc/fstab, et j'ai immédiatement rendu les choses plus humaine :-) Tout ça a fonctionné quelques mois ! Et souvent au début ! Je suis convaincu que ça commencé à débloquer suite à une mise à jour en ligne. Cordialement Patrick
In data martedì 24 gennaio 2017 14:37:51, Patrick Serru ha scritto:
Je me souviens qu'après l'installation, le disque était référencé par son UUID, dans /etc/fstab, et j'ai immédiatement rendu les choses plus humaine
Voilà ton problème. Avec le UUID tu ne l'aurais pas. Parce que, selon la situation du début, le système va chercher un disque que n'existe pas parce que il ne peut pas vérifier que le disque n'est pas disponible (i.e. pendant le redémarrage). Au moins je pense que ceci devrait faire la différence. Les outils de système de installation minimal vont probablement chercher l'utilisation du UUID. Je vais un peut chercher si il y a des références disponibles. -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
A propos, je viens de voir ça: est-ce qu'il y a (en temps normales bien sur) une raison pourquoi tu n'utilise pas le paramètre noatimes pour le ssd? -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Donc, le LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0 N'est plus du tout utilisé et non plus dan la machine ou tu l'as déconnectés? -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le mardi 24 janvier 2017, stakanov a écrit :
A propos, je viens de voir ça: est-ce qu’il y a (en temps normales bien sur) une raison pourquoi tu n’utilise pas le paramètre noatimes pour le ssd?
La bonne raison pour laquelle je n’utilise pas noatimes est… l’ignorance de son existence ! Je viens de jeter un œil : le jeu en vaut-il la chandelle ? Surtout qu’avec un SSD le gain de temps est déjà prodigieux. Le mardi 24 janvier 2017, stakanov a écrit :
Donc, le
LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0
N’est plus du tout utilisé et non plus dan la machine ou tu l’as déconnectés?
Oui. Ce disque me sert de temps en temps pour faire une duplication de /linux/7-samsung_sav, sur lequel j’ai des années d’archives. Je le confis ensuite à quelqu’un qui n’habite pas au même endroit que moi. J’ai longtemps gardé en commentaire la ligne où il était fait référence à l’UUID de la partition racine, mais c’est parti. L’UUID de cette partition que peut m’indique le système journalier (sur lequel je poste actuellement) sera le même que celui connu par Grub/Linux au moment de monter le système de secours ? Grâce à ls -l /dev/disk/by-uuid/ et ls -l /dev/disk/by-label/, je peux conclure que l’UUID de la partition qui m’intéresse est 0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd Je vais tenter de modifier fstab pour voir ce que cela donne. C’est bien ainsi LABEL=2-SSD_sec / ext4 acl,user_xattr 1 1 -> UUID=0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd / ext4 acl,user_xattr 1 1 En attendant la confirmation, je vais tenter de rebooter après avoir commenté les lignes de fstab relatives aux st500. Pour ma défense, Grub, X et Open Suse n’ont pas toujours été merveilleux, et cette histoire d’UUID ajoutait une bonne couche de désarroi supplémentaire. C’est à cette époque difficile que j'ai appris à haïr l'UUID :-) C’est vrai que pour une partition racine… mais ça continue d'être humainement illisible y compris dans fstab ! Cordialement, Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le mardi 24 janvier 2017, Patrick Serru a écrit :
Le mardi 24 janvier 2017, stakanov a écrit :
A propos, je viens de voir ça: est-ce qu’il y a (en temps normales bien sur) une raison pourquoi tu n’utilise pas le paramètre noatimes pour le ssd?
La bonne raison pour laquelle je n’utilise pas noatimes est… l’ignorance de son existence ! Je viens de jeter un œil : le jeu en vaut-il la chandelle ? Surtout qu’avec un SSD le gain de temps est déjà prodigieux.
Le mardi 24 janvier 2017, stakanov a écrit :
Donc, le
LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0
N’est plus du tout utilisé et non plus dan la machine ou tu l’as déconnectés?
Oui. Ce disque me sert de temps en temps pour faire une duplication de /linux/7-samsung_sav, sur lequel j’ai des années d’archives. Je le confis ensuite à quelqu’un qui n’habite pas au même endroit que moi.
J’ai longtemps gardé en commentaire la ligne où il était fait référence à l’UUID de la partition racine, mais c’est parti. L’UUID de cette partition que peut m’indique le système journalier (sur lequel je poste actuellement) sera le même que celui connu par Grub/Linux au moment de monter le système de secours ? Grâce à ls -l /dev/disk/by-uuid/ et ls -l /dev/disk/by-label/, je peux conclure que l’UUID de la partition qui m’intéresse est 0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd Je vais tenter de modifier fstab pour voir ce que cela donne. C’est bien ainsi LABEL=2-SSD_sec / ext4 acl,user_xattr 1 1 -> UUID=0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd / ext4 acl,user_xattr 1 1
En attendant la confirmation, je vais tenter de rebooter après avoir commenté les lignes de fstab relatives aux st500.
Pour ma défense, Grub, X et Open Suse n’ont pas toujours été merveilleux, et cette histoire d’UUID ajoutait une bonne couche de désarroi supplémentaire. C’est à cette époque difficile que j'ai appris à haïr l'UUID :-) C’est vrai que pour une partition racine… mais ça continue d'être humainement illisible y compris dans fstab !
Cordialement,
Patrick
Je viens de booter deux fois sans problème avec - les deux lignes relatives aux partitions du disque dur non moté en commantaire, - grub installé depuis mon système "quitidient", dont la partition racine est également sur le SSD. Bug ? Cordialement, Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
In data martedì 24 gennaio 2017 17:25:39, Patrick Serru ha scritto:
Le mardi 24 janvier 2017, Patrick Serru a écrit :
Le mardi 24 janvier 2017, stakanov a écrit :
A propos, je viens de voir ça: est-ce qu’il y a (en temps normales bien sur) une raison pourquoi tu n’utilise pas le paramètre noatimes pour le ssd?
La bonne raison pour laquelle je n’utilise pas noatimes est…
l’ignorance de son existence ! Je viens de jeter un œil : le jeu en vaut-il la chandelle ? Surtout qu’avec un SSD le gain de temps est déjà prodigieux.
Le mardi 24 janvier 2017, stakanov a écrit :
Donc, le
LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0
N’est plus du tout utilisé et non plus dan la machine ou tu l’as déconnectés?
Oui. Ce disque me sert de temps en temps pour faire une duplication
de /linux/7-samsung_sav, sur lequel j’ai des années d’archives. Je le confis ensuite à quelqu’un qui n’habite pas au même endroit que moi.
J’ai longtemps gardé en commentaire la ligne où il était fait référence
à l’UUID de la partition racine, mais c’est parti. L’UUID de cette partition que peut m’indique le système journalier (sur lequel je poste actuellement) sera le même que celui connu par Grub/Linux au moment de monter le système de secours ? Grâce à ls -l /dev/disk/by-uuid/ et ls -l /dev/disk/by-label/, je peux conclure que l’UUID de la partition qui m’intéresse est 0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd Je vais tenter de modifier fstab pour voir ce que cela donne. C’est bien ainsi LABEL=2-SSD_sec / ext4 acl,user_xattr 1 1 ->
UUID=0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd / ext4 acl,user_xattr 1 1
En attendant la confirmation, je vais tenter de rebooter après avoir
commenté les lignes de fstab relatives aux st500.
Pour ma défense, Grub, X et Open Suse n’ont pas toujours été
merveilleux, et cette histoire d’UUID ajoutait une bonne couche de désarroi supplémentaire. C’est à cette époque difficile que j'ai appris à haïr l'UUID :-) C’est vrai que pour une partition racine… mais ça continue d'être humainement illisible y compris dans fstab !
Cordialement,
Patrick
---------------------- Je viens de booter deux fois sans problème avec - les deux lignes relatives aux partitions du disque dur non moté en commantaire, - grub installé depuis mon système "quitidient", dont la partition racine est également sur le SSD.
Bug ?
Cordialement,
Patrick Oui je pense bug report serait indiqué.
noatime: voyons, normalement on disait (surtout pour les premiers ssd, que avoir le swap sur ssd va détruire le ssd. Je ne peut pas confirmer ceci, j'ai un adata pro 900 est il marche toujours a merveille. Donc, pour swap en tous cas noatimes est une valeur bonne. Aussi pour /root j'ai l'expérience que ceci peut induire une vitesse de démarrage légèrement plus rapide. Malheureusement, je n'ai pas un ssd pour le home pour le moment. Je pense noatime pour le /home va se rendre utile quand on ha a déplacer des grandes quantités de petit fichier. Une autre chose, je pense tu utilise (intelligemment, moi de même) ext4 pour tes partitions. Ext4 ha un très bonne support pour trim, cependant pour une question d'économie des temps de démarrage je préfère de ne le pas mettre "institutionnalisé" en fstab ce valeur. (valeur serait: discard). Il suffit en effet chaque 6 mois de ouvrir la CLI est taper: sudo fstrim -a -v /linux (dans ton cas naturellement) et attendre longtemps - il va te dire ce qu'il a fait. En combinaison avec noatime, ceci donne, à mon expérience, des bonnes résultats. Amuse toi bien ;-) "stak" -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le mardi 24 janvier 2017, stakanov a écrit :
In data martedì 24 gennaio 2017 17:25:39, Patrick Serru ha scritto:
Le mardi 24 janvier 2017, Patrick Serru a écrit :
Le mardi 24 janvier 2017, stakanov a écrit :
A propos, je viens de voir ça: est-ce qu’il y a (en temps normales bien sur) une raison pourquoi tu n’utilise pas le paramètre noatimes pour le ssd?
La bonne raison pour laquelle je n’utilise pas noatimes est…
l’ignorance de son existence ! Je viens de jeter un œil : le jeu en vaut-il la chandelle ? Surtout qu’avec un SSD le gain de temps est déjà prodigieux.
Le mardi 24 janvier 2017, stakanov a écrit :
Donc, le
LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0
N’est plus du tout utilisé et non plus dan la machine ou tu l’as déconnectés?
Oui. Ce disque me sert de temps en temps pour faire une duplication
de /linux/7-samsung_sav, sur lequel j’ai des années d’archives. Je le confis ensuite à quelqu’un qui n’habite pas au même endroit que moi.
J’ai longtemps gardé en commentaire la ligne où il était fait référence
à l’UUID de la partition racine, mais c’est parti. L’UUID de cette partition que peut m’indique le système journalier (sur lequel je poste actuellement) sera le même que celui connu par Grub/Linux au moment de monter le système de secours ? Grâce à ls -l /dev/disk/by-uuid/ et ls -l /dev/disk/by-label/, je peux conclure que l’UUID de la partition qui m’intéresse est 0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd Je vais tenter de modifier fstab pour voir ce que cela donne. C’est bien ainsi LABEL=2-SSD_sec / ext4 acl,user_xattr 1 1 ->
UUID=0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd / ext4 acl,user_xattr 1 1
En attendant la confirmation, je vais tenter de rebooter après avoir
commenté les lignes de fstab relatives aux st500.
Pour ma défense, Grub, X et Open Suse n’ont pas toujours été
merveilleux, et cette histoire d’UUID ajoutait une bonne couche de désarroi supplémentaire. C’est à cette époque difficile que j'ai appris à haïr l'UUID :-) C’est vrai que pour une partition racine… mais ça continue d'être humainement illisible y compris dans fstab !
Cordialement,
Patrick
---------------------- Je viens de booter deux fois sans problème avec - les deux lignes relatives aux partitions du disque dur non moté en commantaire, - grub installé depuis mon système "quitidient", dont la partition racine est également sur le SSD.
Bug ?
Cordialement,
Patrick
Oui je pense bug report serait indiqué.
noatime: voyons, normalement on disait (surtout pour les premiers ssd, que avoir le swap sur ssd va détruire le ssd. Je ne peut pas confirmer ceci, j'ai un adata pro 900 est il marche toujours a merveille. Donc, pour swap en tous cas noatimes est une valeur bonne. Aussi pour /root j'ai l'expérience que ceci peut induire une vitesse de démarrage légèrement plus rapide. Malheureusement, je n'ai pas un ssd pour le home pour le moment. Je pense noatime pour le /home va se rendre utile quand on ha a déplacer des grandes quantités de petit fichier. Une autre chose, je pense tu utilise (intelligemment, moi de même) ext4 pour tes partitions. Ext4 ha un très bonne support pour trim, cependant pour une question d'économie des temps de démarrage je préfère de ne le pas mettre "institutionnalisé" en fstab ce valeur. (valeur serait: discard). Il suffit en effet chaque 6 mois de ouvrir la CLI est taper:
sudo fstrim -a -v /linux
(dans ton cas naturellement) et attendre longtemps - il va te dire ce qu'il a fait. En combinaison avec noatime, ceci donne, à mon expérience, des bonnes résultats.
Amuse toi bien ;-) "stak"
En fait, j'ai réglé le problème du "trim" autrement. Au démarrage, je lance toujours en root un script qui lance init 5 entre autres scripts et surveille les process kde. 15 minutes après qu'il y en ait moins de 3 process, je fais les sauvegardes du jour, ensuite, juste avant d'éteindre la system avec poweroff, je lance un fstrim. Merci pour les réponses. Cependant, je ne posterai pas de "bug report"... Cordialement, Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
On mardi, 24 janvier 2017 21.33:47 h CET Patrick Serru wrote:
Le mardi 24 janvier 2017, stakanov a écrit :
In data martedì 24 gennaio 2017 17:25:39, Patrick Serru ha scritto:
Le mardi 24 janvier 2017, Patrick Serru a écrit :
Le mardi 24 janvier 2017, stakanov a écrit :
A propos, je viens de voir ça: est-ce qu’il y a (en temps normales bien sur) une raison pourquoi tu n’utilise pas le paramètre noatimes pour le ssd?
La bonne raison pour laquelle je n’utilise pas noatimes est…
l’ignorance de son existence ! Je viens de jeter un œil : le jeu en vaut-il la chandelle ? Surtout qu’avec un SSD le gain de temps est déjà prodigieux.
Le mardi 24 janvier 2017, stakanov a écrit :
Donc, le
LABEL=1-st500_sav /linux/1-st500_sav ext4 acl,user_xattr 0 0 LABEL=2-st500_42.1_tmp /linux/2-st500_42.1_tmp ext4 user,noauto,users,acl,user_xattr 0 0
N’est plus du tout utilisé et non plus dan la machine ou tu l’as déconnectés?
Oui. Ce disque me sert de temps en temps pour faire une duplication
de /linux/7-samsung_sav, sur lequel j’ai des années d’archives. Je le confis ensuite à quelqu’un qui n’habite pas au même endroit que moi.
J’ai longtemps gardé en commentaire la ligne où il était fait référence
à l’UUID de la partition racine, mais c’est parti. L’UUID de cette partition que peut m’indique le système journalier (sur lequel je poste actuellement) sera le même que celui connu par Grub/Linux au moment de monter le système de secours ? Grâce à ls -l /dev/disk/by-uuid/ et ls -l /dev/disk/by-label/, je peux conclure que l’UUID de la partition qui m’intéresse est 0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd Je vais tenter de modifier fstab pour voir ce que cela donne. C’est bien ainsi LABEL=2-SSD_sec / ext4 acl,user_xattr 1 1 ->
UUID=0e0a36aa-1f9a-4823-8a5e-260b85dcc7fd / ext4 acl,user_xattr 1 1
En attendant la confirmation, je vais tenter de rebooter après
avoir
commenté les lignes de fstab relatives aux st500.
Pour ma défense, Grub, X et Open Suse n’ont pas toujours été
merveilleux, et cette histoire d’UUID ajoutait une bonne couche de désarroi supplémentaire. C’est à cette époque difficile que j'ai appris à haïr l'UUID :-) C’est vrai que pour une partition racine… mais ça continue d'être humainement illisible y compris dans fstab !
Cordialement,
Patrick
----------------------
Je viens de booter deux fois sans problème avec
- les deux lignes relatives aux partitions du disque dur non moté en commantaire, - grub installé depuis mon système "quitidient", dont la partition racine est également sur le SSD.
Bug ?
Cordialement,
Patrick
Oui je pense bug report serait indiqué.
noatime: voyons, normalement on disait (surtout pour les premiers ssd, que avoir le swap sur ssd va détruire le ssd. Je ne peut pas confirmer ceci, j'ai un adata pro 900 est il marche toujours a merveille. Donc, pour swap en tous cas noatimes est une valeur bonne. Aussi pour /root j'ai l'expérience que ceci peut induire une vitesse de démarrage légèrement plus rapide. Malheureusement, je n'ai pas un ssd pour le home pour le moment. Je pense noatime pour le /home va se rendre utile quand on ha a déplacer des grandes quantités de petit fichier. Une autre chose, je pense tu utilise (intelligemment, moi de même) ext4 pour tes partitions. Ext4 ha un très bonne support pour trim, cependant pour une question d'économie des temps de démarrage je préfère de ne le pas mettre "institutionnalisé" en fstab ce valeur. (valeur serait: discard). Il suffit en effet chaque 6 mois de ouvrir la CLI est taper:
sudo fstrim -a -v /linux
(dans ton cas naturellement) et attendre longtemps - il va te dire ce qu'il a fait. En combinaison avec noatime, ceci donne, à mon expérience, des bonnes résultats.
Amuse toi bien ;-) "stak"
--------------------------- En fait, j'ai réglé le problème du "trim" autrement. Au démarrage, je lance toujours en root un script qui lance init 5 entre autres scripts et surveille les process kde. 15 minutes après qu'il y en ait moins de 3 process, je fais les sauvegardes du jour, ensuite, juste avant d'éteindre la system avec poweroff, je lance un fstrim.
Merci pour les réponses. Cependant, je ne posterai pas de "bug report"...
Cordialement,
Patrick
Au vu de ta fstab, avec entre autres des disques présents ou pas, je te conseille de regarder comment utilisater autofs Comme ça tu auras le strict minimum pour démarrer avec systemd/dracut le système. et puis tout le reste se monte et se démonte tout seul lors du premier accès. -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
Le mercredi 25 janvier 2017, Bruno Friedmann a écrit :
En fait, j'ai réglé le problème du "trim" autrement. Au démarrage, je lance toujours en root un script qui lance init 5 entre autres scripts et surveille les process kde. 15 minutes après qu'il y en ait moins de 3 process, je fais les sauvegardes du jour, ensuite, juste avant d'éteindre la system avec poweroff, je lance un fstrim.
Merci pour les réponses. Cependant, je ne posterai pas de "bug report"...
Cordialement,
Patrick
Au vu de ta fstab, avec entre autres des disques présents ou pas, je te conseille de regarder comment utilisater autofs
Comme ça tu auras le strict minimum pour démarrer avec systemd/dracut le système. et puis tout le reste se monte et se démonte tout seul lors du premier accès.
--
Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
----------------------- Bonjour Bruno, Merci pour la suggestion. autofs semble intéressant et je me demande s’il place les disques (qui peuvent l’être !) en mode stand-by ("hdparm -Y /dev/ …"). J’ai changé la carte mère et le boîtier de ma machine il y a 6 mois. Comme il m’arrive de faire des enregistrements audio, j’espérais réduire le bruit induit par la mécanique par le changement du boîtier. Voulant améliorer un peu plus la situation et comme de plus ça résonne avec le vert de mon âme, j’ai essayé la mise en stand-by des disques. Quelle ne fut pas ma surprise de constater que le moteur du Samsung est bien plus bruyant que celui du Westewn-Digital. Vous savez : ce bruit que l’on entend pas mais qui fait du bien quand il s’arrête… Comme la fréquence de la fondamentale est assez basse, il est possible que ce soit un problème de résonance lié à la mécanique de CE boîtier. Le script dont j’ai fait mention vérifiait régulièrement si les disques n’étaient pas montés , et dans ce cas, les plaçait en stand-by. J’ai d’ailleurs pu constater à cette occasion, que le système les en sortait au bout d’un certain temps. Mais j’ai eu (cru avoir) des problèmes de disque, en l’occurrence, à l’occasion de la mise à jour de 42.1 en 42.2 (-> opensuse-kde3@opensuse.org), j’ai retiré cette partie du script, car je me suis dit que cela devait être une nuisance pour les disques. J’ai constaté récemment que mon problème de disque était (est) dû… à la connectique ! Donc, si autofs place les disques en stand-by, j’adopte tout de suite, sinon, j’adopterai plus tard, parce qu’un "tiens" vaut mieux qu’un "deux, tu l’auras" (-: vous savez comment je suis, Bruno, je roule toujours en KDE !). Aujourd’hui, j'ouvre yast pour “modifier” fstab pour un nouveau "device", et j’ouvre kdf pour monter et démonter au besoin, et ça me va car cela reste une manœuvre plutôt occasionnelle. Cordialement, Patrick -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
On mercredi, 25 janvier 2017 09.46:29 h CET Patrick Serru wrote:
Le mercredi 25 janvier 2017, Bruno Friedmann a écrit :
En fait, j'ai réglé le problème du "trim" autrement. Au démarrage, je
lance toujours en root un script qui lance init 5 entre autres scripts et surveille les process kde. 15 minutes après qu'il y en ait moins de 3 process, je fais les sauvegardes du jour, ensuite, juste avant d'éteindre la system avec poweroff, je lance un fstrim.
Merci pour les réponses. Cependant, je ne posterai pas de "bug
report"...
Cordialement,
Patrick
Au vu de ta fstab, avec entre autres des disques présents ou pas, je te conseille de regarder comment utilisater autofs
Comme ça tu auras le strict minimum pour démarrer avec systemd/dracut le système. et puis tout le reste se monte et se démonte tout seul lors du premier accès.
--
Bruno Friedmann
Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot
----------------------- Bonjour Bruno,
Merci pour la suggestion. autofs semble intéressant et je me demande s’il place les disques (qui peuvent l’être !) en mode stand-by ("hdparm -Y /dev/ …").
J’ai changé la carte mère et le boîtier de ma machine il y a 6 mois. Comme il m’arrive de faire des enregistrements audio, j’espérais réduire le bruit induit par la mécanique par le changement du boîtier. Voulant améliorer un peu plus la situation et comme de plus ça résonne avec le vert de mon âme, j’ai essayé la mise en stand-by des disques. Quelle ne fut pas ma surprise de constater que le moteur du Samsung est bien plus bruyant que celui du Westewn-Digital. Vous savez : ce bruit que l’on entend pas mais qui fait du bien quand il s’arrête… Comme la fréquence de la fondamentale est assez basse, il est possible que ce soit un problème de résonance lié à la mécanique de CE boîtier.
Le script dont j’ai fait mention vérifiait régulièrement si les disques n’étaient pas montés , et dans ce cas, les plaçait en stand-by. J’ai d’ailleurs pu constater à cette occasion, que le système les en sortait au bout d’un certain temps. Mais j’ai eu (cru avoir) des problèmes de disque, en l’occurrence, à l’occasion de la mise à jour de 42.1 en 42.2 (-> opensuse-kde3@opensuse.org), j’ai retiré cette partie du script, car je me suis dit que cela devait être une nuisance pour les disques. J’ai constaté récemment que mon problème de disque était (est) dû… à la connectique !
Donc, si autofs place les disques en stand-by, j’adopte tout de suite, sinon, j’adopterai plus tard, parce qu’un "tiens" vaut mieux qu’un "deux, tu l’auras" (-: vous savez comment je suis, Bruno, je roule toujours en KDE !). Aujourd’hui, j'ouvre yast pour “modifier” fstab pour un nouveau "device", et j’ouvre kdf pour monter et démonter au besoin, et ça me va car cela reste une manœuvre plutôt occasionnelle.
Cordialement,
Patrick
En tout cas les disques externes usb (c'est là que je l'utilise le plus) passe tous en standby et les partitions proprement démontées après le délai indiqué d'inactivité. Dans ton cas attention, car ça réveillera le disque au moment ou un accès sera détecté. Le réveil monopolise pas mal les ressources io ... donc je ne sais pas l'impact sur le processus d'enregistrement du son que je sais assez sensible .... -- Bruno Friedmann Ioda-Net Sàrl www.ioda-net.ch Bareos Partner, openSUSE Member, fsfe fellowship GPG KEY : D5C9B751C4653227 irc: tigerfoot -- To unsubscribe, e-mail: opensuse-fr+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-fr+owner@opensuse.org
participants (3)
-
Bruno Friedmann -
Patrick Serru -
stakanov