Re: [Astlinux-devel] Astlinux base system

[Lonnie A. <li...@lo...>]

Regarding - Update the toolchain using a newer gcc and glibc

I have been testing a new crosstool-NG 1.24.0 version.

I settled in on a good update:

glibc 2.27, binutils 2.29.1, gcc 6.5.0

After a few package tweaks, and patches for the new glibc, it builds and runs.

But, not after a day or so of frustration, the initrd with the new glibc crashed when called by the kernel.  I tested many toolchain build combinations, using versions much like our current it worked, but any bump in the glibc and gcc it crashed.

So, if you are playing along at home, here are some clues ...

Looking at initrd sizes:

Current:
eglibc 2.18, binutils 2.22, gcc 4.8.3
initrd.img size: 2658045

Testing:
glibc 2.27, binutils 2.29.1, gcc 6.5.0
initrd.img size: 4001609


OK, I'll end the suspense, the problem is the kernel has a limit of the ramdisk size allowed, which needed to be increased.

This kernel change:
-CONFIG_BLK_DEV_RAM_SIZE=8192
+CONFIG_BLK_DEV_RAM_SIZE=16384

Or, passing ramdisk_size=16384 via the KCMD in the .run.conf

allows the new initrd to run.

The resulting astlinux image also runs, though bigger in size:

Current:
eglibc 2.18, binutils 2.22, gcc 4.8.3
astlinux.tar.gz size: 50851434

Testing:
glibc 2.27, binutils 2.29.1, gcc 6.5.0
astlinux.tar.gz size: 53732464

Note that the astlinux.tar.gz contains two copies of glibc, one in the initrd and one in the run-image.

More size info:

Current:
eglibc 2.18, binutils 2.22, gcc 4.8.3
# ls -l /lib/*so
-rwxr-xr-x    1 root     root        120224 Mar 31 17:00 /lib/ld-2.18.so
-rwxr-xr-x    1 root     root       1525336 Mar 31 17:00 /lib/libc-2.18.so
-rwxr-xr-x    1 root     root         30856 Mar 31 17:00 /lib/libcrypt-2.18.so
-rwxr-xr-x    1 root     root         14528 Mar 31 17:00 /lib/libdl-2.18.so
-rwxr-xr-x    1 root     root        993504 Mar 31 17:00 /lib/libm-2.18.so
-rwxr-xr-x    1 root     root         76608 Mar 31 17:00 /lib/libnsl-2.18.so
-rwxr-xr-x    1 root     root         22728 Mar 31 17:00 /lib/libnss_dns-2.18.so
-rwxr-xr-x    1 root     root         43384 Mar 31 17:00 /lib/libnss_files-2.18.so
-rwxr-xr-x    1 root     root        140676 Mar 31 15:01 /lib/libpthread-2.18.so
-rwxr-xr-x    1 root     root         76400 Mar 31 17:00 /lib/libresolv-2.18.so
-rwxr-xr-x    1 root     root         31512 Mar 31 17:00 /lib/librt-2.18.so
-rwxr-xr-x    1 root     root         10472 Mar 31 17:00 /lib/libutil-2.18.so

Testing:
glibc 2.27, binutils 2.29.1, gcc 6.5.0
# ls -l /lib/*so
-rwxr-xr-x    1 root     root        157352 Apr  8 23:06 /lib/ld-2.27.so
-rwxr-xr-x    1 root     root       1767720 Apr  8 23:06 /lib/libc-2.27.so
-rwxr-xr-x    1 root     root         39064 Apr  8 23:06 /lib/libcrypt-2.27.so
-rwxr-xr-x    1 root     root         14584 Apr  8 23:06 /lib/libdl-2.27.so
-rwxr-xr-x    1 root     root       1648920 Apr  8 23:06 /lib/libm-2.27.so
-rwxr-xr-x    1 root     root         84752 Apr  8 23:06 /lib/libnsl-2.27.so
-rwxr-xr-x    1 root     root         22712 Apr  8 23:06 /lib/libnss_dns-2.27.so
-rwxr-xr-x    1 root     root         47432 Apr  8 23:06 /lib/libnss_files-2.27.so
-rwxr-xr-x    1 root     root       2389056 Apr  8 21:54 /lib/libpthread-2.27.so
-rwxr-xr-x    1 root     root         80528 Apr  8 23:06 /lib/libresolv-2.27.so
-rwxr-xr-x    1 root     root         31552 Apr  8 23:06 /lib/librt-2.27.so
-rwxr-xr-x    1 root     root         10464 Apr  8 23:06 /lib/libutil-2.27.so

You might ask why use glibc 2.27 vs. glibc 2.28 ?  OpenWrt uses 2.27, as many compatibility changes occur in 2.28 which would require additional package patches to fix.  It seems reasonable to stick with glibc 2.27 for compatibility with older packages.

Finally, do you see the potential problem here ?  If you said "revert-to-previous to 1.3.8 (or earlier) will not work" you would be correct.  Since we only have one initrd.img file (not a separate initrd.img for each run-image, a revert-to-previous would use the newer initrd.img with the older kernel config ... crash.  Possibly we could create a temporary fix for that by automatically passing ramdisk_size=16384 to the kernel command line, at least with kernel-reboot.

Lonnie