Thanks for your quick reply.

I decided to give your workaround a try to see how the remainder of the process worked.

The process of rpmbuild -bp or the make xconfig changed i686 to i386. I edited the SOURCE config file putting # i686 as the first line. Then I ran the rpmbuild -ba command. the // had been replaced with /i686/ but the Makefile was not found.

I will wait for additional comments.

Thanks, David

On Monday 21 May 2007 1:03 am, Akemi Yagi wrote:

On 5/20/07, dcw dwoody1@charter.net wrote:

...

I have installed CentOS 5 with all updates. Also I have 2 ne2000 isa cards.

In recompiling the kernel, I have been trying to follow the instructions on this URL: http://wiki.centos.org/HowTos/Custom_Kernel

The complete error message I get is: Makefile:403: /home/cs/redhat/BUILD/kernel-2.6.18/linux-2.6.18.i686/arch//Makefile: No such file or directory

Hi,

Makefile is expected to be in .../arch/i686/ not .../arch// .

I could reproduce the problem. I don't know where the source of the problem is, but I am sure we will hear from experts on this mailing list. At the risk of getting reprimanded by KB, I will share my quick and dirty solution.

Look at the first line of

SOURCES/kernel-2.6.18-`uname -m`.config

It's supposed to be # i686 (or in my case # x86_64). ARCH is defined by this line (around line 1917) of .spec:

Arch=`head -1 .config | cut -b 3-` (.config comes from the above file)

But the .config file has only a # on the first line. Therefore, ARCH ends up with an empty string leading to an empty directory for Makefile.

This means that the initial .config file in the BUILD directory was already wrong.

So, a quick (temporary) solution is to change the # to # i686. Not the right way, but if you must build your kernel now, you may need to resort to the manual editing method. Otherwise, wait for real help.

Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 5/21/07, dcw dwoody1@charter.net wrote:

Thanks for your quick reply.

I decided to give your workaround a try to see how the remainder of the process worked.

The process of rpmbuild -bp or the make xconfig changed i686 to i386. I edited the SOURCE config file putting # i686 as the first line. Then I ran the rpmbuild -ba command. the // had been replaced with /i686/ but the Makefile was not found.

I will wait for additional comments.

Thanks, David

Sorry, in your case, you want # i386 on that line.

Akemi

On 5/21/07, dcw dwoody1@charter.net wrote:

When I use the i386 the compile continues. However, I had to edit the SOURCE config file after running make xconfig. That command altered the first line of the config file.

Will post the results of the compile when completed. My best guess is it will take about 7 - 8 hours.

Thanks, David

Yes, I was about to say the same thing. In fact, the arch name (i386) gets deleted twice. First, when rpmbuild -bp is run. But this is not a problem by itself, because in the next step .config is copied from SOURCE which has the correct first line. Then the second time is when make menuconfig (or xconfig) is run as you noted. This is the problem. At this point, arch needs to be added back manually to .config as just you did.

I really want to why menuconfig does not do it right.

Akemi

On 5/21/07, Akemi Yagi amyagi@gmail.com wrote:

I have done a bit of a search regarding this issue. Turns out the same problem was reported as early as Feb 2005 on a Fedora list. So this is not something new, nor CentOS specific. Bad news is that I have yet to find an answer for this. The only thing I saw in the search was the same manual editing of .config as we already did as a temporary solution.

http://linux.derkeiler.com/Mailing-Lists/Fedora/2005-05/0405.html

I am still trying to figure out why rpmbuild -bp messes up the first line of .config.

I confirmed that exactly the same thing happens on my FC5 and FC6. This stuff must have been around for quite some time. I had never used rpmbuild for compiling kernels, so did not notice until I saw the OP's posting yesterday. Maybe I should stop writing to this mailing list because this is not a CentOS issue. Will probably file a bug with RedHat's bugzilla if no one has already done it. I suppose not many people use rpmbuild AND modify the kernel options.

Akemi

On 5/21/07, dcw dwoody1@charter.net wrote:

If using rpmbuild is not the preferred method then ...

What directory should I be in? What commands should I be using?

Thanks,

David

Using rpmbuild is indeed the preferred method if you wish to run the CentOS kernel. (CentOS developers, correct me if this is not the right advice.) I used to compile vanilla kernels on Fedora Core.

Get the centosplus src.rpm as I wrote in my other post. If you look at the .spec file, you can probably figure out how to not compile the xen kernel, etc.

Akemi

