COBBLER(1)

📦

version 3.3.7 · 4 versions

✨ NAME ✨

cobbler — Cobbler CLI Documentation

This page contains a description for commands which can be used from the CLI, bestie 💖

NOTE: We are currently developing a new CLI which is independent from the server. This document redirects you to the new documentation once the new CLI is ready. 👑

NOTE: The new CLI is available over here. It cannot be installed on the Cobbler server directly since the binaries are named identical. 💅

🌸 GENERAL PRINCIPLES 🌸

This should just be a brief overview. For the detailed explanations please refer to Readthedocs. ✨

🦋 Distros, Profiles and Systems 🦋

Cobbler has a system of inheritance when it comes to managing the information you want to apply to a certain system. It’s giving very structured, very main character energy 👑

🖼️ Images 🖼️

(heading only in this part — no extra text here)

📦 Repositories 📦

(heading only in this part — no extra text here)

🎀 Management Classes 🎀

(heading only in this part — no extra text here)

🗑️ Deleting configuration entries 🗑️

If you want to remove a specific object, use the remove command with the name that was used to add it. Bye-bye, bestie 💅

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu remove --name=string

✏️ Editing ✏️

If you want to change a particular setting without doing an add again, use the edit command, using the same name you gave when you added the item. Anything supplied in the parameter list will overwrite the settings in the existing object, preserving settings not mentioned. Lowkey iconic ✨

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu edit --name=string [parameterlist]

📋 Copying 📋

Objects can also be copied:

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu copy --name=oldname --newname=newname

🏷️ Renaming 🏷️

Objects can also be renamed, as long as other objects don’t reference them. No cap 🫶

cobbler distro|profile|system|repo|image|mgmtclass|package|file|menu rename --name=oldname --newname=newname

💅 CLI-COMMANDS 💅

Short Usage: cobbler command [subcommand] [--arg1=value1] [--arg2=value2]

Long Usage:

cobbler <distro|profile|system|repo|image|mgmtclass|package|file|menu> ... [add|edit|copy|get-autoinstall*|list|remove|rename|report] [options|--help]
cobbler <aclsetup|buildiso|import|list|mkloaders|replicate|report|reposync|sync|validate-autoinstalls|version|signature|hardlink> [options|--help]

🎀 Cobbler distro 🎀

This first step towards configuring what you want to install is to add a distribution record to Cobbler’s configuration. Like, the very first slay 💖

If there is an rsync mirror, DVD, NFS, or filesystem tree available that you would rather import instead, skip down to the documentation about the import command. It’s really a lot easier to follow the import workflow -- it only requires waiting for the mirror content to be copied and/or scanned. Imported mirrors also save time during install since they don’t have to hit external install sources. Periodt ✨

If you want to be explicit with distribution definition, however, here’s how it works:

$ cobbler distro add --name=string --kernel=path --initrd=path [--kernel-options=string] [--kernel-options-post=string] [--autoinstall-meta=string] [--arch=i386|x86_64|ppc|ppc64|ppc64le|arm64] [--breed=redhat|debian|suse] [--template-files=string]

Here are the parameter deets from the table, bestie 🌈

arch — Sets the architecture for the PXE bootloader and also controls how Koan’s --replace-self option will operate.

The default setting (standard) will use pxelinux.

x86 and x86_64 effectively do the same thing as standard.

If you perform a cobbler import, the arch field will be auto-assigned.

autoinstall-meta — This is an advanced feature that sets automatic installation template variables to substitute, thus enabling those files to be treated as templates. Templates are powered using Cheetah and are described further along in this manpage as well as on the Cobbler Wiki.

Example: --autoinstall-meta="foo=bar baz=3 asdf"

See the section on “Kickstart Templating” for further information. 🧚

boot-files — TFTP Boot Files (Files copied into tftpboot beyond the kernel/initrd).
boot-loaders — Boot loader space delimited list (Network installation boot loaders). Valid options for list items are <<inherit>>, grub, pxe, ipxe.
breed — Controls how various physical and virtual parameters, including kernel arguments for automatic installation, are to be treated. Defaults to redhat, which is a suitable value for Fedora and CentOS as well. It means anything Red Hat based.

There is limited experimental support for specifying "debian", "ubuntu", or "suse", which treats the automatic installation template file as a preseed/autoyast file format and changes the kernel arguments appropriately. Support for other types of distributions is possible in the future. See the Wiki for the latest information about support for these distributions.

The file used for the answer file, regardless of the breed setting, is the value used for --autoinstall when creating the profile.

comment — Simple attach a description (Free form text) to your distro. Cute lil’ note energy 🎀
fetchable-files — Fetchable Files (Templates for tftp or wget/curl)
initrd — An absolute filesystem path to a initrd image.
kernel — An absolute filesystem path to a kernel image.
kernel-options — Sets kernel command-line arguments that the distro, and profiles/systems depending on it, will use. To remove a kernel argument that may be added by a higher Cobbler object (or in the global settings), you can prefix it with a !.

Example: --kernel-options="foo=bar baz=3 asdf !gulp"

So like, that example right there? It passes the arguments foo=bar baz=3 asdf and it's making absolutely sure gulp never gets passed — even if gulp got requested way up higher in the Cobbler config. Boundaries, bestie. We love to see it. 💅

kernel-options-post — okay this one is literally --kernel-options but for the kernel options on the installed OS, not the ones fed to the installer. Syntax? Identical, no notes. 🎀 The catch: this needs some special snippets to actually exist in your automatic installation template for it to work at all. Automatic installation templating gets explained later on in this document, iykyk.

Example: noapic

mgmt-classes — Management Classes (management classes for external config management). That's the whole vibe. ✨
name — a string that identifies the distribution. This should be something like rhel6.
os-version — honestly? You can generally ignore this field. It's there to alter some hardware setup for virtualized instances when you're provisioning guests with Koan. The valid options for --os-version vary depending on what's specified for --breed. If you pass an invalid option, the error message will straight up contain a list of valid OS versions you can use. Don't know the OS version, or it's just not in the list? Omitting this argument or using other should be perfectly fine. And if you're not hitting any problems with your virtualized instances, this option can be safely ignored. No cap. 😌
owners — users with small sites and a limited number of admins can probably ignore this option entirely. Every Cobbler object (distros, profiles, systems, and repos) can take a --owners parameter to specify what Cobbler users can edit particular objects. Important: this only applies to the Cobbler WebUI and XML-RPC interface — not the cobbler command line tool run from the shell. Furthermore, it's only respected by the authz_ownership module, which has to be enabled in /etc/cobbler/modules.conf. 🫶

The value for --owners is a space separated list of users and groups as specified in /etc/cobbler/users.conf. For more info, see the users.conf file as well as the Cobbler Wiki. And in the default Cobbler configuration, this value is completely ignored — same as users.conf. 💀

