Password Kernel 1.3 serial key or number

The VIRL PE 1.6 release is an incremental update to VIRL PE 1.5, including bug fixes, updated reference platforms, and some enhancements since the VIRL PE 1.5.145 release. The major additions to this release are support for IPv6 on the primary and shared networks, and the availability of a set of additional shared networks. Unlike in the 1.5 release, the changes introduced in VIRL PE 1.6 have not affected the configuration and installation process in significant ways. Therefore, the same set of salt masters as configured for VIRL PE 1.5 can provision the upgrade to any deployed 1.5 instance. For more information, see the sections below on how to migrate to VIRL PE 1.6.

NOTE

• If you are running VIRL PE 1.2.83 or earlier today, or if you're running a 1.3.x cluster setup, you CANNOT perform an in-place upgrade. Migrating to VIRL PE 1.6 requires a fresh installation either by deploying the OVA or, on bare metal systems, by installing the ISO image.
• Due to space constraints, the ISO image only contains a minimum set of VM images (IOSv, IOSv-L2 and the Server image). Additional images can be added using UWM once the system is installed.
• If deploying on a Cisco UCS C220M4 with Cisco 12G SAS Modular RAID Controller you must enable RAM disk using the UWM System Configuration pages in order to support IOS XRv images.

Availability

Installation images for all supported platforms are available for download. Login to My Account in the Cisco Learning Store and click Download in the VIRL PE subscription box.

ATTENTION:Versions older than v1.5.145 are not supported anymore with the release of v1.6. PLEASE UPGRADE AS SOON AS POSSIBLE!

Online training material is available -- this material is designed to help get you started and productive quickly – Cisco VIRL Getting Started Tutorial

NOTE: the tutorial includes some video walkthroughs. To view the video, ensure that your browser supports H.264 video and any plugins are enabled.
 

Software Version History

IPv6 access on the primary network

With the 1.6 release, both automatic and static optional configuration of an IPv6 address is available on the primary (management) network used to access the VIRL deployment. Either at install time, in the startup configuration, or post-deployment and after an upgrade, using the virl_setup tool, the primary network's addressing can be adjusted. All required VIRL services are available via both IPv4 and IPv6. Static IP configuration of cluster compute nodes is available in the UWM System Configuration, or in the virl_setup tool. Automatic configuration on the primary network can be switched from SLAAC to DHCPv6, if required in a particular deployment environment.

Additional shared networks

Up to six shared networks are made available in the UWM System configuration, in addition to the original pair of shared networks, named 'flat' and 'flat1'. These new networks are named composed of a fixed prefix 'shared-', and a configurable suffix; the expectation is to use this suffix to distinguish these new networks by their purpose, or equipment connected through them.

Like with the original two shared networks, a physical interface of the main VIRL (controller) host may be selected to provide a connection of this network with the outside lab environment. This is optional, hence no additional interfaces are required on the host in order to install and use VIRL PE 1.6. Without an external interface, the shared networks are available to bridge together nodes from different simulations running in the same deployment.

Both an IPv4 and an IPv6 subnet may be configured on any of the eight shared networks. The original two shared networks must have an IPv4 subnet configured for compatibility reasons. The new shared networks require at least one subnet to be configured.

The IPv6 subnet for a shared network is fixed with a /64 prefix. The simulation nodes shall receive their IPv6 addresses via SLAAC, provided by the built-in facility. Thus, the IPv6 address of each host is computed from their interface MAC address, which can be controlled using the 'static_mac' extension. This extension can be set of a node to control the management interface addressing, or on the L2 FLAT element connected to a data interface used for this shared network.

For Cisco router nodes that don't support SLAAC, notably IOS XRv, the initial configuration may contain a '(no )ipv6 address' line in the initial configuration. The correct IPv6 address will be injected into that line when the node is starting, using the same mechanism employed for IPv4 addresses on nodes that don't support DHCP.

In case the nodes in the shared network are supposed to communicate IPv6 traffic through to other networks in the outside lab environment, a suitable router is expected to be configured in the outside lab. That router should be advertising the same IPv6 prefix to avoid misconfiguration.

Controlling reported host URLs and IP addresses (in a cluster)

The location of the VIRL PE host used by individual users may vary in particular scenarios, such as if a NAT is employed between the users and the deployed lab, or if the VIRL services are being accessed over a shared network and an OpenVPN connection. The VIRL PE services do not make assumptions over the presence and validity of a DNS system in the lab where it is deployed either - no reverse lookups are used to determine a public hostname for any VIRL host, be it the controller or compute hosts in a cluster.

A configuration option named 'virl_local_ip' was used in these situations to inform the VIRL services what hostname or IP to use to refer to itself. No equivalent option existed for compute hosts in a cluster; this resulted in the reported links for serial consoles of nodes deployed to computes using the primary interface IP address of that compute host. Which is usually incorrect in such scenarios.

The generated links in both UWM and the desktop UI now consistently reuse the same host that the client is using, be it a hostname or IP address. Thus, for single-host deployments, and the controller node in a cluster, there is no need to configure virl_local_ip or anything else in this respect, anymore.

In a cluster deployment, in cases where the primary network address of the compute is not to be used, a different configuration can be applied. Log into the VIRL controller node, and issue a command such as . For controller that has the set hostname 'X', use the 'resolve_X' to force the value regardless of what the user configured; this is not required, and may be counterproductive though. After the configurations are present for all hosts, use to apply the changes.

Improved control over generated MAC addresses

The MAC addresses of simulation nodes' interfaces are assigned by one of three mechanisms: 1. static_mac - for management interfaces, and interfaces connected to L2 FLAT or L3 SNAT simulation elements; 2. management addresses are generated using a pattern consisting of a constant prefix, and a unique simulation and node number; and 3; all other interfaces use a random MAC address with a constant prefix like 'fa:16:3e'.

In cases where shared networks are inter-connected between multiple VIRL PE or OpenStack deployments, the same address might be assigned to two nodes. The UWM system configuration can now be used to control and avoid clashes by picking a different prefix for addresses generated by the second and third mechanism.

Bare-metal installations use hardware enablement kernels

The ISO installer contains a newer Linux kernel release, which is run by default on all new deployments. This kernel should allow for certain newer hardware components to be recognized properly when installed on a physical computer. The older kernel can still be selected when booting the server from the bootloader menus.

Due to performance issues with some newer kernels available by default to the Ubuntu 16.04 (Xenial) system, the new kernel is installed from a Ubuntu 18.04 (Bionic) repository. Only the kernel packages shall be installed from this repository, all other packages are disabled from being considered for installation.

The ISO installer still does not support installations in UEFI mode; servers should be configured to Legacy (BIOS) mode before installation, as described in installation instructions.

Bug fixes and minor enhancements in 1.6.65

• Auto-netkit / Live visualization
  • VIRLDEV-4878 - IOSvL2 configuration for the cisco/cisco account consistent with IOSv
  • VIRLDEV-4738 - Custom configuration for router loopback 0 interface missing from generated configuration
  • VIRLDEV-6561 - Live vis services failed to communicate after port changes
  • VIRLDEV-6165 - Live vis path traces from LXC nodes were failing due to incorrect MTU settings in the LXC
  • VIRLDEV-4922 - Collect log action fails for NX-OSv
  • VIRLDEV-6357 - Connecting to management IP of server and LXC nodes failed
• VM Maestro
  • VIRLDEV-6375 - Upgrade the bundled java versions
  • VIRLDEV-6242 - Offer current shared networks for L2 FLAT host network setting
  • VIRLDEV-6198 - Allow setting backend service URL using an IPv6 address
  • VIRLDEV-6022 - Remember size of the extension edit window
  • VIRLDEV-6599 - Remove dependency on potentially vulnerable package
  • VIRLDEV-6707 - Sign the Mac OS X GUI application with an official Cisco key