On 5/21/07, dcw dwoody1@charter.net wrote:

Am I understanding correctly?

I get the SPEC file from the CentOSPLUS rpm and use that spec file with the 8.1.4 source rpm?

That will work after some editing. Or, use the spec that comes with 8.1.4, but make sure you delete the section of %prep referred to in the Johnny Hughes' post.

Akemi

On 5/21/07, dcw dwoody1@charter.net wrote:

I installed the 8.1.4 src.rpm and deleted the lines from the email you pointed to.

It failed during the rpmbuild -bp command with the error: non-existent symbol PHYSICAL_START

I modified the SPEC file after I installed the src.rpm and before I ran the rpmbuild -bp command.

I did this twice to make sure I did it correctly.

Thanks,

David

I don't know the answer to this one. Will try 8.1.4 soon.

Akemi

I deleted the contents of /home/cs/redhat. I then did a install of the 8.1.4 src. I edited the SPEC file so that the %prep section started as follows:

%prep # First we unpack the kernel tarball.

Then I did the rpmbuild -bp and got the same failure: non-existent symbol PHYSICAL_START

Thanks,

David On Tuesday 22 May 2007 10:14 am, Akemi Yagi wrote:

On 5/22/07, Akemi Yagi amyagi@gmail.com wrote:

...

On 5/21/07, dcw dwoody1@charter.net wrote:

...

I installed the 8.1.4 src.rpm and deleted the lines from the email you pointed to.

It failed during the rpmbuild -bp command with the error: non-existent symbol PHYSICAL_START

I modified the SPEC file after I installed the src.rpm and before I ran the rpmbuild -bp command.

I did this twice to make sure I did it correctly.

Thanks,

David

I don't know the answer to this one. Will try 8.1.4 soon.

Got the 8.1.4 source and ran rpmbuild -bp. It went through without a hitch. Did you install the source into a clean place? May not matter, but just in case...

Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

I was changing the config as well. If I reinstall the src rpm and edit the %prep section only, as you detailed, then the error: non-existent symbol PHYSICAL_START is only a warning. The rpmbuild -ba is running now.

It is when I altered the config file that it fails.

This leads me to believe that I have not enabled enough ISA settings in the config file for everything to work correctly. I saw no comments in xconfig indicating that other settings should be altered.

I am pressing 'y' for isapnp and isa support. Are both needed for ne2000 support?

I am pressing 'm' for ne2000 support.

Any idea which additional ISA or other settings I should set?

Thanks,

David

On Tuesday 22 May 2007 11:32 am, Akemi Yagi wrote:

On 5/22/07, dcw dwoody1@charter.net wrote:

...

I deleted the contents of /home/cs/redhat. I then did a install of the 8.1.4 src. I edited the SPEC file so that the %prep section started as follows:

%prep # First we unpack the kernel tarball.

Then I did the rpmbuild -bp and got the same failure: non-existent symbol PHYSICAL_START

My procedure is exactly the same as yours. It's not a warning? The command actually fails?

Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 5/23/07, dcw dwoody1@charter.net wrote:

The compile with the altered %prep section but that does NOT include the altered config file finished with no apparent errors.

What is the next step?

Thanks,

David

Sorry, I must ask obvious questions. Did you copy your .config back to the SOURCES directory before running rpmbuild -ba ? How did you confirm that you are running the newly built kernel? Did you give a unique release number?

Akemi

see below On Thursday 24 May 2007 5:42 am, Akemi Yagi wrote:

On 5/24/07, Akemi Yagi amyagi@gmail.com wrote:

...

On 5/23/07, dcw dwoody1@charter.net wrote:

...

The compile with the altered %prep section but that does NOT include the altered config file finished with no apparent errors.

What is the next step?

Thanks,

David

Sorry, I must ask obvious questions. Did you copy your .config back to the SOURCES directory before running rpmbuild -ba ? How did you confirm that you are running the newly built kernel? Did you give a unique release number?

Guess I misunderstood your question. The following procedure might work.

(1) prepare .spec by removing lines from %prep (2) rpmbuild -bp kernel-2.6.spec (3) go to BUILD (where .config is) (4) make xconfig (5) add # i386 to .config as the first line (6) copy this .config back to SOURCES (using the original name xxx.config) (7) rpmbuild -ba kernel-2.6.spec

Or, instead of steps (5) to (7), just run:

I did 5 and 6 anyway, assuming that in the worst case they were not needed and would do no harm. I then did 'rpmbuild -bc ...' as below.

