Custom kernel a pain

merc64 · 2007-01-18 00:29:36

I compiled a custom kernel in abs a while ago, loosely following the doc in the wiki, but there were a few things I didn't like/couldn't figure out.

The PKGBUILD from dibblethewrecker interactively brings up the config dialog in build(). IIRC, it also resets to a default config every time. I much prefer the way Debian packages the kernel, where you configure it first and then make the package (and no, I don't like much else about Debian).

Another thing is I never got mkinitcpio to create a unique filename for the image. The default kernel and my custom kernel have to share the same image.

I'm pretty used to recompiling kernels by now from several distros, but I found the Arch abs method pretty intimidating (granted, I don't really understand mkinitrd/mkinitcpio yet).

With ABS in general, it's difficult to sync the changes in the main abs tree with custom packages. When I update abs, I can't tell what changed in the default packages so I can update my local abs packages.

Are there any custom kernel resources I might not have seen that address those first two issues?

noriko · 2007-01-18 01:03:37

umm, why not modify the pkgbuild ...
there is a line in there that brings up the config...

merc64 · 2007-01-18 02:04:09

noriko wrote:

umm, why not modify the pkgbuild ...
there is a line in there that brings up the config...

True enough. I just noticed that line was right up near the top, but I think there's more to it than just commenting out that line. For instance, the sources need to be downloaded before you can get to menuconfig. IDK, I was mostly asking for information on that one, and wondering if anyone else had dealt with the same problems.

yankees26 · 2007-01-18 02:43:14

makepkg downloads the sources for you, hence the sources line in the PKGBUILD.

noriko · 2007-01-18 07:53:34

make ur config and save it say @ ~/konfig

then in the pkgbld, copy it into place ..
i can't remmeber wher it goes, it'e been a while ...

but this should help..

copy ~/konfig [kenel_config]

_________________________________________
let's know how it goes, ....

tomk · 2007-01-18 14:13:30

merc64 wrote:

The PKGBUILD from dibblethewrecker interactively brings up the config dialog in build()

Only if you set it up that way. If you have a kernel config that you want to use unchanged, uncomment the line

yes "" | make config

instead of make menuconfig/xconfig.

merc64 wrote:

IIRC, it also resets to a default config every time.

It resets to the config it originally started with, and it also copies the modified config back to the build directory:

  # save the updated config to build with today's date
  cp ./.config $startdir/config-$(date +%b%d-%Hh)

Note the helpful comment.

merc64 wrote:

I much prefer the way Debian packages the kernel, where you configure it first and then make the package

See above - and may I suggest that you prefer it simply because you're more familiar with it?

merc64 wrote:

Another thing is I never got mkinitcpio to create a unique filename for the image. The default kernel and my custom kernel have to share the same image.

Bad idea. The initcpio image uses modules from the kernel with which it should be used. Have a look at mkinitcpio -h and the mkinitcpio wiki page for more details.

Two more general points - it's very possible you can do without mkinitcpio. If you don't have any special boot-time requirements e.g. encryption, just build what you need into your kernel. And finally, although the ABS way is recommended, you are of course free to use any kernel building method you like.

tomk · 2007-01-18 14:15:39

One more thing, after re-reading your chosen title for this thread - if your custom kernel is "a pain", why not use one of the Arch kernel packages? They're very good, you know.

Acid7711 · 2007-01-18 19:56:02

That's still my biggest gripe about Arch honestly. While stupid, I miss kernel compilation as it was in Gentoo, without all the stupid images. Go into /usr/src/linux make it, copy it over and be done with it. Simple as that. I think makepkg custom kernel is a pita and needless.

My only problem with doing it the way I'm used to is once I did that on Arch, compiled/installed the nvidia drivers by hand (as you would do with Gentoo), and one day I wanted to revert back to arch kernel so I didn't have to patch for the CK set by hand, and low and behold I had a mess of nvidia-drivers that wouldn't run X and wouldn't delete and install others.

Long story short, I ended up with a reinstall because no one could help. I'd like to see some kind of changes in for that, but it's really a pita. Quite honestly, it could easiiiiiiiiiiiiiiily be solved by having a compiled version of Nvidia in the main repos. That would solve all the problems of having to remove them if ever wanting to revert, etc.... Maybe I'm off my tree here, i dunknow.

I don't want to use the stock kernel images that Arch supplies. No reason really other than I enjoy doing my own. But I fear my life for a reinstall from what happened last time with the ass-mess of nvidia drivers. :?

tomk · 2007-01-18 20:50:24

Acid7711 wrote:

Go into /usr/src/linux make it, copy it over and be done with it. Simple as that. I think makepkg custom kernel is a pita and needless.

And as I said above, you can handle your kernel builds any way you want - it's your system. If you're not bothered about keeping your system under pacman's control, the way you have summarised above is fine.

Acid7711 wrote:

low and behold I had a mess of nvidia-drivers that wouldn't run X and wouldn't delete and install others.

I'm not exactly sure what you mean here, and in particular I don't know why you would expect manually installed drivers to "delete and install others". If you tried to install the Arch nvidia packages over your previous manually-installed version, then pacman would correctly complain about file conflicts. The solution to this is to remove the files that pacman complains about - reinstalling your system is not necessary.

Acid7711 wrote:

I'd like to see some kind of changes in for that, but it's really a pita. Quite honestly, it could easiiiiiiiiiiiiiiily be solved by having a compiled version of Nvidia in the main repos.

Please post your suggestions as feature requests in the bugtracker, bearing in mind that pacman will not at any stage be modified to handle conflicts with files that are not under its control.

Acid7711 wrote:

I fear my life for a reinstall from what happened last time with the ass-mess of nvidia drivers. :?

As mentioned, in the absence of actual details, I'm assuming you ran into difficulty because you tried to replace a manual nvidia install with the Arch nvidia package. Stick to one or the other, and you should be fine.

bigbob73 · 2007-01-18 21:46:12

it is quite easy to compile your kernel the old fashioned way. you can also do the nvidia driver the manual way. Works great here.

P.S. if you have a legacy card, use a 96xx series driver.

Dusty · 2007-01-18 21:50:36

Actually, Judd originally designed Arch such that the 'traditional' kernel compile method should be used. The ABS package was developed iteratively, by myself, lilsirecho, and (mostly) dtw nee dibblethewrecker to make kernel compiling more automated and therefore easier. If you think the traditional method is easier, its certainly not considered un-kiss or unarchlike to use that method instead.

Dusty

merc64 · 2007-01-19 03:47:30

yankees26 wrote:

makepkg downloads the sources for you, hence the sources line in the PKGBUILD.

Yeah, what I meant was that I wasn't sure if you could easily configure the package in advance with ABS because there wouldn't be the Makefile there to start menuconfig until AFTER makepkg downloaded and uncompressed the sources. You could manually edit .config or copy it from /usr/src, but the first is difficult and the second seems clumsy.

tomk wrote:

merc64 wrote:
I much prefer the way Debian packages the kernel, where you configure it first and then make the package
See above - and may I suggest that you prefer it simply because you're more familiar with it?

Actually, I've only recompiled in Debian twice, and I was pretty uncomfortable with it at the time, but I had to admit when it was done that it worked pretty well... I mostly use Gentoo (the system I'm on now). I have to boot up my laptop whenever I want to make sure my facts are straight here... I do like Arch, but I still miss the USE flags. I don't like installing X on that laptop because it's tiny, but I have to build practically everything in ABS to disable X and enable framebuffer.

tomk wrote:

merc64 wrote:
Another thing is I never got mkinitcpio to create a unique filename for the image. The default kernel and my custom kernel have to share the same image.
Bad idea. The initcpio image uses modules from the kernel with which it should be used.

I know it's a bad idea, that's why it irks me . It still works for now, but I'm trying to figure out how to make them stop clobbering each other. I guess instead of "have to share the same image" I should say "I can't make them stop sharing the same image".

tomk wrote:

And finally, although the ABS way is recommended, you are of course free to use any kernel building method you like.

I certainly recognize that. People use Arch for the freedom/control. My only issues were (a) the PKGBUILD provided was a little complex and I personally found it difficult to tweak, so I was looking for advice, and (b) compiling a custom kernel is a common task (I think I saw Judd recommend everyone do it, that the default ones were just to get things running) and I thought maybe some more details in the Wiki might help others. Just to throw out the suggestion.

Dusty · 2007-01-19 04:31:57

merc64 wrote:

(I think I saw Judd recommend everyone do it, that the default ones were just to get things running)

