0

I'm trying to install glibc 2.20 (built recently) to Debian using this guideline from FAQ referenced at this page (the question within FAQ is How do I install all of the GNU C Library project libraries that I just built?):

The only pedantically correct way to install these libraries is to carry out a make install INSTALLDIR=/tmp/glibc which installs the libraries to /tmp/glibc, after which you copy that directory into an initial root disk, boot the initial root disk, and copy the results to your root filesystem, and then pivot into the root filesystem as the final step of booting. That is the only safe way to install glibc today.

I have managed to copy this fresh glibc directory (which contains the product of make install) into a decompressed copy of initrd (the one which is loaded by default), compress it back and successfully boot after specifying this new initrd in GRUB by editing command line.

Could anybody tell me how and where should I copy this glibc to my root filesystem (to make it the primary C library in the system instead of the current (default) one)?

1 Answer 1

2

Your question ("how and where should I copy this glibc to my root filesystem") admits several answers, with the one mentioned in the FAQ being the one with minimum requirements (although not the simplest at all, IMHO).

What they are suggesting, once you've booted your kernel root-mounting your new initrd (and, hence, ending in a prompt like '(initramfs)' is to mount your real system somewhere below your filesystem. Supposing your real root-filesystem resides in /dev/sda1, something like:

   (initramfs) mkdir /new_root
   (initramfs) mount /dev/sda1 /new_root

After this, you will have:

  • /lib => contains the new libraries you've compiled yourself and packed within the INITRD you've used to boot and root-mount;
  • /new_root/lib => contains the old libraries still present on your hard drive, within your (not-running) real system;

(BTW: you could also have a lib64 structure aside the mentioned /lib, depending on your architecture. Please apply some common sense and sanity checks before applying what I'm writing)

At this stage, you already have all it's needed to copy the content from /lib to /new_root/lib and then simply umount /new_root and reboot.

So why they're suggesting such "magic" with pivot_root and the like?

IMHO, what they're assuming, in the FAQ, is that you want to limit the number of reboot to the minimum. One reboot is unavoidable (to boot from INITRD). Then you can mount the root-partition, copy the libraries and.... tell the system to continue booting as normal, pointing to the (new) root-file-system that you just mounted from your hard-drive. Here, the key-point is that the "root mount point" (the "/" folder, in other words) need to be replaced from the one related to the INITRD image, to the one related to your real system (/dev/sda1 partition mounted to /new_root under the INITRD filesystem).

There are several tools being able to "change root", with pivot_root being referenced in the FAQ. Here you can find a discussion about using pivot_root to switch among two linux installations. It's perfectly suitable to your case, as the two systems are the INITRD initial one and the real system on your disk.

Here you can find some information (and links) comparing pivot_root to switch_root.

Before posting this answer, I've run through some pivot_root test: unfortunatly I have been UNABLE to pivot_root, ending in various errors (BTW: it seems I'm not alone here).

Due to problems above, I've got to the conclusion that a "second reboot" is not a problem and easy the whole process.

As for other approaches, it's also possible (...and even much easier) to simply boot your linux-box with a Live-CD (like SystemRescueCD) and:

  • manually extract the (new) libraries from the INITRD;
  • replace the (old) ones in your system with aboves.

Obviously, to get access to your INITRD as well as your real system, you need to "mount" your partitions somewhere within the file-system of the live-cd (in the same way as discussed above).

As for the extraction process, let's assume your initrd is /mnt/initrd.img-3.2.0-58-generic. Let's check it's compressed:

damiano@tablet:/$ file /mnt/initrd.img-3.2.0-58-generic
/mnt/initrd.img-3.2.0-58-generic: gzip compressed data, from Unix, last modified: Wed Jan  8 11:54:03 2014

Not let's decompress it, to better check its content (we'll work in /tmp/libs directory):

damiano@tablet:/$ mkdir /tmp/libs
damiano@tablet:/$ cd /tmp/libs
damiano@tablet:/tmp/libs$ gzip -dc /mnt/initrd.img-3.2.0-58-generic > init_uncompressed
damiano@tablet:/tmp/libs$

Now let's check what's in the uncompressed file:

damiano@tablet:/tmp/libs$ file init_uncompressed 
init_uncompressed: ASCII cpio archive (SVR4 with no CRC)

