FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo User

 
 
LinkBack Thread Tools
 
Old 09-22-2008, 12:47 PM
Matthew Richards
 
Default Can the install method be contained within a kickstart file that is referenced via a %include option

Hi Jerry,

Thanks for the suggestion, I'll give it a whirl.

One question that springs to mind , do you know if identifying the USB drive
via its label (which is how I am identifying it in my %pre script
coincidentally) will prevent Anaconda from seeing the USB drive as a viable
install target? Do you think I should also include an option of (ignoredisk
--drives=LABEL="name") in the kickstart file, and is that syntax even
supported?

Just some thoughts . . . as I say, I will give it a whirl.

Thanks again.

Matt.


----------------------- Original Message -----------------------

From: Jerry Vonau <jvonau@shaw.ca>
To: Discussion of Development and Customization of the Red Hat Linux Installer
<anaconda-devel-list@redhat.com>
Cc:
Date: Mon, 22 Sep 2008 07:31:57 -0500
Subject: Re: Can the install method be contained within a kickstart file that
is referenced via a %include option

Matthew Richards wrote:
> Apologies in advance for the long post, and if this question is being posted
in
> the wrong place. It is rather kickstart oriented but I think this is the
right
> place for it.
>
> Short version:
>
> In a kickstart install, can the install method (specifically 'harddrive') be
> contained within a file that is referenced via a %include option in the main
> kickstart file?
>
> Long Version:
>
> I am re-spinning CentOS 5.2 (Anaconda 11.1.2.113-1) with the aim of making it
> install unattended from a USB flash drive.
>
> The USB drive is identified differently depending upon the hardware
> configuration of the system with which it is booted. Generally speaking if
the
> system has only IDE disks then the USB drive becomes /dev/sda. If the system
> has a SCSI or SATA disk then the USB drive becomes /dev/sdb, etc.
>
> The problem I face is that Anaconda sees the USB drive as a viable install
> target and bootloader option. To prevent Anaconda from installing to the USB
> drive I am using the harddrive, ignoredisk and bootloader kickstart options,
> e.g.
>
> harddrive --partition=/dev/sda1 --dir=/iso
> ignoredisk --drives=sda
> bootloader --driveorder=hda,hdb,hdc,hdd,sda,sdb,sdc,sdd --location=mbr
>
> (Ok, I know the configuration of the bootloader option is ugly but it meets
my
> requirements for now and my respun distro will probably never be installed on
a
> system with more than 3 local disks)
>
> I cannot hard code these kickstart options because the USB drive identity
> changes with each different hardware configuration, so I have used a similar
> approach to the dynamic partitioning example given in the %pre section of the
> kickstart doco. That is, I am using the %pre section to probe the install
> target and identify the USB drive and then generate a kickstart file-part
that
> contains the appropriate harddrive, ignoredisk and bootloader options as
> outlined above. The kickstart-part is then included in the main kickstart
file
> via the %include option.
>
> It seems that when the install method is not in the main kickstart file that
> Anaconda prompts for the install method. I believe this is because it does
not
> run the scripts in the %pre section until after it has loaded the stage2
image,
> for which it needs to know the install method which is why it prompts the
user
> and puts and end to the whole unattended experience. My kickstart file looks
> something like this:
>
> %include /tmp/ks-part
> %include /tmp/ks-common # this has all of my other kickstart options in it.
> %pre
> # shell script to identify USB drive and echo 'harddrive' and 'ignoredisk'
> options to /tmp/ks-part
>
> Can anyone suggest a way around this or an alternative solution please?
>
> Two that have come to mind while writing this post are (1) use custom udev
> rules added via the initrd.img file to ensure that usb drive is always
mounted
> as /dev/sdX and then hard code this setting into the kickstart file, (2) use
a
> custom anaconda installer update (e.g. kickstart.py) to perform the dynamic
USB
> drive identification and exclusion, instead of using the %pre section of
> kickstart.
>
> Thanks.
>
> Matt

