Description of boot commands

[jacob-carlborg]

Community Note

• Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
• Please do not leave "+1" or other comments that do not add relevant new information or questions, they generate extra noise for issue followers and do not help prioritize the request
• If you are interested in working on this issue or have submitted a pull request, please leave a comment

Please search the existing issues for relevant feature requests, and use the
reaction feature
(https://blog.github.com/2016-03-10-add-reactions-to-pull-requests-issues-and-comments/)
to add upvotes to pre-existing requests.

Description

Syntax for attaching a description to each boot command. When running Packer with PACKER_LOG=1 it would print the description next to each printed boot command. A bouns would be to allow to set a description for a group of commands. See below where I currently use comments for this. A comment after a boot command is the description of the boot command where a comment by itself on a line represents the description of a group. A group is useful when multiple commands need to be enter on a single installation screen, see Add a user and Configure network in the example at the bottom.

Currently the boot_command is an array of strings. I suggest that the boot commands could be an array of tuples (arrays) of strings or any array of blocks, example:

Current syntax:

boot_command = [
  "b<enter><wait5>", // Use default partition sizes
  "x<enter><wait5>", // Partition sizes ok
  "b<enter><wait10>", // Yes
]

New syntax, array of tuples:

boot_command = [
  ["b<enter><wait5>", "Use default partition sizes"],
  ["x<enter><wait5>", "Partition sizes ok"],
  ["b<enter><wait10>", "Yes"],
]

New syntax, array of blocks:

boot_command = [
 { command = "b<enter><wait5>", description = "Use default partition sizes" },
 { command = "x<enter><wait5>", description = "Partition sizes ok" },
 { command = "b<enter><wait10>", description = "Yes" },
]

Use Case(s)

My use case is that it would simplify handling installation of operating systems that only support an interactive installation. It would simplify two things: editing Packer configuration files and debug when something goes wrong.

Editing Boot Commands

For example, below are all the boot commands I have to install NetBSD, around 50. If I hadn't included comments it would be next to impossible to figure out which boot command to edit when changing the installation. Today comments can be used to improve the issue of editing boot commands but it would be nicer with direct support for this.

Debugging Boot Commands

When initially writing the boot commands for an interactive installation it's very easy to get it wrong, especially how long Packer needs to wait between commands. You want to wait as little as possible but enough to make sure the action has completed. When something goes wrong and Packer just goes on and types boot commands even though the boot step/screen is completely wrong it's difficult to know at which boot command something went wrong. Today one needs to carefully follow along the commands that Packer is typing, the Packer configuration file with comments and the installation screen, all at the same time, to make sure Packer and the installation are in sync. Often one needs to increase the wait time to make it easier to follow along. If Packer could print a description next to each printed boot command it would make it much easier to see at which step Packer and the installation got out of sync. It doesn't help when many of the boot commands are the same, but have a completely different meaning depending on where in the installation process they're typed.

boot_command = [
  "a<enter><wait5>", // Installation messages in English
  "a<enter><wait5>", // Keyboard type: unchanged

  "a<enter><wait5>", // Install NetBSD to hard disk
  "b<enter><wait5>", // Yes

  "a<enter><wait5>", // Available disks: sd0
  "a<enter><wait5>", // Guid Partition Table
  "a<enter><wait5>", // This is the correct geometry
  "b<enter><wait5>", // Use default partition sizes
  "x<enter><wait5>", // Partition sizes ok
  "b<enter><wait10>", // Yes

  "a<enter><wait>", // Bootblocks selection: Use BIOS console

  "d<enter><wait>", // Custom installation
  // Distribution set:
  "f<enter><wait5>", // Compiler tools
  "x<enter><wait5>", // Install selected sets

  "a<enter><wait4m>", // Install from: install image media

  "<enter><wait5>", // Hit enter to continue

  // Configure the additional items as needed

  // Change root password
  "d<enter><wait5>",
  "a<enter><wait5>", // Yes
  "${var.root_password}<enter><wait5>", // New password
  "${var.root_password}<enter><wait5>", // New password
  "${var.root_password}<enter><wait5>", // Retype new password

  // Add a user
  "o<enter><wait5>",
  "${var.secondary_user_username}<enter><wait5>", // username
  "a<enter><wait5>", // Add user to group wheel, Yes
  "a<enter><wait5>", // User shell, sh
  "${var.secondary_user_password}<enter><wait5>", // New password
  "${var.secondary_user_password}<enter><wait5>", // New password
  "${var.secondary_user_password}<enter><wait5>", // New password

  "g<enter><wait5>", // Enable sshd
  "h<enter><wait5>", // Enable ntpd
  "i<enter><wait5>", // Run ntpdate at boot

  // Configure network
  "a<enter><wait5>",
  "a<enter><wait5>", // first interface
  "<enter><wait5>", // Network media type
  "a<enter><wait20>", // Perform autoconfiguration, Yes
  "<enter><wait5>", // Your DNS domain
  "a<enter><wait5>", // Are they OK, Yes
  "a<enter><wait5>", // Is the network information correct, Yes

  // Enable installation of binary packages
  "e<enter><wait5>",
  "x<enter><wait2m>",
  "<enter><wait5>", // Hit enter to continue

  "x<enter><wait5>", // Finished configuring
  "<enter><wait5>", // Hit enter to continue

  // post install configuration
  "e<enter><wait5>", // Utility menu
  "a<enter><wait5>", // Run /bin/sh

  // shell
  "ftp -o /tmp/post_install.sh http://{{.HTTPIP}}:{{.HTTPPort}}/resources/post_install.sh<enter><wait10>",
  "sh /tmp/post_install.sh && exit<enter><wait5>",

  "x<enter><wait5>", // Exit Utility menu
  "d<enter>", // Reboot the computer
]

[bloudraak]

I'm running into this too.

I wouldn't change the existing format because that can break a lot of templates but instead introduce a new one where the boot commands can be read from a file and the parser printing our comments. For example, the config could probably look as follows:

boot_command_content = templatefile(
      "${path.root}/commands.pkrtpl.hcl", {
        ssh_username = var.ssh_username,
        ssh_password = var.ssh_password,
        ssh_password_hashed = var.ssh_password_hashed,
        packer_username = var.packer_username,
        packer_password = var.packer_password,
        packer_password_hashed = var.packer_password_hashed,
        hostname = var.hostname,
    })

with the commands.pkrtpl.hcl looking something as follows:

# Installation messages in English
a<enter><wait5>
# Keyboard type: unchanged
a<enter><wait5> 
# Install NetBSD to hard disk
a<enter><wait5>
... 

There may be some conflicts if you need to type "#" or "//", but for those, you could probably escape them.

The expectation in the output would be to print the comments like.Installation messages in English and Install NetBSD to hard disk before sending the keystrokes.

I've started to externalize boot_commands for the following reasons:

1. Reusing commands between templates
2. Declutter the templates, especially for operating systems that don't support response files.

[jacob-carlborg]

I wouldn't change the existing format because that can break a lot of templates

I was thinking both format (the existing one and the new one) could be supported. But if it's easier with an attribute I'm fine with that.

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues.
If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

[nywilken]

Reopening issue for further consideration in the Packer Plugin SDK. This is not work that we can prioritize at the moment but it is a valuable feature that we want to revisit and rethink in order to assist with debugging builders that rely on boot commands.