2 possible problems: DNS resolution and "Networking disabled"

English Network/Internet
#1

Hello. On May 25, 2018, the day 64-bit openSUSE Leap 15.0 Linux (“Leap 15”) was released, I upgraded to it from 64-bit openSUSE Leap 42.3 Linux (“Leap 42.3”). My main difficulty after this upgrade is in accessing the Internet properly, but only in certain ways.–That is I COULD access the Internet using commands like

newbie@linux-hdi0:~> ping 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.048 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.085 ms
64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.084 ms
^C
--- 127.0.0.1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2027ms
rtt min/avg/max/mdev = 0.048/0.072/0.085/0.018 ms
newbie@linux-hdi0:~>

but NOT via the command

newbie@linux-hdi0:~> nslookup www.google.com
;; connection timed out; no servers could be reached

newbie@linux-hdi0:~>

According to Henk van Velden, a failed computer execution of the command “nslookup google.com” indicates that the “DNS” (Domain Name System) “server does not work properly” ([https://forums.opensuse.org/showthread.php/484373-Yast-Could-not-resolve-host-download-opensuse-org on the Internet](https://forums.opensuse.org/showthread.php/484373-Yast-Could-not-resolve-host-download-opensuse-org on the Internet)).

The “host” command did not work for me either, as shown below:

newbie@linux-hdi0:~> host 172.217.5.228
;; connection timed out; no servers could be reached
newbie@linux-hdi0:~>

(The Internet Protocol address for http://www.google.com/ is 172.217.5.228.). Implementation for the command “host” is included in the software package bind-utils, which is installed in my installation of Leap 15.

I could not download software updates from a Leap-15 repository via openSUSE’s YaST2’s (Yet another Setup Tool 2’s) Online Update or Software Management with the result “Repository is not cached”, or “visit” https://www.opensuse.org/searchPage/ via the Mozilla Firefox Web browser in Leap 15. When I tried to update my Leap-15 software I received the messages

Error code: Connection failed
Error message: Could not resolve host: download.opensuse.org

.

After clicking on “Skip” a few times, for skipping accessing that Web site, I eventually received the message “No update repository configured yet.” But I had 11, Leap-15 repositories, with five of them enabled, including for which I received the above error code and message. I later ran my Leap-15 installation disc through the point at which some Leap-15 repositories were reinstalled and then exited that installation. But those reinstallations did not eliminate my Leap-15 problems.

As shown below, mixed results regarding “server” were obtained for the command

newbie@linux-hdi0:~> dig @8.8.8.8 www.google.com

; <<>> DiG 9.11.2 <<>> @8.8.8.8 www.google.com
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
newbie@linux-hdi0:~>

.
I have Leap 15 as a Virtual Machine (VM) in Oracle VM VirtualBox. And my network setting within VirtualBox is NAT (Network Address Translation).

Below please see my results for three more commands:

newbie@linux-hdi0:~> /sbin/lspci -nnk
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02)
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000]
00:01.1 IDE interface [0101]: Intel Corporation 82371AB/EB/MB PIIX4 IDE [8086:7111] (rev 01)
	Kernel driver in use: ata_piix
	Kernel modules: ata_piix, pata_acpi, ata_generic
00:02.0 VGA compatible controller [0300]: InnoTek Systemberatung GmbH VirtualBox Graphics Adapter [80ee:beef]
	Kernel driver in use: vboxvideo
	Kernel modules: vboxvideo
00:03.0 Ethernet controller [0200]: Intel Corporation 82540EM Gigabit Ethernet Controller [8086:100e] (rev 02)
	Subsystem: Intel Corporation PRO/1000 MT Desktop Adapter [8086:001e]
	Kernel driver in use: e1000
	Kernel modules: e1000
00:04.0 System peripheral [0880]: InnoTek Systemberatung GmbH VirtualBox Guest Service [80ee:cafe]
	Kernel driver in use: vboxguest
	Kernel modules: vboxguest
00:05.0 Multimedia audio controller [0401]: Intel Corporation 82801AA AC'97 Audio Controller [8086:2415] (rev 01)
	Subsystem: Dell Device [1028:0177]
	Kernel driver in use: snd_intel8x0
	Kernel modules: snd_intel8x0
00:06.0 USB controller [0c03]: Apple Inc. KeyLargo/Intrepid USB [106b:003f]
	Kernel driver in use: ohci-pci
	Kernel modules: ohci_pci
00:07.0 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 08)
	Kernel driver in use: piix4_smbus
	Kernel modules: i2c_piix4
