Re: [gentoo-user] Re: Something went wrong with DNS, plz help!
2014-07-27 2:10 GMT+03:00 walt w41...@gmail.com: 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 glad the evil spirits decided to depart. Just temporary. To have a nap. And probably because he knew that I will not do anything during the night. But now, when I turned my computer on to do the real work, he came back! Seriously, I just found out that the contents of my /etc/resolv.conf is not only rewritten at every reboot but 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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I am going to start another thread about it. It will be called: resolv.conf is different after every reboot Are you using networkmanager? No. It is not installed. My resolv.conf says it was created by networkmanager. This, by the way, reminds me MS Windows very much. :)
[gentoo-user] resolv.conf is different after every reboot
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 # Generated by net-scripts for interface lo domain mynetwork or # Generated by net-scripts for interface eth0 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway.
Re: [gentoo-user] resolv.conf is different after every reboot
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 # Generated by net-scripts for interface eth0 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 That's what replaces it when eth0 comes up. It looks like eth0 is not being brought up fully, what do your logs say? It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. You can't stop root overwriting a file, root laughs in the face of file permissions. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. -- Neil Bothwick If at first you don't succeed, call in an airstrike. signature.asc Description: PGP signature
Re: Re: [gentoo-user] wxGTK compilation fails missing thread.h
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.
[gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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 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. How can the second happen, if the first is true??? Best regards, mcc
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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, 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. How can the second happen, if the first is true??? Best regards, mcc I am by no means a expert on this but I'll try to provide some info, which others may correct. ;-) I had a situation similar to yours a few months ago. I had a bad spot that popped up. After some effort, I got the drive to mark that as bad. Now, from my understanding, the drive sort of has some extra space that it can use if needed. However, at some point it will run out if you have spots going bad one after another. Again, my understanding. Let's say it has 200 extra spots. You then run the test or the drive detects on its own and finds a bad spot. It marks that spot as bad and then uses one of the extra spots. So, if you have 201 spots to go bad, you fresh out of luck. Again, that's my understanding of this. Now can someone else that knows even more than me explain this better? :-D Dale :-) :-)
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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. How can the second happen, if the first is true??? 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. I've had a couple of drives get to the stage where SMART tests abort at an error and in both cases the manufacturer replaced them without question. -- Neil Bothwick If at first you do succeed, try to hide your astonishment. signature.asc Description: PGP signature
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 12:29 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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 # Generated by net-scripts for interface eth0 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 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? 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. It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. Currently, I have no such functions in my /etc/conf.d/net file. Shall I copy them there from /usr/share/doc/netifrc-0.2.2/net.example Could you, please, be more specific on these logger commands too. I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. You can't stop root overwriting a file, root laughs in the face of file permissions. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. I do not have such file. Of course, if you do not mean /etc/resolv.conf But I have posted its content above.
Re: [gentoo-user] resolv.conf is different after every reboot
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.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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. A similar problem was noted at... https://forums.gentoo.org/viewtopic-t-816332-start-0.html Can you post the contents of your /etc/conf.d/net and also the output of the rc-update show command? That should help narrow down the potential sources of your problem. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
Neil Bothwick n...@digimed.co.uk [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 over time it is time to change the hd. How can the second happen, if the first is true??? 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. I've had a couple of drives get to the stage where SMART tests abort at an error and in both cases the manufacturer replaced them without question. -- Neil Bothwick If at first you do succeed, try to hide your astonishment. Hi Dale, hi Neil, thanks for the infos. But it is slightly off the point I tried to explain (I am no native english speaker...sorry...:) Suppose - as in my case - I have not yert managed to urge the hd to map the bad sector off... Now...all tests abort after scanning 10% of the disk. Disk health status is reported as PASSED...cause only one bad sector has been found. But 90% of the space of the disk has never been scanned. Is this an implementation fault? And if YES...is it the implementation of the firmware? And: Is it my firmware or the one of the drive? ;) Best regards, mcc
Re: [gentoo-user] Re: ECC-ram, it is worth it.
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.
Re: [gentoo-user] Re: ECC-ram, it is worth it.
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 bad data. I've seen that happen before and it really sucks. :-( Dale :-) :-)
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
meino.cra...@gmx.de wrote: Neil Bothwick n...@digimed.co.uk [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 over time it is time to change the hd. How can the second happen, if the first is true??? 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. I've had a couple of drives get to the stage where SMART tests abort at an error and in both cases the manufacturer replaced them without question. -- Neil Bothwick If at first you do succeed, try to hide your astonishment. Hi Dale, hi Neil, thanks for the infos. But it is slightly off the point I tried to explain (I am no native english speaker...sorry...:) Suppose - as in my case - I have not yert managed to urge the hd to map the bad sector off... Now...all tests abort after scanning 10% of the disk. Disk health status is reported as PASSED...cause only one bad sector has been found. But 90% of the space of the disk has never been scanned. Is this an implementation fault? And if YES...is it the implementation of the firmware? And: Is it my firmware or the one of the drive? ;) Best regards, mcc Interesting. I was able to get mine to do a full test and give me a clean result. If yours doesn't, well, I'd be diggin me out a box and sending that puppy back to mommy. It seems to need some help. To me, errors is one thing, errors that can't be corrected is a whole new problem. It should fix it and pass the test. Even with my drive passing the test, I don't trust it yet. If it was still showing the error even after I did what I had done, I certainly wouldn't trust it. If yours can't finish the long self test, it may need repairs that are above our pay grade. Maybe Neil or someone will have more ideas. I hope. Dale :-) :-)
Re: [gentoo-user] resolv.conf is different after every reboot
Grand Duet wrote: 2014-07-27 12:29 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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. Could be /var/log/messages or dmesg. I'd check both. Dale :-) :-)
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
Dale rdalek1...@gmail.com [14-07-27 13:12]: meino.cra...@gmx.de wrote: Neil Bothwick n...@digimed.co.uk [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 over time it is time to change the hd. How can the second happen, if the first is true??? 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. I've had a couple of drives get to the stage where SMART tests abort at an error and in both cases the manufacturer replaced them without question. -- Neil Bothwick If at first you do succeed, try to hide your astonishment. Hi Dale, hi Neil, thanks for the infos. But it is slightly off the point I tried to explain (I am no native english speaker...sorry...:) Suppose - as in my case - I have not yert managed to urge the hd to map the bad sector off... Now...all tests abort after scanning 10% of the disk. Disk health status is reported as PASSED...cause only one bad sector has been found. But 90% of the space of the disk has never been scanned. Is this an implementation fault? And if YES...is it the implementation of the firmware? And: Is it my firmware or the one of the drive? ;) Best regards, mcc Interesting. I was able to get mine to do a full test and give me a clean result. If yours doesn't, well, I'd be diggin me out a box and sending that puppy back to mommy. It seems to need some help. To me, errors is one thing, errors that can't be corrected is a whole new problem. It should fix it and pass the test. Even with my drive passing the test, I don't trust it yet. If it was still showing the error even after I did what I had done, I certainly wouldn't trust it. If yours can't finish the long self test, it may need repairs that are above our pay grade. Maybe Neil or someone will have more ideas. I hope. Dale :-) :-) 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
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 13:39 GMT+03:00 Walter Dnes waltd...@waltdnes.org: 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.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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. A similar problem was noted at... https://forums.gentoo.org/viewtopic-t-816332-start-0.html Like in the thread above, I also have a line dns_domain_lo=mynetwork in my /etc/conf.d/net file. It says nothing to me and I do not remember how it got there. But somewhere on Gentoo forum I have found the following explanation: If you only specify dns_domain_lo=foo and restart the lo interface it will put domain foo in /etc/resolv.conf and remove everything else. So, I guess I should try to remove that line from my /etc/conf.d/net file. But why the system worked fine for about a year *with* this line then? Can you post the contents of your /etc/conf.d/net hostname=myhostname dns_domain_lo=mynetwork config_eth0=My.Local.IP netmask My.Net.Mask broadcast Broadcast.IPof.My.LocalNetwork routes_eth0=default via Local.IPof.My.Gateway dns_servers_eth0=My.First.DNS.IP My.Second.DNS.IP 8.8.8.8 mtu_eth0=1500 # if needed # The network scripts are now part of net-misc/netifrc # In order to avoid sys-apps/openrc-0.12.4 from removing this file, this comment was # added; you can safely remove this comment. Please see # /usr/share/doc/netifrc*/README* for more information. and also the output of the rc-update show command? # rc-update show alsasound | boot bootmisc | boot dbus | default devfs | sysinit dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit local | default localmount | boot loopback | boot metalog | default modules | boot mount-ro | shutdown mtab | boot net.eth0 | default net.lo | boot netmount | default privoxy | default procfs | boot root | boot savecache | shutdown swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit udev-mount | sysinit urandom | boot Everywhere above eth0 has been put instead of its udev predictable name. Do you think that I need carrier_timeout_eth0=20 somewhere in /etc/conf.d/net ? Thank you. That should help narrow down the potential sources of your problem.
Re: [gentoo-user] wxGTK compilation fails missing thread.h
On 07/27/2014 12:30 PM, Adam Carter wrote: On Sat, Jul 26, 2014 at 9:59 PM, Alexander Kapshuk alexander.kaps...@gmail.com 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 package itself, and therefore I see why -l1 makes sense. I am no multi-thread compilation expert, but here's what I've got on my system with x11-libs/wxGTK-2.8.12.1-r1 building without any trouble. grep MAKEOPTS /etc/portage/make.conf MAKEOPTS=-j3 What value is your MAKEOPTS set to?
Re: [gentoo-user] Re: re: which NTPd package to use?
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 competition, even for servers. ntpd is way overrated, unnecessarily hard to setup correctly, fragile and contrary to popular belief not even that accurate, unless you use external HW clocks. Chrony is maintained by Red Hat in cooperation with the timekeeping code in the kernel. openntpd seems to be easier to set up according to wiki.gentoo.org. Many many years ago I helped port openntpd to Linux. It was OK-ish at the time and easier/less hassle than ntpd, but the portable version for Linux stopped working reliably many years ago due to kernel changes. IMHO it really should no longer be in the tree since it gives a false sense of accuracy. just my 0.01€.. -h Is this gentoo wiki article still relevant when it comes to configuring chrony on gentoo? http://www.gentoo-wiki.info/Chrony Or should I stick to the instructions given here: /usr/share/doc/chrony-1.29.1/chrony.txt.bz2 Thanks. This is my chrony.conf without all the commented out parts. server 64.6.144.6 server 67.159.5.90 server 67.59.168.233 server 204.62.14.98 server 69.50.219.51 server 209.114.111.1 driftfile /etc/chrony.drift keyfile /etc/chrony/chrony.keys commandkey 1 logdir /var/log/chrony log measurements statistics tracking rtc The last two lines are optional. Use those if you like to be nosy and watch it do its thing. I still have ntpdate installed and use it to check and see how close it is on occasion. This is what I get from the test: root@fireball / # ntpdate -b -u -q pool.ntp.org server 198.144.194.12, stratum 2, offset -0.003320, delay 0.10658 server 173.44.32.10, stratum 2, offset -0.003313, delay 0.07515 server 70.60.65.40, stratum 2, offset -0.003059, delay 0.09262 server 38.229.71.1, stratum 2, offset -0.001002, delay 0.09563 26 Jul 15:16:00 ntpdate[10232]: step time server 173.44.32.10 offset -0.003313 sec root@fireball / # I did a fair sized upgrade the other day and went to the boot runlevel afterwards to restart the services that were updated. I'm pretty sure it has been doing its thing since then without me doing anything to it. I think you can use mirrorselect to find the best mirrors for your area. I can't recall the command but I bet a search of the Gentoo forums would find it fairly quick. Looking at the howto, the only thing I do different is put it in the default runlevel. Unless I am in the default runlevel, there is no internet access available anyway. No internet access, no way to set the clock anyway. ;-) Hope that helps. Dale :-) :-) Terrific. Thanks.
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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 before, I may could have done that without moving my data but that was to complicated and risky for me at the time. From my understanding tho, until that data is moved off the bad spot so that the drive knows it can do what it needs to, that spot is still going to show up. I don't know of a way to make it test beyond the bad spot either. If you have a drive that you can move that data over to so that you can play with the bad drive, that's what I would do. Once you get it moved, then dd the whole drive, run the test and then see what results you get. I looked at a howto that someone posted or I found and doing it with the data on there just made me nervous. I'm running out of info here. Anyone else provide more help than me? Dale :-) :-)
Re: [gentoo-user] wayland
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 KDE or KDE SC anymore. There are 3 separate projects: - KDE Frameworks 5 (released already) - KDE Plasma 5 (released too) - KDE Applications 5 (this or is not yet released) Qt 4 apps will still be able to work with Frameworks 5 and Plasma 5. As for Wayland, we should not worry about KDE or GNOME not supporting it but rather about nvidia or amd video driver. Nouveau is still slow and I doubt it'll show decent perfomance in near future. thanks all. I still don't understand if Gnome 3.12 should work now with current wayland/weston or not. At least I get this when testing: Jul 27 14:38:28 goto gnome-session[22840]: gnome-session[22840]: WARNING: Unable to find required component 'gnome-shell-wayland' Recompiling gnome-session doesn't help and that file(?) isn't anywhere. I only get a blinking cursor when I log into gdm with gnome on wayland S
Re: [gentoo-user] resolv.conf is different after every reboot
On Jul 27, 2014, at 13:33, Grand Duet grand.d...@gmail.com wrote: 2014-07-27 12:29 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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 # Generated by net-scripts for interface eth0 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 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? 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. It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. Currently, I have no such functions in my /etc/conf.d/net file. Shall I copy them there from /usr/share/doc/netifrc-0.2.2/net.example Could you, please, be more specific on these logger commands too. I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. You can't stop root overwriting a file, root laughs in the face of file permissions. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. I do not have such file. Of course, if you do not mean /etc/resolv.conf But I have posted its content above. Depending on your filesystem a temporary solution to your problem is to setup /etc/resolv.conf correctly and then: chattr +i /etc/resolv.conf After that the content of the file will not change. -- -Matti
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
Dale rdalek1...@gmail.com [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 to erase the drive. As mentioned before, I may could have done that without moving my data but that was to complicated and risky for me at the time. From my understanding tho, until that data is moved off the bad spot so that the drive knows it can do what it needs to, that spot is still going to show up. I don't know of a way to make it test beyond the bad spot either. If you have a drive that you can move that data over to so that you can play with the bad drive, that's what I would do. Once you get it moved, then dd the whole drive, run the test and then see what results you get. I looked at a howto that someone posted or I found and doing it with the data on there just made me nervous. I'm running out of info here. Anyone else provide more help than me? Dale :-) :-) Hi Dale, thanks for the info... I already did this. PLEASE read my previous posting completly. dd failed with an I/O error at that spot.
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 16:10 GMT+03:00 Matti Nykyri matti.nyk...@iki.fi: On Jul 27, 2014, at 13:33, Grand Duet grand.d...@gmail.com wrote: 2014-07-27 12:29 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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 # Generated by net-scripts for interface eth0 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 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? 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. It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. Currently, I have no such functions in my /etc/conf.d/net file. Shall I copy them there from /usr/share/doc/netifrc-0.2.2/net.example Could you, please, be more specific on these logger commands too. I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. You can't stop root overwriting a file, root laughs in the face of file permissions. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. I do not have such file. Of course, if you do not mean /etc/resolv.conf But I have posted its content above. Depending on your filesystem a temporary solution to your problem is to setup /etc/resolv.conf correctly and then: chattr +i /etc/resolv.conf After that the content of the file will not change. Thank you. I will try it if deleting the line dns_domain_lo=mynetwork from my /etc/conf.d/net file will not work. But does chattr +i differ from chmod a-w ? (The latter did not work for me. I use ext4 file system.)
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [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 to erase the drive. As mentioned before, I may could have done that without moving my data but that was to complicated and risky for me at the time. From my understanding tho, until that data is moved off the bad spot so that the drive knows it can do what it needs to, that spot is still going to show up. I don't know of a way to make it test beyond the bad spot either. If you have a drive that you can move that data over to so that you can play with the bad drive, that's what I would do. Once you get it moved, then dd the whole drive, run the test and then see what results you get. I looked at a howto that someone posted or I found and doing it with the data on there just made me nervous. I'm running out of info here. Anyone else provide more help than me? Dale :-) :-) Hi Dale, thanks for the info... I already did this. PLEASE read my previous posting completly. dd failed with an I/O error at that spot. H. I'd be getting my data off there or some sort of backup and then try erasing the whole drive. If that fails as well, then it seems like you need a box and some shipping to get a replacement if it is under warranty. If the dd fails, that sounds like maybe it has a error it can't correct for some reason. I think dd does its thing on a basic level and I have never had it give me a error except for running out of space when it is done. I'm sure if the command you used was wrong, Neil would have picked up on it and said something. So, I don't think you are doing anything wrong, I just think your drive may have even more serious issues than mine had. Unless someone else comes on with a idea on something else to try, I'd be looking for somewhere to put my data and a different drive. If after that you can get it working, well, you got a spare. If not, it was broke anyway. I hope someone else has more ideas. Dale :-) :-)
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
On Sat, Jul 26, 2014 at 9:51 AM, Alan McKinnon alan.mckin...@gmail.com 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. This works easily
as the source disk is local and the kernel can get to it. With NFS, the
source disk is remote and it's the remote kernel that must do the
accessing. RPC is a way to safely ask a remote kernel to do something
and get a result that behaves identical to a local kernel call.
Obviously, this is rather hard to implement correctly.
The original RPC was written by Sun and other newer implementations
exist, like libtirpc - to support useful features like not being stuck
with only UDP. That's what the ti means - Transport Independant.
RPC has been in a state of flux for some time and I too have run into
init-script oddities as things change.
In my case, I have nfs-utils-1.3.0, and rc-update configuredd to start
rpc.statd. This works because
depend() {
...
need portmap
...
}
and in the init.d file for rpcbind:
depend() {
...
provide portmap
}
So rpcbind starts at boot time and all my nfs mounts JustWork
To confirm the above, for nfs-utils-1.2.9-r3.
If I start nfs manually, all the associated daemons start too even
though I haven't added them to default (although idmapd is started
because of /etc/conf.d/nfs):
# ls -1 /etc/init.d/rpc*
/etc/init.d/rpc.idmapd
/etc/init.d/rpc.pipefs
/etc/init.d/rpc.statd
/etc/init.d/rpcbind
# rc-update | grep rpc
# rc-service nfs start
* Starting rpcbind ... [ ok ]
* Starting NFS statd ...[ ok ]
* Setting up RPC pipefs ... [ ok ]
* Starting idmapd ... [ ok ]
* Mounting nfsd filesystem in /proc ... [ ok ]
* Exporting NFS directories ... [ ok ]
* Starting NFS mountd ... [ ok ]
* Starting NFS daemon ... [ ok ]
* Starting NFS smnotify ... [ ok ]
#
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
On Sunday 27 Jul 2014 15:05:53 Dale wrote: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [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 to erase the drive. As mentioned before, I may could have done that without moving my data but that was to complicated and risky for me at the time. From my understanding tho, until that data is moved off the bad spot so that the drive knows it can do what it needs to, that spot is still going to show up. I don't know of a way to make it test beyond the bad spot either. If you have a drive that you can move that data over to so that you can play with the bad drive, that's what I would do. Once you get it moved, then dd the whole drive, run the test and then see what results you get. I looked at a howto that someone posted or I found and doing it with the data on there just made me nervous. I'm running out of info here. Anyone else provide more help than me? Dale :-) :-) Hi Dale, thanks for the info... I already did this. PLEASE read my previous posting completly. dd failed with an I/O error at that spot. H. I'd be getting my data off there or some sort of backup and then try erasing the whole drive. If that fails as well, then it seems like you need a box and some shipping to get a replacement if it is under warranty. If the dd fails, that sounds like maybe it has a error it can't correct for some reason. I think dd does its thing on a basic level and I have never had it give me a error except for running out of space when it is done. I'm sure if the command you used was wrong, Neil would have picked up on it and said something. So, I don't think you are doing anything wrong, I just think your drive may have even more serious issues than mine had. Unless someone else comes on with a idea on something else to try, I'd be looking for somewhere to put my data and a different drive. If after that you can get it working, well, you got a spare. If not, it was broke anyway. I hope someone else has more ideas. Does it still error out if you run the commands in this sequence? mkswap -L swap -f -c /dev/sda2 dd if=/dev/zero of=/dev/sda2 bs=512 conv=notrunc Also, did you try the 'hdparm --write-sector' option that Volker mentioned? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] resolv.conf is different after every reboot
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 dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit local | default localmount | boot loopback | boot metalog | default modules | boot mount-ro | shutdown mtab | boot net.eth0 | default net.lo | boot netmount | default privoxy | default procfs | boot root | boot savecache | shutdown swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit udev-mount | sysinit urandom | boot Everywhere above eth0 has been put instead of its udev predictable name. Do you think that I need carrier_timeout_eth0=20 somewhere in /etc/conf.d/net ? Have you tried disabling network hotplugging in /etc/rc.conf? i.e. setting rc_hotplug=!net.* Sounds like the interfaces are being brought up out of order. Dan
Re: [gentoo-user] resolv.conf is different after every reboot (Got an idea!)
2014-07-27 14:30 GMT+03:00 Grand Duet grand.d...@gmail.com: 2014-07-27 13:39 GMT+03:00 Walter Dnes waltd...@waltdnes.org: 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.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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. A similar problem was noted at... https://forums.gentoo.org/viewtopic-t-816332-start-0.html Like in the thread above, I also have a line dns_domain_lo=mynetwork in my /etc/conf.d/net file. It says nothing to me and I do not remember how it got there. But somewhere on Gentoo forum I have found the following explanation: If you only specify dns_domain_lo=foo and restart the lo interface it will put domain foo in /etc/resolv.conf and remove everything else. So, I guess I should try to remove that line from my /etc/conf.d/net file. But why the system worked fine for about a year *with* this line then? Well, after finishing my main job, I finally got an idea why everything went wrong after the last system update. During my last system update, portage instructed me to add dev-lang/tk-8.5.15 threads line to my /etc/portage/package.use file. Here is the portage message about it: The following USE changes are necessary to proceed: (see package.use in the portage(5) man page for more details) # required by dev-lang/ruby-1.9.3_p484[tk] # required by dev-ruby/rake-0.9.6[ruby_targets_ruby19] # required by dev-lang/ruby-2.0.0_p353 # required by dev-ruby/racc-1.4.9[ruby_targets_ruby20] # required by dev-ruby/rdoc-4.0.1-r1[ruby_targets_ruby19] =dev-lang/tk-8.5.15 threads And in my /etc/portage/package.use file this line has already been commented. So, I just uncommented it. But I do remember that it was commented for a reason, though do not remember exactly why. May be uncommenting that line allowed bringing up lo and eth0 interfaces *in parallel*. If it is the case, then I have an easy explanation why the contents of /etc/resolv.conf file after boot is unpredictable. 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. What do you think? Can you post the contents of your /etc/conf.d/net hostname=myhostname dns_domain_lo=mynetwork config_eth0=My.Local.IP netmask My.Net.Mask broadcast Broadcast.IPof.My.LocalNetwork routes_eth0=default via Local.IPof.My.Gateway dns_servers_eth0=My.First.DNS.IP My.Second.DNS.IP 8.8.8.8 mtu_eth0=1500 # if needed # The network scripts are now part of net-misc/netifrc # In order to avoid sys-apps/openrc-0.12.4 from removing this file, this comment was # added; you can safely remove this comment. Please see # /usr/share/doc/netifrc*/README* for more information. and also the output of the rc-update show command? # rc-update show alsasound | boot bootmisc | boot dbus | default devfs | sysinit dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit local | default localmount | boot loopback | boot metalog | default modules | boot mount-ro | shutdown mtab | boot net.eth0 | default net.lo | boot netmount | default privoxy | default procfs | boot root | boot savecache | shutdown swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit udev-mount | sysinit urandom | boot Everywhere above eth0 has been put instead of its udev predictable name. Do you think that I need carrier_timeout_eth0=20 somewhere in /etc/conf.d/net ? Thank you.
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 17:50 GMT+03:00 Daniel Frey djqf...@gmail.com: 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 dmesg | sysinit fsck | boot hostname | boot hwclock | boot keymaps | boot killprocs | shutdown kmod-static-nodes | sysinit local | default localmount | boot loopback | boot metalog | default modules | boot mount-ro | shutdown mtab | boot net.eth0 | default net.lo | boot netmount | default privoxy | default procfs | boot root | boot savecache | shutdown swap | boot swapfiles | boot sysctl | boot sysfs | sysinit termencoding | boot tmpfiles.dev | sysinit tmpfiles.setup | boot udev | sysinit udev-mount | sysinit urandom | boot Everywhere above eth0 has been put instead of its udev predictable name. Do you think that I need carrier_timeout_eth0=20 somewhere in /etc/conf.d/net ? Have you tried disabling network hotplugging in /etc/rc.conf? i.e. setting rc_hotplug=!net.* No, I have rc_hotplug=* in my /etc/rc.conf file. I will try it, thank you for the tip. Sounds like the interfaces are being brought up out of order. Yes, I have just written about it the following: I finally got an idea why everything went wrong after the last system update. During my last system update, portage instructed me to add dev-lang/tk-8.5.15 threads line to my /etc/portage/package.use file. Here is the portage message about it: The following USE changes are necessary to proceed: (see package.use in the portage(5) man page for more details) # required by dev-lang/ruby-1.9.3_p484[tk] # required by dev-ruby/rake-0.9.6[ruby_targets_ruby19] # required by dev-lang/ruby-2.0.0_p353 # required by dev-ruby/racc-1.4.9[ruby_targets_ruby20] # required by dev-ruby/rdoc-4.0.1-r1[ruby_targets_ruby19] =dev-lang/tk-8.5.15 threads And in my /etc/portage/package.use file this line has already been commented. So, I just uncommented it. But I do remember that it was commented for a reason, though do not remember exactly why. May be uncommenting that line allowed bringing up lo and eth0 interfaces *in parallel*. If it is the case, then I have an easy explanation why the contents of /etc/resolv.conf file after boot is unpredictable. 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 looked into my /etc/rc.conf file, and have found there the option rc_parallel=NO which softens my previous arguments a bit, but not completely: may be lo and eth0 are brought up not in parallel but in different order, anyway.
Re: [gentoo-user] resolv.conf is different after every reboot
On Jul 27, 2014, at 16:39, Grand Duet grand.d...@gmail.com wrote: 2014-07-27 16:10 GMT+03:00 Matti Nykyri matti.nyk...@iki.fi: On Jul 27, 2014, at 13:33, Grand Duet grand.d...@gmail.com wrote: 2014-07-27 12:29 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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 # Generated by net-scripts for interface eth0 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 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? 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. It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. Currently, I have no such functions in my /etc/conf.d/net file. Shall I copy them there from /usr/share/doc/netifrc-0.2.2/net.example Could you, please, be more specific on these logger commands too. I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. You can't stop root overwriting a file, root laughs in the face of file permissions. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. I do not have such file. Of course, if you do not mean /etc/resolv.conf But I have posted its content above. Depending on your filesystem a temporary solution to your problem is to setup /etc/resolv.conf correctly and then: chattr +i /etc/resolv.conf After that the content of the file will not change. Thank you. I will try it if deleting the line dns_domain_lo=mynetwork from my /etc/conf.d/net file will not work. But does chattr +i differ from chmod a-w ? (The latter did not work for me. I use ext4 file system.) Yes it does. Ext-filesystem supports immutable bit which is enforced by kernel so even root can't modify the file in any way. -i unsets the bit. -- -Matti
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
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 complicated because the devs are solving problems that I don't understand or even know about. I double your search for understanding ... my various efforts to set up NFSv4 for sharing stuff in my LAN also lead to unstable behavior and frustration. 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 another example ;-) Additional in my context: using systemd ... so there are other (different?) dependencies at work and services started. I'd be happy to get that working in a reliable way. I don't remember unstable behavior with NFS (v2 back then?) when we used it at a company I worked for in the 90s. Stefan
[gentoo-user] Re: resolv.conf is different after every reboot
Grand Duet grand.duet at 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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 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. and also the output of the rc-update show command? # rc-update show mtab | boot net.eth0 | default net.lo | boot netmount | default Everywhere above eth0 has been put instead of its udev predictable name. Do you think that I need carrier_timeout_eth0=20 somewhere in /etc/conf.d/net ? I do not try and force the eth' names onto an interface I have these in rc-status: mtab | boot net.enp5s0 | default netmount | default I just look at the dmesg output and use the new, default funky names. You can read up on these evolving interface names by googling. Here is one link (often posted to this user group) to get you started: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ hth, James
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
Mick michaelkintz...@gmail.com [14-07-27 16:36]: On Sunday 27 Jul 2014 15:05:53 Dale wrote: meino.cra...@gmx.de wrote: Dale rdalek1...@gmail.com [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 to erase the drive. As mentioned before, I may could have done that without moving my data but that was to complicated and risky for me at the time. From my understanding tho, until that data is moved off the bad spot so that the drive knows it can do what it needs to, that spot is still going to show up. I don't know of a way to make it test beyond the bad spot either. If you have a drive that you can move that data over to so that you can play with the bad drive, that's what I would do. Once you get it moved, then dd the whole drive, run the test and then see what results you get. I looked at a howto that someone posted or I found and doing it with the data on there just made me nervous. I'm running out of info here. Anyone else provide more help than me? Dale :-) :-) Hi Dale, thanks for the info... I already did this. PLEASE read my previous posting completly. dd failed with an I/O error at that spot. H. I'd be getting my data off there or some sort of backup and then try erasing the whole drive. If that fails as well, then it seems like you need a box and some shipping to get a replacement if it is under warranty. If the dd fails, that sounds like maybe it has a error it can't correct for some reason. I think dd does its thing on a basic level and I have never had it give me a error except for running out of space when it is done. I'm sure if the command you used was wrong, Neil would have picked up on it and said something. So, I don't think you are doing anything wrong, I just think your drive may have even more serious issues than mine had. Unless someone else comes on with a idea on something else to try, I'd be looking for somewhere to put my data and a different drive. If after that you can get it working, well, you got a spare. If not, it was broke anyway. I hope someone else has more ideas. Does it still error out if you run the commands in this sequence? mkswap -L swap -f -c /dev/sda2 dd if=/dev/zero of=/dev/sda2 bs=512 conv=notrunc Also, did you try the 'hdparm --write-sector' option that Volker mentioned? -- Regards, Mick Hi Mick, thanks for your reply on the topic. I executed the mkswap/dd combo a several times today. Since I have no logs I repeated again. Here are the results: solfire:/home/usermkswap -L swap -f -c /dev/sda2 1 bad page mkswap: /dev/sda2: warning: wiping old swap signature. Setting up swapspace version 1, size = 6291448 KiB LABEL=swap, UUID=e742c0a6-862c-41e9-be4b-698b33c5a236 solfire:/home/userdd if=/dev/zero of=/dev/sda2 bs=512 conv=notrunc dd: error writing ‘/dev/sda2’: Input/output error 1669369+0 records in 1669368+0 records out 854716416 bytes (855 MB) copied, 28.4799 s, 30.0 MB/s [1]24047 exit 1 dd if=/dev/zero of=/dev/sda2 bs=512 conv=notrunc solfire:/home/user I am a little anxious about the hdparm command... For me it is unclear what sector is meant: smartclt says: Num Test_DescriptionStatus Remaining LifeTime(hours) LBA_of_first_error # 1 Selective offline Completed: read failure 90% 14500 4288352511 From a previous posting I learned that LBA in this case is the byte counter. The sector is therefore 4288352511/512=8375688 However as a result of the dd command above I found this in the dmesg log: [48588.471905] end_request: I/O error, dev sda, sector 1773816 Now...what sector count fits what sector count ... ? I will not fire zeroes towards my hd this way before I know exactly to what I am shooting at... ;) Any light in all this shadow is heartly appreciated... Best regards, mcc
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
On 27 July 2014 18:25:24 CEST, Stefan G. Weichinger li...@xunil.at 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 that I have no idea how NFS works, and each new version is more complicated because the devs are solving problems that I don't understand or even know about. I double your search for understanding ... my various efforts to set up NFSv4 for sharing stuff in my LAN also lead to unstable behavior and frustration. 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 another example ;-) Additional in my context: using systemd ... so there are other (different?) dependencies at work and services started. I'd be happy to get that working in a reliable way. I don't remember unstable behavior with NFS (v2 back then?) when we used it at a company I worked for in the 90s. Stefan I use NFS for filesharing between all wired systems at home. Samba is only used for MS Windows and laptops. Few things I always make sure are valid: - One partition per NFS share - No NFS share is mounted below another one - I set the version to 3 on the clients - I use LDAP for the user accounts to ensure the UIDs and GIDs are consistent. NFS4 requires all the exports to be under a single foldertree. I haven't had any issues in the past 7+ years with this and in the past 5+ years I had portage, distfiles and packages shared. /etc/portage is symlinked to a NFS share as well, allowing me to create binary packages on a single host (inside a chroot) which are then used to update the different machines. If anyone wants a more detailed description of my setup. Let me know and I will try to write something up. Kind regards Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
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 another example ;-) As so often ... my fault: thinkpads did have NFSv4 in the kernel, but no nfs-utils installed ... ;-) sorry, S
Re: [gentoo-user] Re: resolv.conf is different after every reboot
2014-07-27 19:33 GMT+03:00 James wirel...@tampabay.rr.com: Grand Duet grand.duet at 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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I set my nameservers all manually in this file and they do not every change. I also thought that /etc/resolv.conf do not change at every reboot before run into this problem and tried to write down my own /etc/resolv.conf I do not run systemd. I'm not sure of your issue(s) but, historically, resolv.conf should not be displaying this behavior. Historically, may be, but currently the main net config file is /etc/config.d/net, at least for openRC. /etc/resolv.conf is produced at every boot from /etc/config.d/net by net-scripts. and also the output of the rc-update show command? # rc-update show mtab | boot net.eth0 | default net.lo | boot netmount | default Everywhere above eth0 has been put instead of its udev predictable name. Do you think that I need carrier_timeout_eth0=20 somewhere in /etc/conf.d/net ? I do not try and force the eth' names onto an interface I have these in rc-status: mtab | boot net.enp5s0 | default netmount | default I just look at the dmesg output and use the new, default funky names. You can read up on these evolving interface names by googling. You did not understood my remark above correctly: in my system config files I do use these fu*ky names but instead of exposing them to the whole Internet I have changed a fu*ky name for eth0 back to eth0 for better clarity and security. :) Here is one link (often posted to this user group) to get you started: http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ hth, James
Re: [gentoo-user] resolv.conf is different after every reboot
On 27/07/2014 12:30, Grand Duet wrote: 2014-07-27 13:39 GMT+03:00 Walter Dnes waltd...@waltdnes.org: 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.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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. A similar problem was noted at... https://forums.gentoo.org/viewtopic-t-816332-start-0.html Like in the thread above, I also have a line dns_domain_lo=mynetwork in my /etc/conf.d/net file. It says nothing to me and I do not remember how it got there. But somewhere on Gentoo forum I have found the following explanation: If you only specify dns_domain_lo=foo and restart the lo interface it will put domain foo in /etc/resolv.conf and remove everything else. You can specify dns_domain - without an interface suffix - which ought to prevent this behaviour. However, you'd be better off getting rid of it altogether. All the option does is define the suffix(es) that are appended by the resolver under certain conditions. These conditions are as follows: a) the initial name isn't qualified (contains no dots) [1] b) the initial name could not be resolved (NXDOMAIN response) Making up fake domains for this setting, as many Gentoo users are induced into doing, serves no purpose. Let's assume that I have fakedomain as a search domain in resolv.conf. Let's see what happens for a short name: $ host -t A -v shorthost | grep -e Trying -e NX Trying shorthost.fakedomain Trying shorthost Host shorthost not found: 3(NXDOMAIN) Result: two spurious DNS lookups, each resulting in NXDOMAIN. You may use tcpdump to confirm that there are indeed two. Now, let's try looking up a fully qualified hostname that happens not to exist: $ host -t A -v nonexistent.google.com | grep -e Trying -e NX Trying nonexistent.google.com Trying nonexistent.google.com.fakedomain Host nonexistent.google.com not found: 3(NXDOMAIN) Result: The first lookup fails and is immediately followed by an another lookup that is completely and utterly useless. Had a search domain _not_ been defined, then the resolver could have concluded its efforts after the first NXDOMAIN response. The bottom line is that it only makes sense to define search domain(s) if the following two conditions hold true. 1) You want to be able to resolve hostnames in their short form 2) Records for said names will exist in a known, *valid* domain Otherwise, don't bother and leave it to the DHCP server to decide [2]. While I haven't looked at the handbook lately, it has had a history of prescribing dns/domain related options without adequate explanation and, in some cases, with outright misleading information [3]. On a related note, some people prefer to manage resolv.conf themselves and it is not initially obvious as to how to do this while also using DHCP. Trying to make the file immutable is not a proper approach. The trick is as follows: * Specify dhcpd_eth0=nodns (do this for any dhcp-using interfaces) * Do not specify any dns or nameserver related settings in conf.d/net The netifrc scripts will then leave resolv.conf alone. --Kerin [1] Check out the ndots option in the resolv.conf(5) manpage [2] DHCP servers may specify a search domain for clients with option 15 [3] https://bugs.gentoo.org/show_bug.cgi?id=341349
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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 am no native english speaker...sorry...:) Suppose - as in my case - I have not yert managed to urge the hd to map the bad sector off... Now...all tests abort after scanning 10% of the disk. Disk health status is reported as PASSED...cause only one bad sector has been found. But 90% of the space of the disk has never been scanned. Read the smartctl message again, it's not reporting a bad sector, it's reporting a read failure. Bad sectors are detected and mapped out in the background, you have something more serious, something that prevents the drive scanning past this point. If it's less then two years old, send it back. Most drive manufacturers have a form on their web site where you can input the serial number and see the warranty status. If you can return it so so, ASAP. -- Neil Bothwick Press every key to continue. signature.asc Description: PGP signature
Re: [gentoo-user] resolv.conf is different after every reboot
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 brought up correctly and then the config is overwritten by the lo config. I'd suggest going with the suggestion of disabling hotplugging for net.* interfaces. what do your logs say? Could you, please, be more precise where to look for logs. /var/log/messages, dmesg, the standard places. It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. Currently, I have no such functions in my /etc/conf.d/net file. Shall I copy them there from /usr/share/doc/netifrc-0.2.2/net.example Yes, they are run are various stages of bringing up the interface. Could you, please, be more specific on these logger commands too. I meant to add a logger call to each function to see how far it gets logger eth0 going up logger eth0 up logger eth0 failed or something like that. but it appears this is moot and eth0 is up successfully. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. I do not have such file. Of course, if you do not mean /etc/resolv.conf But I have posted its content above. I meant /etc/resolvconf.conf, which you were asked for before, but as you don't have it, the problem isn't there. -- Neil Bothwick Vital papers will demonstrate their vitality by moving to where you can't find them. signature.asc Description: PGP signature
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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 point I tried to explain (I am no native english speaker...sorry...:) Suppose - as in my case - I have not yert managed to urge the hd to map the bad sector off... Now...all tests abort after scanning 10% of the disk. Disk health status is reported as PASSED...cause only one bad sector has been found. But 90% of the space of the disk has never been scanned. Read the smartctl message again, it's not reporting a bad sector, it's reporting a read failure. Bad sectors are detected and mapped out in the background, you have something more serious, something that prevents the drive scanning past this point. If it's less then two years old, send it back. Most drive manufacturers have a form on their web site where you can input the serial number and see the warranty status. If you can return it so so, ASAP. Glad you noticed something I didn't. I just wish it was better news for the OP. 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 the arm moves the heads across the platter. If I get what you are saying, it's like the heads get to a certain point, about 10%, and then stop. Thanks. Dale :-) :-)
Re: [gentoo-user] NFS tutorial for the brain dead sysadmin?
On 27/07/2014 17:55, J. Roeleveld wrote: On 27 July 2014 18:25:24 CEST, Stefan G. Weichinger li...@xunil.at 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 that I have no idea how NFS works, and each new version is more complicated because the devs are solving problems that I don't understand or even know about. I double your search for understanding ... my various efforts to set up NFSv4 for sharing stuff in my LAN also lead to unstable behavior and frustration. 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 another example ;-) Additional in my context: using systemd ... so there are other (different?) dependencies at work and services started. I'd be happy to get that working in a reliable way. I don't remember unstable behavior with NFS (v2 back then?) when we used it at a company I worked for in the 90s. Stefan I use NFS for filesharing between all wired systems at home. Samba is only used for MS Windows and laptops. Few things I always make sure are valid: - One partition per NFS share - No NFS share is mounted below another one - I set the version to 3 on the clients - I use LDAP for the user accounts to ensure the UIDs and GIDs are consistent. These are generally good recommendations. I'd just like to make a few observations. The problems associated with not observing the first constraint (one filesystem per export) can be alleviated by setting an explicit fsid. Doing so can also help to avoid stale handles on the client side if the backing filesystem changes - something that is very useful in a production environment. Therefore, I tend to start at 1 and increment with each newly added export. For example:- /export/foo *(async,no_subtree_check,fsid=1) /export/foo/bar *(async,no_subtree_check,fsid=2) /export/baz *(async,no_subtree_check,fsid=3) If using NFSv3, I'd recommend using nolock as a mount option unless there is a genuine requirement for locks to be co-ordinated. Such locks are only advisory and are of questionable value. Using nolock simplifies the requirements on both server and client side, and is beneficial for performance. NFSv3/UDP seems to be limited to a maximum read/write block size of 32768 in Linux, which will be negotiated by default. Using TCP, the upper bound will be the value of /proc/fs/nfsd/max_block_size on the server. Its value may be set to 1048576 at the most. NFSv3/TCP is problematic so I would recommend NFSv4 if TCP is desired as a transport protocol. NFSv4 provides a useful uid/gid mapping feature that is easier to set up and maintain than nss_ldap. NFS4 requires all the exports to be under a single foldertree. This is a myth: http://linuxcostablanca.blogspot.co.uk/2012/02/nfsv4-myths-and-legends.html. Exports can be defined and consumed in the same manner as with NFSv3. I haven't had any issues in the past 7+ years with this and in the past 5+ years I had portage, distfiles and packages shared. /etc/portage is symlinked to a NFS share as well, allowing me to create binary packages on a single host (inside a chroot) which are then used to update the different machines. If anyone wants a more detailed description of my setup. Let me know and I will try to write something up. Kind regards Joost --Kerin
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 21:14 GMT+03:00 Kerin Millar kerfra...@fastmail.co.uk: On 27/07/2014 12:30, Grand Duet wrote: 2014-07-27 13:39 GMT+03:00 Walter Dnes waltd...@waltdnes.org: 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.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 nameserver My.First.DNS-Server.IP nameserver My.Second.DNS-Server.IP nameserver 8.8.8.8 I tried to chmod this file to be unwrittable even for root but after a reboot it have been overwritten anyway. A similar problem was noted at... https://forums.gentoo.org/viewtopic-t-816332-start-0.html Like in the thread above, I also have a line dns_domain_lo=mynetwork in my /etc/conf.d/net file. It says nothing to me and I do not remember how it got there. But somewhere on Gentoo forum I have found the following explanation: If you only specify dns_domain_lo=foo and restart the lo interface it will put domain foo in /etc/resolv.conf and remove everything else. You can specify dns_domain - without an interface suffix - which ought to prevent this behaviour. However, you'd be better off getting rid of it altogether. It is my first reboot after commenting out the line dns_domain_lo=mynetwork and so far it went good. Moreover, the file /etc/resolv.conf has not been overwritten. I still have to check if everything else works fine and if I will get the same result on the next reboot but I hope that the problem has been solved. All the option does is define the suffix(es) that are appended by the resolver under certain conditions. These conditions are as follows: a) the initial name isn't qualified (contains no dots) [1] b) the initial name could not be resolved (NXDOMAIN response) Making up fake domains for this setting, as many Gentoo users are induced into doing, serves no purpose. Let's assume that I have fakedomain as a search domain in resolv.conf. Let's see what happens for a short name: $ host -t A -v shorthost | grep -e Trying -e NX Trying shorthost.fakedomain Trying shorthost Host shorthost not found: 3(NXDOMAIN) Result: two spurious DNS lookups, each resulting in NXDOMAIN. You may use tcpdump to confirm that there are indeed two. Now, let's try looking up a fully qualified hostname that happens not to exist: $ host -t A -v nonexistent.google.com | grep -e Trying -e NX Trying nonexistent.google.com Trying nonexistent.google.com.fakedomain Host nonexistent.google.com not found: 3(NXDOMAIN) Result: The first lookup fails and is immediately followed by an another lookup that is completely and utterly useless. Had a search domain _not_ been defined, then the resolver could have concluded its efforts after the first NXDOMAIN response. The bottom line is that it only makes sense to define search domain(s) if the following two conditions hold true. 1) You want to be able to resolve hostnames in their short form 2) Records for said names will exist in a known, *valid* domain Otherwise, don't bother and leave it to the DHCP server to decide [2]. While I haven't looked at the handbook lately, it has had a history of prescribing dns/domain related options without adequate explanation and, in some cases, with outright misleading information [3]. On a related note, some people prefer to manage resolv.conf themselves and it is not initially obvious as to how to do this while also using DHCP. Trying to make the file immutable is not a proper approach. The trick is as follows: * Specify dhcpd_eth0=nodns (do this for any dhcp-using interfaces) * Do not specify any dns or nameserver related settings in conf.d/net The netifrc scripts will then leave resolv.conf alone. Thank you for the nice explanation that convinced me that I do not need that feature at all. I do not use DHCP at all but I got the general point. [1] Check out the ndots option in the resolv.conf(5) manpage [2] DHCP servers may specify a search domain for clients with option 15 [3] https://bugs.gentoo.org/show_bug.cgi?id=341349
Re: [gentoo-user] resolv.conf is different after every reboot
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 looked into my /etc/rc.conf file, and have found there the option rc_parallel=NO which softens my previous arguments a bit, but not completely: may be lo and eth0 are brought up not in parallel but in different order, anyway. The first thing I do on any new build is disable network hotplugging in /etc/rc.conf, as I've run into lots of problems, especially if you have multiple network devices and need to bring them up in a specific order. udev processes these items and apparently brings the interfaces up on its own unless you tell it otherwise (the !net.* in rc.conf). I've just gotten used to disabling that automagic because I want things to start in a certain order and udev can mess that up. During boot, you'll see something like 'processing events' and that's when udev is automagically doing it's start. From what I recall, this happens before the boot runlevel. So yes, it can mess things up as you've seen. I've never had the issue you have, even though I use a static ip, routes and dns servers in /etc/conf.d/net, but I would presume that this is just udev. FYI it doesn't always process things in the same order, as I've experienced with udev and my TV tuner cards... it can be random. Dan
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 22:13 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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 brought up correctly and then the config is overwritten by the lo config. I think so. As I have already reported in another reply to this thread, it is my first reboot after commenting out the line dns_domain_lo=mynetwork and so far it went good. Moreover, the file /etc/resolv.conf has not been overwritten. I still have to check if everything else works fine and if I will get the same result on the next reboot but I hope that the problem has been solved. But it looks like a bug in the net csript. Why lo configuration should overwrite eth0 configuration at all? I'd suggest going with the suggestion of disabling hotplugging for net.* interfaces. Thank you for the advice, I will try this if it appears that the problem has not been solved yet. what do your logs say? Could you, please, be more precise where to look for logs. /var/log/messages, dmesg, the standard places. It might be worth putting logger commands in preup(), postup() and failup() in conf.d/net. Currently, I have no such functions in my /etc/conf.d/net file. Shall I copy them there from /usr/share/doc/netifrc-0.2.2/net.example Yes, they are run are various stages of bringing up the interface. Could you, please, be more specific on these logger commands too. I meant to add a logger call to each function to see how far it gets logger eth0 going up logger eth0 up logger eth0 failed or something like that. but it appears this is moot and eth0 is up successfully. Thank you for this explanation as well. I will try it a bit later but I feel that before doing it I should refresh my knowledge of scripts in general. BTW, I'm not sure if it's still relevant, but I don't think you ever posted the contents of /etc/resolvconf.conf, if it exists. I do not have such file. Of course, if you do not mean /etc/resolv.conf But I have posted its content above. I meant /etc/resolvconf.conf, which you were asked for before, but as you don't have it, the problem isn't there. -- Neil Bothwick Vital papers will demonstrate their vitality by moving to where you can't find them.
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-27 23:28 GMT+03:00 Daniel Frey djqf...@gmail.com: 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 looked into my /etc/rc.conf file, and have found there the option rc_parallel=NO which softens my previous arguments a bit, but not completely: may be lo and eth0 are brought up not in parallel but in different order, anyway. The first thing I do on any new build is disable network hotplugging in /etc/rc.conf, as I've run into lots of problems, especially if you have multiple network devices and need to bring them up in a specific order. udev processes these items and apparently brings the interfaces up on its own unless you tell it otherwise (the !net.* in rc.conf). I've just gotten used to disabling that automagic because I want things to start in a certain order and udev can mess that up. Thank you. Now, I will be aware of this issue and disabling hotplugging in this way will be the next thing I will try if the problem will not be solved by just removing dns_domain_lo=mynetwork from my /etc/conf.d/net file. It is not because I am stubborn (though it may be :) but because I want to do changes step by step to identify the cause of the problem. P.S. As far as I know, I have only one network interface on this computer, eth0, not counting lo, of course. :) During boot, you'll see something like 'processing events' and that's when udev is automagically doing it's start. From what I recall, this happens before the boot runlevel. So yes, it can mess things up as you've seen. I've never had the issue you have, even though I use a static ip, routes and dns servers in /etc/conf.d/net, but I would presume that this is just udev. FYI it doesn't always process things in the same order, as I've experienced with udev and my TV tuner cards... it can be random. Thank you for your explanations once more.
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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 the arm moves the heads across the platter. If I get what you are saying, it's like the heads get to a certain point, about 10%, and then stop. I don't think so, as I've seen this sort of thing on a drive but still been able to access ~all my data. It seems that the SMART tests are a little stupid in this respect and give up when they decide a drive is broken, as opposed to failing. -- Neil Bothwick Irritable? Who the bloody hell are you calling irritable? signature.asc Description: PGP signature
Re: [gentoo-user] resolv.conf is different after every reboot
On 27/07/2014 21:38, Grand Duet wrote: 2014-07-27 22:13 GMT+03:00 Neil Bothwick n...@digimed.co.uk: 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 brought up correctly and then the config is overwritten by the lo config. I think so. As I have already reported in another reply to this thread, it is my first reboot after commenting out the line dns_domain_lo=mynetwork and so far it went good. Moreover, the file /etc/resolv.conf has not been overwritten. I still have to check if everything else works fine and if I will get the same result on the next reboot but I hope that the problem has been solved. But it looks like a bug in the net csript. Why lo configuration should overwrite eth0 configuration at all? I would consider it be a documentation bug at the very least. Being able to propagate different settings to resolv.conf depending on whether a given interface is up may be of value for some esoteric use-case, although I cannot think of one off-hand. Some other distros use the resolvconf application to handle these nuances. In any case, it is inexplicable that the user is invited to define dns_domain for the lo interface. Why would one want to push settings to resolv.conf based on the mere fact that the loopback interface has come up? Also, it would be a great deal less confusing if the option were named dns_search. I think that the handbook should refrain from mentioning the option at all, for the reasons stated in my previous email. Those who know that they need to define a specific search domain will know why and be capable of figuring it out. It's too bad that the handbook is still peddling the notion that this somehow has something to do with 'setting' the domain name. It is tosh of the highest order. --Kerin
Re: [gentoo-user] Re: resolv.conf is different after every reboot
On Sun, Jul 27, 2014 at 12:33 PM, James wirel...@tampabay.rr.com 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.conf these days. Instead systemd-resolved can create one for you in /run, and if you want you can symlink to it from /etc/resolv.conf. Rich
Re: [gentoo-user] wxGTK compilation fails missing thread.h
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.
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
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 drives apart so I know how the arm moves the heads across the platter. If I get what you are saying, it's like the heads get to a certain point, about 10%, and then stop. I don't think so, as I've seen this sort of thing on a drive but still been able to access ~all my data. It seems that the SMART tests are a little stupid in this respect and give up when they decide a drive is broken, as opposed to failing. So, it isn't likely a mechanical failure but *maybe* some sort of firmware/software/or other type of failure? Interesting. The reason I was asking is because it seems the OP is using the drive, even booting from it I think, which makes me think it is still able to access the data but yet the SMART test can't get to the same area. It was a bit confusing since it wasn't logical. One type of access is working while another isn't. Odd. I realize that short of some techy person taking the drive apart, we won't likely really know why it failed the test but just curious as to what options were there as to the failure. Well, run into something interesting everyday. I hope the OP can get his data off there before this gets worse. I guess if nothing else, SMART showed that something isn't right, is likely failing and needs attention. If SMART is correct. ;-) Dale :-) :-)
Re: [gentoo-user] Contradictionary behaviour of SMART on hds ?!?
2014-07-27 5:29 GMT-06:00 meino.cra...@gmx.de: 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 this part, if i understood dd reported failing at 4288352511 bytes in your drive, make a loopback device with an offset past that sector to try dd keep going, or run dd with skip up to that sector with. # losetup -o 428835252 /dev/loop1 /dev/your_hdd just to give an example, calculate an apropiate byte count for a 1 sector above, and then use dd on /dev/loop1
Re: [gentoo-user] wxGTK compilation fails missing thread.h
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 my system: du -a /usr/*|sed '/\/thread.h$/!d;s/.*\t//' /usr/include/event2/thread.h /usr/include/ruby-2.0.0/ruby/thread.h /usr/include/wx-2.8/wx/thread.h /usr/lib/perl5/5.16.3/i686-linux/CORE/thread.h /usr/src/linux-3.12.21-gentoo-r1/include/config/generic/smp/idle/thread.h /usr/src/linux-3.12.21-gentoo-r1/tools/perf/util/thread.h
