Dans ce petit tutoriel, je vais montrer comment restaurer manuellement le snapshot primary (la copie principale du système JunOS) sur un switch Juniper EX2200, dans le cas où l’appareil boote automatiquement sur le backup slice à cause d’une erreur ou corruption sur la partition /dev/da0s2a.
L’EX2200, c’est pas tout jeune, mais c’est encore ben vivant comme modèle. On le voit souvent dans des petits bureaux, sur des segments secondaires dans des réseaux plus gros, ou même dans des homelabs. Il a tout ce qu’il faut pour faire rouler un réseau L2 de base : 48 ports gigabit, des slots SFP pour l’uplink, et surtout — un vrai OS JunOS basé sur FreeBSD. C’est parfait pour faire du tuning, de l’automatisation ou du troubleshooting — que tu sois admin réseau ou juste passionné.
Mais comme tout vieux hardware, il a ses particularités. Une des plus importantes, c’est la structure de boot en double slice : le switch a deux partitions root, da0s1a et da0s2a, et il switche entre les deux au boot. Si la primary (en général da0s2a) est brisée, il va booter automatiquement sur la backup (da0s1a) — sans avertissement. À première vue, tout marche, mais tu risques des problèmes : tu peux plus faire de updates ou sauvegarder ta config en toute sécurité.
Dans ce guide, je vais couvrir les vrais symptômes qu’on a déjà vus sur le terrain :
- cannot mount /dev/da0s2a quand on check le snapshot
- boot automatique sur le backup slice
- aucune alarme avec show system alarms, même après la restauration
- échec du montage manuel et erreurs avec
fsck
C’est parti, on répare ça ✌️
1. Vérifier l’état actuel
J’ai fait cette procédure sur un Juniper EX2200-48T-4G, version JUNOS 15.1R6.7. Selon la version que t’as, certaines commandes peuvent être un peu différentes.
Première chose à faire : vérifier sur quel slice le switch a booté (primary ou backup), et si la partition /dev/da0s2a (la primary) est accessible ou pas
show system snapshot media internal
Cette commande te montre de quel slice la machine est partie, et si les deux partitions sont montées.
- La primary c’est généralement : /dev/da0s2a
- Le backup : /dev/da0s1a
Si l’appareil a booté sur la copie de secours, tu verras soit une ligne indiquant que le backup est active, soit un message du genre :
error: cannot mount /dev/da0s2a
Sur le screenshot, on voit un exemple où le primary slice est brisé (da0s2a peut pas être monté), donc le switch roule à partir du backup slice.
Tu peux aussi checker avec :
show system alarms
Si tu vois un message comme :
Minor Host 0 Boot from backup root
…ça veut dire que la primary est probablement corrompue ou inaccessible.
⚠️ Par contre, attention : sur des versions plus vieilles de JunOS (comme 15.1R6.7), cette alarme peut même pas apparaître du tout. Donc même si la primary est brisée, show system alarms peut ne rien dire. Faut pas se fier uniquement à ça.
Re-check aussi avec :
show system snapshot media internal
Sur le screenshot, on voit clairement que :
- Le backup slice /dev/da0s1a est actif et utilisé
- Le primary slice /dev/da0s2a est pas monté (error: cannot mount /dev/da0s2a)
- Version de JunOS : 15.1R6.7
Bref, le switch roule sur la copie de secours (backup) et le primary est probablement HS
On vérifie aussi si les deux copies du root sont disponibles : /dev/da0s1a (backup) et /dev/da0s2a (primary).
Pour ça, on utilise la commande suivante :
show system storage
Dans ce cas précis, on peut observer :
- /dev/da0s1a est monté en tant que /, ce qui signifie que le système fonctionne actuellement à partir du backup slice.
- /dev/da0s2a (le slice primary) n’apparaît même pas dans la liste des systèmes de fichiers montés, ce qui indique que ce slice n’est pas monté ou qu’il est endommagé.
Étape 2 – Restauration du primary slice
Bon, on a confirmé que l’appareil a booté à partir du slice de secours — le backup slice, en général /dev/da0s1a. Mais le slice principal (/dev/da0s2a, aussi appelé primary) est HS : soit il est corrompu, soit carrément non montable.
Avant de tenter une “guérison”, faut savoir ce qu’il faut pas faire :
❌ N’essaie pas de monter /dev/da0s2a manuellement — tu vas juste te taper un Operation not permitted, même en tant que root.
❌ N’essaie pas de lancer fsck directement sans passer par su — tu vas te ramasser un Permission denied et basta.
Pour réparer, on utilise la commande officielle JunOS, prévue exactement pour ce genre de scénario :
request system snapshot slice alternate
C’est un peu comme un bouton magique restore :
- ça copie tout ce qui se trouve sur le slice actif actuel (donc le backup),
- ça écrase complètement le primary (reformat + re-image),
- et ça crée une version miroir du backup dans le slice principal.
Pendant l’exécution, le système peut afficher un warning du genre “this may impact system stability”. Pas de stress — tu tapes yes et tu laisses rouler.
Comment vérifier que la restauration a bien marché ?
Une fois la commande finie, relance :
show system snapshot media internal
Regarde la ligne du primary. Si tu vois une nouvelle date — comme ici :
primary /dev/da0s2a Aug 30 23:48:46 2025
… alors bingo. La restauration est réussie et ton slice principal est de nouveau opérationnel.
Étape 3 – Reboot pour validation
Une fois le primary slice restauré, c’est le moment de vérifier si le switch peut booter tout seul à partir de la partition principale — /dev/da0s2a.
Pour ça, on lance une commande toute simple mais ultra-importante :
request system reboot
Ouais, c’est juste un reboot, mais dans notre cas, c’est le test final : on checke si tout a bien été fait et si le primary slice fonctionne à nouveau.
À surveiller pendant le boot
Regarde bien la console. Tu devrais voir passer une ligne du genre :
Trying to mount root from ufs:/dev/da0s2a
C’est la preuve que le système tente de monter le root à partir du slice principal. Parfait, c’est ce qu’on veut.
Tu ne dois pas voir l’avertissement suivant :
Booted from backup root
Si ce message apparaît, c’est que ça a foiré, et l’appareil a encore booté sur le slice de secours. Dans ce cas, retour à l’étape 2 pour revoir la restau.
Si tout se passe bien, que le reboot se fait depuis /dev/da0s2a, c’est gagné. Le primary est back online, et ton backup peut rester là tranquille — prêt à te sauver la peau une autre fois si jamais.
Étape 4 – Vérification fsck (optionnelle)
Si tu veux faire une vérification complète du système de fichiers sur le primary slice, tu peux utiliser fsck.
Lance ces commandes :
start shell su fsck -y /dev/da0s2a
La commande va scanner la partition principale et corriger automatiquement les erreurs s’il y en a.
⚠️ Attention :
- Ne lance jamais fsck sans su — tu vas juste avoir un beau Permission denied.
- Et ne tente pas de monter le slice manuellement : c’est en read-only, donc tu vas te heurter à un Operation not permitted.
Si tout est clean, tu devrais voir quelque chose comme :
... clean ... 0.0% fragmentation
Pas d’erreurs ? Parfait. On est prêts pour la suite.
Étape 5 – Vérification finale après reboot
Pour valider que tout tourne maintenant sur le primary slice, on fait un dernier reboot :
request system reboot
Puis, une fois redémarré, on tape :
show system snapshot media internal
Si tu vois que da0s2a (primary) a une date récente, que da0s1a (backup) a encore l’ancienne, et qu’il n’y a plus d’erreur du style cannot mount — alors c’est bon signe : le switch a booté correctement sur la partition principale.
On peut aussi refaire un check avec :
show system alarms
Le message du genre “Boot from backup root” devrait avoir disparu.
S’il n’est plus là — ça confirme que le switch tourne maintenant sur la bonne partition (root primaire) et que tout est revenu à la normale.
Félicitations, la partition où l’erreur s’est produite a été restaurée avec succès et fonctionne maintenant normalement.
Pour éviter de perdre des configurations importantes, pense à créer un snapshot juste après chaque mise à jour ou modification de configuration : request system snapshot — cela met à jour les deux copies (primary et backup).
Bonne chance!