[RESOLU]Problème BIOS

geole · Le 20/08/2020, à 17:44

Bonjour Coeur Noir
Je suis malgré tout surpris de la fin de fsck, j'aurais pensé qu'il se serait terminé par quelque chose disant que c'était fini.
Je vois que faire un fsck d'une partition de 2 TO prend du temps.

J'irais bien regarder le contenu du répertoire lost+found et virer complètement ce qu'il contient vu ce que tu dis.

Pour le clonage des blocs réclamés plusieurs fois.....
- La commande que j'ai proposée contenait l'option Y
Mais ne pas la mettre oblige à répondre des centaines de fois Y et machinalement, on répondra aussi Y à cette question sans réfléchir.
S'il y a des centaines de blocs demandés des centaines de fois, on risque d'avoir un disque trop petit ....
Il est probable que, dans cette action de duplication, des fichiers contiennent maintenant des données d'autres fichiers qui sont sans rapport. Si les données ne sont pas de même nature, il y aura des fichiers illisibles. Si les données sont de même nature, cela risque de ne pas être très cohérent: Dans une photo cela va passer, dans un tableau excel, je ne sais pas comment la présentation se fera...
L'idéal serait de ne pas accepter la duplication. C'est peut-être pour cette raison que la réparation qui demande des corrections de fichiers n'est pas lancée automatiquement afin de pouvoir faire du cas par cas.

Coeur Noir · Le 20/08/2020, à 18:02

Je suppose que tu m'as vu venir avec mes gros sabots : est-ce qu'on n'aurait pas dû rester concentrés sur ce que proposait boot-repair ( l'incertitude de boot efi/bios_legacy ou créer une partition boot ), rendre à root les dossiers Lost+Found et .Trash-0 puis seulement plus tard s'intéresser à fsck ?

Attendons le retour de gibar, espérons que sa machine démarre normalement…

geole · Le 20/08/2020, à 18:38

Dès le début, j'ai dit que cela bootait parfaitement bien. Le plantage était du à l'absence de l'option NOFAIL dans la partition de données.

Le FSCK a été déclenché car le compteur était atteint et il s'est planté car il y avait quelque chose d'anormal probablement depuis un certain temps mais cela n'a pas de rapport avec ces deux dossiers. => voir le propriétaire des deux dossiers.

root@a:/media/SDA9# ls -als
total 132
 4 drwxr-xr-x  24 root root  4096 août  20 19:19 .
 4 drwxr-xr-x   5 root root  4096 juil.  6 19:35 ..
12 drwxr-xr-x   2 root root 12288 mai    5 15:42 bin
 4 drwxr-xr-x   4 root root  4096 mai    5 15:51 boot
 4 drwxr-xr-x   2 root root  4096 mai    5 13:39 cdrom
 4 drwxr-xr-x   5 root root  4096 oct.  21  2015 dev
12 drwxr-xr-x 134 root root 12288 mai    5 14:14 etc
 4 drwxr-xr-x   3 root root  4096 mai    5 13:45 home
 0 lrwxrwxrwx   1 root root    32 mai    5 15:45 initrd.img -> boot/initrd.img-4.2.0-42-generic
 0 lrwxrwxrwx   1 root root    32 mai    5 13:46 initrd.img.old -> boot/initrd.img-4.2.0-16-generic
 4 drwxr-xr-x  27 root root  4096 oct.  21  2015 lib
 4 drwxr-xr-x   2 root root  4096 mai    5 15:39 lib64
16 drwx------   2 a    a    16384 mai    5 13:21 lost+found
 4 drwxr-xr-x   2 root root  4096 oct.  21  2015 media
 4 drwxr-xr-x   2 root root  4096 oct.  19  2015 mnt
 4 drwxr-xr-x   2 root root  4096 oct.  21  2015 opt
 4 drwxr-xr-x   2 root root  4096 oct.  19  2015 proc
 4 drwx------   3 root root  4096 mai    5 16:13 root
 4 drwxr-xr-x  11 root root  4096 oct.  21  2015 run
