Description of problem:
On SLES-12 machine, if we try to delete the disk image through virsh vol-delete command immediately for vm which is provisioned through virt-manager, getting
cannot unlink file 'XXX': Permission denied" error.
This error occurs only for disk which gets created while provisioning the vm.
If we delete the same disk through virt-manager then it gets deleted properly.
If we create another disk through virt-manager and delete by using above virsh command,it gets deleted properly.
To summarize, problem is only for deleting disk which is created as part of provisioning VM.
Version-Release number of selected component (if applicable):
OS:SUSE Linux Enterprise Server 12 SP1 (x86_64)
Libvirt Version:
cv-hj-kvmlib01-am02:/var/lib/libvirt/images # virsh version
Compiled against library: libvirt 1.3.1
Using library: libvirt 1.3.1
Using API: QEMU 1.3.1
Running hypervisor: QEMU 2.3.1
Steps to Reproduce:
Provision the vm through virt-manager on SLES_12
Delete the disk image which is created while provisioning the vm using virsh command line:
virsh # vol-delete /var/lib/libvirt/images/.qcow2
error: Failed to delete vol /var/lib/libvirt/images/.qcow2
error: cannot unlink file '/var/lib/libvirt/images/.qcow2': Permission denied
I think this might be similar to the question you asked here.
Assuming this is a volume you've properly detached from the VM, you probably just need a pool-refresh to let virsh know the volume is no longer in use:
# virsh pool-refresh default
(assuming your using the 'default' pool)
Then try deleting again. If you still get permission errors, I'd suggest looking at the perms of the image files and the contents of the following two configs:
/etc/libvirt/qemu.conf
/etc/libvirt/libvirtd.conf
Related
I want to install MySQL community edition 5.7.29 on OpenSuse Linux leap 15.1 as following:
Download the file: mysql-5.7.29-1.sles12.x86_64.rpm-bundle.tar;
untar the file then get 8 files
>mysql-community-client-5.7.29-1.sles12.x86_64.rpm
>mysql-community-common-5.7.29-1.sles12.x86_64.rpm
>mysql-community-devel-5.7.29-1.sles12.x86_64.rpm
>mysql-community-embedded-5.7.29-1.sles12.x86_64.rpm
>mysql-community-embedded-devel-5.7.29-1.sles12.x86_64.rpm
>mysql-community-libs-5.7.29-1.sles12.x86_64.rpm
>mysql-community-server-5.7.29-1.sles12.x86_64.rpm
>mysql-community-test-5.7.29-1.sles12.x86_64.rpm
install the 4 files rpm using the command:
>sudo zypper install mysql-community-{server,client,common,libs}-*
Then the error message shows as below:
>mysql-community-common-5.7.29-1.sles12.x86_64.rpm:
Header V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEY
V3 DSA/SHA1 Signature, key ID 5072e1f5: NOKEY
>Looking for gpg key ID 5072E1F5 in cache /var/cache/zypp/pubkeys.
Repository Plain RPM files cache does not define additional
'gpgkey=' URLs.
mysql-community-common-5.7.29-1.sles12.x86_64 (Plain RPM files
cache): Signature verification failed [4-Signatures public key is
not available]
>Abort, retry, ignore? [a/r/i] (a):
Any response will be appreciated.
Just write i to bypass this issue and successfully complete installation.
The issue because by default OpenSUSE use downloads.opensuse.org repository that seems to use proxy to nearest server mirror, but the problem is that it seems some mirrors does not update something on his servers so you found messages like "Signature verification failed".
You can try several solutions:
Use some VPN service to change your IP location to find a chance that download.opensuse.org will redirect you on some good mirror.
Change "download.opensuse.org" domain in the repo configuration in the /etc/repo.d (or /etc/zypp/repo.d) to some other server from the list: https://mirrors.opensuse.org/list/15.0.html and put it into the repository files (/etc/repo.d/* or /etc/zypp/*), e.g. http://nrt.edge.kernel.org/opensuse (instead of http://download.opensuse.org).
Also you can change source server even in the OpenSUSE installation mode while use graphical install. For that you should cancel graphical install and when text mode menu opened, in the "Expert mode" you can edit configuration from the console. In the console you can't use "vi" so use "sed" command to change the file contents.
Scan configs:
grep "downloads.opensuse.org" -r /etc
Change content for every file:
sed -i s/downloads.opensuse.org/nrt.edge.kernel.org\/opensuse/g /etc/products.d/openSUSE.prod
...
I am running Podman version 1.6.2 on Ubuntu 18.04. I am unable to start a container after stopping it.
I run the container with:
podman run -d -p 8081:8081 --name nexus -v /opt/nexus-data:/nexus-data sonatype/nexus3
And it starts up ok. If I run:
podman container stop nexus
podman container start nexus
I get an error:
Error: unable to start container "nexus": container create failed (no
logs from conmon): EOF
When run with debug logging I see this in the output:
DEBU[0000] Initializing event backend journald DEBU[0000]
using runtime "/usr/lib/cri-o-runc/sbin/runc" WARN[0000] Error
initializing configured OCI runtime crun: no valid executable found
for OCI runtime crun: invalid argument
DEBU[0000] unmounted container
"419f6576ff23328c6445526058c9988aa27a4b69605348230fa26246a522c726"
ERRO[0000] unable to start container "nexus": container create failed
(no logs from conmon): EOF
The source image is:
docker.io/sonatype/nexus3
I'm not sure what the "invalid argument" in the logs means. Do I need to pass another argument?
there seems to be problem with the latest version of conmon package from Project Atomic PPA (v 2.0.3).
I had the same problem and I installed a lower version of conmon package (v 2.0.0) from,
https://launchpad.net/ubuntu/+archive/primary/+files/conmon_2.0.0-1_amd64.deb
This is a package built for Eoan. However, it worked on my Bionic environment and I am able to start my containers again.
As #Loki Arya noted, a bug in the common package was causing the issue. Since Podman for Unbuntu is no longer being hosted at projectatomic ppa, the updates after version 1.6.2 that fixed the bug were not available.
After removing the project atomic ppa and all associated packages, I reinstalled Podman for Ubuntu from its new repository location here
I've tested Podman (1.7) and it is working great, including the start command
Gitlab runner throw ERROR: Preparation failed: Getwd: getwd: no such file or directory?
gitlab version is: GitLab Community Edition 8.6.4
gitlab-runner version: 1.11.5
My CI throw ERROR: Preparation failed: Getwd: getwd frequently,
but sometimes we commit is work fine. So we didn't know what the final reason cause this problem.
We only know about one thing that is this error shows after we moved the build directory.
In my case that was because of residual gitlab-runner processes still executing. I resolved it by identifying guilty pids then killed them:
$ ps -ax | grep gitlab-runner
27034 ? Ssl 0:06 /usr/bin/gitlab-runner run --working-directory /home/gitlab-runner --config /etc/gitlab-runner/config.toml --service gitlab-runner --syslog --user gitlab-runner
$ sudo kill -9 27034
I got the same error and solved by restarting gitlab-runner
gitlab-runner restart
The Gitlab Runner checks out a copy of your repository into CI_PROJECT_DIR. You can check its value by adding the following to your .gitlab-ci.yml:
script:
- echo $CI_PROJECT_DIR
I received the "getwd: no such file or directory" error because:
I had changed my working directory to /var/www/mysite (I am using a docker container with gitlab-runner installed inside it, but I think that's beside the point)
one of my deploy script lines moves /var/www/mysite to /var/www/old-mysite.
I'm used to the Gitlab Runner checking out its build inside /home/gitlab-runner/build. When I changed the docker working directory this caused the runner to check it out at /var/www/mysite/build.
After my script moved /var/www/mysite to /var/www/old-mysite, on second and subsequent runs, gitlab runner still expected to find (/var/www/mysite) but it no longer existed, hence the error.
Given the above, I can't explain why the runner works the first time ever, when that directory also doesn't exist, but hopefully my answer might at least prompt something useful for someone! :)
On my ubuntu laptop I was issuing some kubectl commands including running kubernetes from a local Docker container all was well ... at some point I then issued this command
kubectl config set-cluster test-doc --server=https://104.196.108.118
now my local kubectl fails to execute ... looks like the Server side needs to get reset back to default
kubectl version
Client Version: version.Info{Major:"1", Minor:"2", GitVersion:"v1.2.2", GitCommit:"528f879e7d3790ea4287687ef0ab3f2a01cc2718", GitTreeState:"clean"}
error: couldn't get version/kind; json parse error: json: cannot unmarshal string into Go value of type struct { APIVersion string "json:\"apiVersion,omitempty\""; Kind string "json:\"kind,omitempty\"" }
I deleted and reinstalled the gcloud SDK binaries and ran
mv ~/.config/gcloud ~/.config/gcloud~ignore
gcloud init
gcloud components update kubectl
How do I delete my local kubectl settings (on ubuntu 16.04) and start fresh ?
It's important to note that you've set a kubeconfig setting for your client. When you run kubectl version, you're getting the version for client and the server which in your case seems to be the issue with the version command.
Updating your config
You need to update the setting to the appropriate information. You can use the same command you used to set the server to change it to the correct server.
If you want to wipe the slate clean in terms of client config, you should remove the kubeconfig file(s). In my experience with the gcloud setup, this is just ~/.kube/config.
If you are running the cluster through google cloud engine, you can use gcloud to get the kubeconfig set for you as per the container engine quick start guide. The following assumes that you have defaults for the project, zone, and cluster set.
gcloud container clusters get-credentials CLUSTER_NAME
Removing kubectl - this isn't necessary
If your goal is to wholesale get rid of kubectl, you should remove the component rather than reseting gcloud.
gcloud components remove kubectl
But that won't solve your problem as it doesn't remove or reset ~/.kube/config when I run it on Mac and if you want to keep working with it, you'll need to reinstall kubectl.
I installed the Google Cloud SDK (gcloud) on my Windows workstation several weeks back. I noticed that every time I run a command, I saw output similar to:
MySQL: command not found
... before the normal command begins. I assumed that the SDK detected that I have MySQL installed on my workstation, and was trying (in a very buggy manner) to hook into it for Cloud SQL support. It was annoying, but I didn't pay it much attention.
Today I ran a gcloud components update command, and now the SDK is altogether non-functional. Apparently Google fixed the issue with the MySQL command's PATH, as the SDK is successfully invoking mysql.exe with every execution.
It's trying to connect with the MySQL user Utilities, and prompting me for a password. Of course I have no idea what the password is supposed to be, since I didn't create this user.
I went into MySQL Workbench and set the password for this user to a known value, so that I can get past the password prompt triggered by the SDK. However, the problem now is that any gcloud command that I type simply drops me into a MySQL shell session!
What the hell? I'm not sure why Cloud SDK is so insistent on accessing my local MySQL environment anyway. We do use Cloud SQL, but I have no particular interest in using gcloud to manage it (particularly if it's buggy). I can't remove the Cloud SQL component from my local environment right now... because once again, any gcloud command simply drops me into a MySQL shell. So I suppose my next step is to wipe the SDK off my workstation altogether, and attempt to install again without Cloud SQL selected. Why is any of this necessary at all?
UPDATE:
Blowing away my Cloud SDK enviroment and re-installing did not make the problem go away. However, removing mysql.exe from my system PATH did. Apparently, the current version of Cloud SDK simply breaks right now (at least on Windows) when it detects MySQL in your path. I wonder how this made it past QA?
The output from gcloud info is below (email address and current project ID redacted):
> gcloud info
Google Cloud SDK [0.9.67]
Platform: [Windows, x86_64]
Python Version: [2.7.6 (default, Nov 10 2013, 19:24:24) [MSC v.1500 64 bit (AMD64)]]
Site Packages: [Disabled]
Installation Root: [C:\Program Files\Google\Cloud SDK\google-cloud-sdk]
Installed Components:
core: [2015.06.30]
bq-win: [2.0.18]
core-win: [2015.06.02]
gcloud: [2015.06.30]
windows-ssh-tools: [2015.06.02]
gcutil-msg: [2015.06.09]
gsutil: [4.13]
bq: [2.0.18]
preview: [2015.06.30]
gsutil-win: [4.12]
System PATH: [C:\Program Files\Google\Cloud SDK\google-cloud-sdk\bin\..\bin\sdk;C:\Program Files\ConEmu;C:\Program Files\ConEmu\ConEmu;C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\Extensions\Microsoft\Windows Azure Tools\Docker\;C:\ProgramData\Oracle\Java\javapath;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Users\Steve\.dnx\bin;C:\Program Files\Microsoft DNX\Dnvm\;C:\Program Files (x86)\nodejs\;C:\Program Files (x86)\GtkSharp\2.12\bin;C:\HashiCorp\Vagrant\bin;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\;C:\Program Files\Microsoft SQL Server\120\Tools\Binn\;C:\Program Files (x86)\Git\cmd;C:\Program Files\Google\Cloud SDK\google-cloud-sdk\bin;C:\PROGRA~2\Groovy\GROOVY~1.3\bin;C:\Users\Steve\.dnx\runtimes\dnx-coreclr-win-x86.1.0.0-beta5\bin;C:\Users\Steve\.dnx\bin;C:\Dev\gradle-2.4\bin;C:\Users\Steve\AppData\Roaming\npm;C:\Users\Steve\AppData\Local\Code\bin;C:\Program Files\Boot2Docker for Windows]
Cloud SDK on PATH: [True]
Installation Properties: [C:\Program Files\Google\Cloud SDK\google-cloud-sdk\properties]
User Config Directory: [C:\Users\Steve\AppData\Roaming\gcloud]
User Properties: [C:\Users\Steve\AppData\Roaming\gcloud\properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]
Account: [...]
Project: [...]
Current Properties:
[core]
project: [...]
account: [...]
disable_usage_reporting: [False]
Logs Directory: [C:\Users\Steve\AppData\Roaming\gcloud\logs]
Last Log File: [C:\Users\Steve\AppData\Roaming\gcloud\logs\2015.07.06\11.43.23.734000.log]
I can't comment so will post as an answer.
You probably have some environmental variable set up in a way that confuses gcloud. Can you also post the output of set cloudsdk from the command line? That should print all the environmental variables with the prefix "cloudsdk". You can redirect it to a file so it's easier to copy: set cloudsdk > environment_cloudsdk.txt.
Not sure how this can happen. If the CLOUDSDK_ env vars are empty, and gcloud.cmd is correct, gcloud shouldn't touch mysql at all. "c:\Program Files\Google\Cloud SDK\google-cloud-sdk\bin\gcloud.cmd" lists at the top what each env var does. Make sure they are not set. Also when you reinstall Cloud SDK, make sure the directory "c:\Program Files\Google\Cloud SDK\" is properly deleted and that there's nothing in the PATH var about it.