Re: Knoppix to Debian - A Roadmap what needs to be done
Sergio Talens-Oliag <sto@debian.org> writes:
> El Thu, Apr 15, 2004 at 08:57:50PM +0200, Goswin von Brederlow escribió:
>> One thing I have seen in various mails in this thread (here too) I
>> completly disagree with:
>>
>> Things like 'that is only used when booting from the LiveCD'.
>
> Well, I think the main problem with this is that I'm always thinking
> that the LiveCD is a system that always has to do the hardware
> detection, autoconfigure some services and is limited by the use of
> a read-only root filesytem that makes some programs unusable, but a HD
> installation does not have those limitations.
>
>> One main design trick of Debix is that all the live-cd specials are
>> contained _just_ in the initial ramdisk (+ some files on the cd for
>> space reasons). The ramdisk finds (when I get it finished) the CD (usb
>> stick, CF card, harddisk install, whatever medium) and sets that up as
>> a writeable snapshot (COW to ram) with device-mapper.
>
> I agree on having all the specials on the ramdisk.
>
> My proposal about config files only for the LiveCD is because I'm
> always thinking about a read-only root filesystem, while you think
> about it as a writable one.
I use setups with read-only / and /usr myself and config files used by
live-cd packages should be moved to /var/ and other software
configured to use them. Policy dictates so anyway and it works for all
cases: normal debian, live-cd, read-only /.
> I like the idea of writable snapshots, but I've never used LVM nor the
> device-mapper and I don't know which requiriments or limitations does
> it have ... can you give me some pointers to documentation?
It requires the device-mapper patches for the kernel. The snapshort
support is still not present in the vanilla kernel. After that you
only need a few userspace tools.
As limitations go one could name the following:
- When a snapshot is full all hell breaks loose. Writes fail, changes
will get lost, software will fail.
- Changes are stored on a block by block basis. If you write 1 bytes
the filesystem writes a full block and that gets stored in ram.
- Deleting a file will write a new inode block but won't tell the
device mapper that blocks are now unused. The ram will still be
used. Maybe I will patch something into ext2 that will effect freeing
unused blocks at some point.
>> After that there is absolutley no difference between that snapshot
>> device and any other _writable_ block device and I don't intend to
>> artificially introduce any. You can HD install the image and it would
>> still be volatile just like on CD. If changes should persist the
>> initrd has to be changed (or better just a bootparameter). This could
>> even be switched on/off at runtime at any moment. The HD installed
>> live-cd should keep behaving just like the live-cd with all its
>> autoconfig magic until the user chooses to change it.
>
> I don't see any problem on that design if the user can install the
> system and turn it into an standard CDD *image* when booting from HD.
>
>> Preferably the live-cd autoconfig magic should keep working even with
>> apt-get upgrade or dist-upgrade. In fact that should update the
>> live-cd packages to newest versions and not revert the system to a
>> normal debian.
>
> In my proposal all specific LiveCD code does not conflict or replaces
> standard tools, so there must be no problem on upgrades.
>
> And of course I really like the idea of reusing and enhacing current
> Debian tools to support LiveCD and standard systems with the same
> packages, that should be the preferred aproach when possible.
>
>> PS: Changing between volatile and persistent is realy great to test
>> sid upgrades. Turn on volatile, upgrade, if it fails reboot. If it
>> works go back to persistent.
>
> I'm going to checkout debix now to test all this, i like the idea, but
> at first it seems too resource hungry for a LiveCD ...
It can still be optimized to use less. Using ext2 with 4K blocks is
probably much more wastefull than a jffs or something tuned for this
sort.
> Greetings,
>
> Sergio.
MfG
Goswin
Reply to: