[gentoo-user] Setting PYTHON_TARGETS in make.conf is not supported?
Just now I have tried to manually set PYTHON_TARGETS="python2_7 python3_6" PYTHON_SINGLE_TARGET="python3_6" in /etc/portage/make.conf and got the following error: # emerge --update --deep --with-bdeps=y --newuse --backtrack=120 --ask world These are the packages that would be merged, in order: Calculating dependencies... done! !!! The ebuild selected to satisfy "app-text/asciidoc" has unmet requirements. - app-text/asciidoc-8.6.10::gentoo USE="-examples -graphviz -highlight -test" ABI_X86="(64)" PYTHON_SINGLE_TARGET="(-pypy) -python2_7" PYTHON_TARGETS="python2_7 (-pypy)" The following REQUIRED_USE flag constraints are unsatisfied: exactly-one-of ( python_single_target_pypy python_single_target_python2_7 ) The above constraints are a subset of the following complete expression: exactly-one-of ( python_single_target_pypy python_single_target_python2_7 ) python_single_target_pypy? ( python_targets_pypy ) python_single_target_python2_7? ( python_targets_python2_7 ) (dependency required by "app-text/dvisvgm-2.1.3::gentoo" [installed]) (dependency required by "app-text/texlive-2017::gentoo[extra]" [installed]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument]) which is similar to those errors I got while trying to set PYTHON_TARGETS="python2_7 python3_5" PYTHON_SINGLE_TARGET="python3_5" before switching yesterday from python-3.5 to python-3.6 target. Does it mean that setting python targets in /etc/portage/make.conf is not supported any more? P.S. Currently my system is up-to-date and already switched to python-3.6 targets.
Re: [gentoo-user] Any real need to switch python targets back and forth every month?
2018-07-26 16:04 GMT+03:00 Rich Freeman : > On Thu, Jul 26, 2018 at 8:45 AM Grand Duet wrote: >> > Did this even impact the stable branch? >> >> Yes. > > Hmm, I suspect I didn't sync before it was reverted. Either that or I > noticed the noise on the lists and waited a day. > > This is one issue with our news - it isn't really realtime. If we > want people to hold the presses and re-sync they don't get that notice > until they've already re-synced. > >> May be, adding some additional "almost stable" level between >> "stable" and "unstable" one to make "stable" stable indeed? > > If anything it seems like the proposal to drop stable comes along > every few years. I don't see anybody being eager to add another level > of QA. A big practical issue would be that unless people are actually > using the two lower levels significantly then nothing is actually > getting checked before going to stable. > > There is really no reason you couldn't have a release-based Gentoo > derivative. Everything is in git. All "somebody" needs to do is > start a repo with a release-driven workflow that treats Gentoo as the > upstream master branch, targeting changes for release branches and > then doing release candidates and QA/etc. Then those release-based > users would sync from there instead of the upstream Gentoo repo. > Ideally somebody would bundle it with a reference binary repo that > people could optionally sync from to speed installs for packages where > they're not changing USE flags. > > The problem is that this all takes quite a bit of work, and I'm > skeptical that it would ever happen. However, for larger Gentoo > deployments in production environments I suspect most are doing things > more-or-less in this fashion, but just with the packages they care > about. If somebody has 100 production servers running Gentoo I doubt > they are set to just sync from us. Rather they would set up their own > mirror and carefully test portage snapshots before they go rolling > them out. Ok. Thank you for your reply.
Re: [gentoo-user] Any real need to switch python targets back and forth every month?
2018-07-26 16:01 GMT+03:00 Neil Bothwick : > On Thu, 26 Jul 2018 13:44:28 +0300, Grand Duet wrote: > >> Before switching python_targets for the first time, you could use your >> news system to inform Gentoo users that >> 1) you are switching python_targets > > Like the one on May 22nd titled "Python 3.6 to become the default target"? > >> and so, those who really want to have a stable Gentoo system should >> 1) do such and such changes to their config files and > > Like in the aforementioned news item? > > FWIW I had no problem with the profile change and locked my system at 3.6 > to save switching back when the profile did so. Ok. There was such a news. However, I have actually followed the following recommendation in it, before the last python_target switch from 3.5 to 3.6: If you would like to postpone the switch to Python 3.6, you can copy the current value of PYTHON_TARGETS and/or PYTHON_SINGLE_TARGET to /etc/portage/make.conf or its equivalent: PYTHON_TARGETS="python2_7 python3_5" PYTHON_SINGLE_TARGET="python3_5" but the emerge gave strange errors mentioned above and aborted.
Re: [gentoo-user] Any real need to switch python targets back and forth every month?
2018-07-26 15:01 GMT+03:00 Rich Freeman : > On Thu, Jul 26, 2018 at 6:44 AM Grand Duet wrote: >> >> Before switching python_targets for the first time, you could use your >> news system to inform Gentoo users that >> 1) you are switching python_targets >> 2) it may be "a bit premature", > > If anybody thought that it was a bit premature it wouldn't have been > done at all. It is exactly what is bad: nobody expects any troubles where they definitely should be! Anyway, it is a good idea to write a news on changing python_targets and major version of gcc, even if no developper expects any troubles, because we already know their predictive (dis)ability. :) >> and so, those who really want to have a stable Gentoo system should >> 1) do such and such changes to their config files and >> 2) wait about 3 months untill all the dust will settle. > > Did this even impact the stable branch? Yes. > If you want stable Gentoo, you probably shouldn't have edited make.conf > to set your keywords to ~arch. I did not. Moreover, currently I have no single unstable package installed on my system. >> P.S. The said above together with the recent Gentoo signing key issue >> and sometimes "corrupted" daily portage snapshots that I download by >> emerge-webrsync make me think that even so called "stable" Gentoo >> lacks quality control and cannot be considered as stable and suted for >> those that really need a stable system. > > Well, most people stick with RHEL/CentOS or Debian Stable for that > kind of experience, where changes only happen on releases with > significant QA, and backporting of fixes. That simply isn't the kind > of experience Gentoo aims to deliver. It is sad to hear. Actually, I don't want to change the Linux distro. A bit more "due diligence" from Gentoo devs will be enough. :) May be, adding some additional "almost stable" level between "stable" and "unstable" one to make "stable" stable indeed? In any case, if I will leave Gentoo, it will be in favour of some BSD, not a Linux disro.
Re: [gentoo-user] Any real need to switch python targets back and forth every month?
2018-07-25 18:20 GMT+03:00 Mike Gilbert : > On Wed, Jul 25, 2018 at 7:58 AM Grand Duet wrote: >> >> After today's emerge-webrsync, I have found that python_targets >> and python_single_targets use flags have been changed again >> from python3_5 to python3_6, which leads to a lot of recompilation. >> >> It already happened last month and a week later the both use flags >> was changed back, again with a lot of recompilations. >> >> And it was not the first time! >> >> Is any real need to switch python_targets and python_single_target >> back and forth every month? >> > > It's very simple: > > 1. The default was switched to python3.6. This was probably a bit premature. > 2. People complained that this broke their systems, so we reverted the > default back to python3.5. > 3. The problems were fixed, so we switched the default back to python3.6. > > Sorry to have wasted your precious computing time, but hey, people > make mistakes sometimes. Before switching python_targets for the first time, you could use your news system to inform Gentoo users that 1) you are switching python_targets 2) it may be "a bit premature", and so, those who really want to have a stable Gentoo system should 1) do such and such changes to their config files and 2) wait about 3 months untill all the dust will settle. By the way, last time I have tried to set PYTHON_SINGLE_TARGET="python3_5" PYTHON_TARGETS="python2_7 python3_5" in my /etc/portage/make.conf and I got a vary strange errors from emerge afterwards: every time the # emerge --update --deep --with-bdeps=y --newuse --backtrack=120 --ask world command was run, a *new* package complained about something and system update aborted. I guess from that that the syntax of setting python_targets has been changed lately (may be, it should now be set only in package.use) but nobody informed Gentoo users about it. P.S. The said above together with the recent Gentoo signing key issue and sometimes "corrupted" daily portage snapshots that I download by emerge-webrsync make me think that even so called "stable" Gentoo lacks quality control and cannot be considered as stable and suted for those that really need a stable system.
[gentoo-user] Any real need to switch python targets back and forth every month?
After today's emerge-webrsync, I have found that python_targets and python_single_targets use flags have been changed again from python3_5 to python3_6, which leads to a lot of recompilation. It already happened last month and a week later the both use flags was changed back, again with a lot of recompilations. And it was not the first time! Is any real need to switch python_targets and python_single_target back and forth every month?
Re: [gentoo-user] resolv.conf is different after every reboot
2014-07-28 1:00 GMT+03:00 Kerin Millar kerfra...@fastmail.co.uk: 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. I agree with you. But how to put it all in the right ears?
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
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
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] 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] 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] 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
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
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.
[gentoo-user] Something went wrong with DNS, plz help!
The first reboot after recent update of the system have shown that I cannot open any webpage in Firefox. More exactly, Firefox or my system cannot any more resolve URL to IP address (sorry if I use wrong terms). Thus, host gmail.com gives: ;; connection timed out no servers could be reached Nevertheless dig @8.8.8.8 gmail.com reports the corresponding IP adresses. I have not changed any my network settings and my /etc/conf.d/net file still contains list of my DNS servers that contains server 8.8.8.8 as well but somehow it is not enough any more. :( During my last system update, I suddenly found that I had to update about 150 packages, what was a little bit strange as I update my system at least once a week. I have attributed that to the remnants of gnome2 (now I am using fxce4) that I have not cleaned completely and that is now going to update. So, I deviated a bit from my usual system update routine trying to fix that. Nevertheless, as to my view, during my system update I did nothing to distroy the DNS lookup. Luckily, I save my system update logs and now can attach the last one to this e-mail. Please, help me to recover my internet access, as I still have to do a lot of real work till Monday and have not enough time to investigate this problem alone and without a proper internet access. :( # emerge-webrsync Fetching most recent snapshot ... Trying to retrieve 20140724 snapshot from http://de-mirror.org/gentoo ... Fetching file portage-20140724.tar.xz.md5sum ... Fetching file portage-20140724.tar.xz.gpgsig ... Fetching file portage-20140724.tar.xz ... Checking digest ... Checking signature ... gpg: Signature made Fri 25 Jul 2014 03:55:29 AM EEST using RSA key ID C9189250 gpg: Good signature from Gentoo Portage Snapshot Signing Key (Automated Signing Key) [unknown] gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: DCD0 5B71 EAB9 4199 527F 44AC DB6B 8C1F 96D8 BF6D Subkey fingerprint: E1D6 ABB6 3BFC FB4B A02F DF1C EC59 0EEA C918 9250 Getting snapshot timestamp ... Syncing local tree ... Number of files: 180119 Number of files transferred: 5148 Total file size: 327.62M bytes Total transferred file size: 35.67M bytes Literal data: 35.67M bytes Matched data: 0 bytes File list size: 4.56M File list generation time: 0.001 seconds File list transfer time: 0.000 seconds Total bytes sent: 16.10M Total bytes received: 124.13K sent 16.10M bytes received 124.13K bytes 135.75K bytes/sec total size is 327.62M speedup is 20.20 Cleaning up ... q: Updating ebuild cache ... q: Finished 37417 entries in 0.297930 seconds Performing Global Updates (Could take a couple of minutes if you have a lot of binary packages.) @ # emerge --update --deep --with-bdeps=y --newuse --ask world These are the packages that would be merged, in order: Calculating dependencies... done! The following packages are causing rebuilds: (media-libs/libmng-2.0.2-r1::gentoo, ebuild scheduled for merge) causes rebuilds for: (dev-qt/qtgui-4.8.5-r3::gentoo, ebuild scheduled for merge) (gnome-base/gnome-desktop-3.12.2::gentoo, ebuild scheduled for merge) causes rebuilds for: (gnome-extra/gnome-screensaver-3.6.1::gentoo, ebuild scheduled for merge) (media-libs/x264-0.0.20140308::gentoo, ebuild scheduled for merge) causes rebuilds for: (media-video/vlc-2.1.2::gentoo, ebuild scheduled for merge) [ebuild U ] virtual/libintl-0-r1 [0] ABI_X86=(64%*) -32% (-x32) [ebuild U ] media-libs/vo-aacenc-0.1.3 [0.1.2] ABI_X86=(64%*) (-32) (-x32) [ebuild U ] gnome-base/gnome-common-3.12.0 [3.10.0] [ebuild U ] dev-libs/vala-common-0.24.0 [0.22.1] [ebuild U ] media-libs/libpng-1.6.12 [1.6.10] [ebuild U ] sys-libs/cracklib-2.9.1-r1 [2.9.1] ABI_X86=(64%*) (-32) (-x32) [ebuild U ] x11-libs/gnome-pty-helper-0.36.3 [0.34.9] [ebuild R] media-libs/lcms-2.5 [ebuild r U ] media-libs/libmng-2.0.2-r1 [1.0.10-r1] ABI_X86=(64%*) (-32) (-x32) [ebuild r U ] media-libs/x264-0.0.20140308 [0.0.20111220] USE=sse%* -opencl% ABI_X86=(64%*) (-32) (-x32) [ebuild U ] media-libs/xvid-1.3.3 [1.3.2] ABI_X86=(64%*) (-32) (-x32) [ebuild U ] dev-libs/gobject-introspection-common-1.40.0 [1.38.0] [ebuild U ] virtual/perl-Test-Simple-0.980.0-r5 [0.980.0-r4] [ebuild U ] perl-core/IO-1.25-r1 [1.25] [ebuild U ] virtual/perl-Digest-1.170.0-r3 [1.170.0-r1] [ebuild U ] virtual/perl-File-Spec-3.400.0-r2 [3.400.0-r1] [ebuild U ] dev-lang/orc-0.4.19 [0.4.18] [ebuild U ] virtual/perl-Scalar-List-Utils-1.270.0-r2 [1.270.0-r1] [ebuild U ] virtual/perl-Test-Harness-3.260.0-r2 [3.260.0-r1] [ebuild U ] virtual/perl-IO-Compress-2.60.0-r1 [2.60.0] [ebuild U ] perl-core/Archive-Tar-1.900.0-r1 [1.900.0] [ebuild U ] dev-db/sqlite-3.8.4.3 [3.8.2] ABI_X86=(64%*) (-32) (-x32) [ebuild R] dev-libs/libgcrypt-1.5.3 [ebuild U ]
Re: [gentoo-user] Something went wrong with DNS, plz help!
2014-07-26 19:02 GMT+03:00 Alan McKinnon alan.mckin...@gmail.com: On 26/07/2014 17:23, Grand Duet wrote: The first reboot after recent update of the system have shown that I cannot open any webpage in Firefox. More exactly, Firefox or my system cannot any more resolve URL to IP address (sorry if I use wrong terms). Thus, host gmail.com http://gmail.com gives: ;; connection timed out no servers could be reached Nevertheless dig @8.8.8.8 http://8.8.8.8 gmail.com http://gmail.com reports the corresponding IP adresses. I have not changed any my network settings and my /etc/conf.d/net file still contains list of my DNS servers that contains server 8.8.8.8 as well but somehow it is not enough any more. :( During my last system update, I suddenly found that I had to update about 150 packages, what was a little bit strange as I update my system at least once a week. I have attributed that to the remnants of gnome2 (now I am using fxce4) that I have not cleaned completely and that is now going to update. So, I deviated a bit from my usual system update routine trying to fix that. Nevertheless, as to my view, during my system update I did nothing to distroy the DNS lookup. Luckily, I save my system update logs and now can attach the last one to this e-mail. Please, help me to recover my internet access, as I still have to do a lot of real work till Monday and have not enough time to investigate this problem alone and without a proper internet access. :( what is the contents of /etc/resolve.conf? # Generated by net-scripts for interface lo domain mynetwork That is all. I tried to add here lines like: nameserver 8.8.8.8 but found out that this file is rewritten on every reboot. My net try was to create /etc/resolv.conf.tail file and put that line there but that did not help either.
Re: [gentoo-user] Something went wrong with DNS, plz help!
2014-07-26 19:09 GMT+03:00 Jc García jyo.gar...@gmail.com: 2014-07-26 9:23 GMT-06:00 Grand Duet grand.d...@gmail.com: The first reboot after recent update of the system have shown that I cannot open any webpage in Firefox. More exactly, Firefox or my system cannot any more resolve URL to IP address (sorry if I use wrong terms). Thus, host gmail.com gives: ;; connection timed out no servers could be reached Nevertheless dig @8.8.8.8 gmail.com reports the corresponding IP adresses. I have not changed any my network settings and my /etc/conf.d/net file still contains list of my DNS servers that contains server 8.8.8.8 as well but somehow it is not enough any more. :( During my last system update, I suddenly found that I had to update about 150 packages, what was a little bit strange as I update my system at least once a week. I have attributed that to the remnants of gnome2 (now I am using fxce4) that I have not cleaned completely and that is now going to update. So, I deviated a bit from my usual system update routine trying to fix that. Nevertheless, as to my view, during my system update I did nothing to distroy the DNS lookup. Luckily, I save my system update logs and now can attach the last one to this e-mail. Please, help me to recover my internet access, as I still have to do a lot of real work till Monday and have not enough time to investigate this problem alone and without a proper internet access. :( You did verify your settings where correctly used to generate /etc/resolv.conf ? I guess, no. if not, append some known dns to that file this way: nameserver 8.8.8.8 nameserver 8.8.4.4 This does not help as /etc/resolv.conf is overwritten on every reboot. Creating /etc/resolv.conf.tail also did not help. verify connection to your gateway and internet with ping. It is ok. I am writing from the same subnet.
Re: [gentoo-user] Something went wrong with DNS, plz help!
2014-07-26 19:13 GMT+03:00 Mick michaelkintz...@gmail.com: On Saturday 26 Jul 2014 16:23:20 Grand Duet wrote: The first reboot after recent update of the system have shown that I cannot open any webpage in Firefox. More exactly, Firefox or my system cannot any more resolve URL to IP address (sorry if I use wrong terms). Thus, host gmail.com gives: ;; connection timed out no servers could be reached OK, what does 'cat /etc/resolve.conf' shows? # Generated by f***ing net-scripts for interface lo domain mynetwork It seems that you do not have a nameserver set up in your system? I have everything in /etc/conf.d/net: dns_servers_...=... ... 8.8.8.8 but currently nothing in /etc/resolv.conf Nevertheless dig @8.8.8.8 gmail.com reports the corresponding IP adresses. I'm guessing that 'dig gmail.com' doesn't come up with an answer? You are right. :) I have not changed any my network settings and my /etc/conf.d/net file still contains list of my DNS servers that contains server 8.8.8.8 as well but somehow it is not enough any more. :( Do you then define the nameservers statically? I think, yes. Do you use dhcpcd, or something else? I assign IP for my Gentoo computer statically in /etc/conf.d/net: config_...=my.local.IP netmask ... routes_...=default via my.local.router.IP but I have not changed all this since last reboot when everything worked ok.
Re: [gentoo-user] Something went wrong with DNS, plz help!
2014-07-26 19:27 GMT+03:00 Jc García jyo.gar...@gmail.com: 2014-07-26 10:22 GMT-06:00 Grand Duet grand.d...@gmail.com: etc/resolv.conf ? I guess, no. if not, append some known dns to that file this way: nameserver 8.8.8.8 nameserver 8.8.4.4 This does not help as /etc/resolv.conf is overwritten on every reboot. Creating /etc/resolv.conf.tail also did not help. verify connection to your gateway and internet with ping. It is ok. I am writing from the same subnet. That was just the trouble-shooting part, I use /etc/resolv.conf.head as my permanent solution to dns nameservers setting on my desktop(see my previous mail). Moving my /etc/resolv.conf.tail with nameservers IPs to /etc/resolv.conf.head changed nothing on reboot.
Re: [gentoo-user] Something went wrong with DNS, plz help!
2014-07-26 21:38 GMT+03:00 Mick michaelkintz...@gmail.com: On Saturday 26 Jul 2014 17:47:51 Grand Duet wrote: 2014-07-26 19:27 GMT+03:00 Jc García jyo.gar...@gmail.com: 2014-07-26 10:22 GMT-06:00 Grand Duet grand.d...@gmail.com: etc/resolv.conf ? I guess, no. if not, append some known dns to that file this way: nameserver 8.8.8.8 nameserver 8.8.4.4 This does not help as /etc/resolv.conf is overwritten on every reboot. Creating /etc/resolv.conf.tail also did not help. verify connection to your gateway and internet with ping. It is ok. I am writing from the same subnet. That was just the trouble-shooting part, I use /etc/resolv.conf.head as my permanent solution to dns nameservers setting on my desktop(see my previous mail). Moving my /etc/resolv.conf.tail with nameservers IPs to /etc/resolv.conf.head changed nothing on reboot. Have you checked that: udev has not changed the name of your NIC and if it has, that your symlinks in /etc/init.d are correct. Similarly, interface names are correct in your /etc/conf.d/net. The syntax in /etc/conf.d/net is in line with /usr/share/doc/netifrc- */net.example.bz2 If all of the above are as they should be, then I'm running out of ideas. I am also. After having a break, I decided to manually edit /etc/resolv.conf and then chmod it to be unoverwrittable. But I had no chance to check this solution: after booting my Gentoo computer once again, I have found out that now /etc/resolv.conf was created *with* DNS servers IPs, and everything works fine. But it is *very* strange as I have *not* changed anything after my previous reboot. Absolutely. Have I discovered a new Windows-like fix for a Gentoo system that can be called Just reboot it several times?
Re: [gentoo-user] Something went wrong with DNS, plz help!
2014-07-26 22:43 GMT+03:00 Peter Humphrey pe...@prh.myzen.co.uk: On Saturday 26 July 2014 22:16:53 Grand Duet wrote: 2014-07-26 21:19 GMT+03:00 Alan McKinnon alan.mckin...@gmail.com: On 26/07/2014 18:16, Grand Duet wrote: 2014-07-26 19:02 GMT+03:00 Alan McKinnon alan.mckin...@gmail.com: On 26/07/2014 17:23, Grand Duet wrote: The first reboot after recent update of the system have shown that I cannot open any webpage in Firefox. More exactly, Firefox or my system cannot any more resolve URL to IP address (sorry if I use wrong terms). Thus, host gmail.com http://gmail.com gives: ;; connection timed out no servers could be reached Nevertheless dig @8.8.8.8 http://8.8.8.8 gmail.com http://gmail.com reports the corresponding IP adresses. I have not changed any my network settings and my /etc/conf.d/net file still contains list of my DNS servers that contains server 8.8.8.8 as well but somehow it is not enough any more. :( During my last system update, I suddenly found that I had to update about 150 packages, what was a little bit strange as I update my system at least once a week. I have attributed that to the remnants of gnome2 (now I am using fxce4) that I have not cleaned completely and that is now going to update. So, I deviated a bit from my usual system update routine trying to fix that. Nevertheless, as to my view, during my system update I did nothing to distroy the DNS lookup. Luckily, I save my system update logs and now can attach the last one to this e-mail. Please, help me to recover my internet access, as I still have to do a lot of real work till Monday and have not enough time to investigate this problem alone and without a proper internet access. :( what is the contents of /etc/resolve.conf? # Generated by net-scripts for interface lo domain mynetwork That isn't right. It should say it's for interface eth0. At first I thought eth0 wasn't being brought up, but then you quoted replies from dig, so it must be. 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!). This, by the way, reminds me MS Windows very much. I am afraid that you will not believe me, but I really did not changed any configuration and have not (re)emerged anything after the previous reboot. Why it did not worked then and does work now? It is really very strange! That is all. I tried to add here lines like: nameserver 8.8.8.8 but found out that this file is rewritten on every reboot. My net try was to create /etc/resolv.conf.tail file and put that line there but that did not help either. Then the problem is obvious - you have no nameserver entries as you don't create any. The computer can't make them up by magic... But it did it just before the last update: it created DNS entries in /etc/resolv.conf from my /etc/conf.d/net file on every reboot. And now it cannot do this magic? You need to create static nameserver entries because you use a static (i.e. no dhcp) configuration. Add them to /etc/resolvconf.conf It does not help as /etc/resolv.conf is overwritten on every reboot. If it still gets removed across restarts Yes, it does. Do you still have netifrc installed? Maybe it got lost in all that updating work. Try emerging it again anyway. As I have already written, DNS resolution now magically works again and without any intervention from my side: just a few reboots (one was no enough!). So, no need to re-emerge netifrc now. Do your 90-network-rules look like mine? $ cat /lib/udev/rules.d/90-network.rules # do not edit this file, it will be overwritten on update # /etc/udev/rules/90-network.rules: triggering network init-scripts # Activate our network if we can SUBSYSTEM==net, ACTION==add,RUN+=net.sh %k start SUBSYSTEM==net, ACTION==remove, RUN+=net.sh %k stop My file is exactly the same, and it was changed on May 10, 2014 last time. So, it could not be the cause. I'm clutching at straws here, and I hear others doing the same ;-( Everything is very, very strange.
