LinuxQuestions.org - [SOLVED] Slackware 14.2 glibc-2.23 vs Slackware Current glibc-2.24 and the Current 4.4.17 Kernel

- Slackware (https://www.linuxquestions.org/questions/slackware-14/)

- - Slackware 14.2 glibc-2.23 vs Slackware Current glibc-2.24 and the Current 4.4.17 Kernel (https://www.linuxquestions.org/questions/slackware-14/slackware-14-2-glibc-2-23-vs-slackware-current-glibc-2-24-and-the-current-4-4-17-kernel-4175586849/)

Slackware 14.2 glibc-2.23 vs Slackware Current glibc-2.24 and the Current 4.4.17 Kernel

Question for the Experts.

I've been installing the 4.4.x Kernel Packages from Slackware64 Current into my Slackware64 14.2 System.

Up to now, Current and 14.2 were both running glibc-2.23 and both were compiled with gcc-5.3.0 so no problems with that.

Now Current is running glibc-2.24 compiled with gcc-5.4.0.

I suppose the Current 4.4.x Kernels are no longer safe to install in 14.2 ?

Thanks !

-- kjh( :) all good ( easy ) things must eventually come to an end :) )

Hello,

AFAIK, you can use a newer kernel even if it was compiled against new glibc and/or with new gcc, but, you must not upgrade the kernel-headers package.

To not break anything, it's better to not upgrade the kernel packages, but to *install* the news alongside the older versions. slackpkg will complain about duplicate packages, but you can circumvent that by blacklisting the kernel packages in /etc/slackpkg/blacklist.

Once you have installed the new packages (ie. kernel-huge, kernel-generic, kernel-modules, and kernel-sources), do not forget to re-create the initrd for the generic kernel as in example below, and to re-run lilo (if you use it).

Code:

$ /usr/share/mkinitrd/mkinitrd_command_generator.sh -k 4.4.17



...

mkinitrd -c -k 4.4.17 ...

I just tried in a VM while writing this message, and all seems to work, even VirtualBox that I installed in the VM (for fun) has automatically rebuilt the modules for 4.4.17.

Anyway, It would be better that you try this in a VM before doing that on your system.

--
SeB

Thank you as always, SeB !

Interesting results !

I'll give it a shot:

Code:

cd /home/dld/slackware/slackware-current-64

installpkg slackware64/a/kernel-generic-4.4.17-x86_64-1.txz \

          slackware64/a/kernel-huge-4.4.17-x86_64-1.txz    \

          slackware64/a/kernel-modules-4.4.17-x86_64-1.txz

vim /etc/lilo.conf

lilo

shutdown -r now

#

# after booting 4.4.17  ...

#

cd /home/dld/nvidia

NVIDIA-Linux-x86_64-367.35.run

shutdown -r now

#

# after booting 4.4.17 + NVidia ...

#

startx

Since I can always 'revert' to an older kernel I'll give it a go on my Prod Laptop and report back.

Thanks again, SeB.

-- kjh

Hello,

about nvidia driver. Just in case you don't know, you can build the driver module for the running kernel without uninstall of the existing module(s) with the option --kernel-module-only. Personaly, I always run it as below :

Code:

$ sh ./NVIDIA-Linux-<ARCH>-<VERSION>.run --accept-license --ui=none --kernel-module-only

--
SeB

Thanks for the NVidia hint SeB.

[EDIT]
The following did not work because I failed to install the kernel-source-4.4.17 !

See post #3

I installed kernel-source-4.4.17, reset the symlinks in /boot/ and all is well.

I'll run 4.4.17 for a while and watch the logs.
[/EDIT]

The 4.4.17 experiment was a bust.

The system booted 4.4.17 fine but my VMWare Workstation BlockDev and Network Modules FAILED to load.

Normally with a new Kernel, there will be a delay on 'first boot' while VMWare rebuilds the Kernel Modules.

This time with kernel-4.4.17 from Slackware64 Current the rebuild failed and I had no vmnet interfaces ( not sure about the disks -- didn't even try ).

I rebooted 4.4.16 which hung hard after the 'ACPI: Power Button [PWRF]' message but before the message saying it was loading a custom ath10k_pci Kernel Module I built for my Killer 1535 Wireless.

I did a Hard-Reset and booted 4.4.17 and fixed the symlinks in /boot:

Code:

cd /boot/

ln -sf System.map-huge-4.4.16  System.map

ln -sf config-huge-4.4.16      config

ln -sf vmlinuz-huge-4.4.16      vmlinuz

ln -sf vmlinuz-generic-4.4.16  vmlinuz-generic

ln -sf vmlinuz-huge-4.4.16      vmlinuz-huge

After which I was able to boot 4.4.16 and the NVidia Modules loaded and VMWare started OK.

I'll be removing those 4.4.17 Packages ( after I do a dry-run: `removepkg -warn kernel-*-4.4.17`) and then I'll build and install those 4.4.17 Kernel Packages locally :)