12 drwxr-xr-x   2 root root 12288 mai    5 15:45 sbin
 4 drwxr-xr-x   2 root root  4096 oct.  21  2015 srv
 4 drwxr-xr-x   2 root root  4096 oct.  16  2015 sys
 4 drwxrwxrwt   7 root root  4096 mai    5 17:29 tmp
 4 drwxrwxr-x   2 a    a     4096 août  20 19:19 .Trash-0
 4 drwxr-xr-x  11 root root  4096 oct.  21  2015 usr
 4 drwxr-xr-x  13 root root  4096 oct.  21  2015 var
 0 lrwxrwxrwx   1 root root    29 mai    5 15:45 vmlinuz -> boot/vmlinuz-4.2.0-42-generic

Voir le contrôle.

a@a:/media$ sudo umount /dev/sda9 
a@a:/media$ sudo fsck -f /dev/sda9
fsck de util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
Ubuntu1510 : 232073/544576 fichiers (0.2% non contigus), 1235593/2176000 blocs
a@a:/media$ sudo mount /dev/sda9 /media/SDA9
a@a:/media$ ls -ls /media/SDA9
total 120
12 drwxr-xr-x   2 root root 12288 mai    5 15:42 bin
 4 drwxr-xr-x   4 root root  4096 mai    5 15:51 boot
 4 drwxr-xr-x   2 root root  4096 mai    5 13:39 cdrom
 4 drwxr-xr-x   5 root root  4096 oct.  21  2015 dev
12 drwxr-xr-x 134 root root 12288 mai    5 14:14 etc
 4 drwxr-xr-x   3 root root  4096 mai    5 13:45 home
 0 lrwxrwxrwx   1 root root    32 mai    5 15:45 initrd.img -> boot/initrd.img-4.2.0-42-generic
 0 lrwxrwxrwx   1 root root    32 mai    5 13:46 initrd.img.old -> boot/initrd.img-4.2.0-16-generic
 4 drwxr-xr-x  27 root root  4096 oct.  21  2015 lib
 4 drwxr-xr-x   2 root root  4096 mai    5 15:39 lib64
16 drwx------   2 a    a    16384 mai    5 13:21 lost+found
 4 drwxr-xr-x   2 root root  4096 oct.  21  2015 media
 4 drwxr-xr-x   2 root root  4096 oct.  19  2015 mnt
 4 drwxr-xr-x   2 root root  4096 oct.  21  2015 opt
 4 drwxr-xr-x   2 root root  4096 oct.  19  2015 proc
 4 drwx------   3 root root  4096 mai    5 16:13 root
 4 drwxr-xr-x  11 root root  4096 oct.  21  2015 run
12 drwxr-xr-x   2 root root 12288 mai    5 15:45 sbin
 4 drwxr-xr-x   2 root root  4096 oct.  21  2015 srv
 4 drwxr-xr-x   2 root root  4096 oct.  16  2015 sys
 4 drwxrwxrwt   7 root root  4096 mai    5 17:29 tmp
 4 drwxr-xr-x  11 root root  4096 oct.  21  2015 usr
 4 drwxr-xr-x  13 root root  4096 oct.  21  2015 var
 0 lrwxrwxrwx   1 root root    29 mai    5 15:45 vmlinuz -> boot/vmlinuz-4.2.0-42-generic

a@a:/media/SDA9$ cd lost+found
a@a:/media/SDA9/lost+found$ ls -ls
total 0
a@a:/media/SDA9/lost+found$

On notera que .Trash-0 a été viré.

Dernière modification par geole (Le 20/08/2020, à 18:39)

Coeur Noir · Le 20/08/2020, à 19:09

Il faudra comparer avec ce qui a eu lieu chez gibar84 - fsck vire probablement .Trash-0 parce qu'il est vide mais ne corrige pas les droits et permissions ( Lost+Found dans ton exemple ). Ça restera donc à faire chez gibar, je présume, même si c'est pas ça qui bloque le démarrage, ça n'est pas normal non plus.

nofail n'envoie pas d'erreur si le périphérique concerné est absent ( = déconnecté, hors tension ). Ce qui est rare ( mais certes pas impossible ) avec un disque interne.

Dernière modification par Coeur Noir (Le 20/08/2020, à 20:36)

moko138 · Le 20/08/2020, à 19:37

Coeur Noir a écrit :

@geole, dans ce cas vaut-il mieux accepter les demandes de « clonage » ou pas ?