• UWM

  • VIRLDEV-5570 - Remember previous values for some system configuration values for proper cleanup

  • VIRLDEV-5571 - Fix order of system configuration actions when multiple system configuration values are changed
  • VIRLDEV-6361 - Background tasks may leak memory and stop updating external state
  • VIRLDEV-5851 - Cluster health was green when active computes were missing
  • VIRLDEV-6180 - Do not report license failure before activation
  • VIRLDEV-6240 - Ensure each compute host is used in cluster system operation check
  • VIRLDEV-6246 - Add support for Git operations via REST API
  • VIRLDEV-6133 - Multiple user creation does not work as expected
  • VIRLDEV-6461 - Salt configuration and status does not show each failing salt master connection
  • VIRLDEV-6307 - Support git source for browser-based editing of a virl file
  • VIRLDEV-6348 - Fix preview of virl file synced from the browser-based editor
  • VIRLDEV-6451 - Fix API wrongly returning 401 unauthorized instead of 403 forbidden if resource operation is prohibited by System configuration controls
  • VIRLDEV-5488 - SSH console can be higher than browser window, failing to display most recent lines
  • VIRLDEV-6523 - Volumes cannot be created
  • VIRLDEV-6284 - Upgrade shall visually distinguish successfult and failed steps
  • VIRLDEV-6241 - System operation check fails in maintenance mode
  • VIRLDEV-6164 - OpenVPN configuration file is being cached by browsers unchanged even when modified during system configuration
  • VIRLDEV-6008 - Restrict access to VM Control pages to uwmadmin based on system configuration.
• VIRL Core
  • VIRLDEV-6079 - allow up to 128 data interfaces in a node subtype. Note that large numbers of interfaces on a node may slow down its deployment and teardown, in addition to potential increased resource requirements by the node itself. All data interfaces from first up to the highest interface present on a node in the topology file must be simulated.
  • VIRLDEV-6072 - Interface count for IOS XRv 9000 was lowered to 8 data interfaces. This matches official documentation of the current IOS XRv 9000 images. Future releases of IOS XRv 9000 may increase the number of available interfaces
  • VIRLDEV-6073 - Interface count for NX-OSv 9000 was increased to 64 data interfaces, and its hw_bios switched to OVMF.fd.
    • Note that operating a NX-OSv 9000 node with more interfaces places increased demands on memory for the node, meaning that a different flavor may be required for such nodes. See also known issue VIRLDEV-6416.
    • On upgrade, existing NX-OSv 9000 images with a hw_bios setting set to n9kbios.bin should be modified in UWM Node Resources > Images to also switch to OVMF.fd.
  • VIRLDEV-4947 - Allow node to set its serial and machine UUID. Due to infrastructure constraints, only one node with a given UUID may be placed in the VIRL system at a time.
  • VIRLDEV-6555 - Change method of connecting static serial ports with node serial consoles directly
  • VIRLDEV-6528 - Allow nodes to specify common names for dummy interface networks. A node extension allows connecting special interfaces between management and data interfaces
  • VIRLDEV-6258 - Initial confuguration management/shared/snat IP address injection shall not rewrite 'ip address dhcp'
  • VIRLDEV-6061 - Traffic capture does not start for node in a site element
  • VIRLDEV-6095 - Docker node in a site, or with non-standard name does not start
  • VIRLDEV-6169 - Fix apparent overlap in TCP port ranges
  • VIRLDEV-6105 - Live capture does not report port clashes
  • VIRLDEV-6817 - Increased memory limit in lxc-sshd (and derived subtypes including management LXC) to 32 MB to avoid shutoffs due to limit being reached
  • VIRLDEV-6888 - HWE kernel dropped overlayfs alias for overlay filesystem

• Infrastructure

  • VIRLDEV-6079 - Support PCI multifunction for interfaces. An image property can control how interface hardware is simulated; may be useful if more than 28 interfaces are simulated on a node
  • VIRLDEV-6098 - Nodes are not proportionately distributed across cluster. The main weight is now placed on the number of unoccupied CPUs on a host
  • VIRLDEV-6102 - OpenStack and other infrastructure services only listen on internal interfaces
  • VIRLDEV-6116 - qemu was generating large amounts of messages in individual VM logs (IOSv nodes) wrt register access
  • VIRLDEV-6100 - add generated password protection to redis service
  • VIRLDEV-6254 - randomize keystone service token
  • VIRLDEV-6159 - generate new OpenVPN keys whenever OpenVPN is re-enabled
  • VIRLDEV-6267 - propagate built bridge module to computes
  • VIRLDEV-6201 - Switch to docker community edition; update coreos image
  • VIRLDEV-6292 - Eliminate vinstall subcommands other than salt and upgrade
  • VIRLDEV-6224 - Compute minion validates MTU on cluster network on startup
  • VIRLDEV-6343 - Do not run Apache on compute hosts
  • VIRLDEV-6338 - Increase timeout of libvirtd waiting on kvm to avoid nodes going into error state on smaller hosts
  • VIRLDEV-6312 - Upgrade from obsolete and vulnerable pycrypto to pycryptodome
  • VIRLDEV-6313 - Upgrade from theoretically vulnerable paramiko versions
  • VIRLDEV-6231 - Change login message of disabled computes
  • VIRLDEV-6187 - Allow changing cluster subnet on non-cluster deployment
  • VIRLDEV-6543 - Disabling cluster in virl_setup does not work as expected
  • VIRLDEV-6317 - Kernel bridge module must be compiled with 'retpoline'-supporting gcc on latest kernels
  • VIRLDEV-6342 - Make system services wait for interfaces they depend on
  • VIRLDEV-6422 - Salt error even if valid salt master is found
  • VIRLDEV-6745 - Allow VM metadata to be downloaded using neutron metadata service
  • VIRLDEV-5457 - Disabled screensaver on baremetal console
  • VIRLDEV-6825 - Upgrade fails on common.grub

Bug fixes and minor enhancements in 1.6.67

• Infrastructure
  • VIRLDEV-7395 Fix ARP neighbor table overflow
  • VIRLDEV-7409 Set default value for 'licence_renew_interval'
  • VIRLDEV-7411 Update OpenStack patches to match the latest OpenStack modules
  • VIRLDEV-7421 Upgrade salt version to 3000.x
  • Increase limit for virtlogd
  • Flush keystone token table periodically
  • Pin Werkzeug to version below 1.0.0

Security vulnerabilities in Salt

All VIRL PE releases older than 1.6.67 are using a version of salt, 2017.7.2, that has known security vulnerabilities, CVE-2020-11651 and CVE-2020-11652. See the Cisco Security Advisory cisco-sa-salt-2vx545AG for more information about the vulnerabilities and whether your VIRL PE instance may have been running a vulnerable service.

VIRL PE 1.6.67 fixes the problem by using a newer version of salt, 3000.3, which contains fixes for CVE-2020-11651 and CVE-2020-11652.

Performing a New Installation

If you already have a previous version of VIRL PE installed, it may be possible to upgrade it. See below for more information on in-place upgrades.

If you do not already have VIRL PE installed, please use the updated VIRL PE 1.6 installation guides posted at VIRL PE documentation site

Select the instructions on that site appropriate for your selected installation option.

Deployment instructions for:

In-place upgrade instructions

NOTE - you must have communication to the current Cisco salt masters and have a valid license key in order to perform the upgrade.

NOTE - recent releases of both Firefox and Chrome browsers have disabled a feature required by UWM Upgrade page prior to the 1.6 release. Read the upgrade steps page for workarounds available in both browsers.

Currently Running VIRL PE version 1.5.x

An upgrade is available in the UWM VIRL Server > System Upgrade page. Follow the steps of the upgrade process to completion.

For further information on the individual steps, visit the upgrade steps page.

Currently Running VIRL PE Version 1.3.x

If your current VIRL PE instance is VIRL 1.3.x, you may perform an in-place upgrade to the latest release without reinstalling. The instructions for 1.5 upgrade can be followed, with two major differences.

First, if you're using DHCP for the primary network configuration, you need to clear Google's DNS nameserver configuration from the /etc/virl.ini configuration.

Second, the UWM in 1.3.x does not store the result of the individual upgrade commands. As a result, once the newer UWM takes over during the 'vinstall upgrade' step, the previous steps, including vinstall upgrade, may be highlighted in red, indicating a failure. A successful vinstall upgrade command will report

For further information on the individual steps, visit the upgrade steps for 1.3 page

Currently Running VIRL PE Version 1.2.x or Less

If your current VIRL PE instance is VIRL PE version 1.2.x, 1.1.x, or less, you must perform a full reinstallation to migrate to VIRL PE 1.6. See the section above for instructions on performing a "new installation."

Currently Running a VIRL PE Cluster

