1 2 Previous Next 22 Replies Latest reply on Feb 23, 2009 6:20 AM by 511303 Go to original post
      • 15. Re: Problems after removing glibc-* RedHat EL5
        511303
        Matosh, I am not sure I can follow you.
        Matosh wrote:
        On HDD under /root I have downloaded before removing glbic-* a file called:
        glibc-2.5-24.src.rpm
        This one is a source file, can I use it in command?:
        # rpm -ivh /mntsysimage/root/glibc-2.5-24.src.rpm
        No, that's SOURCE rpm. You need binary glibc rpm.
        Does that schedule is fine?
        1. starting linux in rescue mode - I have RedHat DVD installation
        2. after getting into shell mode I will execute:
        # rpm -ivh /mntsysimage/root/glibc-2.5-24.src.rpm
        3. make a restart of server and pray ;)
        right?
        Holly Mary! Pray for what? No, that schedule will not work. You need glibc binary rpm package. Matosh, please. Boot in rescue mode, get the shell, then

        # chroot /mnt/sysimage

        and, if this succeeds, see whether or not you have busybox installed (it is just one executable). Type

        # busybox

        and see what happens. Then tell me

        1. have you busybox installed or not?

        2. if answer is NO, can you download busybox and glibc from ULN using another machine, extract busybox executable from rpm package, and then save that executable (not rpm package) and glibc binary rpm package on CD? Yes or No?

        When I get your answers, I'll give you further step-by-step instructions.
        Here is screenshot when I tried mount cdrom with linux in shell of rescue mode.
        http://images38.fotosik.pl/64/603be9f8c9cefab6med.jpg
        No Matosh, you cannot mount with symlinks at the "raw stage" in rescue mode. /dev/cdrom is symbolic link to the CD/DVD device, that is /dev/hda or /dev/sda or so.

        Answer the questions above.

        NJ
        • 16. Re: Problems after removing glibc-* RedHat EL5
          675190
          After getting into shell I typed:

          chroot /mnt/sysimage

          and got:

          chroot: cannot run command '/bin/sh': Exec format error

          So seems to be not going well..
          • 17. Re: Problems after removing glibc-* RedHat EL5
            511303
            Matosh wrote:
            After getting into shell I typed:
            chroot /mnt/sysimage
            and got:
            chroot: cannot run command '/bin/sh': Exec format error
            Oh, God, you don't even have static bash (chroot calls /bin/sh if no command is given). With static bash you could easily

            # chroot /mnt/sysimage /bin/bash-static

            OK. Never mind. Now, from the same rescue shell, try
            # chroot /mnt/sysimage /sbin/busybox 
            to make sure the busybox is installed. If you get the error message:

            "chroot: cannot run command `busybox': No such file or directory"

            then busybox is not installed on your damaged system (/mnt/sysimage). Don't be confused with the fact that "in-memory" version of busybox command exists in rescue mode. It is for anaconda and you cannot do anything with it. Besides, it is dynamically linked version (needs shared libs) and works only outside root environment (glibc is not relocatable).

            Note that you must have on CD 3 binary rpm packages for 64-bit OEL:
            glibc-2.5-24.i686.rpm
            glibc-2.5-24.x86_64.rpm
            glibc-common-2.5-24.x86_64.rpm
            plus the extracted executable from
            busybox-1.2.0-4.el5.x86_64.rpm
            if it is not already installed.

            This file is a must-have as it is statically linked and doesn't depend on shared libs. The easiest way to extract an individual file from an rpm package without installing the rpm (using another machine, of course), is by using Midnight Commander (mc). If you don't have it, use rpm2cpio:
            # rpm2cpio busybox-1.2.0-4.el5.x86_64.rpm | cpio -idv ./sbin/busybox
            and busybox executable will be found in the ./sbin directory relative to the current directory (subdirectory).

            Then burn the CD with those glibc packages and busybox executable (if not already installed).

            Let me know what you did.

            NJ
            • 18. Re: Problems after removing glibc-* RedHat EL5
              511303
              Matosh,

              I've just noticed on your screenshot
              http://images38.fotosik.pl/64/603be9f8c9cefab6med.jpg
              the error message:

              "wrong ELF class: ELFCLASS32"

              that tells me the lsusb program from /mnt/sysimage/sbin (that is in PATH) is trying to use a library (libusb-0.1.so.4) that was compiled for 32-bit architecture. That could mean that you are using the 1st Installation CD of 32-bit OEL to boot in rescue mode. It doesn't work. It must be 64-bit.

              NJ
              • 19. Re: Problems after removing glibc-* RedHat EL5
                511303
                In addition to my last post. The error message you got trying to chroot
                chroot: cannot run command '/bin/sh': Exec format error
                regardless of the fact that it wouldn't succeed anyway because of missing libs, confirms my suspicion of wrong architecture (not valid executable format!). Make sure that the DVD which has been used to boot in rescue mode contains the same minor OEL-5 version (eg. 5.2) as your damaged system and is built for the same architecture.

                As it seems you are using usb DVD plugged in one usb port, why don't you ask your sysadmin for its name? The most important thing when it comes to usb interface is to know device's BLOCK NAME, usually being found in the /dev directory (ls must show brw-, not crw- that is character raw device). The "problem" with usb devices is that its block names are shown only when device is plugged in usb port, and not shown if it is not, although the usb interface itself is already properly detected and setup. The things like searching dmesg output, /dev, /dev/usb, /etc/fstab, /etc/mtab, /proc/devices, /proc/bus/usb or so, will not be of too much help as long as device is not mounted. Even `ls -l /dev | grep usb', that can show several usb device "names", shows in fact its character raw device names counterparts. When I plug a memory stick in one usb port of a machine where names sda, sdb and sdc are already assigned to 3 SATA HDDs, its block name appears as /dev/sdd1. On another machine with 2 SATA drives, the same stick is named /dev/sdc1. On a machine with all ATA HDDs, it appears as /dev/sda1. Try

                # tail -f /mnt/sysimage/var/log/messages

                from the rescue shell to see if you can recognize the block name. Then you can easily mount it, eg:

                # mount /dev/sdd1 /temporary

                Apart from that, I have an alternative idea to solve your problem with glibc: copying lib files from rescue environment to your root environment. From rescue shell type
                # cp -ru /mnt/runtime/lib /mnt/sysimage
                # cp -ru /mnt/runtime/usr/lib /mnt/sysimage/usr  
                In the case of 64-bit architecture, you must also copy lib64 libraries in addition:
                # cp -ru /mnt/runtime/lib64 /mnt/sysimage
                # cp -ru /mnt/runtime/usr/lib64 /mnt/sysimage/usr  
                This should be enough for bash and rpm binaries in your root environment to work. I believe that command
                # chroot /mnt/sysimage
                now succeeds and your original rpm can work. Now you should try to mount DVD, this time from your root environment, and perform full glibc installation from the DVD (rpm -i). Or, if you cannot mount DVD, you can try to restart and boot system normally as basic glibc files now exist. I believe the system is going to boot successfully, certainly with some error messages and warnings, but you should be able to mount DVD in normal way and install glibc from the DVD or using yum.

                Once again - make sure that the DVD contains the same OEL-5 version as your system and is built for the same architecture.


                NJ
                • 20. Re: Problems after removing glibc-* RedHat EL5
                  TommyReynolds-Oracle
                  No, using a .src.rpm will not work for this; the files in it need to be compiled and all sorts of stuff.

                  Use a binary RPM, either .i386.rpm or .x86_64.rpm depending on your architecture.

                  Be sure to use the "rpm -i" command and not the "rpm -U" command; an update (-U) first deletes an existing version...

                  As long as you can ls(1) the RPM file from the rescue mode shell prompt, you do not need to mount anything.

                  HTH
                  • 21. Re: Problems after removing glibc-* RedHat EL5
                    511303
                    Use a binary RPM, either .i386.rpm or .x86_64.rpm depending on your architecture.
                    Yes, but where to find the package? It doesn't exist on system! He has a source rpm, not binary rpm. Even if he had it, how to install it? Nothing works! The /bin/rpm, /bin/bash, /bin/ls, everything... in his rescue root environment (/mnt/sysimage) do not work because of missing libraries, and he has no statically linked counterparts.
                    Be sure to use the "rpm -i" command and not the "rpm -U" command; an update (-U) first deletes an existing version...
                    There is not an existing version! He destroyed everything. And which rpm to use? There are two environments in rescue mode: (1) rescue's "raw stage root" environment, and (2) rescue's "system root" environment accessible by `chroot /mnt/sysimage' setting the new root. He can neither `chroot', nor use rpm from rescue's raw stage root, as glibc is not relocatable to /mnt/sysimage from the raw stage root environment.
                    As long as you can ls(1) the RPM file from the rescue mode shell prompt, you do not need to mount anything.
                    ??? He cannot ls the rpm because the rpm doesn't exist. He doesn't have it on system. He thought he had it, but it was a .src.rpm.

                    As it seems the first variant with busybox is too complicated for him (cannot mount DVD, etc), the goal is to make the /bin/bash and /bin/rpm in his system root environment worked. It can easily be done by "raw copying" the libs from rescue's raw stage root to the system root environment, as it was shown in the example in my last post.

                    It works. I've just verified this on one machine. Yes, little barmy, risky and irresponsible, but I was sure it would work. Destroyed everything (-e allmatches nodeps) just like he did. Nothing worked! Booted in rescue mode, copied the rescue's libraries to /mnt/sysimage, restarted the system successfully (some error messages and warnings!), and then performed the full glibc installation from CD. The picture is the same as before - no orphan files in lib directories! Everything works again like Swiss Watch.

                    The whole procedure took me less than 15 minutes.

                    NJ

                    Edited by: NJ on Feb 22, 2009 2:35 PM
                    • 22. Re: Problems after removing glibc-* RedHat EL5
                      511303
                      Matosh,

                      just a correction. It is not necessary to copy all the content of /mnt/runtime/usr/lib and /mnt/runtime/usr/lib64, just their gconv subdirectories.

                      For 32-bit arch
                      # cp -ru /mnt/runtime/lib /mnt/sysimage
                      # cp -ru /mnt/runtime/usr/lib/gconv /mnt/sysimage/usr/lib
                      For 64-bit arch
                      # cp -ru /mnt/runtime/lib64 /mnt/sysimage
                      # cp -ru /mnt/runtime/usr/lib64/gconv /mnt/sysimage/usr/lib64
                      NJ
                      1 2 Previous Next