[gentoo-user] Re: how to recover a portage that wasn't in use for very long time
Alexey Luchko wrote: colinux ~ # emerge portage --pretend --tree These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] sys-apps/portage-2.1.6.11 [2.1.2.2] [ebuild U ] app-shells/bash-3.2_p39 [3.1_p17] USE=-examples% -plugins% [ebuild U ] sys-apps/portage-2.1.6.11 [2.1.2.2] [ebuild U ] dev-python/pycrypto-2.0.1-r6 [2.0.1-r5] [ebuild U ] sys-apps/sandbox-1.6-r2 [1.2.17] [ebuild N] app-arch/lzma-utils-4.32.7 USE=-nocxx [ebuild N] app-admin/eselect-news-20080320 [ebuild U ] app-admin/eselect-1.0.11-r1 [1.0.7] USE=-vim-syntax% [ebuild U ] app-misc/pax-utils-0.1.19 [0.1.15] [blocks B ] sys-apps/portage-2.1.5 (is blocking app-shells/bash-3.2_p39) colinux ~ # Hi! Thank every one for your help. Finally I got it out this way: first emerge --nodeps bash then emerge portage upgraded portage to the latest version and then, of cause, emerge -uDN system -pvt it had blocked packages [blocks B ] sys-apps/man-pages-3 (sys-apps/man-pages-3 is blocking sys-apps/man-pages-posix-2003a) [blocks B ] sys-fs/e2fsprogs-1.41 (sys-fs/e2fsprogs-1.41 is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-apps/mktemp (sys-apps/mktemp is blocking sys-apps/coreutils-7.1) [blocks B ] sys-libs/com_err (sys-libs/com_err is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-apps/util-linux-2.13 (sys-apps/util-linux-2.13 is blocking sys-apps/coreutils-7.1) [blocks B ] sys-libs/ss (sys-libs/ss is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) I unmerged them, and then emerge -uDN system had been working fine until sys-libs/e2fsprogs-libs-1.41.3-r1 compilation failed with ../../lib/libuuid.so: undefined reference to `___tls_get_addr' I had no separate uuid package installed colinux ~ # emerge --search uuid | less Searching... [ Results for search key : uuid ] [ Applications found : 4 ] * dev-libs/ossp-uuid [ Masked ] Latest version available: 1.6.2 Latest version installed: [ Not Installed ] * dev-perl/Data-UUID Latest version available: 1.148 Latest version installed: [ Not Installed ] * dev-python/uuid [ Masked ] Latest version available: 1.30 Latest version installed: [ Not Installed ] * dev-ruby/uuidtools Latest version available: 1.0.7 Latest version installed: [ Not Installed ] It claimed on /usr/tmp/portage/sys-libs/e2fsprogs-libs-1.41.3-r1/work/e2fsprogs-libs-1.41.3/lib/libuuid.so I checked whether the name tls_get_addr exists and found nothing colinux e2fsprogs-libs-1.41.3 # pwd /usr/tmp/portage/sys-libs/e2fsprogs-libs-1.41.3-r1/work/e2fsprogs-libs-1.41.3 colinux e2fsprogs-libs-1.41.3 # grep tls_get_addr `find . -iname '*.c'` After seaching tls_get_addr on http://www.google.com/codesearch I decided to update glibc first: colinux ~ # emerge glibc -pvt These are the packages that would be merged, in reverse order: Calculating dependencies... done! [ebuild U ] sys-libs/glibc-2.8_p20080602-r1 [2.3.6-r4] USE=-debug% -gd% -glibc-omitfp (-hardened) (-multilib) -nls* -profile (-selinux) -vanilla% (-build%) (-erandom%) (-glibc-compat20%) (-nptl%) (-nptlonly%) 0 kB [?=0] Total: 1 package (1 upgrade), Size of downloads: 0 kB Portage tree and overlays: [0] /usr/portage [?] indicates that the source repository could not be determined * IMPORTANT: 1 news items need reading for repository 'gentoo'. * Use eselect news to read news items. colinux ~ # emerge glibc * i386 CHOSTs are no longer supported. * Chances are you don't actually want/need i386. * Please read http://www.gentoo.org/doc/en/change-chost.xml Here I've decided to make yet another backup and tried to remount / readonly. And found the mount missing. I'm guessing that util-linux is the package containing mount and it depends on e2fsprogs-libs-1.41.3-r1. Here I am now ;) Any advice is welcome! Alexey.
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Wednesday 13 May 2009 12:03:40 Alexey Luchko wrote: Alexey Luchko wrote: colinux ~ # emerge portage --pretend --tree These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] sys-apps/portage-2.1.6.11 [2.1.2.2] [ebuild U ] app-shells/bash-3.2_p39 [3.1_p17] USE=-examples% -plugins% [ebuild U ] sys-apps/portage-2.1.6.11 [2.1.2.2] [ebuild U ] dev-python/pycrypto-2.0.1-r6 [2.0.1-r5] [ebuild U ] sys-apps/sandbox-1.6-r2 [1.2.17] [ebuild N] app-arch/lzma-utils-4.32.7 USE=-nocxx [ebuild N] app-admin/eselect-news-20080320 [ebuild U ] app-admin/eselect-1.0.11-r1 [1.0.7] USE=-vim-syntax% [ebuild U ] app-misc/pax-utils-0.1.19 [0.1.15] [blocks B ] sys-apps/portage-2.1.5 (is blocking app-shells/bash-3.2_p39) colinux ~ # Hi! Thank every one for your help. [snip long sad story of portage blockers] Here I am now ;) Any advice is welcome! Why are you doing this? Is it to learn how to cope with such things? If not, you are really wasting time that you will never get back. The last 18 months has seen much activity in the tree, lot's of it from large packages being split into smaller ones, and blockers installed. You've already come across mktemp/coreutils and e2fsprogs. You still have to deal with bash/python then that delicious recent cock-up with wget, expat and you have to decide if you want com_err or not. And plenty more. This all happened so long ago I forget the details (lucky for you it's all in the mail archives!). Trust me, if this is not a learning exercise, just unmount your data volumes and reinstall the machine. The pain is not worth it. Really. Especially if glibc decides it doesn't like your headers, then you really are up the creek if you didn't quickpkg critical apps in the system set first :-) -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On 13 May 2009, at 11:17, Alan McKinnon wrote: ... Why are you doing this? Is it to learn how to cope with such things? If not, you are really wasting time that you will never get back. ... Trust me, if this is not a learning exercise, just unmount your data volumes and reinstall the machine. The pain is not worth it. Really. ... I'm inclined to disagree with you here. Obviously, it depends on the user - as I've undertaken this, I knew not to bother asking here because I knew I'd receive exactly this response. I examined ebuilds to see the blockers looked up compatible versions in the portage attic, and I did my own searches when I came to problems like this one. And so far I've been ok. In my case, reinstallation would be a huge pain. I would be massively worrying about which services on the machine I need to configure again, and whether everything I needed had been backed up properly. I have forgotten the original procedures I followed setting up many of these services, and it could easily take a week to set the machine up from scratch. If I upgrade the obsolete portage incrementally, I know that everything is still working, and I update the machine without disruption to the users who depend upon the machine. If a service fails during the procedure, then it is only ONE service that I have to fix, not several. As I upgrade a package run etc-update I can back up the original config files, and if I find the new ones are vastly different then I can refer to the originals /or diff them in. If this upgrade procedure is undertaken cautiously, then it is no worse or different than it was when the changes originally entered the portage tree. One can `emerge -pv world` and then emerge the first package with --oneshot, rinse repeat. Sure, this is potentially time- consuming, but I can leave packages compiling whilst I'm doing other things - reinstalling from scratch a base Gentoo installation isn't too bad (hardware, logger, housekeeping), but once you add in a number of services then I'm going to need to dedicate some time to the job. I'm not reading Alexey too clearly, but it seems to me that he is saying he has a full system backup. In this case one can restore to that in minutes if something goes hosed badly during an emerge or if the users come in the next morning complain that $facility isn't working. I'm NOT saying that this procedure is for everyone, but equally I don't think it's fair to say there's NEVER any justification for it. Stroller.
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Wednesday 13 May 2009 16:16:10 Stroller wrote: In my case, reinstallation would be a huge pain. I would be massively worrying about which services on the machine I need to configure again, and whether everything I needed had been backed up properly. I have forgotten the original procedures I followed setting up many of these services, and it could easily take a week to set the machine up from scratch. But whether you reinstall (backing up and replacing old configs then runnign diff of course) or incrementally upgrade, and $SERVICE breaks, either way you equally do not know about it till $USER complains. It's just that I remember all too well what it took to get through those many various blockers. More often than not I was once of the first to run into them - I sync and update daily - but I'd hate to do it all again all in one go, especially when all my buddies here have forgotten the procedure. Horses for courses I guess. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On 13 May 2009, at 11:03, Alexey Luchko wrote: Alexey Luchko wrote: colinux ~ # emerge portage --pretend --tree These are the packages that would be merged, in reverse order: Calculating dependencies... done! [nomerge ] sys-apps/portage-2.1.6.11 [2.1.2.2] [ebuild U ] app-shells/bash-3.2_p39 [3.1_p17] USE=-examples% - plugins% [ebuild U ] sys-apps/portage-2.1.6.11 [2.1.2.2] [ebuild U ] dev-python/pycrypto-2.0.1-r6 [2.0.1-r5] [ebuild U ] sys-apps/sandbox-1.6-r2 [1.2.17] [ebuild N] app-arch/lzma-utils-4.32.7 USE=-nocxx [ebuild N] app-admin/eselect-news-20080320 [ebuild U ] app-admin/eselect-1.0.11-r1 [1.0.7] USE=-vim- syntax% [ebuild U ] app-misc/pax-utils-0.1.19 [0.1.15] [blocks B ] sys-apps/portage-2.1.5 (is blocking app-shells/ bash-3.2_p39) colinux ~ # Hi! Thank every one for your help. Finally I got it out this way: first emerge --nodeps bash then emerge portage upgraded portage to the latest version and then, of cause, emerge -uDN system -pvt it had blocked packages [blocks B ] sys-apps/man-pages-3 (sys-apps/man-pages-3 is blocking sys-apps/man-pages-posix-2003a) [blocks B ] sys-fs/e2fsprogs-1.41 (sys-fs/e2fsprogs-1.41 is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-apps/mktemp (sys-apps/mktemp is blocking sys-apps/coreutils-7.1) [blocks B ] sys-libs/com_err (sys-libs/com_err is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) [blocks B ] sys-apps/util-linux-2.13 (sys-apps/util- linux-2.13 is blocking sys-apps/coreutils-7.1) [blocks B ] sys-libs/ss (sys-libs/ss is blocking sys-libs/e2fsprogs-libs-1.41.3-r1) I unmerged them, and then emerge -uDN system had been working fine until sys-libs/e2fsprogs-libs-1.41.3-r1 compilation failed with ../../lib/libuuid.so: undefined reference to `___tls_get_addr' Alexey, I think `emerge --nodeps bash` was the cause of your problem. You need to resolve each and every dependency - often sequentially or incrementally - before you go on to the next package. --nodpes is just asking your system to break. I gave you advice in my previous message - you should have emerged earlier versions of packages in order, for the reason to avoid blockers. The Gentoo devs had a GOOD REASON when they declared bash-3.2_p39 as blocking the current portage. If you had tried to emerge the earlier bash you would probably have found it blocked by an earlier portage /or mktemp /or com_err /or util-linux /or sys-libs/ ss. If you had resolved each dependency in turn you would have eventually been able to upgrade to the latest versions. I know this, because last month I did this myself. A system last upgraded in August or September 2007 now has bash-3.2_p39 and portage-2.1.6.4 installed on it. If you don't have the patience for this, then do as Alan says reinstall the whole system. If you don't understand what I wrote, then just ask. If you want to upgrade this system then you're going to have to do a lot of work yourself. You WILL need to get older intermediate package versions from the CVS attic http://sources.gentoo.org/ and you will need to Google read the list archive to see the correct procedure for resolving the mktemp, com_err, util-linux sys-libs/ss problems. But that really is pretty straightforward - it is clearly documented on the list emerge version X of this, then version Y of that. Stroller.
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On 13 May 2009, at 15:27, Alan McKinnon wrote: ... It's just that I remember all too well what it took to get through those many various blockers. More often than not I was once of the first to run into them - I sync and update daily - but I'd hate to do it all again all in one go, especially when all my buddies here have forgotten the procedure. I think it does help if one upgrades a week or two after everyone else. I upgrade my main systems only every 4 - 12 weeks, and whenever I have a problem I look in the list archives and a clear upgrade procedure has most always been described. I upgraded a 2007 system to current only a few weeks ago, and I encountered ALL the portage, mktemp, com_err, util-linux sys-libs/ss problems. Honestly, it was not so bad. All these problems were clearly documented on the list - perhaps by yourself! - and I was able to overcome all of them in the course of an afternoon. The system was down for a couple of hours because I was hasty impatient at one point, but in my case the significant cause of delays was that the machine is an old Duron 800mhz took time with its compilation. With a faster machine I could perhaps have done all these upgrades within an hour. Grabbing old versions of ebuilds from the attic is a bit of a pain, you wget them, rename them, copy them into /usr/local/portage, create the manifest and it's only when you try to emerge them that you find you also need a .patch file. But all these blockers are overcome just by upgrading the various packages in a straight-forward order. I reread Alexey's post after replying to yours, and the reason he's having problems is because he's being careless. If you break the system, it's obviously a gamble whether you'll get your ass out of the problem you created for yourself. If you want to be sure of not breaking the system then you have to be cautious, resolve EACH and EVERY dependency in turn and not just go fukkit, i don't know what that package does so, i'll ignore or unmerge it, upgrade this other package to the latest version and hope everything resolves. Stroller.
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Wednesday 13 May 2009 16:49:52 Stroller wrote: I reread Alexey's post after replying to yours, and the reason he's having problems is because he's being careless. If you break the system, it's obviously a gamble whether you'll get your ass out of the problem you created for yourself. If you want to be sure of not breaking the system then you have to be cautious, resolve EACH and EVERY dependency in turn and not just go fukkit, i don't know what that package does so, i'll ignore or unmerge it, upgrade this other package to the latest version and hope everything resolves. Very true. I see he's got the bash/portage mutual blocker one as well. Nasty one that - only by close study of the ebuilds did I manage to figure out that - upgrade bash to interim version in the tree - upgrade portage to latest - upgrade bash to latest was the only way through. In those days we didn't have automatic blocker resolution in portage either. And yes, if Alexey is being careless then portage is going to bite his ass. Alexey, if you read this: Do not unmerge bash, portage, wget or python without first making a quickpkg. Otherwise you will be left with an unusable system and no way out of it - portage uses those packages directly and cannot function without them. -- alan dot mckinnon at gmail dot com
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Wed, May 13, 2009 at 10:00 AM, Alan McKinnon alan.mckin...@gmail.com wrote: On Wednesday 13 May 2009 16:49:52 Stroller wrote: I reread Alexey's post after replying to yours, and the reason he's having problems is because he's being careless. If you break the system, it's obviously a gamble whether you'll get your ass out of the problem you created for yourself. If you want to be sure of not breaking the system then you have to be cautious, resolve EACH and EVERY dependency in turn and not just go fukkit, i don't know what that package does so, i'll ignore or unmerge it, upgrade this other package to the latest version and hope everything resolves. Very true. I see he's got the bash/portage mutual blocker one as well. Nasty one that - only by close study of the ebuilds did I manage to figure out that - upgrade bash to interim version in the tree - upgrade portage to latest - upgrade bash to latest was the only way through. In those days we didn't have automatic blocker resolution in portage either. And yes, if Alexey is being careless then portage is going to bite his ass. Alexey, if you read this: Do not unmerge bash, portage, wget or python without first making a quickpkg. Otherwise you will be left with an unusable system and no way out of it - portage uses those packages directly and cannot function without them. buildsyspkg in FEATURES (make.conf) can be a life saver too :)
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
Paul Hartman paul.hartman+gen...@gmail.com writes: buildsyspkg in FEATURES (make.conf) can be a life saver too :) But it does not (IMHO) save binaries for enough packages. For example, it saves a binary for portage but not for python. I think it would be good if it saved a binary package for everything which would be built in stage-1, which would provide a much better 'get out of jail free' if a critical package gets corrupted or fails to run.
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Wed, May 13, 2009 at 10:30 AM, Graham Murray gra...@gmurray.org.uk wrote: Paul Hartman paul.hartman+gen...@gmail.com writes: buildsyspkg in FEATURES (make.conf) can be a life saver too :) But it does not (IMHO) save binaries for enough packages. For example, it saves a binary for portage but not for python. I think it would be good if it saved a binary package for everything which would be built in stage-1, which would provide a much better 'get out of jail free' if a critical package gets corrupted or fails to run. That's true, I didn't think of that before. Thankfully I have never needed to use it, but I keep it enabled as a security blanket.
Re: [gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Wed, 13 May 2009 16:30:09 +0100, Graham Murray wrote: buildsyspkg in FEATURES (make.conf) can be a life saver too :) But it does not (IMHO) save binaries for enough packages. Then use buildpkg. -- Neil Bothwick It's only a hobby ... only a hobby ... only a signature.asc Description: PGP signature
[gentoo-user] Re: how to recover a portage that wasn't in use for very long time
On Sunday 10 May 2009, Alan McKinnon wrote: Once you sort that out, there's a whole host of other stuff to fix as well - expat, latest xorg and many more - all stuff that everyone else fixed a while ago and since forgot. Yes, beware of mktemp/coreutils too. I don't remember of other dangers, maybe pam... Ciao Francesco -- Linux Version 2.6.29-gentoo-r3, Compiled #2 SMP PREEMPT Sat May 9 18:15:29 CEST 2009 Two 2.9GHz AMD Athlon 64 Processors, 4GB RAM, 11653 Bogomips Total aemaeth
