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

Re: Can the install method be contained within a kickstart file that is referenced via a %include option

Hi Neils,

I had a look into your suggestion of customising a standard /boot/initrd-$(uname -r).img in order to create the Stage0 image.

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?

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?

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)?


----------------------- 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,

WINCOR NIXDORF International GmbH 
Sitz der Gesellschaft: Paderborn 
Registergericht Paderborn HRB 3507
Geschäftsführer: Eckard Heidloff (Vorsitzender), Stefan Auerbach, Dr. Jürgen Wunram
Vorsitzender des Aufsichtsrats: Karl-Heinz Stiller 
Steuernummer: 339/5884/0020 - Ust-ID Nr.: DE812927716 - WEEE-Reg.-Nr. DE44477193

Diese E-Mail enthält vertrauliche Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und vernichten Sie diese E-Mail. Das unerlaubte Kopieren sowie die unbefugte Weitergabe dieser E-Mail ist nicht gestattet.

This e-mail may contain confidential information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorised copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

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