1) Je n'ai jamais rencontré un cas où j'aie le savoir suffisant pour décider entre les choix que me proposait fsck !

Ici, je peux seulement supposer que, si le clonage est proposé, c'est parce qu'un même inoeud est attribué à deux fichiers.
Cloner l'inoeud serait alors une façon de préserver l'accès aux deux fichiers (sans en sacrifier).

2) Répondre "non" implique le statu quo ante : on est bien avancé...

3) Donc j'utilise toujours fsck avec les options -yfv et je n'ai jamais eu à m'en plaindre, sauf sur des FS windows.

= =

Purger lost+found sans avoir seulement regardé son contenu ??? Quel intérêt ? Et quels risques !

Dernière modification par moko138 (Le 20/08/2020, à 20:53)

moko138 · Le 20/08/2020, à 20:04

geole a écrit :

S'il y a des centaines de blocs demandés des centaines de fois, on risque (...)

On ne risque rien car :
- Sur un disque matériellement sain, le fsck va proposer la correction d'une poignée (au pire) d'inoeuds.
- Si fsck propose de corriger des centaines ou des milliers d'inoeuds - je l'ai vécu une fois (*) avant ma décision d'employer l'option -y systématiquement (et je vous laisse imaginer le "plaisir" qu'il y a à passer une heure à appuyer sur la touche "y" ou sur la touche "n" sans savoir...) - c'est que le disque est terriblement abîmé. Matériellement. Donc incapable d'enregistrer les corrections de fsck !

___
(*) C'était sur le disque de récup' dont j'ai parlé ailleurs, celui aux 1229 secteurs HS. Il avait très probablement subi un atterrissage de têtes en fonctionnement. Rien n'était efficace sur la zone abîmée.
Les seules actions utiles ont été de mettre la zone abîmée (une vingtaine de Gio, marges comprises) en zone non allouée, c'est-à-dire sans partition.
AJOUT : et de désactiver les tests automatiques de smartctl (smartctl -o off /dev/sda).
FIN d'ajout

Moyennant quoi, le reste du disque m'a encore servi (système et données) pendant environ quatre ans.

Dernière modification par moko138 (Le 20/08/2020, à 20:21)

Coeur Noir · Le 20/08/2020, à 20:26

moko138 a écrit :

Purger lost+found sans avoir seulement regardé son contenu ??? Quel intérêt ? Et quels risques !

Geole précise bien de d'abord en regarder le contenu avant d'éventuellement le purger.
Quant à moi je notais que ces deux dossiers ( .Trash-0 et Lost+Found ) chez gibar n'appartiennent pas à root comme ils le devraient ( et qu'il faudra donc corriger cela ).

Merci pour les précisions concernant fsck, moko, je n'ai pour l'instant jamais expérimenté telle situation d'où ma question.

Ce qui reste curieux ici - entre autres - c'est que le disque en question sdb semble sain, il y a un smartcontrol dans l'une des discussions…

Et que boot-repair suggère des réparations ( créer une partition boot, réinstaller grub ) qui n'ont pas été tentées ou de démarrer en bios-legacy ( ce qui à priori n'a pas aidé ).

Dernière modification par Coeur Noir (Le 20/08/2020, à 20:41)

moko138 · Le 20/08/2020, à 20:47

Coeur Noir a écrit :

Quant à moi je notais que ces deux dossiers ( .Trash-0 et Lost+Found ) chez gibar n'appartiennent pas à root comme ils le devraient ( et qu'il faudra donc corriger cela ).

+1
Et mettre gibar84 en garde contre sudo nautilus...

geole précise bien de d'abord en regarder le contenu avant d'éventuellement le purger.

Oups ! Mes excuses à tous !

moko138 · Le 20/08/2020, à 21:10

Pour boot-repair, j'ai beaucoup moins d'expérience que geole.

- -

Coeur Noir a écrit :

Ce qui reste curieux ici - entre autres - c'est que le disque en question sdb semble sain, il y a un smartcontrol dans l'une des discussions…

Tu sais comme moi qu'on peut avoir la sous-couche matérielle constituée par le disque, saine (ce que réflèteront des données SMART favorables)
et par-dessus, saine ou en vrac suite à des coupures d'alimentation par exemple, la surcouche logicielle qu'est un FS.

