[gobolinux-users] How to update Linux Kernel?

[Michael Homer]

On 6/12/07, rubisher <rubisher at scarlet.be> wrote:
> Michael,
>
> Michael Homer wrote:
> > On 6/10/07, rubisher <rubisher at scarlet.be> wrote:
> [snip]
>
> >> Ok just small 'Conflict' warnings:
> >>
> >> ~]InstallPackage Scripts
> > <snip>
> >> SymlinkProgram: Conflict: /System/Links/Libraries/python2.3/site-packages/GetAvailable.pyc
> >> SymlinkProgram: Conflict: /System/Links/Libraries/python2.3/site-packages/PythonUtils.pyc
> >> SymlinkProgram: Conflict: /System/Links/Libraries/python2.3/site-packages/GuessProgramCase.pyc
> >> SymlinkProgram: Conflict: /System/Links/Libraries/python2.3/site-packages/FindPackage.pyc
> >> SymlinkProgram: Conflict: /System/Links/Libraries/python2.3/site-packages/GuessLatest.pyc
> > <snip>
> >> So I still have to learn: why conflict and how to fix?
> > Use `SymlinkProgram -c overwrite Scripts` to wipe the conflicts. That
>
> Ok done.
> I used 'Freshen -U OpenSSH' and seems to work kindly: Glibc and OpenSSL needed upgrade was managed smoothly ;-)
>
> > means that another program has (or has had) files with the same name,
>
> that's what I understood too ;-)
>
> > and you have to choose which to use (in this case, I think some parts
> > have been moved from Compile into Scripts, so you can just overwrite
> > them).
> That's what I have to learn: how to find back which package already supplied it. I will check that later.
`ls -l /System/Links/Libraries/python2.3/site-packages/GetAvailable.pyc`.
Convenient, isn't it? Or `readlink -f`, which is slightly more
reliable, but it doesn't make a difference in this case. (Explanation:
if site-packages (say) only occurred in one package, there would just
be a symlink to the directory within /Programs/Foo under
/S/L/L/python2.3, and ls -l wouldn't resolve it, while readlink -f
will resolve them all the way up the tree)

>
> >> That said new Scripts help me to install the new kernel 2.6.20.7:
> > Good.
> [snip]
> >> Next steps:
> >>         1/ Compile Linux (I already use with success 2.6.21.4 on my debian)
> >>         2/ Build a kernel with my own config.
> > That shouldn't be a problem, so long as you've upgraded your Compile.
> > They're really the same step; Compile Linux will make menuconfig for
> > you,
> Yes it did but I am too laisy today to check out all my previous build option, I will continue later ,sorry.
>
> > so you can set it up how you like. It also takes care of
> > installing the kernel and modules, so it's pretty simple from there.
>
> I trust you but I need to go in more details how Recipe works:
> I would like it works like I use to rebuild my kernel manualy;
> some where I created a KBuild dir (e.g. linux-2.6-local_i686 and more if needed)
> then set  KBUILD_OUTPUT to point to that dir then I can run classical
>
> make clean ; make oldconfig;
>
> even
>
> make V=1 bzImage 2>&1 | tee /var/log/k-2.6.21.4 # so that I can trace build pb if encountered
>
> the same for modules, ...
>
> This method shows me severall advantages imho:
>         1/ the src tree is not anymore populated with binaries and it's so easier to look for something with 'find'
>         2/ different .config file are saved in their KBuild dir, so:
>                 - no risk of mistake when copying config file (in manual operation it happend frequently)
>                 - you can build several kernel for various config with only one src tree (save space)
>                   + in parallel (also with cross-compiler).
It unpacks and compiles in the same place, /F/C/S/Linux/2.6.21.4. It
then copies all the necessary files out into /P/Linux and /S/K/boot.
There's nothing stopping you from compiling manually with whatever
environment you like, though.

You'd probably want to use the source tree from the recipe (since it's
had the patches applied), but I don't think there'd be a problem
building to somewhere else as long as you moved the files into the
right places later on.
-Michael