Re: [gentoo-amd64] Re: system broken?
On 12/10/08, Duncan [EMAIL PROTECTED] wrote: OK, I just checked bugzilla and I bet it's this bug: http://bugs.gentoo.org/show_bug.cgi?id=250342 It's a problem that seems specific to the new ~arch glibc-2.9* version and the stable portage-2.1.4* series. With either ~arch portage (2.1.6 series) or masked portage (2.2_rcs), or with stable glibc-2.6* or ~arch glibc-2.8 (so previous to the latest 2.9 version), nobody has yet reported a problem, so repeating the above, it seems to require BOTH the ~arch 2.9 glibc AND the stable 2.1.4* portage. Thus, three options: 1) Upgrade portage to the 2.1.6 ~arch series 2) Downgrade glibc back to the 2.8 series or stable 3) There are code-hack workarounds reported on the bug. Note that there are a few other obscure bugs already reported on the new glibc, as well, including remote-X problems. So unless you have some burning need to run glibc 2.9, I'd choose to revert it. The bugs will be fixed in time, but it often takes awhile to track them all down and figure out and fix the problems. Try it again in three months or whatever. Hi Duncan, thanks a lot for this link! This seems to be exactly the issue I have (and also caused by the wish to have GCC 4.3). I will downgrade glibc (and gcc) to have a stable system again. Currently I'm at work, but will get back to you asap and inform you on the result. Regards, Martin
[gentoo-amd64] Re: system broken?
Ben de Groot [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 10 Dec 2008 13:09:25 +0100: Martin Herrman wrote: thanks a lot for this link! This seems to be exactly the issue I have (and also caused by the wish to have GCC 4.3). I will downgrade glibc (and gcc) to have a stable system again. Except you can't downgrade glibc. It won't work. So your best bet is to get a tarball of portage-2.1.6 (or 2.2_rc17) from someone with a functioning ~amd64 system. (I myself am stuck on ~x86 for the moment.) Well, you can, but not directly. Surely you have an emergency boot method, either (like me) a backup root partition that you snapshot from your working one periodically when you know the system's working pretty smoothly (which means you've rebooted since your last merges so you know you can), or a LiveCD of some sort, maybe a Gentoo LiveCD, maybe something else, that you can boot to and mount your broken system partitions from? That's the basis from which to start. If you don't have such an emergency boot solution, how do you expect to recover in the event you have a broken boot? When I had a problem with glibc and needed to downgrade, I simply stuck the appropriate root=/dev/whatever on the kernel command line from grub, and booted to my backup root partition. The way I'm setup, that gives me the exact working system I had at that point, and can mount either my normal or backup /home and other data partitions, so I'm still fully operational. I was able to mount my my normal root from the backup, along with my packages partition, then set ROOT= to point to the normal working partition, and emerge -K an appropriate binpkged glibc over top of the broken one. I must admit I was a bit apprehensive about it as I'd never used portage's ROOT= setting before, and after all this is glibc we're talking about, but it worked fine, and I was then able to reboot back into my normal root again. Another alternative as long as glibc isn't so broken you can't run anything, is to hand-edit the ebuild to kill the downgrade blocker bit of the script. Finally, as posted elsewhere, it's also possible to start with a stage tarball once again as a known good starting point, then emerge -- emptytree @system to get back to a current system. This is sort of the equivalent of an OS reinstall on other OSs/distributions and it works quite well. Of course, it helps if you make a backup of your /etc before you do it, so you can quickly recover overwritten config files. So there's ways to downgrade glibc. You just have to be smarter than the child-safety-locks portage has in place to prevent you from doing it inadvertently and breaking a system further, as doing so after remerging a bunch of packages thus linking them to the new glibc might do. But if you have a backup to operate from if necessary, you don't have to worry so much about breaking a system which is probably already partially broken or you'd not be having to worry about downgrading glibc. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] Re: system broken?
Martin Herrman wrote: thanks a lot for this link! This seems to be exactly the issue I have (and also caused by the wish to have GCC 4.3). I will downgrade glibc (and gcc) to have a stable system again. Except you can't downgrade glibc. It won't work. So your best bet is to get a tarball of portage-2.1.6 (or 2.2_rc17) from someone with a functioning ~amd64 system. (I myself am stuck on ~x86 for the moment.) -- Ben de Groot Gentoo Linux developer (lxde, media, desktop-misc) Gentoo Linux Release Engineering PR liaison __ [EMAIL PROTECTED] http://ben.liveforge.org/ irc://chat.freenode.net/#gentoo-media irc://irc.oftc.net/#lxde __ signature.asc Description: OpenPGP digital signature
[gentoo-amd64] Re: system broken?
Martin Herrman [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 09 Dec 2008 20:05:00 +0100: [snipped] OK, I just checked bugzilla and I bet it's this bug: http://bugs.gentoo.org/show_bug.cgi?id=250342 It's a problem that seems specific to the new ~arch glibc-2.9* version and the stable portage-2.1.4* series. With either ~arch portage (2.1.6 series) or masked portage (2.2_rcs), or with stable glibc-2.6* or ~arch glibc-2.8 (so previous to the latest 2.9 version), nobody has yet reported a problem, so repeating the above, it seems to require BOTH the ~arch 2.9 glibc AND the stable 2.1.4* portage. Thus, three options: 1) Upgrade portage to the 2.1.6 ~arch series 2) Downgrade glibc back to the 2.8 series or stable 3) There are code-hack workarounds reported on the bug. Note that there are a few other obscure bugs already reported on the new glibc, as well, including remote-X problems. So unless you have some burning need to run glibc 2.9, I'd choose to revert it. The bugs will be fixed in time, but it often takes awhile to track them all down and figure out and fix the problems. Try it again in three months or whatever. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] Re: system broken?
On Wed, Dec 10, 2008 at 2:45 PM, Duncan [EMAIL PROTECTED] wrote: Well, you can, but not directly. Surely you have an emergency boot method, either (like me) a backup root partition that you snapshot from your working one periodically when you know the system's working pretty smoothly (which means you've rebooted since your last merges so you know you can), or a LiveCD of some sort, maybe a Gentoo LiveCD, maybe something else, that you can boot to and mount your broken system partitions from? That's the basis from which to start. If you don't have such an emergency boot solution, how do you expect to recover in the event you have a broken boot? When I had a problem with glibc and needed to downgrade, I simply stuck the appropriate root=/dev/whatever on the kernel command line from grub, and booted to my backup root partition. The way I'm setup, that gives me the exact working system I had at that point, and can mount either my normal or backup /home and other data partitions, so I'm still fully operational. I was able to mount my my normal root from the backup, along with my packages partition, then set ROOT= to point to the normal working partition, and emerge -K an appropriate binpkged glibc over top of the broken one. I must admit I was a bit apprehensive about it as I'd never used portage's ROOT= setting before, and after all this is glibc we're talking about, but it worked fine, and I was then able to reboot back into my normal root again. Another alternative as long as glibc isn't so broken you can't run anything, is to hand-edit the ebuild to kill the downgrade blocker bit of the script. Finally, as posted elsewhere, it's also possible to start with a stage tarball once again as a known good starting point, then emerge -- emptytree @system to get back to a current system. This is sort of the equivalent of an OS reinstall on other OSs/distributions and it works quite well. Of course, it helps if you make a backup of your /etc before you do it, so you can quickly recover overwritten config files. So there's ways to downgrade glibc. You just have to be smarter than the child-safety-locks portage has in place to prevent you from doing it inadvertently and breaking a system further, as doing so after remerging a bunch of packages thus linking them to the new glibc might do. But if you have a backup to operate from if necessary, you don't have to worry so much about breaking a system which is probably already partially broken or you'd not be having to worry about downgrading glibc. Well, this is why I actually love Linux: you still have control over your system, no matter what happened. But.. the downside is that you need to know how things work :-) For the moment, I have chosen the most easiest way: sys-apps/portage app-admin/eselect-news app-admin/eselect added to package.keywords. That went smooth and everything seems to work again (altough it adds the number of masked packages, which is a risk). But.. I should now keep an eye on the development of glibc and portage (etc.) packages so I can get back to the stable tree again? Can it take months before gcc 4.3 and glibc 2.8 are stable? Martin
[gentoo-amd64] Re: system broken?
Martin Herrman [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Wed, 10 Dec 2008 19:53:01 +0100: For the moment, I have chosen the most easiest way: sys-apps/portage app-admin/eselect-news app-admin/eselect added to package.keywords. Note that you may wish to use a complete package atom, including version, ~cat-egory/package-0.1.2 for instance, to include all -r revisions but no other versions, when you keyword, or =cat-egory/package-0.1*, to incluse 0.1.1, 0.1.2, etc, but not 0.2.0. That way portage won't try to automatically upgrade you to ~arch forever, only for that version. That went smooth and everything seems to work again (altough it adds the number of masked packages, which is a risk). But.. I should now keep an eye on the development of glibc and portage (etc.) packages so I can get back to the stable tree again? Can it take months before gcc 4.3 and glibc 2.8 are stable? You'd have to ask toolchain or keep watch on the related bugs to see their comments, but in general, such toolchain packages can't stabilize until everything can either compile with them (ebuilds apply patches so it works), or in some cases, has other ebuild workarounds (in the worst cases, the ebuild may test for a version of gcc and die, telling the user it can't use that version, but that's for instance for cruft that won't compile with any gcc4 version at all, say). Then all those working ebuilds must themselves go stable, which is a minimum 30 day process in most cases. So indeed, it can takes months to stabilize such things. That said, I've had no problems with gcc-4.3.2 for some time now, tho part of that may be patches that are bugged but that I'm carrying locally -- they haven't been applied to the ebuilds yet, and where they are, those ebuilds may not be stable themselves yet, since I run all ~arch. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
[gentoo-amd64] Re: system broken?
Martin Herrman [EMAIL PROTECTED] posted [EMAIL PROTECTED], excerpted below, on Tue, 09 Dec 2008 15:05:36 +0100: What has happened? What to do next? Most of those errors seem to be portage itself choking. I just did an update here and had a python remerge due to new USE flag (2.5.2-r8, I'm on ~amd64). If you had a python update or remerge too, that could be it. Check and see if your python has the expat use flag and whether it's on or not. If you do and it's off, that /may/ be the problem, as I left mine on. Whether it's python or portage (I suspect one of the two, if it was glibc you'd almost certainly have far bigger problems), you'll likely not be able to remerge a good package to fix it, since portage keeps crashing. If you've been using FEATURES=buildpkg, you should be able to untar an older package version over top of your system, using basically the below procedure but using your own package rather than the tarball from the URL. If not, then use the tarball from the URL listed in the following document: Manually fixing broken portage installations http://www.gentoo.org/proj/en/portage/doc/manually-fixing-portage.xml That's for portage itself. If that's not it, try python. If you've been using FEATURES=buildpkg you should have an older package to use. If not, the bash part of portage should at least work, so you should be able to use ebuild.sh to step-by-step thru emerging python, or you can download a stage tarball, unpack it somewhere, chroot into it, quickpkg python, then untar that package over your main system using a procedure like that for portage, above. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman
Re: [gentoo-amd64] Re: system broken?
Martin Herrman wrote: Of course (using Gentoo now for a month or so), I don't have buildpkg in my config. So I used the manual on the URL you provided. It says that one should emerge portage first to get a correct system first. But when I do that, I get an error: Yeah - once you break it you get stuck with the pieces. Somebody might have a clever solution for you - if not your best best might be to find a stage3 tarball off the distribution site and unpack it somewhere. In there you'll find good (but stale) copies of anything you need. If nothing else you can install the stage3 to a directory, then set up your environment per the install guide and chroot to it. Then type quickpkg portage to generate a binary package in /var/packages (within the chroot). You can then use that binary package to reinstall portage. Best way to do that is with emerge -k, but if that doesn't work you can always just expand the tarball into your root. I'd re-emerge portage just to clean up after doing that. It could be something other than portage that is broken. If you're still able to boot and generally function, it can't be anything too critical (like glibc). I wouldn't jump the gun on my stage3 idea - somebody else might have a more clever and clean solution. However, I've cleaned up after a few disasters via partial manual reinstalls. And if you just quickpkg specific packages from your chroot you won't be overwriting files en-masse. You could also update your chroot (emerge -uD system) and then you wouldn't need to worry too much about copying over files left and right. Just be careful not to wipe out your /etc files (fstab and passwd come to mind) by copying them from the stage3.
