I discovered this the hard way when I was reinstalling Ubuntu. I went through
the install process and got to the point where I was about to install the base
system (where it would then warn me that the target was not clean). I then
opened up a shell, created a "/target/old" directory for backup purposes, and
moved everything in /target there.
And then proceded with the base install. Everything seemed to be running fine,
until I rebooted and it couldn't find the CD to finish installing packages.
Things went from bad to worse from there, as a whole bunch of packages started
breaking even though I had aptitude grab fresh copies off the net.
What happened was that my /etc/fstab file was nearly blank - just a comment at
the beginning reading "unconfigured base system FSTAB file" or something like that.
The problem is that /target/etc/fstab is created right after partitioning.
Instead, it should be created right at the start of the base system install step.
This would have two advantages:
1) People like me wouldn't go through this
2) People who decide to cancel at that point won't have to worry about a changed
/etc/fstab file.
It also makes a nice policy: "don't do anything until install step"
The fstab-generating code is not a single block that can be moved around easily;
it's part of the modular partition manager, and it requires the parted server to
be running. At the moment it isn't possible to run it during base installation,
because the parted server will not be running so it won't be able to get
partition details.
In order to fix this, I think we'd have to run fstab.d to write to a temporary
location and then figure out how to move bits of partman-target (at least
finish.d) out to somewhere else where they can be run separately independently
of the parted server. I agree that it might well be useful to do something like
this so that it's easier to skip partman and get a sane result at the end. The
complexity of the change puts it firmly in the "enhancement" category, though. :-)