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

[stage0] 100% automated kickstart from usb-stick



Hello Matt,

I'm back in the office again and have access to mail and subversion :)

Attached .tgz contains a slightly adjusted stage0-creation the way we
use it. The used distribution is Fedora Core 4, but with some small
changes it should work on RHEL/CentOS-5 (I'll be working on that later).

Any comments, ideas are very welcome!


Matthew Richards wrote:
> I could not see a simple method of building a custom Stage0 image
> that would work on unknown scsi hardware without, for example,
> including many SCSI drivers and a method of detecting the hardware
> and insmoding the appropriate driver. Any suggestions?

No, we  also include a lot of drivers for all (our) known hardware.


> Also, have you tried bootstrapping the loader before (exec chroot
> tmp-directory /bin/loader)? When I did this I received a complaint
> about the 'term' variable not being set?

Never noticed/seen this...


> You mentioned a Bugzilla patch that makes it possible to specify more
> than one ks.cfg file. Do you know the Bugzilla number for this
> please, I would like to take a look (btw, I did do a quick scan of RH
> Bugzilla but couldn't find the relevantbug report)?

212146 or https://bugzilla.redhat.com/show_bug.cgi?id=212146

Cheers,
Niels


> Regards, Matt
> 
> 
> 
> ----------------------- Original Message -----------------------
>  
> From: Niels de Vos <niels devos wincor-nixdorf com>
> To: Matthew Richards <Matthew Richards contentkeeper com>
> Cc: anaconda-devel-list redhat com
> Date: Wed, 24 Sep 2008 19:42:45 +0200
> Subject: Re: Can the install method be contained within a kickstart file that is referenced via a %include option
>  
> Hello Matt,
> 
> Matthew Richards wrote:
>> I suppose that having a Stage0 solution would indeed be more elegant
>> than an updates.img solution. I'm guessing that you would not have to
>> rebuild a Stage0 image very often but would have to re-generate an
>> updates.img patch any time you moved to a new version of Anaconda.
> 
> It's not that elegant, just working around limitations of anaconda.
> 
> 
>> I'm curious about this "some kind of detection with two ks.cfgs" that
>> you refer to. It sounds like you are implying that this is done via a
>> custom patch to Anaconda? I can't help wondering if Anaconda is
>> flexible enough to allow this sort of thing without a custom patch
>> by, say, placing 2 ks= options in the bootloader config - but that
>> would probably result in either an error or only one of the ks.cfg
>> files being parsed . . . sorry, just thinking as I type.
> 
> The patch in Bugzilla (#) exactly does make this possible. With this
> patch, a ks= option allows more than one ks.cfg. However, it's just
> an other workaround for missing functionality. I still don't know what 
> the best way would be to implement this correctly in anaconda/kickstart.
> 
> 
>> It is a bit of a challenge to guess what you are getting at with my
>> limited Linux app development knowledge, but I imagine you are
>> proposing to:
>>
>> (1) Build a new initrd.img containing only the resources needed for
>> your basic environment and the tasks that you need to perform ( I
>> have little idea what this would contain but I suppose I could find
>> out from Anaconda-Init source and its dependencies, or from LSB, or
>> from Linux From Scratch or something similar).
> 
> These are not the references I would suggest. It's probably far more 
> easy to look into a standard /boot/initrd-$(uname -r).img. They are now 
> in cpio.gz format, extract it like:
>     mkdir /tmp/my-initrd
>     cd /tmp/my-initrd
>     gunzip /boot/initrd-$(uname -r).img | cpio -id
> 
> The script init is the starting point and can be extended/replaced. It 
> might be adviseable to include a busybox or something like it ;)
> 
>> (2) Write a new Stage0-Anaconda-Init based on Stage1 Anaconda-Init,
>> that will run your tasks and then finish by loading Stage1 initrd.img
>> and running /sbin/loader?
> 
> No, don't write a stage0-anaconda-init. It is more like "stage0 
> bootstraps anaconda". In the init you would do a minimal setup of the 
> system (like a standard initrd.img) and some extras:
> 
> * detect the install target (search for /dev/sda,sdb,...)
> * detect the install source (search for/dev/sda,sdb,http,nfs,...)
> * create a tmp-directory
> * extract the original initrd.img which includes the loader
> * sed ks.cfg and save it in the same tmp-directory
> * exec chroot tmp-directory /bin/loader
> 
> Note that the loader parses /proc/cmdline, therefore you can set 
> ks=file:///tmp/ks.cfg as boot option.
> 
> 
>> How's that for a guess?
> 
> Close, but don't think too complicated. Only try to do the minimal 
> things needed. Everything what the proposed stage0 does can easily be 
> written in shell-scripts.
> 
> Good luck,
> Niels
> 
> 

Attachment: stage0.tgz
Description: application/gz

Attachment: signature.asc
Description: OpenPGP digital signature


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