https://access.redhat.com/downloads/...roduct-sources

I have a running Red Hat Enterprise Server Linux (the kind we download from this link and burn to a CD and/or a flash stick and install. I originally burnt mine from a flash stick since at the time, I had no DVD, only a CD reader. Now I have a DVD and a CD.

Anyway, there was one driver that did not come with it so I've added someone else's build (weak update), and I would like to make it a strong update build. So I need to get to a point where I can build a driver. So far I cannot do that but I have a plan.

The below info shows you my setup and it also shows you that I've downloaded and burnt the source rpm CDs for my exact distribution. So presumably I'll just unpack all that 6.2GB worth of source and start building. My question is, should I supplement those two CDs with all the RPM packages with a yum install of either 1) kernel-debug.x86_64 and/or kernel-debug-devel.x86_64? In other words, do I need more than just the Red Hat source that I got from the above link.

I can epel the kernel- stuff from the repo if need be. My question is, will this add some stuff on that I will find useful? I will or course have to add the source code for the driver I'm building. Actually, I already have it from another source. I just would feel better building that one driver myself but due to dependencies it's almost always better just to build the kernel first. Of course if someone can point me into a path of not build it all, that's fine too. Perhaps I can analyze the dependencies. I realize I have to add that driver to the KConfig and/or Makefile - I've already done that.

I've just never built Linux from scratch.

Any advice appreciated. I have the correct gcc.

Below info is my setup so far:

RHEL 7.2 Source DVD1

Last modified: 2017-07-28 SHA-256 Checksum: e47a26ce70ae338ee1a80f8f1da11b3f7871c94a2a8cefabd7ca882215b61b67
Download Now
4.36 GB
RHEL 7.2 Source DVD2

Last modified: 2017-07-28 SHA-256 Checksum: e202025c65e80e9c193f3b350a063bcc21a4e9007df60fd8b6a10cf095f7e314

gcc-libraries-5.2.1-2.1.el7.src.rpm
Is this the
gcc-4.8.5-4.el7.src.rpm

[root@localhost ~]# uname -r
3.10.0-327.el7.x86_64
[root@localhost ~]# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.5/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.5-20150702/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.8.5 20150623 (Red Hat 4.8.5-4) (GCC)

addons

media.repo

Packages

repodata

TRANS.TBL


Packages

I'm not in a hurry, so if you want to work on emergencies, I can wait until late tonight or tomorrow to get back to this. This is a quasi-emergency.

This is not the Red Hat help desk...NOTHING here is an emergency for anyone; read the LQ Rules and "Question Guidelines"

That said, if you're having a problem with Red Hat Enterprise, you should call the Red Hat support you are PAYING FOR (right???) with your RHEL subscription. They can help you. And you have provided next to no useful details that would let anyone here help you, aside from saying RHEL 7.2. You say:

• "I've added someone else's build (weak update), and I would like to make it a strong update build." - What does that mean? Who is the "someone else"? Where did you get it?
• "So presumably I'll just unpack all that 6.2GB worth of source and start building." - No, you don't build RHEL 7.2 from source; you download a working ISO and install it via DVD, or to a USB stick following the instructions you find on their website. Or you download CentOS 7.2 and do the same thing. Nothing to build/compile.
• You don't bother telling us what this mystery driver is or what its for.

If this is an 'emergency' and you need to load Linux, do NOT get RHEL unless you're paying; load CentOS instead. And putting "how to install centos 7.2" into Google yields lots:
https://www.centos.org/download/
https://www.howtoforge.com/tutorial/...inimal-server/

I'd download the minimal ISO image, and let it get all the current stuff from the net, rather than a DVD that will then have to immediately update.

I have finished setting up a new server workstation that has Linux Mint. I will still debug the problems on the Redhat Linux Enterprise server. But the differences between Redhat, CentOS, ..., are not that significant. The source code in EPEL is probably more or less common to both. Perhaps there are minor differences. I DO intend to completely rebuild the kernel, but only for the purposes of debugging drivers so if I can find someone who has already done the Maipo build, I'll just use their binaries. I may also do a deep analysis of the existing binaries and see if I can get the driver built against it somehow to save me time. Eventually, this driver will be built. In my new system, my SCSI card was automatically supported by the Linux Mint operating system, so, until I get Redhat debugged, I can use the new system, hence, I wasn't worried about speed to resolve the issue. There is NO reason why I shouldn't just figure out what is wrong with the particular model SCSI card in the Redhat machine - it would help a lot of people who have troubles when I figure out what it is. It's an old, longstanding bugaboo with the Adaptec cards. It's always hit or miss - but it's a driver issue, it's NOT a hardware issue. There's just a bug in the driver because the original system was only built for MAC and Windows. It was only the Linux developers (open-source) who built a driver, and something just didn't work out the first go-around, that can be solved in the 2nd go-around, that's all. My Enterprise Redhat Maipo was not bundled with the driver - I had to ask someone for the driver, and it doesn't work perfectly yet. It might also be an issue of exactly how the driver is used by software that uses it. Some software might know how to get it to work in some cases. I need more reliability and flexibility.

Why bother? Because again, unless you pay for RHEL, you won't be able to get the pieces you're missing to be able to compile the driver.
Right...which is why you should use CentOS if you're not paying for it, since you could then use the online repositories.
You can use EPEL on both systems, correct. But again...that is NOT going to give you the pieces you're missing.
There is no issue, other than the fact you don't want to pay for RHEL apparently. Unless you have access to the online repositories, you won't be able to load what you need to build the driver. And you still haven't told us what this mystery card is, or answered any of the other questions you were asked in the first reply.

Even at that, it appears that you're trying to use very old hardware on a new system. Chances are, this won't be of much use to anyone using RHEL, because when they pay for a server, they're not going to use old hardware, but get something current and supported. And if they DO need to build the driver, they will have the tools and software to be able to do it.