You can try labeling the usb drive, then use that label to identify the
usb drive at the boot prompt with ks=LABEL="name":/ks.cfg. and
method=hd:LABEL="name"/

Not sure if your version of anaconda will support that syntax.

Jerry

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-22-2008, 01:15 PM
Jerry Vonau
 
Default Can the install method be contained within a kickstart file that is referenced via a %include option

Matthew Richards wrote:

Hi Jerry,

Thanks for the suggestion, I'll give it a whirl.

One question that springs to mind , do you know if identifying the USB drive
via its label (which is how I am identifying it in my %pre script
coincidentally) will prevent Anaconda from seeing the USB drive as a viable
install target?


Think the usb drive becomes a "protected partition", and thus becomes
unavailable as an install target.


Do you think I should also include an option of (ignoredisk
--drives=LABEL="name") in the kickstart file, and is that syntax even
supported?


Not sure, I just tried the LABEL=drive trick last week, to my surprise
it worked straight away with F9. Sorry I don't recall if the usb-drive
showed up while partitioning.


Jerry

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-22-2008, 11:56 PM
Matthew Richards
 
Default Can the install method be contained within a kickstart file that is referenced via a %include option

Hi Jerry,

I've tried the LABEL= option but it did not work.

Thanks again for your suggestion, but the version of Anaconda I am using
(11.1.2.113-1) does not seem to support the LABEL= option.

Anaconda just complains that it cannot find the kickstart file when I use the
LABEL= option. Also, it seems that the LABEL= option is not supported for the
install method either as when I manually tell Anaconda where the kickstart file
is located it then proceeds to prompt me for the install method, seemingly
ignoring the method=hd:LABEL="name"/<dir> option I gave it.

I assume this is because I am using an older version of Anaconda. I have read a
few brief comments about improved options support and about the concept of a
"protected partition" in the later versions of Anaconda, but I think I need
something very recent (e.g. F8, F9) to get access to these options.

I suppose I could always try to backport the options via the Anaconda updates
method. That might be worth a try, but I would be getting into unknown
territory there as I am no python programmer. If I was I would just work my way
thorough the source for Anaconda and answer my own questions instead of
bothering you good folks :-)

For now I intend to follow up on the suggestion by Niels de Vos, and I suppose
I should investigate the possibility of using the Anaconda updates method to
get access to the LABEL= option support. A little lateral thinking about the
problem couldn't go astray either.

Regards,

Matt



----------------------- Original Message -----------------------

From: Jerry Vonau <jvonau@shaw.ca>
To: Discussion of Development and Customization of the Red Hat Linux Installer
<anaconda-devel-list@redhat.com>
Cc:
Date: Mon, 22 Sep 2008 08:15:24 -0500
Subject: Re: Can the install method be contained within a kickstart file
that is referenced via a %include option

Matthew Richards wrote:
> Hi Jerry,
>
> Thanks for the suggestion, I'll give it a whirl.
>
> One question that springs to mind , do you know if identifying the USB drive
> via its label (which is how I am identifying it in my %pre script
> coincidentally) will prevent Anaconda from seeing the USB drive as a viable
> install target?

Think the usb drive becomes a "protected partition", and thus becomes
unavailable as an install target.

> Do you think I should also include an option of (ignoredisk
> --drives=LABEL="name") in the kickstart file, and is that syntax even
> supported?
>
Not sure, I just tried the LABEL=drive trick last week, to my surprise
it worked straight away with F9. Sorry I don't recall if the usb-drive
showed up while partitioning.

Jerry

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 09-23-2008, 04:13 AM
Matthew Richards
 
Default Can the install method be contained within a kickstart file that is referenced via a %include option