Du coup, je ne comprends pas ta remarque. Pourrais-tu la préciser, s'il te plaît ?

Coeur Noir · Le 20/08/2020, à 21:57

Oui, il y a au moins 2 trucs qui m'intriguent :

1⋅ à priori le système de gibar a démarré maintes fois sans problème. Jusqu'à ce que… le FS soit trop abîmé ? Il n'y aurait pas eu de signes avant coureurs ? Le fsck a l'air d'avoir bossé 3 heures durant…

2⋅ boot-repair fait des suggestions qu'on n'a pas suivies pour l'instant. Et le démarrage avec bios réglé en legacy n'a pas aidé non plus, alors que les partitions nécessaires semblent bien vues par le système. Faut-il se méfier des suggestions de boot-repair ? Privilégier fsck dans ce genre de situation ?

…et dans les autres trucs qui m'intriguent, il y a le fait qu'on essaie d'aider quelqu'un qui n'a pas l'air super à l'aise avec toutes ces recommandations techniques ( nul reproche à gibar ) mais du coup c'est assez difficile de savoir ce qui fut fait / pas fait…

geole · Le 21/08/2020, à 12:30

Bonjour
Humour
Lorsqu'on utilise seulement ubuntu, le boot devrait être plus aisé qu'en cas du dual boot. Mais en réalité:
Aussitôt qu'il faut un peu bricoler, il est souvent utile de faire apparaître le menu de boot. Les ennuis commencent alors:
Il faut appuyer sur des touches et ce ne sont pas les mêmes entre le legacy et l'EFI
En plus, il faut faire vite et le faire au bon moment.
et cela continue avec des intervenants qui demandent d'utiliser nano pour faire des corrections avec un clavier qui par moment n'est pas français à moins qu'ils demandent d'utiliser boot-repair
En plus, ils ne sont pas toujours d'accord eux sur ce qu'il faut faire.
c'est la galère............

Problème... Comment va-il falloir codifier cette fameuse ligne du fichier /etc/fstab qui définit le montage de la partition de données.
Il y a une idée disant qu'il est préférable de planter le boot lorsque la partition n'est pas correcte.
Il y a une autre idée qui dit: Il faut toujours faire le maxima pour éviter que le boot se plante.

J'ai commencé un début de test
Premier boot avec le plantage suivant dans INITRAMFS avec le message d'erreur relevé tant bien que mal
ALERT!!!! UUID=xxxxx-xxx-xxx-xxxxx-xxxxxxxx DOES not exist........
Au moins on est sur que l'exécution ne se fera pas!

Second boot sans plantage.... Mais on finira bien par se rendre compte qu'il manque une partition....
Le message d'erreur est récupérable facilement.

@a:~$ journalctl -b -p err
-- Logs begin at Fri 2020-07-24 18:03:29 CEST, end at Fri 2020-08-21 12:37:52 CEST. --
août 21 12:35:54 a systemd[1]: Failed to start Import ZFS pools by cache file.
août 21 12:36:59 a gdm-password][2995]: gkr-pam: unable to locate daemon control file
août 21 12:37:06 a systemd[1]: Timed out waiting for device /dev/disk/by-uuid/d344f479-afae-413d-8ff4-a5c1c9b1c9f1.

donc au choix, une codification de ce style
UUID=d344f479-afae-413d-8ff4-a5c1c9b1c9f1 /BADext4 auto nosuid,nodev,nofail,x-gvfs-show 0 2
ou
/dev/disk/by-uuid/d344f479-afae-413d-8ff4-a5c1c9b1c9f1 /BADext4 auto nosuid,nodev,nofail,x-gvfs-show 0 2
(codification obtenue avec l'application gnome-disk-utility

NOTA, je croyais qu'il n'y avait pas de différence de comportement et je vais continuer en essayant de fabriquer une partition ext4 qui a besoin d'être réparée.
Le montage manuel de la partition donne le résultat suivant

sudo mount -v /dev/sda37 /BADext4
mount: /BADext4: wrong fs type, bad option, bad superblock on /dev/sda37, missing codepage or helper program, or other error.

Facile à obtenir avec une commande dd bien adaptée.

AJOUT suite des tests....
La partition est montée avec cette description habituelle

UUID=4faab776-b879-44f8-84ba-401c917fbc00 /media/SDA16 ext4   defaults  0 2

Duplication de gros fichiers dans un répertoire de la partition puis extinction sauvage de l'ordinateur alors que la copie n'est pas finie....
AU reboot, je constate
1) Que la partition n'est pas montée ==> Si les liens sont décrits dans le fichier .config/user-dirs.dirs , ils deviennent cassés. Le problème est connu, On peut très bien faire une commande standard interdisant la destruction des liens.
===> On peut aussi décrire les liens directement dans le répertoire utilisateur afin de préserver le fichier
2) Un message d'erreur non visible pendant le boot est enregistré dans le journal

