SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 2013-04-15 2:02 PM, Michael Mol mike...@gmail.com wrote: Were this one of my systems (none of which is in a prod scenario, so take it with a grain of salt), I'd emerge -e --keep-going @system, and then emerge --resume a few times. You're stuck in something not unlike a bootstrap scenario. Ok, well, the DB was down, and I had the data backed up, so last resort, I switched back to the 32bit kernel, rebooted, and started the first emerge -e --keep-going @system, and left for home to continue working on it from there... It was done by the time I got home (about 25 minute drive), so didn't take nearly as long as I had feared - mostly because about 28 packages - most of them the ones that take a really long time (like glib, glibc and gcc) died almost immediately... After the first one completed, I did emerge --resume until everything was emerged. Then I started it all over again, and this time, *everything* recompiled successfully! But, apache still wouldn't start up. The error was PHP related, so, I rebuilt that with emerge -vu (with 5.4 masked so it would pull in the latest update to 5.3 since emerging -vuk (reinstalling the quickpkg'd masked version) didn't work - and this time PHP successfully updated, and presto, everything is now working as expected! I'm still planning on finishing up the new server (had already started on it) and migrating the DB to it, but now the pressure is off. So, massive thanks! to Michael for the suggestion (had heard of totally rebuilding the entire system using -e and --keep-going, but never done it)... and of course, gentoo is amazing. Charles
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 04/16/2013 11:23 AM, Tanstaafl wrote: On 2013-04-15 2:02 PM, Michael Mol mike...@gmail.com wrote: Were this one of my systems (none of which is in a prod scenario, so take it with a grain of salt), I'd emerge -e --keep-going @system, and then emerge --resume a few times. You're stuck in something not unlike a bootstrap scenario. Ok, well, the DB was down, and I had the data backed up, so last resort, I switched back to the 32bit kernel, rebooted, and started the first emerge -e --keep-going @system, and left for home to continue working on it from there... It was done by the time I got home (about 25 minute drive), so didn't take nearly as long as I had feared - mostly because about 28 packages - most of them the ones that take a really long time (like glib, glibc and gcc) died almost immediately... After the first one completed, I did emerge --resume until everything was emerged. Then I started it all over again, and this time, *everything* recompiled successfully! But, apache still wouldn't start up. The error was PHP related, so, I rebuilt that with emerge -vu (with 5.4 masked so it would pull in the latest update to 5.3 since emerging -vuk (reinstalling the quickpkg'd masked version) didn't work - and this time PHP successfully updated, and presto, everything is now working as expected! I'm still planning on finishing up the new server (had already started on it) and migrating the DB to it, but now the pressure is off. So, massive thanks! to Michael for the suggestion (had heard of totally rebuilding the entire system using -e and --keep-going, but never done it)... and of course, gentoo is amazing. To be clear, you didn't rebuild the entire system. You rebuilt core packages. To rebuild the entire system, it'd be: emerge -e @world # Plus whatever else there is. You're still at risk of non-@system packages having risky opcodes. Sounds like PHP turned out to be one of those. You will probably need to rebuild others. But I'm very glad I was able to help. :) signature.asc Description: OpenPGP digital signature
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 2013-04-16 11:28 AM, Michael Mol mike...@gmail.com wrote: To be clear, you didn't rebuild the entire system. You rebuilt core packages. To rebuild the entire system, it'd be: emerge -e @world Correct - which is why I said @system... ;) # Plus whatever else there is. Hmmm... are there really packages that belong to neither @system or @world? How would I go about finding/updating these? You're still at risk of non-@system packages having risky opcodes. Sounds like PHP turned out to be one of those. You will probably need to rebuild others. Correct again, and am planning on doing this this weekend, *after* I get Linode's backups enabled and get a good snapshot of the system in 'working' (if possibly partially borked) condition... But I'm very glad I was able to help. :) Me too... :)
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 04/16/2013 11:50 AM, Tanstaafl wrote: On 2013-04-16 11:28 AM, Michael Mol mike...@gmail.com wrote: To be clear, you didn't rebuild the entire system. You rebuilt core packages. To rebuild the entire system, it'd be: emerge -e @world Correct - which is why I said @system... ;) # Plus whatever else there is. Hmmm... are there really packages that belong to neither @system or @world? How would I go about finding/updating these? I must have missed where you ran emerge -e @world. Oops. :) But, yes, there are packages which don't belong to @system or @world. @world consists of things you've explicitly asked for. @system consists of things that are deemed inherently necessary for system operation. Neither necessarily contains things like x11-libs/libX11, which may be pulled in as a dependency of something in @world or @system (depending on USE flags, etc). Various python modules would also not be found in either @world or @system. @system and @world are explicit statements...there are still the dependencies to worry about. But if you ran emerge -e @world, the -e would have picked those up. [snip] signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: Eth0 interface not found - udev
On Fri, Apr 12, 2013 at 04:48:25PM +, Grant Edwards wrote: Yea, I always had problems with that. I'd edit the LILO config file, forget to run the update command, reboot, then spend an embarassing amount of time trying to figure out why my new kernel behaved exactly like my old kernel despite the changes I'd made. That change alone made switching to grub worthwhile. PEBKAC ... never knew the fix to that was changing software. :-) -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Re: Eth0 interface not found - udev
On 04/16/2013 12:43 PM, Bruce Hill wrote: On Fri, Apr 12, 2013 at 04:48:25PM +, Grant Edwards wrote: Yea, I always had problems with that. I'd edit the LILO config file, forget to run the update command, reboot, then spend an embarassing amount of time trying to figure out why my new kernel behaved exactly like my old kernel despite the changes I'd made. That change alone made switching to grub worthwhile. PEBKAC ... never knew the fix to that was changing software. :-) I thought that's why you were using Gentoo rather than RHEL or LFS. :P signature.asc Description: OpenPGP digital signature
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 2013-04-16 12:12 PM, Michael Mol mike...@gmail.com wrote: I must have missed where you ran emerge -e @world. Oops. :) I didn't... I was replying to your comment that implied that I thought I had rebuilt my entire 'system', when in fact I specified '@system', meaning, only those packages in @system... :) That said... since this entire system was 32bit up until my little mistake, and I only updated/compiled a few packages, my thoughts are that the vast majority of the system should be 'ok' - or am I missing something (wouldn't surprise me if I am)... But, yes, there are packages which don't belong to @system or @world. @world consists of things you've explicitly asked for. @system consists of things that are deemed inherently necessary for system operation. Neither necessarily contains things like x11-libs/libX11, which may be pulled in as a dependency of something in @world or @system (depending on USE flags, etc). Various python modules would also not be found in either @world or @system. @system and @world are explicit statements...there are still the dependencies to worry about. But if you ran emerge -e @world, the -e would have picked those up. Gotcha... thanks for the clarification.
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 04/16/2013 02:03 PM, Tanstaafl wrote: On 2013-04-16 12:12 PM, Michael Mol mike...@gmail.com wrote: I must have missed where you ran emerge -e @world. Oops. :) I didn't... I was replying to your comment that implied that I thought I had rebuilt my entire 'system', when in fact I specified '@system', meaning, only those packages in @system... :) That said... since this entire system was 32bit up until my little mistake, and I only updated/compiled a few packages, my thoughts are that the vast majority of the system should be 'ok' - or am I missing something (wouldn't surprise me if I am)... Nuke the site from orbit...$FILL_IN_THE_BLANK :) It's unfortunate there's no tool to perform as revdep-rebuild, except checking that, e.g. a package was built with the current CHOST or CFLAGS set. The fact that I can run 'emerge --info $atomname' to get the build environment for a given $atomname tells me the system has enough information that this is possible. I simply don't know the finer details of where all this information lurks. But if I had such a tool, it would be of immense use to me while installing new systems; no need to emerge -e @world... signature.asc Description: OpenPGP digital signature
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On Tue, Apr 16, 2013 at 1:09 PM, Michael Mol mike...@gmail.com wrote: It's unfortunate there's no tool to perform as revdep-rebuild, except checking that, e.g. a package was built with the current CHOST or CFLAGS set. The fact that I can run 'emerge --info $atomname' to get the build environment for a given $atomname tells me the system has enough information that this is possible. I simply don't know the finer details of where all this information lurks. But if I had such a tool, it would be of immense use to me while installing new systems; no need to emerge -e @world... Check out /var/db/pkg/$CATEGORY/$PKGNAME/ -- there are text files containing CFLAGS, CHOST and many others. You or someone like you should be able to hack together a simple script to look for differences. :)
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On Tue, 16 Apr 2013 13:18:51 -0500, Paul Hartman wrote: It's unfortunate there's no tool to perform as revdep-rebuild, except checking that, e.g. a package was built with the current CHOST or CFLAGS set. The fact that I can run 'emerge --info $atomname' to get the build environment for a given $atomname tells me the system has enough information that this is possible. I simply don't know the finer details of where all this information lurks. But if I had such a tool, it would be of immense use to me while installing new systems; no need to emerge -e @world... Check out /var/db/pkg/$CATEGORY/$PKGNAME/ -- there are text files containing CFLAGS, CHOST and many others. You or someone like you should be able to hack together a simple script to look for differences. :) % source /etc/portage/make.conf % for f in /var/db/pkg/*/*/CFLAGS [[ $(cat $f) == $CFLAGS ]] || echo $f It does give quite a few hits though, because ebuilds can strip out flags. Of course, that in itself may be an indication that you have over-ricered your CFLAGS ;-) -- Neil Bothwick There are only two tragedies in life: one is not getting what one wants; and the other is getting it. - Oscar Wilde (1854-1900) signature.asc Description: PGP signature
Re: SOLVED - was Re: [gentoo-user] Serious problem with linode vm
On 04/16/2013 04:53 PM, Neil Bothwick wrote: On Tue, 16 Apr 2013 13:18:51 -0500, Paul Hartman wrote: It's unfortunate there's no tool to perform as revdep-rebuild, except checking that, e.g. a package was built with the current CHOST or CFLAGS set. The fact that I can run 'emerge --info $atomname' to get the build environment for a given $atomname tells me the system has enough information that this is possible. I simply don't know the finer details of where all this information lurks. But if I had such a tool, it would be of immense use to me while installing new systems; no need to emerge -e @world... Check out /var/db/pkg/$CATEGORY/$PKGNAME/ -- there are text files containing CFLAGS, CHOST and many others. You or someone like you should be able to hack together a simple script to look for differences. :) % source /etc/portage/make.conf % for f in /var/db/pkg/*/*/CFLAGS [[ $(cat $f) == $CFLAGS ]] || echo $f It does give quite a few hits though, because ebuilds can strip out flags. ebuilds should not generally be stripping out flags. Certainly there are occasional and valid cases, but they're pretty rare. Heck, last time I reported a bug where a flag was causing a build failure (since the package was using a compiler different from the system compiler), I was told it wasn't the packaging system's job to deal with that kind of bug. Of course, that in itself may be an indication that you have over-ricered your CFLAGS ;-) Or you might simply know what you're doing. http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS#Determining_available_processor_features Highly valuable if you're going to use distcc. signature.asc Description: OpenPGP digital signature
