Re: Installing image payloads

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

 



Am Mittwoch, den 09.04.2014, 17:25 +0200 schrieb Vratislav Podzimek:
> On Wed, 2014-04-09 at 17:05 +0200, Fabian Deutsch wrote:
> > Hey,
> > 
> > as mentioned in my earlier email I'm working on oVirt Node.
> > 
> > One special thing about Node is that we deploy an image, forming the
> > rootfs, and not packages which then form the rootfs.
> > 
> > Currently we have our own installer carrying all the necessary bits to
> > do this.
> > 
> > I now wonder if we could probably add some features to anaconda to
> > deploy an image, instead of packages.
> > 
> > The basic idea is that the rootfs is rolled out (as in dd'ed) using an
> > existing image, and not yum (or the other file based solutions).
> > 
> > Note: Important to note here is that the image should be copied/dd'ed as
> > is, not file-wise copied into a new FS (liek it's happening with the
> > liveimg payload IIUIC).
> > 
> > The idea is to roll out the image into a LV, then create a write-able
> > snapshot or thin volume and use that as the rootfs.
> > 
> > Form that point on there shouldn't be a to big difference between a file
> > based deployment and the image based one.
> > Ok - Granted. There will surely be some more details which need to be
> > addressed, e.g. the bootloader.
> > 
> > Any thoughts on this and can someone maybe tell if this is doable with
> > anaconda?
> Maybe a stupid idea, but:
> What do you need/expect from the installer? If there is an image that
> should be dd'ed somewhere, I somehow cannot see any place where the
> installer could bring some benefits.

Hey,

much of th ework between our installer and anaconda is redundant, think
of storage discovery and enumeration (also partitioning), iSCSI
initialization, multipath, and EFI support  ... Just to name the big
items.

Node is somewhere between embedded and a minimal install. It is not
embedded, because we don't make assumptions about the hardware where
Node get's installed, thus we don't know e.g. what kind of disks and how
many disks are there (which you typically know in an embedded world).

Further more we could use the functionality present in anaconda to do
the post-deployed configuration, e.g. adding a user or configure the
network (using the user and network ks directives).

Greetings
fabian

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

[Index of Archives]     [Kickstart]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [Yosemite Photos]     [KDE Users]     [Fedora Tools]
  Powered by Linux