00:0b.0 USB controller [0c03]: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller [8086:265c]
	Kernel driver in use: ehci-pci
	Kernel modules: ehci_pci
00:0d.0 SATA controller [0106]: Intel Corporation 82801HM/HEM (ICH8M/ICH8M-E) SATA Controller [AHCI mode] [8086:2829] (rev 02)
	Kernel driver in use: ahci
	Kernel modules: ahci
newbie@linux-hdi0:~>


newbie@linux-hdi0:~> sudo -i traceroute www.google.com
[sudo] password for root: 
www.google.com: Name or service not known
Cannot handle "host" cmdline arg `www.google.com' on position 1 (argc 1)
newbie@linux-hdi0:~&gt;


newbie@linux-hdi0:~> ifconfig
If 'ifconfig' is not a typo you can use command-not-found to lookup the package that contains it, like this:
    cnf ifconfig
newbie@linux-hdi0:~>

From YaST2’s Software Management I learned that ifconfig WAS a part of net-tools, but on May 26, 2018 WAS NOT a part of net-tools, a software package installed in my Leap-15 installation; instead on May 26, 2018 implementation for the command ifconfig is a part of the software package net-tools-deprecated, which appears not to be installed in my Leap-15 installation. So this explains why the command ifconfig was not recognized in my Leap-15 installation on May 26, 2018. According to YaST2’s Software Management ifconfig was obsoleted by one or more software tools in the software package iproute2, which IS installed in my Leap-15 installation.

Partly following advice from https://theos.in/desktop-linux/resolve-conf-linux-example/ in the file /etc/resolv.conf I tried inputting

search google.com
nameserver 172.217.5.228

, beginning in column one in each of these lines, and deleting the line reading

### Please remove (at least) this line when you modify the file!

But still I had no success in visiting a Web page in the Mozilla Firefox Web browser in openSUSE. I inserted one tab before each of the “search…” and “nameserver…” additions in /etc/resolv.conf. But those insertions did not eliminate my problems.

After writing much of the above content I learned from a search of https://forums.openSUSE.org/ that the DNS problem was reported as a “bug” on https://bugzilla.opensuse.org/show_bug.cgi?id=1092352. I tried the “workaround” posted by S.B. there of effectively removing the file resolv.conf from the directory /etc (He actually suggested deleting that file. I at least temporarily moved it to my desktop and to “Trash.”). But unfortunately afterward I still could not have a Web page displayed in my installation of the Mozilla Firefox Web browser in Leap 15.

I think after my upgrade to Leap 15 I seem to have lost access to the Internet in Leap 15 via a software connection called eth0 or eth1 which used to be active! In Leap 15 when I placed my computer’s touchpad arrow over the icon which looked like two computer monitors I saw “Networking disabled.” In YaST2’s Network Settings on the Global Options tab I found “82540EM Gigabit Ethernet Controller” and “Not configured.” Leap 15 is a Virtual Machine (VM) installed inside VirtualBox, in my case. Is this 82540EM Gigabit Ethernet Controller a piece of real hardware of my computer or virtual hardware made to work with VirtualBox? I found no such hardware device or software “device” listed among the controllers in Device Manager in my 64-bit Windows 10 Home Edition, host operating system. Yet http://download.opensuse.org/distribution/leap/15.0/repo/non-oss shows that it is clearly a physical device of Intel Corporation with an operating temperature range of zero to 70 degrees Centigrade. So I am inclined to think that the 82540EM Gigabit Ethernet Controller may not be a physical device of my physical computer. I suspect it might be a virtual “device” in VirtualBox or Leap 15. Nevertheless am I supposed to configure this “device?” If so, how?

A lengthy diagnostic procedure for network-related problems applicable to Leap 15 exists on https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.reference/cha.nm.html#sec.nm.configure. As I discussed here, I have troubleshot a few of the items discussed there. In the past few years I have mostly been using WiFi service to access the Internet with my Dell notebook computer. Before my upgrade from Leap 42.3 to Leap 15 I could update my Leap 42.3 computer software via the Internet.

In my installation of Leap 15 on the evening of May 26, 2018 in the eastern United States there might be two different problems in what I have discussed here: 1) the DNS problem I think resolving Internet Protocol (IP) addresses as names and vice versa and 2) “Networking disabled.” I wonder if this second problem could be because I presently don’t have an Internet connection configured properly in Leap 15. Please help me with these problems.

#2

You can check your IP address with

ip a

Personally, I prefer the formatting from “ifconfig”, so I installed “net-tools-deprecated”.

It is possible that you do not have an IP address at all. If that’s a problem, check
Bug 1080832 (especially comment #5).

#3

If it’s just name resolution that’s not working for you, try removing /etc/resolv.conf and restarting the network with

systemctl restart network

or do

netconfig f update

then see if you can resolve hostnames.

#4

Just a FYI…

Within the past 12 hrs,
I’ve done LEAP 42.3 > LEAP 15 upgrades both by using the DVD and online using “zypper dup” and both completed successfully without any network problems.

That said, upgrading can be complex and not all upgrades can ever be a guaranteed success, only nearly 100%.

You need to use the nslookup tool to analyze your situation more closely…

  • Instead of running a complex nslookup command, I instead recommend entering a nslookup session with simply “nslookup” so that you don’t need to keep typing nslookup repetitively. You can type “exit” to leave an nslookup session.
  • Try pointing to a different server, for example the following command re-points to Google DNS. You can re-point again and again to various DNS servers if you wish.
> server 8.8.8.8
  • Always query for a different domain to avoid cached results.
  • Clear your name cache to avoid cached results (both failed as well as successful)
systemctl restart nscd.service

Related to what you’ve already done

  • You can edit /etc/resolv.conf to point to a DNS server, but be aware that change won’t likely survive a reboot. Permanent changes should be done differently, and if DNS is provided by your DHCP then you’ve probably got a bigger problem.
  • If you’re running a virtual machine like Virtualbox, fire up a different Guest which has been known to work. Make sure the Guest network connections are same or similar. There shouldn’t be a problem, but I’ve always been very suspicious of VBox’s NAT connection which sets up the Guest without its own IP address (The Guest shares the Host IP address). Instead, I recommend configuring “NAT-network” which sets up a conventional network connection when the Guest has its own, unique IP address.

TSU

#5 
newbie@linux-hdi0:~> ping 127.0.0.1

Others will correct me if I got this wrong, but pinging one’s self is not going to give you any info that’s useful as you obviously can connect to yourself (especially a special IP number like 127.0.0.1).

#6

Yes,
The localhost interface (typically assigned 127.x.y.z) is <not> exposed to physical network devices.
It’s completely different than the interface for which as an example a DHCP configuration might be applied.

So, it would be useful to ping the assigned network address instead of the localhost interface address.

TSU

#7

Thanks to all of you who kindly took some time to post postings in this “thread” of postings. I found that my computer software was set to use the so-called “wicked” method via YaST Contol Center, System, Network Settings, under Network Setup Method on the Global Options tab. Accordingly in https://bugzilla.opensuse.org/show_bug.cgi?id=1080832 I saw that Nimroy Das suggested making a file /etc/wicked/local.xml with the contents

<config>
   <addrconf>
       <dhcp4>
          <create-cid>rfc2132</create-cid>
       </dhcp4>
   </addrconf>
</config>

on the hunch that the DHCP server didn’t “like” rfc4361 client-id. Neil Rickert followed that advice and had good results after entering “systemctrl restart wickedd” or else “systemctrl restart wicked” and “rebooting” into openSUSE Tumbleweed. The version of openSUSE there on February 2, 2018 was reported as “Current.” Perhaps “Current” meant the currently tested version of openSUSE Tumbleweed, so maybe version 15.0 on February 2, 2018.

Given Neil Rickert’s reported success, I did what he did, namely making local.xml, entering both “systemctrl restart wickedd” and “systemctrl restart wicked”, and then rebooting into Leap 15.0. I entered the command “ip a” and obtained the following results (But later “systemctrl” was not “recognized” in my installation of Leap 15.):

newbie@linux-hdi0:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 08:00:27:24:85:7d brd ff:ff:ff:ff:ff:ff
newbie@linux-hdi0:~>

I still saw “Networking disabled” in a context-sensitive menu when my computer’s touchpad arrow was placed over an icon looking like two computer monitors on the lower-right side of my Leap-15 computer screen. I compared the above output with the first example output under “Show IP Addresses” on https://www.rootusers.com/11-ip-command-examples-for-linux/. Afterward I decided that for the Internet connection eth1 no Internet Protocol (IP) version-4 (IPv4) or version-6 address had been assigned to it! And I wonder if the word “DOWN” could mean that eth1 was not active at the time the above output was produced.

Below are my results for some experiments with the command “nslookup”.

newbie@linux-hdi0:~> nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> server 64.4.11.37
Default server: 64.4.11.37
Address: 64.4.11.37#53
> exit

newbie@linux-hdi0:~>

The IP address 64.4.11.37 is one of the IP addresses for microsoft.com. These nslookup results look good to me.

On the other hand,

newbie@linux-hdi0:~> nslookup
> server www.google.com
nslookup: couldn’t get address for ‘www.google.com’: not found
newbie@linux-hdi0:~> nslookup www.google.com
;; connection timed out; no servers could be reached

newbie@linux-hdi0:~>
.
So a summary of today’s results in my installation of Leap 15.0 is that

  1. a Web site appears to be reachable via its IP address, but not via its Uniform Resource Locator (URL), for example, www.google.com.

  2. While online my so-called “ethernet” connection eth1 in Leap 15.0 has no IP address within VirtualBox.

  3. In Leap 15.0 I continued to see “Networking disabled.”

Consider me ignorant concerning the details of the relevant computer software. What should I do or try next?

Further question: If I see “RESOLVED FIXED” on the top of a https://bugzilla.opensuse.org/ posting for openSUSE Tumbleweed or Leap, is it safe for me to assume that that matter has been fixed in the next or current release of openSUSE Leap so that I can ignore such a bugzilla posting?

#8

Sorry, several examples of terminal commands and computer responses were not placed in code format in my previous posting:

newbie@linux-hdi0:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 08:00:27:24:85:7d brd ff:ff:ff:ff:ff:ff
newbie@linux-hdi0:~>

I still saw “Networking disabled” in a context-sensitive menu when my computer’s touchpad arrow was placed over an icon looking like two computer monitors on the lower-right side of my Leap-15 computer screen. I compared the above output with the first example output under “Show IP Addresses” on https://www.rootusers.com/11-ip-command-examples-for-linux/. Afterward I decided that for the Internet connection eth1 no Internet Protocol (IP) version-4 (IPv4) or version-6 address had been assigned to it! And I wonder if the word “DOWN” could mean that eth1 was not active at the time the above output was produced.

Below are my results for some experiments with the command “nslookup”.

newbie@linux-hdi0:~> nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> server 64.4.11.37
Default server: 64.4.11.37
Address: 64.4.11.37#53
> exit

newbie@linux-hdi0:~>

.
The IP address 64.4.11.37 is one of the IP addresses for microsoft.com. These nslookup results look good to me.

On the other hand,

newbie@linux-hdi0:~> nslookup
> server www.google.com
nslookup: couldn't get address for 'www.google.com': not found
newbie@linux-hdi0:~> nslookup www.google.com
;; connection timed out; no servers could be reached

newbie@linux-hdi0:~>
#9

[QUOTE=2009Newbie;2866894]


newbie@linux-hdi0:~> nslookup
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> server 64.4.11.37
Default server: 64.4.11.37
Address: 64.4.11.37#53
> exit

That doesn’t actually tell you anything, other than that the command “nslookup” exists on your system.

I’m now thinking that you might have a hardware issue. Perhaps your network card requires a driver that isn’t installed.

  1. a Web site appears to be reachable via its IP address, but not via its Uniform Resource Locator (URL), for example, www.google.com.

I am not actually seeing where you reached a server by its IP address.

Further question: If I see “RESOLVED FIXED” on the top of a https://bugzilla.opensuse.org/ posting for openSUSE Tumbleweed or Leap, is it safe for me to assume that that matter has been fixed in the next or current release of openSUSE Leap so that I can ignore such a bugzilla posting?

You have to read the fine print. In the case of bug 1080832, the “FIXED” means that they have added documentation explaining the issue and describing the workaround.

#10

I have a similar (or maybe the same) problem: after zypper dup went without problems, when entered the system there was no internet connection through browser.

If I issue on konsole

ping 172.217.5.228

I get an answer, but if I input that address on firefox or chromium they turn it into “www.google.com” but then tell me they cannot connect to the server. Chromium even says “cannot find the IP of the server www.google.com”. A “ping google.com” fails.

My system is set to use NetworkManager. I really do not have any idea where to start to look to fix this problem. Do I need to perform a clean install?

#11

Fixed!!! I edited /etc/resolv.conf to add the following line

nameserver XXX.XXX.X.X

where XXX.XXX.X.X represent the router IP (the address you use to enter its configuration). Reboot and that’s it!

#12

Better delete the file and reboot, or run “netconfig -f update”, and it should get re-created correctly.
If you modify it manually, it won’t ever be updated by the system again.

Btw, this is likely http://bugzilla.opensuse.org/show_bug.cgi?id=1092352, NetworkManager seems to overwrite /etc/resolv.conf with a broken one under certain circumstances (not only when upgrading from 42.3 to 15.0!).
The exact reasons have not been found yet though, and it also seems to be not easily reprodicable.

#13

IMHO it’s better to edit “/etc/sysconfig/network/config”:


## Type:        string
## Default:     ""
#
# List of DNS domain names used for host-name lookup.
# It is written as search list into the /etc/resolv.conf file.
#
NETCONFIG_DNS_STATIC_SEARCHLIST=" «The domain name of your LAN/WLAN supplied by your DNS server box» "

Then, at boot time, with DHCP, “/etc/resolv.conf” will be auto-magically written with the appropriate IPv6 and IPv4 addresses for the Name Server.

Alternatively, you can use the following “/etc/sysconfig/network/config” value:


## Type:        string
## Default:     ""
#
# List of DNS nameserver IP addresses to use for host-name lookup.
# When the NETCONFIG_DNS_FORWARDER variable is set to "resolver",
# the name servers are written directly to /etc/resolv.conf.
# Otherwise, the nameserver are written into a forwarder specific
# configuration file and the /etc/resolv.conf does not contain any
# nameservers causing the glibc to use the name server on the local
# machine (the forwarder). See also netconfig(8) manual page.
#
NETCONFIG_DNS_STATIC_SERVERS=""
#14

Although you posted later (after this post) that you were able to resolve your problem, I consider your fix temporary and your fix itself could turn out to be problematic.

So, a quick rundown of what is in <this> post…

If your system was set up to be a DHCP client,
Your machine wasn’t assigned a working IPv4 address… And that needs to be looked into.
That you say you were able to run nslookup and ping remote Internet IP addresses using IPv4 addresses is curious… I would have thought that you’d only have IPv6 working.
So, there is something odd happening at your Internet router besides its iPv4 DHCP service.

And,
It follows that your temporary fix to edit /etc/resolv.conf is again because of your DHCP issue… If you didn’t obtain a DHCP IP address, then it also stands to reason that you didn’t get your DNS Server configuration for the same reason.

So,
Figure out what is happening with DHCP on your network and you’ll probably solve your problem properly and permanently without causing other problems you’ll likely see with your current fix.

TSU

#15

This won’t help in the case that NetworkManager overwrote /etc/resolv.conf with a broken one without nameservers.
That’s unrelated to the config.

And most users probably get the nameserver automatically via DHCP anyway, so no need to add one in /etc/sysconfig/network/config.

Then, at boot time, with DHCP, “/etc/resolv.conf” will be auto-magically written with the appropriate IPv6 and IPv4 addresses for the Name Server.

This will happen anyway (without changing /etc/sysconfig/network/config), but only if /etc/resolv.conf has not been modified manually.

You should only have to modify /etc/sysconfig/network/config the way you wrote if you want to add an additional, static nameserver not provided by DHCP.

#16

True for everyone who doesn’t have an AVM Fritz!Box as their DSL Router and DHCP server and DNS (cache) server (or, a DSL Router which does similar things … ).

  • If you have an AVM Fritz!Box DSL Router and, you’ve taken the default configuration that the Fritz!Box is your DHCP server and your DNS cache server, then:
  • For an acceptable DNS performance set the “/etc/sysconfig/network/config” token ‘NETCONFIG_DNS_STATIC_SEARCHLIST’ to the value of the domain name that an AVM Fritz!Box uses for your LAN and WLAN: "fritz.box
    " – yes, really, AVM (a company in Berlin) have reserved the domain “fritz.box” within the “.box” TLD and, they’ve taken steps to ensure that, everything works as expected …
#17

And why do you assume RGBsuse has such a router, or present this as definitive thing to do?

Actually he wrote that it worked before the upgrade, so manually adding DNS servers should not be necessary at all.

Ok, his problem is probably different to the original one discussed here though, but I don’t really see your comments related to this thread or his problem either.

Again, there currently is a bug in NetworkManager that can make it overwrite /etc/resolv.conf with a broken one. Not really specific to Leap 15.0, but apparently more likely to happen if you upgrade to it using “zypper dup”.
The proper fix is to delete /etc/resolv.conf or run “sudo netconfig -f update” to let the system regenerate it correctly.

#18

Because, my experience is, given a DSL Router with DHCP and DNS services which drops a “private” ‘.box’ domain name onto the private LAN and WLAN, the current openSUSE network setup method gives more reliable and faster DNS results and, faster boot times, if the static search list is used to search for Name Servers within that domain.
[HR][/HR]Please be aware that, AVM Fritz!Boxes suffered more than a few DNS issues when the ‘.box’ TLD was made public but, those issues have now been addressed by AVM and, the additional setting with the static search list ensures that, the openSUSE boxes do not inadvertently pick up a DNS service which is not that supplied by the DSL Router …

#19

That may well be (I don’t know as I never had such a “problematic” device), but you proposed it to RGBsuse as the proper thing to do without mentioning any reasons or further explanations, and also without any indication that it would actually apply to his problem (which it likely doesn’t IMHO).

Anyway, things should be clearer now. (and continuing this “discussion” won’t add anything… :wink: )

#20

I’m sorry. Earlier in this “thread” of postings I misspelling Nirmoy Das’s name as Nimroy Das.

Gratefully May 28, 2018 was a better day than previous days for me to access Web sites through Leap 15.0 through Oracle Virtual Machine (VM) VirtualBox! (Hereafter in this posting I call this VirtualBox.) In short, one of my difficulties was likely caused by my experimenting on May 26, 2018 trying to gain such Web-site access, one day after I upgraded Leap 42.3 to Leap 15.0. That May 26th date was the date I found that a file with a name containing eth1 had been modified; eth0 had been produced in the year 2016 in an earlier version of openSUSE installed on my computer. I guess software problems may have occurred when I within YaST2’s (Yet another Setup Tool 2’s) System, Network Settings tried a simple replacement of Network Manager Service for the so-called Wicked Service as the “Network Setup Method,” and then returned to the Wicked Service. Compared to my May 27, 2018 failure, May 28, 2018’s success was at least in part due to configuring the Intel PRO MT/1000 MT, 82540EM virtual network “card” provided by VirtualBox 5.2.12r122591, which recently was not configured in my Leap-15.0 installation, possibly the renaming of my “ethernet” connection eth1 to eth0, and possibly due to my making local.xml, which I discussed earlier in this “thread” of postings.

In recent years in openSUSE I have mostly been using the Lightweight X Windows System, version 11 (X11), Desktop Environment (LXDE). So my report here applies mostly to the LXDE.

Something I did on May 26, 2018 may have caused my “ethernet” connection “eth0” to be renamed as “eth1.” To reverse that process, following the advice of “clrg” on http://ubuntuforums.org/showthread.php?t=1548254, as a “root” user, after making a backup of the file /etc/udev/rules.d/70-persistent-net.rules, within the original version of that file I changed “eth1” to “eth0”, saved that file, and then entered “init 6.”—From https://serverfault.com/questions/511614/what-is-the-difference-between-init-6-and-reboot-on-red-hat-rhel-centos I understood that the command “init 6” is designed to execute K* scripts and then to “reboot” a Linux operating system.

I began the process of configuring VirtualBox’s 82540EM virtual newtork “card” within YaST2 by clicking on the icon on the left-hand side of the LXDE taskbar, selecting “System, LXDE Control Center, YaST Control Center,” inputting my “root”-user password, selecting “System, Network Settings,” and, on the ensuing “Overview” tab with “82540EM Gigabit Ethernet Controller” selected and indicated as “Not configured,” clicking on “Edit.” I clicked on the “radio” button to the left of “Dynamic Address” to have a black disc placed within that “radio” button, selected “DHCP,” accepted “DHCP both version 4 and 6,” and clicked on “Next.” Afterward near the bottom of that “Overview” tab under “Name” I could see “82540 Gigabit Ethernet Controller” for the “Name,” “DHCP” for the “IP Address”, and “eth0” for the “Device”. And below “82540 Gigabit Ethernet Controller (Not connected)” I could see its MAC (Media Access Control) address in my installation of VirtualBox, its BusID, and

  • Device Name: eth0

  • Started automatically on cable connection

  • IP address assigned using DHCP

.
I clicked on “Add” and then “Cancel,” with no net effect due to those two clickings, and then clicked on “OK.” “Networking disabled” was still shown in the context-sensitive menu when I placed my computer’s touchpad arrow over the symbols of two computer monitors on the right-hand side of the LXDE taskbar. I shut down Leap 15.0 and VirtualBox and then restarted VirtualBox with my host, 64-bit Windows 10 Home Edition operating system connected to the Internet. In VirtualBox’s “Settings, Network,” and on the “Adapter 1” tab, clicking on the downward-pointing arrow beside “Advanced” displayed a check mark in the checkbox beside “Cable Connected.” With my openSUSE Virtual Machine (VM) highlighted in the left-hand pane of VirtualBox’s main window I clicked on “Start” near the top of that window.

I logged into the LXDE in Leap 15.0. Still “Networking disabled” was shown in the context-sensitive menu for the two-monitor icon on the taskbar. But, similar to what is shown below, gratefully this time the command “ip a” gave a much better result than previously!

newbie@linux-hdi0:~> ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:24:85:7d brd ff:ff:ff:ff:ff:ff
    inet 10.0.2.15/24 brd 10.0.2.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe24:857d/64 scope link 
       valid_lft forever preferred_lft forever
newbie@linux-hdi0:~>

And, similar to what is shown below, the command host 8.8.8.8 gratefully gave me a better result than a similar command previously did!

newbie@linux-hdi0:~> host 8.8.8.8
8.8.8.8.in-addr.arpa domain name pointer google-public-dns-a.google.com.
newbie@linux-hdi0:~>

But the results at first seemed to me not so good for the two microsoft.com Uniform Resource Locators (URLs) shown below:

newbie@linux-hdi0:~> host 64.4.11.37
Host 37.11.4.64.in-addr.arpa. not found: 3(NXDOMAIN)
newbie@linux-hdi0:~> 

newbie@linux-hdi0:~> host 65.55.58.201
Host 201.58.55.65.in-addr.arpa. not found: 3(NXDOMAIN)
newbie@linux-hdi0:~>

I wonder if this could be because google.com is set up for the host command from a “visitor,” but the above Microsoft Corporation Web sites with the Internet Protocol (IP) addresses 64.4.11.37 and 65.55.58.201 are not set up for host commands from “visitors.”

Gratefully I could afterward have openSUSE’s home page displayed in a Mozilla Firefox Web browser in Leap 15.0! And finally I could obtain updates for Leap-15.0 software packages within YaST2!
I noticed that a second icon looking like two computer monitors had appeared on the taskbar in the LXDE. Placing my computer’s touchpad arrow over that icon resulted in showing the numbers of bytes and packets received through my network connection eth0. The other taskbar icon looking like a pair of computer monitors still showed “Networking disabled.” Speculation: I wonder if that could be in effect “telling” me that the Network Manager Service was disabled because I was using the so-called Wicked Service as the Network Setup Method within Leap 15.0. In any case, with the other successes in accessing the Internet this result seemed ignorable.

As another possible factor in my above successes, on my part there is considerable mystery concerning my inclusion of the file /etc/wicked/local.xml that I discussed earlier in this “thread” of postings. Again, as suggested by Nirmoy Das, Neil Rickert had success with that inclusion in obtaining IP, version-4 addresses (https://bugzilla.opensuse.org/show_bug.cgi?id=1080832). According to Nirmoy Das there that file’s purpose was apparently to substitute the use of a file named rfc2132 for the file named rfc4361, in case there was difficulty with rfc4361 using the so-called Wicked Service (instead of the Network Manager Service) in Leap 15.0. From the Internet I learned that in the context of computer software rfc can stand for either Request For Comments or Remote Function Call. So which of those definitions applies in this situation is one question of mine. Secondly, prior to my configuration of the 82540EM Gigabit Ethernet Controller on May 28, 2018 I did not find either “rfc2132” or “rfc4361” included in any active statement in either of my files dhclient-eth0.conf or dhclient-eth1.conf, both of which were in the directory /var/lib/NetworkManager; instead each of those files included active mentions of “rfc3442” and “rfc4833”. Also I did not find either of the files rfc2132 or rfc4361 on https://www.kernel.org/doc/rfc-linux.html. Aside from requesting help in explaining these mysteries, I am, at least for now, leaving /etc/wicked/local.xml in my Leap-15.0 installation, a file which has been considered a “workaround solution.” If Leap-15.0 code writers find what they consider a more preferred solution for https://bugzilla.opensuse.org/show_bug.cgi?id=1080832, kindly please inform me of it in this “thread” of postings.

After being able to obtain updates or else new, compared to Leap 42.3, software packages in Leap 15.0, at first I had 14 of such updates downloaded and installed via YaST2, “Online Update”, and some Leap-15.0 online repositories. During the installations of those software packages, and after being notified I to the effect, I agreed to the replacement of some files with other files of the same names. Those files and the paths, maybe of the older files, were:

/usr/share/terminfo/s/screen.linux,
/usr/share/terminfo/s/screen.konsole,
/usr/share/terminfo/s/screen.gnome, and
/usr/share/doc/packages/kernel-syms/README.SUSE, which was replaced about 12 times.

Later I had numerous other updates and/or software packages installed in my installation of Leap 15.0.

I don’t have Internet access in my home. But I discovered a way to have numerous “texlive” software packages, or software packages needed by texlive, installed while offline that had been previously downloaded from Leap-15.0 repositories while online. In YaST2’s “Software Management” I suppose that a pair of blue-colored version numbers, with one of those version numbers between parentheses and one of them not between parentheses, might indicate that the installation file for the version surrounded by parentheses had been downloaded, but had yet to be executed to replace the then-installed version with the newer version of the relevant software package. The beginning of that process was to enter YaST2’s “Software Management”, and while offline to click on “Skip autorefresh,” or something similar to that, to enter “texlive” in the “Search” edit control, and afterward to click on the “Search” software “button.” After that I could click on the “Package” menu item, select “All in This list,” and then “Update if newer version available.” In this way while offline I could have 460 software packages related to TeX Live installed and 1,759 updates installed, the installation files for all of which had been previously downloaded from openSUSE repositories. I guess that the majority of TeX Live may not be included in an .iso (International Standards Organization) file for the installation of openSUSE in order to keep the total size of the files finalized on an openSUSE-installation Digital Video Disc (DVD) within the size 4.7-gigabyte size of a single-layer, Recordable DVD, or DVD-R.

Another conceivable way to have a large number of TeX Live software packages installed while offline could be to have them dowloaded as a group from http://tug.org/texlive/acquire-netinstall.html or else within https://ctan.org/; to produce from them a TeX Live, installation DVD-R; and then while offline to install them in openSUSE using that DVD-R. I have not tried that process for a large number of TeX Live software packages. It also might be more complicated than obtaining and installing TeX Live software packages from openSUSE repositories. I thank Neil Rickert and all of you who kindly took some of your time to post some comments within this “thread” of postings.