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

re: [stage0] 100% automated kickstart from usb-stick

Hi Niels,

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- (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
when mounting. 

The idea we had was to borrow some code from e2label that would allow us to 
read the
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 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 
the updates.

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)
Content-Type: multipart/mixed;

This is a multi-part message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=3D212146


> Regards, Matt
> ----------------------- Original Message -----------------------
> =20
> 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
> =20
> 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,
> Niels

Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Version: GnuPG v1.4.5 (GNU/Linux)



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