I’m not at all sure, but I think you may have encountered that packaging change I referred to above. In 2.6.27 the ext3 module is definitely in the x64 default-base package. I don’t know where it is in the 2.6.31 packaging - but I know it is there (and ext4) because I installed both with 11.2 Milestone 5. Unfortunately, I deleted that installation so I can’t check it further for you. In short, it’s there somewhere.
You will need to put ext3 and ext4 in the initrd, and if you have more than one kernel installed, you will need to be sure to build the initrd pointing to the 2.6.31 modules to line up with the 2.6.31 mainline.
Perhaps you could just add the Factory repository and upgrade the kernel in YaST? If the packaging has changed, it (hopefully) will show you which 2.6.31 packages correspond to your 2.6.27 packages. If you still need (or want as a backup) the 2.6.27 kernel & initrd binaries, you can copy those files to another folder you make under /boot; this would enable you to boot with the older kernel after 2.6.31 installation.
Yes, - if ext4 module isn’t using for the work w/ext3 also. In all the binary RPM’s I downloaded there is only source for ext3 things
I built the kernel from source some times, but have no expirience w/building of initrd (using mkinitrd). So I’ll prefer instead of initrd to build the kernel itself or try to apply the necessary for me Nehalem/SRAT patch from SLES to 2.6.27/OpenSuSE kernel.
Ehh, I must install the kernel on server working in private IP address space, so I don’t use YaST directly. And the packaging has changed - simple because kernel RPM’s naming scheme in 11.2 is new.
Just one last idea - perhaps you could do a test install of 11.2 Milestone 6 in a virtual machine or on a test machine/partition? That way you would for sure answer your questions.
It appears you have some unique requirements. If you are not using SuSE’s initrd, then indeed you are either compiling modules into the mainline yourself or using another method of loading them. Especially given the patch that you need, if you can’t test SuSE’s 3.6.31, then perhaps it would be best to compile a fresh kernel from kernel.org (if you need to, you could combine the SuSE’s kernel configuration with your own). I suspect that the 2.6.27 patch you need is now in the newest kernel’s mainline.
Thanks for your ideas. Taking into account the changing of kernel packaging, I prefer to obtain somewhere on SuSE sites very simple information - the list of SuSE kernel packages I must install on the server
I checked today last 11.2 kernel packages from Sept. 2nd, and also desktop packages - w/the same result: noone contains ext3 modules, only ext4.
May be it means that ext3 module is built in initrd and SHOULD NOT be contained in any kernel package ?
Just no, I beleive. I have heterogenous HPC cluster, where new dual Nehalem-based server was added. Frontal node works w/10.3, but it can’t be used w/Nehalem - so I installed on Nehalem server (“internal node”) 11.1. But default 11.1 kernel has serious bug w/NUMA support for Nehalem (really NUMA tools don’t work). So I’m trying to obtain simple normal working kernel.
Sorry, it looks that I wrote here something which was not clear (misunderstanding) - of course, I use initrd from OpenSUSE kernel packages.
Unfortunately I don’t have any information about using of this patch in
OpenSuSE kernels later than default 11.1 2.6.27-7. On OpenSuSE kernel maillist it was recommended to try last 11.2 kernel - and I attempt to use it, or apply kernel patch for SLES (therefore other) kernel. To be more clear, I don’t boot really installed additional 11.2/2.6.31 kernel - because of RPM’s message about absense of ext3 module (and some others). Again, if it’s possible, that all the necessary modules must be placed only in initrd (and not in the /lib/modules) - or I must use ext4 module for ext3 - I may try to boot w/installed 11.2 kernel).
(I’m afraid to damage the filesystem).
What is about building of vanilla kernel.org kernel - yes, it’s normal way. But I switched from RH to SuSE about6 years ago - when 1st Opteron’s appear SuSE was the only stable distribution - and then used SLES/SuSE/OpenSuSE w/o any problem. So SuSE kernels is now habitual for me - else I’ll switch back to FC or Centos
I just did a quick test install of 11.2 Milestone 6. There are 2 kernel packages (aside from Xen), “kernel-default” and “kernel-desktop”. According to the desktop package version, it has “features disabled not typically used on the desktop” (to reduce latency), but exactly what those are is not stated in the package itself. I did a modprobe on all the modules in your list, and ext4 was the only one found, i.e., all the others - including ext3 which I installed on - are apparently in the mainline, which would explain why you couldn’t find them.
I also took a look at Factory snapshot. In addition to the 2 above, there are also matching “base” packages for each. But I don’t know what those are, and they are not included in the M6 iso. But looking at the package list for “default” in M2, it appears it includes everything in 11.1’s three packages (i.e., default, base, and extra). And M2’s default is 117MB, while 11.1’s three total to ~90MB; that would seem to suggest everything is in the single package, with, again, quite a few (the most common?) modules built directly into the mainline.
Thanks for your help !!
I didn’t reboot my SuSE w/new kernel (from 11.2) because of long running batch jobs, so your data are important for me.
But I’m not sure that I understand correctly your words about “mainline”. Does mainline means the static, “pure monolithic” part of the kernel (in opposition to dynamically loaded kernel modules) - i.e. that therefore I don’t need more to have this modules “as modules” ?
Yes (sorry about that, “mainline” is an old programming term). The mainline is the main core code itself, in this case, the kernel file. Modules are code objects which act as extensions to the mainline, each for a very specific purpose. So the mainline provides the major and most commonly used functionality, along with the framework to call and utilize code extensions where required.
I don’t know why in SuSE’s 11.2 kernel, that commonly used modules have been migrated into the mainline, whether that is a decision by SuSE developers or upstream by Linus (I don’t follow kernel development anymore). I can speculate though that with modern desktop/server machines there is less need for a bare-minimum core. Regardless, the kernel architecture will retain its modular character, in order for it to be easily configured (and still supportable) for a wide variety of devices (phones, routers, appliances, etc.).
I saw your question on the kernel mailing list. If I understood the question/replies correctly, the patches suggested are intended as workarounds for a bios flaw. That is a tough problem (unless you have a lot of leverage with the hardware vendor or the vendor has a lot of customers with the same issue). If the problem is widespread enough, the patches may be in the 2.6.31 mainline (there certainly are other such workaround patches already there). If not, you’ll have to find a kernel with them (also ref’d by Thomas in his reply), or you’ll have to compile your own kernel. Searching kernel.org may tell you the status of the patches vis-a-vis the mainline.
I myself can’t check - is’t the BIOS error or Linux kernel error. But it’s known (in Linux community) problem, and AFAIK at least some distribution vendors (CentOS, for example) solved it.
I can’t leverage to Supermicro - (especially) taking into account that I don’t know that it’s the BIOS error. In any case I downloaded and use last Supermicro BIOS version for my system board.
I’m sure that it must be widerspread problem, taking into account that dual Intel Xeon/Nehalem platform might be the most popular server platform.
I checked today 2.6.31-rc7-4-default kernel from 11.2 Factory (btw, thanks again for your help - I was sure that my boot attempts will not destroy filesystem) - w/the same bad result: node0 and node2 directories (instead of node0 and node1) in /sys/devices/system/node directory.
I suspect that CentOS’s solution is the same as Thomas ref’d, i.e., a patched kernel - in this case SLE (patched) since that is Novell’s enterprise server version. I would try to find that, and failing that, patch/recompile my own kernel. On kernel.org you might find info re a long-term solution and possibly other alternatives.
I patched today default x86-64 kernel from OpenSuSE 11.1 repo (2.6.27.7-9). The kernel was built from source using SRAT/NUMA patches by Kurt Garloff.
Kernel w/patches works OK w/my Supermicro X8DTi mobo (w/dual Nehalem Xeon E5520).
So the problem is solved. But as I wrote in my previous message here, this problem remains w/11.2 kernels (I checked default binary 2.6.31-4.1 version).
Yes, - if ext4 module isn’t using for the work w/ext3 also. In all the binary RPM’s I downloaded there is only source for ext3 things 