Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Grant Taylor]

On 6/9/19 12:49 PM, Mick wrote:

3. Rebuild libtools, binutils, glibc.


Well, I've had some progress.

I'm now booted and running the kernel I just compiled.  (Same config, 
same genkernel command.)


I unmasked, downgraded, and selected (binutils-config) binutils to 
2.30-r4 before re-running the same genkernel command.


Interestingly enough, my ZFS pool didn't import when I booted, likely 
because the modules were from my backup.  Which means the new kernel 
wasn't compatible with the old modules.  So I'm re-emerging 
sys-fs/zfs-kmod now.

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Grant Taylor]

On 6/9/19 2:23 PM, Mick wrote:
I think Dale meant a later tree will contain updated packages, which 
may fix previous breakages and incompatibilities.


Please clarify which tree:  Kernel and / or Portage

Hypothetically, a later VBox version requires some later version libs, 
which your current tree is missing.  A re-sync will bring these in 
and your next emerge will fix the problems you were having.


I don't recall what version of VirtualBox was installed.  I know that it 
was 5..  I also know that it was current 3 ~ 4 months ago 
(emerge --sync at the time).


It looks like 5.2.26 is now installed (possibly the same version I had). 
 Anything newer than that (5.2.28-r1 / 5.2.30 / 6.*) is still masked by 
~amd64.


Admittedly, I have experienced this more than once with various 
packages.


I've had bad versions come into Portage that shuffle out in a few days 
multiple times before.  But those always failed to emerge (compile / 
install).


Nevertheless, your module related problems are more obscure/involved. 
A dev should have a better idea as to what might be causing this.


ACK

I'll need to refresh my account to post to the forums.

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Mick]

On Sunday, 9 June 2019 21:16:52 BST Grant Taylor wrote:
> On 6/9/19 1:38 PM, Dale wrote:
> > While I see that point and quite often it is a good idea, it could
> > also be that a fix is in the newer tree.  It could even be that you
> > caught the tree in the middle of some sort of change and you missed
> > part of it.
> > 
> > If it were me, I'd try everything you can but if you can't find a
> > solution, I'd sync and see what happens.  I've had a fresh sync fix
> > issues on a few occasions.  It's somewhat rare but can happen.
> > 
> > Just a thought.
> 
> Your logic makes sense.
> 
> I actually did end up reluctantly doing that at one point when I
> couldn't access my ZFS pool, which contained /usr/portage.  So, an
> emerge --sync was run to populate /usr/portage while attempting to fix ZFS.
> 
> I abandoned that line of work after a couple of hours and ended up
> restoring my ZFS module backup from a few days prior.  That got me
> access to my ZFS pool again.
> 
> So, I'm disinclined to think that it's a bum copy of portage.
> 
> But, it is still a valid question to to ask.

I think Dale meant a later tree will contain updated packages, which may fix 
previous breakages and incompatibilities.

Hypothetically, a later VBox version requires some later version libs, which 
your current tree is missing.  A re-sync will bring these in and your next 
emerge will fix the problems you were having.

Admittedly, I have experienced this more than once with various packages.  
Nevertheless, your module related problems are more obscure/involved.  A dev 
should have a better idea as to what might be causing this.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Grant Taylor]

On 6/9/19 1:38 PM, Dale wrote:
While I see that point and quite often it is a good idea, it could 
also be that a fix is in the newer tree.  It could even be that you 
caught the tree in the middle of some sort of change and you missed 
part of it.


If it were me, I'd try everything you can but if you can't find a 
solution, I'd sync and see what happens.  I've had a fresh sync fix 
issues on a few occasions.  It's somewhat rare but can happen.


Just a thought.


Your logic makes sense.

I actually did end up reluctantly doing that at one point when I 
couldn't access my ZFS pool, which contained /usr/portage.  So, an 
emerge --sync was run to populate /usr/portage while attempting to fix ZFS.


