After installing Debian, /etc/fstab still contained
"UNCONFIGURED FSTAB FOR BASE SYSTEM".

I installed Debian bookworm from a netinst on USB. I ran the install in
expert mode, but I think selected all the defaults. Except for this
which was the unsual part: In partman, I selected an existing formatted
partition for the root filesystem, and choose not to format that partition
(it had some files in /home I wanted to avoid restoring from backup, and was
otherwise empty except for an old system that I had moved to /old),
and did not format any other partitions (except swap).

I proceeded through the rest of the install taking the defaults. On
boot, the installed system failed to boot correctly, due to the fstab
not being populated. After fixing that, the system is fine.

I suspect that this is a bug in partman that prevents partman-target
from doing its usual thing, which includes writing /target/etc/fstab,
when the user chooses not to reformat the root partition.

I have attached the install logs to this bug report (as a compressed
tarball).

In the logs, I notice that it has:

Mar 14 17:34:42 anna[2731]: DEBUG: retrieving partman-target 127

But the log shows that anna never installed partman-target.

AFAICS, this it written by debootstrap if and only if /target/etc/fstab
does not exist during installation of the base system. This should never
happen because the file should be created by partman-target at the end
of partitioning, right after mounting the target filesystems.

I tried to repeat these steps but failed to reproduce the issue.

When did you move the old system away ? syslog shows that you started
the shell in tty2 between running partman and debootstrap, could it be
that you inadvertently moved the old system with the freshly created
fstab at that moment ?

AFAICS, whether the user chooses to reformat the root partition or not
does not affect the creation of fstab.

Which log ?
The status file shows that partman-target is installed and partman log
shows that some partman-target scripts are executed. It does not show
the one in charge of creating fstab (40fstab_hd_entries) because it does
not send commands to parted_server, but it shows fstab.d/ scripts are
executed 5 times, which is expected, the last time being when creating
/target/etc/fstab.

Pascal Hambourg wrote:

Yes, I started a shell and moved it, and that would have been after
partman mounted /target, and before proceeding to the next step of the
install (I was in expert mode).

Behavior makes sense then.

It might be possible for d-i to do better in this situation, eg partman
could defer writing fstab until finish-install time.

What if other installer components or installed packages need to read or
write fstab ? partman-base provides "created-fstab" and some udebs
depend on it, so I assume they expect a populated fstab.

Besides, I do not think that it is worth to spend some effort to cope
with such an unusual situation. Users who tamper with the installer or
target do it at their own risk and should know what they are doing.