[Revisor-users] adding rpms to respin dvd

Jeroen van Meeuwen kanarip at kanarip.com
Sat Oct 20 13:42:13 UTC 2007


Arno Karner wrote:
> the way I'm trying to do it, is create your own yum repository
> add that repository to the /etc/revisor/conf.d config file you will be using
> using the gui select your packages, or use a kickstart file.

This is the recommended way to add packages to a Revisor compose, indeed.

> Some third party repos work, others don't (unknown reason)
> 
> If you want more than one boot option with a kickstart file, you will 
> have to deconstruct the resping
> edit the isolinux.cfg file and add your extra kickstart files and regen 
> the iso image with the added files
> 

Could you please log a ticket at 
http://hosted.fedoraproject.org/projects/revisor to reflect this 
requirement? We could possibly let one specify their own isolinux.cfg to 
use, or provide stanzas to populate the isolinux.cfg with. Thanks in 
advance.

> Unknown:
>   How to use %include directive in kick start files, so that host1, 2, 3 
> can include common
>   disk partitioning, common packages, and still include there own config 
> rpms
>   trying to use any kind of a path in the %include statment won't work 
> for the
>   /etc/revisor/conf.d and the cdrom image, but what I've read on the 
> kickstart spec, they don't
>   mention if they %include file is relative to the directory of the main 
> kickstart file
> 

%include is relative to $PWD, which is bad when trying to use the 
%include statements during compose. However since the compose only uses 
the %packages section of the kickstart file, it is recommended you 
specify the kickstart file that has the complete %packages section, and 
%include from there.

Using copy_dir you would be able to specify a directory (tree) on the 
host system to be copied onto the media, under files/. If you put your 
%include'd kickstart files there, you can use %include 
/mnt/source/files/ks-include.cfg.

Mind that during compose Revisor will attempt to include any %include 
kickstart files, but won't fail if it fails to find the included file. 
As far as I know, it doesn't even complain which means there could be 
made some improvement there. I'm not sure whether pykickstart throws bak 
a warning or exception that Revisor could catch though.

> Problems:
>   not all the files from kickstart rpms are included (reason unknown)

We've had reports from another user (jhp, thanks!) and troubleshooted 
with him only to find out there was a problem with the architecture not 
being set when loading another model. From the CLI, this never was a 
problem because Revisor doesn't load any default model but from the GUI 
mode it selects f7-i386 as a default, setting the architecture to i386. 
When loading (for example) f7-x86_64, the architecture (or actually 
compatible architecture list) in yum wasn't updated. We've fixed this 
problem in GIT.

>   rpms are not loaded in the right order (dependency sorting 
> problem)(maybe my problem not putting Requires: in the right place in 
> the spec file)
>   rpms that are missing, not always identified during build (reason 
> unknown)(identified by anaconda at install time)

There may be a "compatibility" problem in the comps file that is used 
during compose, and the one that ends up on the media. Revisor in GIT 
now has a feature that is supposed to fix that (--revisor-comps which is 
off by default), so that the comps file that ends up on the media 
reflects the contents of the repositories during compose.

>   the anaconda generated kick start file, does not reflect what packages 
> where installed via kickstart, gets the disk partitioning though
> 
> Admissions:
>   I know not all my rpms are setup right yet, to be on the first disk, 
> always put mine on second disk and installed with a shell script
>   working on checking and fixing broken rpms, and trying to identify why 
> they not included on the respin media
> 
> Testing:
>   next test will pull the httpd logs, and compare with what packages are 
> missing, and what packages can be installed on remote
>   machines using the same yum repo that revisor is suppose to use.
> 

Have you tried using the --debug flag on revisor and examine it's rather 
verbose output? Along with an increased yum debuglevel this should be so 
verbose, that any problems in Requires: and Provides: should be 
expressed in the output.

-- 
Kind regards,

Jeroen van Meeuwen
-kanarip

--
http://www.kanarip.com/
RHCE, LPIC-2, MCP, CCNA
C6B0 7FB4 43E6 CDDA D258  F70B 28DE 9FDA 9342 BF08


More information about the Revisor-users mailing list