I abandoned that line of work after a couple of hours and ended up 
restoring my ZFS module backup from a few days prior.  That got me 
access to my ZFS pool again.


So, I'm disinclined to think that it's a bum copy of portage.

But, it is still a valid question to to ask.

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Dale]

Grant Taylor wrote:
> On 6/9/19 12:49 PM, Mick wrote:
>
>> 2. Sync portage and upgrade gcc to the latest stable version. Switch
>> to it.
>
> Portage is within a few days of current.
>
> I do an emerge --sync -q before doing the emerge -DuNeq @world.  I've
> not done a --sync since then while working on things.  The idea is to
> not introduce any more changes while dealing with this.


While I see that point and quite often it is a good idea, it could also
be that a fix is in the newer tree.  It could even be that you caught
the tree in the middle of some sort of change and you missed part of it. 

If it were me, I'd try everything you can but if you can't find a
solution, I'd sync and see what happens.  I've had a fresh sync fix
issues on a few occasions.  It's somewhat rare but can happen. 

Just a thought.

Dale

:-)  :-) 

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Grant Taylor]

On 6/9/19 12:49 PM, Mick wrote:
If you haven't done it already, perhaps have a look in the path 
/lib/modules/ 4.9.76-gentoo-r1/misc/ to check the VBox modules are 
present and owned by root:root with 0644 access rights.


They are there.  I would have expected the error message to be different 
if the modules couldn't be found (or read).


But it doesn't hurt to check.

ls -l /lib/modules/4.9.76-gentoo-r1/misc
total 621
-rw-r--r-- 1 root root 539592 Jun  8 09:39 vboxdrv.ko
-rw-r--r-- 1 root root  15000 Jun  8 09:39 vboxnetadp.ko
-rw-r--r-- 1 root root  39384 Jun  8 09:39 vboxnetflt.ko
-rw-r--r-- 1 root root  36248 Jun  8 09:39 vboxpci.ko


Since you have not cross compiled any of these modules, altered your 
make.conf CFLAGS, or messed with the linux-headers, I can't see what 
else might have gone sideways.  :-/


Agreed.

I'm not saying this is what you should do, but unless someone more 
learned than myself chimes in with better advice, this is how I would 
go about it:


1. Make a back up of your system in case you can't get back into it 
and need to restore from a back up.


BackupPC does that nightly for me.

Aside:  I'm quite happy with BackupPC.  It has worked extremely well for 
me for about 10 years.  If you're looking for a backup solution, I 
highly recommend you check it out.  I think you should check it out even 
if you aren't looking.


2. Sync portage and upgrade gcc to the latest stable version. 
Switch to it.


Portage is within a few days of current.

I do an emerge --sync -q before doing the emerge -DuNeq @world.  I've 
not done a --sync since then while working on things.  The idea is to 
not introduce any more changes while dealing with this.



3. Rebuild libtools, binutils, glibc.


Okay.

Do you (or anyone) know of any problems with downgrading binutils?  If I 
wanted to try to regress to the last working version for testing?


I don't know much about libtools.

I do know that glibc shouldn't be changed willy nilly without a good reason.


4. Rebuild @system.


Is there any problem with rebuilding @world in lieu of @system?  I think 
it just means more packages.  I guess there could be an issue with the 
overall emerge if there is a problem with a package that's in @world but 
not in @system.  At least emerge would not finish gracefully in that case.


5. Copy your present kernel config to the latest stable kernel 
which also deals with the MDS Intel vulnerability; change symlink; 
'make oldconfig' on the latest kernel; build it and install it. 


I'm reluctant to move to a new kernel version at this time.  I'm using 
Open vSwitch (for reasons) and last I looked (admittely it's been a 
while) I had an issue with newer than 4.9..  I don't recall 
the specifics.


Seeing as how I'm not concerned with the Intel MDS issues on this 
machine at this time, I don't view that as a compelling reason to change 
the kernel /now/.  Especially when dealing with other issues.


