f2605e9281
The troubleshooting kernel command line option nomodeset unfortunately changes the way framebuffer interactions work with graphics devices which in some cases can result in kernel memory to be used for graphics updates. When this happens on some specific hardware common in rack mount servers with baseboard management controllers, this can cause the memory bus to become locked for a brief time while the graphics update is occuring. This locked memory bus means disk IO can become blocked, and network cards can overflow their buffers resulting in packet loss on top of the latency incurred by the graphics update executing. As such, we've removed the nomodeset option from default usage and added a note describing its removal to the documentation along with a release note. Change-Id: I9084d88c3ec6f13bd64b8707892758fa87dd7f86
4.8 KiB
Boot interfaces
The boot interface manages booting of both the deploy ramdisk and the user instances on the bare metal node.
The PXE boot interface is generic and works
with all hardware that supports booting from network. Alternatively,
several vendors provide virtual media implementations of the
boot interface. They work by pushing an ISO image to the node's management
controller, and do not require either PXE or iPXE. Check your driver
documentation at ../drivers for details.
PXE boot
The pxe and ipxe boot interfaces uses PXE
or iPXE accordingly to
deliver the target kernel/ramdisk pair. PXE uses relatively slow and
unreliable TFTP protocol for transfer, while iPXE uses HTTP. The
downside of iPXE is that it's less common, and usually requires
bootstrapping using PXE first.
The pxe and ipxe boot interfaces work by
preparing a PXE/iPXE environment for a node on the file system, then
instructing the DHCP provider (for example, the Networking service) to
boot the node from it. See direct-deploy-example for a better understanding of
the whole deployment process.
Note
Both PXE and iPXE are configured differently, when UEFI boot is used instead of conventional BIOS boot. This is particularly important for CPU architectures that do not have BIOS support at all.
The ipxe boot interface is used by default for many
hardware types, including ipmi. Some hardware types,
notably ilo and irmc have their specific
implementations of the PXE boot interface.
Additional configuration is required for this boot interface - see
/install/configure-pxe
for details.
Kernel parameters
If you need to pass additional kernel parameters to the deployment/cleaning ramdisk (for example, to configure serial console), use the following configuration option:
[pxe]
kernel_append_params = nofb vga=normalNote
The option was called pxe_append_params before the Xena
cycle.
Per-node and per-instance overrides are also possible, for example:
baremetal node set node-0 \
--driver-info kernel_append_params="nofb vga=normal"
baremetal node set node-0 \
--instance-info kernel_append_params="nofb vga=normal"Starting with the Zed cycle, you can combine the parameters from the
configuration and from the node using the special %default%
syntax:
baremetal node set node-0 \
--driver-info kernel_append_params="%default% console=ttyS0,115200n8"Together with the configuration above, the following parameters will be appended to the kernel command line:
nofb vga=normal console=ttyS0,115200n8Note
Ironic does not do any de-duplication of the resulting kernel parameters. Both kernel itself and dracut seem to give priority to the last instance of the same parameter.
Warning
Previously our documentation listed the Linux kernel parameter
nomodeset as an option. This option is intended for
troubleshooting, and can greatly degrade performance with Matrox/Aspeed
BMC Graphics controllers which is very commonly used on physical
servers. The performance degredation can greatly reduce IO capacity upon
every console graphics update being written to the screen.
Common options
Enable persistent boot device for deploy/clean operation
For (i)PXE booting, Ironic uses non-persistent boot order changes for clean/deploy by default. For some drivers, persistent changes are far more costly than non-persisent ones, so this approach can bring a performance benefit.
In order to control this behavior, however, Ironic provides the
force_persistent_boot_device flag in the node's
driver_info. It allows the values Default
(make all changes but the last one upon deployment non-persistent),
Always (make all changes persistent), and
Never (make all boot order changes non-persistent). For
example in order to have only persistent changes one would need to set
something like:
$ openstack baremetal node set --driver-info force_persistent_boot_device='Always' <node>Note
It is recommended to check if the node's state has not changed as there is no way of locking the node between these commands.
Note
The values 'True'/'False' for the option 'force_persistent_boot_device' in the node's driver info for the (i)PXE drivers are deprecated and support for them may be removed in a future release. The former default value 'False' is replaced by the new value 'Default', the value 'True' is replaced by 'Always'.