On Tuesday 16 April 2013 22:15:32 Michael Mol wrote:
> Or you might simply know what you're doing.
>
> http://en.gentoo-wiki.com/wiki/Hardware_CFLAGS#Determining_available_proc
> essor_features
Out of curiosity I had a look at that guide, but `$ echo "" | gcc -
march=native -v -E - 2>&1 | grep c
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
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
On Tue, Apr 16, 2013 at 1:09 PM, Michael Mol 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 giv
On 04/16/2013 02:03 PM, Tanstaafl wrote:
> On 2013-04-16 12:12 PM, Michael Mol 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',
>
On 2013-04-16 12:12 PM, Michael Mol 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... :)
On 04/16/2013 11:50 AM, Tanstaafl wrote:
> On 2013-04-16 11:28 AM, Michael Mol 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 what
On 2013-04-16 11:28 AM, Michael Mol 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 tha
On 04/16/2013 11:23 AM, Tanstaafl wrote:
> On 2013-04-15 2:02 PM, Michael Mol 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
On 2013-04-15 2:02 PM, Michael Mol 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 wa
Tanstaafl wrote:
>On 2013-04-15 3:11 PM, Michael Mol wrote:
>> If this were me, I would set up a clean install from scratch. No, I
>> wouldn't use a x86 userspace with a x64 kernel, but that's because of
>> the benefits I see with the 64-bit arch, not with any issues I'd be
>> aware of from usin
On 2013-04-15 12:10 PM, Michael Mol wrote:
Argh. Reply to your own posts if you need to append content. Otherwise,
I can't easily address everything at once.
Sorry, I usually do, but I'm kind of flustered right now...
Anyway, you can (I believe) run a 64-bit kernel with a 32-bit CHOST.
Your
On 2013-04-15 3:11 PM, Michael Mol wrote:
If this were me, I would set up a clean install from scratch. No, I
wouldn't use a x86 userspace with a x64 kernel, but that's because of
the benefits I see with the 64-bit arch, not with any issues I'd be
aware of from using an x64 kernel with an x32 us
On 04/15/2013 02:54 PM, Tanstaafl wrote:
> On 2013-04-15 2:02 PM, Michael Mol 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
On 2013-04-15 2:02 PM, Michael Mol 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, before I start.
On 2013-04-15 2:08 PM, Tanstaafl wrote:
On 2013-04-15 2:03 PM, Tanstaafl wrote:
Ok, I think all I need to get our db back up is to remerge php, but it
is failing.
The last error appears to be the zlib check.
I did already try
emerge -1 sys-libs/zlib
and retrying to emerge php, but got the
On 04/15/2013 02:08 PM, Tanstaafl wrote:
> On 2013-04-15 2:03 PM, Tanstaafl wrote:
>>
>> Ok, I think all I need to get our db back up is to remerge php, but it
>> is failing.
>>
>> The last error appears to be the zlib check.
>>
>> I did already try
>>
>> emerge -1 sys-libs/zlib
>>
>> and retrying
Michael Mol wrote:
> On 04/15/2013 12:51 PM, cov...@ccs.covici.com wrote:
> > Michael Mol wrote:
> >
> >> On 04/15/2013 12:07 PM, Tanstaafl wrote:
> >>> On 2013-04-15 11:51 AM, Tanstaafl wrote:
> I'm confused about how this works in a hosted virtual environment.
>
> My Dev serve
On 2013-04-15 2:03 PM, Tanstaafl wrote:
Ok, I think all I need to get our db back up is to remerge php, but it
is failing.
The last error appears to be the zlib check.
I did already try
emerge -1 sys-libs/zlib
and retrying to emerge php, but got the same error:
Ok, added -zlib to package.
On 2013-04-15 1:46 PM, Tanstaafl wrote:
On 2013-04-15 11:42 AM, Michael Mol wrote:
On 04/15/2013 11:37 AM, Tanstaafl wrote:
Hi all,
Help! :(
[snip]
I've tried recompiling both (both compile/install ok), but when I try to
start SSHD I get:
# /etc/init.d/sshd start
/etc/init.d/sshd
On 04/15/2013 01:46 PM, Tanstaafl wrote:
> On 2013-04-15 11:42 AM, Michael Mol wrote:
>> On 04/15/2013 11:37 AM, Tanstaafl wrote:
>>> Hi all,
>>>
>>> Help! :(
>>
>> [snip]
>>
>>>
>>> I've tried recompiling both (both compile/install ok), but when I try to
>>> start SSHD I get:
>>>
>>> # /etc
On 2013-04-15 11:42 AM, Michael Mol wrote:
On 04/15/2013 11:37 AM, Tanstaafl wrote:
Hi all,
Help! :(
[snip]
I've tried recompiling both (both compile/install ok), but when I try to
start SSHD I get:
# /etc/init.d/sshd start
/etc/init.d/sshd: line 18: 2079 Illegal instruction "${SSH
On 04/15/2013 12:51 PM, cov...@ccs.covici.com wrote:
> Michael Mol wrote:
>
>> On 04/15/2013 12:07 PM, Tanstaafl wrote:
>>> On 2013-04-15 11:51 AM, Tanstaafl wrote:
I'm confused about how this works in a hosted virtual environment.
My Dev server failed to come up after the migrati
On 2013-04-15 12:51 PM, cov...@ccs.covici.com wrote:
Michael Mol wrote:
On 04/15/2013 12:07 PM, Tanstaafl wrote:
Can you run a 64bit kernel on a system that was originally
running/compiled with 32bit?
I don't see why not. The 64-bit kernel provides all the hooks necessary
for a 32-bit user
Michael Mol wrote:
> On 04/15/2013 12:07 PM, Tanstaafl wrote:
> > On 2013-04-15 11:51 AM, Tanstaafl wrote:
> >> I'm confused about how this works in a hosted virtual environment.
> >>
> >> My Dev server failed to come up after the migration, until their tech
> >> support suggested switching to t
On 04/15/2013 12:07 PM, Tanstaafl wrote:
> On 2013-04-15 11:51 AM, Tanstaafl wrote:
>> I'm confused about how this works in a hosted virtual environment.
>>
>> My Dev server failed to come up after the migration, until their tech
>> support suggested switching to the 64bit kernel... did that and i
On 04/15/2013 11:53 AM, Tanstaafl wrote:
> On 2013-04-15 11:42 AM, Michael Mol wrote:
>> Guessing the new host has different CPU capabilities exposed to the
>> guest, either because of a differing hypervisor configuraiton, or
>> because of the different underlying hardware.
>
> Hmmm again...
>
>
On 15/04/13 16:53, Tanstaafl wrote:
On 2013-04-15 11:42 AM, Michael Mol wrote:
Guessing the new host has different CPU capabilities exposed to the
guest, either because of a differing hypervisor configuraiton, or
because of the different underlying hardware.
Hmmm again...
CHOST is the same o
On 2013-04-15 11:51 AM, Tanstaafl wrote:
I'm confused about how this works in a hosted virtual environment.
My Dev server failed to come up after the migration, until their tech
support suggested switching to the 64bit kernel... did that and it is
fine now (or appears to be)...
But the Prod se
On 2013-04-15 11:42 AM, Michael Mol wrote:
Guessing the new host has different CPU capabilities exposed to the
guest, either because of a differing hypervisor configuraiton, or
because of the different underlying hardware.
Hmmm again...
CHOST is the same on both:
CHOST="i686-pc-linux-gnu"
On 2013-04-15 11:42 AM, Michael Mol wrote:
^^ That screams 'CFLAGS' issue. Verify that the CFLAGS for your prod
server are the same (or close enough) to that of your dev server.
Hmmm, they are different...
Dev (working) server has:
CFLAGS="-O2 -march=i686 -pipe"
Prod server has:
CFLAGS="-m
On 2013-04-15 11:42 AM, Michael Mol wrote:
On 04/15/2013 11:37 AM, Tanstaafl wrote:
Hi all,
Help! :(
[snip]
I've tried recompiling both (both compile/install ok), but when I try to
start SSHD I get:
# /etc/init.d/sshd start
/etc/init.d/sshd: line 18: 2079 Illegal instruction "${SSH
On 04/15/2013 11:37 AM, Tanstaafl wrote:
> Hi all,
>
> Help! :(
[snip]
>
> I've tried recompiling both (both compile/install ok), but when I try to
> start SSHD I get:
>
> # /etc/init.d/sshd start
> /etc/init.d/sshd: line 18: 2079 Illegal instruction "${SSHD_BINARY}" -t
> ${SSHD_OPTS}
> *
Hi all,
Help! :(
I have a serious problem with our production DB machine hosted on
linode, and I hope someone can help me.
They recently updated their hardware, but taking advantage of it
required 'migrating' our machines...
I migrated our dev server first, and it failed to boot after
34 matches
Mail list logo
