Re: Native Anaconda Support for Installs via USB Flash Stick

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

 



Title: Re: Native Anaconda Support for Installs via USB Flash Stick
David,
  Thanks for the quick reply!  This sounds like it is worth pursuing.   The only issue I see here is what to put as the option for the “install” command in the kickstart.  Obviously, I can’t use the “cdrom” directive that we usually use, and when the kickstart is being written, we won’t know what the parameters to the harddrive directive would be.  The documentation seems to say that the install command is optional anyway.  Should I just skip the command entirely and just depend upon the repo that we’ll set up in the %pre script?

Thanks,
  Jason


On 4/1/09 5:36 PM, "David Cantrell" <dcantrell@xxxxxxxxxx> wrote:

On 04/01/2009 01:01 PM, Jason Maestri wrote:
>    The company I work for has a need to be able to install Fedora onto
> several different hardware configurations via a USB thumb drive.  As far as
> I can currently tell, the only way to install via a thumb drive is to treat
> it like a hard drive and tell Anaconda which device it is.  We would like to
> see something like the "cdrom" install method, where we would just say
> "flash" in the kickstart and kernel options, and then Anaconda would take
> care of the rest.
>
>    I have been looking into this for the past few days and have begun to
> modify the source accordingly.  I am adding a flashinstall.c module to the
> loader, and the next step would be to modify the python code of Anaconda
> proper.

Not more code in the loader!

>    Once the loader is ready to pass things off to Anaconda, there are two
> ways (as I see it) to proceed.  Anaconda itself, like the loader, can be
> modified to find the flash device and install from there, or the loader can
> just modify the kickstart file when it is installing it into /tmp/ks.cfg.
> In the latter case, it would create an hd: entry so that when Anaconda takes
> over, it would just pretend it was installing from a normal hard drive.
> That method is a little more straightforward, having fewer new code paths to
> maintain, but nothing else seems to do anything like that.
>
>    Does anybody have any thoughts about the best way to do this?  Also, once
> it is done and working, is this something that the community would be
> interested in having?  I would love to see this go into the upstream
> Anaconda source so that others can use it.  Either way, the source code will
> be available should anybody care to peruse it.
>
> Thank you for your time in responding.

Based on what you're describing, I think we provide enough in the
installer to do what you want without having to modify the source.
Here's my brainstorm:

1) Boot from USB jumpdrive, we can already do this.

2) Build custom USB boot media for your company which includes a
kickstart file and modifies the boot arguments to pass the correct
'ks' argument to the installer so it uses your kickstart file.

3) The kickstart file can be minimal, mostly you just want to control
where packages are coming from (or automate as much as you want).  With
the 'repo' command, you can do that.

    a) Include a %pre script in your kickstart file that finds the
       packages on your USB media.  The %pre script writes out
       /tmp/repoks.cfg, which contains 'repo' commands that point to
       the location you found.

    b) Add a '%include /tmp/repoks.cfg' in the kickstart file so the
       kickstart file always includes the repo on the USB media.

    c) Add %packages and any other kickstart commands you want to
       automate the install.

Done.

--
David Cantrell <dcantrell@xxxxxxxxxx>
Red Hat / Honolulu, HI

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



--
Jason C. Maestri
Senior Software Engineer
Solera Networks
O (801) 623.5192
C (801) 867.7654

http://www.soleranetworks.com





The information in this e-mail and in any attachments is confidential and may be privileged. If you are not the intended recipient, please destroy this message, delete any copies held on your systems and notify the sender immediately. You should not retain copy or use this e-mail for any purpose, nor disclose all or any part of its content to any other person.
_______________________________________________
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