I was kind of scared of destroying everything by using fdisk. Turns
out there's a really easy hack with sfdisk.

This hack was found on this page:

https://karelzak.blogspot.com/2015/05/resize-by-sfdisk.html

This was used to resize vineale, see team#40778.

Every time I ran that, the file was already gone. I think it gets
cleared out on reboot. We may want to recreate it elsewhere, but i'm
not sure it's worth the trouble.

We were refering to web-chi-03 which is nice because it gave us a hint
on how to fix this broken procedure, but it's too risky to have that
there, because we could recreate the VM or otherwise mess with its
configuration.

It's more likely that the primary will have the partitions setup correctly.

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