I just compiled and installed the latest kernel, 2.6.12.2, to be used with Suse 9.1.

The most serious glitch is that the PCMCIA network card no longer starts.

Here's an excerpt of var/log/boot.msg. I would really appreciated ideas about how to solve this. (The kernel upgrade is to address a USB hardware problem, so I would like to be able to stick with it.)

I think there have been some changes with hardware detection in the newer kernel. How did you configure the kernel? Did you clone an older configuration, or did you set up a new configuration?

I think that either the pcmcia system does not recognise the card at all, or the card does not find a valid driver. You don't need to worry about the ip6 messages, they are normal, because SUSE expects to find some patches in the kernel. What I find starnge as well is the missing /etc/resolv.conf. If you had a working internet connection previously, this file should be there.

I set up a default kernel configuration, just selecting ReiserFS as the built-in file system. Should I try cloning the previous config?

One other change is that I disabled the initial ram disk - but this would be irrelevant here, right?

The
message happened under the previous kernel as well, in fact. Didn't seem to affect the internet connection.

Any ideas about what to tweak?

It is always a little tricky to find the best configuration. If you clone the previous configuration, you might run into the same USB problem as before, however if you stick to the default configuration you may create new problems.

But I would alway recommend to use the previous config as a template and change only the required parameters.

I have exactly the same problem with this update:
- Pentium II Celeron
- Ethernet NIC 3COM 3CXXX
- ISDN NIC AVM Fritz PCI PnP
- SuSE 9.1
- Kernel 2.6.12.2

I compiled and installed the original kernel (ftp.kernel.org) on the same system using the following steps:
- make O=/home/user/build/kernel xconfig
- Loaded the original SuSE kernel options from file /boot/config-2.6.5-7.155.29-default
- Changed the processor type to Pentium II/Celeron
- Save
- make O=/home/user/build/kernel
- Backup of /boot/initrd and /boot/vmlinuz links
- sudo make O=/home/user/build/kernel modules_install install
- Renaming and restore of /boot/initrd and /boot/vmlinuz links
- Registered the new kernel in /boot/grub/menu.lst

Resulting problems:
1. On startup, beginning with the initialization of the network interface 'lo' I get repeating messages
"ip6tables: No chain/target/match by that name"
2. On startup during Firewall initialization (steps 2+3) or 'rcnetwork restart' I get repeating messages
"It's not possible to reject outgoing packets. Expect Timeouts"

This is weird, I haven't got time to examine this in detail.
What happens here?

Thx,
René

This is actually expected. The SUSE kernel uses a couple of patches for ipv6. The firewall script started at bootup expects those patches to be present and will produce the above error messages. However, this will not prevent the network from functioning. So if you have trouble to connect, you'll have to search for a solution elsewhere.

BTW: you can get those patches by installing the kernel-source.src.rpm. This will install in /usr/src/packages and provide all patches to make the SUSE kernel. However I am not sure if they can be used with a higher kernel version.

In fact, the ippp0 ISDN network interface doesn't come up with the message
"Error in /usr/bin/isdnctrl"
If I try this manually I get an error like this: "/dev/isdnctrl or /usr/dev/isdnctrl - Device
not found"
The ippp0 interface is lost now, even if I boot with the original SuSE
kernel.

On a different computer with only a different motherboard, processor type P III, Ethernet NIC and without an ISDN NIC, but otherwise the same
configuration all went fine.

Has someone got a hint, where to look in the compile configuration, for instance whether there is missing some module, for instance "Connection state match support (IP_NF_MATCH_STATE)" or other things? May the mentioned patches will not be necessary in each case?

As very simple way to check if an option is available or not, is to simply 'grep' the term from your kernel config, e.g. 'cat .config | grep IP_NF_MATCH_STATE'

I noticed a little difference in the way you created your kernel config. When I clone a kernel configuration, I ususally run 'make oldconfig' on the old configuration file, to make sure that all new kernel options are available for configurations. I don't know if this is done automatically when you load a config in 'make xconfig'.

It seems like 'make xconfig' overtakes alle new kernel configuration parameters with its standard values when you load an external configuration directly over its menu. For being sure, on the computer where I compiled the kernel and it was working, I
- renamed the current .config to .config.cur in /home/user/build/kernel
- copied the SuSE kernel configuration from /boot/ to /home/user/build/kernel and renamed it to .config
- make O=/home/user/build/kernel oldconfig
- overwrote a couple of certain values
- diff .config .config.cur
Result: There are only differences in values that I explicitely changed in comparison to their default values.
I will retry this later on the failure machine.
Possibly someone gained different experiences here(?)

BTW: Thank you for the constructive discussion.

I just compiled kernel 2.6.12.3, and this time I tried abisko's advice by using the 'make oldconfig' to clone the previous configuration.

However, I'm not sure this worked as expected, because I used 'make mrproper' - and I think this deletes existing the existing config file, right? However, I then copied the existing config file from /boot before doing the 'make oldconfig', so perhaps it did work after all.

In any case, I got loads and loads of [Y,n] options to complete the configuration. These all seemed to be marked (NEW), as new kernel features. So I took the opportunity to say yes to a lot of features which mentioned 'PCMCIA' or 'CardBus' or 'PCI'. The truth is that I didn' t know exactly what I was doing, but it must have worked because this time the PCMCIA network card started up correctly and everything seems to work at last.

