SR Linux software overview

This chapter describes the basic software operations on the SR Linux.

File system layout

The file system is distributed and laid out as a closed-source third-party application on the OS. The following table lists the file system layout.

Table 1. File system layout

Path

Description
/opt/srlinux/appmgr/* YAML configuration for Nokia-provided applications
/opt/srlinux/appmgr/aaa_mgr System files for AAA manager
/opt/srlinux/appmgr/logmgr System files for log manager
/opt/srlinux/bin/* Application binaries
/opt/srlinux/firmware/* Contains firmware (BIOS, IOCTL, CPLD, and so on)
/opt/srlinux/imm/imminit.tar IMM image
/opt/srlinux/lib/* Nokia-provided shared libraries
/opt/srlinux/models/* Nokia-provided YANG models
opt/srlinux/config.json Factory system configuration
/opt/srlinux/osync/* Configuration files and exclude/include files for overlay synchronization
/opt/srlinux/python/* The virtual environment used to run SR Linux Python processes
/opt/srlinux/systemd/* Systemd unit files and configuration
/opt/srlinux/usr/* Community-provided binaries, shared libraries, and licenses
/opt/srlinux/var/run/* Running directory for process sockets
/opt/srlinux/ztp/* ZTP virtual environment, templates, and client
/etc/opt/srlinux/config.json System configuration
/etc/opt/srlinux/config.json.gz Compressed system configuration (if the configuration needs to compressed)
/etc/opt/srlinux/banner The system banner, pre-login
/etc/opt/srlinux/license.key License file
/etc/opt/srlinux/srlinux.rc Global environment file
/etc/opt/srlinux/tls/* User-configured certificates
/etc/opt/srlinux/appmgr/* YAML configuration for operator-provided agents
/etc/opt/srlinux/appmgr/overrides YAML overrides for operator and Nokia-provided applications
/etc/opt/srlinux/models/* YANG modules for operator-provided agents
/etc/opt/srlinux/checkpoint/* Configuration checkpoints
/etc/opt/srlinux/devices/* Discovered devices
/etc/opt/srlinux/cli/plugins/* Operator-provided plug-ins
/var/opt/srlinux/run/* Application PIDs
/var/log/srlinux/buffer/* Tmpfs logging
/var/log/srlinux/buffer.persist/* Persistent buffered logging
/var/log/srlinux/file/* Persistent logging
/var/log/srlinux/debug/* Debug logging, tmpfs
/var/log/srlinux/debug.persist/* Persistent debug logging
/var/log/srlinux/monitor/* Log_mgr tmpfs storage
/var/log/srlinux/monitor.persist/* Log_mgr persistent storage
/var/log/srlinux/archive/* Archive directory for previous startups
$HOME/.srlinuxrc Per-user environment
$HOME/srlinux/cli/plugins/* Per-user CLI plug-ins

The Solid State Drive (SSD) is used for an overlay file system, allowing the user to add persistent modifications to the system.

Boot process

The SR Linux boots using a normal Linux boot mechanism. The BIOS is set up to boot from the internal storage device. The following is the normal boot sequence:
  1. The system powers on. Assuming a fully populated system, all components initialize to the point where they bring up their link on the back door bus. Fans are under hardware control and run at 100% speed.
  2. Both control modules start their boot sequence. During this sequence, the following occurs:
    1. The BIOS tries to boot off the internal storage device.
    2. Grub2 loads the kernel and initramfs into memory. The initramfs contains a squashfs of the root file system used to run SR Linux, including base CentOS and SR Linux applications. The squashfs is unpacked and loaded.
    3. When the initramfs has loaded, the application manager (app_mgr) starts and loads the applications based on their start order.
    4. The system is operational.
  3. On control-redundant platforms, both control modules attempt to boot at the same time. The control module in slot B waits up to 300 seconds before becoming active, after detecting slot 1 on the back door bus.
  4. The chassis_mgr and device_mgr initialize, push images, and boot each line card and Switch Fabric Module (SFM). This includes making any decisions based on power availability, and taking control of fans.