Im having failure to install PIAF 3 or PIAF 3.1.6. It hangs at the 'stopping ntp services'. Both times I tried clean install from scratch. After 5 mins I ctrl-C then it picks back up, but fails later when again it hangs 'stopping ntp services'.
Any ideas anyone?
CentOS 6.7 64Bit minimal
Green 3.1.6 033015
running on a DELL desktop T20.
Open new terminal.
service ntpd stop
You will see installation will continue where it was stuck.
Repeat it until when ever script hang while 'stopping ntp services'
It works perfectly file with me, hope it will solve your problem as well. Keep me posted.
Related
The com.canonical.multipassd service is constantly logging errors on my Mac and multipass won't work at all, even after reinstalling, rebooting, and updating my Mac.
In an attempt to use my GPU in a Linux VM through multipass, I tried to install the AMDGPU driver for my card (Radeon Pro 5300 4GB). I had installed multipass through brew and made some progress, but the ./amdgpu-install process was returning various errors as a result of missing dependencies. Having started to resolve the missing dependencies, in an attempt to build the driver again, the build just stopped halfway through and I couldn't terminate the process or get the VM to respond at all (didn't take a screenshot sorry).
Because of this, I closed the VM shell and tried to get multipass to shut down the VM. Multipass stopped responding altogether - the application just spun, and it didn't respond at all in terminal. I force quit multipass in Activity Monitor. That still didn't fix it, so I (somewhat stupidly) force quit 'hyperkit' and 'multipassd'. This is where everything went really wrong.
Having force quit 'multipassd', I tried to re-open multipass, but it returned the error below
list failed: cannot connect to the multipass socket
Please ensure multipassd is running and '/var/run/multipass_socket' is accessible
I looked this up and tried a few suggested solutions. I uninstalled multipass with Brew. I deleted the application, and reinstalled with brew. I also tried brew remove multipass, and tried installing using the .pkg from the multipass website. When that didn't fix it, I restarted my computer and reset NVRAM on startup. That also didn't make a difference, so I have just updated my Mac to MacOS 11.4, and it is still not fixed.
The console logs suggest that multipassd is still doing something, as it is continually logging in the system.log:
May 26 09:39:15 <myName> com.apple.xpc.launchd[1] (com.canonical.multipassd[2131]): Service exited with abnormal code: 1
May 26 09:39:15 <myName> com.apple.xpc.launchd[1] (com.canonical.multipassd): Service only ran for 0 seconds. Pushing respawn out by 10 seconds.
In the multipass log, this message is also being generated about once every 10 seconds:
[error] [daemon] Caught an unhandled exception: Invalid MAC address
[warning] [Qt] QMutex: destroying locked mutex
These messages are being generated even after resetting NVRAM and rebooting. I think they're the cause of my issue launching multipass, but I haven't found any solution to stop them, and I can't identify any process that is still running related to multipass. As far as brew is concerned, multipass is not installed, but it's logs are still filling up...
Happy to provide console or terminal output if needed - nothing else on my Mac seems to be broken, I just can't use multipass now. I do have a time machine backup, so if that is guaranteed to fix it, I might just resort to the backup, but I'm not sure that would necessarily fix it, and I would rather find an alternative solution.
As this has probably made clear, I'm very new to Linux and VMs... any solutions greatly appreciated!
Fixed it!! I hadn't properly uninstalled it - the 'proper' uninstall script can be run using
sudo sh "/Library/Application Support/com.canonical.multipass/uninstall.sh"
Reinstalling multipass after running this command worked fine.
I am been fighting with TigerVNC since around Fedora 17. Every time I started it manually I would get a black screen that would eventually display the gnome desktop and if I started with systemctl it would not work at all.
Recently wiped my system and installed Fedora 30. Same black screen when I manually start vncserver, but now it never displays the gnome desktop.
These are all default installs. I get no errors to accompany the black screens. I am at a loss of what to do. Could someone provide a working xstartup, config, and command line vncserver command so that I can hopefully get this working?
I had the same issue today after a fresh Fedora 30 install.
But, my home directory is from an older install so I'm using my old ~/.vnc directory and ~/.Xclients file.
I got it working by doing the following two things:
sudo echo "DESKTOP=GNOME" > /etc/sysconfig/desktop
Start vncserver manually as yourself. If you are already running a desktop on your system then you will have to use a different display number, so the command would be something like "vncserver :2".
I recently upgraded to Ubuntu16 from 14. Everything went fine, however my wifi connection went to a crawl. I actually experienced this on a previous system that I installed Ubuntu16 on and because of that, stuck with Ubuntu14 for as long as I could until version lag forced me to upgrade.
I came across this solution that was referring to Ubuntu 17
https://askubuntu.com/questions/905288/extremely-slow-connection-after-17-04-update
And it seemed to do the trick!
The only issue is that now after a system suspend or boot-up, I have to run
sudo systemctl restart systemd-resolved
Otherwise I cannot connect to any server.
Its not a huge deal, I've aliased it at this point, but it would be nice get it operating appropriately.
Thanks for the help!
Download this link. If the download by the first link failed, download this file.
Open the Terminal and run these commands on your ubuntu pc.
cd rtlwifi_new-master
make
sudo make install
sudo modprobe -rv rtl8723be
sudo modprobe -v rtl8723be ant_sel=2
sudo ip link set wlp13s0 up
sudo iw dev wlp13s0 scan
Very often when running ansible-playbook on the Vagrant VM from Windows, I need to stop in the middle of something by pressing Ctrl+C. This happens if ansible becomes unresponsive or there is some bug we need to fix asap, so there is no point of waiting until provisioner completes.
The probem is that Ctrl+C does not work, some 2 ruby.exe processes get stuck in process tree. Any subsequent vagrant commands fail until you manually kill these ruby processes.
I also use to kill all stucked python ansible processes on the VM before running new provision.
Any way to handle it more jently?
I found this problem as well on Windows and using Puppet Apply. The only way I can happily kill it by opening another terminal/cmd and then vagrant ssh -- sudo pkill puppet. That gracefully terminates the process, and allows me to regain control of my first terminal again.
In short the solution is:
Take a terminal that works.
I find one working gitbash v2.32.0.windows..
The latest available gitbash currently is v2.38.1. But only the old one is working correctly with Vagrant(Oracle VM). The strange thing is that the latest one (gitbash v2.38.1) is working fine with SSH connections to AWS EC2 instances.
Alternatively. Windows PowerShell is working fine with Vagrant(Oracle VM).
If someone needs my bad experience, here it is.
The following terminals DON'T WORK
gitbash v2.38.1 (latest for now)
gitbash V2.36.0
ConEmu v220807 Alhpa (latest for now)
cmder v1.3.20.1282 (latest for now)
I propose using vagrant halt.
When there are problems while running a recipe and the client run is hanging half way, the installed Chef client will be unusable.
You can then exit the machine, reboot, clean up chef pid files and so forth but each time the Chef client is started the following message is shown:
Chef client is running, will wait for it to finish and then run.
Chef should be able to recover from this when a reboot is performed but this is not the case.
What is the best way to recover from a client run that hangs half way? Currently I delete the VM and create a new one but that is not a real solution.
Is it possible to recover when it hangs half way?
Stop the service if any running : sudo service chef-client stop
if the issue persists
find out if nay chef client process/service is running: ps aux | grep chef
kill the process
if the issue persists
look up your chef client settings under /etc/chef/client.rb and/or your etc/init.d/chef-client
then locate the pid_file and lockfile path
delete the files
if the issues persists, you might run like me a old version of chef-client
you need to look in your chef cache folder
I had to delete /var/chef/cache/chef-client-running.pid
If it timeout takes place - converging should work fine over and over again. Well, if you need to remove client - you can run sudo rm -rf /etc/chef on client machine. All the options are described here in details.
I ran into the same issue where the kitchen converge process would get hung, typically due to an improper msi installation in my case. I would then have to reboot the kitchen machine.
I noticed that an elevated scheduled task was running which when stopping, it would kill the process, but the issue returned when I ran it again ("chef client 2092 is running, will wait for it to finish and then run").
It then occurred to me that the last attempt to reboot, which normally resolves the issue, didn't succeed because of an open file preventing the reboot. Rebooting the machine did resolve the issue in my case. It's not a perfect solution but it does work as a work-around in my case.