unmerging linux-headers and broken system
 

First of all, I do admit I did a stupid thing :). Being a debian user, thought removing kernel-headers would have beeen harmless so I unmerged it.
As the result, I cannot emerge it again, not to speak about any other program I'd like to install. Basically, nothing emerges failing with the following:
I'd appreciate any help and promise I'll be a good user next time :]

Right,I guess you missed the big red warning when unmerging that ;)

In any case, don't worry. It's easy to get back from this one using a prebuilt package.

As I am typing from an x86 box I just packaged it with quickpkg, and uploaded it to my server. All you need to do is to download this into your root fs /.

Then tar xf it. After that, you should re-emerge linux-headers (first thing), to replace my hand-made package with a legitimate Gentoo one.

http://www.jesgue.es/files/gentoo-x8...aders-3.9.tbz2

By the way, you might be interested in adding this to your make.conf, so portage automatically builds packages at least for system packages. Those packages come in handy when you break something vital.

So this would be right up there with unmerging python ?. Did that once, several years ago ....

Unmerging python is slightly worse, both practically and philosophically speaking. However, the worst thing is unmerging glibc and/or tar, that will require a livecd to recover.

Thanks for that :) I untared the usr folder to the root . However, I have no idea why but system seems to be really messed up. Look at the examples:

Yesterday, I copied over the usr directory from the official stage3 to my system being convinced it will recover the missing headers. It seems, however that I've made it more messy than before.
Is there any way-out of this except for reinstalling the whole system?

Ugh, if you did that, then I am afraid that re-installing is the fastest way out of this problem.

The fact that there's not even a valid /dev/null means that your system is horribly broken. Note that by replacing your whole /usr with the one in the stage you probably downgraded glibc. That alone is enough to turn your system into a dead boulder.

Eh, I should have waited but to tell the truth I was quite sure gentoo user-experts would have just ignored me having realized my stupidity.
I've been switching to gentoo for a while being still a noob for some matters. All the same, I want to learn but hardly, there's a way to achieve unless making mistakes :)

Thanks for your support.

Hey! we've all been there at some point, so, please, ask as much as you need, either here, at the Gentoo fora, the mailing lists, irc or wherever you feel more comfortable. Even "experts" commit mistakes from time to time ;)

That's the spirit. But next time, if you are in doubt just ask. Sometimes there's an easy way back, that is, until you give the definitive step that will make things horribly worse :)

You're very welcome.

I really wonder what broke your system, linux-headers is a system package alright and you get a big fat warning when removing it. In actuality it is used to build glibc only and should not cause havoc, at least not instantly.
Anyhow, methinks for stable Gentoo binary packages can be downloaded from attic if need arises?

And, infact - it works! I just rebooted, remounted all the partitions, mounted proc and dev and it was it.
I am still having the problem with linux-headers-3.10 but this time, the error is different and the compilation process seems to have gone few steps further. Am I right?

Your system is broken.

The first errors (the ones about your locales) are probably easily fixable by re-editing /etc/locale.gen (if needed, just to make sure it's ok), and then running "locale-gen" as root.

You must make sure that you generate the locales that portage is complaining about (en_US.UTF-8).

But the rest of errors about undefined symbols and that stuff is probably due to your toolchain being completely broken, which, as I said, is to be expected when your system binaries have been built against a toolchain that you abruptly overwrote with another one.

If you truly want to recover from this, as a learning exercise, you can look into the [url=http://tinderbox.dev.gentoo.org/]gentoo tinderbox[/u], which has prebuilt binaries for the most critical packages. You might be able to do something using those, you'll need to restore portage, glibc, gcc, binutils, coreutils, sandbox, libtool, python and probably some others.

The x86 branch is here:

http://tinderbox.dev.gentoo.org/default-linux/x86/

You can put the packages in /usr/portage/packages and use emerge -K to force installation via binary packages. Or, if that doesn't work, just use tar as before (your system can't possibly go any worse, so...).

If you get to the point where you can use "eselect" to pick the new binary toolchain, and then "emerge -e system" then that's a good start.

OK. I will give it a try in next days when I get more free time. As you said - it can't go any worse :).
Stay tuned for more ;)

I downloaded portage binary file from tinderbox, created /usr/portage/rescue dir to have all the system binaries stored.
When I emerge I'm getting

I adjusted, the PKGDIR variable to so it should be good to go.
What am I missing?

You just

I've also tried untaring. 2 dirs /usr and /etc extract from the archive. Should I copy them over?
I'm afraid, I'm stopping understanding what I am doing.

