usr sur autre partition non pris en compte au démarrage

Posté par mik-Collectif le 09 mars 2017 à 20:09. Licence CC By‑SA.

Étiquettes : aucune

mar.

2017

Bonjour,

Je suis sur Xubuntu 16.04 LTS 2, un petit pc basse conso (AsRock) mais avec un carte intégrée qui pose toujours des soucis (gma500), bien que là ce ne soit pas le problème.
Je précise que je ne suis pas novice mais pas administrateur non plus.
J'entretiens le pc d'une association ou il y a beaucoup de chose installées.
Dernièrement j'ai laissé les mises à jour se faire et boom! un classique.
Le système n'était pas trop stable depuis un moment déjà, c'éait quitte ou double et bien c'est quitte.
Habitué de ce genre de problème, j'ai donc les partitions /usr et /home qui sont séparées
et bien sure les données sont stockées sur un disque externes.

Je suis passé par Boot-Repair pensant que le problème venait de là mais, grave erreur.
Boot-Repair tiens très mal compte des partitions séparées et j'ai mis plusieurs jours à tout refaire
Grub pointait sur (hd0,ms_dos8) qui est en fait la partition /usr !
Bref, avec une autre clé, j'ai réinstallé en chroot. La aussi, j'ai mis du temps à comprendre
qu'il fallait monter aussi les partition séparées /home et /usr avec prop etc…

J'ai réinstallé le noyau en chroot aussi mais la première fois sans savoir qu'il y avait besoin
de faire attention aux fameuses partitions.

Du coup maintenant que tout pourrait marcher, le GRUB refonctionne, le noyau semble avoir aucun soucis,
(fsck /dev/sda1 est normal, et le noyau s'est très bien installé sans erreur la dernière fois), mais
un répertoire créer sans doute au moment de l'installe du noyau s'est créé.

Comme les liens sont détruits, il faut passer par la version upstart, au prompt je rentre id et psswd sans soucis, mais il indique alors de suite
sh : 1 : /usr/bin/dev : not found
une fois logger je n'ai accès qu'a quelques commandes qui m'ont permis de comprendre que je pointais sur un /usr presque vide.
Je l'ai renommé, et regardé dans le fstab mais tout est ok.
Bref je ne vois pas quoi faire d'autre.
je mets le fstab de la partition /dev/sda1 (ou est le Xubuntu)
/etc/fstab: static file system information.

Use 'blkid' to print the universally unique identifier for a
 device; this may be used with UUID= as a more robust way to name devices
 that works even if disks are added and removed. See fstab(5).

# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=538d443f-27fe-44c0-8147-5675da6ac83f /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda6 during installation
UUID=d9b8e176-5cc9-4bf3-85ee-4b88ce873eb4 /home           ext4    defaults        0       2
# /usr was on /dev/sda8 during installation
UUID=d244abfc-e194-4bfb-a7db-cba174c92147 /usr            ext4    defaults        0       2
# swap was on /dev/sda5 during installation
UUID=50d8e9a0-69cb-4820-a632-143ecf31674c none            swap    sw              0       0

Quelqu'un sait à quel endroit se fait le pointage, je croyais avoir compris que c'était fstab.
Merci d'avance

Michaël

# d'apres ton FSTAB

Posté par NeoX le 09 mars 2017 à 21:18. Évalué à 2.

d'apres ton /etc/fstab
il cherche a monter /usr à partir de la partition qui à l'UUID suivant :

UUID=d244abfc-e194-4bfb-a7db-cba174c92147 /usr ext4 defaults 0 2

tu peux verifier l'UUID des partitions en faisant la commande
blkid qui va confirmer si la partition d244….92147 existe

ou pas.
- [^] # Re: d'apres ton FSTAB
  
  Posté par totof2000 le 09 mars 2017 à 21:29. Évalué à 1.
  
  J'ai eu exactement ce problème lors de la mise à jour de la machine de ma fille : je suis passé de ubuntu 14.04 à Ubuntu 16.04.
  
  Ce qui est le plus comique, c'est que je me souviens très bien avoir viré les UUID de partition à une époque mais qu'un abruti de développeur ou de mainteneur a décidé que c'est mieux les UUID (et dans ce cas je l'invite à être cohérent avec lui-même et de cesser d'utiliser les DNS), et ma machine s'est retrouvé avec un truc que je n'ai pas demandé. Par contre je ne peux pas certifier que c'est la mise à jours vars 16.04 qui a pêté ma fstab : c'est peut-être une autre mise à jour qui a fait le coup.
- [^] # Re: d'apres ton FSTAB
  
  Posté par mik-Collectif le 09 mars 2017 à 23:46. Évalué à 1.
  
  Oui j'ai vérifié 50 fois, c'est le bon UUID pour /usr.
  Pas de soucis.
  Merci
  - [^] # Re: d'apres ton FSTAB
    
    Posté par ʭ ☯ le 10 mars 2017 à 08:52. Évalué à 2.
    
    J'essayerais de passer en LABEL ou en /dev/s*** pour cette partition pour voir…
    
    ⚓ À g'Auch TOUTE! http://afdgauch.online.fr
# /usr merge ?

Posté par kna le 10 mars 2017 à 10:56. Évalué à 4.

Je ne sais pas si c'est la cause de ton problème, mais la plupart des distributions migrent petit à petit tous les binaires de /bin et /sbin dans /usr/bin et /usr/sbin, /bin et /sbin deviendront à terme des liens symboliques vers /usr/bin et /usr/sbin (c'est déjà le cas sur certaines distributions) : https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Lors de ta mise à jour, il y a peut-être un binaire utile au boot qui a été déplacé ainsi, le boot serait alors « cassé » ce qui bloquerait le montage de /usr (où bêtement, mount à été déplacé de /bin vers /usr/bin ?).

