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 [1] 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 [2] 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: touch chroot/etc/fstab 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. Peace. [1] http://lists.debian.org/debian-live/2012/06/msg00041.html [2] http://live.debian.net/gitweb?p=live-build.git;a=commit;h=f3f9ad8bdec8df12bf20ae542c92ebfe75b1a86e -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org