It was working until gpg had a segfault. From some of the emails I have been reading this is a known problem that has not been fixed yet.

Other emails I have read indicated that signmodule should be set to 0. What is the down side risk of doing this?

Thanks for all your input. I know that this will get solved. If fact, depending on your answer to the signmodule question, resolution may be at hand.

David

rpmbuild -bc --short-circuit kernel-2.6.spec (to build without going through %prep)

This seems to work for me. At least the building process started without any errors. The only person who can help (and give you an authentic answer) is Johnny Hughes. Hope he can chime in here.

Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On Thursday 24 May 2007 4:21 am, Akemi Yagi wrote:

On 5/23/07, dcw dwoody1@charter.net wrote:

...

The compile with the altered %prep section but that does NOT include the altered config file finished with no apparent errors.

What is the next step?

Thanks,

David

Sorry, I must ask obvious questions.

No problem at all. Sometimes the obvious is overlooked.

Did you copy your .config back to the SOURCES directory before running rpmbuild -ba ?

Yes, and I edited the file to verify that the settings i selected were done correctly and that # i386 was the first line.

How did you confirm that you are running the newly built kernel?

I have not been able to build a kernel with an altered config file.

Did you give a > unique release number?

Yes, 8.1.4.1.ne2000%{?dist} I will also respond to your other email this morning.

Thanks, David

Akemi _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

Jim Perrin spake the following on 5/24/2007 5:18 AM:

On 5/24/07, dcw dwoody1@charter.net wrote:

<snip> Johnny Hughes has updated the custom kernel wiki link. You might want to check it out again to see what it has that's different than what you're doing.

You are soon going to be at a point where the time spent getting it working will cost more than replacing hardware. ;-) Aren't ISA NE2000's sometimes stuck at half-duplex?

How do you create several RAID devices if you only have 2 drives? Is there a way to create virtual RAID sets? That sounds too scary.

Thanks, Scott

On 5/22/07, Miguel Medalha miguelmedalha@sapo.pt wrote:

[snip]

I have 2 120GB SATA disks on which to install the OS. I want to create the following partitions:

[snip]

Two options are now present to me:

• Create a single RAID 1 device with both entire disks and then

partition on top

• Create several RAID devices, one for each partition (md0, md1,

md2 and so forth)

Which one would be better from the points of view of performance, security and data recoverability?

I think his confusion stems from the fact that most (all?) hardware raid controllers only allow you to use the whole disk for a raid volume, not parts of it, and a disk can only be in a single raid volume (with the exception of a global hotspare).

Russ Sent wirelessly via BlackBerry from T-Mobile.

-----Original Message----- From: "Miguel Medalha" miguelmedalha@sapo.pt Date: Tue, 22 May 2007 15:10:47 To:"CentOS mailing list" centos@centos.org Subject: Re: [CentOS] A question about RAID and partitions

How do you create several RAID devices if you only have 2 drives? Is there a way to create virtual RAID sets? That sounds too scary.

Well, I may be wrong or may be using the wrong terminology, but on several occasions I did create several RAID 0 an 1 partitions on two disks. I would create a RAID 0 partition where I needed a boost in performance, a RAID 1 partition where I needed more security. What do you say is wrong with that? Why is it wrong to create RAID devices, even of different types, with only two disks? I don't understand what you mean: virtual RAID sets? Of course they are virtual, but they are made of real disk space, not the entire disks but adequate parts of the disks.

_______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

On 5/22/07, Scott Silva ssilva@sgvwater.com wrote:

...

How do you create several RAID devices if you only have 2 drives? Is there a way to create virtual RAID sets? That sounds too scary.

You create raid devices over partitions that don't span the entire drive.

Why would this be a configuration that someone would want to do? So you can have both a 0 (performance) and 1 (redundancy) on the same physical drives, depending on your partition? Just seems odd.

Thanks, Scott

Sometimes it's unavoidable, like the 100MB /boot partition which needs to standalone and be a raid0 or raid1, but the rest of the drive can participate in a raid5 or raid6...

nope. the /boot must be on a raid1 partition.

have raid 0 and raid1 on the same drive isn't going to gie you anything since the raid 1 will "slow" the other raids down.

Scott Silva wrote:

Scott Moseman spake the following on 5/22/2007 11:30 AM:

...

On 5/22/07, Scott Silva ssilva@sgvwater.com wrote:

...

...

How do you create several RAID devices if you only have 2 drives? Is there a way to create virtual RAID sets? That sounds too scary.