Well, let's stop and think for a moment.

That message is misleading and probably means that portage can't find the binary package. "-K" forces the usage of binary packages, so, if no binary package can be found, it fails. Admittedly the error message is a bit weird.

So, please, do this:

Note down the exact version of the package that portage is trying to emerge, then go to tinderbox and download the same exact version. After that, put it in /usr/portage/packages/sys-apps/ (sys-apps is the portage category where the package "portage" lives). If you have adjusted PKGDIR in your make.conf, then adjust this path accordingly.

After this, the emerge -K command should work.

You could untar them, but I only advice that if portage is broken beyong repair. If emerge is working we should use it instead of randomly throwing files into the fs.

Also, if you need clarification in some step, please, just ask and I'll try to explain more clearly.

shows the requested version is 2.2.7 and that corresponds to the one I'm trying to install.


Anyway. I copied the tbz archive to /usr/portage/packages/sys-apps and now it is there

I've also adjusted the /etc/make/conf PKGBUILD so portage finds the packages

But. If I emerge -K, it fails again:

Just a side note: I notice, there's a subdir under /usr/portage/packages, named "portage" with some ebuilds in it. Just a shoot: Maybe putting the tbz file there will help emerge find it?

Setting PKGDIR is not needed if you are using the default /usr/portage/packages.

Make sure you don't have a duplicated make.conf, both /etc/portage/make.conf and /etc/make.conf are valid. So, double check that.

Besides that, I'd start afresh, and do this:

If that doesn't tell you that it wants to install from binary repo (or fails at all) then something is screwed.

If your package tells you that it's masked because of CHOST, edit /usr/portage/packages/Packages (it's just a plain text file), look for the package "portage", and then for the CHOST line, then change from i486 to i686, and repeat the emerge command.

For this concrete package, this should be fine.

I don't know if it's important, but I've jus realized my portage tree lays directly under /usr/portage, so I adjusted the make.conf accordingly.

Is that correct?

I got rid of /etc/portage/make.conf just at start, so It's not duplicated.
I also noted if it's the case, emerge will notify the user when issuing any command.

Summing up: You want me to remove the whole portage tree under /usr/portage, make a new category-dir and emerge the binary file. Right?

No!

I want you to remove the contents of /usr/portage/packages/

I posted that as fast as I could to avoid a little disaster (nothing compared to the rest though). There's no need to wipe portage. And there's no need for you to put that in make.conf either. As I said, if you are using the defaults, you don't need to put them explicitly in make.conf.

/usr/portage is the default for $PORTDIR, so no need to add it.
Same goes for /usr/portage/packages for $PKGDIR and /usr/portage/distfiles for $DISTDIR.

Please, remove the contents of /usr/portage/packages, then proceed as I told you in the post above, and see if that helps at all :)

Sorry. I was close to the disaster once again.
Now, I've just adjusted PKGDIR to the default value but it seems there is no directory named packages under /usr/portage.

Under /usr/portage lays my whole "tree".
I hope I'm not missing anything obvious.

No, just create it if it doesn't exist. I have no idea if it comes by default in the standard portage tree.

Maybe it's created the first time you use quickpkg, or when you emerge a package with FEATURES="buildpkg" (or "buildsyspkg").

But you can just create it manually. Just to be sure you can do this and see where it's pointing by default.

OK. Just followed your instructions.
At first emerge would complain about the CHOST, but after changing it in Packages file it went fine (what is that file about BTW?).

Now portage shouts about python.

So I guess, I'll have to download it as binary and emerge in the same way prior to repairing portage.

You can try that. If something fails I can provide native i686 binaries. As long as they don't conflict with my installation.

As for your question, well, I admittedly no speciallist in how Gentoo handles bins, I rarelly needed that, but it seems to register some aspects on how the binaries residing there were compiled. Note that, unlike ebuilds, binary build do have an specific arch, chost, cflags, uses, etc.

Following your strategy I've made it to emerge portage :)

At first python needed sqlite so I created the right directory under /usr/portage/packages, download sqlite it and emerged. After emerging sqlite, I did the same with python and eventually, portage. All of this required manual changing chost entry in the updating Packages file.

So far so good. Seems to be good strategy to follow with the rest, right?
Hopefully. There won't be many deps to download and install.

Some packages might pose a probles, for example glibc and gcc. If you need to reinstall those let me know. don't install those from tinderbox.

in the previous post, you told me to recover: Portage and python are already ahead. I can start with binutils, coreutils,sanbox,libtool and repair glibc and gcc at the end. What do you think?

Yes, but that was before knowing that the packages in tinderbox differ from your chost.

You should use bin packages only to restore your system to a point where portage can do its job.

So, if you can already emerge packages there's no need to continue that path. Just to test, can portage re-emerge itself now?

Yes, it can :). So, is the system in working-stage now?

That's a good start, however, since the breakage was somewhat important, I'd do this:

Check the output and if there's nothing wrong go ahead. That should recompile the whole system set (it will take a while). The system set is the basic system, which is more-or-less what comes in the stage (but not exactly).

After that ends, if there's no problem, see this


See what compiler is set as system compiler (marked with an asterisk). If there's a newer one you might want to enable it. After that, if nothing fails (that'd surprise me greatly), do this to update your whole world, and ensure that everything is consistent

You were right - Too soon for claiming victory ;).

emerge -eva @system still fails.

I'll upload a bin package for binutils. It's one of these packages that won't work from another CHOST, so I am preparing one for i686. As soon as it's up I'll give you the link, then you can install like the others above.

That error might have something to do with binutils, we can't be sure though. But trying is for free.

By the way, once you install that, you can resume the last emerge operation by using "emerge --resume", as long as you didn't launch another emerge in the while.

You might also find useful to know that "emerge --resume --skipfirst" will skip the last package and continue from the next upwards.

ps. While I was writing it finished, so here you are:

http://www.jesgue.es/files/gentoo-x8...ls-2.23.2.tbz2

I emerged binutils without problems (thank you)

It seems however, the compilation fails with the same error as before.
Weird, 2 packages just emerged and it is bzip2 to crash.

Can you paste the whole contents of /var/tmp/portage/app-arch/bzip2-1.0.6-r3/temp/build.log?

Sure. Sorry about not having it done before.

The output doesn't contain any extra info, but we had to try :)

Which gcc and glibc versions do you have installed? What does gcc-config -l say?

It shows the following:

Are you suspecting gcc as a reason of the issue?

That's my same sys-devel/gcc version, so I uploaded a binary package.

If glibc is 2.17, then just pick those and install them. The sys-libs/glibc absolutely must match, so, if it's even slightly different, don't install my 2.17 package. Installing a different glibc from the stage is probably what started all of this, so be careful... Note that the "errno.h" file that appears mentioned in the bzip2 error is part of the standard glibc library, so it's very likely that the problem is due to mismatching components. If your glibc is some other version, you will need a binary package for that concrete version.

http://www.jesgue.es/files/gentoo-x8...-4.7.3-r1.tbz2
http://www.jesgue.es/files/gentoo-x8...libc-2.17.tbz2

After that, just to be sure, use "gcc-config -l" to check that that's the only compiler, and re-set it using "gcc-config 1". To be on the safe side do also this:

Then cross your fingers and try to emerge bzip2 again.

In case that doesn't work, just download this bzip2 binary, and install it. Then do the emerge -e world thing, and if bzip2 fails again just use --resume --skipfirst. Maybe you've just hit a rare bzip2 bug and the rest will compile ok.

ps. My packages are a bit big because I have debug symbols enabled. But don't worry, they won't slow down your system because the debug stuff is split from the binaries. Anyway, that will go away as soon as you are able to recompile them yourself.

I made it to install gcc. When to "libgc", it seems to be the same version. Right?

Right :)

Fails:

I'm not a programmer myself but it seems glibs complains abaou some main directories missing.
Maybe I should run from /root ?

Yes. Binary package usually don't include files under /etc for security reasons. I'll try to upload a new package soon. It'll take a bit because it's big and my upload speed is not so good.

Sure. Take your time :)

It was faster this time.

The file is up now, you can use the same link above, I overwrote the old one.

After merging this, take one minute to run etc-update, and review your /etc/locale.gen and run "locale-gen" if needed.

Thanks but here I'm loosing you again. What exactly happened? Glibc didn't merge due /etc files missing?
Shall I run the newest package from /root or under right category-dir?

It didn't merge because the glibc ebuild does something with some files that should be contained in the tarball. But in this case they were not there, because the packages created with the quickpkg tool omit some files. This is ok for most packages, but it seems it is not ok for glibc. So I repackaged it to include everYthing.

The package must be in /usr/portage/packages/sys-libs

Hmm. still fails with the same error as before
I used the link from your previous post just as you told me to.

Admittedly, now that I think about it, I never emerged a binary for glibc. I have only done it the hard way, by untaring in /. I guess that's the sanest option that you have for that package. Just

You've just made my day - Bzip2 made it! I'm now emerging the rest. So far so good :) Keep your fingers crossed.