After all, the kernel has shown that it can be compiled and successfully 
run on the system.  So I really don't think the kernel version that I'm 
running is the problem.  ;-)



Don't forget to emerge @module- rebuild.


I use genkernel, which handles the config file for me.  (I've confirmed 
the one it's using matches the one from /proc/config.gz of the good 
kernel.)  I also have genkernel configured to rebuild modules for me.


CMD_CALLBACK="emerge --quiet @module-rebuild"

If the newly built kernel won't boot, troubleshoot the error messages 
at boot and perhaps keyword and try a later kernel.


I know that I can't successfully boot the new kernel.  I don't know if 
there are any error messages generated or not.  My monitor goes dark for 
a moment after picking the kernel in GRUB (2), and then I see my 
system's firmware initializing again.  The good kernel (that I'm 
replying from) does similar, but I see the penguins as part of the frame 
buffer initializing and other kernel messages.  I can't tell if there 
are messages from the bad kernel, or if the system is simply rebooting 
before any output.  Either way, I can't see any that quickly if they are 
there.  (I suppose I could record it with my phone and look at the video.)


The reason I would go about it this way is because ultimately you 
will need to both upgrade gcc and move on to a later version kernel.


I agree that I /should/ do that.  (RFC sense of "should".)  But I don't 
think it's required for what I use this machine for.  Admittedly, I 
won't get any of the myriad of benefits available without doing so.  But 
that's a /choice/, not a /compulsion/.  ;-)


I appreciate right now may not be the right time for you, but at some 
point, when convenient, you'll have to make time to deal with these 
errors and work through them to a solution.


Maybe.  Maybe not.  (See above.)

PS. May also be worth posting in the forums and asking in IRC as 
there will be more users who may have come across you problem.


ACK

Thank you for your input Mick.  I appreciate 

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Mick]

On Sunday, 9 June 2019 18:55:34 BST Grant Taylor wrote:
> On 6/9/19 2:56 AM, Mick wrote:
> > This sounds as if it may be related to a move from an older gcc to
> > a newer version.
> 
> I'm not sure it's related to a gcc version:
> 
> # gcc-config -l
>   [1] x86_64-pc-linux-gnu-6.4.0 *
>   [2] x86_64-pc-linux-gnu-8.3.0
> 
> I think that gcc 8.3 might have been selected and I reverted to 6.4
> thinking that it might have been part of the problem.  I have since done
> an emerge -DuNeq @world with gcc 6.4 and the problem persists.
> 
> > Checking my understanding:
> > 
> > 1. The old modules, compiled with the old gcc and toolchain worked
> > fine.
> 
> Correct.
> 
> > 2. The new modules, compiled with the new gcc but old libtool,
> > binutils and glibc worked (usually you update these or @system,
> > before you update the whole world).
> 
> Correct.
> 
> > 3. The new modules, compiled with the new gcc and toolchain rebuilt
> > the second time do not work (this would use libtools, binutils, glibc,
> > now compiled with the new gcc).
> 
> Correct.
> 
> > 4. All of the above happens with the old kernel, which was not rebuilt
> > with the new toolchain.
> 
> Correct.
> 
> > 5. New kernel(s) compiled thereafter will not boot.
> 
> Correct.
> 
> > You have not mentioned if you upgraded gcc.
> 
> I think that the first emerge -DuNeq @world did pull in a new gcc.  But
> I have since selected gcc 6.4 as part of diagnostics.  (See above.)
> 
> > The error you get about modules failing to load sounds like a
> > path/symlink error, or a linux headers error, or a change of arch.
> 
> I don't think it's a symlink error.  (I've configured things to not
> automatically update the sym-link.)
> 
> # ls -la /usr/src/linux
> lrwxrwxrwx 1 root root 22 Sep  8  2018 /usr/src/linux ->
> linux-4.9.76-gentoo-r1/
> # uname -a
> Linux REDACTED 4.9.76-gentoo-r1 #1 SMP Thu Nov 15 22:23:44 MST 2018
> x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux
> 
> As you can see, the machine has enough CPU that I can let it do the
> following to make sure that things are consistent.  (At least I think
> that's what's happening.)
> 
> emerge -DuNeq @world && emerge --depclean && revdep-rebuild
> 
> That's my SOP.  If that fails I usually try a --resume to see if the
> problem repeats, and if it's at the same place.  If that fails for some
> reason, I'll fall back to a @system.  Usually the failure is caused by
> something that I've done, disk space, ZFS version issues, etc.
> 
> > Since both vbox and zfs modules fail to boot I would not think this
> > is a zfs isolated problem.
> 
> Agreed.
> 
> > Have you tried forcing the loading of these modules?
> > 
> > modprobe --force --verbose 
> 
> No, not yet.  I've never had any success forcing the kernel to load modules.
> > What errors do you get with the new non-booting kernels?
> 
> # modprobe --force --verbose vboxdrv
> insmod /lib/modules/4.9.76-gentoo-r1/misc/vboxdrv.ko
> modprobe: ERROR: could not insert 'vboxdrv': Exec format error
> 
> dmesg reports the following for each attempt to (force) load the module.
> 
> module: vboxdrv: Unknown rela relocation: 4
> 
> Mick I get the impression that you've got the correct understanding of
> my current situation.  I'm interested learn what you think should be done.


