Linux Kernel 3.4 RCX has Been Released To Test - Post Your Comments Here!

English Install/Boot/Login
21

Linux kernel 3.4-rc2 has been released tonight for testing here: Kernel-3.4-rc2

I was able to install the new kernel just fine using S.A.K.C and using the kernel patch for the NVIDIA driver 295.33 for kernel 3.3+ as supplied by Larry Finger here and installed using S.A.N.D.I.. All is working except for one major problem. The Firewall does not work properly for me in openSUSE. I noticed that Samba would not work after loading kernel 3.4-rc2, just as it did in rc1. I made a visit to the Firewall and turned it off. Sure enough, Samba started working, but low and behold, I can not get the Firewall started again from YaST. I have not looked into any error messages just yet as it is late here, but I will on Sunday.

Thank You,

22

On 03/31/2012 05:56 PM, jdmcdaniel3 wrote:
>
> Well tonight 3-31-12, the last day of March 2012, kernel 3.4-rc1 has
> been released for testing which you can find here:
> http://tinyurl.com/894jaf9
>
…]

Yesterday (2012 April 09), I installed RC2 from Kernel:/HEAD/standard/
for my openSUSE 12.1 / AMD integrated on-board ‘Radeon 6000 series in
Llano Apu’ - HD6530D. I have been using ‘atiupgrade’ from ‘please try
again’.

With RC1, there was no problem (not that I could see). This time, the
monitor has intermittent horizontal flickering lines especially when I
interact with the computer (mouse click, typing in a terminal emulator,
etc.).

Well, I don’t know what I’m doing here, so I got a stable kernel from
Kernel:/stable/standard/. It looks OK. I will be sticking with this. I
have unsubscribed from Kernel:/HEAD/standard/. I’ve encountered no
problems with kernels from this until now.

Anybody who knows what he’s doing can investigate the matter.

23

Kernel 3.4-rc3 has been released for testing. I was able to get it to compile and load just fine. There seems to be no current patch to get nVIDIA 295.40 to work with kernel 3.4 at present. I continues to be on prowl for such a fix and will post such if I find it.

Thank You (for using openSUSE),

24

On 04/16/2012 08:06 PM, jdmcdaniel3 wrote:
>
> Kernel 3.4-rc3 has been released for testing. I was able to get it to
> compile and load just fine. There seems to be no current patch to get
> nVIDIA 295.50 to work with kernel 3.4 at present. I continues to be on
> prowl for such a fix and will post such if I find it.
>
> Thank You (for using openSUSE),

File http://www.lwfinger.com/nvidia_patches/patch_nvidia_295_40.run_for_3.3+
works for kernels > 3.3, including 3.4-RCX.

25

Thanks Larry as always for your very much appricated help.

Thank You,

26

Kernel 3.4-rc3 can be found at Index of /repositories/Kernel:/vanilla/standard
compiling using sakc I have been getting errors after the compiling right fter I enter the root password. manually running

make modules_install install

I get two error messages 5 and 25 I think. but every thing seems to be ok

27

On 04/17/2012 06:06 AM, jdmcdaniel3 wrote:
>>
>> File http://tinyurl.com/78wzab4
>> works for kernels> 3.3, including 3.4-RCX.
>
> Thanks Larry as always for your very much appricated help.

I will try to keep up with Nvidia. If they release a version and I don’t post a
patch, please ping me.

28

So, if you are using SAKC with openSUSE 12.2 M2 or M3, you will be getting errors for now and I have posted a bug report. If you get these errors with any older version of openSUSE, please take a look at the ~/Documents folder for a text file in the format of linux-3.3.2.041312.211223.txt and towards the end, the exact operation when the error occurred would be helpful to me. If its about openSUSE 12.2 M2 or M3, post it in a message about that openSUSE version. If not beta, then post a message about it at the end of my blog on SAKC. When in doubt, you can even just email me about the problem. You can just post the info around the error or use USU Paste for anything larger,

Thank You,

29

Larry I will do just as you say. I do know that its not up to you to keep a way to install a proprietary nVIDIA driver into the latest kernel and so your efforts are way beyond the call of duty and I really do appreciate your help. I will re-post anything you give to me for all to use and give you credit for all of your efforts. It greatly allows more of us stuck on nVIDIA products to work with the latest kernel versions which is just great!

Thank You,

30

So, with some needed help from Larry to get the nVIDIA driver loaded, I am running kernel 3.4-rc3 in openSUSE 12.1 and with nVIDIA driver 295.40 and all except for one problem is working. The openSUSE 12.1 Firewall does not work properly in that it does two things. When the Firewall is autostarted and at first startup of openSUSE, no Samba shares are allowed in to view. Further, shutting down the firewall does allow Samba to work, but the Firewall can no longer be restarted. I do wonder if no one else has had a Firewall problem when using kernel 3.4-rcx besides me? Without doing anything but switching back to kernel 3.3.2, the openSUSE Firewall continues to work normally just as before.

Thank You,

31

So as I mentioned before, I can not get the openSUSE 12.1 Firewall to work when using kernel 3.4-rcx at present. I was able to determine that the kernel modules called ipt_LOG and ip6t_LOG are not loading when using kernel 3.4-rcx and that these do load when using kernel 3.3.1 or 3.3.2 in openSUSE 12.1. Right now, I really need a firewall expert to pipe in (post a comment here) and say if these two modules, if they were missing, that the openSUSE Firewall will not run. Its just a guess, but this problem, if not fixed, will make kernel 3.4 a non-starter for usage with openSUSE 12.1 if not 12.2 as well.

Thank You,

32

On 04/18/2012 05:26 PM, jdmcdaniel3 wrote:
>
> So as I mentioned before, I can not get the openSUSE 12.1 Firewall to
> work when using kernel 3.4-rcx at present. I was able to determine that
> the kernel modules called ipt_LOG and ip6t_LOG are not loading when
> using kernel 3.4-rcx and that these do load when using kernel 3.3.1 or
> 3.3.2 in openSUSE 12.1. Right now, I really need a firewall expert to
> pipe in (post a comment here) and say if these two modules, if they were
> missing, that the openSUSE Firewall will not run. Its just a guess, but
> this problem, if not fixed, will make kernel 3.4 a non-starter for usage
> with openSUSE 12.1 if not 12.2 as well.

Those two modules have been merged into xt_LOG. You need to enable
CONFIG_NETFILTER_XT_TARGET_LOG in your configuration.

33

Please forgive me for asking for more details.

Is this being changed in the Firewall configuration file /etc/sysconfig/SuSEfirewall2 as an added value to say CONFIG_NETFILTER_XT_TARGET_LOG=“yes” for instance and then run sudo /sbin/SuSEfirewall2 in terminal for it to take effect, or is this the kernel 3.4 NETFILTER_XT_TARGET_LOG =n] which should be NETFILTER_XT_TARGET_LOG =y]? I can say that the first method did not do anything different and that I get the error:

SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 ...
commit failed on table filter: No chain/target/match by that name
commit failed on table filter: No chain/target/match by that name
SuSEfirewall2: Firewall rules successfully set

I am getting ready to try the second, but in case I blow up, I am posting this question now.

Thank You,

34

