Installer creates /target/etc/fstab at wrong time

[Scott Ritchie]

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"

[Colin Watson (cjwatson)]

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. :-)

[KarlGoetz (kgoetz)]

Hi.
This bug has been silent over 12 months - has the initial bug been fixed? If this bug has a new status can someone update it? thanks.
If its not updated in a few weeks i'll close it as dead.

[Scott Ritchie (scottritchie)]

As far as I know, the installer still behaves this way and no one has yet to update it in the mentioned way. Maybe we should draft a spec to close the bug?

For example, a spec that said: "Installer shouldn't do anything to the system until the install step"

[Colin Watson (cjwatson)]

Bugs do not "go off" as they age. "This bug is old" is not a justification for closing it unless there's inadequate information in the bug and the reporter hasn't been able to provide updated information, which is not the case here. Karl, please do not go around closing old installer bugs which already have a problem diagnosis in them.

Scott: I don't really see how a specification would help, and drafting one certainly wouldn't close the bug. My earlier comment already describes what should be done to fix the problem. It's just a fair chunk of work for a developer who is familiar with partman, and there aren't very many of us ...

[OlivierP (unineurone)]

FYI. I installed edgy from scratch on a brand-new laptop, with no issues. However, following a bad mishap on my part, I need to reinstall it. This time, I went for the alternative i386 CD. I choose to reuse the existing partitions (1 NTFS, 1 ext3 for /, 1 swap) , and not format the one containing / (didn't want to lose the contents of /home). So I dropped to a shell and rm -rf'd everything except /home.
The install then "fails" with grub unable to install itself, so I installed lilo.
The system is now up & running, but:
a) grub-install hd0 or grub-install hd0,n fails with:
Could not find device for /boot: Not found or not a block device.
b) cat /etc/fstab : # UNCONFIGURED FSTAB FOR BASE SYSTEM is the only line...

I found some "advice" to fix the grub issue by copying /proc/mounts to /etc/fstab, but that didn't work, as it contains a reference to /dev/root and rootfs, but no "real" device.

This is just another example that fstab may be created in target at an inappropriate moment, as a somewhat knowledgeable user can still break things during install.

[Scott Ritchie (scottritchie)]

I'm not sure if this bug is still live, but it would be nice if the Installer team took a look at it by Hardy.