journalctl -b -p err
-- Logs begin at Fri 2020-07-24 18:03:29 CEST, end at Fri 2020-08-21 14:59:38 CEST. --
août 21 14:55:04 a systemd-fsck[1064]: fsck failed with exit status 8.
août 21 14:55:05 a systemd[1]: Failed to mount /media/SDA16.

3) on peut monter la partition

sudo mount -v /dev/sda16 /media/SDA16 
mount : /dev/sda16 monté sur /media/SDA16.

sudo mount -v /dev/sda16 /media/SDA16
mount: /media/SDA16: /dev/sda16 déjà monté sur /media/SDA16.

4) elle est en bon état

sudo umount -v /dev/sda16 
umount: /media/SDA16 (/dev/sda16) démonté

sudo umount -v /dev/sda16
umount: /dev/sda16: non monté.

sudo fsck /dev/sda16
fsck de util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Ubuntu1910 : propre, 303997/2616320 fichiers, 6496606/10485760 blocs

sudo fsck -f /dev/sda16
fsck de util-linux 2.34
e2fsck 1.45.5 (07-Jan-2020)
Passe 1 : vérification des i-noeuds, des blocs et des tailles
Passe 2 : vérification de la structure des répertoires
Passe 3 : vérification de la connectivité des répertoires
Passe 4 : vérification des compteurs de référence
Passe 5 : vérification de l'information du sommaire de groupe
Ubuntu1910 : 303997/2616320 fichiers (0.9% non contigus), 6496606/10485760 blocs

Au boot suivant, la partition est bien montée.

Dernière modification par geole (Le 21/08/2020, à 14:31)

gibar84 · Le 21/08/2020, à 16:24

Bonjour,

Coeur Noir a écrit :

…et dans les autres trucs qui m'intriguent, il y a le fait qu'on essaie d'aider quelqu'un qui n'a pas l'air super à l'aise avec toutes ces recommandations techniques ( nul reproche à gibar ) mais du coup c'est assez difficile de savoir ce qui fut fait / pas fait…

C'est la vérité et cela ne provoque aucun traumatisme j'ai suffisamment de réalisme pour accepter mon statut de néophyte dont la probabilité de progression en matière d’informatique avoisine les quelques % (je n'aime pas l'auto flagellation) .
Par contre votre constante recherche de solutions à mes problèmes fait mon admiration, j'y ajoute une satisfaction personnelle car depuis quelques semaines je me sens un peu moins nul. (c'est mon coté optimiste)

Depuis le #48 les discussions entre vous se succèdent et j'ai le sentiment que vous avancez vers une solution (les essais réalisés par geole)
Tel un bon petit soldat, je me tiens arme au pied prêt à exécuter vos commandes.

geole · Le 21/08/2020, à 16:29

Coeur Noir a écrit :

Attendons le retour de gibar, espérons que sa machine démarre normalement…

Bonjour
Puisque le fsck est terminé, on attends que tu bootes normalement et que tu décrives ce qui va se passer.......

Coeur Noir · Le 21/08/2020, à 16:53

Ok, donc chez Gibar, reste à savoir pourquoi son disque sdb est parfois absent.

Il y a eu dans un premier temps le fait qu'il n'était pas déclaré dans le fstab ( réglé depuis ).

Manifestement bien que sdb est maintenant déclaré dans le fstab, il arrive à ce disque de ne pas être présent au démarrage ( branchement fragile, alimentation insuffisante, lenteur quelconque ) ?
Il faudrait éliminer ce risque, s'assurer que sdb finisse par monter automatiquement là où Gibar l'attend.

