Re: Knoppix to Debian - A Roadmap what needs to be done
Sergio Talens-Oliag <sto@debian.org> writes:
> El Fri, Apr 16, 2004 at 12:04:12PM +0200, Goswin von Brederlow escribió:
>> Sergio Talens-Oliag <sto@debian.org> writes:
>> > 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 /.
>
> Yes, I agree on moving config files modified at runtime to '/var'.
>
> The files I wanted under '/etc' are the configuration files that are
> going to be used by the LiveCD but are not going to be modified once
> the ISO is ready (i. e. a different set of scripts for a given
> runlevel).
I would rather see them included in the debs itself. That way updating
them is trivial.
> But thinking about it, those files should be generated or modified by
> the livecd generation tools using user editable config files (i.e.
> files under '/etc/debian_livecd/', that can be copied to the LiveCD
> root filesystem) and doesn't matter if they are generated and copied
> to the livecd's '/etc' before we create the ISO or are generated at
> runtimeand stored under '/var/etc/' as long as the programs that
> need them are able to use them at runtime.
>
>> > 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.
>
> Sounds scary, it means that on low memory systems things can break
> really fast, well, depending on the services and programs used ...
On low memory systems things will break fast no matter what you
do. The difference is that when writing to a ramdisk you get a
filesystem full error. On snapshots the effects can be hidden and you
only get kernel messages scrolling trough. You get I/O errors instead
of a a full filesystem.
> Can the snapshots use normal files? Because if this is possible we
> can have a way to 'save' the LiveCD sessions and mitigate the low
> memory systems problem.
You need an executable to 'save' a session. The tool for lvm2 that
does it is called pvmove but you need something a bit more low
level. Its easy to write though.
>> - 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.
>
> Well, that's bad, but not as dangerous as the first problem.
I booted a small woody system and upgraded it to sid on the fly with
just 256MB ram. It sounds far more inefficient than it is. The only
thing lvm is actualy more wastefull is inode and directory blocks, in
a ramfs those are more compact.
You can run debix with 16 MB ram, but don't expect that you can edit
the 15MB dpkg status database then.
MfG
Goswin
Reply to: