[gentoo-user] Big problem with module-rebuild

[gentoo-user] Big problem with module-rebuild

[Holly Bostick]

.. and that problem is, in short, that the rebuild unmerges the previous
version, in the currently-running (or previous) kernel modules folder,
breaking the previous kernel.

And my question is, how to get it to stop doing that. If Portage has a
FEATURES setting that prevents the previous version being unmerged this
way, I don't know what it is.....

Example:

I'm currently using 2.6.13-gentoo-r4, and am compiling 2.6.14-gentoo.

/usr/src/linux points to 2.6.14-gentoo.

module-rebuild rebuild
** Preparing to merge modules:
** Packages which I will emerge are:
	=sys-fs/submount-0.9-r2
	=media-libs/svgalib-1.9.23
	=media-video/ati-drivers-8.18.8-r1

Now, taking the "most important" of these modules, let's look at what
happens with ati-drivers (it's "most important" because X is set to
use it, and naturally X won't start if the driver is not found).

|>> emerge (3 of 3) media-video/ati-drivers-8.18.8-r1 to /
<snip>
 * Determining the location of the kernel source code
 * Found kernel source directory:
 *     /usr/src/linux
 * Found sources for kernel version:
 *     2.6.14-gentoo
 * Checking for MTRR support enabled ...

         [ ok ]
 * Checking for AGP support enabled ...

         [ ok ]
 * Checking for DRM support disabled ...

         [ ok ]
* X11 implementation is xorg-x11.

So, the drivers are going to compile against 2.6.14, which is what I
want, and correct. So far so good.

| >>> Unpacking source...
 * Unpacking Ati drivers ...         [ ok ]
 * Applying fglrx-2.6.14-access_ok.patch ...       [ ok ]
|>>> Source unpacked.
 * Building the DRM module...
make: Entering directory `/usr/src/linux-2.6.14-gentoo'
 <snip>
make: Leaving directory `/usr/src/linux-2.6.14-gentoo'
|>>> Test phase [not enabled]: media-video/ati-drivers-8.18.8-r1

|>>> Install ati-drivers-8.18.8-r1 into
/var/tmp/portage/ati-drivers-8.18.8-r1/image/ category media-video
 * Installing fglrx module
<snip>
--- /lib/modules/
--- /lib/modules/2.6.14-gentoo/
--- /lib/modules/2.6.14-gentoo/video/
|>>> /lib/modules/2.6.14-gentoo/video/fglrx.ko
<snip>
|>>> /usr/lib/opengl/ati/lib/libGL.so.1 -> libGL.so.1.2

And the drivers build and install fine... then this:

|>>> Safely unmerging already-installed instance...
<snip>
==>--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko
==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video
==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4
<snip>
Switching to ati OpenGL interface... done
|>>> original instance of package unmerged safely.
Switching to ati OpenGL interface... done

So the rebuild process has *removed* the kernel modules for what will be
the previous kernel when I reboot--- and if my new kernel doesn't boot,
well neither will my previous one, depending on how critical the modules
are (in this case, I just won't have X, but depending on one's setup,
one might have lost something really necessary).

In any case this is really not correct behaviour (I want both the
currently-running kernel module and the future-kernel module to be
installed).

The only way I can see to avoid this is to step through the emerges with
the 'ebuild' command, stopping after 'install', and not performing
'postinst' or 'unmerge' (whichever one is performed at the end to remove
the previously-existing package).

I don't see SLOTs as being precisely appropriate, but I don't see what
other method *might* resolve this, since the previously-installed
package is in this case (in most cases?) *not* the same as the
re-emerged package, because they are compiled against different kernels.

Is there a way to SLOT external kernel modules against the kernel
version it's being compiled against?

This seems to definitely be a bug, but I have not the first clue how to
submit it, nor what against....

....help, help, help.... and hope 2.6.14 works, because if it doesn't,
I've got no modules for my previous kernel....

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Big problem with module-rebuild

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

On Mon, 07 Nov 2005 18:26:02 +0100, Holly Bostick wrote:

> And my question is, how to get it to stop doing that. If Portage has a
> FEATURES setting that prevents the previous version being unmerged this
> way, I don't know what it is.....

Doesn't AUTOCLEAN="no" do this?

It is a separate setting, not a FEATURE.


-- 
Neil Bothwick

"A hundred years of forgetting and it all comes rushing back..."

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-user] Big problem with module-rebuild

[Holly Bostick]

Neil Bothwick schreef:
> On Mon, 07 Nov 2005 18:26:02 +0100, Holly Bostick wrote:
> 
> 
>> And my question is, how to get it to stop doing that. If Portage
>> has a FEATURES setting that prevents the previous version being
>> unmerged this way, I don't know what it is.....
> 
> 
> Doesn't AUTOCLEAN="no" do this?
> 
> It is a separate setting, not a FEATURE.
> 
> 

Yes, I see that, but since the description of it is not exactly clear, I
don't know if setting it to "no" would help, except by testing, which
I'm not prepared to do atm:

(from man make.conf)

 AUTOCLEAN = ["yes" | "no"]
              Automatically cleans the system by removing outdated
packages which will not remove functionalities or prevent your  system  from
              working.  On  major ABI changes this may need to be set to
off to ensure that the system can be rebuilt using the new libs before
              the old ones are removed. Downgrading with this option
turned off may result in missing symlinks and an inoperable system.
              Defaults to yes.


In this respect, am I to assume that the "outdated package" is the
previously-installed version? I don't think so; I think this is a
separate process.

I just reinstalled Wine (unrelated, but perhaps appropriate for an
example) and the output does the "clean" process well after the previous
version (which is in this case the same version) was removed:


|>>> Safely unmerging already-installed instance...
--- !mtime obj /usr/share/wine/wine.inf
<snip>
--- !targe sym /usr/lib/libwine.so
--- !targe sym /usr/bin/wineg++
--- !targe sym /usr/bin/winecpp
|>>> original instance of package unmerged safely.
 * ~/.wine/config is now deprecated.  For configuration either use
 * winecfg or regedit HKCU\Software\Wine
|>>> Regenerating /etc/ld.so.cache...
|>>> app-emulation/wine-0.9 merged.

|>>> clean: No packages selected for removal.
|>>> Auto-cleaning packages ...

But I could most certainly be reading this all wrong; it would certainly
be an easy solution if that was the case.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Big problem with module-rebuild

[George Garvey]

On Mon, Nov 07, 2005 at 07:59:39PM +0100, Holly Bostick wrote:
> Neil Bothwick schreef:
> > On Mon, 07 Nov 2005 18:26:02 +0100, Holly Bostick wrote:
> > 
> > 
> >> And my question is, how to get it to stop doing that. If Portage
> >> has a FEATURES setting that prevents the previous version being
> >> unmerged this way, I don't know what it is.....
> > 
> > 
> > Doesn't AUTOCLEAN="no" do this?
> > 
> > It is a separate setting, not a FEATURE.

   Setting AUTOCLEAN to no, generally, will make a mess (in my
opinion). Then, ALL old copies of things that are updated will be left
installed. One ends up with multiple installed versions of every
package on the system eventually.
   Maybe just for that one package it would be okay. But it sounds
like the wrong answer.
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Big problem with module-rebuild

[Neil Bothwick]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

On Tue, 8 Nov 2005 05:47:13 -0800, George Garvey wrote:

>    Setting AUTOCLEAN to no, generally, will make a mess (in my
> opinion). Then, ALL old copies of things that are updated will be left
> installed. One ends up with multiple installed versions of every
> package on the system eventually.
>    Maybe just for that one package it would be okay. But it sounds
> like the wrong answer.

I was only suggesting it be used in this case, not as a global setting.

-- 
Neil Bothwick

I have seen the truth, and it makes no sense.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-user] Re: Big problem with module-rebuild

[Remy Blank]

Holly Bostick wrote:
> And the drivers build and install fine... then this:
> 
> |>>> Safely unmerging already-installed instance...
> <snip>
> ==>--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko
> ==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video
> ==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4
> <snip>
> Switching to ati OpenGL interface... done
> |>>> original instance of package unmerged safely.
> Switching to ati OpenGL interface... done
> 
> So the rebuild process has *removed* the kernel modules for what will be
> the previous kernel when I reboot

I don't think so. "cfgpro" means the modules are *not* removed on
unmerge. Have a look, they should still be there. At least, they are on
my machines, although I don't use module-rebuild but a custom script (a
one-liner, actually). I have always had the messages as you describe
above, and the modules have always stayed around. If they don't, then
something is wrong with your configuration.

It's kinda the same as /etc on unmerge. The files just stick around.

-- Remy


Remove underscore and suffix in reply address for a timely response.

-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Re: Big problem with module-rebuild [SOLVED]

[Holly Bostick]

Remy Blank schreef:
> Holly Bostick wrote:
> 
>> And the drivers build and install fine... then this:
>> 
>> |>>> Safely unmerging already-installed instance... <snip> ==>---
>> cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko ==>---
>> cfgpro dir /lib/modules/2.6.13-gentoo-r4/video ==>--- cfgpro dir
>> /lib/modules/2.6.13-gentoo-r4 <snip> Switching to ati OpenGL
>> interface... done |>>> original instance of package unmerged
>> safely. Switching to ati OpenGL interface... done
>> 
>> So the rebuild process has *removed* the kernel modules for what
>> will be the previous kernel when I reboot
> 
> 
> I don't think so. "cfgpro" means the modules are *not* removed on 
> unmerge. Have a look, they should still be there. At least, they are
> on my machines, although I don't use module-rebuild but a custom
> script (a one-liner, actually). I have always had the messages as you
> describe above, and the modules have always stayed around. If they
> don't, then something is wrong with your configuration.
> 
> It's kinda the same as /etc on unmerge. The files just stick around.
> 
> -- Remy

Thank you, Remy-- you're right:

la /lib/modules/2.6.13-gentoo-r4/video/
totaal 317
drwxr-xr-x  2 root root     72 nov  7 18:00 .
drwxr-xr-x  6 root root    496 nov  7 18:30 ..
-rw-r--r--  1 root root 321951 nov  7 18:00 fglrx.ko

OK, so I'm panicking over nothing, which is good to know, but now I'm a
little P.O.'d that I should have had *cause* to panic (I've gotta be a
bit P.O'd about something, since I've made a fool of myself ;-) ).

Seems to me that someone even less technically adept than I am (and I'm
not really all that, after all), could really lose their cool under
these circumstances, all because of that little cfgpro that they might
not know what it means, even if they saw it.

I'm really glad to know that the files are not in fact removed, but I
have this feeling that it should have been clearer that they really
weren't removed, despite the fact that that section of the operation was
removing files. Ah well, I know Portage isn't perfect, but it usually
doesn't scare the pants off me just during normal operation like that
(which tends to scare me more than just normal Portage scary-stuff).

Anyway, thanks again.

Holly
-- 
gentoo-user@gentoo.org mailing list

Re: [gentoo-user] Big problem with module-rebuild

[Peter Ruskin]

On Monday 07 November 2005 17:26, Holly Bostick wrote:
> And the drivers build and install fine... then this:
> |>>> Safely unmerging already-installed instance...
>
> <snip>
> ==>--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko
> ==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video
> ==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4
> <snip>
> Switching to ati OpenGL interface... done
>
> |>>> original instance of package unmerged safely.
>
>T Switching to ati OpenGL interface... done
>
> So the rebuild process has *removed* the kernel modules for what
> will be the previous kernel when I reboot--- and if my new kernel
> doesn't boot, well neither will my previous one, depending on how
> critical the modules are (in this case, I just won't have X, but
> depending on one's setup, one might have lost something really
> necessary).

This sort of thing happened *ages* ago with the nvidia drivers.  I 
don't remember how they fixed it but you could try adding 
"CONFIG_PROTECT="/lib/modules" to /etc/make.conf.

-- 
Peter
========================================================================
Gentoo Linux: Portage 2.0.51.22-r3.	kernel-2.6.13-gentoo-r5.
i686 AMD Athlon(tm) XP 3200+.		gcc(GCC): 3.3.5-20050130.
KDE: 3.4.92 (beta2, >= 20051010).	Qt: 3.3.4.
========================================================================
-- 
gentoo-user@gentoo.org mailing list

[gentoo-user] Re: Big problem with module-rebuild

[Marc Christiansen]

Holly Bostick <motub@planet.nl> wrote:
> .. and that problem is, in short, that the rebuild unmerges the previous
> version, in the currently-running (or previous) kernel modules folder,
> breaking the previous kernel.

Did you check if the files are really gone?

[...]
> |>>> Safely unmerging already-installed instance...
> <snip>
> ==>--- cfgpro obj /lib/modules/2.6.13-gentoo-r4/video/fglrx.ko
> ==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4/video
> ==>--- cfgpro dir /lib/modules/2.6.13-gentoo-r4
     ^^^^^^^^^^
The '---' mean that no action was taken and the following word gives the
reason, in this case CONFIG_PROTECT (at least it should be this way and
for me it is).

> This seems to definitely be a bug, but I have not the first clue how to
> submit it, nor what against....

If the modules are indeed gone, I'd say it is a bug in emerge or
portage.

> ....help, help, help.... and hope 2.6.14 works, because if it doesn't,
> I've got no modules for my previous kernel....

For me the switch to 2.6.14 went without much problems and I did use
module-rebuild. My modules are still there for 2.6.13-r5. Most of
the problems were my own fault, I decided to cleanup my kernel config
and deselected too much... Except for a problem with the owner-module
for iptables, it no longer supports cmd-owner, pid-owner or sid-owner
although the help still says it does, you have to look at dmesg to find
out. But this is a minor problem which I'll solve when needed. So,
enough of my ramblings they don't help you.

Marc

-- 
gentoo-user@gentoo.org mailing list