Les suggestions de boot-repair on oublie pour l'instant ?

Dernière modification par Coeur Noir (Le 21/08/2020, à 17:04)

gibar84 · Le 22/08/2020, à 16:19

Bonjour

Coeur Noir a écrit :

Ok, donc chez Gibar, reste à savoir pourquoi son disque sdb est parfois absent.

La réponse (la seule?) peut se trouver parmi les tests que j'ai tentés:
Test 1
Les disques sda et sdb sont actifs (branchés)
Je démarre sur DVD live tout se passe bien
Test 2
Les disques sda et sdb sont actifs (branchés) le système tourne en boucle et bute sur le message qui demande de lancer une maintenance aucune action (entrée, oui) ne débloque la situation, j'ai peut-être eu de la chance (évité de compliquer la situation)
Test 3
Le disque sda actif (branché) le disque sdb inactif (débranché) tout se passe normalement, arrivée sur le bureau ubuntu qui se présente tel qu'il était avant le problème de boot.
Sauf que les activités sont entrées en léthargie à preuve les activités "vitales" comme firefox et thunderbird ne démarrent pas

Dernière modification par gibar84 (Le 22/08/2020, à 17:07)

geole · Le 22/08/2020, à 17:05

Bonjour
Si SDB est bien un disque interne, rebranche-le et reboote.
On va alors reprendre toute l'analyse depuis le début. Il est possible qu'il y ait deux incidents.
Lorsque cela va planter, tu frappes la commande suivante:

  journalctl    -xb

De nouveau, tu photographies ce qui est en rouge et tu postes si tu as un autre ordinateur
et tu continues avec cette commande

   fsck   -y  /dev/sdb1

Comme la dernière fois tu ne photographies que la fin.
et dans la foulée, tu rebootes et tu dis si c'est totalement identique.
Mais, cette fois-ci, en cas de plantage, tu continues en frappant la commande suivante

nano  /etc/fstab

Tu iras mettre un # au début de la ligne qui décrit la partition de données.
L'explication des commandes de nano pour sauver le fichier et quitter nano est décrite dans l'écran de nano en bas à gauche. Le caractère de commande sera frappé juste après l'appui sur la touche Ctrl
Nota. Je ne serais pas disponible ce soir.

On aura alors un ubuntu fonctionnant avec ses deux disques dont l'un sera à monter avec une commande classique qui est nettement plus facile à faire que dans un boot. (sudo mount -v /dev/sdb1 /mnt )

Pour firefox et thunderbird, il est possible que leur répertoire de configuration se soit perdu dans les diverses manipulations. Mais cela devrait pouvoir se réparer.

Dernière modification par geole (Le 22/08/2020, à 17:23)

geole · Le 22/08/2020, à 17:15

geole a écrit :

Bonjour
Un extrait de la réparation

Force Unmount all blkid partitions (for fsck) except / /boot /cdrom /dev /etc /home /opt /pas /proc /rofs /sys /tmp /usr /var
umount: /media/ubuntu/Clé USB: la cible est active.

fsck -fyM /dev/sda1
fsck from util-linux 2.34

fsck -fyM /dev/sdb1
fsck from util-linux 2.34

fsck -fyM /dev/sdc1
fsck from util-linux 2.34

Pas très parlante. Elle est certainement bonne

J'ai fait quelques tests. La réparation n'a pas été faite. J'ai informé le concepteur de l'outil.

Dernière modification par geole (Le 22/08/2020, à 17:19)

gibar84 · Le 22/08/2020, à 17:21

@geole

Tu iras mettre un # au début de la ligne qui décrit la partition de données.
................... après l'appui sur la touche Ctrl

Cette partie me soucie un peu alors peux-tu me rassurer, si je me loupe, la procédure peut-elle être relancée sans problème?

PS
-je n'ai pas de 2ème ordi (portable mais en panne) je ne pense pas que le transfert puisse se faire par smartphone ?
-je ferai la manip lundi matin

geole · Le 22/08/2020, à 17:29

Normalement, il n'y a pas grand risque, le plus difficile étant de jouer avec les touches de positionnement pour se mettre en début de la ligne

