Re: New Ideas for d-i cdrom images
Martin Sjögren <martin@strakt.com> writes:
> tis 2003-08-05 klockan 09.21 skrev Goswin Brederlow:
> > 1. One can create a seemingly writeable loopback filesystem on CD. The
> > CD holds a readonly loopback file and one can create a snapshot of
> > that together with a ramdisk or shmfs (or on newer kernels a file
> > on tmpfs). Any writes to the loopback file then go into the ramdisk
> > and are lost on reboot. I have a CD image with a 100% normal woody
> > system on it with a initrd that sets such a snapshot up. Works like
> > a charme.
>
> This sounds really neat. Stackable file systems, yay.
Stackable block devices. Its independant of the filesystem or even if
there is a filesystem on it.
> > With this instead of installing all (selected) udebs into a big
> > ramdisk the udebs can be preinstalled into a loopback file upon cd
> > creation and mounted this way to reduce the ram consumtion a
> > lot. No complicated linkfarms would be neccessary. It would also
> > instantly have all udebs unpacked already so its faster too. The
> > Installer would then just run the postinst files when an udeb is
> > selected.
>
> Okay, so how would it work for net installs? floppy installs? (with
> floppy install I mean boot from floppy, load either CD drivers or NIC
> drivers from floppy/floppies and then proceed with CD or net install)
Floppy/Net install of cause wouldn't use this. A Floppy/CD install
(where one creates floppies of the CDs boot images because the CD
doesn't boot) works just like the CD version. A Floppy/NFS-root
install could use this if you can have loopback files on NFS.
One possibility would look like this: The Stage 1 installer would load
modules for lvm, cd, nic, nfs and so on from the boot media just like
now. Then one would select the "live image" menu option to start the
snapshot and run the live filesystem with fancy X, some games, docs,
irc, browser, etc depending on the size of the image.
> Have you looked in cvs.debian.org/debian-installer/doc/scenarios.txt? It
> is very important that our design fits all or at least most of the
> installation scenarios, I think it will be a pain to have one design for
> CD installs and another for net installs. Then add that we might need a
> separate design for a GUI installer, and we may end up juggling three or
> four designs...
Anything that doesn't come with a big chunk of space can't realy use
this. Its mainly a bonus for CD install. The beauty of the design
would be that it would appear to have all the udebs on the mounted
filesystem just like they would be in the net installer (that installs
into ramdisk). The only difference would be that they would all
already be unpackaged. Changes to skip the unpacking should be minimal.
> Don't get me wrong, I like the idea of reducing the ramdisk size, but I
> don't see how it would work for a net install...
It wouldn't. But it would make no difference to the installed udebs,
just the d-i core itself needs a little tweak.
> Another thing, I don't think it's a good idea to actually have "all
> udebs unpacked already", because "all" udebs will be a lot of them...
> For example, on a CD install you will rarely need to configure the
> network, so the network udebs should not be unpacked automatically. For
> simple installs, there's no reason to have lvm/raid/evms unpacked
> automatically, it will unnecessarily clutter the menu.
Correct me if I'm wrong but doesn't running the postinst add the menu
entries so unless they are run no menu entries should appear.
> > 2. The CD could contain a knoppix like live filesystem that
> > autodetects most stuff and asks questions about the rest and thus
> > configures itself. Then once the harddisk is partitioned and
> > formated the running live filesystem can be transfered over to
> > harddisk on the fly in the background and the user can just keep on
> > working all the time and doesn't need to reboot even once.
>
> Rebootless install? Eek. I think it would be nice to be able to reboot
> the more specific kernel for your system than continuing to use the udeb
> kernel...
So far the same kernel has been used for the install and later system
and I wouldn't change that behaviour. You only end up with the install
kernel working but the installed kernel not working.
> > 3. When repartitioning a harddisk one has to reboot if any partition
> > is in use to let changes take affect. Using lvm the partition can
> > be mapped seperatly and those mappings can be changed in
> > userspace. One can also move partitions around in the background
> > with lvm and even have a resume feature when the system crashes
> > inbetween (provided there is some space to store resume
> > infos). IIRC evms has some of those features already.
>
> But how often will a partition be in use when you partition it from an
> installer? I don't understand your point, but then, I don't know
> anything about lvm.
.oO( Your low on ram, you setup swap and activate it using the
textmode. Than you switch to graphical mode for a nice and more
comfortable partitioner.)
Well, I don't realy know why people have that problem but I've read
about it a few times on irc so somehow new users trigger that.
But moving partitions esspecially with a "resume after crash" option
and a resize FS option comes in handy. Is there a parted udeb and how
good is it moving partitions?
> > 4. And another realy strange feature: Multi-install. One can stick say
> > 8 harddisks into one system, boot the debian-installer and set
> > those harddrives up as mirrors of each other. Then one installs as
> > allways and when done distributes the harddisks to 8 computers to
> > get 8 identical systems. Ok, realy strange features but might be
> > usefull for pool installs. Maybe network block devices could be
> > used instead of removing the disks.
>
> Heh, cute. This could be useful, but even more useful is to have a
> recreatable installation scenario so you can just put a floppy or a CD
> in a machine, or even better PXE boot it and it just installs with
> predefined values.
One could save the snapshot information to harddisk or via net and
restore it on the next boot.
Or one has a big general purpose image as network block device on a
server and then changes to that on each machine or also as network
blockdevice (or loopback file on nfs). No more linkfarms to get
different configs per host. Just change the files and it gets stored
in the hosts personal snapshot file. :) Buts thats beyond the scope of
debian-installer.
> > A test CD image with the woody live cd is available on
> > rsync://mrvn.homeip.net/images/
> > but beware, its a DSL line so the 50MB bz2 will take ages.
>
> Well, I might as well start downloading it while at work...
>
>
> /Martin
MfG
Goswin
Reply to: