Installing glibc-2.26-r6 inside chroot fails

devsk

It fails with kernel too old coming from toochain-glibc.eclass because my host is running kernel 2.6.32. OK, I modify that eclass to not die, but then the glibc install fails because sln is not able to create symlinks: sln fails with "FATAL : kernel too old".

I pass --enable-kernel=2.6.32 to the configure and glibc still fails to install with the same error.

My running kernel for the gentoo install would be 4.9.x when it boots up on a VM. Its just that I don't have control over the kernel of the host where I am doing chroot into. That kernel is fixed to 2.6.32.

Anybody know how to build glibc with older kernels? Why did someone put this dumb check at build time anyway? It should only be dying at run time if the running kernel is old.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

Once you build glibc, you will install it. If the installed glibc is broken, you will no longer be able to use that system root. That encourages the glibc maintainers to take a very cautious view toward known glibc breakage.

Why not build an appropriately old glibc now, finish the install, and reboot into the modern kernel, then upgrade glibc from there?

Jaglover · Posted: Sat Feb 17, 2018 11:42 pm Post subject:

I understand you are installing Gentoo? Will it boot up with stage3 unpacked and your own kernel? Then you do not chroot for upgrade.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!

devsk · Posted: Sun Feb 18, 2018 12:55 am Post subject:

Let me describe the setup. I have a beefy host given by our IT to build a gentoo system as our distro for the product. The built gentoo system eventually boots inside a VM using 4.9.x kernel. The VM has no capabilities (2 vCPUs, 256MB of RAM) to build or update the packages. The rootfs is a read-only squashfs image.

The beefy host is a redhat system with 2.6.32 kernel. I have no control on this setup, and I can not update the kernel. I get into a chroot and build my gentoo there. Once built, I build a squashfs image and move it to the VM to boot the newly created image.

It is during the update that portage wants to update glibc from 2.25 to 2.26 and this kernel check is coming in the way.

Note that the running kernel for the built gentoo system is 4.9.x and hence not old. So, this check for kernel should have been for runtime, and not build time.

Ant P. · Watchman Joined: 18 Apr 2009 Posts: 6920

You've got a few options. Avoid glibc 2.26 entirely, fix glibc by hand to work on a ten year old kernel, create a build VM to do the job, find another physical box that isn't hopelessly out of date...

...or point out to your management that RHEL 6 is going to start costing them serious money unless they start taking action now for the approaching EOL. 30 months isn't a long time in the enterprise world.

devsk · Posted: Sun Feb 18, 2018 3:49 am Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

I think your first post addressed that question, at least indirectly. You are not only building glibc. You are also running it. If you were not running parts of it, the sln program would not fail on you during the install phase, because you would not be running the sln from the new glibc. While it might be possible to use the ancient kernel during the build, your existing failure shows it is not possible without patching glibc. You can update your kernel or you can patch sln (and possibly other things) not to require a new kernel.

I concur with Ant P. Your best practical bet is to mask >=sys-libs/glibc-2.26 until such time as IT provides a sane build environment.

devsk · Posted: Sun Feb 18, 2018 8:58 am Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21633

Masking only sys-libs/glibc may not be an option. You might get somewhere if you mask more. (Yes, I am aware of the irony that I am actively advocating masking out new versions of multiple packages, which is in almost all cases the wrong solution on Gentoo. I think it is the wrong solution here, but since you cannot fix your kernel, it is the least bad option in my opinion.) For the output shown, you only need net-libs/rpcsvc-proto for the specific versions and flags picked elsewhere. Older app-emulation/open-vm-tools does not require it. Older autofs requires it conditionally, and can be disabled via USE flag.

NeddySeagoon · Posted: Sun Feb 18, 2018 7:28 pm Post subject:

devsk,

This is for a product. The IT department is supposed to be there to support products, not get in the way.
File a ticket and make a lot of noise. Someone will listen.

The downside is, you will get known to all the right people for all the wrong reasons.

Having said all that, set yourself up a target root, much like crossdev does.
You can run Gentoo on that out of date kernel and build things but not install them in the chroot, so you don't actually run them.
Portage is quite happy to install arm64 binaries on my amd64 box that way.
The target root will only contain the things than will be moved to the product.

FEATURES=buildpkgonly might be an option too.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

devsk · Posted: Sun Feb 18, 2018 7:40 pm Post subject:

@NeddySeagoon: This turned out to be harder than I initially thought but yeah, I am not going to fight the windmills any longer... :-)

glibc folks have decided to move on, we should move on as well. I have put in a request for a brand new build env with newer kernel. Let's see how that goes.