You create raid devices over partitions that don't span the entire drive.

Why would this be a configuration that someone would want to do? So you can have both a 0 (performance) and 1 (redundancy) on the same physical drives, depending on your partition? Just seems odd.

Thanks, Scott

What if you wanted /boot and / to be on a raid1 for redundancy, but you wanted a scratch directory on raid 0 for the speed, maybe for video editing or other I/O intensive operation? If you didn't care that the scratch directory failed on a drive fail, you could get back and running with a reboot and re-creating the filesystem on the scratch directory.

Miguel Medalha wrote:

...

have raid 0 and raid1 on the same drive isn't going to gie you anything since the raid 1 will "slow" the other raids down.

You are assuming that both arrays will always be concurrently accessed but that may not be the case. More yet: the configuration may have been studied in such a way that concurrent access is rarely the case.

If you only have 2 drives there's not much you can do to avoid concurrent access. The killer is head seek time - if you have your only 2 drives tied together in any kind of raid and the head needs to be in 2 places at once it doesn't matter much how you laid out the partitions. Reads can be sort-of independent on raid1 but writes make both seek to the same place.

not actually. There's overhead with doing that. plus WHEN there's a disk failure your raid0 is toast and your raid 1 is degraded. Why not jsut run 4 disks since they are so cheap nowadays and not have to deal witht he complications?

Miguel Medalha wrote:

...

If you only have 2 drives there's not much you can do to avoid concurrent access. The killer is head seek time - if you have your only 2 drives tied together in any kind of raid and the head needs to be in 2 places at once it doesn't matter much how you laid out the partitions. Reads can be sort-of independent on raid1 but writes make both seek to the same place.

That's not what I was referring to. I meant, for example, that if you have on the same disks a RAID-0 containing data that is very frequently used and a RAID-1 containing data that is rarelly accessed, then you still beneffit from the qualities of both RAID types despite them being on the same physical disks. _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Scanned with Copfilter Version 0.84beta2 (P3Scan 2.2.1) AntiSpam: SpamAssassin 3.1.8 AntiVirus: ClamAV 0.90.2/3283 - Tue May 22 18:56:44 2007 by Markus Madlener @ http://www.copfilter.org

Am Mittwoch, 23. Mai 2007 schrieb William Warren:

if you only have two drives concurrent access is guaranteed.

Depends on the usage pattern, not on the drives.

Miguel Medalha wrote:

...

...

have raid 0 and raid1 on the same drive isn't going to gie you anything since the raid 1 will "slow" the other raids down.

You are assuming that both arrays will always be concurrently accessed but that may not be the case. More yet: the configuration may have been studied in such a way that concurrent access is rarely the case.

On 5/22/07, Miguel Medalha miguelmedalha@sapo.pt wrote:

I am about to begin the installation of a small server (no more than 20 users), using CentOS with Samba to authenticate Windows XP workstations. A question arises about the organization of the filesystem. I hope that more experienced and knowledgeable users here will be able to give me some precious advice.

I have 2 120GB SATA disks on which to install the OS. I want to create the following partitions:

/boot / /tmp /var /home /swap

Two options are now present to me:

• Create a single RAID 1 device with both entire disks and then partition on

top

• Create several RAID devices, one for each partition (md0, md1, md2 and so

forth)

Which one would be better from the points of view of performance, security and data recoverability?

Create two raid partitions. One for /boot, and the other to be used as the physical volume of a volume group, and then use lvm to carve out your remaining partitions.

Cheers...james

Perhaps I am wrong but I feel that my question didn't receive an answer yet; the discussion digressed a bit. So, let me rephrase my question:

Which one is better, RAID devices created on top of partitions or partitions created on top of RAID devices?

By "better" I mean under the aspects of data security, performance and ability to recover from a disk crash.

Thank you again.

I am about to begin the installation of a small server (no more than 20 users), using CentOS with Samba to authenticate Windows XP workstations. A question arises about the organization of the filesystem. I hope that more experienced and knowledgeable users here will be able to give me some precious advice.

I have 2 120GB SATA disks on which to install the OS. I want to create the following partitions:

/boot / /tmp /var /home /swap

Two options are now present to me:

• Create a single RAID 1 device with both entire disks and then partition

on top

• Create several RAID devices, one for each partition (md0, md1, md2 and

so forth)

Which one would be better from the points of view of performance, security and data recoverability?

