| 1 |
Bill Longman wrote: |
| 2 |
> On 06/21/2010 12:01 PM, Dale wrote: |
| 3 |
> |
| 4 |
>> Alex Schuster wrote: |
| 5 |
>> |
| 6 |
>>> Dale writes: |
| 7 |
>>> |
| 8 |
>>> |
| 9 |
>>> |
| 10 |
>>>> I don't use genkernel anymore. I just roll my own. That way, I know |
| 11 |
>>>> what is in there and what is not. Then if something doesn't work, I |
| 12 |
>>>> know if it is the kernel or something else. With genkernel, you won't |
| 13 |
>>>> have a clue what it is since you don't know much if anything about the |
| 14 |
>>>> kernel and how it is configured. |
| 15 |
>>>> |
| 16 |
>>>> |
| 17 |
>>> That's not necessarily true. When I create a new kernel, I copy |
| 18 |
>>> /usr/src/linux/.config into the new kernel directory, make oldconfig and |
| 19 |
>>> menuconfig just as I like my kernel to be, and recreate the linux symlink |
| 20 |
>>> to the new kernel directory. Then I do a genkernel --install --lvm --luks |
| 21 |
>>> all&& emerge -a @module-rebuild, and am done. |
| 22 |
>>> I never noticed genkernel changing anything in my configuration, .config, |
| 23 |
>>> /proc/config.gz and the stuff in /etc/kernels/ are identical. Until not |
| 24 |
>>> long ago, I did not even know that genkernel was intended to create a |
| 25 |
>>> working kernel from scratch. |
| 26 |
>>> |
| 27 |
>>> Wonko |
| 28 |
>>> |
| 29 |
>>> |
| 30 |
>>> |
| 31 |
>> I always do mine this way. I copy the .config from the old kernel to |
| 32 |
>> the new kernel, run make oldconfig then afterwards make all&& make |
| 33 |
>> modules_install and then copy the kernel to /boot with my own numbering |
| 34 |
>> system. That way I know which version and series the kernel is. After |
| 35 |
>> that, edit grub with the new kernel and I'm done. I have only had that |
| 36 |
>> fail once in the past six years or so and the kernel made some serious |
| 37 |
>> changes and I had to start from scratch that one time. They moved |
| 38 |
>> things around and oldconfig couldn't reorganize things on the new kernel. |
| 39 |
>> |
| 40 |
>> Point being, genkernal causes issues for people and they don't know how |
| 41 |
>> to fix it because they expect genkernel to do everything. Problem with |
| 42 |
>> that is that usually when someone has a kernel problem, they use |
| 43 |
>> genkernel. If they do their own, it just works. Now someone new to |
| 44 |
>> building a kernel may need some help but apparently genkernel needs some |
| 45 |
>> help anyway. May as well learn how to roll your own. This is Gentoo |
| 46 |
>> after all. |
| 47 |
>> |
| 48 |
> The only thing that genkernel would add is your initrd. The kernel is |
| 49 |
> exactly the same, whether you compile it with "make" or through |
| 50 |
> "genkernel". Do a test and you'll see. (I'm assuming we're both talking |
| 51 |
> about gentoo-sources, not vanilla-sources. Either way, they'd be the |
| 52 |
> same.) Some might be confused about what happens in the steps if they |
| 53 |
> haven't been down the "kernel compilation trail" more than once or |
| 54 |
> twice, but for folks who just want to compile their kernel and plop it |
| 55 |
> into place, along with a hands-off initrd, it's rather handy. |
| 56 |
> |
| 57 |
> |
| 58 |
|
| 59 |
But only if it works. When I compile my kernel, I KNOW for sure what is |
| 60 |
in there. When genkernel does one, especially on a new install, I have |
| 61 |
no idea what is in it or what is not. If something goes wrong, I don't |
| 62 |
know where to start. Is it a kernel problem or is it something else? |
| 63 |
Who knows. Then you have to go back and start from the bottom, usually |
| 64 |
the kernel, and work your way back up to find out what is broken. |
| 65 |
|
| 66 |
Genkernel may work for you but that doesn't mean it does for everyone |
| 67 |
else. Should I mention hal here? When someone comes for help, your |
| 68 |
looking for the failure not the successes. If it was sucessful, they |
| 69 |
wouldn't need help. |
| 70 |
|
| 71 |
Dale |
| 72 |
|
| 73 |
:-) :-) |
Archives