[Résolu] Dossiers en double sur le Bureau

Pimprelune · Le 04/08/2019, à 09:43

Bonjour le Forum et les cracks Linuxiens de mon sujet !

@moko138 : Noté au chapitre "Formules Terminal & Autres" !

Maintenant puis-je demander comment vous savez qu'un Fichier Texte doit s'ouvrir (ou non) avec les droits admin ? Je reformule (puisque qu'un MdP est demandé, c'est qu'il s'agit d'agir dessus avec les droits admin), comment est déterminé la "valeur" (courant, ou haute sécurité pour "travailler" sur ce Fichier) ?

D'ailleurs, pourquoi y-a-t-il le [.] devant config ? Ça fait partie des Dossiers cachés ?

Mille excuses, je viens de trouver les/des réponses... très intéressantes (etc = editing text config) !

Accessoirement, car je commençais à me croire atteinte d'Alzheimer...

Coeur Noir a écrit :

@pimprelune, je vais finir par croire que tu ne lis pas les réponses qu'on te fait, des fois…
~/.config/user-dirs.dirs
Non ! La commande c'est
gedit ~/.config/user-dirs.dirs
Idem pour ta question concernant « comment modifier le fichier fstab… la réponse était déjà dans le point 4 du #44
Bon mettons ça sur le compte d'une discussion un peu longue, qui prend quelques chemins de traverse…

Je n'ai p.a.s appliqué les changements du #44, m'étant contenté de la "simple" commande de Roschan pour ne pas prendre

la peine de réparer quelque chose qui fonctionne

, donc je n'ai pas tapé les commandes citées (et donc pas intégrées dans ma cervelle), ce qui explique un peu ma crucherie sur la question, Coeur Noir.

[HS]

Coeur Noir a écrit :

tu sais normalement sous 18.04 tu peux activer le numlock / verrou pavé numérique à l'écran de connexion GDM, c'est dans les paramètres gnome il me semble, juste une option à cocher, rien à installer…

Je n'ai pas GDM dans mes applications ni ne le vois apparaître à la connexion, il est présent dans les Logiciels (à installer, a fortiori ), aussi je ne sais où régler le numlock dès le départ (avant le Bureau).
Mais vu la tartine de l'installation en question, je vais forcer mon unineurone à activer le pavé numérique avant de taper le MdP . [/HS]

Pimprelune

Dernière modification par Pimprelune (Le 04/08/2019, à 14:24)

geole · Le 04/08/2019, à 11:34

Pimprelune a écrit :

Je n'ai p.a.s appliqué les changements du #44, m'étant contenté de la "simple" commande de Roschan pour ne pas prendre
la peine de réparer quelque chose qui fonctionne
, donc je n'ai pas tapé les commandes citées (et donc pas intégrées dans ma cervelle), ce qui explique un peu ma crucherie sur la question, Coeur Noir.

Bonjour Pimprelune, Je pense que tu exagères en disant "la peine de réparer quelque chose qui fonctionne" alors que tu indiques que dans 70% des cas, cela ne fonctionne pas.!!!!
Le but à atteindre est que cela fonctionne dans 100 % des cas.

ATTENTION: Pour le moment, il n'est pas envisagé de changer les noms des points de montage, les modifications de hier ne portent que sur la façon dont le montage est controlé.

Bonjour tout le monde.
Pour obtenir une amélioration proche de 95% de fonctionnement, on pourrait jouer sur les fréquences de contrôle de la qualité des partitions en disant de contrôler systématiquement la partition contenant le /home et plus rarement la partition contenant les données ou plus du tout en prévoyant de faire ce contrôle manuellement (démontage de la partition, contrôle et remontage) au moment qui convient le mieux.

Il me semble que la solution dite "drastique" n'est pas dangeureuse. J'ai même écrit que je la préférais à la solution de réparation officielle consistant à mettre les données au premier niveau dans /home!

J'ai pas mal cherché pour "ordonner" les séquences de contrôle. J'ai trouvé un certain nombre de réponses qui semblent très logiques. Tout était en anglais pour des autres O.S que UBUNTU, je vous épargne les liens. La recherche était basée sur les mots clé "fstab pass".
J'en déduis que le module fck utilisé par ubuntu est arriéré par rapport à d'autres ou que j'ai pas encore trouvé l'option permettant de faire un travail correct. Mes tests ont été négatils!!!!
Si le travail était correctement fait, on pourrait alors modifier cette partie de documentation ( https://doc.ubuntu-fr.org/mount_fstab ) de la façon suivante
6) la colonne <pass> règle la vérification au démarrage. Laissez-y les valeurs par défaut de l'installation. Si vous ajoutez manuellement des partitions, les valeurs de <pass> doivent être:
0 ⇒ Pas de vérification. Concrétement pour les partitions swap et les partitions windows
1 => Vérification en mode séquentiel dans l'ordre de description des lignes dans le fichier. Concrétement pour la racine (votre partition principale),
N => Vérification en mode parrallèle. Le contrôle de niveau N ne commence à être exécuté que lorsque le niveau N-1 est terminé.

Pourtant, la commande man fsck semble dire que c'est bien comme cela que le fonctionnement est prévu

-A Walk through the /etc/fstab file and try to check all filesystems in one run. This option is typically used from the /etc/rc system initialization
file, instead of multiple commands for checking a single filesystem.

The root filesystem will be checked first unless the -P option is specified (see below). After that, filesystems will be checked in the order speci‐
fied by the fs_passno (the sixth) field in the /etc/fstab file. Filesystems with a fs_passno value of 0 are skipped and are not checked at all.
Filesystems with a fs_passno value of greater than zero will be checked in order, with filesystems with the lowest fs_passno number being checked
first. If there are multiple filesystems with the same pass number, fsck will attempt to check them in parallel, although it will avoid running mul‐
tiple filesystem checks on the same physical disk.

fsck does not check stacked devices (RAIDs, dm-crypt, ...) in parallel with any other device. See below for FSCK_FORCE_ALL_PARALLEL setting. The
/sys filesystem is used to determine dependencies between devices.

Hence, a very common configuration in /etc/fstab files is to set the root filesystem to have a fs_passno value of 1 and to set all other filesystems
to have a fs_passno value of 2. This will allow fsck to automatically run filesystem checkers in parallel if it is advantageous to do so. System
administrators might choose not to use this configuration if they need to avoid multiple filesystem checks running in parallel for some reason – for
example, if the machine in question is short on memory so that excessive paging is a concern.

fsck normally does not check whether the device actually exists before calling a filesystem specific checker. Therefore non-existing devices may
cause the system to enter filesystem repair mode during boot if the filesystem specific checker returns a fatal error. The /etc/fstab mount option
nofail may be used to have fsck skip non-existing devices. fsck also skips non-existing devices that have the special filesystem type auto.

google traductio de man fsck a écrit :

-A Parcourez le fichier / etc / fstab et essayez de vérifier tous les systèmes de fichiers en une fois. Cette option est généralement utilisée à partir de l’initialisation du système / etc / rc.
fichier, au lieu de plusieurs commandes pour vérifier un seul système de fichiers.
Le système de fichiers racine sera vérifié en premier sauf si l'option -P est spécifiée (voir ci-dessous). Après cela, les systèmes de fichiers seront vérifiés dans l'ordre spécifié.
fié par le champ fs_passno (le sixième) dans le fichier / etc / fstab. Les systèmes de fichiers avec une valeur fs_passno égale à 0 sont ignorés et ne sont pas du tout vérifiés.
Les systèmes de fichiers dont la valeur fs_passno est supérieure à zéro seront vérifiés dans l'ordre, les systèmes de fichiers dont le numéro fs_passno est le plus bas étant vérifiés
premier. S'il y a plusieurs systèmes de fichiers avec le même numéro de passe, fsck essaiera de les vérifier en parallèle, bien qu'il évitera d'exécuter plusieurs commandes.
Plusieurs systèmes de fichiers vérifient sur le même disque physique.
fsck ne vérifie pas les périphériques empilés (RAID, dm-crypt, ...) en parallèle avec un autre périphérique. Voir ci-dessous pour le réglage FSCK_FORCE_ALL_PARALLEL. le
Le système de fichiers / sys est utilisé pour déterminer les dépendances entre les périphériques.
Par conséquent, une configuration très courante dans les fichiers / etc / fstab consiste à définir le système de fichiers racine sur une valeur fs_passno égale à 1 et à définir tous les autres systèmes de fichiers.
avoir la valeur fs_passno égale à 2. Cela permettra à fsck d’exécuter automatiquement des vérificateurs de système de fichiers en parallèle s’il est avantageux de le faire. Système
les administrateurs peuvent choisir de ne pas utiliser cette configuration s'ils doivent éviter plusieurs vérifications de système de fichiers s'exécutant en parallèle pour une raison quelconque - pour
Par exemple, si la machine en question manque de mémoire, une pagination excessive est un problème.
Normalement, fsck ne vérifie pas si le périphérique existe réellement avant d'appeler un vérificateur spécifique au système de fichiers. Par conséquent, des appareils non existants peuvent
oblige le système à entrer en mode de réparation du système de fichiers au démarrage si le vérificateur spécifique au système de fichiers renvoie une erreur irrécupérable. L'option de montage / etc / fstab
nofail peut être utilisé pour que fsck ignore les périphériques non existants. fsck ignore également les périphériques non existants dotés du type de système de fichiers spécial auto.

AJOUT. Je constate que cela fonctionne comme prévu avec la commande

sudo    fsck    -RAMvn

où j'ai jonglé avec 3 partitions que j'ai pu démonté... et changer l'orde de contrôle avec des PASS égaux à 10 15 et 20
Je vais chercher comment supprimer le parallélisme du boot

Je viens de comprendre que le contrôle des partitions au démarrage de l'ordinateur est maintenant fait par le service system-fsck dont le principe de base est de paralléliser les contrôles pour que cela puisse se faire simultamément suite à une demande des gros serveurs équipé de milliers de disques. Donc probablement aucune chance de trouver comment le casser. J'ai trouvé que la réparation d'un système de fichier assez abimé peut être réparé automatiquement..

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash fsck.mode=force fsck.repair=yes"

Dernière modification par geole (Le 04/08/2019, à 17:46)

Pimprelune · Le 04/08/2019, à 14:46

Hello le Forum, bonjour geole !

En fait, la phrase exacte était

pas la peine de réparer quelque chose qui fonctionne / if it ain't broken don't fix it

(et je ne la connaissais pas) dans les propositions de Coeur Noir - message #44 - pour réparer ce problème.

C'était bien évidemment dans l'optique d'utiliser (régulièrement/quand besoin est/tous les jours ?) la commande

gedit ~/.config/user-dirs.dirs

et le Fichier Texte (à modifier correctement) de Roschan, plutôt que de chercher en profondeur la raison de ce "bug". Comme on a vu que je suis un peu limitée, c'était une solution à envisager. Car après application de la formule, ça fonctionnait.

Comme d'autres problème sont apparus en même temps, geole, le provisoire dépannait excellemment, mais je n'avais rien contre une recherche (faite par les experts ) plus poussée.

(File ailleurs décrire le problème de mes icônes d'extensions baladeuses, elles aussi --------------------------------------------------------> )

Pimprelune

Dernière modification par Pimprelune (Le 04/08/2019, à 14:50)

Coeur Noir · Le 04/08/2019, à 16:06

@geole : non. La valeur pass n'a que 3 options, la 0 la 1 ou la 2 point barre : pas de vérif', vérif' en séquentiel, ou vérif' en paralèlle. Mmm… est-ce que ça mériterait pas un fil dédié cette question de la verif' et des valeurs de pass ? On est déjà à 6 pages et comme @pimprelune tu oublies de répondre à certaines questions / dire où tu en es, perso je n'arrive plus à me figurer clairement la situation.

Est-ce que ceci est correct, Pimprelune :
⋅ tu es re-passée en connexion de session manuelle,
⋅ tu as modifié le fichier fstab,
⋅ tu n'as pas modifié les droits d'écriture du fichier user-dirs.dirs comme suggéré au #72.
→ Si tout cela est exact, voyons avec un peu de temps si ça suffit à améliorer la situation.

Si ça re-merdoie pareil, il faudra un nouveau bilan, avec ces commandes :

systemd-analyze
systemd-analyze blame
dmesg | grep Error
dmesg | grep sd

à passer dès que tu constates le pépin et poster ici les retours.

Par ailleurs il y a cette plainte brillamment relevée par les camarades qui peut d'ores et déjà être corrigée, via la suggestion de moko :

sudo umount -v /dev/sdb1 && sudo fsck.fat -ytv /dev/sdb1

Il faudra poster ici le retour de cette commande, qu'on sache ce qu'elle a vu / réparé.

Dernière modification par Coeur Noir (Le 04/08/2019, à 16:09)

Pimprelune · Le 04/08/2019, à 17:26

Exact, CoeurNoir !

- Je suis repassée en connexion de session manuelle (MdP à chaque fois),

- J'ai modifié le fichier fstab (remplacé

/dev/disk/by-uuid/de066ccd-9a0e-4d6f-b55c-57f411c9cb71 /mnt/de066ccd-9a0e-4d6f-b55c-57f411c9cb71 auto nosuid,nodev,nofail 0 2

par

# montage partition du gros disque
UUID=de066ccd-9a0e-4d6f-b55c-57f411c9cb71 /mnt/de066ccd-9a0e-4d6f-b55c-57f411c9cb71 ext4 defaults 0 2

),

- Je n'ai pas modifié les droits d'écriture du fichier user-dirs.dirs (because inconvénients mentionnés au #45).

Alors dès que les Dossiers reviennent - détachés de mon Dossier perso - sur le Bureau, il me faudra passer les commandes -->

systemd-analyze
systemd-analyze blame
dmesg | grep Error
dmesg | grep sd

Puis venir vous donner les retours... Je n'ai rien oublié ??

Et je réponds - illico presto ! - à l'interrogation de moko138 -->

pimprelune@pimprelune-desktop-AlF:~$ sudo umount -v /dev/sdb1 && sudo fsck.fat -ytv /dev/sdb1
[sudo] Mot de passe de pimprelune : 
umount: /boot/efi (/dev/sdb1) démonté
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Seek to 536870400:Argument invalide
pimprelune@pimprelune-desktop-AlF:~$

J'dis rien, Hummmm, même si argument invalide me laisse perplexe (que dire du boot/efi démonté (???)).

À vous la main, les experts, pour analyser la réponse.

Encore merci à vous tous pour le temps passé à démêler cet imbroglio !

Pimprelune

Dernière modification par Pimprelune (Le 04/08/2019, à 17:28)

Coeur Noir · Le 04/08/2019, à 19:39

@Pimprelune, impecc' tu n'as rien oublié.
Concernant :
- Je n'ai pas modifié les droits d'écriture du fichier user-dirs.dirs (because inconvénients mentionnés au #45).
conscient⋅e des inconvénients, et maintenant qu'on sait que le disque sda ( le gros, dans /mnt ) est parfois lent à monter,
suite à https://forum.ubuntu-fr.org/viewtopic.p … #p22127979, soit une vérif' du FS tous les 10 démarrages,
ce « hack » t'apporterait la paix.

@moko je ne sais pas quoi penser de :

pimprelune@pimprelune-desktop-AlF:~$ sudo umount -v /dev/sdb1 && sudo fsck.fat -ytv /dev/sdb1
[sudo] Mot de passe de pimprelune : 
umount: /boot/efi (/dev/sdb1) démonté
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Seek to 536870400:Argument invalide
pimprelune@pimprelune-desktop-AlF:~$

Dernière modification par Coeur Noir (Le 04/08/2019, à 22:09)

melixgaro · Le 04/08/2019, à 19:44

Une vérif' : Coeur noir, tu parles de sda dans ton dernier message. sda est bien celui qui se monte dans /mnt ?

moko138 · Le 04/08/2019, à 20:03

melixgaro a écrit :

Une vérif' : Coeur noir, tu parles de sda dans ton dernier message. sda est bien celui qui se monte dans /mnt ?

sda1, oui.

= =

@moko je ne sais pas quoi penser de :

pimprelune@pimprelune-desktop-AlF:~$ sudo umount -v /dev/sdb1 && sudo fsck.fat -ytv /dev/sdb1
[sudo] Mot de passe de pimprelune : 
umount: /boot/efi (/dev/sdb1) démonté
fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Seek to 536870400:Argument invalide
pimprelune@pimprelune-desktop-AlF:~$

Je crois qu'on touche aux limites du linuxien fsck.fat concernant un FS windows.

536870400 secteurs = 268435200 kio
= 262143,75 Mio
= 255,999755859 Gio
La petite /boot/efi finirait si loin ? Je n'y crois pas. Que dis-tu d'une petite vérification :

sudo parted -l | grep -vA4 loop

?

Coeur Noir · Le 04/08/2019, à 22:10

Euh oui oui ça mange pas de pain … elle sert à quoi ici cette partition /boot/efi ?
Et pardonne mon ignorance mais pourquoi
nombre de secteurs / 2 = taille en kio
ou c'est juste une coïncidence ?

moko138 · Le 04/08/2019, à 22:44

elle sert à quoi ici cette partition /boot/efi ?

Présente dans le fstab,

UUID=2B00-45D4  /boot/efi       vfat    umask=0077      0       1

elle sert - je suis habilité à te le révéler - à... booter en (U)EFI.

Mais l'expert en UEFI, sur ce fil, c'est geole.

= =

pourquoi
nombre de secteurs / 2 = taille en kio
ou c'est juste une coïncidence ?

Aucune coïncidence.

sudo parted -l | grep -vA4 loop

en plus du partitionnement, précisera :
soit Sector size (logical/physical): 512B/512B
soit Sector size 512B (logical) / 4096B (physical)

Pimprelune · Le 04/08/2019, à 23:54

Il me semblait bien que je devais vous rendre ma copie passer une commande...

Voilà qui est fait -->

pimprelune@pimprelune-desktop-AlF:~$ sudo parted -l | grep -vA4 loop
[sudo] Mot de passe de pimprelune : 
Modèle: ATA ST2000DM001-1ER1 (scsi)
Disque /dev/sda : 2000GB
Taille des secteurs (logiques/physiques): 512B/4096B
Table de partitions : gpt
Disk Flags: 

Numéro  Début   Fin     Taille  Système de fichiers  Nom    Fanions
 1      1049kB  2000GB  2000GB  ext4                 Datas


Modèle: ATA Samsung SSD 850 (scsi)
Disque /dev/sdb : 250GB
Taille des secteurs (logiques/physiques): 512B/512B
Table de partitions : gpt
Disk Flags: 

Numéro  Début   Fin     Taille  Système de fichiers  Nom                   Fanions
 1      1049kB  269MB   268MB   fat32                EFI System Partition  démarrage, esp
 2      269MB   1343MB  1074MB  ext4                 Boot
 3      1343MB  55,0GB  53,7GB  ext4                 Systeme
 4      55,0GB  241GB   186GB   ext4                 Home
 5      241GB   250GB   8590MB  linux-swap(v1)       Swap


pimprelune@pimprelune-desktop-AlF:~$

Et corrigez-moi si je me trompe, mais ça précise (comme tu l'avait dit, moko138) que les secteurs (logique/physique) sur le disque mécanique (de 2 To) sont de taille 512B/4096B
et sur le SSD, ils sont de 512B/512B.

Pimprelune

geole · Le 05/08/2019, à 09:58

Bonjour à tous

Au post N° 45

Coeur Noir a écrit :

Ici puisque les montages fonctionnent, j'évoquais une autre manière de faire : une fois qu'on est satisfait de son fichier user-dirs.dirs, on peut lui retirer tout droit d'écriture, comme ça plus personne ne le modifie.,
.

En investiguant un peu plus, j'ai réussi à trouver par mal de discussions sur le problème.
Le concepteur de XDG permet à l'utilisateur de faire en sorte que le fichier de directives ne soit plus réactualisé au démarrage puisqu'il est bon. Voir même pour la totalité des utilisateurs de l'ordinateur.
Voici la procédure pour un utilisateur qui sera à répéter autant de fois qu'il y a d'utilisateurs qui ont le problème.
a) Copie du fichier de configuration générale dans le fichier dans le fichier de configuration de l'utilisateur qui n'existe probablement pas

        cp  -nv   /etc/xdg/user-dirs.conf    $HOME/.config

b) Remplacer le mot True par le mot False dans le fichier copié.

La procédure pour la totalité des utilisateurs est de faire l'action de remplacement dans le fichier original

Explication par la commande man user-dirs.conf
Cela devrait permettre de rétablir la connexion automatique.

Au post 133

moko138 a écrit :

Je ne sais pas quoi penser de :

fsck.fat 4.1 (2017-01-24)
Checking we can access the last sector of the filesystem
Seek to 536870400:Argument invalide

Voici mon avis.
Cela ressemble fortement à ce https://bugs.launchpad.net/ubuntu/+sour … bug/794943 connu depuis 2011 et corrigé dans d'autres OS. Pas encore traité chez ubuntu.
Je vais leur signaler. Je suggère de conserver en état, au cas où ils demanderaient des informations.

Le module de contrôle indique que la partition a un problème quelque part
On peut penser qu'il raconte n'importe quoi et que la partition est parfaite.
On penser qu'il a raison, et qu'il y a une erreur quelque part. Ne connaissant pas exactement le style d'erreur, la réparation n'est pas évidente. Sauf à fabriquer du neuf de la façon suivante.
1) Sauver les données. Cette action est sans risque et permettra de voir déjà si tout est lisible. Voici la commande testée. Elle peut être faite dès maintenant.

               sudo cp -rv /boot/efi/*  $HOME

Je ne conseille pas de faire la partie qui suit. Si on doit la faire, tout doit être fait sans arrêt machine, Sinon c'est boot-repair qui saura faire les points 4 5 et 6...
2) Si le module de contrôle à raison ( Seek to 536870400), Il y a une zone délirante dans la partition. Je ne vois que la solution d'écrire des zéros dans la totalité de la partition. Je peux proposer en ligne de commande avec la commande dd pour la partition sdb1. Une erreur de frappe en mettant un espace entre le b et le 1 est catastrophique. Je propose donc de le faire en mode graphique en lançant l'application gnome-disk-utility
a) Sélectionner la bonne partition (sdb1)
b) Dire de la formater
c) Préciser effacer Notons qu'on est prévenu qu'on efface les données. L'action consiste à écrire des zéros dans la totalité de la partition
d) Il faut choisir un type de partition, Pourquoi pas -Compatible avec les systèmes de fichiers et périphériques FAT
e) Lancer l'action et regarder son déroulement se faire. C'est rapide. Quitter l'application.

3) On va maintenant formater la partition créée pour être bootable par le bios EFI. Il faut lancer l'application GPARTED Au besoin l'installer. Je sais qu'elle fonctionnera puisque l'application GEDIT fonctionne.
a) Se positionner sur la partition qui vient d'être créée par l'outil précédant, On constate qu'elle est au format FAT16 et non FAT32. Certains ordinateurs EFI savent booter avec du format FAT16 mais pas tous.
b) Dire qu'on fait un formatage FAT32
c) En profiter pour lui donner une étiquette/un label, cela ne coûte rien " EFItoutNeuf" ?
d) Exécuter
e) Mettre le drapeau de boot

4) Rapatrier les données.
a) Monter la partition avec cette commande

sudo mount  -v   /dev/sdb1    /boot/efi

b) Copie inverse avec cette commande

             sudo cp -rv   $HOME/EFI /boot/efi

5) Mise à jour du fichier /etc/fstab
Le reformatage ayant changé le UUID de la partition, il faut récupérer sa valeur avec cette commande

          sudo blkid   |  grep sdb1

exemple de retour
/dev/sda3: SEC_TYPE="msdos" LABEL="dupfat32" UUID="7BE2-C811" TYPE="vfat" PARTLABEL="DUPFAT32" PARTUUID="38e0429c-7d61-459a-85d8-70715749ee58"
Puis la reporter au bon endroit dans le fichier /etc/fstab qui doit s'ouvrir avec cette commande car c'est fichier n'appartenant pas à l'utilisateur

    gedit admin:///etc/fstab

La zone à rectifier étant celle-ci
# /boot/efi was on /dev/sdb1 during installation
UUID=2B00-45D4 /boot/efi vfat umask=0077 0 1

6) Informer le bios EFI que la partition de boot a changé d'identification. Les commandes à faire étant celles-ci

sudo efibootmgr  --create      --disk     /dev/sdb    --part    1      --label     "grub"      --loader      "\EFI\ubuntu\grubx64.efi"
sudo efibootmgr  --create      --disk     /dev/sdb    --part    1      --label     "shim"      --loader      "\EFI\ubuntu\shimx64.efi"

A ce niveau, j'ai mis les deux commandes ne sachant pas trop ce qu'il y avait avant. Pour le savoir, il faudrait le retour de la commande sudo efibootmgr
Ou que j'aille regarder en détail dans cette discussion ou dans l'autre, s'il n'y a pas un boot-info qui traîne.

Je pense avoir bien détaillé. Mais c'est quand même la partition de boot, Je pense cette machine n'est pas équipée de windows donc si on rate, boot-repair sera notre sauveur.

NOTA: Le format FAT32 est un format libre de droits depuis déjà quelques années https://fr.wikipedia.org/wiki/FAT32

Dernière modification par geole (Le 05/08/2019, à 12:18)

moko138 · Le 05/08/2019, à 10:17

Merci geole de ces infos !

Mais
1) Même si "tous ces brevets sont tombés dans le domaine public en 2013/2014", on voit bien qu'Ubuntu ne sait toujours pas réparer le fat32 correctement.

2) On peut se demander si, puisque la 18.04 de Pimprelune démarre, le message assurant que /boot/efi/ a un problème ne découlerait pas du même bug de fsck.fat.
En tout cas, on peut momentanément ignorer et le message d'erreur et la réparation.

Pimprelune · Le 05/08/2019, à 12:32

Hello le Forum et les calés Linuxiens !

Alors je lis attentivement le tout, et je ne fais que passer la première commande, geole ? Et je ne touche à rien au cazoù quelqu'un voudrait en savoir plus sur le contenu-système de ma machine, c'est ça ?

Direction le Fixe, je suis actuellement sur le portable

Pimprelune

geole · Le 05/08/2019, à 12:56

Bonjour
Oui uniquement cette commande

sudo cp -rv /boot/efi/*  $HOME

Il est important de savoir si toutes les données de boot sont accessibles.

Après ce qui pourrait être demandé par ceux qui qui sont en charge du problème, ce sont des extraits de choses contenues UNIQUEMENT dans la partition FAT32 et ils n'ont pas ton adresse mais uniquement la mienne. Je transmettrais si une telle demande arrive et on avisera comment répondre.

Pimprelune · Le 05/08/2019, à 13:38

Réponse, geole --> je me marre

pimprelune@pimprelune-desktop-AlF:~$ sudo cp -rv /boot/efi/*  $HOME
[sudo] Mot de passe de pimprelune : 
cp: impossible d'évaluer '/boot/efi/*': Aucun fichier ou dossier de ce type
pimprelune@pimprelune-desktop-AlF:~$

Aaaaaaah oui, c'est tout de suite plus clair ! (mode ironie )

Alors je vais peut-être dire une débilité, geole et moko138, mais quand le collègue de l'Axul est venu lundi dernier, au passage, il a mentionné que - puisque lors de la précédente installation (début 2018, sur la machine actuelle, avec OUIFIFI UEFI et Cie), cette interface posait des problèmes à l'usage "courant" du PC - il avait réinstallé (en septembre de la même année) sans l'UEFI.

Frappez pas ! Le système unineuronal et la chaleur, ça ne fait pas bon ménage

À ma question

Mais c'est pas une obligation maintenant sur les ordinateurs ?

, il avait répondu que non, il y avait toujours moyen de faire sans... J'avoue que ça n'a pas percuté chez moi, je croyais sincèrement qu'installer sans, ce n'était pas possible. Mais à la suite de certaines réponses du Terminal (sur ce fil) concernant l'UEFI, j'ai activé mon neurone et je me suis rappelée cette info.

[mode exaspérée] C'est sympa de savoir que puisqu'on est une fille pasdouée en informatique, on n'est pas avisée des spécifications - primordiales ! - de son matériel réinstallé Grrrrrrr, mais bref, passons ! [/mode exaspérée]

Ne pouvez vous pas "voir" ce qu'il en est dans mon système avec une commande spéciale ? Ou alors ça n'a aucune importance ?? Et par conséquent ce "souvenir" n'amène rien de nouveau sur le sujet ???

Pimprelune

Dernière modification par Pimprelune (Le 05/08/2019, à 14:33)

moko138 · Le 05/08/2019, à 13:55

impossible d'évaluer '/boot/efi/*': Aucun fichier ou dossier de ce type

Bien sûr, puisque, pour pouvoir y lancer fsck, nous l'avons démontée.

Remontage :

sudo mount -a -v

= =

geole,
Tu déc*nnes complètement, de quintupler la longueur de ton message de 10h58, deux heures après qu'on t'a répondu.

Pimprelune · Le 05/08/2019, à 14:30

Je "re-monte" le UEFI, moko138, avec ta commande ?

Pimprelune

Coeur Noir · Le 05/08/2019, à 15:11

Rrrôôoo bah oui, geole, super bien vu !
Le concepteur de XDG permet à l'utilisateur de faire en sorte que le fichier de directives ne soit plus réactualisé au démarrage
c'était pourtant écrit en toutes lettres dans le fichier en question :

coeurnoir@Asgard:~$ cat /etc/xdg/user-dirs.conf
# This controls the behaviour of xdg-user-dirs-update which is run on user login
# You can also have per-user config in ~/.config/user-dirs.conf, or specify
# the XDG_CONFIG_HOME and/or XDG_CONFIG_DIRS to override this
(…)
coeurnoir@Asgard:~$

Donc @Pimprelune, pour ne plus que tes dossiers aient la bougeotte ( = désactiver « proprement » la mise à jour auto des dossiers, plutôt qu'enlever les droits d'écriture sur le fichier user-dirs.dirs ) :
1⋅ lancer gedit
2⋅ y coller dans la fenêtre vide le texte :

# désactive la m.à.j. automatique des dossiers personnels
# pour la réactiver, remplacer False par True ou supprimer ce fichier
# voir https://forum.ubuntu-fr.org/viewtopic.php?pid=22132456#p22132456
#
enabled=False

# This sets the filename encoding to use. You can specify an explicit
# encoding, or "locale" which means the encoding of the users locale
# will be used
filename_encoding=UTF-8

3⋅ enregistrer ce fichier dans ~/.config sous le nom user-dirs.conf

Ça ne résout pas le retard de montage du gros disque dur mais
⋅ au moins ce retard n'aura plus d'incidence sur l'organisation de tes dossiers,
⋅ le fichier user-dirs.dirs reste accessible en écriture, des fois que tu voudrais y changer quelque chose.

Je te suggère donc
⋅ de créer ce fichier,
⋅ et de repasser en connexion de session automatique ( si c'est ce que tu préfères )

La modification du fstab pour le gros disque dur était pertinente, on ne revient pas dessus pour l'instant.

Concernant la partition /boot/efi potentiellement abîmée, je ne suis pas compétent - j'me dis juste que si ton système n'est pas (u)efi il y a peut-être du ménage et de la simplification à faire de ce côté là aussi… geole ? moko ?

Enfin, si la lenteur de montage du gros disque dur est bien causée par la vérif' de son FS, il faudrait peut-être espacer la fréquence de cette vérif' ( grosso modo 1 fois par mois, c'était la valeur par défaut dans l'temps ) plutôt qu'1 fois tous les 10 démarrages, comme mis en place ici https://forum.ubuntu-fr.org/viewtopic.p … #p22127979 ?

Dernière modification par Coeur Noir (Le 05/08/2019, à 15:36)

Pimprelune · Le 05/08/2019, à 16:04

Bon, voyons si j'ai bien suivi tes explications, Coeur Noir =

1. Je lance Gedit (Fait)

2. J'y colle le texte ci-dessus qui parle de "désactiver" (Fait)

3. Je l'enregistre dans ~/.config (que je trouve dans les Fichiers de l'ordinateur sous .config, c'est correct ?) sous le nom de user-dirs.conf (crée avec mes petits doigts de... fée/Fait )

Ça finit (pour cette manœuvre) de cette manière, Coeur Noir ?

Et non, pour le coup, je vais rester avec la connexion-Mdp.

Mille mercis à toi, Coeur Noir, maintenant, on patiente jusqu'au prochain raté !?!

Mes remerciements encore à tous ceux venus apporter leurs connaissances, leur temps, leurs conseils (et bon vouloir) pour aider à débrouiller cet "ennui", bonne après-midi, à +

Pimprelune

Dernière modification par Pimprelune (Le 05/08/2019, à 16:05)

Coeur Noir · Le 05/08/2019, à 16:24

maintenant, on patiente jusqu'au prochain raté → oui, et si raté il y a, on enquêtera à nouveau, voir https://forum.ubuntu-fr.org/viewtopic.p … #p22132211

moko138 · Le 05/08/2019, à 17:18

Pimprelune,
Merci de montrer (depuis ta session installée)
le retour de :

sudo mount -a -v

(l'option "-a" monte tout ce qui est prévu dans le fichier fstab) ;

et le retour de ce test :

[ -d /sys/firmware/efi ] && echo "Session EFI" || echo "Session non-EFI"

geole · Le 05/08/2019, à 17:29

Bonjour à tous.
Je crains malheureusement qu'il y ait rapidement des ratés. Cette solution devrait les masquer.
Nous sommes parti sur le principe que le disque dur pouvait être fini de monter après la connexion automatique de l'utilisateur. C'est tout simplement impossible pour ubuntu.

Je viens de faire quelques tests se rapprochant le plus possible de l'environnement à problème
1) O.S sur un SSD d'environ 32 Go (il n'y a pas de partition dédiée au /home)
2) Données dans un RAIDS1 de deux disques de 500 Go
3) Données de téléchargement dans un espace encore libre de 500 GO de l'un des disques du RAIDS
4) Demande de contrôle des partitions à chaque démarrage...
5) Les options quiet splash ont été éliminées du grub.
6) connexion de l'utilisateur en mode automatique.

Le constat
1) On visualise très bien le déroulement du boot. Tout particulièrement la séquence de contrôle de la qualité des partitions:
- Contrôle d'un disque et contrôle de deux disques.
Sur les six essais, la fin de montage le plus mauvais de la partition contenant la racine et le /home finit au bout de 4,81 secondes et la fin du contrôle des autres partions n'a jamais fini avant 13,89 secondes, le plus mauvais cas fut de 19,64 secondes.
C'est donc a peu près le même retard de 15 secondes

Le plus spectaculaire est juste après l'affichage de la ligne disant que le contrôle disque est fini:
L' écran devient tout noir, Puis, assez rapidement, le "bureau" est affiché. Je peux alors lister le contenu du fichier de directives qui est intact.

On a donc la preuve visuelle que le traitement de la connexion de l'utilisateur se fait après la fin du montage des disques.

On peut en avoir la preuve informatique en faisant ces deux commandes

sudo  cat  /var/log/kern.log | grep mount | tail
sudo  head -15 /var/log/Xorg.0.log

qu'il serait bon d'ajouter dans la liste des commandes à faire si le problème est mal contourné.

Coeur Noir · Le 05/08/2019, à 18:42

@geole

Cette solution [ non m.à.j des dossiers persos ] devrait les masquer. → je n'ai jamais dit autre chose à propose de cette manipulation, hein, c'est un contournement.

N'oublie pas aussi qu'entre temps
⋅ la valeur de pass de ce montage est passée de 1 à 2,
⋅ des droits r-X ont été ré-attribués à g et o sur le point de montage,

Nous sommes partis du principe que le disque dur pouvait être fini de monter après la connexion automatique de l'utilisateur
→ ça a été une des conclusions, mais pas la seule.
Ce que j'en disais, vu le fonctionnement de xdg-user-dirs-update, c'est qu'au moment où il est exécuté il n'a pas accès à toutes les infos pour générer un fichier user-dirs-dirs dûment renseigné.
→ ça ne signifie pas forcément que le montage ne s'est pas fait, ça aurait pu n'être qu'un problème de droits ( la première idée ).

De plus si on ajoute maintenant ta démonstration à propos de la séquence de boot, ça exclue tout problème de montage, donc … on ne sait toujours pas pourquoi xdg-user-dirs-update* n'arrive pas à accomplir sa mission.

Évoqué déjà, BleachBit → j'espère que celui-ci n'a pas servi à faire du ménage dans les paquets de langue, c'était catastrophe assurée sous Ubuntu 14 et 16 ( bug peut-être corrigé depuis, sinon https://forum.ubuntu-fr.org/viewtopic.p … #p21586183 ).

*n'oublions pas non plus qu'il a été désactivé dernièrement par #144.

Dernière modification par Coeur Noir (Le 06/08/2019, à 00:51)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#126 Le 04/08/2019, à 09:43

Re : [Résolu] Dossiers en double sur le Bureau

#127 Le 04/08/2019, à 11:34

Re : [Résolu] Dossiers en double sur le Bureau

#128 Le 04/08/2019, à 14:46

Re : [Résolu] Dossiers en double sur le Bureau

#129 Le 04/08/2019, à 16:06

Re : [Résolu] Dossiers en double sur le Bureau

#130 Le 04/08/2019, à 17:26

Re : [Résolu] Dossiers en double sur le Bureau

#131 Le 04/08/2019, à 19:39

Re : [Résolu] Dossiers en double sur le Bureau

#132 Le 04/08/2019, à 19:44

Re : [Résolu] Dossiers en double sur le Bureau

#133 Le 04/08/2019, à 20:03

Re : [Résolu] Dossiers en double sur le Bureau

#134 Le 04/08/2019, à 22:10

Re : [Résolu] Dossiers en double sur le Bureau

#135 Le 04/08/2019, à 22:44

Re : [Résolu] Dossiers en double sur le Bureau

#136 Le 04/08/2019, à 23:54

Re : [Résolu] Dossiers en double sur le Bureau

#137 Le 05/08/2019, à 09:58

Re : [Résolu] Dossiers en double sur le Bureau

#138 Le 05/08/2019, à 10:17

Re : [Résolu] Dossiers en double sur le Bureau

#139 Le 05/08/2019, à 12:32

Re : [Résolu] Dossiers en double sur le Bureau

#140 Le 05/08/2019, à 12:56

Re : [Résolu] Dossiers en double sur le Bureau

#141 Le 05/08/2019, à 13:38

Re : [Résolu] Dossiers en double sur le Bureau

#142 Le 05/08/2019, à 13:55

Re : [Résolu] Dossiers en double sur le Bureau

#143 Le 05/08/2019, à 14:30

Re : [Résolu] Dossiers en double sur le Bureau

#144 Le 05/08/2019, à 15:11

Re : [Résolu] Dossiers en double sur le Bureau

#145 Le 05/08/2019, à 16:04

Re : [Résolu] Dossiers en double sur le Bureau

#146 Le 05/08/2019, à 16:24

Re : [Résolu] Dossiers en double sur le Bureau

#147 Le 05/08/2019, à 17:18

Re : [Résolu] Dossiers en double sur le Bureau

#148 Le 05/08/2019, à 17:29

Re : [Résolu] Dossiers en double sur le Bureau

#149 Le 05/08/2019, à 18:42

Re : [Résolu] Dossiers en double sur le Bureau

Pied de page des forums