I’m running Open Suse 13.1 in an Oracle Virtual Box VM. I can’t seem to get an IP address, hence I can’t get the VM to get out to the Internet or ping anything.
Right now, I have the Network Adapter set to NAT and it’s on “Adapter Type” Intel Pro/1000 MT Desktop (82540EM). My desktop’s real NIC is a wifi card. Don’t know how that changes anything. (I’ve tried changing the interface from NAT to bridged, and it didn’t make a difference.)
There is no inet address for the enp0s3 interface. And, two, I’m not sure why the interface is not called inet or something like that instead of enp0s3.
This is openSUSE running systemd.
One of the benefits of systemd is that you can use “systemctl” to manage any Unit file configured for any subsystem.
Instead of learning the numerous commands for each subsystem, you can typically execute the same command for all, eg
# systemctl restart network
And, if it fails, the result should spit out relevant information (hopefully).
The reason why your NIC is named the way it is, is because the name is now built on the NIC’s chipset/name… not some generic name. It’s supposed to avoid confusion on multi-homed machines, but I think many are finding it just harder to type (I am).
On 2014-02-17 16:46, tsu2 wrote:
>
>
> This is openSUSE running systemd.
> One of the benefits of systemd is that you can use “systemctl” to manage
> any Unit file configured for any subsystem.
But also, this is openSUSE, and it happens to be an openSUSE policy that
all services must have an rc file to start it.
There was recent talk in factory about how to enforce this policy.
> Instead of learning the numerous commands for each subsystem, you can
> typically execute the same command for all, eg
>
> Code:
> --------------------
> # systemctl restart network
> --------------------
Thus if the above exists, mandatorily in openSUSE “rcnetwork restart”
will also exist and work
No need to learn the names, either. You type “rc”, hit {tab} twice, and
you get the entire list
I suspect the problem is on the host, something with the Wireless connection and the way Virtualbox interacts with it.
As many have found (me included), opensuse 13.1 works in a VM and essentially they’re all the same. So it’s not there that the problem lies, unless the configuration you installed has some specific issues - installation of special software, low on memory or disk, etc…
But if that’s not the case it’s on the host you must seek the solution, either in the settings of Virtualbox or in the network of the host: is it a plain vanilla 192.168.x.x with dhcp or is it something else?
Actually, I’ve been seeing this quite regularly in VMware as well (Guest doesn’t pick up a DHCP IP address on bootup).
Am thinking about converting them to static IP addresses to see if it solves the problem.
So far am not seeing this in any other OS but on the other hand approx. 90% of my Guests are openSUSE.
On 02/17/2014 01:28 PM, Carlos E. R. pecked at the keyboard and wrote:
> On 2014-02-17 16:46, tsu2 wrote:
>>
>> This is openSUSE running systemd.
>> One of the benefits of systemd is that you can use “systemctl” to manage
>> any Unit file configured for any subsystem.
> But also, this is openSUSE, and it happens to be an openSUSE policy that
> all services must have an rc file to start it.
>
> There was recent talk in factory about how to enforce this policy.
>
>> Instead of learning the numerous commands for each subsystem, you can
>> typically execute the same command for all, eg
>>
>> Code:
>> --------------------
>> # systemctl restart network
>> --------------------
> Thus if the above exists, mandatorily in openSUSE “rcnetwork restart”
> will also exist and work
>
>
> No need to learn the names, either. You type “rc”, hit {tab} twice, and
> you get the entire list
>
Wouldn’t it be great to type systemctrl restart <tab><tab> and get a
list of running processes available for a restart or any other parameter
for systemctrl?
On 2014-02-17 19:53, Ken Schneider wrote:
> On 02/17/2014 01:28 PM, Carlos E. R. pecked at the keyboard and wrote:
>> No need to learn the names, either. You type “rc”, hit {tab} twice, and
>> you get the entire list
>>
> Wouldn’t it be great to type systemctrl restart <tab><tab> and get a
> list of running processes available for a restart or any other parameter
> for systemctrl?
On 02/17/2014 04:34 PM, Carlos E. R. pecked at the keyboard and wrote:
> On 2014-02-17 19:53, Ken Schneider wrote:
>> On 02/17/2014 01:28 PM, Carlos E. R. pecked at the keyboard and wrote:
>
>>> No need to learn the names, either. You type “rc”, hit {tab} twice, and
>>> you get the entire list
>>>
>> Wouldn’t it be great to type systemctrl restart <tab><tab> and get a
>> list of running processes available for a restart or any other parameter
>> for systemctrl?
> Did you try? it works here.
>
> There is a bash completion module in systemd.
>
That works but I was hoping to only see running services when trying
restart, instead it shows all services. But it does help for finding the
name of the service. This does help to eliminate the need for the ‘rc’
links.
On 2014-02-18 02:59, Ken Schneider wrote:
> On 02/17/2014 04:34 PM, Carlos E. R. pecked at the keyboard and wrote:
>> There is a bash completion module in systemd.
>>
> That works but I was hoping to only see running services when trying
> restart, instead it shows all services.
Ah, yes, true. It is a very long list.
Try “systemadm”. You have to install “systemd-ui”.
Not too stable, though… I managed to crash it just now:
Ken,
Here is a thumbnail on what you’re asking about.
All systemd Unit files are named “name.unit-type” eg network.service
This means
If you want to list often used Unit files
systemctl
If you want to list Unit files in their various states (I recommend piping “more” as follows) You can use this command to discover the various “types” which is the next command below
systemctl -all | more
If you want to list all files of the same type, as follows. You should know that these types are generally consistent with subsystems so “target” refers to Unit files that load and run on boot, and the following displays service files.
systemctl -t service
You may notice that when you list Unit files, you return state (running, stopped, active, inactive, loaded, unloaded, etc) so you can grep the following that returns services that are loaded but not active for whatever reason (some only run for a moment then exit). These can usually be started with a simple “start” command
