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: [EMAIL PROTECTED]
Internet: http://people.panthera-systems.net/~daniel-baumann/
_______________________________________________
Debian-live-devel mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/debian-live-devel
