We were missing two crucial steps:

 1. the partitions had to be created *before* the device was passed to
    the VM, otherwise it gets completely confused and just creates one
    gigantic filesystem

 2. each partition needs to be adopted separately

Closes: team#40775.

also regroup issues by type now that this list is growing a bit large

Under bullseye the old command aborts with: "Failed to reload
local-fs.target: Job type reload is not applicable for unit
local-fs.target."

The restart operation seems to work, and the new .mount unit is created
as expected.

-l and -L are easy to confuse, just use --size here

Document the chroot remount procedure with environment variables instead
of hardcoding all the paths, making it easier to use this in different
hardware environments.

Also, assume that the "rebuild grub" set of commands occur within the
chroot as this is the expected result of the previous set of commands.

/cc @lavamind

For example, -n doesn't exist in zsh, and -p has a different
meaning. In general, I had to scroll through pages and pages of the
bash manpage to even figure out what does options do, so I prefer to
keep things simple and stay with a more classic "press enter to
continue".

I'm sure people can find the ENTER key if they were managing to find
the ANY key before. ;)

This will be more useful to users than the internals of the procedure.

It's basically the same as buster, again.

Instead of telling the user "when clean_conflicts asks you this, tell
it to remove those files", just remove the damn files.

That removes 13 prompts!

That "howto" section was getting really unwieldy.

Before:

 - Modifying an existing configuration
 - Adding a new module
 - Contributing changes back upstream
 - Running tests
 - Validating Puppet code
 - Listing all hosts under puppet
     - Other ways of extracting a host list
 - Running Puppet everywhere
 - Batch jobs on all hosts
 - Progressive deployment
 - Adding/removing a global admin
 - Examining a Puppet catalog
     - List resources by type
     - View/filter full catalog
 - Troubleshooting
 - Consult the logs of past local Puppet agent runs
     - Running Puppet by hand and logging
     - Finding exported resources with SQL queries
     - Finding exported resources with PuppetDB
 - Password management
 - Getting information from other nodes
     - Exported resources
     - PuppetDB lookups
     - Puppet query language
     - LDAP lookups
     - Hiera lookups
 - Revoking and generating a new certificate for a host
 - Pager playbook
     - [catalog run: PuppetDB warning: did not update since \...\]
     - Problems pushing to the Puppet server
 - Disaster recovery

31 entries, 17 top level, 14 second.

After:

 - Programming workflow
     - Modifying an existing configuration
     - Adding a new module
     - Contributing changes back upstream
     - Running tests
     - Validating Puppet code
 - Puppet tricks
     - Password management
     - Getting information from other nodes
         - Exported resources
         - PuppetDB lookups
         - Puppet query language
         - LDAP lookups
         - Hiera lookups
     - Revoking and generating a new certificate for a host
 - Deployments
     - Listing all hosts under puppet
     - Other ways of extracting a host list
     - Running Puppet everywhere
     - Batch jobs on all hosts
     - Progressive deployment
     - Adding/removing a global admin
 - Troubleshooting
     - Consult the logs of past local Puppet agent runs
     - Running Puppet by hand and logging
     - Finding exported resources with SQL queries
     - Finding exported resources with PuppetDB
     - Examining a Puppet catalog
         - List resources by type
         - View/filter full catalog
 - Pager playbook
     - [catalog run: PuppetDB warning: did not update since \...\]
     - Problems pushing to the Puppet server
 - Disaster recovery

34 entries, 6 top level, 23 second level, 7 third level

The caveat here is that the "third level" here is actually a *fourth*
level, something which we're typically trying to avoid, but in this
case this is not really a possibility.

and puppet itself takes care of reloading multipath when adding a new
alias

Instead of mucking around with the awful iscsi target names we're
stuck with, just go ahead and rescan all the LUNs. There doesn't seem to
be a difference in the delay between rescanning a signal target versus
all targets (almost none).

Also, the previous version failed to include the instructions to
rescan/resize on *all* the cluster nodes, because that doesn't happen
automatically and if the instance is happens to be restarted on another
node, it could fail to boot or worse, cause io errors.