In-place upgrades are only supported for VIRL PE clusters of version 1.5.145 –a VIRL PE installation that consists of a controller and one or more compute nodes. If your current VIRL PE installation is a cluster, you may perform an upgrade, which will simultaneously upgrade all active compute hosts with the controller. The installation procedures and configuration process for a VIRL PE cluster has changed significantly in VIRL PE 1.5 to fix limitations in the VIRL PE 1.3 cluster configuration process. The upgrade instructions are not different between a 1.5.145 standalone and cluster deployments. All enabled computes must be running and reported as working properly for the upgrade to succeed.

Upgrade VIRL Client (VM Maestro)

You should update VM Maestro to the most recent 1.6.0 build. Older releases should still work since there were no changes in the file format or APIs from VIRL PE 1.2 or 1.3. However, running the latest version is generally recommended.

To download the new VM Maestro client

1. Open a web browser and navigate to the VIRL host or virtual machine's IP address.

2. Login to the User Workspace Management (UWM).

3. Select VIRL Server from the menu that appears on the left.

4. Select the Download sub-menu.

5. Select VM Maestro Clients from the list of options.

6. From the list of files presented, download the VM Maestro client appropriate to your local platform (setup EXE for Windows, DMG for OS X, or zip file for Linux).

7. Install VM Maestro.

Once you have installed VM Maestro, you may want to update the node types shown in the Palette to match any changes on the VIRL server:

1. Launch VM Maestro

2. Select File > Preferences > Node Subtypes.

3. Click the Fetch From Server button.
4. Click OK.

This release contains the following component versions:

• OpenStack Mitaka
• VIRL_CORE 0.10.37.35
• AutoNetkit 0.24.1/0.23.12
• Topology Visualization Engine 0.17.28
• Live Network Collection Engine 0.12.11
• VM Maestro 1.6.0-534

Cisco Platform VMs

Bare-metal ISO installers bundle fewer images, which may be added later through UWM.

• IOSv - 15.7(3)M (New)
• IOSv L2 - 15.2.1 (06.2018) (New)
• IOS XRv - 6.1.3 image
• IOS XRv 9000 - 6.5.1 image (New) (NOT BUNDLED, must be installed from the VIRL Software page in the UWM)
• CSR 1000v - 16.9.1 XE-based image (New)
• NX-OSv 7.3.0.1 (Nexus 7000)
• NX-OSv 9000 9.2.3 (Nexus 9000) (New) (NOT BUNDLED, must be installed via UWM > VIRLSoftware)
• ASAv 9.9.2 (New)
• CoreOS 1632.2.1 (New)
• Ubuntu 16.04.3 Cloud-init image

Linux Container Images

• Ubuntu 16.04 LXC

• iPerf 2.0.2 LXC

• Routem 2.1.8 LXC

• Ostinato-drone 0.8 LXC

Salt Master Settings

Once you have installed VIRL, apply for VIRL license key as per the installation instructions. You should enter at least two salt masters, picking a number between 1 and 4. Do not enter the same number twice! You can list up to four salt-masters. When specifying multiple salt masters, separate each one with a comma followed by a space; as shown below. Update your salt-master list if needed.

US (external only)

EU (external only)

AP (external only)

Note that in order to maximize availability and redundancy these master names may at times resolve to servers located in adjacent zones.

The Reset keys and ID dialog within the Salt Configuration and Status page of UWM makes this process easier by providing a default set of Salt masters which can be selected by either clicking the US or the EU button for the respective set of masters.

• Do NOT oversubscribe hardware resources at multiple levels.

  • It is possible to oversubscribe CPU and memory resources at both the VIRL PE System Configuration level and at the VMware ESXi level.

  • By default, VIRL PE applies an oversubscription factor of 2.0 for memory resources and 3.0 for CPU resources.

  • The recommended configuration is to use dedicated resources for the VIRL PE VM at the ESXi layer and control the hardware oversubscription from UWM > VIRL Server > System Configuration.

  • System performance should be closely monitored and the following caveats should be taken into account when running large topologies to this scale.

