[Date Prev][Date Next] [Thread Prev][Thread Next]
re: [stage0] 100% automated kickstart from usb-stick
- From: Matthew Richards <Matthew Richards contentkeeper com>
- To: Niels de Vos <niels devos wincor-nixdorf com>
- Cc: anaconda-devel-list redhat com
- Subject: re: [stage0] 100% automated kickstart from usb-stick
- Date: Wed, 12 Nov 2008 15:17:23 +1100
Firstly let me say thanks for persisting with this issue and for sharing your
work. Secondly, sorry for the
long delay in my response, I have been focused on other parts of my project to
the exclusion of pretty
much all else.
I would like to take a look at your stage0-creation but never received the
attachment... I think my
email client screwed it up because it appears as a block of garbled text at the
end of your email.
I did manage to spend some more time on the issue of automatic USB drive
identification before my
attention was diverted. I was lucky enough to have a friend who is also a
developer go over the
anaconda code with me.
We think that you may be able to make Anaconda-18.104.22.168 (RHEL/CentOS 5.2)
support a HDD install
method where the HDD is identified by its file system label. To do this we
think you would need to add
some code to the Anaconda loader that would allow it to convert a file system
label to a device name
The idea we had was to borrow some code from e2label that would allow us to
label in from the file system super block. Then all we would need to do is add
a little logic to go through
the devices visible to the kernel that would likely be a USB drive and read
their f/s labels until we found
a match then pass that device name back for mounting in the normal manner.
After a quick look at the later versions of Anaconda I think they are doing
something similar to this
anyway. Although, the differences between 22.214.171.124 and the latest one a vast
so it's hard for me to be
Of course the problem with doing this is that you have to update the changes
every time you move to
a new version of Anaconda, but hopefully that would not go on for too long
before the version that
natively supports mounting by f/s label came along and then you could abandon
All the best,,
----------------------- 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: Tue, 21 Oct 2008 14:41:54 +0200
Subject: [stage0] 100% automated kickstart from usb-stick
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
This is a multi-part message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1
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=3D212146
> 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 fil=
e 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=3D 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=3D 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=20
> 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=20
> bootstraps anaconda". In the init you would do a minimal setup of the=20
> 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=20
> ks=3Dfile:///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=20
> things needed. Everything what the proposed stage0 does can easily be=20
> written in shell-scripts.
> Good luck,
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
-----END PGP SIGNATURE-----
[Date Prev][Date Next] [Thread Prev][Thread Next]