Ok. So now we have a cpio archive. Extracting its content is as simple as:

damiano@tablet:/tmp/libs$ cpio -i < init_uncompressed
109835 blocchi

Now, finally, we have everything extracted, included your libs:

 damiano@tablet:/tmp/libs$ ls -l
 totale 54968
 drwxr-xr-x  2 verzulli verzulli     4096 dic 31 14:42 bin
 drwxr-xr-x  3 verzulli verzulli     4096 dic 31 14:42 conf
 drwxr-xr-x  8 verzulli verzulli     4096 dic 31 14:42 etc
 -rwxr-xr-x  1 verzulli verzulli     7230 dic 31 14:42 init
 -rw-rw-r--  1 verzulli verzulli 56235520 dic 31 14:38 init_uncompressed
 drwxr-xr-x  9 verzulli verzulli     4096 dic 31 14:42 lib
 drwxr-xr-x  2 verzulli verzulli     4096 dic 31 14:42 lib64
 drwxr-xr-x  2 verzulli verzulli     4096 dic 31 14:42 run
 drwxr-xr-x  2 verzulli verzulli     4096 dic 31 14:42 sbin
 drwxr-xr-x 10 verzulli verzulli     4096 dic 31 14:42 scripts
 drwxr-xr-x  4 verzulli verzulli     4096 dic 31 14:42 usr

At this point, you can simply copy the lib (and lib64) folder from /tmp/libs to /mnt (assuming your root partitions --/dev/sda1-- is mounted under /mnt) and then reboot.


A final (very personal) note: Having said all the above, let me add that... even though the FAQ clearly states that relying on package-managers to update system-libraries is dangerous, I personally believe that manually dealing with system-libraries on my own... it's surely more dangerous :-)

So, please, don't blame me should you run in an unbootable system ;-)


Update 1:

As for "once you've booted your kernel root-mounting your new initrd", you can proceed this way:

  1. At grub menu, select the entry you usually run and press "E" (Edit). (BTW: if you don't have a grub-menu, than this question and/or other on-line searches can help). You'll get to a screen similar to this:

enter image description here

Please note the line related to the kernel. On such line you find:

  • reference to to kernel (vmlinux-3.8.0-19-generic in my example);
  • reference to device to use to mount the root-filesystem (root=/dev/mapper/kubuntu--vg-root in my example);
  • other boot parameters ( ro quiet splace $vt_handoff )

    1. as you want to root-mount the initrd file you preparared (...containing your updated glibc; and not the common device/hard_drive/partition) you need to edit above line, replacing the reference to the "root=" parameter, as in:

enter image description here

Please note that I used root=/initrd.img-3.8.0-19-generic while you should link to your specific initrd file

  1. once you have properly defined your "root=" parameter, than simply press F10. After few seconds, you should get to the (initramfs) prompt, as in:

enter image description here

Now your "/" has a /lib folder with the libraries you compiled... and packed within the INITRD.


6
  • Thanks a lot for this answer. You write "you've booted your kernel root-mounting your new initrd (and, hence, ending in a prompt like '(initramfs)'". Could you please tell what should I do to get a prompt like (initramfs)? Jan 3, 2015 at 19:58
  • Should I use some kind of minimal initrd instead of my copy of default initrd for carrying fresh glibc? Or may be (initramfs) prompt is reachable after editing the command line in GRUB menu on boot? Jan 3, 2015 at 20:06
  • I just updated my answer to explain how to boot root-mounting your initrd. Jan 4, 2015 at 18:57
  • First, I highly appreciate your efforts. They really inspired me, even though I couldn't get a bootable system after copying these directories. By the way, in my case make install does not generate lib directory. The directories are etc, lib64, sbin, usr and var. The best I achieved so far is booting Debian live (rescue) image, then getting root shell, mounting my target filesystem, performing pivot_root, chroot . bash, and then make install in the build directory. The issue here is kernel version mismatch, since I build glibc for a newer kernel than in live image. Jan 11, 2015 at 20:14
  • It finally returns with FATAL: kernel too old, but glibc itself is updated successfully (checked by ldd --version). Though getconf -a doesn't work... Jan 11, 2015 at 21:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .