Hi all,

I'm a newbie, so please bear with me.
I'm using a NAS, which runs a Debian system, which utilizes BusyBox.
I tried to apt-get install a package, which in turn tried to upgrade libc6.
This hangs due to a call to BusyBox's "init" with the "u" command -
something the BusyBox init does not support, afaik.

If you cook the process down to installing a new libc6 the output looks like:

----------------8<------------------- snip
--------------------------------------
r...@nas:/> apt-get install libc6
Reading package lists... Done
Building dependency tree
Reading state information... Done
Suggested packages:
  locales glibc-doc
The following packages will be upgraded:
  libc6
1 upgraded, 0 newly installed, 0 to remove and 37 not upgraded.
1 not fully installed or removed.
Need to get 4860kB of archives.
After this operation, 0B of additional disk space will be used.
Get:1 http://security.debian.org stable/updates/main libc6 2.7-18lenny6 [4860kB]
Fetched 4860kB in 5s (862kB/s)
Preconfiguring packages ...
(Reading database ... 7289 files and directories currently installed.)
Preparing to replace libc6 2.7-18lenny4 (using
.../libc6_2.7-18lenny6_armel.deb) ...
Unpacking replacement libc6 ...
Setting up libc6 (2.7-18lenny6) ...
BusyBox v1.12.4 (2009-01-02 13:15:21 KST) multi-call binary

Usage: init

Init is the parent of all processes
---------------->8------------------- snip
--------------------------------------

The installation procedure hangs at this point, as (BusyBox) init is
running in the foreground and does not return.
The postinstall script of libc6 does the following (among other things):

----------------8<------------------- snip
--------------------------------------
if [ "`uname -s`" = Linux ]; then
#
#       Upgrade init if possible. There was a bug in all versions
#       up to and including 2.75-4, which didn't affect i386 but
#       did affect most other architectures.
#
sysvinitver="`dpkg -s sysvinit 2>/dev/null | grep ^Version: | sed -e
's/^Version: *//'`"
case "`uname -m`" in
        i?86)
                badsysvinitver="2.[0-6]*|2.7[0-3]*"
                ;;
        *)
                badsysvinitver="2.[0-6]*|2.7[0-4]*|2.75-*"
                ;;
esac
# Black magic. If we are in a chroot, then /proc/1/exe will not resolve to
# a file (will return EPERM). This keeps us from breaking things in
# debootstrap, and the like.
case "$sysvinitver" in
        $badsysvinitver)
                ;;
        *)
                if [ "$(stat -c %d/%i /)" = "$(stat -Lc %d/%i
/proc/1/root 2>/dev/null)" ]; then
                        # the devicenumber/inode pair of / is the same
as that of /sbin/init's
                        # root, so we're *not* in a chroot
                        (init u ; sleep 1)
                fi
                ;;
esac
fi
---------------->8------------------- snip
--------------------------------------

It's the "init u" call that causes the whole thing to hang.

Now I'd like to know whether I can safely skip this step, for instance
by commenting the whole if [ "`uname -s`" = Linux ]; then ... fi
block, as this tries to deal with sysvinit.
I'd be happy to receive any hints (even if it would be "You just shot
your system to pieces by this misguided attempt to update libc6 -
you'll have to reinstall the firmware").

Kind regards
  Andreas
_______________________________________________
busybox mailing list
[email protected]
http://lists.busybox.net/mailman/listinfo/busybox

Reply via email to