On 28/04/2020 03:08, Masaru Nomiya wrote:

Which kernel have you installed?

Yes, that might matter. I'm running 5.6.6-1 from the Kernel Stable repository, as i've commented before, and have /lib/modules/5.6.6-1.gc11f000-default/kernel/drivers/net/hamradio/mkiss.ko.xz

Maybe, mkiss's driver is compressed.

/lib/modules/[kernel version/kernel/drivers/net/hamradio/mkiss.ko.xz

If so, please try this;

$ sudo xz -d /lib/modules/[kernel version/kernel/drivers/net/hamradio/mkiss.ko.xz

You will get the kernel driver, mkiss.ko.

Pease don't take that advice. ALL kernel modules are in the form <name>.ko.xz It is how the kernel loads them. decompressing one will break things. No, more likely what you were using to automagically load that module vanished in the upgrade. FIRST: determine if you kernel has that module What kernel are you using # uname -r Now try # ls /lib/modules/$(uname -r)/kernel/drivers/net/hamradio/mkiss.ko.xz If that's not there then yes, you have a problem. maybe # find /lib -name '*mkiss*' -print will show something useful. maybe not, but it's worth a try. But DO NOT UNCOMPRESS kernel modules! -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/04/2020 13.44, Carlos E. R. wrote:

On 28/04/2020 13.39, Anton Aylward wrote:

...

On 28/04/2020 03:08, Masaru Nomiya wrote:

...

Which kernel have you installed?

I would try bugzilla. Meanwhile, the solution would be roll your own kernel.

Or you can switch to the 15.2 kernel - which I did for another reason. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Anton Aylward wrote:

On 28/04/2020 09:06, Carlos E. R. wrote:

...

On 28/04/2020 13.44, Carlos E. R. wrote:

...

On 28/04/2020 13.39, Anton Aylward wrote:

...

On 28/04/2020 03:08, Masaru Nomiya wrote:

...

Which kernel have you installed?

...

I would try bugzilla. Meanwhile, the solution would be roll your own kernel.

Or you can switch to the 15.2 kernel - which I did for another reason.

Let's see, build 638 is the latest. What kernel version is therein?

5.3.18 - and I see the mkiss module there. -- Per Jessen, Zürich (15.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

...

Maybe, mkiss's driver is compressed.

/lib/modules/[kernel version/kernel/drivers/net/hamradio/mkiss.ko.xz

If so, please try this;

$ sudo xz -d /lib/modules/[kernel version/kernel/drivers/net/hamradio/mkiss.ko.xz

You will get the kernel driver, mkiss.ko.

Please don't take that advice. ALL kernel modules are in the form <name>.ko.xz

Uh no, that's is new, Anton, probably only in Tumbleweed.

FIRST: determine if you kernel has that module

-> modinfo mkiss If you do decompress the module (for whatever reason), just run 'depmod' afterwards. I see 'mkiss' in 15.0 and in Tumbleweed, but not in 15.1. Tumbleweed: # zgrep -i mkiss /proc/config.gz CONFIG_MKISS=m Leap 15.1: per@test150:~> zgrep -i mkiss /proc/config.gz (nothing) I think it should have shown: CONFIG_MKISS is not set Rough guess - mkiss was removed from that kernel, for some reason. -- Per Jessen, Zürich (17.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <r896jc$iod$1@saturn.local.net> Date & Time: Tue, 28 Apr 2020 14:12:28 +0200

[PJ] == Per Jessen <per@computer.org> has written:

[...] PJ> I think it should have shown:

PJ> CONFIG_MKISS is not set

PJ> Rough guess - mkiss was removed from that kernel, for some reason.

Are you sure?

No, that's why I said 'rough guess' :-)

Please do compile the kernel with

kernel-source-5.6.7-3.1.g00d8515.src.rpm kernel-default-5.6.7-3.1.g00d8515.nosrc.rpm

You would find the kernel driver. mkiss.ko.

Yes, no doubt about that, but that is in Tumbleweed, and Marc is running Leap 15.1. -- Per Jessen, Zürich (17.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/04/2020 09:01, Masaru Nomiya wrote:

I'm also using Leap 15.1, not Tumbleweed. Anyway, where can we find the specific kernel for Tumbleweed, I wonder?

Yes, it's the kernel version not the OS level. As i said, I'm using kernel stable from http://download.opensuse.org/repositories/Kernel:/stable/standard/ If you drill down on the http://download.opensuse.org/repositories/Kernel:/ you will find many architectures and OS revisions. I suspect that Tumbleweed is dealt with elsewhere. Since I don't use it, despite what Per says, its not in my collection. But then tumbleweed is not an officially distributed package. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 28/04/2020 14.12, Per Jessen wrote:

...

Anton Aylward wrote:

...

...

Maybe, mkiss's driver is compressed.

/lib/modules/[kernel version/kernel/drivers/net/hamradio/mkiss.ko.xz

If so, please try this;

$ sudo xz -d /lib/modules/[kernel version/kernel/drivers/net/hamradio/mkiss.ko.xz

You will get the kernel driver, mkiss.ko.

Please don't take that advice. ALL kernel modules are in the form <name>.ko.xz

Uh no, that's is new, Anton, probably only in Tumbleweed.

I see much older versions:

test_a__factory_10.2/lib/modules/2.6.18.2-34-default/kernel/drivers/net/hamradio/mkiss.ko

I was commenting on Anton's assertion that "ALL kernel modules are in the form <name>.ko.xz". -- Per Jessen, Zürich (17.4°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Anton Aylward wrote:

On 28/04/2020 08:12, Per Jessen wrote:

...

I see 'mkiss' in 15.0 and in Tumbleweed, but not in 15.1.

I'm running 15.1 and I have it. it seems to be dependent on the kernel version not the release number.

Ah, that's good news - maybe it was re-introduced in an update. I checked it on a system running 4.12.14-lp151.28.36 - maybe your's is newer? -- Per Jessen, Zürich (17.6°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/04/2020 15.20, Anton Aylward wrote:

On 28/04/2020 09:14, Per Jessen wrote:

...

Anton Aylward wrote:

...

On 28/04/2020 08:12, Per Jessen wrote:

...

I see 'mkiss' in 15.0 and in Tumbleweed, but not in 15.1.

I'm running 15.1 and I have it. it seems to be dependent on the kernel version not the release number.

Ah, that's good news - maybe it was re-introduced in an update. I checked it on a system running 4.12.14-lp151.28.36 - maybe your's is newer?

I check for kernel updates daily. Yes, i realise that the same 'changes' that end up in later number kernels might be available as 'patches' to older numbered kernels, but I prefer a completely clean and properly numbered change sequence.

I currently have

ls /boot/initrd-* /boot/initrd-4.15.7-3.g4e5b14d-default /boot/initrd-5.6.5-2.g1bdcfdf-default /boot/initrd-5.6.4-2.g902100b-default /boot/initrd-5.6.6-1.gc11f000-default /boot/initrd-5.6.5-1.g6656dc4-default /boot/initrd-5.6.7-2.gb520bde-default

None of which are stock 15.1 stuff. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 28/04/2020 15.40, Anton Aylward wrote:

On 28/04/2020 09:26, Carlos E. R. wrote:

...

On 28/04/2020 15.20, Anton Aylward wrote:

...

On 28/04/2020 09:14, Per Jessen wrote:

...

Anton Aylward wrote:

...

On 28/04/2020 08:12, Per Jessen wrote:

...

I see 'mkiss' in 15.0 and in Tumbleweed, but not in 15.1.

I'm running 15.1 and I have it. it seems to be dependent on the kernel version not the release number.

Ah, that's good news - maybe it was re-introduced in an update.  I checked it on a system running 4.12.14-lp151.28.36 - maybe your's is newer?

I check for kernel updates daily. Yes, i realise that the same 'changes' that end up in later number kernels might be available as 'patches' to older numbered kernels, but I prefer a completely clean and properly numbered change sequence.

I currently have

ls /boot/initrd-* /boot/initrd-4.15.7-3.g4e5b14d-default  /boot/initrd-5.6.5-2.g1bdcfdf-default /boot/initrd-5.6.4-2.g902100b-default   /boot/initrd-5.6.6-1.gc11f000-default /boot/initrd-5.6.5-1.g6656dc4-default   /boot/initrd-5.6.7-2.gb520bde-default

None of which are stock 15.1 stuff.

Sorry, since they are out there in a approved repository I consider them 'stock'. That they are not on the distribution is is quite another matter.

No, they aren't. Not the supported oss repo. The stock version is the official version. repositories/Kernel:/ is not an official version, it is experimental. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 28/04/2020 10:59, Dave Howorth wrote:

Right, but the whole point of this thread is supposed to be helping somebody who IS running the normal distribution stuff.

It's NOT supposed to be bragging about how your kernels are bigger and better than everybody else who has non-default (who all seem to be doing the same bragging, I hasten to add).

...

As i say, i don't think patching the distribution disk's kernel is a strategy that gives me the control I want.

That the /etc/zypp/zypp.conf file provides the capability to support multiple version of the kernel OUT OF THE BOX.

All I've done is set it to accommodate a specific span.

So what you are asking for is 'install and don't change anything'. Don't alter any of the *.conf files, don't add extra repositories. Ultimately this also means don't use zypper or its GUI equivalent in YaST to update anything. !BOGUS! As I said, claiming that the kernel with the of the one in the distribution is meaningless if patches have been applied to it by the regular update process. At least I'm being honest by admitting that kernel to which update changes are applied is a new, a different kernel and should be recognised as such by renumbering. The only 'bigger' kernels under discussion are those that are bigger because they have the extra mkiss module file. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/04/2020 09:36, Per Jessen wrote:

Leap 15.1 is still on 4.12.14-lp151.28.48 (just upgraded a system). I guess you're running KOTD or some such?

No, I've stated, repeatedly in this thread, that I'm using kernel Stable and retaining a number of STABLE kernels. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/04/2020 09:46, Per Jessen wrote:

Anton Aylward wrote:

...

On 28/04/2020 09:36, Per Jessen wrote:

...

Leap 15.1 is still on 4.12.14-lp151.28.48 (just upgraded a system). I guess you're running KOTD or some such?

No, I've stated, repeatedly in this thread, that I'm using kernel Stable and retaining a number of STABLE kernels.

Anton, you can't expect us to remember what you are running and when. Second, in this thread I see mentioning it exactly once.

More to the point - it won't help Marc as he is running a vanilla Leap 15.1 system, recently upgraded.

Since we - you too - advise adding repositories such as Packman immediately, I would think that kernel updates, being more tightly concerned with immediate issues, security being just one of them, would also rate. Like I said, I want to see and be able to roll back to specific kernels (without the cumbersome demands of BtrFS). I don't think continuously patching the distribution kernel is a healthy approach. I think it is deceptive, hides what the real revisions are. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 28/04/2020 16.17, Per Jessen wrote:

Marc Chamberlin wrote:

...

Any help would be greatly appreciated! (and please don't simple tell me what I need to do, I am venturing into unknown territory here, so actual commands and examples, like pictures, are worth a thousand words!) Thanks,  Marc....

Hi Marc

to summarise the thread sofar -

the 4.12.14 kernel in Leap 15.1 does not have the mkiss module. It appears it was removed.

As Carlos suggested, a bugreport might be sensible.

To fix your immediate problem, think I would install a later kernel, it seems e.g. 5.6.0 has the mkiss module.

The recommended kernel to use in this case (by devs) is the stock kernel in 15.2. It is what they will probably say in the bugzilla, what they told me in another recent bugzilla. More or less kernel-default-5.3.18-lp152.10.4.x86_64 And it has that module. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 29/04/2020 02.28, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <3eb88881-7f72-ab64-a773-28ca9d7aa60c@telefonica.net> Date & Time: Tue, 28 Apr 2020 16:56:07 +0200

[CER] == "Carlos E. R." <> has written:

[...] CER> The recommended kernel to use in this case (by devs) is the stock kernel in CER> 15.2. It is what they will probably say in the bugzilla, what CER> they told me in another recent bugzilla.

CER> More or less kernel-default-5.3.18-lp152.10.4.x86_64

What's the meaning of 'The recommended kernel'?

The one they are recommending on bugzilla for 15.1

In my case,

$ uname -r 5.6.7-2.1-default

with the modified config file according to my environments.

That's different, you are building it. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 29/04/2020 10.19, Masaru Nomiya wrote:

Hello, ...

[CER] == "Carlos E. R." <> has written:

[...] MN> > What's the meaning of 'The recommended kernel'?

CER> The one they are recommending on bugzilla for 15.1

Ah, not your opinion.

CER> > CER> > In my case, CER> > CER> > $ uname -r 5.6.7-2.1-default CER> > CER> > with the modified config file according to my environments.

CER> That's different, you are building it.

Yes, I always build the kernel, by myself. If there's problem, please inform me of it.

No problem :-) Just that it is different methodology, more complex. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Marc Chamberlin wrote:

Hi all who have pitched in to help, thank you and thanks Per Jessen for summarizing for me! Wow I didn't think I would stir up such a discussion ruckus! ;-)  I will answer some of the questions that have been asked but it sounds like I should just resign myself to doing another upgrade to 15.2.

Carlos' suggestion of just upgrading the kernel to whatever is currently in 15.2 sounds good. I think that'll give you exactly what you're after, 'mkiss'.

I will submit a bug report also but doesn't sound like it will do much good LOL,

It is a bit late in the game for 15.1, yeah, and it looks like it was already spotted by someone. You can simply download the 15.2 kernel as an RPM, and install it with rpm or zypper. HTH Per (many years ago OZ1HZV) -- Per Jessen, Zürich (14.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/28/20 11:30 AM, Carlos E. R. wrote:

The way I do it is:

Create directory to use as repository. Say, "/data/LocalRPMs_15.1-15.2-kernel/". cd to it, write this script:

#!/bin/bash echo echo "****************** Processing oss/64" echo lynx -listonly -dump -nonumbers "http://download.opensuse.org/distribution/leap/15.2/repo/oss/x86_64" > 0list_1 uniq 0list_1 0list_2 grep -e "kernel.*rpm\|nfs-kernel.*rpm\|virtualbox.*rpm" 0list_2 | grep -v "\.mirrorlist\|.drpm" > 0list_3 aria2c --continue --allow-overwrite=false --auto-file-renaming=false --input-file=0list_3

echo echo "****************** Processing oss/noarch" echo lynx -listonly -dump -nonumbers "http://download.opensuse.org/distribution/leap/15.2/repo/oss/noarch/"/ > 0list_1 uniq 0list_1 0list_2 grep -e "kernel.*rpm\|nfs-kernel.*rpm\|virtualbox.*rpm" 0list_2 | grep -v "\.mirrorlist\|.drpm" > 0list_3 aria2c --continue --allow-overwrite=false --auto-file-renaming=false --input-file=0list_3

echo echo "****************** Processing update/oss/64" echo lynx -listonly -dump -nonumbers "http://download.opensuse.org/update/leap/15.2/oss/x86_64/" > 0list_1 uniq 0list_1 0list_2 grep -e "kernel.*rpm\|nfs-kernel.*rpm\|virtualbox.*rpm" 0list_2 | grep -v "\.mirrorlist\|.drpm" > 0list_3 aria2c --continue --allow-overwrite=false --auto-file-renaming=false --input-file=0list_3

echo echo "****************** Processing update/oss/noarch" echo lynx -listonly -dump -nonumbers http://download.opensuse.org/update/leap/15.2/oss/noarch/ > 0list_1 uniq 0list_1 0list_2 grep -e "kernel.*rpm\|nfs-kernel.*rpm\|virtualbox.*rpm" 0list_2 | grep -v "\.mirrorlist\|.drpm" > 0list_3 aria2c --continue --allow-overwrite=false --auto-file-renaming=false --input-file=0list_3

rm *meta4 *.aria2

Then run it.

Then, add that repo using yast or zypper. Finally, open up YaST and switch to this new repo.

Each time you want to update the machine, run that script first.

Thanks Carlos for this script and your time of course.  I set up a directory and ran the script but before I proceed further I want to report that the script appeared to give me a lot of download errors. Here is a random  sample of what I saw -

04/28 12:54:56 [ERROR] CUID#293 - Download aborted. URI=http://mirror.siena.edu/opensuse/distribution/leap/15.2/repo/oss/noarch/virt... Exception: [AbstractCommand.cc:351] errorCode=3 URI=http://mirror.siena.edu/opensuse/distribution/leap/15.2/repo/oss/noarch/virt...   -> [HttpSkipResponseCommand.cc:219] errorCode=3 Resource not found [DL:11MiB][#78a2ef 79MiB/107MiB(73%)][#043b08 78MiB/118MiB(66%)][#ddac24 110MiB/118MiB(93%)][#d77eb7 160KiB/866KiB(18%)][#107407 0B/877KiB(0%)] 04/28 12:54:56 [ERROR] CUID#294 - Download aborted. URI=http://www.muug.mb.ca/pub/opensuse/distribution/leap/15.2/repo/oss/noarch/vi... Exception: [AbstractCommand.cc:351] errorCode=3 URI=http://www.muug.mb.ca/pub/opensuse/distribution/leap/15.2/repo/oss/noarch/vi...   -> [HttpSkipResponseCommand.cc:219] errorCode=3 Resource not found

04/28 12:54:56 [ERROR] CUID#295 - Download aborted. URI=http://mirrors.ucr.ac.cr/opensuse/distribution/leap/15.2/repo/oss/noarch/vir... Exception: [AbstractCommand.cc:351] errorCode=3 URI=http://mirrors.ucr.ac.cr/opensuse/distribution/leap/15.2/repo/oss/noarch/vir...   -> [HttpSkipResponseCommand.cc:219] errorCode=3 Resource not found

Do I need to worry about these?  I do see a whole lot of rpm files created in the directory after I ran this script...   Marc.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/28/20 3:01 PM, Carlos E. R. wrote:

The thing is, it is not just updating the kernel, but other things. Huh, do you use nvidia proprietary drivers? Then you need more files. I have a script modification for that as well.

Ok I won't sweat the errors and yes I do use nvidia graphic/video cards...  Again many thanks!   Marc... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 4/28/20 3:14 PM, Carlos E. R. wrote:

On 29/04/2020 00.08, Marc Chamberlin wrote:

...

On 4/28/20 3:01 PM, Carlos E. R. wrote:

...

The thing is, it is not just updating the kernel, but other things. Huh, do you use nvidia proprietary drivers? Then you need more files. I have a script modification for that as well. Ok I won't sweat the errors and yes I do use nvidia graphic/video cards...  Again many thanks!   Marc... Ok!

Create another directory, say "LocalRPMs_15.1-15.2-nvidia"

#!/bin/bash

echo echo "****************** Processing oss/64" echo lynx -listonly -dump -nonumbers "http://http.download.nvidia.com/opensuse/leap/15.2/x86_64/" > 0list_1 uniq 0list_1 0list_2 grep -e "nvidia.*rpm" 0list_2 | grep -v "\.mirrorlist\|.drpm" > 0list_3 aria2c --continue --allow-overwrite=false --auto-file-renaming=false --input-file=0list_3

Provided the nvidia 15.2 repo does exist already, I do not know.

Hi again Carlos, everyone, I fear I need to pick your brains (and all other gurus) a little further, and I apologize for not understanding what is going on with building kernels and their drivers... I am making some guesses here and my communication may not be precise, be wary. I got almost all the way and managed to upgrade the kernel and even managed to almost get it to boot up to the point where the KDE desktop is suppose to show up. The problem I think (BIG guess here) is that the 15.2 repo did not include the same version of the nvidia drivers that I am using in 15.1. I installed the repo as per your suggestion/script and noted that this new repo did not include the drivers for "nvidia-gfxG03-kmp-default - NVIDIA graphics driver kernel module for GeForce 8xxx and newer GPUs", and associated nvidia packages for gfxG03. The new repo did have drivers for gfxG04 and gfxG05 packages which I think are for newer nvidia cards. I have an older GeForce 8500. Not knowing what to do about the fact that there was no gfxG03 packages in the 15.2 repo I chose not to do anything and just leave the nVidia packages as it. That resulted, when I rebooted, and got to the point where the KDE login prompt normally appears, in that all I got was a big fat cursor arrow that I could move around, but nothing more. No login prompt, no desktop, nada. No error messages showed up while I watched the output from all the system startup steps. Other than buying a newer nVidia graphics card, any suggestions? Maybe it is not an nVidia issue but perhaps I need other newer packages such as for the KDE destop with Plasma? I am again just guessing, what do I know? LOL  (Thank goodness that the GRUB menu does allow me to reboot back to either the older 15.1 or 42.2 systems, where everything works as before, so I didn't brick my computer!)  Thanks again for any more suggestions...   Marc.... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote: [snip]

...

Other than buying a newer nVidia graphics card,

Don't. Whatever happens, don't. At worst, buy a new ATI/AMD card. Seriously.

Just build the nvidia drivers for your Geforce card. At least that is what we do and some of our desktop machines are all quite old, with e.g. Quadro FX 4600. Or maybe we use nouveau, I'll have to check. -- Per Jessen, Zürich (10.3°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 29/04/2020 09.32, Per Jessen wrote:

...

Carlos E. R. wrote:

[snip]

...

...

Other than buying a newer nVidia graphics card,

Don't. Whatever happens, don't. At worst, buy a new ATI/AMD card. Seriously.

Just build the nvidia drivers for your Geforce card. At least that is what we do and some of our desktop machines are all quite old, with e.g. Quadro FX 4600. Or maybe we use nouveau, I'll have to check.

That doesn't work in some cases, because the packages may have dependencies on rpms that are not installed. That's the case, for example, with FlightGear, for example (Bug 1132952). (libglvnd support and libopencl conflict)

Maybe Marc doesn't need Flightgear (just like I don't) :-) -- Per Jessen, Zürich (10.6°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Per Jessen wrote:

Carlos E. R. wrote:

[snip]

...

...

Other than buying a newer nVidia graphics card,

Don't. Whatever happens, don't. At worst, buy a new ATI/AMD card. Seriously.

Just build the nvidia drivers for your Geforce card. At least that is what we do and some of our desktop machines are all quite old, with e.g. Quadro FX 4600. Or maybe we use nouveau, I'll have to check.

We use nouveau. I know I've built the drivers in the past though. I don't recall any issues in that. -- Per Jessen, Zürich (11.5°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, In the Message; Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <d5564f96-79c1-2260-a1f2-234035189355@telefonica.net> Date & Time: Wed, 29 Apr 2020 09:10:18 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] CER> > nvidia drivers that I am using in 15.1. I installed the repo as per your CER> > suggestion/script and noted that this new repo did not include the drivers for CER> > "nvidia-gfxG03-kmp-default - NVIDIA graphics driver kernel module for GeForce CER> > 8xxx and newer GPUs", and associated nvidia packages for gfxG03. The new repo CER> > did have drivers for gfxG04 and gfxG05 packages which I think are for newer CER> > nvidia cards. I have an older GeForce 8500. CER> AHHH! That's bad luck. And it is the reason why I changed my hardware: I CER> changed to AIT/AMD graphics. I had that same problem as you, I CER> saw this coming :-/ Why do you say so without looking the result of; $ rpm -qa --last Regards, --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ Think. -- The IBM slogan -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29/04/2020 14.39, Patrick Shanahan wrote:

* Carlos E. R. <robin.listas@telefonica.net> [04-29-20 03:21]:

...

On 29/04/2020 06.13, Marc Chamberlin wrote: [...]

...

...

Not knowing what to do about the fact that there was no gfxG03 packages in the 15.2 repo I chose not to do anything and just leave the nVidia packages as it. That resulted, when I rebooted, and got to the point where the KDE login prompt normally appears, in that all I got was a big fat cursor arrow that I could move around, but nothing more. No login prompt, no desktop, nada. No error messages showed up while I watched the output from all the system startup steps. Other than buying a newer nVidia graphics card,

Don't. Whatever happens, don't. At worst, buy a new ATI/AMD card. Seriously.

VERY misguided information

[...]

Absolutely not. I stand by it, with the many that recommended me to do it. And very happy of having done it. As a last recourse. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Op vrijdag 1 mei 2020 01:06:46 CEST schreef Marc Chamberlin:

...

Plan C: in your situation, *I* would go back to the 15.1 kernel, install the sources, and compile my own kernel with the mkiss driver added. I can guide you with this one.

No need for the entire sources. kernel-default-devel is enough ( apart from the other deps from the 'hard way' What works: Install dkms Enable ( and start ) the dkms service through YaST's services manager Download the latest appropriate NVIDIA....run for your card Run the NVIDIA......run with --dkms option. It will trigger a rebuild of the nvidia kernel modules at a kernel update. On major kernel updates people have reported 1. To need an extra reboot 2. To need to download a newer NVIDIA...run from NVIDIA's site. -- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op vrijdag 1 mei 2020 01:46:04 CEST schreef Carlos E. R.:

On 01/05/2020 01.34, Knurpht-openSUSE wrote:

...

Op vrijdag 1 mei 2020 01:06:46 CEST schreef Marc Chamberlin:

...

...

Plan C: in your situation, *I* would go back to the 15.1 kernel, install the sources, and compile my own kernel with the mkiss driver added. I can guide you with this one.

No need for the entire sources.

Plan C needs the entire sources, because the idea is to build a new kernel with the mkiss module included.

Your plan is a variation of plan B, proprietary Nvidia drivers the hard way, but with dkms.

I will wait for Marc to see if your plan works, and if not I'll explain the plan C in detail ;-)

...

kernel-default-devel is enough ( apart from the other deps from the 'hard way' What works: Install dkms Enable ( and start ) the dkms service through YaST's services manager Download the latest appropriate NVIDIA....run for your card Run the NVIDIA......run with --dkms option. It will trigger a rebuild of the nvidia kernel modules at a kernel update. On major kernel updates people have reported 1. To need an extra reboot 2. To need to download a newer NVIDIA...run from NVIDIA's site. If you rebuild the kernel from sources and use the existing config, you end up with the same kernel. Must say I haven't read the entire thread. That would have kept me busy for another day :D

-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Op vrijdag 1 mei 2020 04:20:23 CEST schreef Carlos E. R.:

On 01/05/2020 02.32, Knurpht-openSUSE wrote:

...

Op vrijdag 1 mei 2020 01:46:04 CEST schreef Carlos E. R.:

...

On 01/05/2020 01.34, Knurpht-openSUSE wrote:

...

Op vrijdag 1 mei 2020 01:06:46 CEST schreef Marc Chamberlin:

...

...

Plan C: in your situation, *I* would go back to the 15.1 kernel, install the sources, and compile my own kernel with the mkiss driver added. I can guide you with this one.

No need for the entire sources.

Plan C needs the entire sources, because the idea is to build a new kernel with the mkiss module included.

Your plan is a variation of plan B, proprietary Nvidia drivers the hard way, but with dkms.

I will wait for Marc to see if your plan works, and if not I'll explain the plan C in detail ;-)

...

kernel-default-devel is enough ( apart st the other deps from the 'hard way' What works: Install dkms Enable ( and start ) the dkms service through YaST's services manager Download the latest appropriate NVIDIA....run for your card Run the NVIDIA......run with --dkms option. It will trigger a rebuild of the nvidia kernel modules at a kernel update. On major kernel updates people have reported 1. To need an extra reboot 2. To need to download a newer NVIDIA...run from NVIDIA's site.

If you rebuild the kernel from sources and use the existing config, you end up with the same kernel. Must say I haven't read the entire thread. That would have kept me busy for another day :D

I know, so I have to explain him how to clone the existing config, then how to modify the correct setting for what he needs, and how to make it all. Not trivial.

(assuming the module builds and was not removed intentionally) Which would leave Marc with a sytem that can no way be upgraded to 15.2 without a lot of manual interference. Why not deal with defaults and really fix things? From what I read - following the list - almost every one of you is running a modified system. How would packagers, realease people ever be able to deal with that? No one f.e. will create an openQA test for upgrading a 15.1 install with a 15.2 kernel.

-- Gertjan Lettink a.k.a. Knurpht openSUSE Forums Team -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/05/2020 00:24, Knurpht-openSUSE wrote:

From what I read - following the list - almost every one of you is running a modified system.

Indeed. I've modified the list of repositories, added, at the very least, Packman - which is a 'suggested' change - so I can reliable viw videos, partitioned my disk further and so altered /etc/fstab. I've altered the Postfixto deal with my domain, with my ISP and routing and some filtering. I've added accounts to my Thunderbird settings and my Firefox bookmarks are plentiful. let's not get into the add-ins/extension for those two Mozilla tools. Oh, and I've customised my backup processes. Lets get read, you expect me NOT to do that?. I may look and sound like an idiot but at least I do backups[1] This is Linus after all; it is supposed to be mutable. Not like my camera or many other things I own

How would packagers, realease people ever be able to deal with that?

Either they don't or 'with perplexity'. I don't have to move from 15.1 to 15.2 to drown in .rpmnew files where the new 'upgrades' have, for example, dot-conf files, that come into conflict with my updates. But WTF, I'm lecturing to the choir. This is why I dread upgrades. They blow apart my carefully and carefully considered configured system.

No one f.e. will create an openQA test for upgrading a 15.1 install with a 15.2 kernel.

Indeed. Certainly not a realistic, useable, 15.1 system. [1] and yes, Ii know Schroedinger's law of backups applies. “The condition of any backup is unknown until a restore is attempted.” https://www.novastor.com/blog/schrodingers-backup-good-bad-backup -- This message represents the official view of the voices in my head -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/05/2020 09:58, Patrick Shanahan wrote:

* Anton Aylward <opensuse@antonaylward.com> [05-01-20 08:46]: [...]

...

I don't have to move from 15.1 to 15.2 to drown in .rpmnew files where the new 'upgrades' have, for example, dot-conf files, that come into conflict with my updates.

But WTF, I'm lecturing to the choir.

This is why I dread upgrades. They blow apart my carefully and carefully considered configured system.

Jim Dandy to the rescue

er s/Jim Dandy/Tumbleweed

but even Tumbleweed does not endure forever, accumulation of cruft and "old standards" still eventually require/call for re-installation. I got six years before succumbing the last time.

Fair enough. Tumbleweed is one form of 'incrementalism', and a pretty aggressive one at that. My use of kernel_Stable is a focused for of aggressive incrementalism. It would have addressed the OP's problem and is quite compatible with all the 15.1. With nvidia? I can't say based on my own experience; I don't run nvidia; i run intel and my experimental boards run AMD. I suppose running 'zypper up' daily is another form of 'soft' incrementalism. Yes i do that and yes I'd recommend looking at it. It may not be as dramatic as Tumbleweed in it's completeness, it may not last for the six years, but once you have a stable system, incrementalism is less disruptive than the 'catastrophism' of a complete upgrade. if you google for 'gradualism vs catastrophism' you find this to be an ancient debating issue in both geomorphology and genetics. Both areas have seen pretty vociferous "discussion" on the matter, so I'd expect nothing gentle here on the matter :-) -- It isn't that they can't see the solution. It's that they can't see the problem. - G. K. Chesterton -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 01/05/2020 04.38, Masaru Nomiya wrote: ...

Just a misrepresentation!

The kernel already include the mkiss's driver. As I wrote before, openSUSE's kernel maintainer compressed it as mkiss.ko.xz.

Sorry, no, it doesn't. The default kernel en 15.1 doesn't. The one in 15.0 or 15.2 do have the module. It is missing in 15.1. And it is not compressed. /lib/modules/5.3.18-lp152.10-default/kernel/drivers/net/hamradio/mkiss.ko Telcontar:~ # modprobe mkiss Telcontar:~ # rmmod mkiss Remember he has Leap 15.1, not TW. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 13.42, Masaru Nomiya wrote:

Hello,

....

I downloaded and checked the openSUSE Leap 15.1's original kernel (4.12.14), and recognized that the it doesn't include the mkiss's driver.

So, I wrote a script for the mkiss's driver, and attach it.

You start with: wget https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.12.14.tar.xz Why? The default openSUSE sources for 15.1 have the mkiss.c module: Telcontar:~ # locate mkiss.c /usr/src/linux-4.12.14-lp151.28.44/drivers/net/hamradio/mkiss.c <====== /usr/src/linux-5.3.18-lp152.10/drivers/net/hamradio/mkiss.c Telcontar:~ # It is safer to use the openSUSE kernel, it has a lot of patches than the upstream does not. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 14.45, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <40cbad1a-6c9e-dba5-541d-3ed1bacde0bb@gmx.es> Date & Time: Fri, 1 May 2020 13:51:58 +0200

[CER] == "Carlos E.R." <> has written:

CER> On 01/05/2020 13.42, Masaru Nomiya wrote: CER> > Hello,

CER> .... CER> > CER> > I downloaded and checked the openSUSE Leap 15.1's original kernel CER> > (4.12.14), and recognized that the it doesn't include the mkiss's CER> > driver. CER> > CER> > So, I wrote a script for the mkiss's driver, and attach it.

CER> You start with:

CER> wget https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.12.14.tar.xz CER> Why?

CER> The default openSUSE sources for 15.1 have the mkiss.c module:

Can you manage it? If so, please show your own method for him

Yes, I will, but I'm waiting for him to comment first if method B with dkms works or not for him, or if he wants to try method C instead (which is what I would do).

I'd like to show just an easiest method.

CER> Telcontar:~ # locate mkiss.c CER> /usr/src/linux-4.12.14-lp151.28.44/drivers/net/hamradio/mkiss.c <====== CER> /usr/src/linux-5.3.18-lp152.10/drivers/net/hamradio/mkiss.c CER> Telcontar:~ #

CER> It is safer to use the openSUSE kernel, it has a lot of patches CER> than the upstream does not.

No, just one patch only.

The entire kernel has lots of patches. It is not about a single module. I can not recommend downloading the kernel from upstream. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 15.28, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <3ab248eb-9898-8595-6a6f-86cd68ad9b2c@telefonica.net> Date & Time: Fri, 1 May 2020 14:54:49 +0200

[CER] == "Carlos E. R." <> has written:

[...] CER> > Can you manage it? CER> > If so, please show your own method for him

CER> Yes, I will, but I'm waiting for him to comment first if method B with dkms CER> works or not for him, or if he wants to try method C instead CER> (which is what I would do).

I couldn't understand the difference between Plan B and Plan C.

What's the difference?

Plan B was install 15.2 kernel (done) and install Nvidia driver the hard way (failed). Plan C is install a modified kernel. It was explained days ago. Before doing your way (plan C) he has to undo the applied plan B. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 16.35, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <ad953623-5b2a-9949-86eb-9119608c6380@telefonica.net> Date & Time: Fri, 1 May 2020 15:59:32 +0200

[CER] == "Carlos E. R." <> has written:

[...] CER> > I couldn't understand the difference between Plan B and Plan C. CER> > CER> > What's the difference?

CER> Plan B was install 15.2 kernel (done) and install Nvidia driver CER> the hard way (failed).

Did he failed with the proprietary driver?

Or, with the openSUSE provided driver?

Both. gfxG03 rpm does not exist. He could not make "the hard way": <https://en.opensuse.org/SDB:NVIDIA_the_hard_way>

CER> Plan C is install a modified kernel.

CER> It was explained days ago.

CER> Before doing your way (plan C) he has to undo the applied plan B.

Are these plans designed for the mkiss's driver? If so, why?

Plans B and C were the alternatives we offered him to try. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 15.59, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <3ab248eb-9898-8595-6a6f-86cd68ad9b2c@telefonica.net> Date & Time: Fri, 1 May 2020 14:54:49 +0200

[CER] == "Carlos E. R." <> has written:

[...] CER> > CER> > No, just one patch only.

CER> The entire kernel has lots of patches. It is not about a single CER> module. I can not recommend downloading the kernel from upstream.

I fully understand why you completely misread.

1. openSUSE Leap 15.1's kernel 4.12.x all are using linux-4.12.tar.xz as a source file. But, in my script, I use the linux-4.12.14.tar.xz. Do you understand the defferences between these two files.

Yes, but I say that downloading the upstream sources is a mistake and is not needed.

2. If you execute my script, you can see the building process use the installed openSUSE's kernel source files, not the linux-4.12.14's.

Huh? Then why download them at all? -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 16.46, Masaru Nomiya wrote:

Hello,

In the Message;

Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <a2c19193-d62f-fe2d-fab8-f60467e2d04b@telefonica.net> Date & Time: Fri, 1 May 2020 16:01:31 +0200

[CER] == "Carlos E. R." <> has written:

[...] CER>> I fully understand why you completely misread. CER>> CER>> 1. openSUSE Leap 15.1's kernel 4.12.x all are using linux-4.12.tar.xz CER>> as a source file. But, in my script, I use the CER>> linux-4.12.14.tar.xz. CER>> Do you understand the defferences between these two files.

CER> Yes, but I say that downloading the upstream sources is a CER> mistake and is not needed.

I can understand about half of what you are saying.

Yes, I noticed that :-)

CER>> 2. If you execute my script, you can see the building process use the CER>> installed openSUSE's kernel source files, not the linux-4.12.14's.

CER> Huh? Then why download them at all?

Sorry, I was under the wrong impression.

BTW, did you inspect .config file of kernel 4.12.14 closely?

It doesn't include the CONFIG_MKISS entry. How can you manage to produce the mkiss's driver?

No, I did not look. I know that the source file is present: /usr/src/linux-4.12.14-lp151.28.44/drivers/net/hamradio/mkiss.c So I assumed the entry would be in the config file. I can confirm that it is not present here :-((

ANyway, it's midnight now, here in Japan.

Regards & Good Night,

Good night! :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Content-ID: <alpine.LSU.2.21.2005012150360.16357@Telcontar.valinor> On Friday, 2020-05-01 at 22:33 +0300, Andrei Borzenkov wrote:

Отправлено с iPhone

...

1 мая 2020 г., в 21:18, Carlos E. R. <robin.listas@telefonica.net> написал(а):



No, I did not look. I know that the source file is present:

/usr/src/linux-4.12.14-lp151.28.44/drivers/net/hamradio/mkiss.c

So I assumed the entry would be in the config file. I can confirm that it is not present here :-((

You need to enable HAMRADIO before you can enable individual drivers.

Ah, of course, makes sense. I was going to build the entire kernel, then I would have seen it. The way of building only one module is unknown to me. Do you know what section it is? I'm looking on "make menuconfig". I had no need to build a kernel for ages. Ah, yes, there is search. Type "/". ┌──────────────────── Search Results ──────── │ Symbol: HAMRADIO [=n] │ Type : boolean │ Prompt: Amateur Radio support │ Location: │ (1) -> Networking support (NET [=y]) │ Defined at net/ax25/Kconfig:5 │ Depends on: NET [=y] && !S390 So: [*] Networking support ---> then [ ] Amateur Radio support ---- Type "y" Now search for "mkiss". │ Symbol: MKISS [=n] │ │ Type : tristate │ │ Prompt: Serial port KISS driver │ │ Location: │ │ -> Networking support (NET [=y]) │ │ -> Amateur Radio support (HAMRADIO [=y]) │ │ (1) -> Amateur Radio AX.25 Level 2 protocol (AX25 [=n]) │ │ -> AX.25 network device drivers │ │ Defined at drivers/net/hamradio/Kconfig:1 │ │ Depends on: NET [=y] && HAMRADIO [=y] && AX25 [=n] && TTY [=y] │ │ Selects: CRC16 [=y] │ So: [*] Amateur Radio support ---> < > Amateur Radio AX.25 Level 2 protocol Type y AX.25 network device drivers ---> finally < > Serial port KISS driver (NEW) Type 'm' save. Still, does not build: Telcontar:/usr/src/linux # grep -i mkiss .config CONFIG_MKISS=m Telcontar:/usr/src/linux # Telcontar:/usr/src/linux # make M=drivers/net/hamradio Building modules, stage 2. MODPOST 0 modules Telcontar:/usr/src/linux # l drivers/net/hamradio/mkiss* - -rw-r--r-- 1 root root 24307 Apr 17 07:38 drivers/net/hamradio/mkiss.c Telcontar:/usr/src/linux # As I said, I know how to build the entire kernel, but not a single module as Masaru Nomiya does on his script: ... make mrproper (I don't) cp /lib/modules/`uname -r`/build/.config ./ (I use /proc/config) cp /usr/lib/modules/`uname -r`/build/Module.symvers ./ (it is not there) make oldconfig make prepare && make scripts make M=drivers/net/hamradio xz -z drivers/net/hamradio/mkiss.ko ... I will check "/usr/src/linux/README.SUSE". The first method involves the following steps: (1) Install the kernel-source package. (2) Configure the kernel, see HOW TO CONFIGURE THE KERNEL SOURCES. (3) Create files required for compiling external modules: ``make prepare'' and ``make scripts''. (4) Compile the module(s) by changing into the module source directory and typing ``make -C $(your_build_dir) M=$(pwd)''. (5) Install the module(s) by typing ``make -C $(your_build_dir) M=$(pwd) modules_install''. Still no go... Telcontar:/usr/src/linux # cd drivers/net/hamradio/ Telcontar:/usr/src/linux/drivers/net/hamradio # make make: *** No targets. Stop. Telcontar:/usr/src/linux/drivers/net/hamradio # make -C . make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' make: *** No targets. Stop. make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' Telcontar:/usr/src/linux/drivers/net/hamradio # Telcontar:/usr/src/linux/drivers/net/hamradio # make M=$(pwd) make: *** No targets. Stop. Telcontar:/usr/src/linux/drivers/net/hamradio # make -C . M=$(pwd) make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' make: *** No targets. Stop. make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' Telcontar:/usr/src/linux/drivers/net/hamradio # - -- Cheers, Carlos E. R. (from openSUSE 15.1 x86_64 at Telcontar) -----BEGIN PGP SIGNATURE----- iHoEARECADoWIQQZEb51mJKK1KpcU/W1MxgcbY1H1QUCXqyCXRwccm9iaW4ubGlz dGFzQHRlbGVmb25pY2EubmV0AAoJELUzGBxtjUfV1TsAn0+/L1Og0EDi0JkMnN5Y PsSZLggWAJ9TwjACV29/YfSOR9LfmdWpCWpv4A== =qN2Y -----END PGP SIGNATURE-----

Hello, In the Message; Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <ed95f66e-3f14-bc14-0e51-f5465aa3ba39@suddenlinkmail.com> Date & Time: Sat, 2 May 2020 03:33:58 -0500 [DCR] == "David C. Rankin" <drankinatty@suddenlinkmail.com> has written: DCR> On 05/01/2020 03:11 PM, Carlos E. R. wrote: DCR> > Still no go... DCR> > DCR> > DCR> > Telcontar:/usr/src/linux # cd drivers/net/hamradio/ DCR> > Telcontar:/usr/src/linux/drivers/net/hamradio # make DCR> > make: *** No targets. Stop. DCR> This is a *guess* (but probably an educated one). I'm sure that kernel network DCR> support, and the remainder of the modules you need depend on other modules DCR> from the kernel build. I suspect, to build an individual module DCR> like you are attempting, needs a prior build of the kernel to DCR> draw from. (could be totally wrong -- but that is what your DCR> troubles suggest) To be sure, I compiled the kernel 4.12.14 source files (linux-4.12.14.tar.xz) with the options; [...] # # AX.25 network device drivers # CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_YAM=m CONFIG_CAN=m CONFIG_CAN_RAW=m CONFIG_CAN_BCM=m CONFIG_CAN_GW=m [...] As a result, I got the below files in the drivers/net/hamradio directory; 6pack.ko baycom_par.ko baycom_ser_fdx.ko baycom_ser_hdx.ko bpqether.ko hdlcdrv.ko mkiss.ko yam.ko That is, Carlos's conclusion; In the Message; Subject : Re: [opensuse] mkiss kernel module missing - executing plan C - fails. Message-ID : <c22cadfd-1187-015a-7f4e-0e9480c8b1a7@telefonica.net> Date & Time: Fri, 1 May 2020 20:48:40 +0200 [CER] == "Carlos E. R." <robin.listas@telefonica.net> has written: [...] CER> At this point, the only way out I see is the bugzilla. is entirely correct, I think. I couldn't dig out the cause, though. Regards, --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/05/2020 11.02, Andrei Borzenkov wrote:

01.05.2020 23:11, Carlos E. R. пишет:

...

Content-ID: <alpine.LSU.2.21.2005012150360.16357@Telcontar.valinor>

On Friday, 2020-05-01 at 22:33 +0300, Andrei Borzenkov wrote:

...

Отправлено с iPhone

...

...

1 мая 2020 г., в 21:18, Carlos E. R. <robin.listas@telefonica.net> написал(а):



No, I did not look. I know that the source file is present:

/usr/src/linux-4.12.14-lp151.28.44/drivers/net/hamradio/mkiss.c

So I assumed the entry would be in the config file. I can confirm that it is not present here :-((

...

You need to enable HAMRADIO before you can enable individual drivers.

Ah, of course, makes sense.

..

...

Still, does not build:

Telcontar:/usr/src/linux # grep -i mkiss .config CONFIG_MKISS=m Telcontar:/usr/src/linux #

You must not compile anything inside /usr/src/linux. README.SUSE makes it pretty clear.

I explained why I don't: ]> Notes: ]> ]> a) Purists will say that it is wrong to do this as root. Well, it happens that none of the above runs as user, because of the ownership of the files. Doing as user is more complicated, so I will not. Can you explain how to do it? How to do it as user in another directory? I don't understand what the readme says - and I have been reading the file for years and never noticed that it was supposed to explain how to do it as user in another directory, till today you said it is there: (2) Create a build directory for use in configuring and building the kernel. Using /usr/src/linux directly requires root priviledges and will cause problems if you need to build kernel modules for other installed kernels. (3) Configure the kernel (for example, ``make -C /usr/src/linux O=$(pwd) oldconfig'', see HOW TO CONFIGURE THE KERNEL SOURCES).

...

Telcontar:/usr/src/linux # make M=drivers/net/hamradio Building modules, stage 2. MODPOST 0 modules Telcontar:/usr/src/linux # l drivers/net/hamradio/mkiss* -rw-r--r-- 1 root root 24307 Apr 17 07:38 drivers/net/hamradio/mkiss.c Telcontar:/usr/src/linux #

Your /usr/src/linux state is already broken, so I have no idea what happens here. You seem to execute random commands without any understanding what they are supposed to do.

You are making wrong assumptions. All I have done in there has been posted in this thread. The kernel tree was installed clean.

...

As I said, I know how to build the entire kernel, but not a single module as Masaru Nomiya does on his script:

This script is for vanilla upstream kernel, not for SUSE distributed kernel sources. How is this script relevant (unless you actually understand what script does and can adapt it to your specific case)?

Then how about you kindly explain how to do it instead of remonstrating to me? I know he is using the vanilla kernel, and I told him that this was not correct. I'm using the openSUSE sources instead, and trying to use only part of what he does, but does not work. And no, of course I do not understand what he is doing, I said so. I have never tried to build a single module, this is is a first for me and trying to learn how to do it.

...

... make mrproper (I don't)

cp /lib/modules/`uname -r`/build/.config ./ (I use /proc/config)

cp /usr/lib/modules/`uname -r`/build/Module.symvers ./ (it is not there)

So much about executing some random script you found somewhere on Internet.

Not on internet. Not random. You have not been reading this thread. It was posted *HERE* on this thread by Masaru Nomiya, yesterday: Date: Fri, 01 May 2020 21:45:31 +0900 Message-ID: <87mu6rx1qs.wl-nomiya@galaxy.dti.ne.jp> From: Masaru Nomiya <nomiya@...> To: opensuse@opensuse.org Subject: Re: [opensuse] mkiss kernel module missing In-Reply-To: <40cbad1a-6c9e-dba5-541d-3ed1bacde0bb@gmx.es> I assumed he knew.

...

make oldconfig

make prepare && make scripts

make M=drivers/net/hamradio

xz -z drivers/net/hamradio/mkiss.ko

...

I will check "/usr/src/linux/README.SUSE".

The first method involves the following steps:

(1) Install the kernel-source package.

(2) Configure the kernel, see HOW TO CONFIGURE THE KERNEL SOURCES.

(3) Create files required for compiling external modules: ``make prepare'' and ``make scripts''.

(4) Compile the module(s) by changing into the module source directory and typing ``make -C $(your_build_dir) M=$(pwd)''.

(5) Install the module(s) by typing ``make -C $(your_build_dir) M=$(pwd) modules_install''.

Still no go...

Telcontar:/usr/src/linux # cd drivers/net/hamradio/ Telcontar:/usr/src/linux/drivers/net/hamradio # make make: *** No targets. Stop. Telcontar:/usr/src/linux/drivers/net/hamradio # make -C . make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' make: *** No targets. Stop. make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' Telcontar:/usr/src/linux/drivers/net/hamradio #

Telcontar:/usr/src/linux/drivers/net/hamradio # make M=$(pwd) make: *** No targets. Stop. Telcontar:/usr/src/linux/drivers/net/hamradio # make -C . M=$(pwd) make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' make: *** No targets. Stop. make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48/drivers/net/hamradio' Telcontar:/usr/src/linux/drivers/net/hamradio #

I do not know where even to start commenting this.

Anyway - you cannot compile additional module that is part of kernel source tree and that is disabled in SUSE kernel config as part of SUSE kernel. You must either

But I enabled it. cer@Telcontar:/usr/src/linux> grep -i mkiss .config CONFIG_MKISS=m

a) force this module to be built as external module. That is BUILDING ADDITIONAL EXTERNAL MODULES in README.SUSE and most simple is (2).

"BUILDING ADDITIONAL (EXTERNAL) MODULES" (1) by configuring the kernel sources in a separate build directory (see HOW TO CONFIGURE THE KERNEL SOURCES), or (2) by using one of the standard configurations in /usr/src/linux-obj/$ARCH/$FLAVOR, or cer@Telcontar:~> ls /usr/src/linux-obj/x86_64/default Makefile Module.supported Module.symvers arch include scripts tools cer@Telcontar:~> Clear as mud, sorry. The first method involves the following steps: (1) Install the kernel-source package. Done. (2) Configure the kernel, see HOW TO CONFIGURE THE KERNEL SOURCES. Done. (3) Create files required for compiling external modules: ``make prepare'' and ``make scripts''. Done (4) Compile the module(s) by changing into the module source directory and typing ``make -C $(your_build_dir) M=$(pwd)''. Fails. (5) Install the module(s) by typing ``make -C $(your_build_dir) M=$(pwd) modules_install''. Let's see the other method in the readme, which you say you use. The second method involves the following steps: (1) Install the kernel-devel package. Happens to be installed: cer@Telcontar:~> rpm -q kernel-devel kernel-devel-4.12.14-lp151.28.44.1.noarch kernel-devel-4.12.14-lp151.28.48.1.noarch cer@Telcontar:~> (2) Install the kernel-$FLAVOR-devel package. This is necessary for symbol version information (CONFIG_MODVERSIONS). Happens to be installed: cer@Telcontar:~> rpm -q kernel-default-devel kernel-default-devel-4.12.14-lp151.28.44.1.x86_64 kernel-default-devel-4.12.14-lp151.28.48.1.x86_64 cer@Telcontar:~> (3) Compile the module(s) by changing into the module source directory and typing ``make -C /usr/src/linux-obj/$ARCH/$FLAVOR M=$(pwd)''. Substitute $ARCH and $FLAVOR with the architecture and flavor for which to build the module(s). Seems to me that it is doing the operation directly on the /usr/src/linux directory as root. It doesn't explain how to do it in another directory. Anyway, it is using linux-obj as you, so one part explained. If the installed kernel sources match the running kernel, you can build modules for the running kernel by using the path /lib/modules/$(uname -r)/build as the -C option in the above command. (build is a symlink to /usr/src/linux-obj/$ARCH/$FLAVOR). They do. cer@Telcontar:~> l /lib/modules/$(uname -r)/build lrwxrwxrwx 1 root root 53 Apr 17 18:00 /lib/modules/4.12.14-lp151.28.48-default/build -> /usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default/ cer@Telcontar:~> (4) Install the module(s) with ``make -C /usr/src/linux-obj/$ARCH/$FLAVOR M=$(pwd) modules_install''.

Of course you need to also build ax25 module that is required by mkiss, so

And you know this how? Maybe of course you happen to know. How am I supposed to know? Anyway: cer@Telcontar:/usr/src/linux> grep -i ax25 .config CONFIG_AX25=y CONFIG_AX25_DAMA_SLAVE=y cer@Telcontar:/usr/src/linux>

bor@leap15:/usr/src/linux> cp -a net/ax25 /tmp

Ah, you copy a part of the source directory to a temporary directory outside. Well, the readme fails to explain this. I don't see why the original sources can not be used and we need a copy, the make process is not supposed to write to the source files.

bor@leap15:/usr/src/linux> sed -ie 's/\(obj-\)$(CONFIG_AX25)/\1m/' /tmp/ax25/Makefile

I have no idea what this is doing, sorry.

bor@leap15:/usr/src/linux> make -C /usr/src/linux-obj/x86_64/default M=/tmp/ax25

Mmm.

make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' LD /tmp/ax25/built-in.o CC [M] /tmp/ax25/ax25_addr.o CC [M] /tmp/ax25/ax25_dev.o CC [M] /tmp/ax25/ax25_iface.o CC [M] /tmp/ax25/ax25_in.o CC [M] /tmp/ax25/ax25_ip.o CC [M] /tmp/ax25/ax25_out.o CC [M] /tmp/ax25/ax25_route.o CC [M] /tmp/ax25/ax25_std_in.o CC [M] /tmp/ax25/ax25_std_subr.o CC [M] /tmp/ax25/ax25_std_timer.o CC [M] /tmp/ax25/ax25_subr.o CC [M] /tmp/ax25/ax25_timer.o CC [M] /tmp/ax25/ax25_uid.o CC [M] /tmp/ax25/af_ax25.o CC [M] /tmp/ax25/sysctl_net_ax25.o LD [M] /tmp/ax25/ax25.o Building modules, stage 2. MODPOST 1 modules CC /tmp/ax25/ax25.mod.o LD [M] /tmp/ax25/ax25.ko make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' bor@leap15:/usr/src/linux> cp -a drivers/net/hamradio/ /tmp

And now you copy another directory.

bor@leap15:/usr/src/linux> sed -ie 's/\(obj-\)$(CONFIG_MKISS)/\1m/' /tmp/hamradio/Makefile

I don't understand what that does, sorry.

bor@leap15:/usr/src/linux> make -C /usr/src/linux-obj/x86_64/default M=/tmp/hamradio KBUILD_EXTRA_SYMBOLS=/tmp/ax25/Module.symvers make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' LD /tmp/hamradio/built-in.o CC [M] /tmp/hamradio/mkiss.o Building modules, stage 2. MODPOST 1 modules CC /tmp/hamradio/mkiss.mod.o LD [M] /tmp/hamradio/mkiss.ko make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' bor@leap15:/usr/src/linux> find /tmp/ax25 /tmp/hamradio -name \*.ko /tmp/ax25/ax25.ko /tmp/hamradio/mkiss.ko

Ok

bor@leap15:/usr/src/linux> sudo insmod /tmp/ax25/ax25.ko bor@leap15:/usr/src/linux> sudo insmod /tmp/hamradio/mkiss.ko bor@leap15:/usr/src/linux> dmesg | tail [12667.358420] NET: Registered protocol family 3 [12675.514306] mkiss: AX.25 Multikiss, Hans Albas PE1AYX bor@leap15:/usr/src/linux>

Ok.

b) compile your own kernel with the same configuration as SUSE kernel with addition of your module.

That is what I was going to do till Masaru Nomiya posted another method that seemed simpler.

That is variant COMPILING YOUR OWN KERNEL in README.SUSE.

-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 02/05/2020 13.32, Per Jessen wrote:

Carlos E. R. wrote:

...

...

Of course you need to also build ax25 module that is required by mkiss, so

And you know this how? Maybe of course you happen to know. How am I supposed to know?

'modinfo mkiss' will tell you ("depends"), but I think it was also evident in the config menu you posted some of earlier.

cer@Telcontar:~/tmp/kernel> modinfo mkiss modinfo: ERROR: Module mkiss not found. cer@Telcontar:~/tmp/kernel> In the search in "menuconfig", perhaps: .config - Linux/x86 4.12.14 Kernel Configuration → Search (mkiss) ───────────────────────────────────────────────────────────── ┌──────────────────────────── Search Results ─────────────────────────────┐ │ Symbol: MKISS [=n] │ │ Type : tristate │ │ Prompt: Serial port KISS driver │ │ Location: │ │ -> Networking support (NET [=y]) │ │ (1) -> Amateur Radio support (HAMRADIO [=n]) │ │ -> Amateur Radio AX.25 Level 2 protocol (AX25 [=n]) │ │ -> AX.25 network device drivers │ │ Defined at drivers/net/hamradio/Kconfig:1 │ │ Depends on: NET [=y] && HAMRADIO [=n] && AX25 [=n] && TTY [=y] │ │ Selects: CRC16 [=y] │ │ │ │ │ │ │ │ │ │ │ ├─────────────────────────────────────────────────────────────────(100%)──┤ │ < Exit > │ └─────────────────────────────────────────────────────────────────────────┘

...

...

bor@leap15:/usr/src/linux> cp -a net/ax25 /tmp

Ah, you copy a part of the source directory to a temporary directory outside. Well, the readme fails to explain this. I don't see why the original sources can not be used and we need a copy, the make process is not supposed to write to the source files.

The whole idea is building an out-of-tree module - the process presumes the source is _not_ part of the kernel sources. That's why Andrei created a copy somewhere else.

If I had sent you a tarball with the module sources, you would probably also have untar'ed into your homedir, e.g. /home/carlos/pers-mkiss/

It is somewhat absurd, the kernel sources are already in /usr/src/linux, they should have designed a method to do it without replicating the tree. Anyway, I am trying, and I got: cer@Telcontar:~/tmp/kernel> l total 612 drwxr-xr-x 8 cer users 222 May 2 13:36 ./ drwxr-xr-x 121 cer users 8192 May 2 12:42 ../ -rw-r--r-- 1 cer users 22 May 2 13:32 .21461.d -rw-r--r-- 1 cer users 200427 May 2 13:36 .config -rw-r--r-- 1 cer users 200089 May 2 13:32 .config.old -rw-r--r-- 1 cer users 200089 May 2 13:34 .configcopy -rw-r--r-- 1 cer users 850 May 2 13:32 .missing-syscalls.d drwxr-xr-x 2 cer users 6 May 2 13:32 .tmp_versions/ -rw-r--r-- 1 cer users 629 May 2 13:34 Makefile drwxr-xr-x 3 cer users 17 May 2 13:32 arch/ drwxr-xr-x 4 cer users 37 May 2 13:32 include/ drwxr-xr-x 2 cer users 43 May 2 13:32 kernel/ drwxr-xr-x 7 cer users 291 May 2 13:32 scripts/ lrwxrwxrwx 1 cer users 34 May 2 13:34 source -> /usr/src/linux-4.12.14-lp151.28.48/ drwxr-xr-x 3 cer users 21 May 2 13:32 tools/ cer@Telcontar:~/tmp/kernel> As you see, the sources were symlinked by the preparation scripts. Why copy them again? I am follwing the readme, method one: BUILDING ADDITIONAL (EXTERNAL) MODULES ... (1) by configuring the kernel sources in a separate build directory (see HOW TO CONFIGURE THE KERNEL SOURCES), or (2) by using one of the standard configurations in /usr/src/linux-obj/$ARCH/$FLAVOR, or (3) by creating a Kernel Module Package (KMP) as described in the Kernel Module Packages Manual, https://drivers.suse.com/doc/kmpm/. The first method involves the following steps: (1) Install the kernel-source package. (2) Configure the kernel, see HOW TO CONFIGURE THE KERNEL SOURCES. Done. (3) Create files required for compiling external modules: ``make prepare'' and ``make scripts''. Done. However, I did first the prepare and scripts, then menuconfig, in that order. First time I notice the instructions in reverse order. (4) Compile the module(s) by changing into the module source directory and typing ``make -C $(your_build_dir) M=$(pwd)''. cer@Telcontar:~/tmp/kernel> cd source/net/ax25/ cer@Telcontar:~/tmp/kernel/source/net/ax25> pwd /home/cer/tmp/kernel/source/net/ax25 cer@Telcontar:~/tmp/kernel/source/net/ax25> Now, what is "my_build_dir"? "/home/cer/tmp/kernel/"? It fails: cer@Telcontar:~/tmp/kernel/source/net/ax25> make -C /home/cer/tmp/kernel/ M=$(pwd) make: Entering directory '/home_aux/cer/tmp/kernel' arch/x86/Makefile:136: CONFIG_X86_X32 enabled but no binutils support mkdir: cannot create directory ‘/home/cer/tmp/kernel/source/net/ax25/.tmp_versions’: Permission denied WARNING: Symbol version dump ./Module.symvers is missing; modules will have no dependencies and modversions. LD /home/cer/tmp/kernel/source/net/ax25/built-in.o ar: /home/cer/tmp/kernel/source/net/ax25/built-in.o: Permission denied make[3]: *** [/usr/src/linux-4.12.14-lp151.28.48/scripts/Makefile.build:479: /home/cer/tmp/kernel/source/net/ax25/built-in.o] Error 1 make[2]: *** [/usr/src/linux-4.12.14-lp151.28.48/Makefile:1569: _module_/home/cer/tmp/kernel/source/net/ax25] Error 2 make[1]: *** [Makefile:152: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 make: Leaving directory '/home_aux/cer/tmp/kernel' cer@Telcontar:~/tmp/kernel/source/net/ax25> Well, obviously permission denied. It is trying to write to "/usr/src/linux", not to my build directory... So what is the incantation, following the readme.suse method one? (5) Install the module(s) by typing ``make -C $(your_build_dir) M=$(pwd) modules_install''. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 03/05/2020 12.59, Andrei Borzenkov wrote:

02.05.2020 14:55, Carlos E. R. пишет:

...

Well, obviously permission denied. It is trying to write to "/usr/src/linux", not to my build directory...

You continue to mix "building external module" and "building your own kernel".

Sorry, but I do not understand. I'm not building an external module, I'm building just one or two modules of the distributed kernel. An external module would be me downloading the nvidia thing separately. I'm not downloading anything, I use the suse rpm. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 02/05/2020 14.03, Anton Aylward wrote:

On 02/05/2020 07:32, Per Jessen wrote:

...

'modinfo mkiss' will tell you

What? oh, wait, that says it is from tumbleweed. But I'm not running tumbleweed, am I?

I check a pile of other module that I see I'm running by using 'lsmod' to find them. They all say: suserelease: openSUSE Tumbleweed

Or is kernel_Stable "tumbleweed by another name'?

You are using the TW kernel by another name.

All this, of course, gets back to Patrick's observations about updating the kernel with Tumbleweed.

-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Hello, In the Message; Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <905c4117-e312-6806-314d-7846060e988f@marcchamberlin.com> Date & Time: Sat, 2 May 2020 15:03:10 -0700 [MC] == Marc Chamberlin <marc@marcchamberlin.com> has written: [...] MC> send me a set of instructions before I do anything further. ;-) MC> I have submitted a bug report about the missing mkiss module, and got the following response which I added a further comment and pushed back on - MC> Takashi Iwai  commented on the bug report - MC>> CONFIG_HAMRADIO was set off already in Leap 15.0, so it's nothing MC>> new in Leap 15.1. MC>> We've disabled drivers that appear almost unused at upgrading to the major MC>> version, and this was one of the results, I suppose. Certainly, google answered, 'Ham on Linux? It's a history'. :-) Anyway, I inspected the files of kernel 4.12.14, but I couldn't find out the disabling the HAMRADIO. He uses a magic, I wonder. Moreover, in kernel 5.6.x, it is set; [...] CONFIG_HAMRADIO=y [...] Why? I'd like to know, but 5.6.x isn't supported... Regards, --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ "No Windows, no gains!" ..... "Why, I am wrong?" -- Bill -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello, In the Message; Subject : Re: [opensuse] mkiss kernel module missing Message-ID : <2108883.A6BUGiGr17@djunix> Date & Time: Sun, 03 May 2020 08:45:18 +0200 [DJ] == "Dr.-Ing. Dieter Jurzitza" <dieter.jurzitza@t-online.de> has written: DJ> Dear Nomiya San, Hi, Jurzitza San, again. DJ> please look into the config file of 4.12.14: DJ> ****** DJ> CONFIG_NET_DROP_MONITOR=m DJ> # CONFIG_HAMRADIO is not set DJ> ****** Yes, I saw it. [...] DJ> I re-enabled it for testing purposes and had to add some DJ> additional entries, then the modules are build and can be found DJ> in the hamradio - directory of the modules of the kernel. Thanks. I'd like to know which file(s) in the src.rpms concerns this settings. I compared the files of 4.2.14 and of 5.6.x , I couldn't find out the differencs. But, inspect, again. Regards, --- ┏━━┓彡 Masaru Nomiya mail-to: nomiya @ galaxy.dti.ne.jp ┃＼／彡 ┗━━┛ Think. -- The IBM slogan -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/05/2020 00.03, Marc Chamberlin wrote:

Carlos, Andrie, Per, Anton, Masaru -  I just wanted to let you all know that I am following along with the discussions (not fully understanding) about the rebuilding of the kernel with the missing modules. I have not disappeared and I really appreciate the amount of effort you are putting into resolving this problem for me so a BIG thanks.  I will wait until the dust settles and you can send me a set of instructions before I do anything further. ;-)

I can post the procedure I wrote till yesterday, but I'm stuck on what to do next.

I have submitted a bug report about the missing mkiss module, and got the following response which I added a further comment and pushed back on -

Takashi Iwai  commented on the bug report -

...

CONFIG_HAMRADIO was set off already in Leap 15.0, so it's nothing new in Leap 15.1.

We've disabled drivers that appear almost unused at upgrading to the major version, and this was one of the results, I suppose.

But they are enabled in 15.1 -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Hello Dieter  How kind of you! Yes I would take you up on your offer, I think that would make it much easier for me. I have never tried building the Linux kernel or any of it's sub modules, and from all the conversations going on about it, it sounds a bit daunting!  And yes, I found this email of yours in my "Junk" folder, and I have tried twice to respond directly back to you but the emails kept bouncing back after the server tried 25 times to send them,  which is why I haven't responded until now. My apologies. I am kinda sad and worried that OpenSuSE might be giving up on us amateur radio operators, I have been a long time fan of OpenSuSE primarily because of their wonderful support for amateur radio in the past. If no one wants to support these modules any more maybe I could step in and help. I am an experienced programmer, but I would need help/mentoring to learn how to work with the kernel and these modules as well as the OpenSuSE software development processes.     Marc... On 5/3/20 3:52 AM, Dr.-Ing. Dieter Jurzitza wrote:

Hello Marc, maybe my email ended in your spam folder ... I could provide readily built ready to go kernel packages based on the current openSUSE kernel, packaged as rpm so you could easily upgrade and remove again without fiddling around with homegrown solutions - but, as I said, I would need to know whether you want this :-) If you want it I would send you a link for download. Best

Dieter

Am Sonntag, 3. Mai 2020, 12:36:32 CEST schrieb Carlos E. R.:

...

On 03/05/2020 00.03, Marc Chamberlin wrote:

...

Carlos, Andrie, Per, Anton, Masaru - I just wanted to let you all know that I am following along with the discussions (not fully understanding) about the rebuilding of the kernel with the missing modules. I have not disappeared and I really appreciate the amount of effort you are putting into resolving this problem for me so a BIG thanks. I will wait until the dust settles and you can send me a set of instructions before I do anything further. ;-) I can post the procedure I wrote till yesterday, but I'm stuck on what to do next.

...

I have submitted a bug report about the missing mkiss module, and got the following response which I added a further comment and pushed back on -

Takashi Iwai commented on the bug report -

...

CONFIG_HAMRADIO was set off already in Leap 15.0, so it's nothing new

in Leap 15.1.

...

We've disabled drivers that appear almost unused at upgrading to the

major version, and this was one of the results, I suppose. But they are enabled in 15.1

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hello Marc, so here comes the "howto": 1.) open a console and become superuser. Change to the directory where the downloaded kernel-*.rpm's from the download are. 2.) check which kernels are installed: rpm -qa | grep "^kernel" The result should look similar to this: djunix:/home/src/kernel/Hamradio-addon # rpm -qa | grep "^kernel" kernel-default-4.12.14-lp151.28.48.1.x86_64 kernel-firmware-20200107-lp151.2.12.1.noarch kernel-default-4.12.14-lp151.28.44.1.x86_64 djunix:/home/src/kernel/Hamradio-addon # You can safely forget about the 28.44.1. The most recent one should be kernel-default-4.12.14-lp151.28.48.1.x86_64 If you have more kernel-* - files installed please let me know! 3.) now you can upgrade (still assuming that you are in the directory with the downloaded files): rpm -Uhv kernel-default-4.12.14-lp151.28.50.1.x86_64.rpm this will take a while, dracut will build a new initrd. Please reboot, this ought to work smoothly (I very much hope though cannot guarantee!) Then you should load the mkiss.ko - module by doing a modprobe mkiss as superuser and you ought to be fine. You can find it in the directory /lib/modules/4.12.14-lp151.28.50.1-default/kernel/drivers/net/hamradio but you do not need to go there. Hope everything runs fine! In case of _any_ deviation in the procedure described above, _any_ error message please write an email. And, on top of this, please retest my email address - I assume you accidentally made a typo .... somewhere. I am not aware of one single person not being able to send emails to me - but you :-(. Take care, Dieter Am Montag, 4. Mai 2020, 17:21:56 CEST schrieb Marc Chamberlin:

Hello Dieter How kind of you! Yes I would take you up on your offer, I think that would make it much easier for me. I have never tried building

-- ----------------------------------------------------------- Dr.-Ing. Dieter Jurzitza 76131 Karlsruhe -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Marc Chamberlin wrote:

I am kinda sad and worried that OpenSuSE might be giving up on us amateur radio operators,

I don't think you need to worry - those drivers are back in the openSUSE kernel already. -- Per Jessen, Zürich (21.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/05/2020 13.01, Per Jessen wrote:

Carlos E. R. wrote:

...

...

Takashi Iwai  commented on the bug report -

...

CONFIG_HAMRADIO was set off already in Leap 15.0, so it's nothing new in Leap 15.1.

We've disabled drivers that appear almost unused at upgrading to the major version, and this was one of the results, I suppose.

But they are enabled in 15.1

Not on this brand new 15.1 install:

osforums:~ # grep Leap /etc/os-release NAME="openSUSE Leap" PRETTY_NAME="openSUSE Leap 15.1"

osforums:~ # zgrep HAMRADIO /proc/config.gz # CONFIG_HAMRADIO is not set

Must be new this week. the mkiss module was included in the 15.1 kernel I downloaded. kernel-default-5.3.18-lp152.10.4.x86_64.rpm CONTENTS.cpio/ucpio://lib/modules/5.3.18-lp152.10-default/kernel/drivers/net/hamradio mkiss.ko It is there. boot/config-5.3.18-lp152.10-default AX.25 network device drivers # CONFIG_MKISS=m CONFIG_6PACK=m CONFIG_BPQETHER=m CONFIG_BAYCOM_SER_FDX=m CONFIG_BAYCOM_SER_HDX=m CONFIG_BAYCOM_PAR=m CONFIG_YAM=m # end of AX.25 network device drivers -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 03/05/2020 14.44, Per Jessen wrote:

Carlos E. R. wrote:

...

On 03/05/2020 13.01, Per Jessen wrote:

...

Carlos E. R. wrote:

...

...

Takashi Iwai  commented on the bug report -

...

CONFIG_HAMRADIO was set off already in Leap 15.0, so it's nothing new in Leap 15.1.

We've disabled drivers that appear almost unused at upgrading to the major version, and this was one of the results, I suppose.

But they are enabled in 15.1

Oops. I meant 15.2.

...

...

Not on this brand new 15.1 install:

osforums:~ # grep Leap /etc/os-release NAME="openSUSE Leap" PRETTY_NAME="openSUSE Leap 15.1"

osforums:~ # zgrep HAMRADIO /proc/config.gz # CONFIG_HAMRADIO is not set

Must be new this week. the mkiss module was included in the 15.1 kernel I downloaded.

kernel-default-5.3.18-lp152.10.4.x86_64.rpm

Judging by the name, I believe that is a 15.2 kernel.

Correct. Typpo. Mental Oops. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 03/05/2020 12.53, Per Jessen wrote:

Marc Chamberlin wrote:

...

thanks.  I will wait until the dust settles and you can send me a set of instructions before I do anything further.

Hi Marc

what Andrei described in one of his posts yesterday is all you need. The module source is in the kernel-source package, you just need to compile ax25 and mkiss as socalled "out-of-tree" modules.

1) install kernel-source 2) switch to user mode 3) copy the source to your homedir, maybe to a subdir if you want:

cp -a /usr/src/linux/net/ax25 /home/marc/subdir/ cp -a /usr/src/linux/drivers/net/hamradio /home/marc/subdir/

your /home/marc/subdir now countains out-of-tree source code for ax25 and mkiss.

4) edit the Makefiles to make sure ax25.o and mkiss.o are included. (Andrei used 'sed' for this). Two lines to edit, one in each Makefile:

edit subdir/hamradio/Makefile: replace '$(CONFIG_MKISS)' with 'm'. edit subdir/ax25/Makefile: replace '$(CONFIG_AX25)' with 'm'.

Ah! So that's what he was doing. Thanks for translating ;-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 02/05/2020 17.34, Andrei Borzenkov wrote:

02.05.2020 13:34, Carlos E. R. пишет:

...

...

...

Telcontar:/usr/src/linux # grep -i mkiss .config CONFIG_MKISS=m Telcontar:/usr/src/linux #

You must not compile anything inside /usr/src/linux. README.SUSE makes it pretty clear.

I explained why I don't:

]> Notes: ]> ]> a) Purists will say that it is wrong to do this as root. Well, it happens that none of the above runs as user, because of the ownership of the files. Doing as user is more complicated, so I will not.

Can you explain how to do it?

I included full example how to do it.

Sorry, not clear to me the methodology.

...

(4) Compile the module(s) by changing into the module source directory and typing ``make -C $(your_build_dir) M=$(pwd)''.

Fails.

This explains how to compile external module, not module that is part of kernel tree.

Ok, then point me to the correct chapter in the readme.

...

(3) Compile the module(s) by changing into the module source directory and typing ``make -C /usr/src/linux-obj/$ARCH/$FLAVOR M=$(pwd)''. Substitute $ARCH and $FLAVOR with the architecture and flavor for which to build the module(s).

Seems to me that it is doing the operation directly on the /usr/src/linux directory as root.

Once again - this is for compiling external module that is not part of kernel tree.

Clear as mud to me that readme.

...

...

Of course you need to also build ax25 module that is required by mkiss, so

And you know this how?

By building mkiss and observing missing symbols?

It doesn't build at all here... I see no reports of missing symbols.

...

Maybe of course you happen to know. How am I supposed to know?

I have never heard about mkiss module until this thread either.

...

Anyway:

cer@Telcontar:/usr/src/linux> grep -i ax25 .config CONFIG_AX25=y CONFIG_AX25_DAMA_SLAVE=y cer@Telcontar:/usr/src/linux>

...

bor@leap15:/usr/src/linux> cp -a net/ax25 /tmp

Ah, you copy a part of the source directory to a temporary directory outside. Well, the readme fails to explain this.

Readme presumes basic understanding of kernel build system.

The Readme is presumed to explain every needed thing.

And once again - readme talks about building external module. "External module" is by definition module that is not part of kernel tree.

Obviously not clear to me.

...

I don't see why the original sources can not be used and we need a copy, the make process is not supposed to write to the source files.

Make process builds external module in place. It writes into directory where external module (source) is located.

...

...

bor@leap15:/usr/src/linux> sed -ie 's/\(obj-\)$(CONFIG_AX25)/\1m/' /tmp/ax25/Makefile

I have no idea what this is doing, sorry.

This is end result of configuring kernel to include AX25 as module. This config variable is undefined because this module is disabled in configuration, so in kernel tree Makefile does nothing. This sed invocation simply replaces variable by its value. If you do not like editing makefile, you could also simply set this variable when calling make, this is indeed more simple.

Sorry, but I can not read sed commands. But Per explained this morning what that line does: edit subdir/hamradio/Makefile: replace '$(CONFIG_MKISS)' with 'm'. edit subdir/ax25/Makefile: replace '$(CONFIG_AX25)' with 'm'. ;-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

On 01/05/2020 01.06, Marc Chamberlin wrote:

On 4/29/20 12:10 AM, Carlos E. R. wrote:

...

On 29/04/2020 06.13, Marc Chamberlin wrote:

Hi again Carlos, and all who have been providing me with their thoughts... Sorry for the delay in getting back, I got sidelined into hauling stuff to the dump yesterday, took all day, sigh...

Anywise, I have tried/used the nouveau driver in the past and ran into troubles with it so gave it up and went back to using the nVidia drivers which worked. So not sure I want to try nouveau again but will hold that thought in reserve for now and give it a go if all else fails.  I took a look at your plan B, and must say I found the instructions confusing, and seems to be aimed at folks with a deeper understanding of the OS and driver details than I have. Also it appears to be a bit dated, I found a couple of links that were either broken or pointing to a temp web page saying the instructions no longer exist. So I am kinda wanting to back away from that route also unless I have no other paths to follow. So that leaves your plan C and I am hoping you can give me an easy to follow guide! ;-)

Ok, the first step is to undo plan B, ie, the installation of the 15.2 kernel and 15.2 Nvidia drivers. Open a terminal, and "su -" to root. Do not forget the dash! Verification 1. You may get something like this: Telcontar:~ # rpm -qa | grep -i kernel kernel-default-4.12.14-lp151.28.44.1.x86_64 kernel-default-5.3.18-lp152.10.4.x86_64 texlive-l3kernel-doc-2017.133.svn44483-lp152.7.2.noarch kernel-devel-4.12.14-lp151.28.44.1.noarch kernel-macros-5.3.18-lp152.10.4.noarch texlive-l3kernel-2017.133.svn44483-lp152.7.2.noarch kernel-docs-5.3.18-lp152.10.4.noarch kernel-syms-4.12.14-lp151.28.44.1.x86_64 kernel-firmware-20200107-lp152.1.1.noarch kernel-syms-5.3.18-lp152.10.4.x86_64 nfs-kernel-server-2.1.1-lp152.8.2.x86_64 kernel-devel-5.3.18-lp152.10.4.noarch kernel-default-devel-5.3.18-lp152.10.4.x86_64 kernel-default-devel-4.12.14-lp151.28.44.1.x86_64 kernel-source-5.3.18-lp152.10.4.noarch kernel-source-4.12.14-lp151.28.44.1.noarch We have to uninstall all those -lp152 packages. Second verification: Telcontar:~ # rpm -qa | grep -i lp152 kernel-default-5.3.18-lp152.10.4.x86_64 texlive-l3kernel-doc-2017.133.svn44483-lp152.7.2.noarch kernel-macros-5.3.18-lp152.10.4.noarch texlive-l3kernel-2017.133.svn44483-lp152.7.2.noarch kernel-docs-5.3.18-lp152.10.4.noarch virtualbox-kmp-default-6.1.6_k5.3.18_lp152.10-lp152.1.1.x86_64 kernel-firmware-20200107-lp152.1.1.noarch kernel-syms-5.3.18-lp152.10.4.x86_64 nfs-kernel-server-2.1.1-lp152.8.2.x86_64 kernel-devel-5.3.18-lp152.10.4.noarch kernel-default-devel-5.3.18-lp152.10.4.x86_64 virtualbox-6.1.6-lp152.1.1.x86_64 kernel-source-5.3.18-lp152.10.4.noarch Telcontar:~ # Fire up yast, as root: yast2 --qt sw_single & - Select view by repository. - Select the kernel 15.2 repository you added. - Notice that the "switch packages link" is not there. - Hack 1.1: Select the System repository. - hack 1.2: Click on "Switch system packages to the version in this repository (15.2 kernel) - Now Click on "Cancel switching system packages to version in repository 15.2 kernel. This is what we wanted. In my case this fails (I am in your situation for another reason). So, in the package panel display version tab. Go package by package selecting the 15.1 version instead of the 15.2 version. You will have to do that for all the packages that were listed in the 2nd verification step above. Apply. Yast will say you need to reboot. Not yet. Exit yast and verify: Telcontar:~ # rpm -qa | grep -i lp152 [1]+ Done yast2 --qt sw_single Telcontar:~ # Telcontar:~ # rpm -qa | grep -i kernel kernel-macros-4.12.14-lp151.28.48.1.noarch kernel-default-4.12.14-lp151.28.44.1.x86_64 kernel-docs-4.12.14-lp151.28.48.1.noarch texlive-l3kernel-2017.133.svn44483-lp151.6.1.noarch kernel-devel-4.12.14-lp151.28.44.1.noarch texlive-l3kernel-doc-2017.133.svn44483-lp151.6.1.noarch kernel-syms-4.12.14-lp151.28.44.1.x86_64 nfs-kernel-server-2.1.1-lp151.7.3.1.x86_64 kernel-default-devel-4.12.14-lp151.28.44.1.x86_64 kernel-firmware-20200107-lp151.2.12.1.noarch kernel-source-4.12.14-lp151.28.44.1.noarch <=============== Telcontar:~ # Notice if you have that package or not, you need it. Fire up yast another time: yast2 --qt sw_single & Go to menu Configuration / Repositories Disable the "15.2 kernel" repository, and the "15.2 NVidia" repository that you added days ago. And apply. We are back on Yast "sw_single" module. On the search box" enter "kernel-source", and make sure it is installed (for 15.1). If not, tick it to install. Display now by repositories, and select the NVidia 15.1 repository. Then select the "version" tab. Make sure that you don't have any 15.2 package there. They should show in red, because on the previous step we disabled that repo. Apply. Reboot. You may want, before reboot, to apply updates: yast2 --qt online_update & after that, reboot. You should be back to kernel-default-4.12.14 running. I am doing that as well, so that will take some time to run. I will continue with plan C proper after my lunch and siesta. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)

Carlos E. R. wrote:

Bad news: Masaru Nomiya wrote that the kernel config file does not contains an entry for the mkiss module, and I confirm that.

Isn't that exactly what I wrote on 28/4 -

the 4.12.14 kernel in Leap 15.1 does not have the mkiss module.   It appears it was removed. Leap 15.1: per@test150:~> zgrep -i mkiss /proc/config.gz (nothing) I think it should have shown: CONFIG_MKISS is not set

You can still build the module out-of-tree, but it looks like that is what you have been working on anyway ? -- Per Jessen, Zürich (12.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Carlos E. R. wrote:

On 02/05/2020 10.40, Per Jessen wrote:

...

Carlos E. R. wrote:

...

Bad news: Masaru Nomiya wrote that the kernel config file does not contains an entry for the mkiss module, and I confirm that.

Isn't that exactly what I wrote on 28/4 -

...

the 4.12.14 kernel in Leap 15.1 does not have the mkiss module. It appears it was removed. Leap 15.1: per@test150:~> zgrep -i mkiss /proc/config.gz (nothing) I think it should have shown: CONFIG_MKISS is not set

You can still build the module out-of-tree, but it looks like that is what you have been working on anyway ?

No, this is not so.

The mkiss.c module is there.

And the configure option is also there, just disabled; it shows after enabling "Amateur Radio support".

Aha, the whole lot was disabled. Yep, I see: # zgrep -i HAM /proc/config.gz # CONFIG_HAMRADIO is not set -- Per Jessen, Zürich (14.3°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 03/05/2020 12.39, Carlos E. R. wrote:

On 01/05/2020 20.48, Carlos E. R. wrote:

...

On 01/05/2020 16.28, Carlos E. R. wrote:

...

On 01/05/2020 01.06, Marc Chamberlin wrote:

...

On 4/29/20 12:10 AM, Carlos E. R. wrote:

...

On 29/04/2020 06.13, Marc Chamberlin wrote:

...

...

(4) Compile the module(s) by changing into the module source directory and typing ``make -C $(your_build_dir) M=$(pwd)''.

Let's try.

cer@Telcontar:~/tmp/kernel> cd source/net/ax25/ cer@Telcontar:~/tmp/kernel/source/net/ax25> pwd /home/cer/tmp/kernel/source/net/ax25 cer@Telcontar:~/tmp/kernel/source/net/ax25>

Now, what is "my_build_dir"? "/home/cer/tmp/kernel/"? It fails:

cer@Telcontar:~/tmp/kernel/source/net/ax25> make -C /home/cer/tmp/kernel/ M=$(pwd) make: Entering directory '/home_aux/cer/tmp/kernel' arch/x86/Makefile:136: CONFIG_X86_X32 enabled but no binutils support mkdir: cannot create directory ‘/home/cer/tmp/kernel/source/net/ax25/.tmp_versions’: Permission denied

WARNING: Symbol version dump ./Module.symvers is missing; modules will have no dependencies and modversions.

LD /home/cer/tmp/kernel/source/net/ax25/built-in.o ar: /home/cer/tmp/kernel/source/net/ax25/built-in.o: Permission denied make[3]: *** [/usr/src/linux-4.12.14-lp151.28.48/scripts/Makefile.build:479: /home/cer/tmp/kernel/source/net/ax25/built-in.o] Error 1 make[2]: *** [/usr/src/linux-4.12.14-lp151.28.48/Makefile:1569: _module_/home/cer/tmp/kernel/source/net/ax25] Error 2 make[1]: *** [Makefile:152: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 make: Leaving directory '/home_aux/cer/tmp/kernel' cer@Telcontar:~/tmp/kernel/source/net/ax25>

Well, obviously permission denied. It is trying to write to "/usr/src/linux", not to my build directory... So what is the incantation, following the readme.suse method one, and a user, not root, directory and permissions?

STUCK.

More attempts. I created copy: cer@Telcontar:~/tmp/kernel> ls local ax25 hamradio cer@Telcontar:~/tmp/kernel> And tried to compile - no go. cer@Telcontar:~/tmp/kernel/local/ax25> cd .. cer@Telcontar:~/tmp/kernel/local> cd .. cer@Telcontar:~/tmp/kernel> make M=./local/ ax25/ hamradio/ cer@Telcontar:~/tmp/kernel> make M=./local/ax25/ WARNING: Symbol version dump ./Module.symvers is missing; modules will have no dependencies and modversions. /usr/src/linux-4.12.14-lp151.28.48/scripts/Makefile.build:44: /usr/src/linux-4.12.14-lp151.28.48/./local/ax25//Makefile: No such file or directory make[3]: *** No rule to make target '/usr/src/linux-4.12.14-lp151.28.48/./local/ax25//Makefile'. Stop. make[2]: *** [/usr/src/linux-4.12.14-lp151.28.48/Makefile:1569: _module_./local/ax25/] Error 2 make[1]: *** [Makefile:152: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 cer@Telcontar:~/tmp/kernel> make -C /usr/src/linux-obj/x86_64/default M=./local/ax25/ make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' arch/x86/Makefile:136: CONFIG_X86_X32 enabled but no binutils support mkdir: cannot create directory ‘./local’: Permission denied mkdir: cannot create directory ‘./local’: Permission denied /usr/src/linux-4.12.14-lp151.28.48/scripts/Makefile.build:44: /usr/src/linux-4.12.14-lp151.28.48/./local/ax25//Makefile: No such file or directory make[3]: *** No rule to make target '/usr/src/linux-4.12.14-lp151.28.48/./local/ax25//Makefile'. Stop. make[2]: *** [/usr/src/linux-4.12.14-lp151.28.48/Makefile:1569: _module_./local/ax25/] Error 2 make[1]: *** [Makefile:152: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' cer@Telcontar:~/tmp/kernel> l .local ls: cannot access '.local': No such file or directory cer@Telcontar:~/tmp/kernel> l ./local total 4 drwxr-xr-x 4 cer users 34 May 3 14:10 ./ drwxr-xr-x 9 cer users 235 May 3 14:09 ../ drwxr-xr-x 3 cer users 4096 May 3 14:14 ax25/ drwxr-xr-x 2 cer users 247 May 2 13:30 hamradio/ cer@Telcontar:~/tmp/kernel> mc cer@Telcontar:~/tmp/kernel> make -C /usr/src/linux-obj/x86_64/default M=local/ax25/ make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' arch/x86/Makefile:136: CONFIG_X86_X32 enabled but no binutils support mkdir: cannot create directory ‘local’: Permission denied mkdir: cannot create directory ‘local’: Permission denied /usr/src/linux-4.12.14-lp151.28.48/scripts/Makefile.build:44: /usr/src/linux-4.12.14-lp151.28.48/local/ax25//Makefile: No such file or directory make[3]: *** No rule to make target '/usr/src/linux-4.12.14-lp151.28.48/local/ax25//Makefile'. Stop. make[2]: *** [/usr/src/linux-4.12.14-lp151.28.48/Makefile:1569: _module_local/ax25/] Error 2 make[1]: *** [Makefile:152: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' cer@Telcontar:~/tmp/kernel> make -C /usr/src/linux-obj/x86_64/default M=local/ax25/ CONFIG_AX25=m make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' arch/x86/Makefile:136: CONFIG_X86_X32 enabled but no binutils support mkdir: cannot create directory ‘local’: Permission denied mkdir: cannot create directory ‘local’: Permission denied /usr/src/linux-4.12.14-lp151.28.48/scripts/Makefile.build:44: /usr/src/linux-4.12.14-lp151.28.48/local/ax25//Makefile: No such file or directory make[3]: *** No rule to make target '/usr/src/linux-4.12.14-lp151.28.48/local/ax25//Makefile'. Stop. make[2]: *** [/usr/src/linux-4.12.14-lp151.28.48/Makefile:1569: _module_local/ax25/] Error 2 make[1]: *** [Makefile:152: sub-make] Error 2 make: *** [Makefile:24: __sub-make] Error 2 make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48-obj/x86_64/default' cer@Telcontar:~/tmp/kernel> F** it. Build it all. cer@Telcontar:~/tmp/kernel> make -C /usr/src/linux O=$PWD modules make: Entering directory '/usr/src/linux-4.12.14-lp151.28.48' make[1]: Entering directory '/home_aux/cer/tmp/kernel' GEN ./Makefile scripts/kconfig/conf --silentoldconfig Kconfig CHK include/config/kernel.release ... This takes a loooong time to run. Uses a single CPU core, I don't know how to parallelize it. ... IHEX2FW firmware/keyspan_pda/keyspan_pda.fw IHEX2FW firmware/keyspan_pda/xircom_pgs.fw IHEX firmware/cpia2/stv0672_vp4.bin make[1]: Leaving directory '/home_aux/cer/tmp/kernel' make: Leaving directory '/usr/src/linux-4.12.14-lp151.28.48' cer@Telcontar:~/tmp/kernel> And the module is there! cer@Telcontar:~/tmp/kernel> l ~/tmp/kernel/drivers/net/hamradio total 1120 drwxr-xr-x 2 cer users 184 May 3 15:31 ./ drwxr-xr-x 27 cer users 8192 May 3 15:32 ../ -rw-r--r-- 1 cer users 263 May 3 15:31 .mkiss.ko.cmd -rw-r--r-- 1 cer users 39051 May 3 15:31 .mkiss.mod.o.cmd -rw-r--r-- 1 cer users 76444 May 3 15:02 .mkiss.o.cmd -rw-r--r-- 1 cer users 579688 May 3 15:31 mkiss.ko -rw-r--r-- 1 cer users 966 May 3 15:28 mkiss.mod.c -rw-r--r-- 1 cer users 74288 May 3 15:31 mkiss.mod.o -rw-r--r-- 1 cer users 340544 May 3 15:02 mkiss.o -rw-r--r-- 1 cer users 0 May 3 15:28 modules.builtin -rw-r--r-- 1 cer users 37 May 3 15:02 modules.order cer@Telcontar:~/tmp/kernel> try to load them (modprobe fails as it searchs another place): Telcontar:/home/cer/tmp/kernel # insmod ./net/ax25/ax25.ko Telcontar:/home/cer/tmp/kernel # insmod ./drivers/net/hamradio/mkiss.ko Telcontar:/home/cer/tmp/kernel # lsmod | grep "mkiss\|ax25" mkiss 20480 0 ax25 73728 1 mkiss Telcontar:/home/cer/tmp/kernel # Done. :-) -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)