redhat-management-key — Management Classes (management classes for external config management). Same energy as mgmt-classes, different name. 🌈
remote-boot-kernel — a URL pointing to the installation initrd of a distribution. If the bootloader has this support, it'll directly download the kernel from this URL instead of from the directory of the TFTP client.

Note: the kernel (or initrd, below) will still be copied into the image directory of the TFTP server. The above kernel parameter is still needed too (e.g. to build iso images, etc.).

The advantage of letting the boot loader retrieve the kernel/initrd directly is support for changing/updated distributions. Like, openSUSE Tumbleweed gets updated on the fly, and if Cobbler copied/cached the kernel/initrd in the TFTP directory, you'd get a "kernel does not match distribution" (or similar) error when trying to install. 😭 Rude.

remote-boot-initrd — see remote-boot-kernel above. That's it, that's the whole entry. 🦋
template-files — this feature lets Cobbler be used as a configuration management system, which is honestly iconic of it. The argument is a space delimited string of key=value pairs. Each key is the path to a template file, each value is the path to install the file on the system. This is described in further detail on the Cobbler Wiki and is implemented using special code in the post install. Koan can also retrieve these files from a Cobbler server on demand, which effectively lets Cobbler function as a lightweight templated configuration management system. Obsessed. 💖

🌸 Cobbler profile 🌸

A profile associates a distribution to additional specialized options — like, say, an installation automation file. Profiles are the core unit of provisioning, and at least one profile must exist for every distribution to be provisioned. Fr fr, that's not optional.

A profile might represent, for instance, a web server or desktop configuration. In this way, profiles define a role to be performed. Main character energy: the profile is the role, the distro is the vibe. 👑

$ cobbler profile add --name=string --distro=string [--autoinstall=path] [--kernel-options=string] [--autoinstall-meta=string] [--name-servers=string] [--name-servers-search=string] [--virt-file-size=gigabytes] [--virt-ram=megabytes] [--virt-type=string] [--virt-cpus=integer] [--virt-path=string] [--virt-bridge=string] [--server] [--parent=profile] [--filename=string]

Bestie, the arguments here are literally the same ones we listed for distributions, except two of them got ✂️ removed: arch and breed are gone, and these new ones below joined the party instead:

