On 07/28/2014 04:33 AM, Adam Carter wrote:
>
>
>
> grep MAKEOPTS /etc/portage/make.conf
> MAKEOPTS="-j3"
>
> What value is your MAKEOPTS set to?
>
> I have tried -j1 to rule out parallel compilation issues, but it
> didn't help.
Here's all the 'thread.h' header files I seem to have on
2014-07-27 5:29 GMT-06:00 :
>
> Back to the initial problem:
>
> How can I offline test the rest of the disk if
> the first bad sector (10%) of the surface breaks
> the test with an error?
>
> Best regards,
> mcc
I've only read this thread not the previous, and I can only give some
feedback on th
Neil Bothwick wrote:
> On Sun, 27 Jul 2014 14:20:23 -0500, Dale wrote:
>
>> Question. Does that mean that the heads can't move past that point? If
>> yes, does that mean the OP can't get any data that is further out than
>> that point? I'm asking hoping I will learn something. I have taken
>> d
>
> grep MAKEOPTS /etc/portage/make.conf
> MAKEOPTS="-j3"
>
> What value is your MAKEOPTS set to?
>
> I have tried -j1 to rule out parallel compilation issues, but it didn't
help.
On Sun, Jul 27, 2014 at 12:33 PM, James wrote:
>
> I set my nameservers all manually in this file and they do
> not every change. I do not run systemd. I'm not sure
> of your issue(s) but, historically, resolv.conf should not
> be displaying this behavior.
>
FWIW, systemd doesn't touch resolv.con
On 27/07/2014 21:38, Grand Duet wrote:
2014-07-27 22:13 GMT+03:00 Neil Bothwick :
On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote:
That's what replaces it when eth0 comes up.
It looks like eth0 is not being brought up fully
It sounds logical. But how can I fix it?
By identifying how f
On Sun, 27 Jul 2014 14:20:23 -0500, Dale wrote:
> Question. Does that mean that the heads can't move past that point? If
> yes, does that mean the OP can't get any data that is further out than
> that point? I'm asking hoping I will learn something. I have taken
> drives apart so I know how th
2014-07-27 23:28 GMT+03:00 Daniel Frey :
> On 07/27/2014 08:08 AM, Grand Duet wrote:
>>
>> If eth0 starts after lo, then I have the right /etc/resolv.conf
>> file, however if lo starts after eth0, then the DNS IPs in
>> resolv.conf file are overwritten with dummy instruction
>> for lo interface.
>>
2014-07-27 22:13 GMT+03:00 Neil Bothwick :
> On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote:
>
>> > That's what replaces it when eth0 comes up.
>> > It looks like eth0 is not being brought up fully
>>
>> It sounds logical. But how can I fix it?
>
> By identifying how far it is getting and why
On 07/27/2014 08:08 AM, Grand Duet wrote:
>
> If eth0 starts after lo, then I have the right /etc/resolv.conf
> file, however if lo starts after eth0, then the DNS IPs in
> resolv.conf file are overwritten with dummy instruction
> for lo interface.
>
> But, now, after your suggestion, I have look
2014-07-27 21:14 GMT+03:00 Kerin Millar :
> On 27/07/2014 12:30, Grand Duet wrote:
>>
>> 2014-07-27 13:39 GMT+03:00 Walter Dnes :
>>>
>>> On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote
This is a continuation of the thread:
"Something went wrong with DNS, plz help!"
>
On 27/07/2014 17:55, J. Roeleveld wrote:
On 27 July 2014 18:25:24 CEST, "Stefan G. Weichinger" wrote:
Am 26.07.2014 04:47, schrieb walt:
So, why did the "broken" machine work normally for more than a year
without rpcbind until two days ago? (I suppose because nfs-utils was
updated to 1.3.0 ?
Neil Bothwick wrote:
> On Sun, 27 Jul 2014 12:41:15 +0200, meino.cra...@gmx.de wrote:
>
>>> My understanding is that the test only aborts if the error is severe
>>> enough to force it to do so. A simple bad block can be skipped and the
>>> rest of the drive tested.
>> But it is slightly off the poi
On Sun, 27 Jul 2014 13:33:47 +0300, Grand Duet wrote:
> > That's what replaces it when eth0 comes up.
> > It looks like eth0 is not being brought up fully
>
> It sounds logical. But how can I fix it?
By identifying how far it is getting and why no further. But it appears
that eth0 is being bro
On Sun, 27 Jul 2014 12:41:15 +0200, meino.cra...@gmx.de wrote:
> > My understanding is that the test only aborts if the error is severe
> > enough to force it to do so. A simple bad block can be skipped and the
> > rest of the drive tested.
> But it is slightly off the point I tried to explain (I
On 27/07/2014 12:30, Grand Duet wrote:
2014-07-27 13:39 GMT+03:00 Walter Dnes :
On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote
This is a continuation of the thread:
"Something went wrong with DNS, plz help!"
Now, the issue became clearer, so I decided to start
a new thread with mor
2014-07-27 19:33 GMT+03:00 James :
> Grand Duet gmail.com> writes:
>
>
>> >> In short: the contents of the file /etc/resolv.conf
>> >> is unpredictably different from one reboot to another.
>> >> It is either
>> >> # Generated by net-scripts for interface lo
>> >> domain mynetwork or
>> >> #
Am 27.07.2014 18:25, schrieb Stefan G. Weichinger:
> Only last week I re-attacked this topic as I start using puppet here to
> manage my systems ... and one part of this might be sharing /usr/portage
> via NFSv4. One client host mounts it without a problem, the thinkpads
> don't do so ... just ano
On 27 July 2014 18:25:24 CEST, "Stefan G. Weichinger" wrote:
>Am 26.07.2014 04:47, schrieb walt:
>
>> So, why did the "broken" machine work normally for more than a year
>> without rpcbind until two days ago? (I suppose because nfs-utils was
>> updated to 1.3.0 ?)
>>
>> The real problem here is
Mick [14-07-27 16:36]:
> On Sunday 27 Jul 2014 15:05:53 Dale wrote:
> > meino.cra...@gmx.de wrote:
> > > Dale [14-07-27 14:36]:
> > >> meino.cra...@gmx.de wrote:
> > >>> Back to the initial problem: How can I offline test the rest of the
> > >>> disk if the first bad sector (10%) of the surface b
Grand Duet gmail.com> writes:
> >> In short: the contents of the file /etc/resolv.conf
> >> is unpredictably different from one reboot to another.
> >> It is either
> >> # Generated by net-scripts for interface lo
> >> domain mynetwork or
> >> # Generated by net-scripts for interface "eth0
Am 26.07.2014 04:47, schrieb walt:
> So, why did the "broken" machine work normally for more than a year
> without rpcbind until two days ago? (I suppose because nfs-utils was
> updated to 1.3.0 ?)
>
> The real problem here is that I have no idea how NFS works, and each
> new version is more com
> On Jul 27, 2014, at 16:39, Grand Duet wrote:
>
> 2014-07-27 16:10 GMT+03:00 Matti Nykyri :
>>> On Jul 27, 2014, at 13:33, Grand Duet wrote:
>>>
>>> 2014-07-27 12:29 GMT+03:00 Neil Bothwick :
> On Sun, 27 Jul 2014 12:21:23 +0300, Grand Duet wrote:
>
> In short: the contents of the
2014-07-27 17:50 GMT+03:00 Daniel Frey :
> On 07/27/2014 04:30 AM, Grand Duet wrote:
>>
>>> and also the output of the "rc-update show" command?
>>
>> # rc-update show
>> alsasound | boot
>>bootmisc | boot
>> dbus | default
>>
2014-07-27 14:30 GMT+03:00 Grand Duet :
> 2014-07-27 13:39 GMT+03:00 Walter Dnes :
>> On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote
>>> This is a continuation of the thread:
>>> "Something went wrong with DNS, plz help!"
>>>
>>> Now, the issue became clearer, so I decided to start
>>>
On 07/27/2014 04:30 AM, Grand Duet wrote:
>
>> and also the output of the "rc-update show" command?
>
> # rc-update show
> alsasound | boot
>bootmisc | boot
> dbus | default
> devfs | sysinit
>
On Sunday 27 Jul 2014 15:05:53 Dale wrote:
> meino.cra...@gmx.de wrote:
> > Dale [14-07-27 14:36]:
> >> meino.cra...@gmx.de wrote:
> >>> Back to the initial problem: How can I offline test the rest of the
> >>> disk if the first bad sector (10%) of the surface breaks the test with
> >>> an error?
On Sat, Jul 26, 2014 at 9:51 AM, Alan McKinnon wrote:
>
> NFS uses RPC to do some heavy lifting - I don't know how familiar you
> are with this, so here's the quick version:
>
> When you mount something locally, and need to use the mounted
> filesystem, kernel calls are used to get at the data. Th
meino.cra...@gmx.de wrote:
> Dale [14-07-27 14:36]:
>> meino.cra...@gmx.de wrote:
>>> Back to the initial problem: How can I offline test the rest of the
>>> disk if the first bad sector (10%) of the surface breaks the test with
>>> an error? Best regards, mcc
>> I never got mine to go past the f
2014-07-27 16:10 GMT+03:00 Matti Nykyri :
>> On Jul 27, 2014, at 13:33, Grand Duet wrote:
>>
>> 2014-07-27 12:29 GMT+03:00 Neil Bothwick :
On Sun, 27 Jul 2014 12:21:23 +0300, Grand Duet wrote:
In short: the contents of the file /etc/resolv.conf
is unpredictably different from o
Dale [14-07-27 14:36]:
> meino.cra...@gmx.de wrote:
> > Back to the initial problem: How can I offline test the rest of the
> > disk if the first bad sector (10%) of the surface breaks the test with
> > an error? Best regards, mcc
>
> I never got mine to go past the first failure until I used dd
> On Jul 27, 2014, at 13:33, Grand Duet wrote:
>
> 2014-07-27 12:29 GMT+03:00 Neil Bothwick :
>>> On Sun, 27 Jul 2014 12:21:23 +0300, Grand Duet wrote:
>>>
>>> In short: the contents of the file /etc/resolv.conf
>>> is unpredictably different from one reboot to another.
>>> It is either
>>> # G
Am 25.07.2014 06:32, schrieb Pavel Volkov:
> On Tuesday, July 22, 2014 1:40:36 AM MSK, James wrote:
>> Bloatware like gnome and KDE will be the last to get QT5, Wayland and a
>> myriad of new, super_fast, secure desktop toys, imho.
>
> Well, KDE is already on Qt 5.
> Strictly speaking, there's no
meino.cra...@gmx.de wrote:
> Back to the initial problem: How can I offline test the rest of the
> disk if the first bad sector (10%) of the surface breaks the test with
> an error? Best regards, mcc
I never got mine to go past the first failure until I used dd to erase
the drive. As mentioned b
On 07/26/2014 11:25 PM, Dale wrote:
> Alexander Kapshuk wrote:
>> On 07/26/2014 03:31 PM, Holger Hoffstätte wrote:
>>> On Sat, 26 Jul 2014 15:05:23 +0300, Alexander Kapshuk wrote:
>>>
Which NTPd package would the list recommend using, ntp, openntpd, or
some other package?
>>> chrony - no
On 07/27/2014 12:30 PM, Adam Carter wrote:
>
> On Sat, Jul 26, 2014 at 9:59 PM, Alexander Kapshuk
> mailto:alexander.kaps...@gmail.com>> wrote:
>
> Forgot to mention.
>
> equery -q b /usr/include/wx-2.8/wx/thread.h
> x11-libs/wxGTK-2.8.12.1-r1
>
>
> Ok so the file IS provided by the pac
2014-07-27 13:39 GMT+03:00 Walter Dnes :
> On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote
>> This is a continuation of the thread:
>> "Something went wrong with DNS, plz help!"
>>
>> Now, the issue became clearer, so I decided to start
>> a new thread with more descriptive Subject.
>>
>
Dale [14-07-27 13:12]:
> meino.cra...@gmx.de wrote:
> > Neil Bothwick [14-07-27 12:32]:
> >> On Sun, 27 Jul 2014 12:12:47 +0200, meino.cra...@gmx.de wrote:
> >>
> >>> On the one hand, the surface test (extended offline and such) aborts
> >>> as soon the first read fgailure happens.
> >>>
> >>> On
Grand Duet wrote:
> 2014-07-27 12:29 GMT+03:00 Neil Bothwick :
> It sounds logical. But how can I fix it? Can carrier_timeout_eth0=
> setting in /etc/conf.d/net file help? If so, how much seconds should I
> use?
>> what do your logs say?
> Could you, please, be more precise where to look for "logs"
meino.cra...@gmx.de wrote:
> Neil Bothwick [14-07-27 12:32]:
>> On Sun, 27 Jul 2014 12:12:47 +0200, meino.cra...@gmx.de wrote:
>>
>>> On the one hand, the surface test (extended offline and such) aborts
>>> as soon the first read fgailure happens.
>>>
>>> On the other hand it is said: If the count
Marc Stürmer wrote:
> Am 26.07.2014 20:23, schrieb Volker Armin Hemmann:
>
>> but you will care when your kernel writes the next file right over the
>> partition boundary.
>
> That's why I do have backups of all my relevant data on an external
> storage medium.
>
>
Just watch that you don't backup
Am 26.07.2014 20:23, schrieb Volker Armin Hemmann:
but you will care when your kernel writes the next file right over the
partition boundary.
That's why I do have backups of all my relevant data on an external
storage medium.
Neil Bothwick [14-07-27 12:32]:
> On Sun, 27 Jul 2014 12:12:47 +0200, meino.cra...@gmx.de wrote:
>
> > On the one hand, the surface test (extended offline and such) aborts
> > as soon the first read fgailure happens.
> >
> > On the other hand it is said: If the count of bad sectors increases
> >
On Sun, Jul 27, 2014 at 12:21:23PM +0300, Grand Duet wrote
> This is a continuation of the thread:
> "Something went wrong with DNS, plz help!"
>
> Now, the issue became clearer, so I decided to start
> a new thread with more descriptive Subject.
>
> In short: the contents of the file /etc/resolv
2014-07-27 12:29 GMT+03:00 Neil Bothwick :
> On Sun, 27 Jul 2014 12:21:23 +0300, Grand Duet wrote:
>
>> In short: the contents of the file /etc/resolv.conf
>> is unpredictably different from one reboot to another.
>> It is either
>> # Generated by net-scripts for interface lo
>> domain mynetwor
On Sun, 27 Jul 2014 12:12:47 +0200, meino.cra...@gmx.de wrote:
> On the one hand, the surface test (extended offline and such) aborts
> as soon the first read fgailure happens.
>
> On the other hand it is said: If the count of bad sectors increases
> over time it is time to change the hd.
>
> Ho
meino.cra...@gmx.de wrote:
> Hi,
>
> after finding a bad sector on my hd (see previous thread) a read a lot
> stuff about SMART, smartctl and such to determine wether and how
> severe is a bad sector and how to cope with it.
>
> There is (at least ;) one thing I dont understand:
>
> On the one hand
Hi,
after finding a bad sector on my hd (see previous thread) a read a lot
stuff about SMART, smartctl and such to determine wether and how
severe is a bad sector and how to cope with it.
There is (at least ;) one thing I dont understand:
On the one hand, the surface test (extended offline and s
On Sat, Jul 26, 2014 at 9:59 PM, Alexander Kapshuk <
alexander.kaps...@gmail.com> wrote:
> Forgot to mention.
>
> equery -q b /usr/include/wx-2.8/wx/thread.h
> x11-libs/wxGTK-2.8.12.1-r1
>
>
Ok so the file IS provided by the package itself, and therefore I see why
-l1 makes sense.
On Sun, 27 Jul 2014 12:21:23 +0300, Grand Duet wrote:
> In short: the contents of the file /etc/resolv.conf
> is unpredictably different from one reboot to another.
> It is either
> # Generated by net-scripts for interface lo
> domain mynetwork
That's what you get when lo comes up.
> or
>
This is a continuation of the thread:
"Something went wrong with DNS, plz help!"
Now, the issue became clearer, so I decided to start
a new thread with more descriptive Subject.
In short: the contents of the file /etc/resolv.conf
is unpredictably different from one reboot to another.
It is either
2014-07-27 2:10 GMT+03:00 walt :
> On 07/26/2014 02:00 PM, Grand Duet wrote:
>> After the last reboot I magically have got the right /etc/resolv.conf
>> with DNS servers IPs.
>>
>> Even more strange is that it happened *without* my intervention:
>> just a few reboots (one was no enough!).
>
> I'm g
52 matches
Mail list logo
