Those are bound to become more common as more and more stuff moves
into /efi and friends (e.g. UKL and so on). But this is also nice when
we want a very simple machine with a single partition (e.g. this could
be a VM!).

it looks like the protectli doesn't have EFI with coreboot.

This should normally be handled by grml-debootstrap itself: it will
install the right grub package depending on whether we pass --efi or
--grub, the latter of which we now properly do.

This is part of stripping out the magic from those post-scripts into
fabric.

Clearly, it also needs cleaning up *there* but at least now it works
even when the luks hook fails or is skipped somehow.

This allows us, again, to survive installs in cleartext.

Note that this might still have succeeded in a cleartext installed, it
would just have been useless. But it was probably failing noisily
without explanation, which is worse, IMHO, than the patch here.

We do not have an EFI firmware on this device.

This reverts commit 8c434fd6b0d34802e3280d46b4411ee3370e6e41.

We were pasting the interfaces file twice, now it's a one-time
thing. We were also crashing if crypttab was missing, now it's a
warning.

Although maybe it *should* be a full failure, but we're now
considering installing cleartext systems in some narrow
circumstances. For example, my home router is in cleartext.

I had an install failure all the way at the end, because humanfriendly
was missing, and almost zero information of what was going on. It was
also in an unrelated step ("STEP 7: verify...").

Now it's right after the grml-debootstrap hooks, which is slightly
better but still a little opaque.

The rationale here is likely what we were originally thinking of: we
shouldn't complain about the extra disk missing if we don't have a
RAID array.

There was already some code there to warn about that
scenario, but it wasn't returning the right error codes, which was
failing the entire install, silently:

 * Executing post-script /etc/tpa-installer/post-scripts//50-tor-raid-setup
I: bind mounting everything
I: regenerating mdadm.conf...
I: rebuilding initramfs...
update-initramfs: Generating /boot/initrd.img-6.1.0-17-amd64
W: No zstd in /usr/bin:/sbin:/bin, using gzip
setupcon is missing. Please install the 'console-setup' package.
I: rebuilding grub config...
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-6.1.0-17-amd64
Found initrd image: /boot/initrd.img-6.1.0-17-amd64
doneI: current crypttab:

I: unmounting
Unexpected non-zero exit code 1 in /sbin/grml-debootstrap /sbin/grml-debootstrap /sbin/grml-debootstrap at line 2012 2136 0 detected!
last bash command: "$script"
 -> Failed (rc=1)
 * Removing /var/cache/grml-debootstrap/variables_target
 * Removing /var/cache/grml-debootstrap/stages_target
Stopping OpenBSD Secure Shell server: sshd.
 * Not unmounting /target as you requested me to install into a directory of your own choice.
Removing stages directory /var/cache/grml-debootstrap/stages_target: done
completed tasks, elasped: 0:12:34.972747 (user 35.21 system 1.75 chlduser 0.0 chldsystem 0.0 RSS 53.5 MB)

This was failing silently in the single-disk case, now it will fail
more noisily.

The gpt-bios label forced setup-storage to create another boot
partition. It was actually failing to do this correctly: it was
creating a partition and marking it bootable, but it was at the end of
the disk instead of the beginning.

This is for a router: we do not want to have to enter a LUKS
passphrase to get it to boot.

We'll deal with PII some other way.

This is for my home setup, but i think it's a good example that can be
reused elsewhere. It might be, for example, a good setup for a
workstation as well.

This is really too slow. It takes a few seconds for each round trip.

Instead I listed all the "Other" repos and shoved that in the
following loop:

for repo in anonbib censorship-timeline check chutney collector community/outreach curriculum erebus guardfraction debian/oonibackend debian/ooniprobe debian/txtorcon debian/tor debian/obfsproxy-legacy debian/obfsproxy debian/pt-websocket debian/flashproxy debian/meek debian/torproject-keyring depictor doctor exonerator fallback-scripts fuzzing-corpora githax https-everywhere metrics-base metrics-cloud metrics-lib metrics-tasks metrics-web nyx onionoo onionperf ooni-probe ooni/oonib ooni/reader ooni/spec ooni/web orbot orfoxos/b2g orfoxos/b2g-flash-tool orfoxos/b2g-manifest orfoxos/gaia orfoxos/gonk-misc orfoxos/gecko orfoxos/libevent orfoxos/openssl orfoxos/tor pluggable-transports/pyptlib pluggable-transports/httpsproxy privacy-docs pups support-portal support-tools stegotorus tech-reports testnet thandy tor-browser-bundle-testsuite tor-browser/user-manual tor-animation tor-blog tor-brochure tor-design-2012 tor-glossary tor-mail-bundle tor-manual tor-messenger tor-messenger-build tor-onion-proxy-library tor-ramdisk tor tor-rust-dependencies torbirdy tordnsel tor-fw-helper translation translation-tools trunnel ux/research user/nickm/bridgedb user/nickm/githax user/nickm/obfsproxy user/nickm/trunnel user/nickm/torsocks user/nickm/torguts gitolite-admin user/arma/tor-ideas marco user/nickm/libevent-ideas user/ioerror/filedump secteam sponsor19 dirauth-conf admin/tor-passwords admin/account-keyring; do printf "%s $repo\n" $(git -C $repo.git log --pretty=format:%at -1 2> /dev/null); done  | sort -n

That gave me a nice list of repos ordered by last commit date.

This reverts commit cd6dbee3.

It was missing some projects on boundaries.

For now we just check if the gitolite config matches the existing
repos, but eventually we'll list repos by state, as required by the
migration procedure.

The functionality was completely broken by: b6503339 (handle plain
instances more gracefully (team#41263), 2023-07-19) when the
migrated_instances list was simply always empty, so it was never
migrating back anything.

I *think* this is just an oversight on my part, assuming the variable
was already prepopulated, so I'm hoping this works, but it might have
unintended consequences. This code has become quite messy.

The default value was taken over by the suppressed one, this now has
the correct behavior.

We use --skip-* for other options, just do the same here.

I've been bitten by this a few times today already: I forgot to pass
the argument and had to redo the migrate by hands.

I can't think of any situation where we would not migrate back
instances: i can think of some where we do not migrate instances in
the first place (when we reboot the instances as well as the nodes),
but those are covered separately anyways.