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.
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
