Hi, the RPMs contain the stuff you need to be installed in the destination system, so the minimal content is just the .ko file (eg. /lib/modules/<kernel version>/updates/driver.ko). For the RPM to work correctly in anaconda DD environment, you also have to use Provides: kernel-modules >= minimal-kernel-version. We no longer use modules.cgz and rhdd files. The new format contains /rhdd3 marker file and the structure you saw in the document. Martin ----- Original Message ----- > Thanks Martin! I'm looking into the dlabel container now. I have one > more, > hopefully quick, question regarding the actual RPM: I've been > generating > my driver disks via the mod_devel_kit, which did not require the > generation of an RPM previously. Could you tell me the minimum > contents > for the RPM (e.g., modinfo, modules.cgz, modules.dep, etc.)? This is > for a > storage driver. > > My current(mod_devel_kit) images currently generate the following > top-level output: > common_shell > install > license.txt > modinfo > modules.alias > modules.cgz > modules.dep > modules.pcimap > os_version > pci.ids > pcitable > platform > rc-ks.cfg > rc-span-ks.cfg > rhdd > uninstall > > Now, from the thread, can I infer that my rhdd file is now a rhdd3 > file? > And is it suitable to re-package the remaining contents into the RPM? > > Many thanks, > > Mike > > > On 1/31/12 4:33 AM, "Martin Sivak" <msivak@xxxxxxxxxx> wrote: > > >Hi, > > > >yes this structure describes the layout of data in some container. > >We do > >not really care much if it is .iso, fat, ext3, cpio or squashfs if > >we can > >mount it. > > > >If you want to use the automatic detection (dlabel) you have to use > >container which supports labels. > > > >And that's it. Nothing complicated regarding modules.cgz or > >modules-info > >like in rhel5 format. You just package the modules as rpms and > >create a > >repository for them on some media and using the described structure. > > > >Martin > > > >----- Original Message ----- > >> > >> > >> Hi, First of all, I apologize re-opening such an old thread. But > >> while I have found some clarifications on the file system layout > >> for > >> the ddv3 drivers, along with some patches, I have been unable to > >> actually find any real documentation on how to create a ddv3 > >> driver. > >> For example, I see the structure is as follows: > DDv3 structure > >> > -------------- > >> > / > >> > |rhdd3 - DD marker, contains the DD's description string > >> > /rpms > >> > | /i386 - contains RPMs for this arch and acts as Yum repo > >> > | /i586 > >> > | /x86_64 > >> > | /ppc > >> > | /... > >> But what I don't see is what else it might be looking for. Do I > >> still > >> package these folders into a .iso package? If there's some > >> documentation on this procedure, I'd really appreciate a link to > >> it. > >> The search terms I'm using must be too generic and the only thing > >> that reports anything substantive is ddv3. Unfortunately, > >> everything > >> leads back to this thread. Thanks! > >> Mike > >> > >> _______________________________________________ > >> Anaconda-devel-list mailing list > >> Anaconda-devel-list@xxxxxxxxxx > >> https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > > >_______________________________________________ > >Anaconda-devel-list mailing list > >Anaconda-devel-list@xxxxxxxxxx > >https://www.redhat.com/mailman/listinfo/anaconda-devel-list > > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list > _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
