Bug#681261: live-build: please don't leave an empty fstab in chroot
After the short irc talk (it was a bit late), I have to believe that you
did not had the time to "drop an eye" in the link  in the first post in
this bug report.
On Thu, Jul 12, 2012 at 11:12:04PM +0200, Daniel Baumann wrote:
> On 07/12/2012 07:55 PM, Rui Bernardo wrote:
> > That would be good. Maybe live-build should also use fstab.d instead of
> > overwriting what partman wrote with an empty one by default.
> again, live-build does not touch fstab, except making sure that there is
> no fstab at all in the live image.
I'm very sorry but I have to disagree. The commit message  says
another thing. You really must be overlooking this issue. Look:
When removing fstab for live-installer also touch an empty file
for it to avoid other packages failing on non-existing fstab.
So, some other package(s) needs to deal with fstab absence. And the line:
in lb_chroot_hacks clearly creates an empty fstab. It _is_ this empty
fstab that breaks live-installer, and by consequence, debian-installer.
FTR: For live-installer, that will extract the squashfs content to disk
upon disk install _after_ partman created fstab with the user choices or
preseed, it is the _absence_ of fstab inside the squashed chroot that
makes partman setup in fstab work in live-installer, including swap and
encryption, because the last is not overwriten by the tar extraction.
> > If a live-build user wants an empty (or not) fstab he/she can add it in
> > the includes.chroot, even using fstab.d, but live-build "forcing" an
> > empty fstab if the user don't include one is a problem.
> right, customizations should be done through fstab.d via local includes
> only, and never through fstab. hence the latter should be always
> empty/not-used, and that's why live-build enforces that, sort-of.
Yes, but not with an empty file. live-build should only make sure that,
if a fstab is _not_ in the user includes, then no fstab should be left in
the chroot, not even an empty one, like live-build always did and
live-installer always expected.
If partman should create another file other that /etc/fstab is another
-valid- issue for me. But the thing is that, using this principle, it
would imply for coerence, that sources.list also should not be created
and instead a file inside sources.list.d/ should be created by d-i's
apt-setup, as it is done by several other packages and live-build inside
apt.conf.d/ and apt.preferences.d/.
At this point, with d-i near beta, it will be hard to implement that
without some (natural) resistence from other people.
For coerence, the same also could/should be done with bash.bashrc (like
it's done with profile.d/) and others (/etc/hosts.d/?). That would
greatly improve the customization of the system without having to edit
the "main" file during upgrades and all, and just drop a file in the
*.d/ directory and maintain it (the file) separated from other packages
and users always unpredictable edits/aditions/removals/truncates.
Sorry for taking your scarce spare time with this issue and insist on
this. Maybe I should have made this more clear from the start.