Ubuntu Kernel compile and missing modules
-
Okay, so I basically did this:
- Took the Ubuntu kernel
- did a very minor reconfiguration by making the USB network driver for the RTL8152 built into the kernel (i.e. marked by
(*)in the menuconfig) instead of a module (i.e.(M)) and - then recompiled the whole thing
I did this in the hopes that this would solve a random hiccup in the book process - booting would often stop at
mounting /proc filesystem. It should be followed by a message stating that the network card was up and linked - but, as I said, it would often just hang at this point. The system would still be responsive (i.e. Ctrl-Alt-Del still worked and rebooted the client) but did not proceed.So I followed the "instructions" and then waited for the compilation to succeed - the server I'm doing this is a bit underpowered so it takes a while. Only to be greeted, after all that waiting, by this:
The instructions I was following are here: https://wiki.ubuntu.com/Kernel/BuildYourOwnKernel
Anyone here have an idea what I can do to fix this? I don't really want to try things at random because this error occured quite a bit into the compile process...
Also, what IS it with the FOSS people and their professional error messages? Seriously.
-
Comment #4 : Bug #899957 : Bugs : linux package : Ubuntu
Hi Tony, Because of the fact that you've disabled BTRFS the module check is failing during the build. The module check during the build is often used as a mechanism in our tooling to prevent accidental disablement of modules. However, since you have purposely disabled the module you need to...
The module check during the build is often used as a mechanism in our tooling to prevent accidental disablement of modules. However, since you have purposely disabled the module you need to ignore the module check.
-
The fact that it found a second missing module (
mii) might be a problem, though. No idea what it is...
-
@anotherusername nice find. I was going to suggest looking in that generic.modules file as it was obviously looking in there for modules.
-
@anotherusername Yes, but where exactly do I put
skipmodule=true?Remember, this is a long build and I don't relish the thought of some part not picking up this variable because I put it in the wrong place.
-
This post is deleted!
-
fakeroot debian/rules binary-generic binary-headers skipabi=true **skipmodule=true**
-
@sweaty_gammon Ah, thank you. Didn't see that part.
-
@sweaty_gammon said in Ubuntu Kernel compile and missing modules:
fakeroot debian/rules binary-generic binary-headers skipabi=true **skipmodule=true**I had a notion that somewhere someone had documented that the "pray for mercy" error message indicated that skipmodule may be in your future.
So I looked up, "skipmodule pray for mercy" and got 2 christers and a porn link. So I added "-jesus". And the christers went away AND SO DID THE PORN LINK.
I still have not found a satisfactory answer as to whether that error message is supposed to be known lore.
Appendix: Ah, I should have looked up "skipmodule "start begging for mercy"" although I strongly suspect that would not have helped much.
So that time, I ended up with two Bullet For My Valentine videos and a porn link. I added -bullet, and the videos went away AND SO DID THE PORN LINK.
Appendix: Well, actually it works fine if you actually quote it. https://www.gonwan.com/2010/05/18/updating-kernel-in-lucid-2/
-
This won't help you at all but...why did you do that?
While my exposure to linux is somewhat limited if you count the number of machines (<100 or so, that newfangled thing never got a foothold here (*)) but at least I can say that since the halcyone days of SuSe 7.x (and some faffing-around with Gentoo) I never ever recompiled a kernel myself, and never had to...
It ain't worth one's time, honestly.
-) next system-update will break something or other
-) RTL8152 / Realtek in a box that matters somehwat -> seriously? ("NE2000 with some glue" comes to mind, cannae remember where I read this)
... and so on ...Did you ever find out what exactly is causing the stall at "mounting ..."? (I'd blame systemd anyways ;-))
... 'cos recompiling the kernel just because it could fix this (can't see how but...) seems to be the nucular option to me and therefore should be avoided at all costs.-> you didn't -at least for me- provide enough info about your hardware to even try to dig into this but "Networking via USB" -> gah, I know you have your reasons but is -trying to- fix that really worth your time?
(*) curiously no one here has a problem running pfSense (BSD something) in a VM as a firewall-appliance, must be a GUI-vs-CLI thing...
PS: the SuSe 7.x-Box is still up-n-running, setup was initially on a1U SuperMicro P3/800 and now chuggin' along on an ESXI 6.5 with Xeon <CBA to look up>
-
@iKnowItsLame I did it because I had an SMP system with too much memory. It sucked and I have avoided ever doing it again. However, agreed, it doesn't help to tell someone not to do this. actually, the advice to blame systemd is probably helpful
-
@iKnowItsLame The problem is that it's a boot over PXE and thus essentially an ephemeral system - there are no direct error messages and I can't access logs yet. And if I reboot then it's all gone because RAM-only.
And I don't need to update that kernel as soon as it's working - it's something the clients use for PXE booting and then writing an image directly to the disc. If that boot process works reliably then there's no need to update at all.
And, yes, it is worth the time - because it will turn a process which takes several hours into something that takes 30 minutes. And which has to be repeated every month or so.
-
IIRC Because the kernel modules are loaded after the kernel extracts itself in memory. It been years since I've mucked around with a Linux kernel (the last time I compiled a kernel was Slackware 9) but it sounds like there is a race condition when detecting the usb network card. If it is already built into the main kernel it should already be loaded.
-
@Gribnit Systemd is always a good target
/"measure at least twice, cut once" is truly a good advice.
//ensuring a replacement 8x4 -in case one accidentally b0rked the clue-bat- is available is an even better one,
///"always just change one thing, do not try a shotgun-approach" is also good; would translate into "try to recompile <kernel> without changing anything & verify boot... just to ensure that the makefiles are equivalent to <kernel that is actually running> in this case would also be a good idea.But we shan't derail this thread with war stories...
@Rhywden do please provide more info about your kit, maybe the experience | google-fu of tdwtf unearths some gems.
"Ich habe dreimal was abgesägt und es ist immer noch zu kurz!"
-
@sweaty_gammon That's what I'm hoping as well - that it's some kind of timing problem which can be solved by integration into the kernel. I mean, it loads some of the time.
-
@iKnowItsLame What exactly do you want/need to know?
-
@Rhywden hah... "just... everything" (duh..)
-> Board, CPU, Memory, Peripherals, just everything.. (is this a VM running on <whatever>, BareMetal, Virtualbox | VMware Player...)
I mean, it loads some of the time.
... don't faff around with the kernel, just try to find the culprit and toggle the "tryHarder"-parameter or at least the "didn't work, plod on silently and let <user> deal with it"to True.Memory lane: one upon a time one decided to set <firewall rules> initially to "deny everything at boot" and missed the fact that <custom firewall-script> was started as last thing
-> what happened to starting ntpd (ntpdate foo.pool.ntp.org) immediately after eth0 came up is left as exercise to the reader.
/hint: since eth0 blocked everything and ntpdate hat no timeout ... ahem
