Yesterday I found a need to have the NTFS module support in my CentOS 5.0 at home, so I happily installed the 8.1.4 source, prepped it (after deleting the rhel and olpc lines per Johnny's notice earlier in this list), made the config with a ".nx" version name using make menuconfig (copying the config from the SOURCES directory, editing it to include the # x86_64 line and copying it back), changing the spec file to make the release also have a ".nx" after the embedded one.
The kernel built and installed without errors, but when it booted (this morning), there were massive errors. It did come up, but without the graphical desktop, so I went in and poked around and found 16 of these:
May 29 07:58:28 localhost modprobe: FATAL: Could not load /lib/modules/2.6.18-8.1.4.el5.nx.nx/modules.dep: No such file or directory
".nx.nx"?????
The kernel rpm is this:
-rw-r--r-- 1 mhr users 15318350 May 29 03:34 kernel-2.6.18-8.1.4.el5.nx.x86_64.rpm
and the running version is this:
Linux mhrichter 2.6.18-8.1.4.el5.nx.nx #1 SMP Tue May 29 03:11:28 PDT 2007 x86_64 x86_64 x86_64 GNU/Linux
I got around this by creating a symlink:
drwxr-xr-x 7 root root 4096 May 29 08:31 2.6.18-8.1.4.el5.nx/ lrwxrwxrwx 1 root root 19 May 29 10:56 2.6.18-8.1.4.el5.nx.nx -> 2.6.18-8.1.4.el5.nx/
My question is: why is the kernel version getting that extra ".nx" in it? I didn't see this problem when I built my 5.0 test kernel at work, and I never saw anything like it in 4.4. Where did I go awry?
Mark Hull-Richter wrote:
Yesterday I found a need to have the NTFS module support in my CentOS 5.0 at home, so I happily installed the 8.1.4 source, prepped it
While not directly connected to your issue.... I hope you realise that a complete kernel build is not required just to get a single module ? you can quite easily, just build that one module and be done with it.
On 5/29/07, Karanbir Singh mail-lists@karan.org wrote:
Mark Hull-Richter wrote:
Yesterday I found a need to have the NTFS module support in my CentOS 5.0 at home, so I happily installed the 8.1.4 source, prepped it
While not directly connected to your issue.... I hope you realise that a complete kernel build is not required just to get a single module ? you can quite easily, just build that one module and be done with it.
It's not configured into the distribution kernel, not even as a module.
Mark Hull-Richter wrote:
On 5/29/07, Karanbir Singh mail-lists@karan.org wrote:
Mark Hull-Richter wrote:
Yesterday I found a need to have the NTFS module support in my CentOS 5.0 at home, so I happily installed the 8.1.4 source, prepped it
While not directly connected to your issue.... I hope you realise that a complete kernel build is not required just to get a single module ? you can quite easily, just build that one module and be done with it.
It's not configured into the distribution kernel, not even as a module.
right. what he said is, you can build a module without having to rebuild the kernel.
On 5/29/07, John R Pierce pierce@hogranch.com wrote:
right. what he said is, you can build a module without having to rebuild the kernel.
Okay, I'll do that. (I have the HowTo and have done so a couple of times.)
But, it doesn't address the .nx.nx problem - can anyone explain that one?
Mark Hull-Richter wrote:
But, it doesn't address the .nx.nx problem - can anyone explain that one?
Yes. It appears that you added the extension in two places: the spec file, and the config file. Just add the extension in the spec file. Adding it in the config file causes confusion in the build process.
On 5/29/07, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
Yes. It appears that you added the extension in two places: the spec file, and the config file. Just add the extension in the spec file. Adding it in the config file causes confusion in the build process.
Okay, but (which, I supposed, means "not REALLY okay..." :-) according to the wiki, and every build I did under 4.4, when building a kernel we are guided to change the "Local version" in the config file (via make menuconfig or whatever) and also to change the "release" in the spec file - both.
Is this no longer true in 5.0/2.6.18? If so, it's certainly a minor convenience, but I haven't seen that documented anywhere yet (or did I miss it?).
Thanks.
Mark Hull-Richter wrote:
On 5/29/07, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
Yes. It appears that you added the extension in two places: the spec file, and the config file. Just add the extension in the spec file. Adding it in the config file causes confusion in the build process.
Okay, but (which, I supposed, means "not REALLY okay..." :-) according to the wiki, and every build I did under 4.4, when building a kernel we are guided to change the "Local version" in the config file (via make menuconfig or whatever) and also to change the "release" in the spec file - both.
Is this no longer true in 5.0/2.6.18? If so, it's certainly a minor convenience, but I haven't seen that documented anywhere yet (or did I miss it?).
All I can say is that I changed the spec file only, and my kernel came out just fine (running version 2.6.18-8.1.4.1.rkn right now).
On 5/29/07, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
Mark Hull-Richter wrote:
On 5/29/07, Robert Nichols rnicholsNOSPAM@comcast.net wrote:
Yes. It appears that you added the extension in two places: the spec file, and the config file. Just add the extension in the spec file. Adding it in the config file causes confusion in the build process.
Okay, but (which, I supposed, means "not REALLY okay..." :-) according to the wiki, and every build I did under 4.4, when building a kernel we are guided to change the "Local version" in the config file (via make menuconfig or whatever) and also to change the "release" in the spec file - both.
Is this no longer true in 5.0/2.6.18? If so, it's certainly a minor convenience, but I haven't seen that documented anywhere yet (or did I miss it?).
All I can say is that I changed the spec file only, and my kernel came out just fine (running version 2.6.18-8.1.4.1.rkn right now).
It certainly looks that way to me, too. Thanks.