[Revisor-users] adding rpms to respin dvd

Sun Oct 21 00:24:44 UTC 2007

----- Original Message ----
From: Jeroen van Meeuwen <kanarip at kanarip.com>
To: Revisor User Discussion and Support List <revisor-users at fedoraunity.org>
Sent: Saturday, October 20, 2007 8:42:13 AM
Subject: Re: [Revisor-users] adding rpms to respin dvd

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.

* I understand that indeed, but anyone, who understands what this tool of yours is, realizes its potential.
* That if you added a hook before the genisoimage, mkisofs, for people to customize the
* isolinux.cfg file, add extra kick start files, binaries. one could have a backup of the configured system(s)
* with the exception of their live data, these configured systems, may even be able to be a live dvd on the same
* backup dvd, that is where I'm going with your tool, even if I have to deconstruct your iso image, modify
* the above and re genisoimage the tree, because you deleted yours, or I havent found it yet.
* Thanks for doing the heavy lifting, repos, rpms, dependacies, etc........

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
> 

* I finaly figured this out, RTFS, RTFM,  revisor doe not expand $releasever, $basearch, so
* when you copy your repos from /etc/yum.repos.d into your /etc/revisor/conf.d file you
* the user must expand these to literal values. LIKE DUH I see the lite.

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.

* I've seen this coming and have decided to use a custom sort / merge script to include
* all my packages into one mater kickstart file that I feed revisor to create the iso image.
* and use the include directive in the individual host kick start files, that are called from 
* isolinux.cfg. copy_dir sounds interesting, and my lighten my load on creating / recreating
* what I want, but I don't understand, where is this directive used, which config file

> 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.

* with the last git pull, and extra debug info from the updated what you need to do page
* was able to build new rpms, install, and the extrat debug output was great in figuring out where
* my problems were. Thanks Some problems were in my sort merge of my system kick start files
* into the master kick start file used by revisor, found using the debug output from revisor
* and examining the /var/tmp/revisor-yumcahe dirs

* One thing I've noticed, or a couple not really related to revisor, but a close next door neighbor
* Anaconda installs packages it does not have keys for (warnings in install.log), which begs the question how do I install keys
* before the big install, and how do I get anaconda to reject packages it does not have keys for

* pointers to more info on copy_dir, the environment of %pre, %post in kickstart files
* more than welcome.
* thanks for the program, the help, the updated document pages all helping move this along.
*    Arno
-- 
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
_______________________________________________
Revisor-users mailing list
Revisor-users at fedoraunity.org
http://lists.fedoraunity.org/mailman/listinfo/revisor-users

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.fedoraunity.org/pipermail/revisor-users/attachments/20071020/1583474f/attachment-0001.html 