Néanmoins normalement /usr devrait être monté par l'initramfs pour pouvoir booter sans avoir ce type de problème. Voir aussi : https://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken/

Je ne me suis pas plus penché sur le sujet, mais ça peut être une piste…
- [^] # Re: /usr merge ?
  
  Posté par remico le 10 mars 2017 à 11:11. Évalué à 1.
  
  Oui c'est ce que je pensais aussi.
  
  Il est possible que lors de l'opération de récupération, certains fichiers se soient créés dans le répertoire /usr avec la partition non-montée.
  
  Par exemple si je crée un fichier dans le répertoire /mnt/sda3
  ls me le liste bien
  Si je monte /dev/sda3 sur /mnt/sda3, ls me liste les fichier de sda3 mais plus mon fichier.
  
  Il faudrait vérifier avec que /usr ne s'est pas recréé avec des fichiers importants. Sur ma distrib /bin et /sbin sont des liens symboliques vers /usr autrement dit je n'aurait vraiment rien qui marche en cas de perte d'/usr.
- [^] # Re: /usr merge ?
  
  Posté par mik-Collectif le 10 mars 2017 à 15:35. Évalué à 1.
  
  Bonsoir,
  
  On peut classer ce bug comme résolu.
  IL y avait un # devant le ligne de /usr dans le fstab.
  Mais il en reste d'autre dont la piste est certainement celle que tu signales
  
  Il serait important de faire remonter à la communauté fr qu'il y a plusieurs soucis qui
  ne sont pas assez signalés dans les tutos dans le cas des gens qui ont un /usr sur une autre partition.
  
  En effet, Boot-Repair a mis une panique totale dans le GRUB, il m'a fallu deux jours pour
  tout remettre à zéro, en allant jusqu'à effacer complètement le MBR.
  Comme le montre ce rapport, il croit que le 'root' est (hd0,ms_dos8)…. qui est justement /usr.
  Bref, le chaos !
  J'aurais du me douter du problème, car en effet il ouvre une fenêtre en demandant si /usr et sur une partition séparée…. mais il n'en tient pas vraiment compte visiblement.
  
  Il faut aussi signaler, à partir de tutos U.S, au moment de le réinstaller en chroot de bien penser à monter les deux partitions esseulées, j'ai pu ainsi repartir avec un GRUB tout neuf.
  
  mount /dev/sda1 /mnt
  
  immédiatement suivi de :
  
  mount /dev/sda8 /mnt/usr
  et aussi
  mount /dev/sda6 /mnt/home
  
  Ces histoires de partitions sont aussi à utiliser pour la ré-installation du noyau.
  C'est peut être que ne le sachant pas les premières fois, j'ai fait des installe sans /usr montée.
  Est-ce Boot-repair ou l'installe qui à mis le #?
  Bref, il manque des procédures stables pour les cas /usr séparés.
  
  Voilà, il n'empêche que maintenant il reste un bug étrange. Mais c'est pour un autre fil.
  Merci
- [^] # Re: /usr merge ?
  
  Posté par mik-Collectif le 10 mars 2017 à 15:42. Évalué à 1.
  
  Bonsoir,
  
  On peut classer ce bug comme résolu.
  IL y avait un # devant le ligne de /usr dans le fstab.
  Mais il en reste d'autre dont la piste est certainement celle que tu signales
  
  Il serait important de faire remonter à la communauté fr qu'il y a plusieurs soucis qui
  ne sont pas assez signalés dans les tutos dans le cas des gens qui ont un /usr sur une autre partition.
  
  En effet, Boot-Repair a mis une panique totale dans le GRUB, il m'a fallu deux jours pour
  tout remettre à zéro, en allant jusqu'à effacer complètement le MBR.
  Comme le montre ce rapport ici, il croit que le 'root' est (hd0,ms_dos8)…. qui est justement /usr.
  Bref, le chaos !
  J'aurais du me douter du problème, car en effet il ouvre une fenêtre en demandant si /usr et sur une partition séparée…. mais il n'en tient pas vraiment compte visiblement.
  
  Il faut aussi signaler, à partir de tutos U.S, au moment de le réinstaller en chroot de bien penser à monter les deux partitions esseulées, j'ai pu ainsi repartir avec un GRUB tout neuf.
  
  mount /dev/sda1 /mnt
  
  immédiatement suivi de :
  
  mount /dev/sda8 /mnt/usr
  et aussi
  mount /dev/sda6 /mnt/home
  
  Ces histoires de partitions sont aussi à utiliser pour la ré-installation du noyau.
  C'est peut être que ne le sachant pas les premières fois, j'ai fait des installe sans /usr montée.
  Est-ce Boot-repair ou l'installe qui à mis le #?
  Bref, il manque des procédures stables pour les cas /usr séparés.
  
  Voilà, il n'empêche que maintenant il reste un bug étrange. Mais c'est pour un autre fil.
  Merci

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.