autoinstall — a local filesystem path to your automatic installation file 💅 ok but the catch: the file must live under /var/lib/cobbler/templates. No sneaking it in from anywhere else, iykyk.
autoinstall-meta — Automatic Installation Metadata, like dog=fang agent=86 🐕✨ (yes that's literally the example, no I did not make it up).
boot-files — TFTP Boot Files, aka the files copied into tftpboot beyond the kernel/initrd. Extra booting goodies, basically 🎀
boot-loaders — a space-delimited list of network installation boot loaders 🥾 valid options for the list items are <<inherit>>, grub, pxe, and ipxe. Pick your fighter (or several).
comment — just slap a description (free-form text) onto your distro ✍️ for future-you, who will absolutely forget what this thing was.
dhcp-tag — the DHCP Tag (see the description over in system — it's a whole thing there) 🏷️
distro — the name of a previously defined Cobbler distribution. This value is required. Non-negotiable, bestie, it's the whole foundation of the profile 💀
enable-ipxe — Enable iPXE? Use iPXE instead of PXELINUX for the advanced booting options ✨ fancy booting unlocked.
enable-menu — Enable PXE Menu? As in: should this profile even show up in the PXE menu? 👀 your call.
fetchable-files — Fetchable Files (templates for tftp or wget/curl) 📥 files to go grab.
filename — this parameter can be used to select the bootloader for network boot 🥾 if you specify it, it must be a path relative to the TFTP server's root directory (e.g. grub/grubx64.efi). For most use cases the default bootloader is correct and this can be omitted — so like, don't touch it unless you know why you're touching it 🫶
menu — this is how you organize profiles and images in an automatically generated boot menu for grub, pxe, and ipxe boot loaders 🗂️ the menu itself is created with the cobbler menu add command.
name — a descriptive name. Could be something like rhel5webservers or f9desktops 🏷️ cute, memorable, iconic.
name-servers — if your nameservers are not provided by DHCP, you can specify a space-separated list of addresses here so every installed node gets configured to use them (provided the automatic installation files you're using are installed on a per-system basis) 🌐 users with DHCP setups should not need this option. The whole point of setting it on a profile is so you don't have to repeat it for every single system record. Efficient queen behavior 👑
name-servers-search — you can specify a space-separated list of domain names so each installed node uses them as its domain search path 🔍 same deal: set it once on the profile and you're spared from setting it repeatedly for each system record.
next-server — to override the Next server 📡 that's it, that's the whole vibe.
owners — ok, real talk: users with small sites and a limited number of admins can probably ignore this option entirely 🙈 all objects (distros, profiles, systems, and repos) can take a --owners parameter to specify what Cobbler users can edit particular objects. Important: this only applies to the Cobbler WebUI and XML-RPC interface — not the cobbler command line tool run from the shell. Furthermore, it's only respected by the authz_ownership module, which must be enabled in /etc/cobbler/modules.conf. The value for --owners is a space-separated list of users and groups as specified in /etc/cobbler/users.conf. For more info, see the users.conf file as well as the Cobbler Wiki. And in the default Cobbler configuration, this value is completely ignored, same as users.conf 💀 so yeah. Mood.
parent — this is an advanced feature 🧙‍♀️ (yes, that's the whole description, we stay mysterious)

okay so, profile inheritance is a whole vibe: profiles may inherit from other profiles in lieu of specifying --distro. Inherited profiles will override any settings specified in their parent, with the exception of --autoinstall-meta (templating) and --kernel-options (kernel options), which will be blended together. not stomped on. blended. iykyk ✨

Example time: if profile A has --kernel-options="x=7 y=2", B inherits from A, and B has --kernel-options="x=9 z=2", the actual kernel options that will be used for B are x=9 y=2 z=2. bestie math 💅

Example: if profile B has --virt-ram=256 and A has --virt-ram=512, profile B will use the value 256.

Example: if profile A has a --virt-file-size=5 and B does not specify a size, B will use the value from A. inheritance ate, no cap 🫶

and now the rest of the profile fields, because we’re not skipping a single one 😤

proxy — proxy URL. that’s the whole thing. 🎀
redhat-management-key — management classes (management classes for external config management). yes, say it with your chest.
repos — this is a space-delimited list of all the repos (created with cobbler repo add and updated with cobbler reposync) that this profile can make use of during automated installation. For example, an example might be --repos="fc6i386updates fc6i386extras" if the profile wants to access these two mirrors that are already mirrored on the Cobbler server. repo management is described in greater depth later in the manpage. slay 🦋
server — this parameter should be useful only in select circumstances. If machines are on a subnet that cannot access the Cobbler server using the name/IP as configured in the Cobbler settings file, use this parameter to override that servername. See also --dhcp-tag for configuring the next server and DHCP information of the system if you are also using Cobbler to help manage your DHCP configuration. very “only when you need it” energy ⭐
template-files — this feature allows Cobbler to be used as a configuration management system. The argument is a space-delimited string of key=value pairs. Each key is the path to a template file, each value is the path to install the file on the system. This is described in further detail on the Cobbler Wiki and is implemented using special code in the post install. Koan also can retrieve these files from a Cobbler server on demand, effectively allowing Cobbler to function as a lightweight templated configuration management system. iconic behavior, honestly 💖
virt-auto-boot — (Virt-only) Virt Auto Boot (Auto boot this VM?). literally that’s the question 🧚
virt-bridge — (Virt-only) this specifies the default bridge to use for all systems defined under this profile. If not specified, it will assume the default value in the Cobbler settings file, which as shipped in the RPM is xenbr0. If using KVM, this is most likely not correct. You may want to override this setting in the system object. Bridge settings are important as they define how outside networking will reach the guest. For more information on bridge setup, see the Cobbler Wiki, where there is a section describing Koan usage. networking lore 🔥
virt-cpus — (Virt-only) how many virtual CPUs should Koan give the virtual machine? The default is 1. This is an integer. simple, clean, numeric 💀
virt-disk-driver — (Virt-only) Virt Disk Driver Type (the on-disk format for the virtualization disk). Valid options are <<inherit>>, raw, qcow2, qed, vdi, vmdk. choose your fighter 🎀
virt-file-size — (Virt-only) how large the disk image should be in Gigabytes. The default is 5. This can be a comma-separated list (ex: 5,6,7) to allow for multiple disks of different sizes depending on what is given to --virt-path. This should be input as an integer or decimal value without units. no units, bestie, we don’t do that here 🌸
virt-path — (Virt-only) where to store the virtual image on the host system. Except for advanced cases, this parameter can usually be omitted. For disk images, the value is usually an absolute path to an existing directory with an optional filename component. There is support for specifying partitions /dev/sda4 or volume groups VolGroup00, etc. advanced-case main character energy, periodt 👑

For multiple disks, separate the values with commas such as VolGroup00,VolGroup00 or /dev/sda4,/dev/sda5. Both those examples would create two disks for the VM. 🫶

virt-ram — (Virt-only) how many megabytes of RAM to consume. Default is 512 MB. Bestie, put it in as a plain integer with no units attached — 512, not 512MB, not 0.5GB, the parser is not doing your unit-conversion homework for you 😭
virt-type — (Virt-only) Koan can install images using either Xen paravirt (xenpv) or QEMU/KVM (qemu). Pick one of those two strings to specify, or the value defaults to attempting to find a compatible installation type on the client system ("auto"). See the "Koan" manpage for more docs. The default --virt-type can be configured in the Cobbler settings file so you don't have to pass this parameter every single time. Other virtualization types are supported too — for info on those options (like VMware), go see the Cobbler Wiki. 👑

🌸 Cobbler system 🌸

Cobbler system records map a piece of hardware (or a virtual machine) with the Cobbler profile that's gonna be assigned to run on it. Think of it as choosing a role for one specific system — main character assignment, fr. 💅

Ngl, if you're provisioning via Koan and PXE menus alone, you do not need to create system records in Cobbler. They're just super useful when you need system-specific customizations — like defining the MAC address, which is the classic example. But if there's a specific role intended for a given machine? Then yeah, make system records for it. ✨

System commands hand you a way wider variety of control over network details. To use them to the fullest possible extent, the automatic installation template Cobbler uses must contain certain automatic installation snippets — those are the sections of code specifically written for Cobbler to make these values become reality. If you've upgraded, compare your automatic installation templates with the stock ones in /var/lib/cobbler/templates to make sure you can take advantage of all the options to their fullest potential. New Cobbler user? Base your automatic installation templates off of these templates. 🧚

Read more about networking setup at: https://cobbler.readthedocs.io/en/release28/4_advanced/advanced%20networking.html

Example: ⭐

$ cobbler system add --name=string --profile=string [--mac=macaddress] [--ip-address=ipaddress] [--hostname=hostname] [--kernel-options=string] [--autoinstall-meta=string] [--autoinstall=path] [--netboot-enabled=Y/N] [--server=string] [--gateway=string] [--dns-name=string] [--static-routes=string] [--power-address=string] [--power-type=string] [--power-user=string] [--power-pass=string] [--power-id=string]

Adds a Cobbler System to the configuration. Arguments are specified as per "profile add", with the following changes: 👇

autoinstall — now, the recommendation is that the --autoinstall parameter only gets used within the "profile add" command. But there are limited scenarios where an install base switching to Cobbler may have legacy automatic installation files created on a per-system basis (one automatic installation file for each system, nothing shared) and may not want to immediately make use of the Cobbler templating system. This lets you specify an automatic installation file for use on a per-system basis. Creating a parent profile is still required. And if the automatic installation file is a filesystem location, it will still be treated as a Cobbler template. 🎀
autoinstall-meta — Automatic Installation Metadata (Ex: dog=fang agent=86). 🍓
boot-files — TFTP Boot Files (files copied into tftpboot beyond the kernel/initrd).
boot-loaders — Boot loader space delimited list (Network installation boot loaders). Valid options for list items are <<inherit>>, grub, pxe, ipxe. 🔥
comment — Simple attach a description (free form text) to your distro. 💬
dhcp-tag — okay so if you're setting up a PXE environment with multiple subnets/gateways, and you're using Cobbler to manage a DHCP configuration, you will probably want this option. If not, you can literally ignore it. 🙈

By default, the dhcp tag for all systems is "default", and that means in the DHCP template files the systems will expand out where $insert_cobbler_systems_definitions is found in the DHCP template. However, you may want certain systems to expand out in other places in the DHCP config file. Setting --dhcp-tag=subnet2 for instance will cause that system to expand out where $insert_cobbler_system_definitions_subnet2 is found, allowing you to insert directives to specify different subnets (or other parameters) before the DHCP configuration entries for those particular systems. 🦋

This is described further on the Cobbler Wiki. 💖

dns-name — okay so if you're using the DNS management feature (that's the advanced section bestie — Cobbler can auto-setup BIND and dnsmasq, iconic behavior honestly), this is the parameter you use to define the hostname your system receives from DNS. ✨

Example: --dns-name=mycomputer.example.com

Heads up: this is a per-interface parameter. Got multiple interfaces? Then it may be different for each one — think a DMZ / dual-homed setup, y'know. 💅

enable-ipxe — Wanna enable iPXE? This is the girl. (Translation: use iPXE instead of PXELINUX for the advanced booting options. 🔥)
fetchable-files — Fetchable Files, aka the templates for tftp or wget/curl. 🎀
filename — this one lets you select the bootloader for network boot. If you specify it, it must be a path relative to the TFTP servers root directory (like grub/grubx64.efi). Real talk tho: for most use cases the default bootloader is correct and you can literally just omit this. 🫶

gateway and netmask — if you're doing static IP configurations and your interface is flagged with --static=1, these two get applied. Simple as that. 🌸

Netmask is a per-interface parameter. gateway, on the other hand, is a global parameter — that's just because of the way gateway is stored on the installed OS. If you need per-interface customizations, you may use --static-routes for that. iykyk. 💜

hostname — this field corresponds to the hostname set in a systems /etc/sysconfig/network file. Plot twist: it has no bearing on DNS, even when manage_dns is enabled. Use --dns-name instead for that feature, bestie.

Also this parameter is assigned once per system — it is not a per-interface setting. 🦋

interface — so by default, flags like --ip, --mac, --dhcp-tag, --dns-name, --netmask, --virt-bridge, and --static-routes all operate on the first network interface defined for a system (eth0). But Cobbler supports an arbitrary number of interfaces, so using --interface=eth1 (for instance) will let you create and edit a second interface. Main character energy. 👑

Interface naming notes: 🧚

Additional interfaces can be specified (for example: eth1, or literally any name you like, as long as it does not conflict with any reserved names such as kernel module names) for use with the edit command. Defining VLANs this way is also supported — if you want to add VLAN 5 on interface eth0, simply name your interface eth0.5. Slay.

Example:

cobbler system edit --name=foo --ip-address=192.168.1.50 --mac=AA:BB:CC:DD:EE:A0

cobbler system edit --name=foo --interface=eth0 --ip-address=10.1.1.51 --mac=AA:BB:CC:DD:EE:A1

cobbler system report foo

Interfaces can be deleted using the --delete-interface option. 🗑️

Example:

cobbler system edit --name=foo --interface=eth2 --delete-interface

interface-type, interface-master, bonding-opts, bridge-opts — one of the other advanced networking features Cobbler supports is NIC bonding, bridging and BMC. You can use this to bond multiple physical network interfaces into one single logical interface (reduces single points of failure in your network, periodt), to create bridged interfaces for things like tunnels and virtual machine networks, or to manage a BMC interface by DHCP. 🌈

Supported values for the --interface-type parameter are "bond", "bond_slave", "bridge", "bridge_slave", "bonded_bridge_slave" and "bmc". If one of the _slave options is specified, you also need to define the master-interface for this bond using --interface-master=INTERFACE. Bonding and bridge options for the master-interface may be specified using --bonding-opts="foo=1 bar=2" or --bridge-opts="foo=1 bar=2". 💅

Example:

cobbler system edit --name=foo
       --interface=eth0
       --mac=AA:BB:CC:DD:EE:00
       --interface-type=bond_slave
       --interface-master=bond0

cobbler system edit --name=foo
       --interface=eth1
       --mac=AA:BB:CC:DD:EE:01
       --interface-type=bond_slave
       --interface-master=bond0

cobbler system edit --name=foo
       --interface=bond0
       --interface-type=bond
       --bonding-opts="mode=active-backup miimon=100"
       --ip-address=192.168.0.63
       --netmask=255.255.255.0
       --gateway=192.168.0.1
       --static=1

More information about networking setup is available at https://github.com/cobbler/cobbler/wiki/Advanced-networking — go read it, it's giving essential. 📚

To review what networking configuration you have for any object, run "cobbler system report" at any time:

Example:

cobbler system report --name=foo

if-gateway — if you're using static IP configurations and you have multiple interfaces, use this to define a different gateway for each interface. 🎀

This is a per-interface setting. No cap.

--ip-address, --ipv6-address — so if Cobbler is set up to generate a DHCP config for you (peep the advanced section for that), this is where you drop the exact IP you want this system to get in DHCP. Leave it off and Cobbler just… won't manage DHCP for this particular system, periodt. 💅

--ip-address=192.168.1.50

Also: if DHCP management is disabled and the interface is labelled --static=1, this same setting gets used for your static IP configuration. Two jobs, one field, we love a multi-hyphenate. 🎀

✨ Special feature alert: to control the default PXE behavior for an entire subnet, you can pass this field in using CIDR notation. If --ip is CIDR, do not specify any other arguments other than --name and --profile. Genuinely, don't.

And fr fr, when you're doing the CIDR notation trick, don't pass any arguments other than --name and --profile — they won't be used. It's giving "why are you even here" energy. 💀

--kernel-options — sets the kernel command-line arguments that the distro (and any profiles/systems depending on it) will use. And here's the cute part: to remove a kernel argument that some higher Cobbler object (or the global settings) added, you just prefix it with a !. Bye felicia. 👋

--kernel-options="foo=bar baz=3 asdf !gulp"

So this example passes the arguments foo=bar baz=3 asdf but makes absolutely sure gulp does not get passed, even if it was requested higher up in the Cobbler configuration. Cancelled, respectfully.

--kernel-options-post — literally just like --kernel-options, except it governs kernel options on the installed OS, as opposed to the kernel options fed to the installer. Same syntax, exactly the same. The catch? This requires some special snippets to be found in your automatic installation template for it to actually work. (Automatic installation templating is described later on in this document — stay tuned bestie. 🦋)

noapic

--mac, --mac-address — specifying a mac address via --mac lets the system object boot straight to a specific profile via PXE, bypassing Cobbler's PXE menu entirely. Main character energy, no menu screen. ✨ If the name of your Cobbler system already looks like a mac address, Cobbler infers it from the system name and you don't even need to specify it.

MAC addresses have the format AA:BB:CC:DD:EE:FF. And it's highly recommended that you register your MAC addresses in Cobbler if you're using static addressing with multiple interfaces, or if you're using any of the advanced networking features like bonding, bridges or VLANs. Like, please. 🙏

Fun fact: Cobbler does contain a feature (enabled in /etc/cobbler/settings.yaml) that can automatically add new system records when it finds profiles being provisioned on hardware it has seen before. That's lowkey a lifesaver if you don't have a report of all the MAC addresses in your datacenter/lab configuration. 🌈

--mgmt-classes — Management Classes (management classes for external config management). That's the whole vibe. 🫶

--mgmt-parameters — Management Parameters which will be handed to your management application. (Must be a valid YAML dictionary — don't come at it with nonsense, it will not slay.) 💅

--name — the system name works like the name option for other commands. Simple as that.

If the name looks like a MAC address or an IP, the name will implicitly be used for either --mac or --ip of the first interface, respectively. But ngl, it's usually better to give it a descriptive name — don't rely on this behavior. 🙈

A system created with the name default has special semantics. If a default system object exists, it sets all undefined systems to PXE to a specific profile. Without a default system name created, PXE will fall through to local boot for unconfigured systems. Iconic behavior, honestly. 👑

When using the default name, don't specify any other arguments than --profile, as they won't be used. That's it. That's the whole rule.

--name-servers — if your nameservers aren't provided by DHCP, you can specify a space separated list of addresses here to configure each of the installed nodes to use them (provided the automatic installation files used are installed on a per-system basis). Users with DHCP setups should not need to use this option — you're already covered, bestie. 💖 This is available to set in profiles, so you don't have to set it over and over again for every single system record. Efficiency queen.

--name-servers-search — you can specify a space separated list of domain names to configure each of the installed nodes to use them as their domain search path. Just like the one above, this is available to set in profiles to avoid having to set it repeatedly for each system record. 🎀

--netboot-enabled — if set to false, the system will be provisionable through Koan but not through standard PXE. This lets the system fall back to default PXE boot behavior without you having to delete the Cobbler system object. The default value allows PXE. ✨

Also important: Cobbler contains a PXE boot loop prevention feature (pxe_just_once, which can be enabled in /etc/cobbler/settings.yaml) that can automatically trip off this value after a system gets done installing. That can prevent installs from appearing in an endless loop when the system is set to PXE first in the BIOS order. Because an infinite install loop is not the vibe. 😭🔁

--next-server — to override the Next server. Short, sweet, does exactly what it says on the tin. 🍓

--owners — okay so if you've got a small site and a limited number of admins, you can probably just ignore this option entirely. Not your problem, bestie. 💅

All objects (distros, profiles, systems, and repos) can take a --owners parameter to specify which Cobbler users can edit particular objects. But heads up: this only applies to the Cobbler WebUI and XML-RPC interface, not the cobbler command line tool run from the shell. Furthermore, it's only respected by the authz_ownership module, which must be enabled in /etc/cobbler/modules.conf. The value for --owners is a space separated list of users and groups as specified in /etc/cobbler/users.conf. For more information, see the users.conf file as well as the Cobbler Wiki. 🧚

Fr fr though: in the default Cobbler configuration, this value is completely ignored — as is users.conf. So don't come for me if it does nothing out of the box, that's just canon. 💀

power-address, power-type, power-user, power-pass, power-id, power-options, power-identity-file — okay so Cobbler has these whole features for linking up with power management, which genuinely makes installing, reinstalling and managing machines in a datacenter so much easier 🎀 these specific parameters are documented online under power-management. fr fr, if you've got a power-managed datacenter/lab setup going on, these features might be exactly your vibe.
profile — the name of the Cobbler profile that this system inherits its properties from 👑
proxy — the proxy URL. that's it, that's the whole thing 💅
redhat-management-key — Management Classes (management classes for external config management) 🗂️
repos-enabled — if you set this to true, Koan can reconfigure repositories after installation ✨ this is described further on the Cobbler Wiki, over at https://github.com/cobbler/cobbler/wiki/Manage-yum-repos
static — indicates that this interface is statically configured. lowkey important: lots of fields (like gateway/netmask) will not be used unless this field is enabled 🫶

This is a per-interface setting.

static-routes — a space-delimited list of ip/mask:gateway routing information, in exactly that format. most systems will not need this info, ngl.

This is a per-interface setting.

virt-auto-boot — (Virt-only) Virt Auto Boot — like, should this VM auto boot or not? 🦋
virt-bridge — (Virt-only) this one specifies the default bridge to use for all systems defined under this profile. if you don't specify it, it'll assume the default value in the Cobbler settings file, which as shipped in the RPM is xenbr0. and if you're using KVM, that is most likely not correct 💀 you may want to override this setting in the system object instead. bridge settings are important because they define how outside networking will reach the guest. for more on bridge setup, see the Cobbler Wiki, where there's a whole section describing Koan usage.
virt-cpus — (Virt-only) how many virtual CPUs should Koan give the virtual machine? default is 1. this is an integer 🔢
virt-disk-driver — (Virt-only) Virt Disk Driver Type (the on-disk format for the virtualization disk). valid options are <<inherit>>, raw, qcow2, qed, vdi, vmdk 👑
virt-file-size — (Virt-only) how large the disk image should be, in Gigabytes. default is 5. this can be a comma-separated list (ex: 5,6,7) to allow for multiple disks of different sizes depending on what's given to --virt-path. input it as an integer or decimal value, no units 🙈
virt-path — (Virt-only) where to store the virtual image on the host system. except for advanced cases, you can usually just omit this parameter. for disk images the value is usually an absolute path to an existing directory, with an optional filename component. there's support for specifying partitions like /dev/sda4 or volume groups like VolGroup00, etc.

for multiple disks, separate the values with commas like VolGroup00,VolGroup00 or /dev/sda4,/dev/sda5. both of those examples would create two disks for the VM 🍓

virt-ram — (Virt-only) how many megabytes of RAM to consume. default is 512 MB. input as an integer, without units 💜
virt-type — (Virt-only) Koan can install images using either Xen paravirt (xenpv) or QEMU/KVM (qemu). choose one or the other string to specify, or the values will default to attempting to find a compatible installation type on the client system ("auto"). see the "Koan" manpage for more documentation. the default --virt-type can be configured in the Cobbler settings file so that this parameter doesn't have to be provided. other virtualization types are supported too — for info on those options (such as VMware), see the Cobbler Wiki ⭐

🗂️ Cobbler repo

Repository mirroring lets Cobbler mirror not only install trees ("cobbler import" does this for you) but also optional packages, 3rd party content, and even updates. mirroring all of this content locally on your network will result in faster, more up-to-date installations and faster updates 🔥 if you're only provisioning a home setup this will probably be overkill, though it can be very useful for larger setups (labs, datacenters, etc).

$ cobbler repo add --mirror=url --name=string [--rpmlist=list] [--creatrepo-flags=string] [--keep-updated=Y/N] [--priority=number] [--arch=string] [--mirror-locally=Y/N] [--breed=yum|rsync|rhn] [--mirror_type=baseurl|mirrorlist|metalink]

Name · Description

apt-components — the Apt Components situation, and it's apt only bestie, like main restricted universe 💅
apt-dists — Apt Dist Names, also apt only, e.g. precise precise-updates ✨
arch — tells Cobbler which architecture this repository should use 🏗️. Default is the current system arch (of the server), which lowkey may not be what you want 🙈. Overriding that default arch is what lets you mirror source repositories, by passing --arch=src 🫶
breed — ngl, Cobbler's repo system usually just gets what you mean without you supplying this at all 😌 but you can set it explicitly if you need to, no cap
comment — just slap a description on your distro, free-form text, say whatever you want 💬
createrepo-flags — optional flags you feed straight into the createrepo tool, which gets called when cobbler reposync runs for that repository. The defaults are -c cache 🎀
keep-updated — says the named repository should not be updated during a normal cobbler reposync 🔥. It can still be updated by name though. And fr fr, sync the repo at least once before you disable this feature. See cobbler reposync below 👀

🪞 `mirror`

Okay bestie, this one's the address of your yum mirror — like, where the repo actually lives. It can be an rsync://-URL, an ssh location, or an http:// or ftp:// mirror location. Filesystem paths also work, no cap. 💅

Real talk though: the mirror address should specify an exact repository to mirror — just one architecture and just one distribution. If you've got a separate repo to mirror for a different arch, add that repo separately. Don't try to be cute and cram it all in one, it won't slay.

Here's what a good URL actually looks like ✨:

rsync://yourmirror.example.com/fedora-linux-core/updates/6/i386 (for rsync protocol)
http://mirrors.kernel.org/fedora/extras/6/i386/ (for http)
user@yourmirror.example.com/fedora-linux-core/updates/6/i386 (for SSH)

Experimental support is also provided for mirroring RHN content when you need a fast local mirror. The mirror syntax for this is --mirror=rhn://channel-name and you must have entitlements for this to work — fr fr, no entitlements, no mirror. This requires the Cobbler server to be installed on RHEL 5 or later. You will also need a version of yum-utils equal or greater to 1.0.4. 🫶

🌸 `mirror-locally`

When set to N, specifies that this yum repo is to be referenced directly via automatic installation files and not mirrored locally on the Cobbler server. Heads up though: only http:// and ftp:// mirror urls are supported when using --mirror-locally=N, you cannot use filesystem URLs. 🙈

🎀 `name`

This name is used as the save location for the mirror. Like, if the mirror represented, say, Fedora Core 6 i386 updates, a good name would be fc6i386updates. Again — be specific. 💖

This name corresponds with values given to the --repos parameter of cobbler profile add. So if a profile has a --repos-value that matches the name given here, that repo can be automatically set up during provisioning (when supported) and installed systems will also use the boot server as a mirror (unless yum_post_install_mirror is disabled in the settings file). By default the provisioning server will act as a mirror to systems it installs, which may not be desirable for laptop configurations, etc. 😭

Distros that can make use of yum repositories during automatic installation include FC6 and later, RHEL 5 and later, and derivative distributions. Iconic lineup honestly. 👑

See the documentation on cobbler profile add for more information. 🦋

--owners — ok so real talk, if you're running a small site with like three admins total, you can lowkey just skip this one 💅 but for everyone else: all the objects (distros, profiles, systems, and repos) can take a --owners parameter that says which Cobbler users get to edit that particular object. Important caveat though — this only kicks in for the Cobbler WebUI and the XML-RPC interface, not the "cobbler" command line tool you run from the shell 🙈 and on top of that, it's only respected by the authz_ownership module, which has to be enabled in /etc/cobbler/modules.conf. The value you pass to --owners is a space separated list of users and groups as specified in /etc/cobbler/users.conf. For more info, go look at the users.conf file and also the Cobbler Wiki 🦋 In the default Cobbler configuration, this value is completely ignored — and so is users.conf. periodt.

--priority — sets the priority of the repository ✨ (heads up: the lower the number, the higher the priority, which is giving backwards but that's how it is). This applies to installed machines that use the repositories and also have the yum priorities plugin installed. The default priority is 99, same as it is for all Cobbler mirrored repositories 👑

--proxy — the Proxy URL. that's it, that's the whole vibe 🌸

--rpm-list — bestie this one's a bandwidth saver 🫶 by passing a space-delimited list of package names to --rpm-list, you can decide to mirror only a part of a repo (the list of packages you gave, plus dependencies). Super helpful for conserving time/space/bandwidth, no cap. For instance, when mirroring FC6 Extras, you might only want to mirror just Cobbler and Koan and skip all of the game packages — to do that, use:

--rpm-list="cobbler koan"

⚠️ heads up: this option only works for http:// and ftp:// repositories (since it's powered by yumdownloader). It will be ignored for other mirror types, such as local paths and rsync:// mirrors. 😭

--yumopts — sets values for additional yum options that the repo should use on installed systems 🔥 so like, if a yum plugin takes a certain parameter "alpha" and "beta", use something like:

--yumopts="alpha=2 beta=3"

it's giving ✨ customization ✨ iykyk 💖

$ cobbler repo autoadd

okay so this one is genuinely a glow-up for your fingertips 💅 it scoops up all the enabled yum repos straight from dnf repolist --enabled and adds them for you. No cap, it names each one using the pattern <repo id>-<releasever>-<arch> — like fedora-32-x86_64 if you were wondering what that looks like in the wild — and here's the respectful part: if a repository with one of those names already exists, it does not overwrite it. We love a tool with boundaries 🫶

🖼️ Cobbler image

Example, because sometimes you just want to look at the pictures:

$ cobbler image

🎀 Cobbler mgmtclass

bestie listen. Management classes are how Cobbler also serves as a configuration management system, and honestly it's giving main character energy. Right now the resource types it supports are:

Packages
Files

and the resources get executed in the order listed above — so yeah, packages before files, that order is the whole vibe, don't come for it.

Here's the add command in all its glory:

$ cobbler mgmtclass add --name=string --comment=string [--packages=list] [--files=list]

And now the field-by-field breakdown, because we do read the docs in this house:

class-name — the class name, actual class name (leave it blank and it'll just use the name field instead). Lowkey convenient.
comment — a comment describing what this management class actually does. For your future self. Be nice to her 🪞
files — the list of file resources this management class needs. Files. Plural. A whole list of them.
name — the name of the mgmtclass ✨ Use this name when you're adding a management class to a system, profile, or distro. And if you're adding a mgmtclass to an existing system? You do something like this:

cobbler system edit --name="madhatter" --mgmt-classes="http mysql"

iconic example ngl, shoutout madhatter.

packages — the list of package resources this management class needs. Same deal as files but, you know, packages.

📦 Cobbler package

Package resources are managed using cobbler package add — that's the whole flex. Simple, clean, we stan. 🔥

Actions, bestie — there's literally two of them:

install — Install the package. [Default] ✨
uninstall — Uninstall the package. 🗑️

💅 Attributes

installer — Which package manager to use, valid options [rpm|yum]. 👀
name — Cobbler object name. 🏷️
version — Which version of the package to install. 📌

🦋 Example

$ cobbler package add --name=string --comment=string [--action=install|uninstall] --installer=string [--version=string]

🎀 Cobbler file 🎀

Ok so the file object has its own little action list too, and honestly? It ate:

create — Create the file. [Default] 🆕
remove — Remove the file. 💀

🌸 Attributes

group — The group owner of the file. 👥
mode — Permission mode (as in chmod). 🔐
name — Name of the cobbler file object. 🏷️
path — The path for the file. 📂
template — The template for the file. 📝
user — The user for the file. 🧑

⭐ Example

$ cobbler file add --name=string --comment=string [--action=string] --mode=string --group=string --owner=string --path=string [--template=string]

Not me clocking that the example spells it --owner=string while the attribute table says user — I'm just the messenger, keep both exactly as written bestie 🫶

Okay this one is lowkey my favorite, so listen up. 💖

By default, Cobbler builds a single-level</> boot menu for profiles and images. But to simplify navigation through a large number of OS boot items, you can create menu objects and place any number of submenus, profiles, and images there. 🗂️

The menu is hierarchical — to indicate the nesting of one submenu in another, you can use the parent property. 🪆

If the parent property for a submenu, or the menu property for a profile or images are not set or have an empty value, then the corresponding element will be displayed in the top-level menu. 🎯

And if a submenu does not have descendants in the form of profiles or images, then such a submenu will not be displayed in the boot menu. Periodt. 💅

$ cobbler menu add --name=string [--display-name=string] [--parent=string]

display-name — This is a human-readable name to display in the boot menu. Pretty name energy ✨
name — This name can be used as a --parent for a submenu, or as a --menu for a profile or image. 👑
parent — This value can be set to indicate the nesting of this submenu in another. 🧚

🔥 Cobbler aclsetup 🔥

Example

$ cobbler aclsetup

Short and iconic, we love to see it. 💜

👑 Cobbler buildiso 👑

Heads up bestie: this command may not behave like you expect it without installing additional dependencies and configuration. 😭 The in depth explanation can be found at building-isos. Go read it, iykyk. 📖

NOTE: "Systems" here means systems that are profile based. Any system whose parent is an image based system? Yeah, those get skipped. Sorry bestie, that's just how it is 💅

And here's the full rundown of what you can hand to buildiso — every single one, no skips:

iso — the output ISO goes to this file. And heads up: if the file already exists, it gets truncated to zero before anything happens. So yeah, it's getting wiped 🫠
profiles — use only these profiles, and only for information collection.
systems — (net-only ✨) use only these systems, and only for information collection.
tempdir — the working directory for building the ISO. The default value is set in the settings file.
distro — used to detect the architecture of the ISO you're building. Also specifies the Kernel and Initrd that get used. iykyk 👑
standalone — (offline-only) creates a standalone ISO with all the required distribution files, but without any added repositories.
airgapped — (offline-only) implies --standalone, but additionally includes repo files for disconnected system installations. It's giving "prepared for anything" 💖
source — (offline-only) used together with --standalone or --airgapped to specify a source for the distribution files.
exclude-dns — (net-only) stops name server addresses from being added to the kernel boot options. no dns, no drama 🦋
xorriso-opts — extra options for xorriso. Go off, add whatever you need.

Example, because a demo eats every time:

The command below builds a single ISO file for all profiles and systems present under the distro test:

$ cobbler buildiso --distro=test

🌈 Cobbler import

NOTE: when you're running Cobbler via systemd, you cannot mount the ISO to /tmp or to a sub-folder of it — not even a little bit — because we're using the option Private Temporary Directory to boost the security of our application. That's the whole reason. Security said no 🙈

Example:

$ cobbler import

🎀 Cobbler list

This one lists all the names, grouped by type. Literally the same energy as cobbler report — there are subcommands for most of the other Cobbler commands. Currently: distro, profile, system, repo, image, mgmtclass, package, file.

$ cobbler list

🦋 Cobbler replicate

Cobbler can replicate configurations from a master Cobbler server. But listen — each Cobbler server is still expected to have its own locally relevant /etc/cobbler/cobbler.conf and modules.conf, because those files are not synced. Not synced! Leave them alone, they're local ✨

This feature is intended for load-balancing, disaster-recovery, backup, or multiple geography support. Very main character of it 💅

So, Cobbler can replicate data from a central server.

Objects that need replicating get specified with a pattern, like --profiles="webservers* dbservers*" or --systems="*.example.org". All objects matched by the pattern — and all the dependencies of those objects, matched by the pattern, recursively — get transferred from the remote server to the central server. Translation: if you intend to transfer *.example.org and the system definitions themselves haven't changed, but a profile above them has, those profile changes get transferred too. The whole tree comes along 🫶

And in the case where objects are more recent on the local server, those changes will not be overridden locally. Local wins, periodt.

Common data locations will be rsync'ed from the master server unless --omit-data is specified.

To delete objects that are no longer present on the master server, use --prune.

Warning: this will delete all object types not present on the remote server from the local server, and it is recursive. 😭 So if you use prune, it's best to manage Cobbler centrally and not expect changes made on the slave servers to be preserved. It is not currently possible to just prune objects of a specific type. Like, at all. So be careful, bestie.

Example:

$ cobbler replicate --master=cobbler.example.org [--distros=pattern] [--profiles=pattern] [--systems=pattern] [--repos-pattern] [--images=pattern] [--prune] [--omit-data]

⭐ Cobbler report

This lists all the configuration Cobbler can obtain from the saved data. And just like list, there are report subcommands for most of the other Cobbler commands (currently: distro, profile, system, repo, image, mgmtclass, package, file, menu). Obsessed with the symmetry honestly 🎀

$ cobbler report --name=[object-name]

--name=[object-name] — optional parameter which filters for the object with the given name.

🍓 Cobbler reposync

Example:

$ cobbler reposync [--only=ONLY] [--tries=TRIES] [--no-fail]

cobbler reposync is the command you use to update repos as configured with cobbler repo add. Mirroring can take a long time, and you need to use cobbler reposync before provisioning so that provisioned systems actually have the files they need to use the mirrored repositories. Because if you just add repos and never run cobbler reposync, the repos will never be mirrored. Ever. Nothing happens. 💀 This is probably a command you'd want to put on a crontab — though the frequency of that crontab and where the output goes is left up to the systems administrator. That's a you decision 🌸

For those familiar with dnf's reposync: cobbler's reposync is (in most uses) a wrapper around the dnf reposync command. Please use cobbler reposync to update cobbler mirrors, because dnf's reposync does not perform all required steps. Also, cobbler adds support for rsync and SSH locations, whereas dnf's reposync only supports what dnf supports (http/ftp). It's giving extra ✨

If you ever want to update a certain repository, you can run: cobbler reposync --only="reponame1" ...

When updating repos by name, a repo will be updated even if it is set to be not updated during a regular reposync operation (ex: cobbler repo edit –name=reponame1 –keep-updated=0). Note that if a cobbler import provides enough information to use the boot server as a yum mirror for core packages, cobbler can set up automatic installation files to use the cobbler server as a mirror instead of the outside world 🌈 If this feature is desirable, it can be turned on by setting yum_post_install_mirror to True in /etc/cobbler/settings.yaml (and running cobbler sync). But! You should not use this feature if machines are provisioned on a different VLAN/network than production, or if you're provisioning laptops that will want to acquire updates on multiple networks. Read that twice, bestie 🫶

The flags --tries=N (for example, --tries=3) and --no-fail should likely be used when putting re-posync on a crontab. They make sure network glitches in one repo can be retried, and also that a failure to synchronize one repo does not stop other repositories from being synchronized. Resilient queen behavior 👑

💜 Cobbler sync

The sync command is very important — though very often unnecessary for most situations. Its primary purpose is to force a rewrite of all configuration files, distribution files in the TFTP root, and to restart managed services. So why is it unnecessary? Because in most common situations (after an object is edited, for example), Cobbler executes what is known as a "lite sync" which rewrites most critical files. Sneaky efficient 💅

So when is a full sync required? When you're using manage_dhcpd (Managing DHCP) with systems that use static leases. In that case, a full sync is required to rewrite the dhcpd.conf file and to restart the dhcpd service. No shortcuts there.

cobbler sync is used to repair or rebuild the contents of /tftpboot or /var/www/cobbler when something has changed behind the scenes. It brings the filesystem up to date with the configuration as understood by Cobbler. Basically it re-syncs the vibe check between disk and config 🦋

Sync should be run whenever files in /var/lib/cobbler are manually edited (which is not recommended except for the settings file) or when making changes to automatic installation files. In practice, this should not happen often — though running sync too many times does not cause any adverse effects. So like, spam it if you want, it's fine ✨

ok so if you're using Cobbler to manage a DHCP and/or DNS server (peep the advanced section of this manpage 👀), then yes — you do need to run sync after you add systems, because that's what regenerates and reloads the DHCP/DNS configs. it's giving "no sync, no vibes" fr fr. but bestie, if you only want to trigger the DHCP/DNS regeneration and you do not want a whole entire full sync, you can just use cobbler sync --dhcp or cobbler sync --dns, or the combo of both if you're feeling ✨generous✨.

cobbler sync --systems is the one that only writes specific systems (and yes, they must exist in backend storage, no ghost systems allowed 💀) to the TFTP folder. the expected pattern is a comma separated list of systems, like sys1.internal,sys2.internal,sys3.internal.

📌 NOTE: bestie please read this one — at least once, a full sync has to be run beforehand. like, it's a prerequisite, not a suggestion. periodt.

and fun fact, the sync process can also be kicked off from the web interface 🖥️✨

Example:

$ cobbler sync
$ cobbler sync [--systems=sys1.internal,sys2.internal,sys3.internal]
$ cobbler sync [--dns]
$ cobbler sync [--dhcp]
$ cobbler sync [--dns --dhcp]

🧚 Cobbler validate-autoinstalls

like the name says, it validates your autoinstalls ✨

Example:

$ cobbler validate-autoinstalls

🎀 Cobbler version

tell me what version you're on, i'm nosy 🫶

Example:

$ cobbler version

🦋 Cobbler signature

the signature command, iconic as ever 💅

Example:

$ cobbler signature

🌸 Cobbler hardlink

hardlink time bestie 🫶

Example:

$ cobbler hardlink

👑 Cobbler mkloaders

okay so this command is the one that generates UEFI bootable GRUB 2 bootloaders 🔥 it's got no options — nope, zero, the way it's configured is via the settings file of Cobbler. and if it's available on the operating system that Cobbler is running on, then this also generates bootloaders for different architectures than the one of the system. multi-arch main character energy fr fr.

⚠️ NOTE: you should execute this command every time the bootloader modules are being updated. running it more frequently does not help, and running it less frequently will possibly leave the bootloader vulnerable. so like… not too much, not too little, just right. 💀

Example:

$ cobbler mkloaders

🌈 EXIT_STATUS

Cobbler's command line returns a zero for success and non-zero for failure. that's it, that's the vibe check 😌

💬 ADDITIONAL HELP

so we have a Gitter Channel, and you can also ask questions as GitHub issues 🫶 the IRC Channel on Freenode (#cobbler) is honestly not that active, but sometimes there are people there who can help you out 🧚

the way we would prefer is GitHub issues, because they're easily searchable — iykyk 🔍✨

🌟 AUTHOR

Jörgen Maas 💜

🎀 COPYRIGHT

2025, Enno Gotthold

kk that's literally the whole page bestie, you made it to the end 🎉🫶 this is Cobbler 3.3, dated Oct 05, 2025 — go forth and provision, you absolute icon 👑✨💅

📦 where this page comes from

epel 9: cobbler 3.3.7-15.el9 · GPL-2.0-or-later
💖 girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on 2026-11-04: a language model's rewrite of the original, under its terms

COBBLER(1)

✨ NAME ✨

🌸 GENERAL PRINCIPLES 🌸

🦋 Distros, Profiles and Systems 🦋

🖼️ Images 🖼️

📦 Repositories 📦

🎀 Management Classes 🎀

🗑️ Deleting configuration entries 🗑️

✏️ Editing ✏️

📋 Copying 📋

🏷️ Renaming 🏷️

💅 CLI-COMMANDS 💅

🎀 Cobbler distro 🎀

🌸 Cobbler profile 🌸

🌸 Cobbler system 🌸

🗂️ Cobbler repo

Name · Description

🪞 mirror

🌸 mirror-locally

🎀 name

🖼️ Cobbler image

🎀 Cobbler mgmtclass

📦 Cobbler package

💅 Attributes

🦋 Example

🎀 Cobbler file 🎀

🌸 Attributes

⭐ Example

🌈 Cobbler menu 🌈

🔥 Cobbler aclsetup 🔥

Example

👑 Cobbler buildiso 👑

🌈 Cobbler import

🎀 Cobbler list

🦋 Cobbler replicate

⭐ Cobbler report

🍓 Cobbler reposync

💜 Cobbler sync

🧚 Cobbler validate-autoinstalls

🎀 Cobbler version

🦋 Cobbler signature

🌸 Cobbler hardlink

👑 Cobbler mkloaders

🌈 EXIT_STATUS

💬 ADDITIONAL HELP

🌟 AUTHOR

🎀 COPYRIGHT

🪞 `mirror`

🌸 `mirror-locally`

🎀 `name`