Stefan Seyfried wrote:
From what I seem to remember, the rpm targets are not really working or supported on the openSUSE kernel (or even on openSUSE with an upstream kernel source? I don't know).
Thanks very much for confirming this. When something goes wrong the hardest thing is to decide between going down the "it's broken" vs the "I'm doing it wrong" path to try to find a fix.
But, at least for me, they are also not really necessary since the kernel relatively cleanly installs in /boot and /lib/modules/<version> subdirectory and can easily be removed manually. I'll write down what I'm doing (from memory, so it might be slightly off...) to build a test kernel for my machine cd /my/sources/linux mkdir out zcat /proc/config.gz > out/.config
I've found that /boot/config-<current_version> (always?) matches /proc/config.gz (after `gunzip`'ing), but yes, that should be the same as what I did.
make oldconfig O=out make menuconfig O=out # or edit out/.config I usually change CONFIG_LOCALVERSION="-seife" so that the custom kernel is easily identified. I also usually do unset CONFIG_DEBUG_INFO, as it saves a huge amount of disk space make -j 8 O=out sudo make install O=out sudo make modules_install O=out
Thanks, I'll try that. What wasn't clear to me were things like if `make install` did the compression of vmlinux (which plain `make` successfully created for me) to vmlinuz, and whether I'd have to run `dracut` or something else manually to create the /boot/initrd-<version> file, etc. I'd hope the Makefile would do it for me, but after my experiences with the "binrpm-pkg" target I didn't have a lot of confidence in it.
I like to have the built objects all in a extra directory for easy cleanup, thus the "O=out"
A nice trick, although I think `make clean` has been working for me without it. Side note: This is the first time I've tried to compile the kernel from source since I was on Slackware almost 30 years ago (before there were kernel modules, if I remember correctly). What I *do* remember from back then was the humorously-named `make mrproper` target, and I was nostalgically amused that it's still in the Makefile.
Before rebooting into the new kernel, I often use "sudo grub2-emu" to check if it really is properly inserted into the grub menu, but that has always worked well for me.
I wondered the same thing (grub configuration) but from what I saw looking around in the the /etc/grub.d/* files is that on openSUSE they dynamically create the menus at boot time from the kernels/initrds in the /boot directory. Very nice, and it seemed to work during my experiments zypper-installing pre-built kernels from RPMs (there was no change to the /etc/grub.d/* files but the new kernel(s) appeared in the boot menus anyway). Scouring the web for information I found instructions for other distros which explicitly required manual steps to reconfigure grub each time. It's one more example of why I think openSUSE gets things right (like the graphical installer which supports all the custom configuration capabilities listed in the Arch and Gentoo manuals, yet lets a naive user do a default install with a few mouse clicks instead of typing dozens of error-prone commands and inputs in a shell terminal).
I think you need to have the "kernel-install-tools" package installed nowadays for the "make install" to work, but I have not had to build a kernel since this was changed :-)
Thanks for the tip. I'll check, and maybe install it anyway just in case. ;)
Best regards, and good luck.
Thanks again. Hopefully I won't need too much more of it.
the kernel@lists.opensuse.org mailing list would have connected you more directly with people that can give a definitive answer to these questions :-)
If I run out of luck again I'll try "wearing out my welcome" over there next time. ;)
I think building kernels is not that hard (and it shouldn't be), so maybe one solution to the "make <something-rpm>" not working in opensuse would be to actually patch it out and replace it with some explanatory message...
I agree ("shouldn't be") and about removing (or a least documenting) non-functioning options. Like I said above, it would save the wasted time trying to find a user-error explanation for something that isn't going to work in the first place.