Par précaution, on va sauver le fichier avant la manipulation (sauvetage à ne faire qu'une fois)

cp  -v  /etc/fstab    /etc/fstab.OLD
nano /etc/fstab

Il me semble qu'on peut accéder au forum avec un smartphone

Dernière modification par geole (Le 22/08/2020, à 17:30)

gibar84 · Le 24/08/2020, à 10:18

Bonjour,

geole a écrit :

Il me semble qu'on peut accéder au forum avec un smartphone (android)

Bien sûr je le fais très souvent, mais je ne maîtrise pas très bien les nouveaux cas, dans celui qui nous intéresse je pense que le cheminement, (en restant bloqué sur l'écran de l'ordi) serait:
photo écran==>(vérifier poids, si trop important comment le réduire sur smart, je n'ai pas réussi à trouver la solution)==>envoyer photo vers hébergeur==>copier lien==>envoi lien sur le fil
Cela à faire toujours écran ordi bloqué
Attendre réponse pour continuer

Je reviens aux manip que tu me demandes de faire:
1- #69 à partir du terminal

cp  -v  /etc/fstab    /etc/fstab.OLD
nano /etc/fstab

2- #66 reboot et au moment du plantage

  journalctl    -xb

   fsck   -y  /dev/sdb1

nano  /etc/fstab

(pour simplifier je les ai rassemblées mais elles seront à envoyer les unes après les autres)

Pour toutes ces commandes comme je ne peux pas faire un copier/coller
je pense que les lignes débutent toujours à l'extrémité gauche de l'écran ?.
mais qu'en est-il des espaces? je vois des 2-3 et peut-être 4 unités

Dernière modification par gibar84 (Le 24/08/2020, à 10:20)

geole · Le 24/08/2020, à 11:41

Bonjour
Le nombre d'espaces entre chaque mot est sans importance, il en faut au moins un.

gibar84 · Le 24/08/2020, à 15:00

cp  -v  /etc/fstab    /etc/fstab.OLD
nano /etc/fstab

retour

 GNU nano 4.8                       /etc/fstab                       Modifié  
overlay / overlay rw 0 0
tmpfs /tmp tmpfs nosuid,nodev 0 0


^G Aide        ^O Écrire      ^W Chercher    ^K Couper      ^J Justifier
^X Quitter     ^R Lire fich.  ^\ Remplacer   ^U Coller      ^T Orthograp.

Est-ce normal? je peux sortir du DVD live et continuer avec les deux disques branchés, boot et attendre plantage pour lancer les 3 commandes et prendre photos? puis t'envoyer adresses toile libre

geole · Le 24/08/2020, à 15:15

Si tu veux faire la manipulation avec le live-DVD, il faut monter la partition de boot du disque interne avant de modifier
Cela va donc donner les commandes suivantes
1) Reconnaître les partitions en regardant leur taille

lsblk  -e7

Je pense que sda sera le DVD , que le ssd sera SDB et que le gros disque sera SDC
2) Montage

sudo mount -v   /dev/sda1  /mnt

3) Sauvegarde

sudo  cp /mnt/etc/fstab  /mnt/etc/fstab.OLD

4) La modification

sudo nano /mnt/etc/fstab

5) Le contrôle

cat /mnt/etc/fstab

Le boot avec les deux disques durs branchés devrait alors être possible sans plantage.
Lorsque tu auras la main, en ligne de commande tu monteras la partition de données.

sudo   mount   -v /dev/sdb1  /mnt

Il devrait alors y avoir un message d'erreur que tu indiqueras du mieux possible

Sinon tu bootes et tu attends le plantage pour faire la modification
Après la modification tu rebootes et même démarche pour monter la partition de données

Dernière modification par geole (Le 24/08/2020, à 15:28)

geole · Le 24/08/2020, à 15:27

Rectification.
En regardant le boot-info. fait en live cela est bien le SDA.

Dernière modification par geole (Le 24/08/2020, à 15:28)

gibar84 · Le 24/08/2020, à 15:55

lsblk  -e7

retour

