[gobolinux-users] Sawn my own legs off

[Michael Homer]

On 7/11/07, Jeremy Visser <jeremy.visser at gmail.com> wrote:
> In the process of attempting to upgrade Util-Linux, I seem to have sawn
> my own legs off by disabling Glibc, thus breaking my system.
>
> I was getting lots of errors trying to compile Util-Linux. In
> particular, the _IOR macros were breaking for some reason. I fixed most
> of those by changing them to _IOR_BAD.
>
> However, I gave up halfway through and decided I would downgrade Glibc
> from 2.5 to 2.4 and see if that fixed the errors without me having to
> strangle with the Util-Linux source code myself.
>
> I then typed "sudo DisableProgram Glibc 2.5". That was the last working
> command that I've typed on my GoboLinux install. Everything is broken
> now, even the trusty BusyBox executable I've kept in the root.
>
> I found that Carlo Calica wrote a program called 'RescueSymlinkProgram'.
> I though I'd try that program, but his website is down. (I've sent him
> an email in the meantime about that.)
It's on the system by default (it's part of Scripts). It might help,
although you'd have to be able to get in first. And in some places it
still depends on Glibc. Whether that matters depends on how hosed the
system is.
> Would RescueSymlinkProgram fix my problem? If so, how do I get a shell
> in order to log on? Are there a few temporary manual symlinks that I can
> make in order to get BusyBox running?
>
> I can't seem to chroot in and do _anything_, because every command I try
>   to tell chroot to run, be it /busybox, or /bin/bash, or /bin/zsh, it
> comes up with 'command not found'. And yes, the symlinks aren't broken.
Just symlink Glibc in manually from another distribution/live CD (cd
/mnt/gobo/System/Links/Libraries && ln -sf
../../../Programs/Glibc/2.5/lib/* . and so for the other
directories.). You may have to delete the existing symlinks first,
since ln -f doesn't always behave as expected. Use ls
../../../Programs/Glibc/2.5/lib/* | xargs rm -f for that. That should
get things to the state where it's bootable, or at least chrootable,
and then you can SymlinkProgram Glibc 2.5 properly.

Another way around would be to put a statically-compiled (important!
Otherwise it depends on Glibc) BusyBox in there somewhere and chroot
in using it as the shell. That would be a good thing to keep around in
the root for emergencies if you like, or another live CD will do just
as well.

As a rule, DisableProgram Glibc is not ever a good idea to do. *If*
you're going back a version, use SymlinkProgram Glibc <old-version>,
but even that is liable to break things badly (everything you've
compiled against the new version will fail).
-Michael