If that's true, I think it must be outdated advice. I'm pretty sure with all the work Phrakture and tpowa have done recently, the stock kernel is meant for general use. They use the module autoloading and other tools to make sure only the stuff you need is running.

Dusty

merc64 · 2007-01-19 06:11:29

Hmm... that is interesting, although the default wouldn't work for me because it didn't have the APM support I needed. I'm sure one of the other kernels in pacman would have worked for me, but I do like having that control and knowing exactly what's enabled in the kernel.

Acid7711 · 2007-01-19 08:00:26

tomk wrote:

Acid7711 wrote:
low and behold I had a mess of nvidia-drivers that wouldn't run X and wouldn't delete and install others.
I'm not exactly sure what you mean here, and in particular I don't know why you would expect manually installed drivers to "delete and install others". If you tried to install the Arch nvidia packages over your previous manually-installed version, then pacman would correctly complain about file conflicts. The solution to this is to remove the files that pacman complains about - reinstalling your system is not necessary.

I didn't expect it to do that. Maybe my wording was confusing, it was some time ago. I'm not exactly 100% sure as I said it was some time ago and I don't remember, but yeah, I couldn't get the manually installed nvidia removed properly and the arch nvidia to install properly. Everything became one huge freaking mess reallllllllllly fast. It was ugly. I do believe I removed the files and something happened. I don't know, long time ago.

tomk wrote:

Acid7711 wrote:
I'd like to see some kind of changes in for that, but it's really a pita. Quite honestly, it could easiiiiiiiiiiiiiiily be solved by having a compiled version of Nvidia in the main repos.
Please post your suggestions as feature requests in the bugtracker, bearing in mind that pacman will not at any stage be modified to handle conflicts with files that are not under its control.

And that's not what I'm asking. It wouldn't have to replace anything. Having a version of nvidia to be compiled in the main distro to use and match a custom kernal's installed headers would solve a looooot of these issues while still keeping pacman 'in the loop'. However, I'm aware pacman main repos aren't for compiling. That's what AUR is for eh?

Another solution for the problem would be having any kernel that comes packages with Arch install the needed headers and such (If I'm off on the terminology the nvidia drivers use I apologize) and have the nvidia drivers a generic that compile directly from those required. Not like compiling nvidia drivers takes more than 30 seconds. Again, I'm aware it's against the whole compiling deal, use makepkg yadayada...... But that way, custom or stock arch kernels would all have nvidia utilize them appropriately each and every time. There'd be no 'guesswork' as there is when I screwed my system over. There also would be no need for other patchset specific nvidia packages ie: beyond,ck, etc....

tomk wrote:

Acid7711 wrote:
I fear my life for a reinstall from what happened last time with the ass-mess of nvidia drivers. :?
As mentioned, in the absence of actual details, I'm assuming you ran into difficulty because you tried to replace a manual nvidia install with the Arch nvidia package. Stick to one or the other, and you should be fine.

Yes, I tried to revert. I didn't think it would or should be that hard to revert back to an arch based kernel and nvidia install, but evidently problems arose and not a single person was able to offer advice at the time. Was a huge mess. Like I said, I wanted to stick with the custom kernel/nvidia install, however at the time I wanted the beyond/ck/some other patchset for some reason. I don't remember why. *shrugs*

Arch Linux

#1 2007-01-18 00:29:36

Custom kernel a pain

#2 2007-01-18 01:03:37

Re: Custom kernel a pain

#3 2007-01-18 02:04:09

Re: Custom kernel a pain

#4 2007-01-18 02:43:14

Re: Custom kernel a pain

#5 2007-01-18 07:53:34

Re: Custom kernel a pain

#6 2007-01-18 14:13:30

Re: Custom kernel a pain

#7 2007-01-18 14:15:39

Re: Custom kernel a pain

#8 2007-01-18 19:56:02

Re: Custom kernel a pain

#9 2007-01-18 20:50:24

Re: Custom kernel a pain

#10 2007-01-18 21:46:12

Re: Custom kernel a pain

#11 2007-01-18 21:50:36

Re: Custom kernel a pain

#12 2007-01-19 03:47:30

Re: Custom kernel a pain

#13 2007-01-19 04:31:57

Re: Custom kernel a pain

#14 2007-01-19 06:11:29

Re: Custom kernel a pain

#15 2007-01-19 08:00:26

Re: Custom kernel a pain

Board footer