If you haven't done it already, perhaps have a look in the path /lib/modules/
4.9.76-gentoo-r1/misc/ to check the VBox modules are present and owned by 
root:root with 0644 access rights.

Since you have not cross compiled any of these modules, altered your make.conf 
CFLAGS, or messed with the linux-headers, I can't see what else might have 
gone sideways.  :-/

I'm not saying this is what you should do, but unless someone more learned 
than myself chimes in with better advice, this is how I would go about it:

1. Make a back up of your system in case you can't get back into it and need 
to restore from a back up.
2. Sync portage and upgrade gcc to the latest stable version.  Switch to it.
3. Rebuild libtools, binutils, glibc.
4. Rebuild @system.
5. Copy your present kernel config to the latest stable kernel which also 
deals with the MDS Intel vulnerability; change symlink; 'make oldconfig' on 
the latest kernel; build it and install it.  Don't forget to emerge @module-
rebuild.

If the newly built kernel won't boot, troubleshoot the error messages at boot 
and perhaps keyword and try a later kernel.

The reason I would go about it this way is because ultimately you will need to 
both upgrade gcc and move on to a later version kernel.  I appreciate right 
now may not be the right time for you, but at some point, when convenient, 
you'll have to make time to deal with these errors and work through them to a 
solution.

PS. May also be worth posting in the forums and asking in IRC as there will be 
more users who may have come across you problem.

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Packages failed to build during 17.0 -> 17.1 migration

[Jack]

On 2019.06.07 06:24, Ilya Trukhanov wrote:

On Fri, Jun 07, 2019 at 08:03:30AM +0100, Sergei Trofimovich wrote:
> On Thu, 06 Jun 2019 18:49:48 -0400
> Jack  wrote:
>
> > On 2019.06.06 18:38, Ilya Trukhanov wrote:
> > > Namely x11-libs/libX11 and dev-libs/glib:
> > >
> > > - libX11 failed during configure because it couldn't find xcb;
> > > - glib failed during configure because it couldn't find  
libmount.

> > >
> > > Looks like it is an order issue, because after rebuilding
> > > x11-libs/libxcb and sys-apps/util-linux, both libX11 and glib  
built

> > > just
> > > fine.
> > >
> > > Should I report bugs for these? The news item says:
> > >
> > > >If you have any problems with the new profiles or the migration
> > > >procedure, please report a bug and make it block the tracker.
> > >
> > > But I'm a little reluctant to do so for various reasons.
> > >
> > I'm in the same situation.  I've had several rebuild failures that
> > succeeded after re-emerging one/some of what they depend on,  
although I

