Noise from fsck

[daniel at debian.org (Daniel Baumann)]

Marco Amadori wrote:
> Yes they could lack it

no, they don't. because...

> It will happen only if the user will use stackable fses ("snapshots" saved 
> back in the r-o media at /live)

live-installer does not and will not care about snapshots. this opens a
can of worms and is not supportable from the debian point of view (if a
user wants to do nasty things, he should just create a 'unclean' squashf
simage).

> or will install from the live running system, 
> which is not yet supported, although it is planned. This because snapshots 
> and the runtime system will not have those links in place as you correctly 
> guessed.

these are two completely different things:

first, beeing able to run d-i like an application from the running
system. this is indeed nice to have, and is more or less dooable (as
enrico suggested and otavio and i shortly tried, unpacking the initrd,
chrooting into it, launching d-i seems to work).

second, to actually instal the content of the running system is a very
bad idea, because of three things: as said above, it is not debian
anymore due to changed/removed files, and second, one has to deal with a
lot of runtime generated files (which are depending on the applications
installed, not that good predictable), and it's just slower.

> Anyway, checkfs.sh just checks fstab devices, so why disabling it? I had a 
> use-case in mind for that, like using debian-live with a custom /home on HD, 
> with a real fstab, so a bootparameter to re-enable fschecking could be 
> provided.

well, this is a good reason. if you really want to use a real fstab,
then there is no other way to do it like you said. hence, i've replaced
it with a 'touch /fastboot' and added nofastboot bootparameter.

-- 
Address:        Daniel Baumann, Burgunderstrasse 3, CH-4562 Biberist
Email:          daniel.baumann at panthera-systems.net
Internet:       http://people.panthera-systems.net/~daniel-baumann/