• The ability to run larger simulations, approaching the node limit or the total CPU and memory capacity of the system, is truly a factor of available resources (memory, CPU, i/o speed, networking configuration, etc.). In particular, node types that are heavier than IOSv might or might not work depending on available memory and CPU resources.
• Additional features (routing protocols, MPLS, ...) might impact the ability to reach the node limit by using more shared resources of the simulation environment.
• At this time, when launching large simulations, approaching the node limit or the system memory and CPU capacity, users must stagger the launch manually (see below for instructions on performing a staggered launch). Most of the Cisco node types place a higher load on the CPU just as the node boots up and loads its configuration. Cisco node types do not always react well to CPU starvation. The system generally functions properly with modest CPU oversubscription, but running simulations close to the total hardware capacity, especially with CPU oversubscription, and starting all of the nodes at once can lead to CPU starvation. A staggered launch will help to avoid this problem.

Staggered Launch of a Topology Simulation

When launching a large topology simulation (i.e., a topology that approaches the limits of the VIRL installation's hardware), it is recommended to avoid booting up every node at once when the simulation first starts. Instead, stagger the launch so that only a subset of the nodes is booting up at once. In the current release, topologies are not automatically staggered during launch. To perform a staggered launch of a topology simulation, the topology must indicate which nodes to start when the simulation is first launched. The back end will start the simulation, but it will only boot those nodes. The remaining nodes will remain in off / ABSENT state until they are manually started.

In VM Maestro, set the Exclude from Launch setting on nodes that you do not want to boot when the simulation first starts. As a starting point, pick a number of nodes equal to the number of physical cores, N, on your system. Try setting the “exclude from launch” setting on all nodes except for that “initial set” of nodes. Note that VM Maestro supports bulk editing: select multiple nodes at once in the topology editor, click the Properties view, and then check the edit a value to apply or remove the setting to all selected nodes. Once the Exclude from Launch setting has been applied to all but N nodes of the topology, the topology is ready for a staggered launch.

Start the simulation. Wait for just the initial set of N nodes to boot up and settle down. The nodes should at least to go to ACTIVE – REACHABLE state, and it’s probably best to leave them for a few minutes even after that to make sure that the configuration is loaded and the initial protocol processing is complete. In the running simulation view, select another batch of N nodes, right-click and select Start Node. Wait until that batch finishes booting up. Then start another batch of N nodes. Repeat until all of the nodes are booted up, running and ACTIVE – REACHABLE. Note that a REACHABLE state is only achieved if the initial or automatic configuration of a starting node achieves that the management IP address is present on the first interface of the node; initial configuration as generated by AutoNetkit is designed to accomplish this.

systemd-boot, previously called gummiboot (German for: 'rubber dinghy'), is a simple UEFI boot manager which executes configured EFI images. The default entry is selected by a configured pattern (glob) or an on-screen menu to be navigated via arrow-keys. It is included with systemd, which is installed on an Arch system by default.

It is simple to configure but it can only start EFI executables such as the Linux kernel EFISTUB, UEFI Shell, GRUB, or the Windows Boot Manager.

Installation

Installing the EFI boot manager

To install the systemd-boot EFI boot manager, first make sure the system has booted in UEFI mode and that UEFI variables are accessible. This can be checked by running the command or, if efivar is not installed, by doing (if the directory exists, the system is booted in UEFI mode).

will be used throughout this page to denote the ESP mountpoint, e.g. , or , or . This assumes that you have ed to your system's mount point.

With the ESP mounted to , use bootctl to install systemd-boot into the EFI system partition by running:

This will copy the systemd-boot boot loader to the EFI partition: on a x64 architecture system the two identical binaries and will be transferred to the ESP. It will then set systemd-boot as the default EFI application (default boot entry) loaded by the EFI Boot Manager.

To conclude the installation, configuresystemd-boot.

Installation using XBOOTLDR

Since systemd version 242, a separate partition of type can be created to keep the kernel and initramfs separate from the partition. XBOOTLDR [1] must have a partition type GUID of .

This is particularly helpful to dual boot with Windows with an existing EFI system partition that is too small. Otherwise create an partition as normal plus another for on the same physical drive. The size of should be enough to accommodate all of the kernels you are going to install.

During install mount to and to .

Once in chroot use the command:

To conclude the installation, configuresystemd-boot.

Updating the EFI boot manager

Whenever there is a new version of systemd-boot, the boot manager can be optionally reinstalled by the user. This can be performed manually or the update can be automatically triggered using pacman hooks. The two approaches are described thereafter.

Manual update

bootctl must be used to update systemd-boot.

If the ESP is mounted on a different location, check the man page for the options and .

Automatic update

The package systemd-boot-pacman-hook^AUR provides a Pacman hook to automate the update process. Installing the package will add a hook which will be executed every time the systemd package is upgraded. Alternatively, to replicate what the systemd-boot-pacman-hook package does without installing it, place the following pacman hook in the directory:

Configuration

Loader configuration

The loader configuration is stored in the file . The following settings can be specified:

• – default entry to select as defined in #Adding loaders; it can be a wildcard like .
• – menu timeout in seconds before the default entry is booted. If this is not set, the menu will only be shown on key (or most other keys actually work too) press during boot.
• – whether to enable the kernel parameters editor or not. (default) is enabled, is disabled; since the user can add to bypass root password and gain root access, it is strongly recommended to set this option to if the machine can be accessed by unauthorized persons.
• – shows automatic entries for Windows, EFI Shell, and Default Loader if set to (default), to hide;
• – shows entry for rebooting into UEFI firmware settings if set to (default), to hide;
• – changes UEFI console mode:
  • for 80x25;
  • for 80x50;
  • and above for non-standard modes provided by the device firmware, if any;
  • picks a suitable mode automatically;
  • for highest available mode;
  • (default) for the firmware selected mode.
• - controls whether to read the random seed from the file . If set to (default), it loads the seed from file only if the EFI variable is set; if set to , it loads the seed from file even if the EFI variable is unset; and if set to , the file is ignored.

For a detailed explanation of the available settings and their corresponding arguments see the loader.conf(5) manual. A loader configuration example is provided below:

Adding loaders

systemd-boot will search for boot menu items in and additionally in if using XBOOTLDR. The possible options are:

• – operating system name. Required.
• – kernel version, shown only when multiple entries with same title exist. Optional.
• – machine identifier from , shown only when multiple entries with same title and version exist. Optional.
• – EFI program to start, relative to your ESP (); e.g. . Either this parameter or (see below) is required.
• – command line options to pass to the EFI program or kernel parameters. Optional, but you will need at least if booting Linux. This parameter can be omitted if the root partition is assigned the correct Root Partition Type GUID as defined in Discoverable Partitions Specification and if the mkinitcpio hook is present.

For Linux boot, you can also use instead of . Or in addition to . The syntax is:

• and followed by the relative path of the corresponding files in the ESP; e.g. ; this will be automatically translated into and – this syntax is only supported for convenience and has no differences in function.

An example of a loader file to launch Arch from a partition with the label arch_os and loading the Intel CPU microcode is:

systemd-boot will automatically check at boot time for Windows Boot Manager at the location , EFI Shell and EFI Default Loader, as well as specially prepared kernel files found in . When detected, corresponding entries with titles , and , respectively, will be generated. These entries do not require manual loader configuration. However, it does not auto-detect other EFI applications (unlike rEFInd), so for booting the Linux kernel, manual configuration entries must be created.

EFI Shells or other EFI apps

In case you installed EFI shells and other EFI application into the ESP, you can use the following snippets.

Examples of loading custom UEFI Shell loaders:

Booting into EFI Firmware Setup

Most system firmware configured for EFI booting will add its own efibootmgr entries to boot into UEFI Firmware Setup.

Support hibernation

See Suspend and hibernate.

Kernel parameters editor with password protection

Alternatively you can install systemd-boot-password^AUR which supports basic configuration option. Use to generate a value for this option.

Install systemd-boot-password with the following command:

With enabled editor you will be prompted for your password before you can edit kernel parameters.

Keys inside the boot menu

The following keys are used inside the menu:

• - select entry
• - boot the selected entry
• - select the default entry to boot (stored in a non-volatile EFI variable)
• - decrease the timeout (stored in a non-volatile EFI variable)
• - increase the timeout (stored in a non-volatile EFI variable)
• - edit the kernel command line. It has no effect if the config option is set to .
• - show the systemd-boot and UEFI version
• - quit
• - print the current configuration
• - help

These hotkeys will, when pressed inside the menu or during bootup, directly boot a specific entry:

• - Linux
• - Windows
• - OS X
• - EFI Shell
• - number of entry

Tips and tricks

Choosing next boot

The boot manager is integrated with the systemctl command, allowing you to choose what option you want to boot after a reboot. For example, suppose you have built a custom kernel and created an entry file to boot into it, you can just launch

and your system will reboot into that entry maintaining the default option intact for subsequent boots. To see a list of possible entries pass the option.

If you want to boot into the firmware of your motherboard directly, then you can use this command:

Preparing a unified kernel image

systemd-boot searches in for unified kernel images, which bundle the kernel, the init RAM disk (initrd), the kernel command line, , and a splash image into one single file. This file can be easily signed for Secure Boot.

Put the kernel command line you want to use in a file, and create the bundle file like this:

Optionally sign the file produced above.

Copy into .

Grml on ESP

Grml is a small live system with a collection of software for system administration and rescue.

In order to install Grml on the ESP, we only need to copy the kernel , the initramfs , and the squashed image from the iso file to the ESP. To do so, first download grml64-small.iso and mount the file (the mountpoint is henceforth denoted mnt); the kernel and initramfs are located in , and the squashed image resides in .

Next, create a directory for Grml in your ESP,

and copy the above-mentioned files in there:

In the last step, create an entry for the systemd-boot loader: In create a file with the following content:

For an overview of the avialable boot options, consult the cheatcode for Grml.

systemd-boot on BIOS systems

If you need a bootloader for BIOS systems that follows The Boot Loader Specification, then systemd-boot can be pressed into service on BIOS systems. The Clover boot loader supports booting from BIOS systems and provides a simulated EFI environment.

Troubleshooting

Installing after booting in BIOS mode

If booted in BIOS mode, you can still install systemd-boot, however this process requires you to tell firmware to launch systemd-boot's EFI file at boot, usually via two ways:

• you have a working EFI Shell somewhere else.
• your firmware interface provides a way of properly setting the EFI file that needs to be loaded at boot time.

If you can do it, the installation is easier: go into your EFI Shell or your firmware configuration interface and change your machine's default EFI file to (or depending if your system firmware is 32 bit).

Manual entry using efibootmgr

If the command failed, you can create a EFI boot entry manually using efibootmgr:

where is the EFI system partition.

Manual entry using bcdedit from Windows

If for any reason you need to create an EFI boot entry from Windows, you can use the following commands from an Administrator prompt:

Replace with the id returned by the first command. You can also set it as the default entry using

Menu does not appear after Windows upgrade

See UEFI#Windows changes boot order.

See also

You may need a serial number and product key to activate some Autodesk software. 

Note: If you are on subscription, you may no longer need to enter a serial number or product key; you just need to sign in. Serial numbers are never required for launching products with network licenses.

Physical Media

Serial Numbers do not appear on software packaging for Autodesk software versions 2014 and newer. Serial numbers for these versions are emailed to you after you place an order or can be found in Autodesk Account.

If you have physical media (a DVD or USB key) for a 2013 or earlier product, your serial number and product key will be printed on the label of the product packaging.

 
Example of label from 2011 version. Format is similar for 2010 - 2013 product releases.

Return to Top

Older product keys

If you can't find the product key for older versions of Autodesk software (2013 and later), you may be able to find it in a text file in the installation folder.

To determine if your product key is available in your installation folder:

1. Using your installation media, (USB key, DVD, download folder, etc.) navigate to the folder that contains the setup.exe file for your Autodesk product.
2. In that folder, look for a file named MID.txt, MID01.txt, MID02.txt or some variation on that name.
3. Open this file in Notepad and verify that the product name is correct.
4. The first five characters of the part number should also be the product key for that product.

Example:

MID: Autodesk_Design_Suite_Ultimate_2012_64bit_SWL_ENU_C009_EXE1
Product Name: Autodesk Design Suite Ultimate 2012
Platform: Windows XP/Vista/Win7
Media: ESD
Part Number: 769D1-05Y001-P503E, 769D1-05Y001-P504E

Return to Top