I am training myself on Linux with a Raspberry Pi 400 (OS: Raspbian) and I would like to setup my personal config file for apps (notably the Terminal in Zsh). I am able to setup my config onto the terminal with the following:
$ cd .dotfiles
$ ./export.sh
$ cd zsh/
$ source ./zshrc
The problem comes when I quit the terminal or if I open a new terminal or if I reboot the computer, the config is not "saved".
I am not an expert, but for changing bash to zsh and maintaining it as default shell language, I did the following:
$ nano /etc/passwd
and changed the following line from :
pi:x:1000:1000:,,,:/home/pi:/bin/bash
to:
pi:x:1000:1000:,,,:/home/pi:/bin/zsh
This move managed to get me zsh from start every time now. I am wondering if i can directly source my .zshrc with the same technique ... Or would you have any better idea?
I would like to avoid repeating the sourcing steps at every start in the terminal ...
I have a source code that runs perfectly fine on Ubuntu, it does some copumtations, and at some points it beeps like this
system("beep -f 400 -l 500");
On Ubuntu I had to do
apt-get install beep
However, I migrated to OpenSuse (not my choice) and now I get this message "sh: beep: command not found", as the command and package are obviously different.
Does anybody know hot to trigger the system beep sound and define the duration and frequency? I have been able to find only one way to change the parameters
setterm -bfreq 500 -blength 500
, but no way to actually trigger the system bell (beep). The following things don't work
echo ^G
echo -e "\a"
PS - the system Bell is enabled at
Configure Desktop -> Application and System Notifications -> System Bell
and you can actually play with this
So, I did what #fvu proposed.
However, one needs to have sudo rights, to do so, otherwise (e.g. at my work-place we don't have sudo rights) there is this output message
Could not open /dev/tty0 or /dev/vc/0 for writing open: No such file or directory
In this case, you should:
sudo chmod 4755 /usr/bin/beep
as proposed here
I noticed that on my OpenSuse 12.3 system, the bell is working in xterm or gnome-terminal, but not in konsole or xfce4-terminal.
If the same applies to your system, then maybe a work-around could be creating a shell script called "beep" which calls xterm and rings the bell:
#!/bin/sh
xterm -e "echo -e '\a'; sleep 1"
How do I delete a VirtualBox machine in the GURU_MEDITATION error state? Is it enough just to delete the directory while VirtualBox is not running?
EDIT: After posting, I deleted the entire directory that "Show in File Manager" navigates to.
It looks like:
Note that there is no power off, and even remove is greyed out. I believe this is the exact same as it looked even before I deleted the directory.
EDIT 2: I tried the command line poweroff after deleting the files. It hangs:
vboxmanage controlvm wmf-vagrant_1354733432 poweroff 0%...10%...20%...
EDIT 3: It also fails to unregister it from the command-line:
VBoxManage unregistervm wmf-vagrant_1354733432 --delete VBoxManage:
error: Cannot unregister the machine 'wmf-vagrant_1354733432' while it
is locked VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE
(0x80bb0007), component Machine, interface IMachine, callee
nsISupports Context: "Unregister(fDelete ?
(CleanupMode_T)CleanupMode_DetachAllReturnHardDisksOnly :
(CleanupMode_T)CleanupMode_DetachAllReturnNone,
ComSafeArrayAsOutParam(aMedia))" at line 160 of file
VBoxManageMisc.cpp
Kill the VBoxHeadless process and run "vagrant destroy"
Destroying vagrant and sending the kill signal with the "killall" command looks like:
killall -9 VBoxHeadless && vagrant destroy
If you can't power off the machine from VirtualBox GUI, then try from the command line using vboxmanage command (VBoxManage on OS X), e.g.:
vboxmanage controlvm NAMEOFVM poweroff
Change NAMEOFVM with the name from vboxmanage list vms command.
then unregister and delete the VM:
vboxmanage unregistervm NAMEOFVM --delete
Or delete it manually:
rm -fr ~/"VirtualBox VMs/NAMEOFVM"
I hit this problem. Eveything I read recommend that you should always manage the boxes via Virtual Box, not directly access files. But when I had an invalid box, the unregistervm command refused to delete it and vagrant destroy did not work. In the end the following process worked.
Kill all running VBox* processes
Delete the folder "boxname" from the folder "VirtualBox VMs"
Edit the file "VirtualBox.xml" and remove the tag corresponding to the invalid box.
I then ran this command the verify the box was gone.
VBoxManage list vms
After that I was able to create a new vm with the same name.
I had a VM that got in a similar state
$ vagrant up
Bringing machine 'tempu' up with 'virtualbox' provider...
==> mms: Checking if box 'hashicorp/precise64' is up to date...
==> mms: Resuming suspended VM...
==> mms: Booting VM...
There was an error while executing `VBoxManage`, a CLI used by Vagrant
for controlling VirtualBox. The command and stderr is shown below.
Command: ["startvm", "9fcf2203-d4b3-47a1-a307-61bfa580bd28", "--type", "headless"]
Stderr: VBoxManage: error: The machine 'temp-ubuntu' is already locked by a session (or being locked or unlocked)
VBoxManage: error: Details: code VBOX_E_INVALID_OBJECT_STATE (0x80bb0007), component Machine, interface IMachine, callee nsISupports
VBoxManage: error: Context: "LaunchVMProcess(a->session, sessionType.raw(), env.raw(), progress.asOutParam())" at line 592 of file VBoxManageMisc.cpp
I looked for a process called VBoxHeadless, but it wasn't running.
I then ran ps and found this process with the same vm id:
$ ps aux | grep -i virtualbox
user 63466 0.0 0.1 2523608 8396 ?? S 9:36am 0:02.67 /Applications/VirtualBox.app/Contents/MacOS/VBoxManage showvminfo 9fcf2203-d4b3-47a1-a307-61bfa580bd28 --machinereadable
Killing that process fixed the problem and VM started correctly after running vagrant up
This is a script I use when I get desperate. It wipes as much trace of any VM from the machine as I can find:
VBoxManage list runningvms | awk '{print $2}' | xargs --no-run-if-empty -t -n1 -IXXX VBoxManage controlvm XXX poweroff
VBoxManage list vms | awk '{print $2}' | xargs --no-run-if-empty -t -n1 VBoxManage unregistervm
killall -9 VBoxHeadless
rm -rf ~/Virtualbox\ VMs/*
I am using Debian Wheezy on a 64-bit multiple-processor host. I was able to solve it eventually by removing all VirtualBox data (though you did not need to delete the Vagrant base box):
Close Virtualbox if running
sudo apt-get remove --purge virtualbox
Move or delete ~/.VirtualBox and ~/VirtualBox\ VMs/. If you're not sure, back them up to a safe place.
Restart.
Reinstall virtualbox.
Use virtualbox/vagrant as normal.
There may be a less disruptive way (e.g. removing only parts of these directories). In my case, fortunately I was using only one VM at the time.
In my case, I wanted to delete ALL Vagrant boxes I currently have on my system by a command line, I did that by:
$ vagrant box list | cut -f 1 -d ' ' | xargs -L 1 vagrant box remove -f --all
Of course, after making sure no further process is attached any more:
killall -9 VBoxHeadless && vagrant destroy
No matching processes belonging to you were found
On windows 10, i solved this problem setting Default firewall configurations back.
Hope it helps...
I've been struggling with frozen Virtual Box instances created earlier using Vagrant.
Luckily found a solution mentioned in similar ticket
so, to recap, if your getting Timeout error or Vagrant complaining it can't provision or any other kind of related issue with Virtual Box try:
List virtual box instances first: VmboxManage list vms
Stop the virtual box instances using id|names of previous command: VBoxManage startvm VMNAME/id --type emergencystop
List vagrant boxes with vagrant box list
Remove one or more causing issues vagrant boxes: vagrant remove box ${box-name}
Afterwards, try vagrant up again and hopefully you will be back to business.
Good luck!
Open the task manager or system monitor and hover with the mouse over the VBoxHeadless to see the name of the VM and kill the process.
Now you can remove the VM with the VirtualBox Manager GUI.
Run vagrant global-status
Identify the vm id
Run vagrant destroy [vm id]
You can use below command to delete VM from vritual box-
vagrant destroy
And use below command to create VM and start again-
vagrant up
i have installed fresshd in one of my windows server.now i am connect to the system through putty. It is working fine.
my issue us when i am running from command line
PuTTY.lnk -ssh -2 -P 22 username#XXX -pw pswd -m command.txt
commands given in the command.txt files are not executed it just open the putty console and it is closing.
when Running from Jenkins also same issue.
I am not sure if you are connecting to Windows from a Linux machine, or to Linux from a Windows machine. Or Windows to Windows?
PuTTY.lnk is not an executable. If you try to run that, it should produce an error 'PuTTY.lnk' is not recognized as an internal or external command. I am assuming you are running the command from a Windows machine, since you are referring to windows shortcut file (.lnk)
You need to use PuTTY.exe + the rest of your command line. Please note that unless it is in your $PATH settings, you would have to provide a full path to the .exe, for example C:\LocationOfPuttyInstall\putty.exe -ssh -2 -P 22 username#XXX -pw pswd -m command.txt. For the sake of preventing any other problem, you should also specify a correct full path to the command.txt file.
If you are not sure where your Putty is installed, on the Windows machine, do the following:
Right click your PuTTY shortcut (the PuTTY.lnk file)
Look under "Target"
That would list your full path to PuTTY.exe executable.
This should resolve your problem.
p.s.
Usually Putty is used to connect from a Windows machine to a Linux machine. From your question, it almost looks like you are trying to connect from a Windows machine to another Windows machine.
You should use PsExec windows tool for such purposes:
http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx
I have a 32-bit desktop, where my copy of emacs is running.
I'd like to be able to debug a program running on a very stripped down qemu 64 bit virtual machine.
The virtual machine has an ssh port 24054, which gives me passwordless root access, and it does have gdb installed.
And it has the directory which my desktop calls ~/myco/chip_test mounted as /9p
So if I make a hello.c file in ~/myco/chip_test,
then go to the 64 bit machine in which the VM will run, and compile it with:
$ gcc -o hello -g hello.c
then start the virtual machine, and on my 32-bit desktop run
$ ssh -p 24054 root#anvil 'cd /9p && gdb ./hello'
Then gdb runs perfectly in command line mode in a window on my desktop.
So now of course I want it to run under emacs, because the command line gdb is a bit hard to read, and I'd like to see my cursor stepping through the file, and have windows with watch variables and so on.
So I try M-x gdb
Run gdb(like this): ssh -p 24054 root#anvil cd /9p && gdb --annotate=3 ./hello
And I get a debugger window up in emacs and everything looks right, in fact I can even set and remove breakpoints by clicking in the fringe of the ~/myco/chip_test/hello.c file in my local emacs, which is the same file as what gdb sees as /9p/hello.c, but the moving cursor doesn't appear or move around, so the whole thing is fairly useless.
So I think that emacs/Gud doesn't quite realise that ~/myco/chip_test/hello.c is the file that the debugger thinks is /9p/hello.c, although obviously something interesting is happening since I can set breakpoints, and so I wonder if there is a way to get one or another programs in the loop to translate the filenames so that everything just works.
Any ideas, or am I just going about this all wrong?
You'll get much better results if you either
mount /home/<user>/myco/chip_test on /home/<user>/myco/chip_test in the
VM (so the source paths match exactly), or
run gdbserver in the VM, and connect local GDB to it.