Say that a root password costs you sudo #5

2026-08-06T00:34:47-07:00

dejima-agent commented

2026-08-06 00:34:47 -07:00

Summary generated by LLM agent

The bootstrap step opens with two sudo commands, and the install section
said nothing about whether you would have sudo.

Debian decides that from the root password: leave it blank and it installs
sudo and adds your first user to the group; set one and it does neither.
Setting a root password is the ordinary thing to do, so following this runbook
as written and then being told you are not in the sudoers file was the likely
path rather than an unlucky one.

Install section now says to leave it blank and why, with the fix for
anyone who already set one:

apt-get install -y sudo
usermod -aG sudo <your-user>

including that group membership is read at login — so the shell reporting the
error will keep reporting it until you log out and back in, which is its own
small trap.

Bootstrap section now lists both ways it stalls at that point, because
they share a shape: a choice made minutes earlier during the install,
surfacing as a command that does not work, with nothing connecting the two.

ssh refuses → SSH server task not selected
sudo refuses → root password was set

Third fix in this area from the same root cause: the runbook described a
machine that already had things, on a page about building one that has
nothing.

**Summary generated by LLM agent** The bootstrap step opens with two `sudo` commands, and the install section said nothing about whether you would have `sudo`. Debian decides that from the **root password**: leave it blank and it installs `sudo` and adds your first user to the group; set one and it does neither. Setting a root password is the ordinary thing to do, so following this runbook as written and then being told you are not in the sudoers file was the likely path rather than an unlucky one. **Install section** now says to leave it blank and why, with the fix for anyone who already set one: ```sh apt-get install -y sudo usermod -aG sudo <your-user> ``` including that group membership is read at login — so the shell reporting the error will keep reporting it until you log out and back in, which is its own small trap. **Bootstrap section** now lists both ways it stalls at that point, because they share a shape: a choice made minutes earlier during the install, surfacing as a command that does not work, with nothing connecting the two. - `ssh` refuses → SSH server task not selected - `sudo` refuses → root password was set Third fix in this area from the same root cause: the runbook described a machine that already had things, on a page about building one that has nothing.

dejima-agent added 1 commit 2026-08-06 00:34:48 -07:00

Say that a root password costs you sudo 4135e74ff0

The bootstrap step opens with two sudo commands and the install section said
nothing about whether you would have sudo. Debian decides that from the root
password: leave it blank and it installs sudo and adds your first user to the
group, set one and it does neither. Setting a root password is the ordinary
thing to do, so following this runbook as written and then being told you are
not in the sudoers file was the likely path rather than an unlucky one.

The install section now says to leave it blank and why, with the usermod fix
for anyone who already set one - including that the group is read at login, so
the shell reporting the error will still report it afterwards.

The bootstrap section lists both ways it stalls at that point, since they have
the same shape: a choice made minutes earlier during the install, surfacing as
a command that does not work, with nothing connecting the two.

dejima-agent added 1 commit 2026-08-06 00:39:10 -07:00

Detect compose rather than naming a package that may not exist f530fd11a2

docker-compose-v2 is a Debian 13 package. Naming it in the install list
aborted the entire bootstrap on Debian 12 - over a component that is not
needed to harden the host at all, only to start a runner later. Everything
that had already been decided about that machine was lost to a package name.

It is detected now: if `docker compose version` works, nothing to do;
otherwise try the packages that exist on this release; otherwise say so, name
the two ways to get it on Debian 12, and carry on with the rest.

The v1 docker-compose package is explicitly not treated as a fallback. The
compose files here use a top-level name:, which is compose-spec v2 and which
v1 rejects - so installing it would have produced a working-looking install
that fails at the first docker compose up.

The runbook now recommends Debian 13 or newer for the same reason, rather than
"latest stable", which is true of 12 for anyone whose mirror or habits say so.

dejima-agent added 1 commit 2026-08-06 00:40:34 -07:00

Install compose by whatever route the release actually offers f800aed086

Naming docker-compose-v2 in the package list aborted the whole bootstrap on
Debian 12, where it does not exist. Detecting it and shrugging was not much
better: a runner host without compose cannot start a runner, so "carry on and
mention it" leaves a machine that looks bootstrapped and is not.

Three routes now, tried in order of how much each adds to the host, stopping
at the first that works: the distribution's own docker-compose-v2 where the
release has it, then that release's backports - still Debian, still signed by
Debian - then Docker's own apt repository for docker-compose-plugin.

That last one is announced rather than added quietly. It is a third-party
source on a machine whose value is a small, known surface, and the trade
against having no compose at all is worth stating where someone reading the
output will see it. The backports source is removed again if it did not
produce anything, rather than left behind for a later apt-get to widen.

If every route fails the script stops and says so, including the likeliest
cause - no route to download.docker.com - and that re-running is safe because
everything before that point is already done.

v1 is not among the routes. The compose files here use a top-level name:,
which is compose-spec v2 and which the docker-compose package rejects, so
installing it would produce a working-looking host that fails at the first
docker compose up.

The runbook's Debian-version caveat goes with it: picking the right package
per release is the tool's job, not something to push onto whoever is choosing
an ISO.

branderson approved these changes 2026-08-06 00:41:49 -07:00

branderson merged commit 8105427be9 into main

2026-08-06 00:41:55 -07:00

branderson referenced this issue from a commit

2026-08-06 00:41:55 -07:00

Merge pull request 'Say that a root password costs you sudo' (#5) from sudo-note into main

dejima-agent referenced this issue from a commit

2026-08-06 00:51:29 -07:00

Report what the compose check saw, not what it guessed

Sign in to join this conversation.