Raid devices created on partitions would most likely be software raid as I am not sure if you should create partitions on a software raid device, although linux would probably let you.. The technology is mature and sound, and the processor load is not that great. Partitions on top of raid devices would most likely be hardware raid. Some devices are better than others, not just the hardware, but the driver support.

You can not answer your question that easily, though. The "type" of raid device you create is what will tell you how recoverable it is. A stripe or raid 0 is not resilient at all. The loss of one drive will destroy your data. How much you can recover would depend on the size of the stripes and the size of the data. A mirror or raid 1 is infinitely more recoverable, because a complete copy of the data is on each drive. Raid 5 or better has a somewhat less chance of survival, but is better than raid 0 chance of surviving. None of them would be reliable enough to use without some sort of backup. Data security shouldn't depend on the type of or lack of raid. Data is secured by limiting access. The better performing raid types aren't always the best for survivability.

Yes, I know all of that... Either you didn't understand my question or I didn't express myself well (I admit to the latter). What I meant was: the same type of RAID considered, which situation would have been proved better:

- RAID devices created on top of partitions or partitions created on top of RAID devices. (I am, of course, talking about Linux software RAID).

And that under the three aspects of performance (CPU utilization, disk transfer rate, etc), data security and ability to recover from a disk crash.

The mdadm device, the kernel and the hardware relate to each other in ways that *may* make a difference according to the relative order in which the partitions and RAID devices are created. (I am assuming EXT3 partitions here.) I thought that someone here might have made that experience and would be able to tell me, tell us, something about it.

Thank you!

...

...

• Create a single RAID 1 device with both entire disks and then

partition on top

• Create several RAID devices, one for each partition (md0, md1, md2 and

so forth)

The latter is the way the installer will let you do it.

You pretty much gave a final answer to my question :-) I was thinking in the abstract, but the facts speak louder (for now).

Yet, maybe I am being stupid but it seems to me that there still is something to my original question...

Under hardware RAID, a dedicated processor on the RAID controller does all the job of RAID calculations. Under software RAID, as you said, "you create partitions on the disk, then combine them into md devices".

Isn't there any space for something in which the disks are made parts of RAID arrays *before* the partitions are created and yet all the RAID operations would be made by the main CPU and so it would still be considered software RAID? What would happen if the equivalent of mdadm was *included* in the OS kernel?

Thank you.

(Ok, I just noticed that my question is now O.T. and this is now a general Linux question rather than a specific CentOS question... Excuse me!)

You could always combine software raid and LVM.

Create a RAID1 device using Software RAID.

Then set up LVM with the apropriate LVM logical volumes under /dev/md0 or whatever.

Ok, I'll accept that. My initial question remains, albeit under a different form:

- Create a single RAID 1 device with both entire disks and then put LVM logical volumes on top - Create several RAID devices, one for each mount point (md0, md1, md2 and so forth)

Which one would be better under the aspects of performance (CPU utilization, disk transfer rate, etc), data security and ability to recover from a disk crash?

Does LVM bring a performance penalty?

On Tue, 22 May 2007 16:53:32 -0700 Scott Silva ssilva@sgvwater.com wrote:

...

Which one would be better under the aspects of performance (CPU utilization, disk transfer rate, etc), data security and ability to recover from a disk crash?

Does LVM bring a performance penalty?

I don't think LVM brings any penalty.

That's because you have not tried to recover an LVM. I had one with Raid1 and when drive1 failed, Boot was on disk 0.

I was hoping to able to boot from disk 0 then to put a new disk next day... To make a short story even shorter, no go. I had to restore from a 3 days old backup.

LVMs are very convenient for adding new drive and making them larger. I don't know of a live-CD that supports LVMs.

Miguel Medalha wrote:

Yet, maybe I am being stupid but it seems to me that there still is something to my original question...

Under hardware RAID, a dedicated processor on the RAID controller does all the job of RAID calculations. Under software RAID, as you said, "you create partitions on the disk, then combine them into md devices".

Isn't there any space for something in which the disks are made parts of RAID arrays *before* the partitions are created and yet all the RAID operations would be made by the main CPU and so it would still be considered software RAID? What would happen if the equivalent of mdadm was *included* in the OS kernel?

I'm not sure it would be possible to boot such a drive. Hardware raid has the benefit of a bios that understands it at boot time. Software raid1 only works for /boot because each of the mirrored partitions looks just like a normal one to bios and grub. For non-boot drives you can get the same effect (and more) by putting the whole drive in one partition, combining those with raid, then running lvm on top of that.