Might need
Newsgroups: linux.redhat.install, alt.linux, be.comp.os.linux, comp.os.linux.hardware, linux.redhat, alt.comp.linux Date: 2003-05-12 02:34:56 PST
Dear,
I'm trying to install RH9 from my harddrive which has got a vfat (DOS) partition. I copied the redhat/rpms and redhat/base dirs from the 3 RH9 CD's to the root of my dos partition (c:\redhat) I copied the DOSUTILS dir from the RH9 CD1 to c:\install\dosutils I want to install RH9 using a kickstart file which is located in the root (c:\) of the DOS partition. I start my installation with the following line : loadlin c:\install\dosutils\autoboot\vmlinuz initrd=c:\install\dosutils\autoboot\initrd.img ramdisk_size=9216 ks=hd:hda1/ks.cfg
I defined my installation path as followed in my kickstart file (ks.cfg): harddrive —partition=hda1 —dir=/redhat harddrive —partition=hda1 —dir=/redhat/ harddrive —partition=hda1 —dir=/ install —harddrive —partition=hda1 —dir=/redhat install —harddrive —partition=hda1 —dir=/redhat/ install —harddrive —partition=hda1 —dir=/ install —harddrive=hda —partition=hda1 —dir=/redhat install —harddrive=hda —partition=hda1 —dir=/redhat/ install —harddrive=hda —partition=hda1 —dir=/
None of these options seem to work. I keep getting the message box seen on tis page
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/install-guide/s1-begininstall-hd.html
"What partition and directory hold the CD (iso9660) images for Red Hat Linux? If you don't see the disk drive you're using listed here, press F2 to configure additional devices."
The directory holding the images always shows the dir I specified in the ks.cfg file.
I this screen is shown, this would mean that the location of the Redhat files cannot be found on the harddrive ? Anyone got an idea ?
Regards,
Dennis
http://www.aarnet.edu.au/redhat/build.txt
Start with the Red Hat enterprise configuration.
SMP
Download kernel
Add -ac pathces to get aacraid
Add patches from Dell to get megaraid
/etc/lilo.conf
Might need
options aic7xxx no_probe
/etc/modules.conf
Might need
options aic7xxx no_probe
PERC2/SC firmware older than v3.13 has known problems and must be upgraded. This RAID contoller is used in the Dell 2400.
bash$ newgrp html bash$ umask 002 bash$ ftp -i mirror.aarnet.edu.au bash$ exit
bash$ newgrp html bash$ umask 002 bash$ cd /home/redhat/linux/7.1/en/os/i386/RedHat/RPMS/
For each update
bash$ ls man-[0-9]*.rpm man-1.5h1-20.i386.rpm bash$ rm man-1.5h1-20.i386.rpm bash$ cp /home/redhat/updates/7.1/en/os/i386/man-1.5i2-0.7x.5.i386.rpm .
Then when finished merging the updates
bash$ rm /home/redhat/linux/7.1/en/os/i386/RedHat/base/hdlist*
bash$ cd /usr/lib/anaconda-runtime/
bash$ ./genhdlist --withnumbers \
--hdlist /home/redhat/linux/7.1/en/os/i386/RedHat/base/hdlist \
/home/redhat/linux/7.1/en/os/i386
bash$ cd /home/redhdat/linux/
bash$ mv 7.1 7.1-20010921
bash$ exit
The date comes from the e-mail header "Date:" in the mailing to redhat-watch-list@redhat.com. It isn't the advisory's "Issue date" as these are often days before the issue of the advisory and need not be monotonically inceasing.
Obtain the afaapps RPM from http://support.dell.com/. Confusingly the RPM is stored in the file aacraid-util-rh7.1.tar.gz or PRC2UTL2.zip. The documentation for this utility is at
http://docs.us.dell.com/docs/storage/57kgr/cli/en/
Obtain the dellmgr, megaflash, megamon and megaraid-snmp RPMs from http://support.dell.com/. Confusingly the RPMs are stored in the file megaraid-util-rh7.1.tar.gz.
Merge these and other Dell-specific RPMSs using the process above.
Edit
/home/redhat/linux/7.1-.../en/os/i386/RedHat/base/comps
and add the lines
i386: 1 Dell PowerEdge Utilities {
i386: dellmgr
i386: megaflash
i386: megamon
i386: megaraid-snmp
i386: afaapps
i386:}
The "comps" file format is not documented, but is reasonably obvious. The mysterious "4" at the top of the file is a version number for the file format. The sections are of the basic form
<wanted> <options> <component> {
<dependency>
...
<package>
...
<optionalpackage>
...
}
Where <wanted> is 1 where the package defaults to being installed, 0 otherwise. <package> is the RPM package.
<options> ::= <nil> <options> ::= --hide
<dependency> ::= <nil> <dependency> ::= @ <component>
<optionalpackage> ::= ? <dependency> {
<package>
...
}
All lines appear to have the form
<condition>: <text>
<condition> ::= <nil> <condition> ::= !<condition> <condition> ::= <architecture>: <condition> ::= (<expr>): <expr> ::= <term> <expr> ::= <term> and <term> <term> ::= arch <architecture> <term> ::= arch !<architecture> <term> ::= lang <language> <term> ::= lang !<language> <architecture> ::= i386 | ia64 | sparc | alpha <language> ::= <lang>[_<region>[.<codeset>]] <lang> ::= ja | cs | pl | ro | sl | sk | tr | uk | ru | ... <region> ::= BR | CN | HK | TW | GB | CA | ES | ... <codeset> ::= gb2312 | ...
The Red Hat Linux kernel is usually a standard Linus kernel with the stable parts of the Alan Cox -ac stream.
The -ac stream tracks the later bug fixes to the Dell megaraid controllers.
Patches for the Dell aacraid controllers can be found at
Get the software
bash$ ftp mirror.aarnet.edu.au ftp> cd pub/linux/kernel/... ftp> get kernel...tar.gz2 ftp> cd pub/linux/kernel/people/alan/... ftp> get patch...bz2 ftp> quit
Unpack and apply Alan's patches
bash$ bzip2 -dc linux-2.4.9.tar.bz2 | tar xf - bash$ cd linux bash$ bzip2 -dc ../patch...bz2 | patch -p1 patching file ...
Check that the aacraid patches aren't in the kernel yet.
bash$ find . -name 'aacraid*' -print
Get the aacraid software from http://www.domsch.com/linux/ and apply it.
bash$ cd .. bash$ wget http://www.domsch.com/linux/aacraid/linux-2.4.9-aacraid-20010816.patch bash$ cd linux bash$ patch -p1 < ../linux-2.4.9-aacraid-20010816.patch
Manually fix rejected chunks
find . -name '*.rej' -print
Check the currently used compiler
bash$ less Documentation/Changes The recommended compiler for the kernel is gcc 2.95.3 or .4... Note that gcc 2.7.2.3 is no longer a supported kernel compiler... egcs-1.1.2 has register allocation problems... The Red Hat gcc 2.96 compiler subtree can also be used to build this tree. You should ensure you use gcc-2.96-74 or later. gcc-2.96-54 will not build the kernel correctly.
bash$ gcc --version 2.96 bash$ rpm -q gcc gcc-2.96-85
Install the configuration used to build the Red Hat kernel
bash# rpm -ivh kernel-source
Configurations are in /usr/src/linux-2.4.3/configs/. Check that aacraid and megaraid are made into modules
bash$ mkdir configs bash$ cp /usr/src/linux-2.4.3/configs/* configs bash$ grep 'CONFIG_SCSI.*RAID' configs/* CONFIG_SCSI_AACRAID=m CONFIG_SCSI_MEGARAID=m
Alter /usr/lib/anaconda-runtime/mk-images.i386 to add megaraid and aacraid. Add the RAID modules whereever the SCSI drivers (say aic7xxx) are mentioned.
LOCALMODULES="$COMMONMODULES BusLogic aic7xxx megaraid aacraid ncr53c8xx sym53c8xx $IDEMODS $SCSIMODS"
Alter /usr/lib/anaconda-runtime/upd-instroot to add megaraid and aacraid.
Configure the kernel based upon the Red Hat Linux configuration.
bash$ cp configs/... .config bash$ make oldconfig
This displays kernel parameters that were altered since the Red Hat kernel was built. Record these in AARNet.txt and keep a copy of the changed configuration variables handy in newconfig.txt.
bash$ make dep bash$ make rpm
You'll need to have /usr/src and below owned by the building user (preferrably not root).
Repeat this step for each kernel configuration. You find the simplest way to do this is to repeat
bash$ cat configs/... newconfig.txt > .config bash$ make dep bash$ make clean bash$ make spec bash$ make rpm bash$ mv kernel-2.4.9ac15.rpm kernel-2.4.9ac19.smp.i686.rpm
for
kernel-...i386.rpm kernel-...i586.rpm kernel-...i686.rpm kernel-smp-...i386.rpm kernel-smp-...i586.rpm kernel-smp-...i686.rpm kernel-enterprise-...i686.rpm
Note that the kernel-BOOT…i386.rpm configuration is signifacntly different from the other kernels and the new configuration variables should be tailored by hand to be minimal.
Generate kernel-headers-…i386.rpm, kernel-pcmcia-cs-…i386.rpm, kernel-doc-…i386.rpm somehow !!!
Alter the file
/home/redhat/linux/7.1-…/en/os/i386/AARNet.txt
to sumarise the differences between this build and stock Red Hat Linux.
$Id$
https://listman.redhat.com/pipermail/seawolf-list/2001-July/008252.html
Sat, 14 Jul 2001 20:54:30 -0400
I'm working on building updated ISOs for Red hat 7.1. I thought I had done everything correctly, but the install blew up in my face when anaconda didn't like something it saw. I've seen this before, and it is usually indicative of a bad build or burn. I wanted to review what I did, and see if someone could point out any glaring errors they might see.
I started by downloading the first 2 CDs of the installation, and put each in its own folder.
I downloaded all of the patches and carefully replaced the existing packages, making sure I placed the appropriate ones in each folder and removed the old ones.
I made sure that the hidden files were in each directory specifying disc 1 and disc 2, and I then ran:
/usr/lib/anaconda-runtime/genhdlist -withnumbers /home/temp/cd-1 /home/temp/cd-2
I looked, and saw that hdlist timestamp had been updated, indicating something happened.
I used mkisofs to create the images. I used the following commands for each from within the root directory of each CD staging area:
CD 1: mkisofs -b images/boot.img -c boot.cat -d -J -L -N -o /home/image-1.iso -r -T -v ./ CD 2: mkisofs -d -J -L -N -o /home/image-2.iso -r -T -v ./
The images were created, and then I used EZ CD Creator to burn out the images. I've not had a problem doing this before, so I believe the steps I've followed are accurate. It's been a while since I last did this, so I may have missed something.
Questions:
Someone on this list mentioned about downloading the latest images to address the SCSI adapters I use. I looked on both ftp.redhat.com and updates.redhat.com and could not find any new images other than the ones first released. Are these hidden somewhere, or is this the only image currently available?
Red Hat released respin ISOs for Red Hat 7.0. Has Red hat done the same with 7.1 or are they planning on doing this? If released, where would I download these from please?
Mike
Make sure nothing but rpms is in the RPMS directories, each rpm passes with rpm -K —nopgp —nogpg.
From the anaconda errors, you can often figure out what was wrong. What did it say?
> /usr/lib/anaconda-runtime/genhdlist -withnumbers /home/temp/cd-1 > /home/temp/cd-2
Probably just an email typo, but you need 2 dashes in —withnumbers.
> > - I looked, and saw that hdlist timestamp had been updated, indicating > something happened. > - I used mkisofs to create the images. I used the following commands > for each from within the root directory of each CD staging area: > > CD 1: mkisofs -b images/boot.img -c boot.cat -d -J -L -N -o > /home/image-1.iso -r -T -v ./ > CD 2: mkisofs -d -J -L -N -o /home/image-2.iso -r -T -v ./
The -T option helps only old DOS systems, so I leave it out to save the space, and I remove the TRANS.TBL files to save space.
Instead of going into the directory and doing ./, I use the full pathname of the directory.
> Red Hat released respin ISOs for Red Hat 7.0. Has Red hat done the same > with 7.1 or are they planning on doing this?
Red Hat's policy seems to be to stick to the original iso, and provide updated rpms separately, but not a new iso. This makes support easier evidently. The 7.0 respin is the only exception I know of.
Red Hat provides updated rpms, but not updated isos.
Jan Carlson
> Is it possible to install Red hat 7.1 from the hard drive? I know you > could do this in earlier versions, but now it appears that when I select > this option, it's looking for the ISO on the hard drive, not the actual > files. Did this feature get removed, or is it still possible to do a > full install from having copied down the i386 directory from > ftp.redhat.com? I tried both text mode and expert mode, and end up in > exactly the same place.
Yes you can, but you need both isos (not the files) and of cource you need them in a partition that won't get nuked during install.
Chris Kloiber
Because of the number of problems associated with corrupted files being downloaded, Red Hat has removed that option from the installer. It is now required that you use ISO files. The integrity of the ISOs can be verified using md5sums which are published for all RH ISO files. This eliminates problems for the customer-support/mailing-list since we just ask "Have you checked the md5sums of your ISO files?"
Ryan Camick
Thu, 19 Jul 2001 09:16:07 -0400
https://listman.redhat.com/pipermail/seawolf-list/2001-July/008699.html
> Is anyone really familiar with building updated ISOs for Red Hat 7.1? I've > noticed a difference and I wanted to see if it's important. > > In the past, I've copied over the ISO to the hard drive, removed the > TRANS.TBL files that were created for the old ISO, checked to make sure the > 0-byte file .disc1-i386 existed, updated the files, and then ran genhdlist. > With 7.1, I just looked and saw on the original ISO that the file > .disc1-i386 is no longer a 0-byte file. It now has a series of numbers in > it: > > 986787650.21020 > > Does anyone know what these are, and how they releate to the distribution? > Further, how do you generate a new set of these numbers for a new image you > build?
Preserve the existing numbers. Otherwise I'd guess you have to find and change the code that looks for them.
You must also run genhdlist upon the files for both cds at the same time. But you already know that if you made updated Guinness CDs that worked.
> I've built ISOs for prior versions with very few problems. So far, I've > been unable to get a good build for the 7.1 ISOs. Any pointers would be > greatly appreciated.
Jan Carlson
Sat, 21 Jul 2001 20:03:12 -0400 https://listman.redhat.com/pipermail/seawolf-list/2001-July/008845.html
I'm working on building updated ISOs of Red hat 7.1. I've noticed in the /RedHat/base directory, there are two files:
hdlist hdlist2
It appears that when you run genhdlist, it will update the first file, hdlist. However, hdlist2 appears to be untouched. If I add any new RPMs to my build, such as nmap or something, shouldn't both of these files be updated to reflect the change? My guess is that hdlist2 has additional information on each RPM being installed, and would be important to be current with what is in the ISO. Is there some new, additional step that needs to be done now when rebuilding ISOs?
Michael J. McGillick
Newsgroups: comp.os.linux.misc >How can I setup a sample environment (meaning carefully pick the >right packages to install, not much not less) and then do further >installation based on this sample environment? > >Seems to me that in RedHat I can use "mkkickstart" to do it, but >reading the man page gave my no clue how to do it. > >How can I do it, w/ or w/o mkkickstart? Note keeping a >"configuration" is far more space-saving than keeping a installed >Linux system. This is my goal. Thanks for your help!
I wholeheartedly agree. In fact, the 'bare metal recovery' approach I use for the systems we install is (1) re-install Linux using kickstart, (2) restore user stuff from backup.
You should create a kickstart file from scratch. It's not that hard — the file is pretty short. It's documented under the kickstart section of this document (go to the bottom of the index): http://www.redhat.com/support/manuals/RHL-6.2-Manual/ref-guide/
Lee Allen
http://www.redhat.com/mirrors/LDP/HOWTO/KickStart-HOWTO-9.html
documented on: 2000.12.21 Thu 22:49:02
Newsgroups: comp.os.linux.misc,linux.redhat.install,linux.redhat.misc
I am having a problem with kickstart under RedHat 6.2 that I have not been able to resolve after weeks of effort.
Basically, the way kickstart partitions the disk is weird, and I cannot persuade it to put the kernel image — or the partition containing the kernel image — at the beginning of the disk. Inevitably it seems to fall somewhere beyond cylinder 1023.
I have tried both a separate 16MB /boot partition, and no /boot partition (so the /boot directory is in / (root) ).
Basically I need a 128MB swap partition, a 16MB /boot partition, a couple of GB for / (root) and a couple more GB for a data partition. I have tried omitting the /boot partition so the /boot directory is within the / (root) partition, but the kernel still ends up at a high cylinder number. And, it creates extended partitions, which I don't like, but I guess that has no real problem.
Is there any way to cause kickstart to put partitions in a particular order?
The other problem is, it doesn't seem to reliably clear the previous partitioning before laying down the new partitions. I am using —clearpart all in my kickstart file.
Thanks for any help. I apologize for a little cross-posting.
Lee Allen
> I am trying to set up a kickstart envioronment for RedHat 6.2. I have > it working properly except I was wondering if there was any way to work > around the > > boot:linux ks=floppy > > if I do not specify then it uses ignore the ks.cfg file in the floppy > but still uses the bootnet image to start the install. > > if there is a way to make the system identify the ks.cfg with having to > type the command at the prompt, then i can have keyboard less network > installs.
yeah, you need to modify syslinux.cfg on the boot floppy.
mount it mount /dev/fd0 /mnt/floppy
then edit /mnt/floppy/syslinux.cfg to look like:
default ks prompt 0 label ks kernel vmlinuz append ks=floppy initrd=initrd.img
At least that's what I've read elsewhere.
Fritz