J'ai installé btrfs sur une machine et tout s'est bien passé
jusqu'ici... Et là c'est cassé.
C'est sur Archlinux, au cas où ça servirait.
Les dernières nouvelles de la machine avant redémarrage : quelques
mises à jour (dont le noyau), un manifeste plantage du lecteur flash.
Les trucs flash ne s'affichaient plus, peut-être depuis les mises à
jour sans redémarrage à suivre ; ça ne m'a pas trop inquiété mais ça a
lancé un systemd-journal qui s'excitait sur le processeur. Ca arrive
aussi en cas de plantage de Firefox, c'est casse-pieds mais en général
ça passe. Là ça ne passait pas trop, mais j'ai a priori réussi à
éteindre la machine proprement.
Ca m'étonnerait que tout ça soit très utile... Maintenant qu'est-ce qui
s'affiche au démarrage :
"
Booting the kernel.
:: running early hook [udev]
:: running hook [udev]
:: Triggering uevents...
:: running hook [btrfs]
Scanning for btrfs filesystems
failed to open /dev/btrfs-control skipping device registration: No such
file or directory
failed to open /dev/btrfs-control skipping device registration: No such
file or directory
failed to open /dev/btrfs-control skipping device registration: No such
file or directory
failed to open /dev/btrfs-control skipping device registration: No such
file or directory
failed to open /dev/sr0: No medium found
:: mounting '/dev/sda3' on real root
mount: wrong fs type, bad option, bad superblock on /dev/sda3,
missing codepage or helper program, or other error
In some case useful info is found in syslog - try
dmesg | tail or so.
You are now being dropped into an emergency shell.
sh: can't access tty; job control turned off
[rootfs /]#
"
Les dernières lignes affichées par dmesg, qui parlent de btrfs :
"
Btrfs loaded
device fsid <un long numéro en hexa> devid 1 transid 70632 /dev/sda3
btrfs: disk space caching is enabled
btrfs: failed to read the systm array on sda3
btrfs: open_ctree failed
Switched to clocksource tsc
"
/dev/sda3, /dev/sda4, /dev/sdb3, /dev/sdb4 et /dev/btrfs-control
apparaissent bien si je fais un "ls /dev".
L'amorceur est syslinux, mais je ne sais pas si c'est encore lui qui
bosse ici, je suppose que le noyau a pris la main et que tout dépend de
lui à ce moment.
Les disques sont sans doute assez pleins (difficile à dire avec btrfs)
mais ça n'a pas l'air d'être le problème ici (?).
A priori j'ai deux partitions btrfs sur /dev/sda3 (/) et /dev/sda4
(/home) et la même chose, en miroir, sur /dev/sdb3 et /dev/sdb4.
Et une bonne nouvelle dans ce bazar : dans le pauvre shell qui apparaît
après ces messages d'erreur je peux faire :
mkdir /mnt
mount /dev/sdb3 /mnt
mount /dev/sdb4 /mnt/home
et mes fichiers apparaissent dans /mnt, donc tout ne semble pas perdu.
Avec /dev/sda3 j'ai le même message d'erreur que plus haut : "wrong fs
type, bad option, ...". Et si je fais un "btrfsck /dev/sda3" je peux
ensuite le monter normalement (sur /mnt par exemple, comme plus haut),
mais même après un démontage propre avec umount au démarrage suivant
c'est à nouveau la même chose (notons quand même que le redémarrage
c'est à l'arrache, je n'arrive pas à éteindre la machine sinon, mais
umount se termine correctement).
Je n'ai pas trop d'idées pour le rétablissement de la situation...
Est-ce qu'il faut que je tente de réassembler les éléments avec des
trucs comme "btrfs device add" ? Qu'est-ce qui pourrait faire que la
partition à monter a l'air cassée à chaque démarrage ?
Ca a l'air de parler plutôt de récupérer des données sans réparer le système de fichiers.
Comme je peux monter les partitions de /dev/sdb et même "réparer" temporairement celles de /dev/sda je devrais peut-être compter sur les capacités de réparation de btrfs ? Monter les /dev/sdb*, rajouter les /dev/sda* avec "btrfs device add" et le laisser reconstruire ça correctement ?
Mais comme je ne connais pas trop et que je voudrais éviter de faire une connerie irréversible, je préfère voir s'il y a quelques avis sur le sujet...
Le Mon, 23 Sep 2013 11:34:03 +0200
didier gaumet <didier.gaumet@gmail.com> a écrit :
Ca a l'air de parler plutôt de récupérer des données sans réparer le
système de fichiers.
Comme je peux monter les partitions de /dev/sdb et même "réparer"
temporairement celles de /dev/sda je devrais peut-être compter sur les
capacités de réparation de btrfs ? Monter les /dev/sdb*, rajouter
les /dev/sda* avec "btrfs device add" et le laisser reconstruire ça
correctement ?
Mais comme je ne connais pas trop et que je voudrais éviter de faire
une connerie irréversible, je préfère voir s'il y a quelques avis sur
le sujet...
Ca a l'air de parler plutôt de récupérer des données sans réparer le système de fichiers.
Comme je peux monter les partitions de /dev/sdb et même "réparer" temporairement celles de /dev/sda je devrais peut-être compter sur les capacités de réparation de btrfs ? Monter les /dev/sdb*, rajouter les /dev/sda* avec "btrfs device add" et le laisser reconstruire ça correctement ?
Mais comme je ne connais pas trop et que je voudrais éviter de faire une connerie irréversible, je préfère voir s'il y a quelques avis sur le sujet...
Yliur
Le Mon, 23 Sep 2013 13:45:47 +0200 Yliur a écrit :
Le Mon, 23 Sep 2013 11:34:03 +0200 didier gaumet a écrit :
Ca a l'air de parler plutôt de récupérer des données sans réparer le système de fichiers.
Comme je peux monter les partitions de /dev/sdb et même "réparer" temporairement celles de /dev/sda je devrais peut-être compter sur les capacités de réparation de btrfs ? Monter les /dev/sdb*, rajouter les /dev/sda* avec "btrfs device add" et le laisser reconstruire ça correctement ?
Mais comme je ne connais pas trop et que je voudrais éviter de faire une connerie irréversible, je préfère voir s'il y a quelques avis sur le sujet...
Si j'ai bien compris, le montage manuel de ma partition racine devrait se faire sur /new_root dans cet environnement de secours, puis exit pour poursuivre le démarrage, non ? Quelqu'un (sur un forum) parle aussi d'un montage sur /root en plus, est-ce qu'il faut le faire ?
Le Mon, 23 Sep 2013 13:45:47 +0200
Yliur <yliur@free.fr> a écrit :
Le Mon, 23 Sep 2013 11:34:03 +0200
didier gaumet <didier.gaumet@gmail.com> a écrit :
Ca a l'air de parler plutôt de récupérer des données sans réparer le
système de fichiers.
Comme je peux monter les partitions de /dev/sdb et même "réparer"
temporairement celles de /dev/sda je devrais peut-être compter sur les
capacités de réparation de btrfs ? Monter les /dev/sdb*, rajouter
les /dev/sda* avec "btrfs device add" et le laisser reconstruire ça
correctement ?
Mais comme je ne connais pas trop et que je voudrais éviter de faire
une connerie irréversible, je préfère voir s'il y a quelques avis sur
le sujet...
Si j'ai bien compris, le montage manuel de ma partition racine devrait
se faire sur /new_root dans cet environnement de secours, puis exit
pour poursuivre le démarrage, non ? Quelqu'un (sur un forum) parle aussi
d'un montage sur /root en plus, est-ce qu'il faut le faire ?
Ca a l'air de parler plutôt de récupérer des données sans réparer le système de fichiers.
Comme je peux monter les partitions de /dev/sdb et même "réparer" temporairement celles de /dev/sda je devrais peut-être compter sur les capacités de réparation de btrfs ? Monter les /dev/sdb*, rajouter les /dev/sda* avec "btrfs device add" et le laisser reconstruire ça correctement ?
Mais comme je ne connais pas trop et que je voudrais éviter de faire une connerie irréversible, je préfère voir s'il y a quelques avis sur le sujet...
Si j'ai bien compris, le montage manuel de ma partition racine devrait se faire sur /new_root dans cet environnement de secours, puis exit pour poursuivre le démarrage, non ? Quelqu'un (sur un forum) parle aussi d'un montage sur /root en plus, est-ce qu'il faut le faire ?
didier gaumet
j'avais regardé un peu trop vite... je pense qu'un btrfsck avec l'option --repair lancée depuis un live-cd ou live-usb sur ta partition /dev/sda3 démontée devrait solutionner ton problème, avec un peu de chance.
-s|--super <superblock> use this superblock copy --repair try to repair the filesystem --init-csum-tree create a new CRC tree --init-extent-tree create a new extent tree
j'avais regardé un peu trop vite...
je pense qu'un btrfsck avec l'option --repair lancée depuis un live-cd
ou live-usb sur ta partition /dev/sda3 démontée devrait solutionner ton
problème, avec un peu de chance.
-s|--super <superblock> use this superblock copy
--repair try to repair the filesystem
--init-csum-tree create a new CRC tree
--init-extent-tree create a new extent tree
j'avais regardé un peu trop vite... je pense qu'un btrfsck avec l'option --repair lancée depuis un live-cd ou live-usb sur ta partition /dev/sda3 démontée devrait solutionner ton problème, avec un peu de chance.
-s|--super <superblock> use this superblock copy --repair try to repair the filesystem --init-csum-tree create a new CRC tree --init-extent-tree create a new extent tree
Yliur
Le Mon, 23 Sep 2013 23:21:59 +0200 didier gaumet a écrit :
j'avais regardé un peu trop vite... je pense qu'un btrfsck avec l'option --repair lancée depuis un live-cd ou live-usb sur ta partition /dev/sda3 démontée devrait solutionner ton problème, avec un peu de chance.
J'avais essayé ce genre de choses (btrfs check --repair) et j'ai réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau pareil.
Donc pour démarrer le système entièrement j'ai fait ça dans l'environnement de secours proposé à la suite de l'échec du montage de la partition : btrfs check --repair /dev/sda3 mount /dev/sda3 new_root exit
Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
Quelques points étranges : - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça échoue. À ce moment je peux réparer sda3 comme indiqué plus haut et la monter, ou monter directement sdb3, la partition miroir, sans avoir besoin de la réparer - Plus bizarre mais peut-être pas très utile : quand sda3 est "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé. - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition racine c'est cette partition qui est cassée et sda3 que je peux utiliser directement, sans réparation. - Les deux partitions ont le même uuid, c'est normal ? Si je fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça échoue comme si je la désignais directement.
Des idées ?
Le Mon, 23 Sep 2013 23:21:59 +0200
didier gaumet <didier.gaumet@gmail.com> a écrit :
j'avais regardé un peu trop vite...
je pense qu'un btrfsck avec l'option --repair lancée depuis un live-cd
ou live-usb sur ta partition /dev/sda3 démontée devrait solutionner
ton problème, avec un peu de chance.
J'avais essayé ce genre de choses (btrfs check --repair) et j'ai
réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau
pareil.
Donc pour démarrer le système entièrement j'ai fait ça dans
l'environnement de secours proposé à la suite de l'échec du montage de
la partition :
btrfs check --repair /dev/sda3
mount /dev/sda3 new_root
exit
Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
Quelques points étranges :
- Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça
échoue. À ce moment je peux réparer sda3 comme indiqué plus haut
et la monter, ou monter directement sdb3, la partition miroir,
sans avoir besoin de la réparer
- Plus bizarre mais peut-être pas très utile : quand sda3 est
"cassée", sdb4 l'est aussi, et réciproquement : c'est croisé.
- Si je dis à syslinux d'utiliser /dev/sdb3 comme partition racine
c'est cette partition qui est cassée et sda3 que je peux utiliser
directement, sans réparation.
- Les deux partitions ont le même uuid, c'est normal ? Si je
fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça échoue
comme si je la désignais directement.
Le Mon, 23 Sep 2013 23:21:59 +0200 didier gaumet a écrit :
j'avais regardé un peu trop vite... je pense qu'un btrfsck avec l'option --repair lancée depuis un live-cd ou live-usb sur ta partition /dev/sda3 démontée devrait solutionner ton problème, avec un peu de chance.
J'avais essayé ce genre de choses (btrfs check --repair) et j'ai réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau pareil.
Donc pour démarrer le système entièrement j'ai fait ça dans l'environnement de secours proposé à la suite de l'échec du montage de la partition : btrfs check --repair /dev/sda3 mount /dev/sda3 new_root exit
Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
Quelques points étranges : - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça échoue. À ce moment je peux réparer sda3 comme indiqué plus haut et la monter, ou monter directement sdb3, la partition miroir, sans avoir besoin de la réparer - Plus bizarre mais peut-être pas très utile : quand sda3 est "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé. - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition racine c'est cette partition qui est cassée et sda3 que je peux utiliser directement, sans réparation. - Les deux partitions ont le même uuid, c'est normal ? Si je fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça échoue comme si je la désignais directement.
Des idées ?
didier gaumet
Le 24/09/2013 16:22, Yliur a écrit :
J'avais essayé ce genre de choses (btrfs check --repair) et j'ai réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau pareil.
Donc pour démarrer le système entièrement j'ai fait ça dans l'environnement de secours proposé à la suite de l'échec du montage de la partition : btrfs check --repair /dev/sda3 mount /dev/sda3 new_root exit
il faudrait peut-être faire un mount dans cet environnement pour voir ce qui est monté. je préfèrerais utiliser un livecd ou liveusb pour effectuer les commandes btrfsck --repair sur les quatre partitions en question sda et sdb, 3 et 4.
Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
- le shell de secours n'est peut-être pas le contexte idéal pour le btrfsck - tu n'as peut-être pas fait une réparation sur les quatre partitions - il faut peut-être effectuer des manips au niveau du RAID, puisque tu en utilises un (dmraid --rebuild ou quelque chose du même genre?)
Quelques points étranges : - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça échoue. À ce moment je peux réparer sda3 comme indiqué plus haut et la monter, ou monter directement sdb3, la partition miroir, sans avoir besoin de la réparer - Plus bizarre mais peut-être pas très utile : quand sda3 est "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé. - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition racine c'est cette partition qui est cassée et sda3 que je peux utiliser directement, sans réparation. - Les deux partitions ont le même uuid, c'est normal ? Si je fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça échoue comme si je la désignais directement.
Des idées ?
comme je n'ai pas utilisé Syslinux ni le RAID, je peux difficilement te répondre intelligemment et j'ai bien peur de ne pas avoir d'autres idées
Le 24/09/2013 16:22, Yliur a écrit :
J'avais essayé ce genre de choses (btrfs check --repair) et j'ai
réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau
pareil.
Donc pour démarrer le système entièrement j'ai fait ça dans
l'environnement de secours proposé à la suite de l'échec du montage de
la partition :
btrfs check --repair /dev/sda3
mount /dev/sda3 new_root
exit
il faudrait peut-être faire un mount dans cet environnement pour voir ce
qui est monté.
je préfèrerais utiliser un livecd ou liveusb pour effectuer les
commandes btrfsck --repair sur les quatre partitions en question sda et
sdb, 3 et 4.
Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
- le shell de secours n'est peut-être pas le contexte idéal pour le btrfsck
- tu n'as peut-être pas fait une réparation sur les quatre partitions
- il faut peut-être effectuer des manips au niveau du RAID, puisque tu
en utilises un (dmraid --rebuild ou quelque chose du même genre?)
Quelques points étranges :
- Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça
échoue. À ce moment je peux réparer sda3 comme indiqué plus haut
et la monter, ou monter directement sdb3, la partition miroir,
sans avoir besoin de la réparer
- Plus bizarre mais peut-être pas très utile : quand sda3 est
"cassée", sdb4 l'est aussi, et réciproquement : c'est croisé.
- Si je dis à syslinux d'utiliser /dev/sdb3 comme partition racine
c'est cette partition qui est cassée et sda3 que je peux utiliser
directement, sans réparation.
- Les deux partitions ont le même uuid, c'est normal ? Si je
fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça échoue
comme si je la désignais directement.
Des idées ?
comme je n'ai pas utilisé Syslinux ni le RAID, je peux difficilement te
répondre intelligemment et j'ai bien peur de ne pas avoir d'autres idées
J'avais essayé ce genre de choses (btrfs check --repair) et j'ai réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau pareil.
Donc pour démarrer le système entièrement j'ai fait ça dans l'environnement de secours proposé à la suite de l'échec du montage de la partition : btrfs check --repair /dev/sda3 mount /dev/sda3 new_root exit
il faudrait peut-être faire un mount dans cet environnement pour voir ce qui est monté. je préfèrerais utiliser un livecd ou liveusb pour effectuer les commandes btrfsck --repair sur les quatre partitions en question sda et sdb, 3 et 4.
Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
- le shell de secours n'est peut-être pas le contexte idéal pour le btrfsck - tu n'as peut-être pas fait une réparation sur les quatre partitions - il faut peut-être effectuer des manips au niveau du RAID, puisque tu en utilises un (dmraid --rebuild ou quelque chose du même genre?)
Quelques points étranges : - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça échoue. À ce moment je peux réparer sda3 comme indiqué plus haut et la monter, ou monter directement sdb3, la partition miroir, sans avoir besoin de la réparer - Plus bizarre mais peut-être pas très utile : quand sda3 est "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé. - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition racine c'est cette partition qui est cassée et sda3 que je peux utiliser directement, sans réparation. - Les deux partitions ont le même uuid, c'est normal ? Si je fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça échoue comme si je la désignais directement.
Des idées ?
comme je n'ai pas utilisé Syslinux ni le RAID, je peux difficilement te répondre intelligemment et j'ai bien peur de ne pas avoir d'autres idées
Yliur
Le Tue, 24 Sep 2013 19:42:21 +0200 didier gaumet a écrit :
Le 24/09/2013 16:22, Yliur a écrit :
> J'avais essayé ce genre de choses (btrfs check --repair) et j'ai > réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau > pareil. > > Donc pour démarrer le système entièrement j'ai fait ça dans > l'environnement de secours proposé à la suite de l'échec du montage > de la partition : > btrfs check --repair /dev/sda3 > mount /dev/sda3 new_root > exit
il faudrait peut-être faire un mount dans cet environnement pour voir ce qui est monté.
Là je travaille sur la machine donc je ne vais pas vérifier maintenant, mais pourquoi cette remarque ? A priori le problème se déclenche parce que la partition racine n'a pas été montée.
je préfèrerais utiliser un livecd ou liveusb pour effectuer les commandes btrfsck --repair sur les quatre partitions en question sda et sdb, 3 et 4.
Pourquoi ? Au cas où quelque chose serait à moitié monté ? Je peux faire ces 4 opérations tant que je n'ai rien monté à la main et quand j'ai monté une des partitions, je ne peux plus effectuer l'opération ni sur elle ni sur sa partition miroir.
> Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
- le shell de secours n'est peut-être pas le contexte idéal pour le btrfsck - tu n'as peut-être pas fait une réparation sur les quatre partitions
Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est toujours la première que je regarde.
- il faut peut-être effectuer des manips au niveau du RAID, puisque tu en utilises un (dmraid --rebuild ou quelque chose du même genre?)
Le raid est géré par btrfs. Si je ne dis pas de bêtises, au montage d'une partition il cherche les miroirs (elles sont peut-être écrites dans les méta-données de chaque partition, je ne sais pas) et il assemble le tout. Enfin il y a aussi une histoire de recherche des partitions concernées par btrfs pour les monter correctement, en principe effectué tout seul au démarrage.
> Quelques points étranges : > - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça > échoue. À ce moment je peux réparer sda3 comme indiqué plus > haut et la monter, ou monter directement sdb3, la partition miroir, > sans avoir besoin de la réparer > - Plus bizarre mais peut-être pas très utile : quand sda3 est > "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé. > - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition > racine c'est cette partition qui est cassée et sda3 que je peux > utiliser directement, sans réparation. > - Les deux partitions ont le même uuid, c'est normal ? Si je > fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça > échoue comme si je la désignais directement. > > Des idées ?
comme je n'ai pas utilisé Syslinux ni le RAID, je peux difficilement te répondre intelligemment et j'ai bien peur de ne pas avoir d'autres idées
Merci pour les suggestions en tout cas.
Le Tue, 24 Sep 2013 19:42:21 +0200
didier gaumet <didier.gaumet@gmail.com> a écrit :
Le 24/09/2013 16:22, Yliur a écrit :
> J'avais essayé ce genre de choses (btrfs check --repair) et j'ai
> réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau
> pareil.
>
> Donc pour démarrer le système entièrement j'ai fait ça dans
> l'environnement de secours proposé à la suite de l'échec du montage
> de la partition :
> btrfs check --repair /dev/sda3
> mount /dev/sda3 new_root
> exit
il faudrait peut-être faire un mount dans cet environnement pour voir
ce qui est monté.
Là je travaille sur la machine donc je ne vais pas vérifier maintenant,
mais pourquoi cette remarque ? A priori le problème se déclenche parce
que la partition racine n'a pas été montée.
je préfèrerais utiliser un livecd ou liveusb pour effectuer les
commandes btrfsck --repair sur les quatre partitions en question sda
et sdb, 3 et 4.
Pourquoi ? Au cas où quelque chose serait à moitié monté ? Je peux
faire ces 4 opérations tant que je n'ai rien monté à la main et quand
j'ai monté une des partitions, je ne peux plus effectuer l'opération ni
sur elle ni sur sa partition miroir.
> Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
- le shell de secours n'est peut-être pas le contexte idéal pour le
btrfsck
- tu n'as peut-être pas fait une réparation sur les quatre partitions
Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est
toujours la première que je regarde.
- il faut peut-être effectuer des manips au niveau du RAID, puisque tu
en utilises un (dmraid --rebuild ou quelque chose du même genre?)
Le raid est géré par btrfs. Si je ne dis pas de bêtises, au montage
d'une partition il cherche les miroirs (elles sont peut-être écrites
dans les méta-données de chaque partition, je ne sais pas) et il
assemble le tout. Enfin il y a aussi une histoire de recherche des
partitions concernées par btrfs pour les monter correctement, en
principe effectué tout seul au démarrage.
> Quelques points étranges :
> - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça
> échoue. À ce moment je peux réparer sda3 comme indiqué plus
> haut et la monter, ou monter directement sdb3, la partition miroir,
> sans avoir besoin de la réparer
> - Plus bizarre mais peut-être pas très utile : quand sda3 est
> "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé.
> - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition
> racine c'est cette partition qui est cassée et sda3 que je peux
> utiliser directement, sans réparation.
> - Les deux partitions ont le même uuid, c'est normal ? Si je
> fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça
> échoue comme si je la désignais directement.
>
> Des idées ?
comme je n'ai pas utilisé Syslinux ni le RAID, je peux difficilement
te répondre intelligemment et j'ai bien peur de ne pas avoir d'autres
idées
Le Tue, 24 Sep 2013 19:42:21 +0200 didier gaumet a écrit :
Le 24/09/2013 16:22, Yliur a écrit :
> J'avais essayé ce genre de choses (btrfs check --repair) et j'ai > réessayé : ça fonctionne mais au démarrage suivant c'est à nouveau > pareil. > > Donc pour démarrer le système entièrement j'ai fait ça dans > l'environnement de secours proposé à la suite de l'échec du montage > de la partition : > btrfs check --repair /dev/sda3 > mount /dev/sda3 new_root > exit
il faudrait peut-être faire un mount dans cet environnement pour voir ce qui est monté.
Là je travaille sur la machine donc je ne vais pas vérifier maintenant, mais pourquoi cette remarque ? A priori le problème se déclenche parce que la partition racine n'a pas été montée.
je préfèrerais utiliser un livecd ou liveusb pour effectuer les commandes btrfsck --repair sur les quatre partitions en question sda et sdb, 3 et 4.
Pourquoi ? Au cas où quelque chose serait à moitié monté ? Je peux faire ces 4 opérations tant que je n'ai rien monté à la main et quand j'ai monté une des partitions, je ne peux plus effectuer l'opération ni sur elle ni sur sa partition miroir.
> Et ça démarre bien. Mais au prochain montage c'est à nouveau cassé.
- le shell de secours n'est peut-être pas le contexte idéal pour le btrfsck - tu n'as peut-être pas fait une réparation sur les quatre partitions
Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est toujours la première que je regarde.
- il faut peut-être effectuer des manips au niveau du RAID, puisque tu en utilises un (dmraid --rebuild ou quelque chose du même genre?)
Le raid est géré par btrfs. Si je ne dis pas de bêtises, au montage d'une partition il cherche les miroirs (elles sont peut-être écrites dans les méta-données de chaque partition, je ne sais pas) et il assemble le tout. Enfin il y a aussi une histoire de recherche des partitions concernées par btrfs pour les monter correctement, en principe effectué tout seul au démarrage.
> Quelques points étranges : > - Syslinux (l'amorceur) est censé démarrer sur /dev/sda3 et ça > échoue. À ce moment je peux réparer sda3 comme indiqué plus > haut et la monter, ou monter directement sdb3, la partition miroir, > sans avoir besoin de la réparer > - Plus bizarre mais peut-être pas très utile : quand sda3 est > "cassée", sdb4 l'est aussi, et réciproquement : c'est croisé. > - Si je dis à syslinux d'utiliser /dev/sdb3 comme partition > racine c'est cette partition qui est cassée et sda3 que je peux > utiliser directement, sans réparation. > - Les deux partitions ont le même uuid, c'est normal ? Si je > fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça > échoue comme si je la désignais directement. > > Des idées ?
comme je n'ai pas utilisé Syslinux ni le RAID, je peux difficilement te répondre intelligemment et j'ai bien peur de ne pas avoir d'autres idées
Merci pour les suggestions en tout cas.
Doug713705
Le 24-09-2013, Yliur nous expliquait dans fr.comp.os.linux.configuration :
Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est toujours la première que je regarde.
Ben, ferme les yeux !
--> []
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Le 24-09-2013, Yliur nous expliquait dans fr.comp.os.linux.configuration :
Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est
toujours la première que je regarde.
Ben, ferme les yeux !
--> []
--
Doug - Linux user #307925 - Slackware64 roulaize ;-)
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
Le 24-09-2013, Yliur nous expliquait dans fr.comp.os.linux.configuration :
Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est toujours la première que je regarde.
Ben, ferme les yeux !
--> []
-- Doug - Linux user #307925 - Slackware64 roulaize ;-) Without freedom of choice there is no creativity. -- Kirk, "The return of the Archons", stardate 3157.4
Yliur
Le Wed, 25 Sep 2013 07:28:02 +1100 Doug713705 a écrit :
Le 24-09-2013, Yliur nous expliquait dans fr.comp.os.linux.configuration :
> Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est > toujours la première que je regarde.
Ben, ferme les yeux !
--> []
Cours vite, sinon je ferme la porte et je te frotte les oreilles !
Le Wed, 25 Sep 2013 07:28:02 +1100
Doug713705 <doug.letough@free.fr> a écrit :
Le 24-09-2013, Yliur nous expliquait dans
fr.comp.os.linux.configuration :
> Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est
> toujours la première que je regarde.
Ben, ferme les yeux !
--> []
Cours vite, sinon je ferme la porte et je te frotte les oreilles !
Le Wed, 25 Sep 2013 07:28:02 +1100 Doug713705 a écrit :
Le 24-09-2013, Yliur nous expliquait dans fr.comp.os.linux.configuration :
> Ça j'ai essayé, et c'est étrange parce que la partition "cassée" est > toujours la première que je regarde.
Ben, ferme les yeux !
--> []
Cours vite, sinon je ferme la porte et je te frotte les oreilles !
Yliur
Le Wed, 25 Sep 2013 12:48:56 +0200 Gérald Rochat a écrit :
Le 24/09/2013 16:22, Yliur a écrit :
> - Les deux partitions ont le même uuid, c'est normal ? Si je > fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça > échoue comme si je la désignais directement.
Non, c'est pas normal. Si fstab fait les montages en se basant sur les UUID ça ne peu pas marcher.
C'est le cas et ça marchait jusqu'ici. D'ailleurs mon problème survient avant la consultation de fstab, non ? Juste en se basant sur la configuration de syslinux.
À partir de quoi est calculé l'uuid ? Comment le retrouver ? Là je l'ai lu dans les traces de btrfs quand il effectue ses tests, mais comme il gère le miroir lui-même (l'assemblage des partitions nécessaires notamment) il a peut-être triché ?
Le Wed, 25 Sep 2013 12:48:56 +0200
Gérald Rochat <gerald@rochat.rf> a écrit :
Le 24/09/2013 16:22, Yliur a écrit :
> - Les deux partitions ont le même uuid, c'est normal ? Si je
> fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça
> échoue comme si je la désignais directement.
Non, c'est pas normal. Si fstab fait les montages en se basant sur
les UUID ça ne peu pas marcher.
C'est le cas et ça marchait jusqu'ici. D'ailleurs mon problème survient
avant la consultation de fstab, non ? Juste en se basant sur la
configuration de syslinux.
À partir de quoi est calculé l'uuid ? Comment le retrouver ? Là je l'ai
lu dans les traces de btrfs quand il effectue ses tests, mais comme il
gère le miroir lui-même (l'assemblage des partitions nécessaires
notamment) il a peut-être triché ?
Le Wed, 25 Sep 2013 12:48:56 +0200 Gérald Rochat a écrit :
Le 24/09/2013 16:22, Yliur a écrit :
> - Les deux partitions ont le même uuid, c'est normal ? Si je > fournis cet uuid à syslinux il tente d'utiliser sdb3 et ça > échoue comme si je la désignais directement.
Non, c'est pas normal. Si fstab fait les montages en se basant sur les UUID ça ne peu pas marcher.
C'est le cas et ça marchait jusqu'ici. D'ailleurs mon problème survient avant la consultation de fstab, non ? Juste en se basant sur la configuration de syslinux.
À partir de quoi est calculé l'uuid ? Comment le retrouver ? Là je l'ai lu dans les traces de btrfs quand il effectue ses tests, mais comme il gère le miroir lui-même (l'assemblage des partitions nécessaires notamment) il a peut-être triché ?
