[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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

>   Greetings,
>     Sergio.


Reply to: