z6c - personal blog about topics

Christian Müller – Letzte Änderung: 14.08.2013 09:16 Uhr

Junos: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE

Aus gegebenem Anlaß hier die Zusammenfassung aus kb.juniper.net zur Situation, daß ein Junos Device (im Artikel ein Switch, in unserem Fall ein SRX210 Router) von der Backup Partition bootet weil mit der primären irgendwas nicht in Ordnung ist.

Situation

Die rote Alarmleuchte ist aktiv. Ich logge mich per SSH oder Console ein und sehe folgendes:

***********************************************************************
**                                                                   **
**  WARNING: THIS DEVICE HAS BOOTED FROM THE BACKUP JUNOS IMAGE      **
**                                                                   **
**  It is possible that the primary copy of JUNOS failed to boot up  **
**  properly, and so this device has booted from the backup copy.    **
**                                                                   **
**  Please re-install JUNOS to recover the primary copy in case      **
**  it has been corrupted.                                           **
**                                                                   **
***********************************************************************

Um sich den Fehler nebst Timestamp anzeigen zu lassen, startet man mit cli das Junos Interface und sieht dann mit folgendem Befehl die Details zum Fehler:

root@vpn1> show chassis alarms 
1 alarms currently active
Alarm time               Class  Description
2013-08-07 10:08:57 CEST Minor  Host 0 Boot from backup root

root@vpn1>

Ursache

Das Problem kann durch Stromausfall, Abstürze oder defekte Platten verursacht werden. Am häufigsten wird hier wohl der Stromausfall sein.

Erkennt Junos, daß es Probleme, wie ein ungechecktes Filesystem auf der aktiven Partition, gibt, bootet es automatisch von der Backup Partition.

Dies ist eigentlich eine der großen Stärken der Juniper Geräte, daß es quasi für jeden Fall eine Ausweichmöglichkeit gibt. Macht Spaß, nen "defekten" Router zu starten und er weiß dennoch, was er zu tun hat. Hut ab vor der Weitsicht und der Art der Implementierung!

Behebung

Mit

request system snapshot media internal slice alternate

wird die backup Partition wieder auf passive gestellt, indem die Hauptpartition aktiviert wird. Hierfür ist kein Rebot nötig, alles läuft weiter, lediglich beim nächsten Reboot wird versucht wieder von der Hauptplatte zu starten. Schlägt dies erneut fehl, wiederholt sich die Prozedur und es wird wieder auf Backup geswitched.

Aber:

Dies macht nur Sinn, wenn es ein kleiner Fehler war, der z.B. durch Filesystemcheck automatisch korrigiert wird. Ausserdem: Die Alarmleuchte bleibt rot und das Banner bleibt bestehen!

Weiteres Vorgehen

Will mans also richtig machen, führt man ein paar zusätzliche Schritte sowie einen sauberen Reboot durch, dadurch hat man dann verifiziert, daß alles wieder in Ordnung ist.

Information

show system storage partitions

liefert

Boot Media: internal (da0)
Active Partition: da0s2a
Backup Partition: da0s1a
Currently booted from: backup (da0s1a)

Partitions information:
  Partition  Size   Mountpoint
  s1a        292M   /         
  s2a        293M   altroot   
  s3e        24M    /config   
  s3f        342M   /var      
  s4a        27M    recovery  
  s4e        2.7M

oder

show system snapshot media internal

Information for snapshot on       internal (/dev/da0s1a) (backup)
Creation date: May 15 14:08:17 2012
JUNOS version on snapshot:
  junos  : 11.2R4.3-domestic
Information for snapshot on       internal (/dev/da0s2a) (primary)
Creation date: Jun 20 22:33:17 2012
JUNOS version on snapshot:
  junos  : 11.2R6.3-domestic

Recover des Systems vom Backup zur primären Partition

request system snapshot media internal slice alternate

Dies kann je nach System schon einige Zeit dauern. Immerhin wird ne komplette Platte formatiert und gecloned oder sonstwas auf nem relativ schwachen System/Prozessor,…

Bei mir stand erst zehn Minuten lang:

Formatting alternate root (/dev/da0s2a)...

Anschliessend dauerte folgendes nur sehr wenige Sekunden:

Copying '/dev/da0s1a' to '/dev/da0s2a' .. (this may take a few minutes)
The following filesystems were archived: /

Nun wird zum Abschluß die kiste nochmal durchgestartet und anschließend das Ergebnis verifiziert.

Reboot

request system reboot # Im verlinkten Howto folgt noch: slice alternate media internal

Verifikation

Anhand der Alarm Leuchte sollte man es direkt erkennen, dennoch logge ich mich erneut ein und lasse mir den Alarmstatus in der Console anzeigen:

show system alarms

Und wenn die Antwort wie folgt ausfällt, ist wohl alles in Ordnung:

No alarms currently active

Kommentare für diesen Artikel noch nicht freigeschaltet.

Bitte eine Email an kommentare@zentonic.org mit Betreff "Kommentare für Post 55"