[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
- From: Matthew Richards <Matthew Richards contentkeeper com>
- To: Niels de Vos <niels devos wincor-nixdorf com>, <anaconda-devel-list redhat com>
- Cc:
- Subject: Re: Can the install method be contained within a kickstart file that is referenced via a %include option
- Date: Fri, 10 Oct 2008 15:27:14 +1100
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)?
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
--
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]