You knew it was coming: kernel build issues after kmod upgrade

usagi · 2012-07-04 11:00:23

Good morning,

After reading the BIG SCARY NOTE on the mailing list, I just *had* to upgrade my system and kernel. Following a -Syu, i built a kernel from the latest source (3.5.0-rc5+). Naturally, it built just fine. However, when i ran 'make modules_install', it installed the modules into /lib, which i was expecting. Moving on from *that* test, i ran:

 make INSTALL_MOD_PATH=/usr/ modules_install

(Note that the INSTALL_MOD_PATH is /usr, NOT /usr/lib/modules/. This is because of how the variable is used)

Anyway, that command installed the modules correctly, but shot this error when it tried to depmod (paraphrasing. the important bit here is the path):

 ERROR: Failed to open /usr//usr/lib/modules/98.99.3.5.0-rc5-custom+: no such file or directory

Interestingly enough, running a simple 'depmod 3.5.0-rc5-custom+' works fine, and all is well. the kernel runs fantasticly, right up to the nvidia module.

So, i submit to you:
What is the prepended "98.99." in the file structure about, and why is the kernel's built-in depmod prepending usr twice?

Thanks folks,
Aaron

EDIT: For clarity, the 98.99 isn't actually there in the file structure, just in the depmod command the kernel makefile runs following modules_install.

Last edited by usagi (2012-07-04 11:02:30)

falconindy · 2012-07-04 13:36:21

It's a hack workaround (which now fails for the wrong reason) in scripts/depmod.sh (in the kernel tree). In the PKGBUILDs for the kernels, we skip this, since the depmod call at that time serves us no purpose (modules are eventually compressed and then we manually invoke depmod).

In building my own kernel, it didn't seem worth my time to figure out why this broke.

edit: Looking back at it now, you still need to edit depmod.sh to avoid the hack failing, but its sufficient enough to just do:

$ sed -i '/^depmod_hack_needed/ s/true/false/' scripts/depmod.sh

...and then invoking 'make MOD_INSTALL_DIR=/usr modules_install' will work as expected with the depmod call at the end.

Sadly, I believe this hack was added in error and should have been fixed in userland.

Last edited by falconindy (2012-07-04 15:29:25)

ngoonee · 2012-07-05 01:37:08

usagi wrote:

Good morning,
After reading the BIG SCARY NOTE on the mailing list, I just *had* to upgrade my system and kernel.

Did you apply similar changes to your PKGBUILD as those listed in the ML note (there's a link to a patch to testing/linux)? Seems like that would workaround the issue falconindy is talking about.

LessWire · 2012-07-06 00:38:17

I'm just wondering why this change will be done - can anyone tell me the advantage ?

Kernel modules in "/usr/..."? This looks not like the right place for me and it complicates with some other scripts. "KISS" !??

karol · 2012-07-06 00:39:36

LessWire wrote:

I'm just wondering why this change will be done - can anyone tell me the advantage ?
Kernel modules in "/usr/..."? This looks not like the right place for me and it complicates with some other scripts. "KISS" !??

https://wiki.archlinux.org/index.php/De … ki:UsrMove

tomegun · 2012-07-06 00:48:07

LessWire wrote:

I'm just wondering why this change will be done - can anyone tell me the advantage ?
Kernel modules in "/usr/..."? This looks not like the right place for me and it complicates with some other scripts. "KISS" !??

We are merging all of /lib into /usr/lib, and eventually will be making /lib a symlink to /usr/lib for compatibility. In simple terms, this simplifies your system by only having one folder (/usr/lib) rather than two (/lib and /usr/lib). Originally, the split was made so that we could boot a basic system without /usr mounted. This reason no longer applies as we mount /usr from the initramfs.

LessWire · 2012-07-06 00:53:02

Thanks carol, i read this. But in this (and some other) case it doesn't make sense in my eyes.
It starts to destroy the "kiss" principle i liked so much so far.

Just my opinion.

LessWire · 2012-07-06 00:56:20

@tomegun: thanks for the statement, that's a reason and hopefully a solution!

compatibility is very important.

Last edited by LessWire (2012-07-06 00:57:44)

karol · 2012-07-06 01:00:07

As Dave Reisner (falconindy) said, it's a bit late for such opinions to matter really: http://mailman.archlinux.org/pipermail/ … 23182.html
The plan wasn't secret and suggestions how to do things differently should have been presented earlier.

You're obviously entitled to your opinion, but like with udev & systemd, things are going to be done this way whether you like it or not.

LessWire · 2012-07-06 01:14:10

You are right, everybody must find the distribution which works best for his needs.

For me it is since a few years Archlinux (after many years with Debian before) and i see no reason for a change till now. Most important for me is the enduration of the "kiss" principle.

So let's look for new things to come.

Allan · 2012-07-06 01:21:57

Having just /usr/lib rather than both /lib and /usr/lib seems KISS to me...

graysky · 2012-07-06 01:23:36

Aren't all major distros going this way at some point? Is this a TGN?

ngoonee · 2012-07-06 01:35:54

graysky wrote:

Aren't all major distros going this way at some point? Is this a TGN?

Eventually yes, but its always good to leave one thread to collect all the searchers who will be searching for information about this. Especially one with a link to the relevant wiki and comments from multiple developers.

Don't know about major distros going this way, but I don't think that's much of a consideration, this isn't like systemd.

tomegun · 2012-07-06 01:37:53

graysky wrote:

Aren't all major distros going this way at some point?

Some have. Some will. Don't know if all will.

Is this a TGN?

Probably, but I agree with ngoonee: Let it go nowhere for a while longer ;-)