On 04/18/2012 09:16 PM, jdmcdaniel3 wrote:
>
> lwfinger;2456920 Wrote:
>> On 04/18/2012 05:26 PM, jdmcdaniel3 wrote:
>>>
>>> So as I mentioned before, I can not get the openSUSE 12.1 Firewall to
>>> work when using kernel 3.4-rcx at present. I was able to determine
>> that
>>> the kernel modules called ipt_LOG and ip6t_LOG are not loading when
>>> using kernel 3.4-rcx and that these do load when using kernel 3.3.1
>> or
>>> 3.3.2 in openSUSE 12.1. Right now, I really need a firewall expert
>> to
>>> pipe in (post a comment here) and say if these two modules, if they
>> were
>>> missing, that the openSUSE Firewall will not run. Its just a guess,
>> but
>>> this problem, if not fixed, will make kernel 3.4 a non-starter for
>> usage
>>> with openSUSE 12.1 if not 12.2 as well.
>>
>> Those two modules have been merged into xt_LOG. You need to enable
>> CONFIG_NETFILTER_XT_TARGET_LOG in your configuration.
>
> Please forgive me for asking for more details.
>
> Is this being changed in the Firewall configuration file
> /etc/sysconfig/SuSEfirewall2 as an added value to say
> CONFIG_NETFILTER_XT_TARGET_LOG=“yes” for instance and then run sudo
> /sbin/SuSEfirewall2 in terminal for it to take effect, or is this the
> kernel 3.4 NETFILTER_XT_TARGET_LOG =n] which should be
> NETFILTER_XT_TARGET_LOG =y]? I can say that the first method did not
> do anything different and that I get the error:
>
>
> Code:
> --------------------
> SuSEfirewall2: Setting up rules from /etc/sysconfig/SuSEfirewall2 …
> commit failed on table filter: No chain/target/match by that name
> commit failed on table filter: No chain/target/match by that name
> SuSEfirewall2: Firewall rules successfully set
> --------------------
>
>
> I am getting ready to try the second, but in case I blow up, I am
> posting this question now.

I don’t know about the firewall. I learned about the kernel change from the
source and the git log info.

35

Well, good news, I have been able to over come the problem with the openSUSE Firewall not working in openSUSE 12.1 with kerenl 3.4-rcx loaded by changing one kernel compile .config setting as suggested by Larry here. The kernel .config file is normally not modified directly, but I was unable to find the exact setting or method to select the required setting another way.

By default, in the kernel .config file, here is the group as existed before my modification, I placed the problem setting in bold:

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
**# CONFIG_NETFILTER_XT_TARGET_LOG is not set**
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

And here it is again after the required modification that worked for me, also in bold:

#
# Xtables targets
#
CONFIG_NETFILTER_XT_TARGET_AUDIT=m
CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
CONFIG_NETFILTER_XT_TARGET_CT=m
CONFIG_NETFILTER_XT_TARGET_DSCP=m
CONFIG_NETFILTER_XT_TARGET_HL=m
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_NETFILTER_XT_TARGET_LED=m
**CONFIG_NETFILTER_XT_TARGET_LOG=m**
CONFIG_NETFILTER_XT_TARGET_MARK=m
CONFIG_NETFILTER_XT_TARGET_NFLOG=m
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
CONFIG_NETFILTER_XT_TARGET_RATEEST=m
CONFIG_NETFILTER_XT_TARGET_TEE=m
CONFIG_NETFILTER_XT_TARGET_TPROXY=m
CONFIG_NETFILTER_XT_TARGET_TRACE=m
CONFIG_NETFILTER_XT_TARGET_SECMARK=m
CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

It is obvious that this setting must become the default in any future versions of openSUSE to use the present Firewall configuration and the next kernel version 3.4. Is anyone listening out there?

Thank You,

36