-- kjh

I have always assumed that in slackware-current, where a new version of a package appears, every package that would be affected by this change is rebuilt or updated. Unless of course there is some mistake. I never had serious problems after updating.

Toutatis --

Yes, Pat does a great job with Dependencies so it is generally true within a single version that the Packages are 'consistent'.

I have been cheating though.

I have been installing kernel-4.4.x Packages from Current into my Slackware64 14.2 System.

But, I've not installed anything from Current into 14.2 except for the Kernel.

So if anything has changed in Current that affects the kernel binaries, I will have to stop 'cheating' and then build and package-up my own kernels in 14.2.

I was worried that the new gcc-5.4.0 and glibc-2.24 in Current might break the Kernel for 14.2 which has gcc-5.3.0 and glibc-2.23

And then to complicate things even more, I am running the MultiLib versions of gcc and glibc:

Code:

# ver gcc- glibc-

-rw-r--r-- 1 root root  44797 Mar 12 14:11 /var/log/packages/gcc-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root  41905 Mar 12 14:11 /var/log/packages/gcc-g++-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root  2762 Mar 12 14:11 /var/log/packages/gcc-gfortran-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root 251603 Mar 12 14:11 /var/log/packages/gcc-gnat-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root  20355 Mar 12 14:12 /var/log/packages/gcc-go-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root 236582 Mar 12 14:12 /var/log/packages/gcc-java-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root  2232 Mar 12 14:12 /var/log/packages/gcc-objc-5.3.0_multilib-x86_64-3alien

-rw-r--r-- 1 root root  32507 Feb 29 05:48 /var/log/packages/glibc-2.23_multilib-x86_64-1alien

-rw-r--r-- 1 root root 491578 Feb 29 05:48 /var/log/packages/glibc-i18n-2.23_multilib-x86_64-1alien

-rw-r--r-- 1 root root  1325 Feb 29 05:48 /var/log/packages/glibc-profile-2.23_multilib-x86_64-1alien

-rw-r--r-- 1 root root  15563 Feb 29 05:48 /var/log/packages/glibc-solibs-2.23_multilib-x86_64-1alien

-rw-r--r-- 1 root root  71018 Aug 12 09:54 /var/log/packages/glibc-zoneinfo-2016f-noarch-1_slack14.2

Seb's post gave me enough info and the courage to try out the 4.4.17 kernel Packages from Current is 14.2.

The Current kernel-*-4.4.17 Packages seem to run OK, after I fixed my goof ( by not installing kernel-source-4.4.17 ).

For the record, this is what I've installed from Current in my 14.2 ( note that slackware64/d/kernel-headers-4.4.17-x86-1 are excluded )

Code:

# ver kernel-*4.4.17



-rw-r--r-- 1 root root    985 Aug 12 06:51 /var/log/packages/kernel-generic-4.4.17-x86_64-1

-rw-r--r-- 1 root root    981 Aug 12 06:51 /var/log/packages/kernel-huge-4.4.17-x86_64-1

-rw-r--r-- 1 root root  248554 Aug 12 06:51 /var/log/packages/kernel-modules-4.4.17-x86_64-1

-rw-r--r-- 1 root root 3413105 Aug 12 08:18 /var/log/packages/kernel-source-4.4.17-noarch-1

Thanks.

-- kjh

Hi,

Quote:

Originally Posted by phenixia2003 (Post 5589730)

AFAIK, you can use a newer kernel even if it was compiled against new glibc and/or with new gcc, but, you must not upgrade the kernel-headers package.

It's not the kernel that is built against glibc, it's the glibc that is built against the kernel. More specifically, against the kernel headers.

Kernel can be compiled with pretty which ever compiler you want, as long as it produces the correct code ;-)
Among the officially supported compilers is gcc, gcc, and gcc ;-)

--
Best regards,
Andrzej Telszewski

Dooh !

Thanks for that info atelszewski !

That explains why it works ( very well so far ).

-- kjh

I have uploaded new multilib versions of gcc-5.4.0 and glibc-2.24 for slackware64-current.

Hi,

i have changed to current just to get the newer gcc, and glibc also , now i do my own custom kernel 4.6.6

at most time after fresh installation i went with the kernel some versions when i also have new hardware
so one can get better support for new functions and devices

i have never had any problems by going this way , its just time consuming , but i have an actual system when i have done

later when its all running like it should, i do only some security patches by compiling these packages by myself

than there is nothing todo until the next slackware comes up or i get new hardware ;)