Booting Fedora from LVM with grub2

Peter Jones pjones at
Fri Mar 30 13:29:39 UTC 2012

On 03/29/2012 10:15 PM, Conan Kudo (ニール・ゴンパ) wrote:
> On Thu, Mar 29, 2012 at 7:18 PM, Chris Lumens <clumens at
> <mailto:clumens at>> wrote:
>      > How is that possible to implement with a:
>      > 1. Show GUI, write kickstart.
>      > 2. Process kickstart.
>      > design?
>     We're not literally going to have one program that you use to construct
>     a kickstart file, write the file out, and then spawn a separate program
>     do to the processing of.  We are using kickstart as the data store
>     internally (via pykickstart) and having one program operate on it.  The
>     only writing will be towards the end of installation, where we spit out
>     /root/anaconda-ks.cfg.
>     A lot of these tasks like figuring out authentication information and
>     adding extra users can be prompted for while filesystems are being
>     created, then actually take effect and augment the ksdata after packages
>     are laid down.  They will be reflected in the final anaconda-ks.cfg.
>     Some other tasks may not map to existing kickstart at all (yet).
>     - Chris
>     --
>     devel mailing list
>     devel at <mailto:devel at>
> If we go for doing something like that, is there any reason to keep firstboot
> around? Couldn't we stuff the actions done in firstboot into anaconda with this
> newer asynch design?

Well, there are some reasons on each side there, and it certainly merits further

Personally, I've got some skepticism about running firstboot-style plugins in
the installer. For those that need that (and they are out there), it's a whole
lot easier to put things like that in the packageset and have them run at 
firstboot than to get them into the running install image. But if we decide it's
worth it, that's probably a problem we could engineer around, too.


More information about the devel mailing list