> > would have expected those to also be rebuilt.
> >
> > I wonder if the instructions should be "emerge -1 --deep /lib32
> > /usr/lib32" ?  I'll have to try it once I'm done with the current  
set

> > of emerges.
> >
> > Anyway - it probably does make sense to file the bug - the worst  
they
> > will do is close it as not a bug, and hopefully at least tell you  
what

> > you should have done to avoid the problem.
> >
>
> I think the emerge command as stated in the news item is incomplete
> as emerge does not pick correct rebuild order (it assumes all  
packages

> are installed and in order, thus picks arbitrary rebuild order).
>
> Try to add --complete-graph to it:
> emerge -1 --deep --complete-graph /lib32 /usr/lib32
>
> --
>
>   Sergei
>

Unfortunately this still doesn't guarantee the correct build order for
me. I wonder if running emerge with --keep-going a few times would  
work in

this situation?

It might be a good idea to mention this issue somewhere on the wiki  
or in a

follow-up news item. I doubt we're the last to face this problem now
that 17.1 profiles are stable.


I opened bug 687600 to improve the New item for this.
For me, adding --deep to the emerge command fixed the build order.
I would guess that adding --keep-going, and running multiple times  
would eventually get everything rebuilt also.


Jack

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Grant Taylor]

On 6/9/19 2:56 AM, Mick wrote:
This sounds as if it may be related to a move from an older gcc to 
a newer version.


I'm not sure it's related to a gcc version:

# gcc-config -l
 [1] x86_64-pc-linux-gnu-6.4.0 *
 [2] x86_64-pc-linux-gnu-8.3.0

I think that gcc 8.3 might have been selected and I reverted to 6.4 
thinking that it might have been part of the problem.  I have since done 
an emerge -DuNeq @world with gcc 6.4 and the problem persists.



Checking my understanding:

1. The old modules, compiled with the old gcc and toolchain worked 
fine.


Correct.

2. The new modules, compiled with the new gcc but old libtool, 
binutils and glibc worked (usually you update these or @system, 
before you update the whole world).


Correct.

3. The new modules, compiled with the new gcc and toolchain rebuilt 
the second time do not work (this would use libtools, binutils, glibc, 
now compiled with the new gcc).


Correct.

4. All of the above happens with the old kernel, which was not rebuilt 
with the new toolchain.


Correct.


5. New kernel(s) compiled thereafter will not boot.


Correct.


You have not mentioned if you upgraded gcc.


I think that the first emerge -DuNeq @world did pull in a new gcc.  But 
I have since selected gcc 6.4 as part of diagnostics.  (See above.)


The error you get about modules failing to load sounds like a 
path/symlink error, or a linux headers error, or a change of arch.


I don't think it's a symlink error.  (I've configured things to not 
automatically update the sym-link.)


# ls -la /usr/src/linux
lrwxrwxrwx 1 root root 22 Sep  8  2018 /usr/src/linux -> 
linux-4.9.76-gentoo-r1/

# uname -a
Linux REDACTED 4.9.76-gentoo-r1 #1 SMP Thu Nov 15 22:23:44 MST 2018 
x86_64 Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz GenuineIntel GNU/Linux


As you can see, the machine has enough CPU that I can let it do the 
following to make sure that things are consistent.  (At least I think 
that's what's happening.)


emerge -DuNeq @world && emerge --depclean && revdep-rebuild

That's my SOP.  If that fails I usually try a --resume to see if the 
problem repeats, and if it's at the same place.  If that fails for some 
reason, I'll fall back to a @system.  Usually the failure is caused by 
something that I've done, disk space, ZFS version issues, etc.


Since both vbox and zfs modules fail to boot I would not think this 
is a zfs isolated problem.


Agreed.


Have you tried forcing the loading of these modules?

modprobe --force --verbose 


No, not yet.  I've never had any success forcing the kernel to load modules.


What errors do you get with the new non-booting kernels?


# modprobe --force --verbose vboxdrv
insmod /lib/modules/4.9.76-gentoo-r1/misc/vboxdrv.ko
modprobe: ERROR: could not insert 'vboxdrv': Exec format error

dmesg reports the following for each attempt to (force) load the module.

module: vboxdrv: Unknown rela relocation: 4

Mick I get the impression that you've got the correct understanding of 
my current situation.  I'm interested learn what you think should be done.

Re: [gentoo-user] Keeping 17-year-old Kylix software alive

[Håkon Alstadheim]

Den 09.06.2019 11:24, skrev Matthias Hanft:


The old Kylix libraries just do some comprehensive calculations.
Not too difficult to manually translate that into PHP (or any
other script language, or even plain C), but just hundreds of
code lines to type...

Find a Pascal-to-C++ translator program, and/or hire a college student 
over the summer to do it.

Re: [gentoo-user] Keeping 17-year-old Kylix software alive

[Matthias Hanft]

Mick wrote:
> 
> Did you try the new revdep-rebuild in case it works (better)?

"Dynamic linking on your system is consistent... All done."

which, obviously, is not true :-)

BTW, the old revdep-rebuild.sh finally wants to rebuild hundreds
of packages... which I interrupted - makes no sense at all for me.

> I am not familiar with the particular software and wouldn't know how to keep 
> it alive on a present day Gentoo system - other than building Gentoo using an 
> old snapshot and installation media, perhaps in a VM and using additional 
> packages of the same era from the attic in a local overlay.

Ok, I could set up a complete "old" system, of course, but I'm
using the old libraries on a "production system" (they are
called by a PHP extension which is used by a public accessible
Apache web server). So I'm really interested in keeping the
rest of the system up-to-date.

The old Kylix libraries just do some comprehensive calculations.
Not too difficult to manually translate that into PHP (or any
other script language, or even plain C), but just hundreds of
code lines to type...

> Someone else may be able to offer useful advice, but I would think this is 
> more of a question suitable for the gentoo-dev mailing list[1] and IRC 
> channel[2].  Have you tried asking there?

Not yet - AFAIK the gentoo-dev list is read-only for non-developpers,
and I've never used IRC in my life at all :-) But I'll give it a try
if I have no further ideas...

-Matt

Re: [gentoo-user] Keeping 17-year-old Kylix software alive

[Mick]

On Sunday, 9 June 2019 09:21:17 BST Mick wrote:
> Hi Matt,
> 
> On Sunday, 9 June 2019 08:49:21 BST Matthias Hanft wrote:
> > Hi,
> > 
> > many years ago, I created some libSomething.so with Kylix 3 (1)
> > which still worked with current (32bit) Gentoo systems (Kernel
> > 4.14.83).
> > 
> > Using "revdep-rebuild.sh" (the *old* script!), for some time,
> > I already got messages like
> > 
> > broken /usr/local/lib/libxercesxmldom.so.1
> > /usr/local/lib/libxercesxmldom.so.1 (symbol __pthread_atfork version
> > GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
> > symbol __pthread_initialize version GLIBC_2.0 not defined in file
> > libpthread.so.0 with link time reference)
> > 
> > but everything worked fine anyway ("libxercesxmldom" is part of
> > Borland's standard runtime libraries).
> 
> Did you try the new revdep-rebuild in case it works (better)?
> 
> > However, after upgrading glibc from 2.27 to 2.28 (or newer), this
> > is not true any more: Compiling and running a C program using the
> > old Kylix libSomething.so libraries causes Segmentation fault, and
> > Apache using a PHP extension which calls those libraries won't start
> > at all any more.
> > 
> > For recompiling the Kylix libSomething.so libraries, I'm keeping
> > alive a Suse 8.1 Linux (2) in VirtualBox (Kernel 2.4.19).
> > 
> > Do you see any chance to keep those Kylix libraries alive and
> > running? If it would help, I'd try to install the old Kylix on
> > a current Gentoo system and try to recompile there (although
> > I guess Kylix won't run on a current Kernel any more - if it
> > can be installed at all).
> > 
> > Switching to another (Pascal-/Delphi-/Lazarus-/etc.) Compiler
> > is not an option because the .so libraries are in fact "packages"
> > (BPL, a special Borland library version).
> > 
> > Is there any possibility for some "binary interface/gateway" to
> > use those libraries any more, or do I have to reprogram the
> > whole functionality with PHP?
> > 
> > -Matt
> > 
> > (1) https://en.wikipedia.org/wiki/Borland_Kylix
> > (2) https://en.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions
> 
> I am not familiar with the particular software and wouldn't know how to keep
> it alive on a present day Gentoo system - other than building Gentoo using
> an old snapshot and installation media, perhaps in a VM and using
> additional packages of the same era from the attic in a local overlay.
> 
> Someone else may be able to offer useful advice, but I would think this is
> more of a question suitable for the gentoo-dev mailing list[1] and IRC
> channel[2].  Have you tried asking there?
> 
> [1] https://www.gentoo.org/get-involved/mailing-lists
> [2] https://www.gentoo.org/get-involved/irc-channels/all-channels.html

Hmm ... reading about borland kylix in the link you provided and this article 
I'm wondering if the two are related:

https://www.gentoo.org/support/news-items/2017-04-10-split-and-slotted-wine.html

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Module and kernel woes after two "emerge -DuNe @world"s

[Mick]

On Saturday, 8 June 2019 20:45:45 BST Grant Taylor wrote:
> On 6/8/19 12:26 PM, Mick wrote:
> > Were these contents not there, or is it that the new version of
> > modules do not work?
> 
> The old (original for the sake of this thread) versions (restored from
> backups) work just fine.
> 
> The version produced during the first emerge -DuNe @world worked.  At
> least I'm not aware of any problems.
> 
> The version produced during the second emerge -DuNe @world did not work.

This sounds as if it may be related to a move from an older gcc to a newer 
version.  Checking my understanding:

1. The old modules, compiled with the old gcc and toolchain worked fine.
2. The new modules, compiled with the new gcc but old libtool, binutils and 
glibc worked (usually you update these or @system, before you update the whole 
world).
3. The new modules, compiled with the new gcc and toolchain rebuilt the second 
time do not work (this would use libtools, binutils, glibc, now compiled with 
the new gcc).
4. All of the above happens with the old kernel, which was not rebuilt with 
the new toolchain.
5. New kernel(s) compiled thereafter will not boot.

You have not mentioned if you upgraded gcc.

The error you get about modules failing to load sounds like a path/symlink 
error, or a linux headers error, or a change of arch.  Since both vbox and zfs 
modules fail to boot I would not think this is a zfs isolated problem.

Have you tried forcing the loading of these modules?

modprobe --force --verbose 

What errors do you get with the new non-booting kernels?

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-user] Keeping 17-year-old Kylix software alive

[Mick]

Hi Matt,

On Sunday, 9 June 2019 08:49:21 BST Matthias Hanft wrote:
> Hi,
> 
> many years ago, I created some libSomething.so with Kylix 3 (1)
> which still worked with current (32bit) Gentoo systems (Kernel
> 4.14.83).
> 
> Using "revdep-rebuild.sh" (the *old* script!), for some time,
> I already got messages like
> 
> broken /usr/local/lib/libxercesxmldom.so.1
> /usr/local/lib/libxercesxmldom.so.1 (symbol __pthread_atfork version
> GLIBC_2.0 not defined in file libpthread.so.0 with link time reference
> symbol __pthread_initialize version GLIBC_2.0 not defined in file
> libpthread.so.0 with link time reference)
> 
> but everything worked fine anyway ("libxercesxmldom" is part of
> Borland's standard runtime libraries).

Did you try the new revdep-rebuild in case it works (better)?


> However, after upgrading glibc from 2.27 to 2.28 (or newer), this
> is not true any more: Compiling and running a C program using the
> old Kylix libSomething.so libraries causes Segmentation fault, and
> Apache using a PHP extension which calls those libraries won't start
> at all any more.
> 
> For recompiling the Kylix libSomething.so libraries, I'm keeping
> alive a Suse 8.1 Linux (2) in VirtualBox (Kernel 2.4.19).
> 
> Do you see any chance to keep those Kylix libraries alive and
> running? If it would help, I'd try to install the old Kylix on
> a current Gentoo system and try to recompile there (although
> I guess Kylix won't run on a current Kernel any more - if it
> can be installed at all).
> 
> Switching to another (Pascal-/Delphi-/Lazarus-/etc.) Compiler
> is not an option because the .so libraries are in fact "packages"
> (BPL, a special Borland library version).
> 
> Is there any possibility for some "binary interface/gateway" to
> use those libraries any more, or do I have to reprogram the
> whole functionality with PHP?
> 
> -Matt
> 
> (1) https://en.wikipedia.org/wiki/Borland_Kylix
> (2) https://en.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions

I am not familiar with the particular software and wouldn't know how to keep 
it alive on a present day Gentoo system - other than building Gentoo using an 
old snapshot and installation media, perhaps in a VM and using additional 
packages of the same era from the attic in a local overlay.

Someone else may be able to offer useful advice, but I would think this is 
more of a question suitable for the gentoo-dev mailing list[1] and IRC 
channel[2].  Have you tried asking there?

[1] https://www.gentoo.org/get-involved/mailing-lists
[2] https://www.gentoo.org/get-involved/irc-channels/all-channels.html

-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.

[gentoo-user] Keeping 17-year-old Kylix software alive

[Matthias Hanft]

Hi,

many years ago, I created some libSomething.so with Kylix 3 (1)
which still worked with current (32bit) Gentoo systems (Kernel
4.14.83).

Using "revdep-rebuild.sh" (the *old* script!), for some time,
I already got messages like

broken /usr/local/lib/libxercesxmldom.so.1
/usr/local/lib/libxercesxmldom.so.1 (symbol __pthread_atfork version GLIBC_2.0 
not defined in file libpthread.so.0 with link time reference
symbol __pthread_initialize version GLIBC_2.0 not defined in file 
libpthread.so.0 with link time reference)

but everything worked fine anyway ("libxercesxmldom" is part of
Borland's standard runtime libraries).

However, after upgrading glibc from 2.27 to 2.28 (or newer), this
is not true any more: Compiling and running a C program using the
old Kylix libSomething.so libraries causes Segmentation fault, and
Apache using a PHP extension which calls those libraries won't start
at all any more.

For recompiling the Kylix libSomething.so libraries, I'm keeping
alive a Suse 8.1 Linux (2) in VirtualBox (Kernel 2.4.19).

Do you see any chance to keep those Kylix libraries alive and
running? If it would help, I'd try to install the old Kylix on
a current Gentoo system and try to recompile there (although
I guess Kylix won't run on a current Kernel any more - if it
can be installed at all).

Switching to another (Pascal-/Delphi-/Lazarus-/etc.) Compiler
is not an option because the .so libraries are in fact "packages"
(BPL, a special Borland library version).

Is there any possibility for some "binary interface/gateway" to
use those libraries any more, or do I have to reprogram the
whole functionality with PHP?

-Matt

(1) https://en.wikipedia.org/wiki/Borland_Kylix
(2) https://en.wikipedia.org/wiki/SUSE_Linux#SUSE_distributions