On 04/19/2012 06:06 PM, jdmcdaniel3 wrote:
>
> Well, good news, I have been able to over come the problem with the
> openSUSE Firewall not working in openSUSE 12.1 with kerenl 3.4-rcx
> loaded by changing one kernel compile .config setting as suggested by
> Larry here. The kernel .config file is normally not modified directly,
> but I was unable to find the exact setting or method to select the
> required setting another way.
>
> By default, in the kernel .config file, here is the group as existed
> before my modification, I placed the problem setting in bold:
>
>
> Code:
> --------------------
> #
> # Xtables targets
> #
> CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
> CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
> CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
> CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
> CONFIG_NETFILTER_XT_TARGET_CT=m
> CONFIG_NETFILTER_XT_TARGET_DSCP=m
> CONFIG_NETFILTER_XT_TARGET_HL=m
> CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
> CONFIG_NETFILTER_XT_TARGET_LED=m
> # CONFIG_NETFILTER_XT_TARGET_LOG is not set
> CONFIG_NETFILTER_XT_TARGET_MARK=m
> CONFIG_NETFILTER_XT_TARGET_NFLOG=m
> CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
> CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
> CONFIG_NETFILTER_XT_TARGET_RATEEST=m
> CONFIG_NETFILTER_XT_TARGET_TEE=m
> CONFIG_NETFILTER_XT_TARGET_TPROXY=m
> CONFIG_NETFILTER_XT_TARGET_TRACE=m
> CONFIG_NETFILTER_XT_TARGET_SECMARK=m
> CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
> CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m
> --------------------
>
>
> And here it is again after the required modification that worked for
> me, also in bold:
>
>
> Code:
> --------------------
> #
> # Xtables targets
> #
> CONFIG_NETFILTER_XT_TARGET_AUDIT=m
> CONFIG_NETFILTER_XT_TARGET_CHECKSUM=m
> CONFIG_NETFILTER_XT_TARGET_CLASSIFY=m
> CONFIG_NETFILTER_XT_TARGET_CONNMARK=m
> CONFIG_NETFILTER_XT_TARGET_CONNSECMARK=m
> CONFIG_NETFILTER_XT_TARGET_CT=m
> CONFIG_NETFILTER_XT_TARGET_DSCP=m
> CONFIG_NETFILTER_XT_TARGET_HL=m
> CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
> CONFIG_NETFILTER_XT_TARGET_LED=m
> CONFIG_NETFILTER_XT_TARGET_LOG=m
> CONFIG_NETFILTER_XT_TARGET_MARK=m
> CONFIG_NETFILTER_XT_TARGET_NFLOG=m
> CONFIG_NETFILTER_XT_TARGET_NFQUEUE=m
> CONFIG_NETFILTER_XT_TARGET_NOTRACK=m
> CONFIG_NETFILTER_XT_TARGET_RATEEST=m
> CONFIG_NETFILTER_XT_TARGET_TEE=m
> CONFIG_NETFILTER_XT_TARGET_TPROXY=m
> CONFIG_NETFILTER_XT_TARGET_TRACE=m
> CONFIG_NETFILTER_XT_TARGET_SECMARK=m
> CONFIG_NETFILTER_XT_TARGET_TCPMSS=m
> CONFIG_NETFILTER_XT_TARGET_TCPOPTSTRIP=m

I will keep an eye on this and send a path if the parameter is not set in the
3.4 kernels.

37

That’s great Larry and thanks for putting me on the right track. So, this .config setting of “CONFIG_NETFILTER_XT_TARGET_LOG=m” who would be making it a default, in the kernel proper or in the default openSUSE kernel configuration? Again, thanks for your help.

Thank You (for using openSUSE),

38

On 04/20/2012 06:16 AM, jdmcdaniel3 wrote:
> That’s great Larry and thanks for putting me on the right track. So,
> this .config setting of “CONFIG_NETFILTER_XT_TARGET_LOG=m” who would be
> making it a default, in the kernel proper or in the default openSUSE
> kernel configuration? Again, thanks for your help.

It will be in the openSUSE default kernel configuration. The kernel will always
maintain the flexibility to completely disable any particular option if at all
possible. After all, does the OS in a washing machine need a firewall?

39

On Fri, 20 Apr 2012 21:11:50 +0530, Larry Finger
<Larry.Finger@lwfinger.net> wrote:

> On 04/20/2012 06:16 AM, jdmcdaniel3 wrote:
>> That’s great Larry and thanks for putting me on the right track. So,
>> this .config setting of “CONFIG_NETFILTER_XT_TARGET_LOG=m” who would be
>> making it a default, in the kernel proper or in the default openSUSE
>> kernel configuration? Again, thanks for your help.
>
> It will be in the openSUSE default kernel configuration. The kernel will
> always maintain the flexibility to completely disable any particular
> option if at all possible. After all, does the OS in a washing machine
> need a firewall?

i’d say, “definitely yes!” to that question. if i had a washing machine,
and that had an OS, i sure wouldn’t want my angry neighbor able to flood
my apartment remotely.

–
phani.

40

On 04/20/2012 10:51 AM, phanisvara das wrote:
>
> i’d say, “definitely yes!” to that question. if i had a washing machine, and
> that had an OS, i sure wouldn’t want my angry neighbor able to flood my
> apartment remotely.

Sorry, but I failed to find the network plug on my washing machine. :wink: