I installed updates on my HP Opensuse Laptop and I cannot get wifi to connect anymore. The Wifi menu in the system tray is missing. I can see bluetooth, but not wifi. Upon investigation, Network Manager service is not running. When I try to run Networkmanager service from terminal using command NetworkManager --no-daemon, it comes up with the below error message.
NetworkManager: /lib64/libcrypto.so.1.1: version 'OPENSSL_1_1_1d' not found (required by /usr/lib64/libssh.so.4)
I have done some research and tried the following things.
Disable NetworkManager and Enable wicked service, but still the interfaces are complaining about NM not working.
When I check hwinfo, I can see the correct model and drivers for the wlan adapter.
I enabled the disabled adapters using ifup wlo1 as the interface was down when I checked ip addr
I was able to use iwlist wlo1 scan, I can see the networks in range, so the adapter is fine. It is an intel
I checked for bugs and there are some reports of similar behavior in 2019.
Use nmcli, it comes up with a message that "network manager is not running"
Tried to use YasT to disable NM and enable Wicked, but YasT does not bring up the Network screen any more after the update. It just spins and does nothing.
Ran Yast from terminal, it comes up with another message to report bug
Internal Error: Please report the bug report with logs. Run save_y2logs to get complete logs.
Caller: /uwr/lib64/ruby/vendor_ruby/2.6/0/yast/yast.rb:186:in "import_pure".
Details: Failed to import module 'PackageSystem' due to component cannot import namespace 'pkg'
Configuration:
uname -a
Linux linux-new 5.4.7-1-default #1 SMP Wed jan 1 07:55:50 UTC 2020 (34ebd01)
cat /etc/*release
LSB_VERSION="core-2.0-noarch:core-3.2-noarch:core-4.0-noarch:core-2.0-x86_64::core-3.2-x86_64:core-4.0-x86_64"
NAME="Opensuse Tumbleweed"
VERSION="20200110"
Does anyone have any ideas?
Related
Simple question but I can't seem to find the answer to this. When I launch of VM on GCP, I'm getting into the machine via the serial port due to some testing we're doing, but the there what looks like logs from process that continuously log out to the screen (assuming this is stdout when accessing via serial port?). I'm trying to turn this off but can't seem to figure out how to.
here is the version that I'm using:
cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 9 (stretch)"
NAME="Debian GNU/Linux"
VERSION_ID="9"
VERSION="9 (stretch)"
VERSION_CODENAME=stretch
ID=debian
HOME_URL="https://www.debian.org/"
SUPPORT_URL="https://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
You can let all noisy output to be delivered to the default port ttyS0 (COM1) and enable alternative login prompt on ttyS1 (COM2).
To enable alternative serial port temporarily until next reboot:
$ sudo systemctl start serial-getty#ttyS1.service
To enable alternative serial port permanently:
$ sudo systectl enable serial-getty#ttyS1.service
Then you might connect to the enabled alternative serial port ttyS1 from Cloud Shell:
CloudShell:$ gcloud compute connect-to-serial-port my-vm --zone=my-zone --port=2
You have 2 way to deactivate the serial ports, as described in the documentation
Either you deactivate it on a specific VM with a metadata value
Or you can apply an organization policy to avoid the serial port use in your organisation, on folders or on an entire project. (We applied this in my company, for security reasons)
When I run vagrant up I get this error
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["startvm", "3ae7b70c-8ea1-417a-ab67-99aef96624f8", "--type", "headless"]
Stderr: VBoxManage.exe: error: Failed to open/create the internal network 'HostInterfaceNetworking-VirtualBox Host-Only Ethernet Adapter #2' (VERR_INTNET_FLT_IF_NOT_FOUND).
VBoxManage.exe: error: Failed to attach the network LUN (VERR_INTNET_FLT_IF_NOT_FOUND)
VBoxManage.exe: error: Details: code E_FAIL (0x80004005), component ConsoleWrap, interface IConsole
I found the solution here: https://www.howtoforge.com/setup-a-local-wordpress-development-environment-with-vagrant/ which is to update the driver of VirtualBox Host-Only Ethernet Adapter
But the problem is I am remotely connected to the machine. So I am afraid that the network settings may lose my remote connection. Also, I cannot reboot the machine.
Is it safe to follow the steps mentioned in the link above which should not disconnect me? If not, is there any alternative way?
Recently I have struggled with this issue. I tried many times to solve the issue. Sometimes I was able to run my vagrant machines successfully but how I did was not sure because I was trying lot of options. But finally, I found a way to solve it. It's pretty simple and tricky.
Solution:
Once you get this error on your terminal, just open your computer network adaptors from the control panel. Select the adaptor which was created for that virtual box. simply disable once and enable again. then run vagrant up command. That's it. the problem is gone.
- Start --> Network status --> Change adaptor options --> (select the Ethernet adaptor - In my case it is Ethernet4)
- Right click --> Disable and right click --> Enable
- vagrant up
I faced the same issue and could not resolve it by changing properties in Network Adapters.
Then i reinstalled Virtual Machine by below command and it worked fine:
V:\softwares>VirtualBox-6.0.4-128413-Win.exe -msiparams NETWORKTYPE=NDIS5
yesterday i baught a new WLAN Nano USB Adapter (LogiLink/WL0084E/Should be supported by Linux). Now i have tried to get it running with my BBB which is running on Debian Wheezy.
First i pluged the WLAN USB Adapter in and i got following Result using lsusb:
Bus 001 Device 003: ID 0bda:8179 Realtek Semiconductor Corp.
I have googled for the ID 0bda:8179 and found following Website: https://wiki.debian.org/rtl819x wich told me to install firmware-realtek by using sudo apt-get install firmware-realtek. After that i should restart by System shutdown -h now and power on again (I know a reboot will do the same).
But the WLAN Adapter was not recoginzed as wlan0 - if i type in ip a i got following result:
1: lo: ...
2: eth0: ...
3: usb0: ...
The Website mentioned above told me that i need the module r8188eu - But on lsmod i got following output:
Module Size Used by
g_multi 50407 2
libcomposite 15028 1 g_multi
omap_rng 4062 0
mt7601Usta 458758 0
So i tought mt7601Usta can may be the right one and i typed in modinfo mt7601Usta
filename: /lib/modules/3.8.13-bone79/kernel/drivers/net/wireless/mt7601Usta.ko
version: 3.0.0.3
description: RT2870 Wireless Lan Linux Driver
But may this driver doesnt Support the WL0084E (Supported by Linux!).
What should i do?
Why do i not have the wlan0 interface?
How can i fix this Problem?
If you need more information, told me commands to execute ;)
Thank you!
Download the latest 8188 driver from realteks website, extract and run install.sh
http://www.realtek.com/downloads/downloadsView.aspx?Langid=1&PFid=48&Level=5&Conn=4&ProdID=274&DownTypeID=3&GetDown=false&Downloads=true
If that doesn't work either just give up with trying to get Wheezy to support it and just hope it works automatically in a newer distro/kernel
My Cygwin installed on Windows 7 was working properly till I try to install a new package. The package installation failed. Then I keep getting this error every time I want to run my Open MPI program. I can successfully compile the program but cannot run it. I even remove and make a new installation without success.
Thanks for any hints. Below is the sample error message.
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:03900] [[3921,1],0] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
[Reloaded-PC:04676] [[3921,1],2] tcp_peer_send_blocking: send() to socket 13 failed: Transport endpoint is not connected (128)
The problem is solved by disabling the unused network adapter in "Control Panel->Network and Internet->Network Connections".
It turned out the unused network adapter tried to get configured by DHCP and an IP address started with "169.254.X.X" was assigned to this adapter when DHCP fails. Somehow openmpi on Cygwin use that invalid IP address for establishing communication between processes.
I figured it out by looking at /tmp/openmpi-sessions-{username}/{PID of orterun}/contact.txt.
I had this same problem on Cygwin with OpenMPI 1.10.4.
Try adding "-report-uri -" to your mpirun command to see what IP address it's trying to use for connection:
mpirun -report-uri - -np 2 a.exe
It should print out a line that looks something like this:
568328192.0;tcp://192.168.10.103,169.254.247.11,0.0.0.0,0.0.0.0,0.0.0.0:55600
If the first IP address after the "tcp://" is not a current valid address for your machine, that's the problem and things are likely to break (even if the correct IP appears later in the list). Apparently ORTE is not smart enough to order the interfaces based on what is actually enabled and online.
If the wrong IP corresponds to an old/disabled interface, uninstall it (if possible) using the windows network connections control panel.
In my case, the first address was a DHCP address for an old hardware adapter I'd removed and thrown away long ago (but apparently not uninstalled in software). Windows normally hides such removed-but-not-uninstalled interfaces in the control panel, but the settings remain in the registry under:
HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\
Search in that registry subkey for the bogus IP address and you are likely to find the problematic interface. I fixed mine by changing the IP address in that registry key to match my current static IP, but uninstalling the interface entirely would probably also work.
I had the same problem with openmpi v 1.8.8 (which is the default version of the package installed by cygwin). Manually going back to version 1.8.6 fixed the issue for me.
I just encountered this problem and in my case I had to disable the "VirtualBox Host-Only Network" adapter (I recently installed virtualbox and have not used openmpi in cygwin after that until today).
1. Open the Cygwin terminal.
mpicc --version
mpirun --version
If not execute, follow the document below and reinstall everything. Document
2. Try turning off Bluetooth and test your program again.
3. Try closing the Wifi and test your program again (you can connect to the wired internete)
4. Open C:\Windows\System32\drivers\etc\hosts
add line
127.0.0.1 localhost cygdrive wpad
and test your program again.
5. If you have a virtual network like VirtualBox or similar, turn off the control panel and test your program again.
6. If possible, uninstall VirtualBox completely. Restart your computer and test your program again.
7. Try turning off the Windows Firewall and test your program again.
The above steps solved both the "tcp_peer_send_blocking: send () to socket 12 failed: transport endpoint is not connected" error and the slowness problem in MPI for Windows 10 - Cygwin.
I have a linux PC acting as a clock client and I would like to synchronize this PC's time using ntpdate against a Windows PC in the same space on the same network. I'm having trouble finding how to do this.
It isn't as easy as just calling ntpdate and using the IP address of the windows PC it would seem although I thought that the Windows Time service was an NTP server. You can see the results of that effort below:
signageclient#signagePC:~$ sudo ntpdate -u 192.168.1.100
1 Apr 09:49:03 ntpdate[12698]: no server suitable for synchronization found
Can anyone suggest how I would do this synchronization? Perhaps the proper windows service hasn't been started? In the above axample, this command is being run on the client PC (linux) and 192.168.1.100 is the IP if the windows PC. No firewall is on currently.
Found the answer! I needed to enable Windows NTP Server in the Local Group Policy Editor under Computer Configuration -> Administrative Templates -> System -> Windows Time Service -> Time Providers. After I enabled this I was able to synchronize against the PCs clock:
signageclient#signagePC:~$ sudo ntpdate -u 192.168.1.100 1 Apr
09:57:08 ntpdate[13347]: adjust time server 192.168.1.100 offset
-0.031445 sec
(This is all in Windows 7 by the way)