*
Hi Niels,
*
How are you going with your Stage0 solution?
*
After giving it some consideration, I have to say that I am probably looking for a simpler solution if*one exists :-) I am not a*developer*and therefore do not have all the necessary skills to write my own loader, etc, which is what I think you are proposing, right?
*
While I am comfortable at a high level with the concepts associated with the the loader environment in stage1, and can kind of muddle my way through the C that makes up the loader, at this stage I*cannot personally justify*the cost in time associated with getting my head around the loader and its environment to a point where I could reproduce it.
*
That being said, I hope I have properly understood what you are proposing and am not barking up the wrong tree :-)
*
I wonder if it is necessary to replace the stage1 image entirely. I am inclined to hack things together when I cannot find an elegant or supported solution to a problem.
*
For instance, would it be possible to put a wrapper of sorts around the loader binary that performed the required tasks before passing control to the loader? Of course, this would depend upon a number of things including what state the stage1 environment was in when the loader was executed by init.
*
Can you please outline how you propose to construct this Stage0 solution in a little more detail? Are you indeed proposing to make custom mods to init and/or loader, or are you thinking of something else?
*
Regards,
*
Matt

*

----------------------- Original Message -----------------------
**
From:*Matthew Richards <Matthew.Richards@contentkeeper.com>
To:*<anaconda-devel-list@redhat.com>
Cc:*
Date:*Mon, 22 Sep 2008 23:07:05 +1000
Subject:*re[2]: Can the install method be contained within a kickstart file that is****referenced via a %include option
**
Hi Niels,

This certainly sounds promising. It has been a while since I have been into
stage1 of the installer (think RH73 days) so I do not recall exactly how the
early stages of the installer string together but I will look into this and get
back to you with any comments I have.

Regards,

Matt

----------------------- Original Message -----------------------
*
From: Niels de Vos <niels.devos@wincor-nixdorf.com>
To: Discussion of Development and Customization of the Red Hat Linux Installer
<anaconda-devel-list@redhat.com>
Cc:
Date: Mon, 22 Sep 2008 14:33:04 +0200
Subject: Re: Can the install method be contained within a kickstart file that
is ***referenced via a %include option
*
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1CD7799D50048DB8F38AEA59
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hello Matt,

Matthew Richards wrote:
> The USB drive is identified differently depending upon the hardware=20
> configuration of the system with which it is booted. Generally
> speaking if the system has only IDE disks then the USB drive becomes
> /dev/sda. If the system has a SCSI or SATA disk then the USB drive
> becomes /dev/sdb, etc.

I'm having the same problem here... The solution I'm thinking of is a
little bit different. It started as a solution for installing over the
network where it is required to have static ip-addresses configured,
but booting (installation) over PXE is required. In this case the
static IP-address is given on the commandline in a pxelinux.cfg.

(Backgound for the wondering readers: booting and 100% functionality
without delays if there are network problems.)

The solution needs one extra step/stage. Normally anaconda does a two
stage installation. Stage1 is the loader, stage2 the installer in
Python which contains a nice GUI. The extra step used is in our case
stage0. Stage0 is an initrd which does a minimal setup of the hardware
and some small ks.cfg editing with sed. After preparing ks.cfg, the
original initrd from the install-set is downloaded, extracted and
'started'.

In my opinion, in a stage0 like the above it would be possible to
detect SATA/IDE/USB drives and replace/change ks.cfg with correct
values.

Any thoughts?

Niels


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

iD8DBQFI15CB5KAkGQPO/QoRAshfAJ4/s8u9voUI52Qt8aoG/QfTBH1YwACfUBBY
WGNpBHcg9Lb+0XYOWGCqXEA=
=hokA
-----END PGP SIGNATURE-----

--------------enig1CD7799D50048DB8F38AEA59--


--===============1199916769==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--===============1199916769==--
--===============1199916769==
Content-Type: text/plain; charset="us-ascii"; charset="us-ascii"

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
--===============1199916769==--

<html><body><pre>
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

</pre></body></html>

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 10-10-2008, 04:27 AM
Matthew Richards
 
Default 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)?

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.


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 07:56 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org