I have an old script that do
$(cat /sys/fs/cgroup/memory/memory.limit_in_bytes)
In fedora 33 this file is not present.
What can I do to resolve this?
Thanks.
The issue is related to new cgroup v2.
To resolve this, revert cgroup to v1:
sudo sed -i '/^GRUB_CMDLINE_LINUX/ s/"$/ systemd.unified_cgroup_hierarchy=0"/' /etc/default/grub
and reboot.
After this /sys/fs/cgroup/memory/memory.limit_in_bytes will be present.
Before rebooting, it's necessary to redo the command to regenerate grub.
For Fedora 33, the commands are:
BIOS
grub2-mkconfig -o /boot/grub2/grub.cfg
UEFI
grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
Related
I use a shutdown-script to backup the files on an instance before it is shutdown.
In this shutdown-script, the gsutil tool is used to send files to a bucket at google cloud storage.
/snap/bin/gsutil -m rsync -d -r /home/ganjin/notebook gs://ganjin-computing/XXXXXXXXXXX/TEST-202104/notebook
It worked well for long days. But recently, there occurs some error as below.
If I run the code manually, it works well. It seems that there is something wrong with jobs management of systemd.
Could anyone give me some hint?
INFO shutdown-script: /snap/bin/gsutil -m rsync -d -r /home/ganjin/notebook gs://ganjin-computing/XXXXXXXXXXX/TEST-202104/notebook
Apr 25 03:00:41 instance-XXXXXXXXXXX systemd[1]: Requested transaction contradicts existing jobs: Transaction for snap.google-cloud-sdk.gsutil.d027e14e-3905-4c96-9e42-c1f5ee9c6b1d.scope/start is destructive (poweroff.target has 'start' job queued, but 'stop' is included in transaction).
Apr 25 03:00:41 instance-XXXXXXXXXXX shutdown-script: INFO shutdown-script: internal error, please report: running "google-cloud-sdk.gsutil" failed: cannot create transient scope: DBus error "org.freedesktop.systemd1.TransactionIsDestructive": [Transaction for snap.google-cloud-sdk.gsutil.d027e14e-3905-4c96-9e42-c1f5ee9c6b1d.scope/start is destructive (poweroff.target has 'start' job queued, but 'stop' is included in transaction).]
Update gsutil with -f option.
update gsutil -f
If the above command doesn’t work then try the command below:
sudo apt-get update && sudo apt-get --only-upgrade install google-cloud-sdk
Update guest environment and try to shutdown the instance. Use the link below as a reference to update the guest environment.
https://cloud.google.com/compute/docs/images/install-guest-environment#update-guest
If still facing issues do forceful shutdown:
sudo poweroff -f
setup: i3wm, fedora 31
I am facing this issue, in which some rpm's even after being installed,
For e.g. I have Bluejeans installed, but when I try running the app, it results in command not found, the baffling part being I have no such issue opening it in gnome.
$ rpm -qa | grep -i bluejeans
bluejeans-v2-2.0.0-188.x86_64
$ bluejeans
zsh: bluejeans: command not found...
same goes when I try accessing using dmenu.
solved the issue, bluejeans was not getting installed in /usr/bin or any other similar paths.
rpm -ql bluejeans
package bluejeans is not installed
while they also named package as bluejeans-v2 which made it harder to search, while in gnome I could start using bluejeans even from the terminal.
solution:
create a symlink to /usr/bin where you have bluejean-v2 installed
ls -s /usr/bin/bluejean-v2 ${install_path}/bluejeans-v2
I've recently started using Google's Compute engine for some of my projects the problem is my startup script doesn't seem to work, For some reason my script just doesn't work, the VM has the startup-script metadata and it works fine when I run it manually with:
sudo google_metadata_script_runner --script-type startup
Here is what I am trying to run on startup:
#!/bin/bash
sudo apt-get update
sudo rm -f Eve.jar
sudo rm -f GameServerStatus.jar
wget <URL>/Eve.jar
wget <URL>/GameServerStatus.jar
sudo chmod 7777 Eve.jar
sudo chmod 7777 GameServerStatus.jar
screen -dmS Eve sh Eve.sh
screen -dmS PWISS sh GameServerStatus.sh
There are no errors in the log either, it just seems to stop at the chmod or screen commands, Any ideas?
Thanks!
To add to kangbu's answer:
Checking the logs in container-optimized OS by
sudo journalctl -u google-startup-scripts.service
showed that the script could not find the user. After a long time of debugging I finally added a delay before the sudo and now it works. Seems the user is not registered when the script runs.
#! /bin/bash
sleep 10 # wait...
cut -d: -f1 /etc/passwd > /home/user/users.txt # make sure the user exists
cd /home/user/project # cd does not work after sudo, do it before
sudo -u user bash -c '\
source /home/user/.bashrc && \
<your-task> && \
date > /home/user/startup.log'
I have the same problem #Brina mentioned. I set up metadata key startup-script and value like:
touch a
ls -al > test.txt
When I ran the script above sudo google_metadata_script_runner --script-type startup, it worked perfectly, However if I reset my VM instance the startup script didn't work. So, I checked startup script logs
...
Jul 3 04:30:37 kbot-6 ntpd[1514]: Listen normally on 5 eth0 fe80::4001:aff:fe8c:7 UDP 123
Jul 3 04:30:37 kbot-6 ntpd[1514]: peers refreshed
Jul 3 04:30:37 kbot-6 ntpd[1514]: Listening on routing socket on fd #22 for interface updates
Jul 3 04:30:38 kbot-6 startup-script: INFO Starting startup scripts.
Jul 3 04:30:38 kbot-6 startup-script: INFO Found startup-script in metadata.
Jul 3 04:30:38 kbot-6 startup-script: INFO startup-script: Return code 0.
Jul 3 04:30:38 kbot-6 startup-script: INFO Finished running startup scripts.
Yes. they found startup-script and ran it. I guessed it had executed as an another user. I changed my script like this:
pwd > /tmp/pwd.txt
whoami > /tmp/whoami.txt
The result is:
myuserid#kbot-6:/tmp$ cat pwd.txt whoami.txt
/
root
Yes. It was executed at the / diectory as root user. Finally, I changed my script to sudo -u myuserid bash -c ... which run it by specified userid.
Go to the VM instances page.
Click on the instance for which you want to add a startup script.
Click the Edit button at the top of the page.
Under Custom metadata, click Add item.
Add your startup script using one of the following keys:
startup-script: Supply the startup script contents directly with this key.
startup-script-URL: Supply a Google Cloud Storage URL to the start script file with this key.
It is working. The documentation for the new instance and existing instance as shown in GCE Start Up Script
Startup script output is written to the following log files:
CentOS and RHEL: /var/log/messages
Debian: /var/log/daemon.log
Ubuntu 14.04, 16.04, and 16.10: /var/log/syslog
On Ubuntu 12.04, SLES 11 and 12, and all images older than v20160606:
sudo /usr/share/google/run-startup-scripts
think that you do not need sudo, as well as the chmod 7777 should be 777
also a cd (or at least a pwd) at the beginning might be useful.
... log to text file, in order to know where the script may fail.
I am trying to use sudo apt-get update But i am getting error as,
W: Failed to fetch http://dl.google.com/linux/chrome/deb/dists/stable/Release Unable to find expected entry 'main/binary-i386/Packages' in Release file (Wrong sources.list entry or malformed file)
E: Some index files failed to download. They have been ignored, or old ones used instead.
I tired the solution given in https://askubuntu.com/questions/120621/how-to-fix-duplicate-sources-list-entry, but again showing the same error. Suggest me something.
It looks like Google has discontinued support for i386, which is why this error now shows up. It looks like they have not gracefully for how their deb install has configured apt. To fix this run the following.
sudo sed -i -e 's/deb http/deb [arch=amd64] http/' "/etc/apt/sources.list.d/google-chrome.list"
Source: https://www.reddit.com/r/chrome/comments/48oje6/linux_how_to_fix_failed_to_fetch/
Edit: As has been pointed out by others, another command is needed to prevent this fix from reverting. Since this is at the top as the accepted answer I feel it should be part of this answer.
sudo sed -i -e 's/deb http/deb [arch=amd64] http/' "/opt/google/chrome/cron/google-chrome"
Also, this issue may exist if there are two files with name google.list and google-chrome.list in /etc/apt/sources.list.d directory with the similar entry like:
In google.list:
deb http://dl.google.com/linux/chrome/deb/ stable main
In google-chrome.list:
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
Then you should remove google.list file or uncomment its entry like below:
#deb http://dl.google.com/linux/chrome/deb/ stable main
That change was reverting overnight for me. Apparently you also need to change /opt/google/chrome/cron/google-chrome
sudo sed -i -e 's/deb http/deb [arch=amd64] http/' "/opt/google/chrome/cron/google-chrome"
Note: this is only for 64-bit
Source: further down that same Reddit thread and http://www.webupd8.org/2016/03/fix-failed-to-fetch-google-chrome_3.html
This doesn't work because there is a default config in /etc/default/google-chrome that contains instructions on repository updating. If you open the google-chrome.list file in /etc/apt/sources.list.d/ you will see that it has the comment:
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# You may comment out this entry, but any other modifications may be lost.
Like the note says, the changes using the instructions in the previous comments will probably be overwritten the next time you update. To resolve this, do the following:
Open a terminal and run cd /etc/default , then sudo nano google-chrome (Note: you can use whatever editor you wish of course))
In the config file, change the 2nd line: repo_reenable_on_distupgrade="true" so that it is false, as in
repo_reenable_on_distupgrade="false", then save the config file.
Now, you can make the edit to the repo as instructed above. In a terminal window run the commands as shown in the previous comments:
sudo sed -i -e 's/deb http/deb [arch=amd64] http/' "/etc/apt/sources.list.d/google-chrome.list"
sudo sed -i -e 's/deb http/deb [arch=amd64] http/' "/opt/google/chrome/cron/google-chrome"
You changes now won't be overwritten by the config directive.
PS. This works in Linux Mint 17.3 so it will probably work in Ubuntu and any Ubuntu based distro as well.
Go to "Software Sources" section in Ubuntu Settings then click on "other software" tab then uncheck: http://dl.google.com/linux/chrome/deb/stable
Now sudo apt-get update will work.
After updating manager go and undo the changes in software sources.
I solved this problem by following process:
1.Open a new Terminal window and run the following command:
sudo gedit /etc/apt/sources.list.d/google-chrome.list
2.In the text file that opens edit the file so that the line reads:
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
N.B: The only addition you need to make is entering the [amd64] architecture after ‘deb’ but preceding the ‘http’. Do not edit or replace any other text in this file.
3.Hit Save. Close the Gedit window and return to the Terminal and refresh your package list by runnin
sudo apt-get update
The ‘failed to fetch’ APT error should no longer appear.
source link
This didn't work for me, until I modified yet another file:
/etc/apt/sources.list.d/additional-repositories.list
and changed:
deb http://dl.google.com/linux/chrome/deb/ stable main
to
deb [arch=amd64] http://dl.google.com/linux/chrome/deb/ stable main
I made the attempt at enabling EPEL on my Fedora 22 machine by running
wget http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm
Then
sudo rpm -ivh epel-release-7-5.noarch.rpm
And now when I run
dnf repolist
I get the following
[sinux1#horrible-host ~]$ sudo dnf repolist
Extra Packages for Enterprise Linux 7 - x86_64 1.8 MB/s | 9.0 MB 00:05
Failed to open: /var/cache/dnf/epel-2b6dfc5904c26562/repodata/49c4e3bd54f19136521be9b254830c954369cc22ce1b661db502ebef13b0004c-updateinfo.xml.bz2.
[sinux1#horrible-host ~]$
I'm stuck and not sure what my next step is. How can I reverse what I did, and what would have been the proper way of enabling EPEL?
Thanks for any input
This is what appears to have worked for me.
Remove the epel repo
rm -rf /etc/yum.repos.d/epel*
then try install epel via dnf
dnf clean all
dnf install epel-release
I did the same as Sinux Tine and ended up in some sort of deadlock.
First try to do like Rup says.
If everything fails, try the following as a last resort. It worked for me.
> su
> cd /var/cache/dnf/epel-2b6dfc5904c26562/repodata
> mkdir throwaway
> mv 49c4e3bd54f19136521be9b254830c954369cc22ce1b661db502ebef13b0004c-updateinfo.xml.bz2 throwaway
That effectively deletes the file which dnf says it cannot open.
When and if the problem is solved, you can delete the throwaway directory and its contents.
Current libsolv version does not have bz2 compression.
Solution: enable bunzip2 compression in libsolv, Basically 'yum update libsolv', then reinstall epel-release.
To complement the answer for Centos 7, I followed the next steps:
Download the libsolv-0.6.14-1.el7 wich was patched
Install it
sudo rpm -ivh libsolv-0.6.14-1.el7.centos.x86_64.rpm
If we get a conflict with the previous version
warning: libsolv-0.6.14-1.el7.centos.x86_64.rpm: Header V3 RSA/SHA1 Signature, key ID 1b6f9f55: NOKEY
Preparing... ################################# [100%]
file /usr/lib64/libsolv.so.0 from install of libsolv-0.6.14-1.el7.centos.x86_64 conflicts with file from package libsolv-0.6.11-1.el7.x86_64
file /usr/lib64/libsolvext.so.0 from install of libsolv-0.6.14-1.el7.centos.x86_64 conflicts with file from package libsolv-0.6.11-1.el7.x86_64
We proceed to remove the previous version
sudo yum erase libsolv-0.6.11-1.el7.x86_64
and install the patched libsolv package
sudo rpm -ivh libsolv-0.6.14-1.el7.centos.x86_64.rpm
We need to reinstall the dnf package manager, because it was removed after to remove the libsolv so we install with the following command.
sudo yum install dnf
We validate it using sudo dnf repolist now it, give us the right output.
Using metadata from Mon Jun 13 10:53:11 2016
repo id repo name status
base CentOS-7 - Base 9,007