ubuntu@ubuntu:~$ lsblk  -e7
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 223,6G  0 disk 
└─sda1   8:1    0 223,6G  0 part 
sdb      8:16   0   1,8T  0 disk 
├─sdb1   8:17   0   1,8T  0 part 
└─sdb2   8:18   0   7,8G  0 part [SWAP]
sdc      8:32   1   7,2G  0 disk 
└─sdc1   8:33   1   7,2G  0 part /media/ubuntu/Clé USB
sr0     11:0    1   2,5G  0 rom  /cdrom

ps sr0 doit correspondre à la clé usb actuellement montée

ubuntu@ubuntu:~$ sudo mount -v   /dev/sdb1  /mnt
mount : /dev/sdb1 monté sur /mnt.
ubuntu@ubuntu:~$

sudo mount -v   /dev/sda1  /mnt

retour

ubuntu@ubuntu:~$ sudo mount -v   /dev/sdb1  /mnt
mount : /dev/sdb1 monté sur /mnt.
ubuntu@ubuntu:~$

sudo  cp /mnt/etc/fstab  /mnt/etc/fstab.OLD

retour

ubuntu@ubuntu:~$ sudo  cp /mnt/etc/fstab  /mnt/etc/fstab.OLD
cp: impossible d'évaluer '/mnt/etc/fstab': Aucun fichier ou dossier de ce type
ubuntu@ubuntu:~$

sudo nano /mnt/etc/fstab

retour

  GNU nano 4.8                     /mnt/etc/fstab  

  [ Le répertoire « /mnt/etc » n'existe pas ]

cat /mnt/etc/fstab

retour

ubuntu@ubuntu:~$ cat /mnt/etc/fstab
cat: /mnt/etc/fstab: Aucun fichier ou dossier de ce type
ubuntu@ubuntu:~$

Tous ces retours permettent-ils de passer à la suite

Le boot avec les deux disques durs branchés devrait alors être possible sans plantage.
Il devrait alors y avoir un message d'erreur que tu indiqueras du mieux possible

Dernière modification par gibar84 (Le 24/08/2020, à 16:02)

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#51 Le 20/08/2020, à 17:44

Re : [RESOLU]Problème BIOS

#52 Le 20/08/2020, à 18:02

Re : [RESOLU]Problème BIOS

#53 Le 20/08/2020, à 18:38

Re : [RESOLU]Problème BIOS

#54 Le 20/08/2020, à 19:09

Re : [RESOLU]Problème BIOS

#55 Le 20/08/2020, à 19:37

Re : [RESOLU]Problème BIOS

#56 Le 20/08/2020, à 20:04

Re : [RESOLU]Problème BIOS

#57 Le 20/08/2020, à 20:26

Re : [RESOLU]Problème BIOS

#58 Le 20/08/2020, à 20:47

Re : [RESOLU]Problème BIOS

#59 Le 20/08/2020, à 21:10

Re : [RESOLU]Problème BIOS

#60 Le 20/08/2020, à 21:57

Re : [RESOLU]Problème BIOS

#61 Le 21/08/2020, à 12:30

Re : [RESOLU]Problème BIOS

#62 Le 21/08/2020, à 16:24

Re : [RESOLU]Problème BIOS

#63 Le 21/08/2020, à 16:29

Re : [RESOLU]Problème BIOS

#64 Le 21/08/2020, à 16:53

Re : [RESOLU]Problème BIOS

#65 Le 22/08/2020, à 16:19

Re : [RESOLU]Problème BIOS

#66 Le 22/08/2020, à 17:05

Re : [RESOLU]Problème BIOS

#67 Le 22/08/2020, à 17:15

Re : [RESOLU]Problème BIOS

#68 Le 22/08/2020, à 17:21

Re : [RESOLU]Problème BIOS

#69 Le 22/08/2020, à 17:29

Re : [RESOLU]Problème BIOS

#70 Le 24/08/2020, à 10:18

Re : [RESOLU]Problème BIOS

#71 Le 24/08/2020, à 11:41

Re : [RESOLU]Problème BIOS

#72 Le 24/08/2020, à 15:00

Re : [RESOLU]Problème BIOS

#73 Le 24/08/2020, à 15:15

Re : [RESOLU]Problème BIOS

#74 Le 24/08/2020, à 15:27

Re : [RESOLU]Problème BIOS

#75 Le 24/08/2020, à 15:55

Re : [RESOLU]Problème BIOS

Pied de page des forums