Updates - Upgrading the VyOS System
Updates - Upgrading the VyOS System
This page describes the VyOS update mechanism, including automatic update checks, system image management, and the procedures for upgrading and rolling back to previous versions.
Overview
VyOS uses an image-based update mechanism, which provides:
- Safety: The ability to roll back to the previous version if problems occur
- Predictability: A complete replacement of system files, with no partial updates
- Isolation: Each version is stored as a separate image
- Fast rollback: Switching between versions via a reboot
- Testing: The ability to validate a new version before making the final switch
System image architecture
VyOS stores several system images on a single device:
/boot/
├── 1.5-rolling-202401150023/ # Current version (default)
├── 1.5-rolling-202312250024/ # Previous version
└── 1.4.0-sagitta/ # Older LTS versionKey features:
- All images share a common
/config/partition - The configuration is preserved when switching between images
- At boot time you can select any installed image
- Deleting an image does not affect the configuration
Types of VyOS updates
Rolling Release (1.5+):
- Continuous updates with new features
- Daily nightly builds
- Recommended for testing and lab environments
- Requires regular monitoring for updates
LTS (Long Term Support):
- Stable releases (for example, 1.4 Sagitta)
- Security fixes and critical bug fixes only
- Recommended for production
- A predictable update cycle
Checking the current version
Version-check commands
# Show the current system version
show version
# Show all installed images
show system image
# Show detailed system information
show version allExample output of show version
vyos@router:~$ show version
Version: VyOS 1.5-rolling-202401150023
Release train: current
Release flavor: generic
Built by: autobuild@vyos.net
Built on: Mon 15 Jan 2024 00:23 UTC
Build UUID: a7b3c9d2-e4f5-6789-0abc-def123456789
Build commit ID: abcdef123456
Architecture: x86_64
Boot via: installed image
System type: KVM guest
Hardware vendor: QEMU
Hardware model: Standard PC (Q35 + ICH9, 2009)
Hardware S/N: unknown
Hardware UUID: 12345678-1234-1234-1234-123456789abc
Copyright: VyOS maintainers and contributorsExample output of show system image
vyos@router:~$ show system image
The system currently has the following image(s) installed:
1: 1.5-rolling-202401150023 (default boot) (running image)
2: 1.5-rolling-202312250024
3: 1.4.0-sagitta
Total images: 3Configuring automatic update checks
Enabling automatic checks
VyOS can automatically check for new versions and notify the administrator.
# Enable automatic update checks
configure
set system update-check auto-check
commit
save
exitConfiguring the update-check URL
configure
# URL for the rolling release (1.5+)
set system update-check url 'https://raw.githubusercontent.com/vyos/vyos-rolling-nightly-builds/main/version.json'
# Enable automatic checks
set system update-check auto-check
commit
save
exitChecking for available updates
# Manually check for available updates
show system updatesExample output of show system updates
vyos@router:~$ show system updates
Current version: 1.5-rolling-202312220023
Update available: 1.5-rolling-202401150023
Update URL: https://github.com/vyos/vyos-rolling-nightly-builds/releases/download/1.5-rolling-202401150023/1.5-rolling-202401150023-amd64.iso
To update, use: add system image <URL>Disabling automatic checks
configure
delete system update-check auto-check
commit
save
exitAdding a new system image
Installing an image from a URL
# Add the latest available version
add system image latest
# Add an image from a specific URL
add system image https://github.com/vyos/vyos-rolling-nightly-builds/releases/download/1.5-rolling-202401150023/1.5-rolling-202401150023-amd64.iso
# Add an image from a local file
add system image /tmp/vyos-1.5-rolling-202401150023-amd64.isoThe image installation process
vyos@router:~$ add system image latest
Trying to fetch latest version from https://github.com/vyos/vyos-rolling-nightly-builds/releases/download/1.5-rolling-202401150023/1.5-rolling-202401150023-amd64.iso
Checking for available updates...
Found new version: 1.5-rolling-202401150023
Do you want to continue? [y/N] y
Downloading image...
######################################################################## 100.0%
Checking image... OK
What would you like to name this image? [1.5-rolling-202401150023]:
# Press Enter for the default name or enter your own
Installing new image...
Copying files... Done
Do you want to set the new image as the default boot image? [y/N] y
# Choose 'y' to have the new image boot by default
Image installation complete.
Do you want to reboot now? [y/N] n
# You can postpone the reboot to finish ongoing tasksInstalling an image with a custom name
vyos@router:~$ add system image https://example.com/vyos-custom.iso
What would you like to name this image? [vyos-custom]: production-20240115
# Convenient for identifying images
Installing new image...
Copying files... Done
Image 'production-20240115' installed successfully.Managing system images
Setting the default image
# Set the image to boot by default
set system image default-boot 1.5-rolling-202401150023
# Or interactively
vyos@router:~$ set system image default-boot
Please specify image name:
1: 1.5-rolling-202401150023
2: 1.5-rolling-202312250024
3: 1.4.0-sagitta
Select image [1-3]: 1
Default boot image set to: 1.5-rolling-202401150023Renaming an image
# Rename an image for easier identification
rename system image 1.5-rolling-202401150023 to production-current
rename system image 1.5-rolling-202312250024 to production-previousDeleting an image
# Delete an unused image to free up space
delete system image 1.4.0-sagitta
# Or interactively
vyos@router:~$ delete system image
The following images are available for deletion:
1: 1.5-rolling-202312250024
2: 1.4.0-sagitta
Select image to delete [1-2]: 2
Warning: This will permanently delete image '1.4.0-sagitta'
Continue? [y/N] y
Deleting image... DoneImportant:
- You cannot delete the currently booted image (running image)
- You cannot delete the default image (default boot) without setting a new one first
- Deleting an image does not affect the configuration in
/config/
Checking disk space usage
# Check the space used by images
show system storage
# Detailed information
df -hvyos@router:~$ show system storage
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 9.5G 4.2G 4.8G 47% /
tmpfs 489M 0 489M 0% /dev/shm
/dev/sda1 497M 125M 372M 26% /boot
Images storage usage:
1.5-rolling-202401150023: 1.2G
1.5-rolling-202312250024: 1.2G
1.4.0-sagitta: 950M
Total: 3.35GThe VyOS update procedure
Preparing for the update
Step 1: Create a configuration backup
# Save the current configuration
save /config/backup-before-update-$(date +%Y%m%d).config
# Copy to an external server (optional)
scp /config/backup-before-update-$(date +%Y%m%d).config user@backup-server:/backups/Step 2: Check the current state
# Check the current version
show version
# Check the installed images
show system image
# Check available space
show system storage
# Check active sessions
show system connections
# Check running processes
show system processesStep 3: Notify users
# Send a warning message to all connected users
wall "WARNING: A system update is scheduled in 10 minutes. Please save your work."
# Or via the system login banner
configure
set system login banner pre-login "The system will be rebooted for an update at 18:00 MSK"
commit
save
exitPerforming the update
Step 1: Download and install the new image
# Check for available updates
show system updates
# Install the new image
add system image latest
# When prompted:
# 1. Confirm the download: y
# 2. Specify the image name (or press Enter for the default)
# 3. Set as default boot: y
# 4. Reboot now: n (postpone until the maintenance window)Step 2: Verify the installation
# Make sure the image is installed
show system image
# Verify that the new image is set as default
# The output should show (default boot) next to the new imageStep 3: Scheduled reboot
# Schedule a reboot (in 5 minutes)
shutdown reboot +5 "Rebooting to apply the VyOS update"
# Or an immediate reboot
reboot now
# Or at a specific time
shutdown reboot 18:00 "Scheduled VyOS update"Step 4: Verify after the reboot
# Verify that the new version has booted
show version
# Verify that the configuration has been applied
show configuration
# Check network reachability
ping 8.8.8.8
# Check that services are working
show interfaces
show protocols
show firewallQuick update procedure (single command)
# For experienced administrators - an automated update
add system image latest && reboot nowCaution: Use only in test environments or when you fully understand the risks.
Rolling back to a previous version (Rollback)
Reasons for a rollback
- Hardware compatibility problems were discovered
- Critical bugs in the new version
- Performance problems
- Incompatibility with the existing configuration
- The need for additional testing
Rollback methods
Method 1: Selecting an image via GRUB (at boot)
When to use: When the system cannot boot or there are critical problems
Procedure:
- Reboot the system:
reboot - When the GRUB menu appears (press ESC if it boots automatically)
- Select the entry with the previous VyOS version
- Press Enter
Note: If the GRUB menu does not appear, press ESC during boot.
Method 2: Changing the default boot image
When to use: When the system is running stably but you need to return to the previous version
Procedure:
# View the available images
show system image
# Output:
# 1: 1.5-rolling-202401150023 (default boot) (running image)
# 2: 1.5-rolling-202312250024
# 3: 1.4.0-sagitta
# Set the previous image as the default
set system image default-boot 1.5-rolling-202312250024
# Reboot the system
reboot nowMethod 3: Interactive rollback
# Launch the interactive rollback wizard
vyos@router:~$ set system image default-boot
Please specify image name:
1: 1.5-rolling-202401150023 (current default)
2: 1.5-rolling-202312250024
3: 1.4.0-sagitta
Select image [1-3]: 2
Default boot image set to: 1.5-rolling-202312250024
Reboot now to apply changes? [y/N] yVerification after a rollback
# Check the version after the reboot
show version
# Make sure the configuration was applied correctly
show configuration
# Check that critical services are working
show interfaces
show protocols
show firewall
show nat
# Check the logs for errors
show log tail 100Automatic rollback via a watchdog
For critical systems, you can configure an automatic rollback on loss of connectivity:
#!/bin/bash
# Automatic rollback script for when problems occur
# Placed on an external monitoring server
VYOS_HOST="192.168.1.1"
PING_TIMEOUT=30
MAX_FAILURES=3
failures=0
while true; do
if ! ping -c 1 -W $PING_TIMEOUT $VYOS_HOST > /dev/null 2>&1; then
((failures++))
echo "Ping failed ($failures/$MAX_FAILURES)"
if [ $failures -ge $MAX_FAILURES ]; then
echo "Critical: VyOS not responding. Manual intervention required!"
# Send an alert to the administrator
# mail -s "VyOS DOWN" admin@example.com < /dev/null
fi
else
failures=0
fi
sleep 60
doneExamples for cloud platforms
Example 1: Yandex Cloud - Automated update checks
In Yandex Cloud, VyOS can automatically check for updates and notify via cloud monitoring.
Configuration for Yandex Cloud
configure
# Enable automatic update checks
set system update-check auto-check
set system update-check url 'https://raw.githubusercontent.com/vyos/vyos-rolling-nightly-builds/main/version.json'
# Configure syslog to send to Yandex Cloud Logging
set system syslog host 10.128.0.100 facility all level info
set system syslog host 10.128.0.100 facility all protocol tcp
# Configure SNMP for monitoring (if used)
set service snmp community yc-monitoring authorization ro
set service snmp listen-address 10.128.0.10
commit
save
exitUpdate-check script for Yandex Cloud
#!/bin/vbash
# /config/scripts/yc-check-updates.sh
# Automatic update check with logging to Yandex Cloud
source /opt/vyatta/etc/functions/script-template
LOG_FILE="/var/log/vyos-update-check.log"
METADATA_URL="http://169.254.169.254/latest/meta-data"
# Get instance information
INSTANCE_ID=$(curl -s $METADATA_URL/instance-id)
ZONE=$(curl -s $METADATA_URL/placement/availability-zone)
echo "[$(date)] Checking updates for instance $INSTANCE_ID in zone $ZONE" >> $LOG_FILE
# Check for updates
UPDATE_INFO=$(cli-shell-api showCfg system update-check)
if [ -n "$UPDATE_INFO" ]; then
echo "[$(date)] Update check enabled" >> $LOG_FILE
# Run the check (the show command is unavailable in scripts, so use the API)
# In production, use the VyOS API or a wrapper
logger -t vyos-updates "Update check completed for $INSTANCE_ID"
else
echo "[$(date)] Update check not configured" >> $LOG_FILE
fi
# Check disk space usage
DISK_USAGE=$(df -h / | tail -1 | awk '{print $5}' | sed 's/%//')
if [ $DISK_USAGE -gt 80 ]; then
logger -t vyos-updates "WARNING: Disk usage is ${DISK_USAGE}% - consider removing old images"
echo "[$(date)] WARNING: Disk usage ${DISK_USAGE}%" >> $LOG_FILE
fi
echo "[$(date)] Update check completed" >> $LOG_FILEConfiguring the task scheduler
configure
# Run the update check every day at 2:00 UTC
set system task-scheduler task check-updates executable path '/config/scripts/yc-check-updates.sh'
set system task-scheduler task check-updates interval 1d
set system task-scheduler task check-updates start-time '02:00'
commit
save
exitCreating a snapshot before an update in Yandex Cloud
#!/bin/bash
# yc-create-snapshot-before-update.sh
# Script to create a disk snapshot before a VyOS update
INSTANCE_NAME="vyos-router-01"
DISK_NAME="vyos-boot-disk"
SNAPSHOT_NAME="vyos-backup-$(date +%Y%m%d-%H%M%S)"
# Requires the yc CLI to be installed and configured
yc compute snapshot create \
--name "$SNAPSHOT_NAME" \
--disk-name "$DISK_NAME" \
--description "Automatic snapshot before VyOS update" \
--labels "instance=$INSTANCE_NAME,type=pre-update"
echo "Snapshot $SNAPSHOT_NAME created successfully"
# Once the snapshot is created successfully, you can update VyOS
ssh vyos@$INSTANCE_NAME "add system image latest"Example 2: VK Cloud - Staged deployment with rollback
VK Cloud lets you create multiple instances for a blue-green deployment.
Scenario: Blue-Green update
Architecture:
- Blue environment: The current production version (VyOS 1.4)
- Green environment: The new version being tested (VyOS 1.5)
- A load balancer switches traffic between the environments
Preparing the Green environment:
# On a new VK Cloud instance
configure
# Basic configuration
set system host-name vyos-router-green
set system domain-name vkcloud.internal
# Check the current version
show version
# If an update is required - install the latest
exit
# Install the image
add system image latest
# Copy the configuration from Blue
scp vyos@blue-instance:/config/config.boot /tmp/blue-config.boot
# Load the configuration
configure
load /tmp/blue-config.boot
# Change the hostname for Green
set system host-name vyos-router-green
commit
save
exitTesting the Green environment:
#!/bin/bash
# vkcloud-test-green-env.sh
# Testing the new environment before switching traffic
GREEN_IP="10.0.1.101"
TESTS_PASSED=0
TESTS_FAILED=0
echo "Testing Green environment at $GREEN_IP"
# Test 1: Ping connectivity
if ping -c 5 $GREEN_IP > /dev/null 2>&1; then
echo "PASS: Ping connectivity"
((TESTS_PASSED++))
else
echo "FAIL: Ping connectivity"
((TESTS_FAILED++))
fi
# Test 2: SSH availability
if ssh -o ConnectTimeout=5 vyos@$GREEN_IP "show version" > /dev/null 2>&1; then
echo "PASS: SSH access"
((TESTS_PASSED++))
else
echo "FAIL: SSH access"
((TESTS_FAILED++))
fi
# Test 3: Routing table
if ssh vyos@$GREEN_IP "show ip route" | grep -q "default"; then
echo "PASS: Default route present"
((TESTS_PASSED++))
else
echo "FAIL: Default route missing"
((TESTS_FAILED++))
fi
# Test 4: NAT rules
if ssh vyos@$GREEN_IP "show nat source rules" | grep -q "rule"; then
echo "PASS: NAT rules configured"
((TESTS_PASSED++))
else
echo "FAIL: NAT rules missing"
((TESTS_FAILED++))
fi
# Test 5: Firewall rules
if ssh vyos@$GREEN_IP "show firewall" | grep -q "rule"; then
echo "PASS: Firewall rules configured"
((TESTS_PASSED++))
else
echo "FAIL: Firewall rules missing"
((TESTS_FAILED++))
fi
echo ""
echo "Results: $TESTS_PASSED passed, $TESTS_FAILED failed"
if [ $TESTS_FAILED -eq 0 ]; then
echo "All tests passed - safe to proceed with traffic switchover"
exit 0
else
echo "Tests failed - do not switch traffic, investigate issues"
exit 1
fiSwitching traffic (via the VK Cloud Load Balancer):
#!/bin/bash
# vkcloud-switch-to-green.sh
# Switching traffic to the Green environment
# Check the tests
if ! ./vkcloud-test-green-env.sh; then
echo "Pre-flight tests failed. Aborting switchover."
exit 1
fi
# Gradual switchover (canary deployment)
echo "Phase 1: Switching 10% traffic to Green..."
# Configure the Load Balancer for 10% of traffic to Green
# (done via the VK Cloud API or the management console)
sleep 300 # 5 minutes of monitoring
echo "Phase 2: Switching 50% traffic to Green..."
# 50% of traffic to Green
sleep 300
echo "Phase 3: Switching 100% traffic to Green..."
# 100% of traffic to Green
echo "Switchover complete. Blue environment remains as rollback option."Rollback procedure:
#!/bin/bash
# vkcloud-rollback-to-blue.sh
# Rollback to the Blue environment when problems occur
echo "EMERGENCY ROLLBACK: Switching all traffic to Blue environment"
# Immediately switch 100% of traffic to Blue
# (via the VK Cloud Load Balancer API)
echo "All traffic redirected to Blue. Green environment available for investigation."
# Send a notification to the team
wall "ROLLBACK EXECUTED: All traffic returned to Blue environment"Automatic monitoring and rollback
#!/bin/bash
# vkcloud-auto-rollback-monitor.sh
# Automatic rollback when problems are detected
GREEN_IP="10.0.1.101"
BLUE_IP="10.0.1.100"
FAILURE_THRESHOLD=3
CHECK_INTERVAL=30
failures=0
while true; do
# Check the availability of Green
if ! ping -c 3 -W 5 $GREEN_IP > /dev/null 2>&1; then
((failures++))
echo "$(date): Green environment check failed ($failures/$FAILURE_THRESHOLD)"
if [ $failures -ge $FAILURE_THRESHOLD ]; then
echo "$(date): CRITICAL - Initiating automatic rollback to Blue"
./vkcloud-rollback-to-blue.sh
# Send a critical notification
curl -X POST https://monitoring.vkcloud.example/alert \
-d "severity=critical&message=Auto-rollback to Blue executed"
# Stop monitoring after the rollback
exit 1
fi
else
# Reset the counter on a successful check
if [ $failures -gt 0 ]; then
echo "$(date): Green environment recovered"
fi
failures=0
fi
sleep $CHECK_INTERVAL
doneExample 3: Hybrid cloud environment - Multi-cloud update strategy
#!/bin/bash
# multi-cloud-update-strategy.sh
# Updating VyOS routers in a multi-cloud environment
# Routers in different clouds
YANDEX_ROUTERS="10.128.0.10 10.128.0.11"
VK_ROUTERS="10.0.1.10 10.0.1.11"
ONPREM_ROUTERS="192.168.1.10 192.168.1.11"
# Function to update a single router
update_router() {
local ROUTER_IP=$1
local ENV_NAME=$2
echo "[$ENV_NAME] Updating router $ROUTER_IP"
# Create a configuration backup
ssh vyos@$ROUTER_IP "save /config/backup-$(date +%Y%m%d).config"
# Download the backup to the local server
scp vyos@$ROUTER_IP:/config/backup-$(date +%Y%m%d).config ./backups/$ENV_NAME-$ROUTER_IP-$(date +%Y%m%d).config
# Update the image
ssh vyos@$ROUTER_IP "add system image latest" < /dev/null
# Schedule a reboot in 5 minutes (to allow cancellation)
ssh vyos@$ROUTER_IP "shutdown reboot +5 'Automatic update'"
echo "[$ENV_NAME] Router $ROUTER_IP scheduled for update"
}
# Update in stages: Yandex Cloud first
echo "Stage 1: Updating Yandex Cloud routers"
for ROUTER in $YANDEX_ROUTERS; do
update_router $ROUTER "Yandex Cloud"
sleep 600 # 10 minutes between routers
done
sleep 1800 # 30 minutes to verify
# Then VK Cloud
echo "Stage 2: Updating VK Cloud routers"
for ROUTER in $VK_ROUTERS; do
update_router $ROUTER "VK Cloud"
sleep 600
done
sleep 1800
# Finally, on-premise
echo "Stage 3: Updating on-premise routers"
for ROUTER in $ONPREM_ROUTERS; do
update_router $ROUTER "On-Premise"
sleep 600
done
echo "All routers updated. Monitor for next 24 hours."Verification and monitoring commands
Checking the version and images
# Current version
show version
# Short version (number only)
show version brief
# All installed images
show system image
# Detailed information
show version allChecking for updates
# Check for available updates
show system updates
# Show the update-check configuration
show configuration system update-check
# Show the update-check URL
show configuration system update-check urlMonitoring disk space
# Overall usage
show system storage
# Detailed by filesystem
df -h
# Size of each image
du -sh /boot/*/
# Top 10 largest files in /config
du -ah /config | sort -rh | head -10Checking the boot history
# Recent reboots
last reboot
# Uptime of the current session
show system uptime
# Date of the last boot
who -bUpdate logs
# Image installation logs
show log | match image
# System logs
show log tail 100
# Boot logs
show log boot
# Search for errors during an update
show log | match -i "error\|fail" | match imageTroubleshooting
Problem 1: Not enough space to install a new image
Symptoms:
Error: Not enough disk space to install new image
Required: 1.5G, Available: 800MDiagnostics:
# Check available space
show system storage
# Show all images
show system image
# Size of each image
du -sh /boot/*/Solution:
# Delete old, unused images
delete system image 1.4.0-sagitta
# Clear old logs
sudo find /var/log -type f -name "*.gz" -delete
sudo find /var/log -type f -name "*.old" -delete
# Clear old configuration backups
sudo rm /config/backup-*.config
# Check the freed-up space
show system storage
# Retry the installation
add system image latestProblem 2: The new image hangs during boot
Symptoms:
- The system hangs on the boot screen
- GRUB shows the new image, but the boot does not complete
- Kernel panic messages appear
Solution via GRUB:
- Reboot the system (physically or via IPMI/KVM)
- Press ESC when GRUB appears
- Select the previously working image
- After a successful boot:
# Set the old image as the default
set system image default-boot 1.5-rolling-202312250024
# Delete the problematic image
delete system image 1.5-rolling-202401150023
# Check the logs for diagnostics
show log boot
show log kernelProblem 3: The configuration is not applied after an update
Symptoms:
- After the update and reboot, the configuration is not applied
- Interfaces are not configured
- Services are not started
Diagnostics:
# Check the current version
show version
# Check the configuration contents
show configuration
# Check the configuration file
cat /config/config.boot
# Check the boot logs
show log boot | match -i "error\|fail\|warn"Solution:
# Load the configuration from a backup
configure
load /config/backup-before-update-20240115.config
commit
save
exit
# If no backup exists - restore a minimal configuration
configure
# Basic interface configuration
set interfaces ethernet eth0 address dhcp
set interfaces ethernet eth0 description 'WAN'
set interfaces ethernet eth1 address 192.168.1.1/24
set interfaces ethernet eth1 description 'LAN'
# NAT
set nat source rule 100 outbound-interface name 'eth0'
set nat source rule 100 source address 192.168.1.0/24
set nat source rule 100 translation address masquerade
commit
save
exitProblem 4: Error downloading the image from a URL
Symptoms:
Error: Failed to download image from URL
Connection timeout or HTTP errorDiagnostics:
# Check network connectivity
ping -c 5 github.com
# Check DNS
nslookup github.com
# Check the route to the internet
show ip route
# Check NAT (if used)
show nat source statistics
# Try to fetch the URL manually
curl -I https://github.com/vyos/vyos-rolling-nightly-builds/releases/download/1.5-rolling-202401150023/1.5-rolling-202401150023-amd64.isoSolution:
# Option 1: Use plain HTTP instead of HTTPS (if possible)
add system image http://mirror.example.com/vyos-image.iso
# Option 2: Download the image to a local server
# On an external server with internet access:
wget https://github.com/vyos/vyos-rolling-nightly-builds/releases/download/1.5-rolling-202401150023/1.5-rolling-202401150023-amd64.iso
# Start an HTTP server
python3 -m http.server 8080
# On VyOS:
add system image http://192.168.1.100:8080/1.5-rolling-202401150023-amd64.iso
# Option 3: Transfer via SCP
# Copy the file to VyOS
scp vyos-image.iso vyos@router:/tmp/
# Install from the local file
add system image /tmp/vyos-image.isoProblem 5: Access to the system is lost after an update
Symptoms:
- The SSH connection drops after the reboot
- You cannot connect to the router
- Ping does not go through
Diagnostics via the console (KVM/IPMI/Serial):
# Log in via the console
# Check the interfaces
show interfaces
# Check the IP addresses
ip addr show
# Check routing
show ip route
# Check the firewall
show firewallSolution:
# Via the console - restore network connectivity
configure
# Verify that the interfaces are configured
show interfaces
# If not - configure them again
set interfaces ethernet eth0 address 192.168.1.1/24
# Temporarily disable the firewall for diagnostics
set firewall all-ping enable
commit
exit
# Try the SSH connection againIf the console is unavailable - roll back via GRUB:
- Reboot (hard reset)
- Select the previous image in GRUB
- After booting, set it as the default
Problem 6: The GRUB menu does not appear
Symptoms:
- The system automatically boots the default image
- You cannot select a different image
Solution:
Method 1: Configure the GRUB timeout
Via SSH (before the problem occurs):
# Increase the GRUB timeout to allow selecting an image
sudo vi /boot/grub/grub.cfg
# Find the line:
# set timeout=0
# Change it to:
# set timeout=10
# Save and rebootMethod 2: Press ESC during boot
- When the VyOS logo appears, press ESC repeatedly
- The GRUB menu should appear even when timeout=0
Method 3: Via the serial console
# Configure the serial console for GRUB access
configure
set system console device ttyS0 speed 9600
commit
save
exitBest Practices
1. Back up before an update
Always create a configuration backup:
# Automatic backup with a timestamp
save /config/backup-$(date +%Y%m%d-%H%M%S).config
# Copy to an external server
scp /config/backup-$(date +%Y%m%d-%H%M%S).config user@backup-server:/vyos-backups/
# For critical systems - a disk snapshot (in the cloud)
# Yandex Cloud: create a snapshot via the web UI or API
# VK Cloud: create a snapshot via the management console2. Test updates
Never update production without testing:
# Testing pipeline:
# 1. Lab environment (isolated network)
# 2. Dev environment (development)
# 3. Staging environment (pre-production)
# 4. Production (on the maintenance-window schedule)
# For each stage:
# - Install the image
# - Load the production configuration
# - Test all critical functions
# - Monitor performance
# - Only after success - move to the next stage3. Document updates
Keep an update log:
# Example log entry
# /config/update-log.txt
2024-01-15 18:00 MSK - Update started
Router: vyos-router-01
Previous version: 1.5-rolling-202312220023
New version: 1.5-rolling-202401150023
Reason: Security patches
Executed by: admin@example.com
Backup: /backups/vyos-20240115-180000.config
Rollback plan: GRUB select previous image
2024-01-15 18:15 MSK - Update completed successfully
Post-update checks: PASSED
All services operational4. Maintenance Windows
Schedule updates during off-peak hours:
# Define a maintenance window
# Examples:
# - Corporate network: 22:00-02:00 on weekdays
# - ISP: 03:00-05:00 on weekdays
# - Critical systems: weekends only
# Notify users in advance
configure
set system login banner pre-login "
MAINTENANCE WINDOW: 15.01.2024 22:00-02:00 MSK
VyOS update scheduled. Brief service interruption expected.
"
commit
save
exit5. Staged Rollout
For multiple routers - update gradually:
# Week 1: Lab and Dev routers (10% fleet)
# Week 2: Staging and non-critical (30% fleet)
# Week 3: Half of production (50% fleet)
# Week 4: Remaining production (100% fleet)
# Between stages:
# - Monitor for 7 days
# - Collect feedback from users
# - Analyze logs and metrics
# - Halt the rollout if problems occur6. Monitoring after an update
Enhanced monitoring for the first 24-48 hours:
#!/bin/bash
# post-update-monitoring.sh
# Extended monitoring after an update
ROUTER_IP="192.168.1.1"
CHECK_INTERVAL=60 # seconds
DURATION=86400 # 24 hours
end_time=$(($(date +%s) + DURATION))
while [ $(date +%s) -lt $end_time ]; do
echo "=== $(date) ==="
# CPU usage
ssh vyos@$ROUTER_IP "show system cpu" | grep "CPU"
# Memory usage
ssh vyos@$ROUTER_IP "show system memory" | grep "Mem:"
# Interface status
ssh vyos@$ROUTER_IP "show interfaces" | grep -E "eth[0-9]|state"
# Connection count
ssh vyos@$ROUTER_IP "show system connections" | wc -l
# Errors in logs
ERRORS=$(ssh vyos@$ROUTER_IP "show log tail 100 | grep -i error" | wc -l)
if [ $ERRORS -gt 0 ]; then
echo "WARNING: $ERRORS errors detected in logs"
fi
sleep $CHECK_INTERVAL
done7. Rollback Plan
Always have a rollback plan ready:
# Document rollback-plan.md
# ROLLBACK PLAN for the 15.01.2024 update
## Conditions for a rollback:
1. Critical services unavailable > 5 minutes
2. Loss of connectivity > 3 minutes
3. CPU/Memory usage > 90% for 10 minutes
4. Critical errors detected in the logs
## Rollback procedure:
1. SSH access: ssh vyos@192.168.1.1
2. Command: set system image default-boot 1.5-rolling-202312220023
3. Command: reboot now
4. Wait: 5 minutes
5. Verify: ping, SSH, services
6. Notify: the team about the rollback
## Escalation contacts:
- L1 Support: +7-xxx-xxx-xxxx
- L2 Engineering: engineering@example.com
- L3 Vendor Support: VyOS commercial support
## Backup location:
- Config: /backups/vyos-20240115.config
- Disk snapshot (Yandex Cloud): snapshot-20240115-1800008. Versioning and labels
Use clear names for images:
# Instead of:
# 1.5-rolling-202401150023
# Use rename:
rename system image 1.5-rolling-202401150023 to production-current
rename system image 1.5-rolling-202312220023 to production-previous
rename system image 1.4.0-sagitta to lts-stable
# Result:
show system image
# 1: production-current (default boot) (running image)
# 2: production-previous
# 3: lts-stable9. Automation via CI/CD
For large infrastructures - automation:
# .gitlab-ci.yml - an example CI/CD pipeline for VyOS updates
stages:
- backup
- update
- verify
- rollback
variables:
VYOS_ROUTERS: "10.0.1.10 10.0.1.11 10.0.1.12"
IMAGE_URL: "https://downloads.example.com/vyos-latest.iso"
backup_configs:
stage: backup
script:
- for router in $VYOS_ROUTERS; do
ssh vyos@$router "save /config/backup-$(date +%Y%m%d).config";
scp vyos@$router:/config/backup-$(date +%Y%m%d).config ./backups/;
done
artifacts:
paths:
- backups/
update_routers:
stage: update
script:
- for router in $VYOS_ROUTERS; do
ssh vyos@$router "add system image $IMAGE_URL";
ssh vyos@$router "shutdown reboot +5";
sleep 600;
done
dependencies:
- backup_configs
verify_update:
stage: verify
script:
- ./scripts/verify-routers.sh
allow_failure: true
rollback_on_failure:
stage: rollback
when: on_failure
script:
- ./scripts/rollback-all-routers.sh10. Security during updates
Verify the authenticity of images:
# Verify the image checksum
curl -O https://downloads.vyos.io/rolling/current/vyos-1.5-rolling-202401150023-amd64.iso
curl -O https://downloads.vyos.io/rolling/current/vyos-1.5-rolling-202401150023-amd64.iso.sha256
# Verify the checksum
sha256sum -c vyos-1.5-rolling-202401150023-amd64.iso.sha256
# Only install after a successful verification
add system image /tmp/vyos-1.5-rolling-202401150023-amd64.isoUpdate automation
Automated update script with checks
#!/bin/bash
# auto-update-vyos.sh
# Fully automated update with checks
set -e
ROUTER_IP="192.168.1.1"
BACKUP_DIR="/backups/vyos"
LOG_FILE="/var/log/vyos-auto-update.log"
ADMIN_EMAIL="admin@example.com"
log() {
echo "[$(date '+%Y-%m-%d %H:%M:%S')] $1" | tee -a $LOG_FILE
}
send_notification() {
local subject="$1"
local body="$2"
echo "$body" | mail -s "$subject" $ADMIN_EMAIL
}
# Pre-flight checks
log "Starting pre-flight checks"
# Check SSH connectivity
if ! ssh -o ConnectTimeout=5 vyos@$ROUTER_IP "show version" > /dev/null 2>&1; then
log "ERROR: Cannot connect to router"
send_notification "VyOS Update FAILED" "Cannot connect to router $ROUTER_IP"
exit 1
fi
# Check disk space
DISK_USAGE=$(ssh vyos@$ROUTER_IP "df -h / | tail -1 | awk '{print \$5}' | sed 's/%//'")
if [ $DISK_USAGE -gt 70 ]; then
log "WARNING: Disk usage is ${DISK_USAGE}%"
send_notification "VyOS Update WARNING" "High disk usage (${DISK_USAGE}%) on $ROUTER_IP"
# Cleanup old images if needed
log "Cleaning up old images"
ssh vyos@$ROUTER_IP "delete system image oldest"
fi
# Backup configuration
log "Creating configuration backup"
BACKUP_FILE="$BACKUP_DIR/$(date +%Y%m%d-%H%M%S)-$ROUTER_IP.config"
ssh vyos@$ROUTER_IP "save /tmp/backup.config"
scp vyos@$ROUTER_IP:/tmp/backup.config $BACKUP_FILE
if [ ! -f $BACKUP_FILE ]; then
log "ERROR: Backup failed"
send_notification "VyOS Update FAILED" "Backup creation failed for $ROUTER_IP"
exit 1
fi
log "Backup created: $BACKUP_FILE"
# Check for updates
log "Checking for available updates"
UPDATE_INFO=$(ssh vyos@$ROUTER_IP "show system updates" 2>&1)
if echo "$UPDATE_INFO" | grep -q "Update available"; then
NEW_VERSION=$(echo "$UPDATE_INFO" | grep "Update available" | awk '{print $3}')
log "Update available: $NEW_VERSION"
# Download and install new image
log "Installing new image: $NEW_VERSION"
ssh vyos@$ROUTER_IP "add system image latest" < /dev/null
# Set as default boot
log "Setting new image as default boot"
ssh vyos@$ROUTER_IP "set system image default-boot $NEW_VERSION"
# Schedule reboot in 5 minutes (safety window for cancellation)
log "Scheduling reboot in 5 minutes"
ssh vyos@$ROUTER_IP "shutdown reboot +5 'Automatic update to $NEW_VERSION'"
send_notification "VyOS Update SCHEDULED" "Router $ROUTER_IP will reboot in 5 minutes to apply update to $NEW_VERSION"
# Wait for reboot to complete
log "Waiting for reboot to complete"
sleep 360 # 6 minutes
# Post-reboot verification
log "Starting post-reboot verification"
RETRIES=10
while [ $RETRIES -gt 0 ]; do
if ssh -o ConnectTimeout=5 vyos@$ROUTER_IP "show version" > /dev/null 2>&1; then
log "Router is back online"
break
fi
log "Waiting for router to come back online (retries left: $RETRIES)"
sleep 30
((RETRIES--))
done
if [ $RETRIES -eq 0 ]; then
log "ERROR: Router did not come back online after reboot"
send_notification "VyOS Update CRITICAL" "Router $ROUTER_IP did not come back online after update. Manual intervention required!"
exit 1
fi
# Verify new version is running
CURRENT_VERSION=$(ssh vyos@$ROUTER_IP "show version | grep Version | awk '{print \$2}'")
if [ "$CURRENT_VERSION" == "$NEW_VERSION" ]; then
log "SUCCESS: Update completed successfully to $NEW_VERSION"
send_notification "VyOS Update SUCCESS" "Router $ROUTER_IP successfully updated to $NEW_VERSION"
else
log "WARNING: Version mismatch. Expected $NEW_VERSION, got $CURRENT_VERSION"
send_notification "VyOS Update WARNING" "Version mismatch on $ROUTER_IP. Expected $NEW_VERSION, got $CURRENT_VERSION"
fi
# Run post-update checks
log "Running post-update health checks"
# Check interfaces
if ! ssh vyos@$ROUTER_IP "show interfaces" | grep -q "eth0"; then
log "ERROR: Interfaces not configured properly"
send_notification "VyOS Update ISSUE" "Interfaces not configured on $ROUTER_IP after update"
fi
# Check routing
if ! ssh vyos@$ROUTER_IP "show ip route" | grep -q "default"; then
log "ERROR: Default route missing"
send_notification "VyOS Update ISSUE" "Default route missing on $ROUTER_IP after update"
fi
log "Update process completed"
else
log "No updates available"
fi
log "Update script finished"Scheduling automatic updates
# Configure cron on the management server for weekly updates
# /etc/cron.d/vyos-updates
# Update every Sunday at 3:00 AM
0 3 * * 0 /opt/scripts/auto-update-vyos.sh >> /var/log/vyos-auto-update.log 2>&1Useful commands
# Viewing the version
show version
show version brief
# Managing images
show system image
add system image <url|latest>
delete system image <name>
rename system image <old-name> to <new-name>
set system image default-boot <name>
# Checking for updates
show system updates
show configuration system update-check
# Backup
save <filename>
save /config/backup-$(date +%Y%m%d).config
# Reboot
reboot
reboot now
shutdown reboot +5
shutdown reboot 18:00
# Monitoring
show system storage
show system uptime
show log | match image
df -h
# Rollback
set system image default-boot <previous-version>
# via GRUB: select the previous image at bootConclusion
Proper management of VyOS updates is critical for maintaining the security and stability of your network infrastructure. The image-based mechanism provides:
- Safe testing of new versions
- Fast rollback when problems occur
- Version isolation
- Preservation of the configuration between updates
Key recommendations:
- Always create a backup before an update
- Test updates in a lab environment
- Plan maintenance windows for production systems
- Document all changes
- Monitor the system after an update
- Have a rollback plan in case of problems
- Use staged rollout for large infrastructures
- Verify the compatibility of the configuration with the new version
- Follow the VyOS release notes for known issues
- Automate the process where possible, but with safety checks
For production environments, we recommend using LTS versions of VyOS and applying updates only after thorough testing in a staging environment. Rolling release versions are suitable for labs and development environments where access to the latest features is important.