l2-filesystem-create-xfs : vert joué seul, rouge en séquence (4 errors)
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 45/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- linux, python
- Domain
- operating-systems, testing
Research direction
Start by rerunning the complete campaign and inspect solution/verified-with.json, including the preserved pytest and playbook output from #46 and #42. Read the root conftest.py fixture _apply_lab_state, l2-filesystem-create-xfs/setup.yaml and cleanup.yaml, and compare the preceding l2-partition-gpt and l2-lvm-extend-persist labs. Done means the cause is confirmed from real output, the full sequence is green, any responsible lab has a regression test, and verified-with.json reports 84 greens.
Written by the indexing model from the issue text.
Description
Symptôme
Campagne de validation du 27/07 à 14:20, solution/verified-with.json :
"l2-filesystem-create-xfs": {
"etat": "ROUGE",
"runtime": "vm",
"resume": "4 errors in 1.36s"
}
La campagne précédente, à 11:46 le même jour, donnait ce lab vert (4 passed in 3.52s). Rien n'a changé dans le lab entre les deux : c'est donc un défaut de séquence, pas du lab isolé.
Ce que le symptôme dit déjà
« errors » et non « failed ». Les quatre tests sont en erreur, pas en échec : c'est la fixture _apply_lab_state du conftest.py racine qui lève, donc le replay de solution.yaml qui échoue. Les tests eux-mêmes n'ont jamais tourné.
1,36 s. Un replay réussi de ce lab prend plusieurs secondes. L'échec est donc très précoce, sur les premières tâches de la solution.
Ce qui est écarté
Le marqueur .xfs-lab-ready. C'est l'incident historique de ce lab (le cleanup effaçait le système de fichiers mais pas le marqueur, donc le setup suivant sautait la préparation). Vérifié : le cleanup.yaml actuel fait bien rm -f /root/xfs-disk.env /root/.xfs-lab-ready. Ce n'est pas une rechute.
Piste principale : neuf labs se partagent le même disque
Le meta.yml ne déclare qu'un seul disque additionnel sur alma-rhcsa-1 (extra_disk_gb: 10), et neuf labs écrivent dessus :
l2-autofs-ondemand l2-fstab-persist-uuid l2-storage-performance
l2-disk-space-troubleshoot l2-lvm-extend-persist l3-fs-readonly-recover
l2-filesystem-create-xfs l2-partition-gpt lfcs-storage-quotas
Auxquels s'ajoute le capstone RHCSA, qui y monte un vgapp en LVM.
Le setup.yaml de ce lab commence par :
set -e
...
wipefs -a "$DISK"
sgdisk --zap-all "$DISK" 2>/dev/null || true
parted -s "$DISK" mklabel gpt
wipefs -a échoue si le disque est occupé : groupe LVM encore actif, volume RAID assemblé, conteneur LUKS ouvert, ou partition encore montée. Avec set -e, la tâche s'arrête là. Le lab qui précède immédiatement dans le meta.yml est l2-partition-gpt, et l2-lvm-extend-persist passe peu avant.
Cette piste explique un échec précoce et une dépendance à la séquence, mais elle n'est pas démontrée : il faut la sortie réelle pour trancher.
Comment trancher, maintenant que c'est possible
L'échec était muet : l'entrée JSON ne porte que etat, resume et runtime, sans la sortie du playbook. Deux correctifs mergés depuis rendent la prochaine campagne parlante :
- #46 :
scripts/verify-solutions.pyconserve la sortie complète d'un pytest en échec et l'écrit dans le JSON ; - #42 : le message de la fixture porte désormais la sortie du playbook, donc la tâche fautive et sa raison.
Prochaine étape : rejouer la campagne complète et lire la sortie de ce lab. Le message nommera la tâche qui échoue, ce qui confirmera ou écartera la piste du disque occupé en une seule passe.
Critères d'acceptation
- La cause est identifiée à partir d'une sortie réelle, pas d'une hypothèse.
- Le lab passe au vert en séquence complète, pas seulement joué seul.
- Si la cause est un état de disque laissé par un lab précédent, c'est ce lab-là qui est corrigé, et un test l'empêche de récidiver, à la manière de
tests/test_marqueurs_setup_cleanup.py. -
solution/verified-with.jsonest régénéré et atteste 84 verts.
- Dominant language
- Python
- Stars
- 45
- Forks
- 8
- Avg merge
- 19h 52m
- Merged PRs (30d)
- 16
Getting set up
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stephrobert/linux-dsoxlab-training
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
stephrobert/linux-dsoxlab-training#83 ·
Maintainers usually reply within 1 day
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
stephrobert/linux-dsoxlab-training#93 ·
Maintainers usually reply within 1 day
-
Test podmanOpen
Difficulty 4/5 1-2 days Newbie friendliness 25/100
stephrobert/linux-dsoxlab-training#81 ·
Maintainers usually reply within 1 day
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 45/100
stephrobert/linux-dsoxlab-training#48 ·
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
stephrobert/linux-dsoxlab-training#40 ·
Maintainers usually reply within 1 day
All issues in stephrobert/linux-dsoxlab-training
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
btclib-org/btclib-wallet#587 · 1 comment ·
Maintainers usually reply within 1 day
-
documentation
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
Judgment-Pack/judgment-pack-spec#275 ·
Maintainers usually reply within 1 day
-
ai-generated
Difficulty 2/5 1-3 hours Newbie friendliness 77/100
Maintainers usually reply within 1 day
-
documentation good first issue priority: low size: XS
Difficulty 1/5 1-3 hours Newbie friendliness 92/100
yeongseon/azure-functions-doctor-python#651 ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
Changaco/python-libarchive-c#146 ·