LessWire · 2012-07-06 01:39:30

Allan wrote:

Having just /usr/lib rather than both /lib and /usr/lib seems KISS to me...

Yes Allan, but i think only if the "make" procedure of the original kernel would follow this as default and it doesn't.

It's not worth and probably too late for a long discussion, i simply created a symlink and moved my modules directory to "/usr/lib" although it's not a clean solution.

sacamano_m82 · 2012-07-07 11:02:04

This breaks "make tar-pkg" in the kernel. I get the same error:

ERROR: could not open directory /home/sujith/dev/wireless-testing/build/tar-install/usr/lib/modules/99.98.3.5.0-rc5-wl: No such file or directory

I understand the /usr move, so is there any clean way to handle this breakage ?

tomegun · 2012-07-07 11:09:25

@sacamano_m82: I just do "make && make install && make modules_install" as normal, followed by "mv /lib/modules/* /usr/lib/modules/". Alternatively, just wait for /lib to become a symlink to /usr/lib, and then it won't matter.

bangkok_manouel · 2012-07-07 11:21:23

edit2/ ah no, that should work

make INSTALL_MOD_PATH=/usr modules_install

Last edited by bangkok_manouel (2012-07-07 11:25:06)

sacamano_m82 · 2012-07-07 11:35:43

tomegun wrote:

@sacamano_m82: I just do "make && make install && make modules_install" as normal, followed by "mv /lib/modules/* /usr/lib/modules/". Alternatively, just wait for /lib to become a symlink to /usr/lib, and then it won't matter.

Well, I build a tarball using the kernel's "tar-pkg" option and push it to a bunch of test machines. This allows me to keep my development tree on a single machine and send incremental .ko files to said test machines later. I use the wireless-testing tree, btw (mostly ath9k development). Right now, I am stuck in a situation where years of kernel building on a daily basis has come to a halt.

falconindy · 2012-07-07 12:45:41

sacamano_m82 wrote:

This breaks "make tar-pkg" in the kernel. I get the same error:
ERROR: could not open directory /home/sujith/dev/wireless-testing/build/tar-install/usr/lib/modules/99.98.3.5.0-rc5-wl: No such file or directory
I understand the /usr move, so is there any clean way to handle this breakage ?

Sure, see my fix in the first reply to the OP.

sacamano_m82 · 2012-07-07 13:11:03

falconindy wrote:

Sure, see my fix in the first reply to the OP.

That fix works only when "modules_install" is invoked from the root Makefile. The script 'buildtar' is broken - http://tinyurl.com/bpbkrxx
(/lib is assumed to be default installation path). And this script is part of the kernel ! I am sure that more scripts/build-setups out there in the wild would break too..

Fixing 'buildtar' doesn't solve the issue, though. scripts/depmod.sh appends an extra "usr" to INSTALL_MOD_PATH (when invoked using make tar-pkg).
A couple of hacks later, I can finally get linux-foo.tar

But, I am using the testing repo after all, so the onus is on me to workaround this issue, I guess, until /lib becomes a tiny footnote.

falconindy · 2012-07-07 13:42:02

sacamano_m82 wrote:

falconindy wrote:
Sure, see my fix in the first reply to the OP.
That fix works only when "modules_install" is invoked from the root Makefile. The script 'buildtar' is broken - http://tinyurl.com/bpbkrxx

No... the error is being generated from the same depmod.sh script which is called in the temporary root that is created by Kbuild when you call tar-pkg. The same fix of removing the hack in this script will fix your tarball creation.

Last edited by falconindy (2012-07-07 13:42:21)

sacamano_m82 · 2012-07-07 14:07:31

falconindy wrote:

No... the error is being generated from the same depmod.sh script which is called in the temporary root that is created by Kbuild when you call tar-pkg. The same fix of removing the hack in this script will fix your tarball creation.

The sequence goes something like this:

In a clean, vanilla tree, make tar-pkg borks with this message (the same one the OP reported):

ERROR: could not open directory /home/sujith/dev/wireless-testing/build/tar-install/usr/usr/lib/modules/99.98.3.5.0-rc5-wl: No such file or directory

After adding the fix you posted:

ERROR: could not open directory /home/sujith/dev/wireless-testing/build/tar-install/usr/lib/modules/3.5.0-rc5-wl: No such file or directory

After fixing the 'buildtar' script to use '/usr' as the install-prefix (note the extra 'usr'):

ERROR: could not open directory /home/sujith/dev/wireless-testing/build/tar-install/usr/usr/lib/modules/3.5.0-rc5-wl: No such file or directory

After a dirty hack using dirname to strip the extra 'usr' (at this point, I just wanted to move on :-) ):

Tarball successfully created in /home/sujith/dev/wireless-testing/build/linux-3.5.0-rc5-wl.tar

Hope that clears things a bit !

falconindy · 2012-07-07 14:22:21

Ah the buildtar script is indeed separately broken.

sacamano_m82 · 2012-07-14 06:18:21

Just a quick update: I updated all of my machines (about 8 systems, using the testing repo) and didn't encounter any nasty glitch. The /lib migration went surprisingly smooth, I didn't end up shooting myself in the foot or anything. The ARCH developers have done a good job, indeed.

Arch Linux

#1 2012-07-04 11:00:23

You knew it was coming: kernel build issues after kmod upgrade

#2 2012-07-04 13:36:21

Re: You knew it was coming: kernel build issues after kmod upgrade

#3 2012-07-05 01:37:08

Re: You knew it was coming: kernel build issues after kmod upgrade

#4 2012-07-06 00:38:17

Re: You knew it was coming: kernel build issues after kmod upgrade

#5 2012-07-06 00:39:36

Re: You knew it was coming: kernel build issues after kmod upgrade

#6 2012-07-06 00:48:07

Re: You knew it was coming: kernel build issues after kmod upgrade

#7 2012-07-06 00:53:02

Re: You knew it was coming: kernel build issues after kmod upgrade

#8 2012-07-06 00:56:20

Re: You knew it was coming: kernel build issues after kmod upgrade

#9 2012-07-06 01:00:07

Re: You knew it was coming: kernel build issues after kmod upgrade

#10 2012-07-06 01:14:10

Re: You knew it was coming: kernel build issues after kmod upgrade

#11 2012-07-06 01:21:57

Re: You knew it was coming: kernel build issues after kmod upgrade

#12 2012-07-06 01:23:36

Re: You knew it was coming: kernel build issues after kmod upgrade

#13 2012-07-06 01:35:54

Re: You knew it was coming: kernel build issues after kmod upgrade

#14 2012-07-06 01:37:53

Re: You knew it was coming: kernel build issues after kmod upgrade

#15 2012-07-06 01:39:30

Re: You knew it was coming: kernel build issues after kmod upgrade

#16 2012-07-07 11:02:04

Re: You knew it was coming: kernel build issues after kmod upgrade

#17 2012-07-07 11:09:25

Re: You knew it was coming: kernel build issues after kmod upgrade

#18 2012-07-07 11:21:23

Re: You knew it was coming: kernel build issues after kmod upgrade

#19 2012-07-07 11:35:43

Re: You knew it was coming: kernel build issues after kmod upgrade

#20 2012-07-07 12:45:41

Re: You knew it was coming: kernel build issues after kmod upgrade

#21 2012-07-07 13:11:03

Re: You knew it was coming: kernel build issues after kmod upgrade

#22 2012-07-07 13:42:02

Re: You knew it was coming: kernel build issues after kmod upgrade

#23 2012-07-07 14:07:31

Re: You knew it was coming: kernel build issues after kmod upgrade

#24 2012-07-07 14:22:21

Re: You knew it was coming: kernel build issues after kmod upgrade

#25 2012-07-14 06:18:21

Re: You knew it was coming: kernel build issues after kmod upgrade

Board footer