NB I still get the same messages -

These don't seem to matter, as abisko explains. Thanks again, abisko.

I suggested this before, you need to build into the kernel few things:
NICs, CONFIG_SCSI=y (for anyone using SATA) the rest is fine if left as in default SuSE 2.6.11. You may need to build USB mass storage into the kernel, if you don't then USB monitor will be added as a module and USB storage will not work at all. USB monitor must be build into the kernel.
Also few changes are required to get DMA working (and in my case also mouse wheel did not work with default SuSE config used as a template.) So try to list


Unfortunately it is better to create clean .config file

I dont have IPv6 build, because as for now it is useless.

By the way there is no advantage of "make config" or "make oldconfig" over "make menuconfig" or "make xconfig".
This is not black magic, stop spread misinformation.

Thanks for the tips broch.

Still not sure exactly which options to turn on in order to get PCMCIA working in a new kernel (it didn't work when I did 'make menuconfig' and accepted the default options for kernel 2.6.12.2). Still, I will look out for SCSI and USB mass storage options at the very least.

Why are there so many 'make' options - config, menuconfig, oldconfig, xconfig - and how exactly are they different?

Sometimes I think you must have a serious paranoia. I read this thread over and couldn't find a single line that would claim something like this. Instead, you'd better enlighten us about the differences (since they are not equal).

'defconfig' (the same as 'make config'?) creates a default configuration, 'oldconfig' doesn't start with default parameters, but uses a previous configuration as template. 'menuconfig', 'xconfig' and 'gconfig' represent different interfaces (ncurses, qt3 and gtk). To complete the list, 'make cloneconfig' tries to use the configuration embedded in the kernel as template (not all kernel are compiled with this feature). 'allmodconfig', 'allyesconfig' and 'allnoconfig' answer all questions with the respective parameter. So it really depends on what you plan to do.

'make mrproper' does indeed remove the old .config, so it is good to start with this commend and you'll be sure to start with 'clean' sources. To keep .config, you can run 'make clean'.

I am not sure if anyone speaks german or italien, but if you do, try www.thomashertweck.de/kernel26.html for some good information about this topic.

no, you simply don't know what are you talking about, you suggested already that "make install" is dangerous, you insisted that 2.6.12 vanilla will work with NICs compiled as a modules. Now you "recomend" to copy default SuSE kernel config to compile new kernel based on 2.6.12 which obviously will generate problems with vanilla. This I suggested in the previous tread, while you have been insisting that default vanilla 2.6.12 has NICs set as modules. In consequence, thanks to your advice, The OP could not resolve his problems with networking using new kernel. You also lied that you did not copy SuSE default config to vanilla (and suse has NICs set as modules in contrast to default vanilla). In consequence OP never rersolved his problems.
Personally I don't care, people are making mistakes, but at least they admit it, obviously you have problem with admitting your mistakes.
By the way several commands from your link are obsolete.

this is for of "backward" user compatibility, and not everybody is installing X. There is no difirence, however on average #make menuconfig" (requires ncurses) and make xconfig is simpler: you don't have to set main branch to see if you need it (because sub branches are visible in xconfig in contrast to config).
Anyway, you can keep 2.6.11.x series around 1.1MB and 2.6.12.x around 1.2MB.
If your first custom kernel will work, you can try to make another one more "cutting edge": add nitro or morph or love1 patches. These patches may increase GUI responsiveness, they provide way better suspend (new generation, read first about SWSUSP2 and how to use it) and these patches often add newer device drivers that sometimes will resolve problems you may have with vanilla (or default SuSE kernel). You can't apply these patches to SuSE's HEAD. Before using any of these patches, read description to see if this is worth your time.
Patches you can fing here:
http://forums.gentoo.org/viewforum-f...f866e7da6434ce

What you will need with vanilla kernels is submount - SuSE's way to automount devices: (zip, floppy, cd/dvd/rom/writers).
Submount you can find here:
http://sourceforge.net/project/showf...group_id=81174
Installation should be done ONLY from running new kernel.

Default .config of 2.6.12 will compile ATA/ATAPI/MFM/RLL support in the kernel, assuming that you are using initrd, compile ATA/.. as a module, you can add floppy as a module and so on. With 2.6.12 the exceptions from this are devices I mentioned before.
When you finish editing and save .config you should make one more change:
edit .config in your favourite editor and make one change:
adjust CONFIG_BLK_DEV_RAM_SIZE to 128000

Because default SuSE kernel is designed for all possible hardware configuration it is pretty big, so it is way better to edit config and remove not used devices and it is better to set proper CPU enable preempt, and change networking options. So if you are going to run command editing config to compile vanilla 2.6.12, you can this time start from scratch. It is a better learning experience, because you will learn how to troubleshoot custom kernels in the future. Obviously copying tested config file is easier, however as you see here sometimes new kernel will require to change several options and it is simply easier, to start from scratch. It will take less time that trying to adjust old config file.

Since you accuse me of lying, I would like you to prove your statements. Please stop attacking me in every post you write. I admitted my mistake about 'make install' immediately, what you continued to ignore. I never claimed that the NIC would be compiled as module, I was talking about ehci. I still could be wrong, however you never proved you where right. I reported your post to the moderators and I expect an apology!

I cannot expect that you read my posts, since you have never done it so far, so I quote myself:
So, where do I claim that kernel 2.6.12 has the NIC drivers as module?