I'm trying to modify the devicetree on my Coral SoM to support a different DSI display, and could use some pointers.
I edited arch/arm64/boot/dts/freescale/fsl-imx8mq-phanbell.dts
then used 'm' to make all
Question:
What is the correct way to modify the devicetree, build and load it to the board!?
Thanks!
can you give a little more details on the changes?
You can definitely do it that way, and I believe you don't need to rebuilt the entire OS, just the kernel is fine:
$ m docker-linux-imx
$ cd ./out/product/packages/bsp
$ scp ./linux-image-4.14.98-imx_11–4_arm64.deb mendel#board-ip
$ ssh mendel#board-ip
$ sudo dpkg -i ./linux-image-4.14.98-imx_11–4_arm64.deb
Another way is to create a device tree overlays. For instance here is a dts for disabling the hdmi: https://gist.github.com/Namburger/f700eb6b18bd1e3697638088d5995c8b
You can then compile it and move it to /boot:
$ dtc -# -I dts -O dtb -o disable-hdmi.dtbo disable_hdmi.dts
$ sudo mv disable-hdmi.dtbo /boot
Then add the file to /boot/overlays.txt to apply it:
$ cat /boot/overlays.txt
# List of device tree overlays to load. Format: overlay=<dtbo name, no extenstion> <dtbo2> ...
overlay= disable-hdmi
Thank you very much Nam.
The first option I think was already working, but I was not sure how to check. It appears that the devicetree can be examined by looking in /proc/device-tree/ for example cat hdmi#32c00000/status gives 'disabled' after doing the modification above, and the HDMI can be verified not working.
I want to run a Bash script prior to either shutdown or reboot of my Pi (running the latest Raspbian, a derivative of Debian).
e.g. if I type in sudo shutdown now or sudo reboot now into the command prompt, it should run my Bash script before continuing with shutdown/reboot.
I created a very simple script just for testing, to ensure I get the method working before I bother writing the actual script:
#!/bin/bash
touch /home/pi/ShutdownFileTest.txt
I then copied the file (called CreateFile.sh) to /etc/init.d/CreateFile
I then created symlinks in /etc/rc0.d/ and /etc/rc6.d/:
sudo ln -s /etc/init.d/CreateFile K99Dave
I'm not certain on what the proper naming should be for the symlink. Some websites say "Start the filename with a K", some say "start with an S", one said: "start with K99 so it runs at the right time"...
I actually ended up trying all of the following (not all at once, of course, but one at a time):
sudo ln -s /etc/init.d/CreateFile S00Dave
sudo ln -s /etc/init.d/CreateFile S99Dave
sudo ln -s /etc/init.d/CreateFile K00Dave
sudo ln -s /etc/init.d/CreateFile K01rpa
sudo ln -s /etc/init.d/CreateFile K99Dave
After creating each symlink, I always ran:
sudo chmod a+x /etc/init.d/CreateFile && sudo chmod a+x /etc/rc6.d/<name of symlink>
I then rebooted each time.
Each time, the file at /home/pi/ShutdownFileTest.txt was not created; the script is not executed.
I found this comment on an older post, suggesting that the above was the outdated method:
The modern way to do this is via systemd. See "man systemd-shutdown"
for details. Basically, put an executable shell script in
/lib/systemd/system-shutdown/. It gets passed an argument like "halt"
or "reboot" that allows you to distinguish the various cases if you
need to.
I copied my script into /lib/systemd/system-shutdown/, chmod +x'd it, and rebooted, but still no success.
I note the above comment says that the script is passed "halt" or "reboot" as an argument. As it should run identically in both cases, I assume it shouldn't need to actually deal with that argument. I don't know how to deal with that argument, either, so I'm not sure if I need to do something to make that work or not...
Could someone please tell me where I'm going wrong?
Thanks in advance,
Dave
As it turns out, part of the shutdown command has already executed (and unmounted the filesystem) before these scripts are executed.
Therefore, mounting the filesystem at the start of the script and unmounting it at the end is necessary.
Simply add:
mount -oremount,rw /
...at the start of the script (beneath the #!/bin/bash)
...then have the script's code...
and then finish the script with:
mount -oremount,ro /
So, the OP script should become:
#!/bin/bash
mount -oremount,rw /
touch /home/pi/ShutdownFileTest.txt
mount -oremount,ro /
...that then creates the file /home/pi/ShutdownFileTest.txt just before shutdown/reboot.
That said, it may not be best practice to use this method. Instead, it is better to create a service that runs whenever the computer is on and running normally, but runs the desired script when the service is terminated (which happens at shutdown/reboot).
This is explained in detail here, but essentially:
1: Create a file (let's call it example.service).
2: Add the following into example.service:
[Unit]
Description=This service calls shutdownScript.sh upon shutdown or reboot.
[Service]
Type=oneshot
RemainAfterExit=true
ExecStop=/home/pi/shutdownScript.sh
[Install]
WantedBy=multi-user.target
3: Move it into the correct directory for systemd by running sudo mv /home/pi/example.service /etc/systemd/system/example.service
4: Ensure the script to launch upon shutdown has appropriate permissions: chmod u+x /home/pi/shutdownScript.sh
5: Start the service: sudo systemctl start example --now
6: Make the service automatically start upon boot: sudo systemctl enable example
7: Stop the service: sudo systemctl stop example
This last command will mimic what would happen normally when the system shuts down, i.e. it will run /home/pi/shutdownScript.sh (without actually shutting down the system).
You can then reboot twice and it should work from the second reboot onwards.
EDIT: nope, no it doesn't. It worked the first time I tested it, but stopped working after that. Not sure why. If I figure out how to get it working, I'll edit this answer and remove this message (or if someone else knows, please feel free to edit the answer for me).
As I a do not have enough senority to post comments this is a new answer for which I appologize.
I added a step to ZPMMaker's answer and it seems to work for me at least.
sudo chmod u+x /etc/systemd/system/example.service
I went through fair amount of google search to install ack-grep on CentOS but I didn't find anything help. I also looked for the source codes but couldn't find it neither. Does anyone know how to install it on the OS?
Thanks a lot.
Could be essentially the same as https://stackoverflow.com/a/23155007/35946 but on CentOS 6.7 the answer is:
# yum install epel-release
# yum install ack
if you don't have the root permission, you can do as follows:
$ curl https://beyondgrep.com/ack-2.22-single-file > ~/bin/ack && chmod 0755 !#:3
or you can change to root user:
$ sudo su
# curl https://beyondgrep.com/ack-2.22-single-file > /bin/ack && chmod 0755 !#:3
You can get it from the EPEL software repository.
From the EPEL FAQ:
For EL5:
su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/5/i386/epel-release-5-4.noarch.rpm'
...
su -c 'yum install ack'
For EL6:
su -c 'rpm -Uvh http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm'
...
su -c 'yum install ack'
Go to Beyond Grep and look at the section titled
Install The ack executeable
curl http://beyondgrep.com/ack-2.14-single-file > ~/bin/ack && chmod 0755 !#:3
And replace ack.2.14 with the current version of ack.
You may need to create the directory mkdir ~/bin/ first. You may
also need to modify ~/.bashrc to include this new path E.G.:
PATH=$PATH:$HOME/bin
Then reload ~/.bashrc
source ~/.bashrc
Test the installation by running ack:
rpm -qa | ack s
This should display any installed packages containing the letter s. (some linux distributions may use ack-grep as the command.
How did you try installing it? Are you using yum? The package is probably not called "ack-grep", but just "ack".
The name "ack-grep" is a Debian-specific thing because there was already a package called "ack", so they called it "ack-grep" instead. That was years ago and now they're dropping the original "ack" package and renaming "ack-grep" to "ack".
For RedHat Enterprise just do sudo yum install ack
I have created user for my AWS ec2 VPS (deployer)
When i am logging with:
ssh -i ~/.ssh/aws/*...*.pem ubuntu#ec2*...*.amazonaws.com
command rvm use 2.0.0 is working correctly
=>
ubuntu#ip-***:~$ rvm list
rvm rubies
=* ruby-2.0.0-p247 [ x86_64 ]
# => - current
# =* - current && default
# * - default
ubuntu#ip-***:~$ rvm which
ubuntu#ip-***:~$
But when i use su - deployer i have got:
deployer#ip***:/home/ubuntu$ rvm
The program 'rvm' is currently not installed. You can install it by typing:
sudo apt-get install ruby-rvm
I would like to understand how correctly write command for ssh login.
I have tried:
ssh -i ~/.ssh/aws/*.pem *ubuntu#ec2***.amazonaws.com -t 'bash --login -c "rvm"'
but received "Connection to ec2-*.amazonaws.com closed".
Within my local machine rvm functioning correctly. I have added
[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm" # Load RVM into a shell session *as a function*
into my ~/.bash_profile
I have spent 3-5 hours studying stackoverflow topics related to this issue, but still not understand what am i doing wrong.
Any help will be highly appreciated! Thanks in advance!
I've run into this problem before and there are 2 ways to solve it.
The first way is to log in directly as the deployer user to the instance. This might mean having to create a ssh keypair (see ssh-keygen -t rsa). Then you can log in with ssh deployer#ec2.instance.address This way the rvm will be loaded directly to the deployed user's shell.
A second way is not to use the dash when su to the deployed user account.
When you use the dash then you load your own bashrc vs that particular user's bashrc.
So sudo su deployer
you nee to use:
su - deployer
it will ensure you use login shell
I am trying to dump a Postgresql database using the pg_dump tool.
$ pg_dump books > books.out
How ever i am getting this error.
pg_dump: server version: 9.2.1; pg_dump version: 9.1.6
pg_dump: aborting because of server version mismatch
The --ignore-version option is now deprecated and really would not be a a solution to my issue even if it had worked.
How can I upgrade pg_dump to resolve this issue?
Check the installed version(s) of pg_dump:
find / -name pg_dump -type f 2>/dev/null
My output was:
/usr/pgsql-9.3/bin/pg_dump
/usr/bin/pg_dump
There are two versions installed. To update pg_dump with the newer version:
sudo ln -s /usr/pgsql-9.3/bin/pg_dump /usr/bin/pg_dump --force
This will create the symlink to the newer version.
I encountered this while using Heroku on Ubuntu, and here's how I fixed it:
Add the PostgreSQL apt repository as described at "Linux downloads (Ubuntu)
". (There are similar pages for other operating systems.)
Upgrade to the latest version (9.3 for me) with:
sudo apt-get install postgresql
Recreate the symbolic link in /usr/bin with:
sudo ln -s /usr/lib/postgresql/9.3/bin/pg_dump /usr/bin/pg_dump --force
The version number in the /usr/lib/postgresql/... path above should match the server version number in the error you received. So if your error says, pg_dump: server version: 9.9, then link to /usr/lib/postgresql/9.9/....
Macs have a builtin /usr/bin/pg_dump command that is used as default.
With the postgresql install you get another binary at /Library/PostgreSQL/<version>/bin/pg_dump
You can just locate pg_dump and use the full path in command
locate pg_dump
/usr/bin/pg_dump
/usr/bin/pg_dumpall
/usr/lib/postgresql/9.3/bin/pg_dump
/usr/lib/postgresql/9.3/bin/pg_dumpall
/usr/lib/postgresql/9.6/bin/pg_dump
/usr/lib/postgresql/9.6/bin/pg_dumpall
Now just use the path of the desired version in the command
/usr/lib/postgresql/9.6/bin/pg_dump books > books.out
You can either install PostgreSQL 9.2.1 in the pg_dump client machine or just copy the $PGHOME from the PostgreSQL server machine to the client machine. Note that there is no need to initdb a new cluster in the client machine.
After you have finished installing the 9.2.1 software, remember to edit some environment variables in your .bash_profile file.
If you're on Ubuntu, you might have an old version of postgresql-client installed. Based on the versions in your error message, the solution would be the following:
sudo apt-get remove postgresql-client-9.1
sudo apt-get install postgresql-client-9.2
If you have docker installed you can do something like:
$ docker run postgres:9.2 pg_dump books > books.out
That will download the Docker container with Postgres 9.2 in it, run pg_dump inside of the container, and write the output.
On Ubuntu you can simply add the most recent Apt repository and then run:
sudo apt-get install postgresql-client-11
Every time you upgrade or re install a new version of PostgreSQL, a latest version of pg_dump is installed.
There must be a PostgreSQL/bin directory somewhere on your system, under the latest version of PostgreSQL that you've installed ( 9.2.1 is latest) and try running the
pg_dump from in there.
For those running Postgres.app:
Add the following code to your .bash_profile:
export PATH=/Applications/Postgres.app/Contents/Versions/latest/bin:$PATH
Restart terminal.
For Macs with Homebrew. I had this problem when fetching the db from Heroku. I've fixed it just running:
brew upgrade postgresql
For mac users
put to the top of .profile file.
export PATH="/Applications/Postgres.app/Contents/MacOS/bin:$PATH"
then run
. ~/.profile
An alternative answer that I don't think anyone else has covered.
If you have multiple PG clusters installed (as I do), then you can view those using pg_lsclusters.
You should be able to see the version and cluster from the list displayed.
From there, you can then do this:
pg_dump --cluster=9.6/main books > books.out
Obviously, replace the version and cluster name with the appropriate one for your circumstances from what is returned by pg_lsclusters separating the version and cluster with a /. This targets the specific cluster you wish to run against.
For me the issue was updating psql apt-get wasn't resolving newer versions, even after update. The following worked.
Ubuntu
Start with the import of the GPG key for PostgreSQL packages.
sudo apt-get install wget ca-certificates
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
Now add the repository to your system.
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'
Install PostgreSQL on Ubuntu
sudo apt-get update
sudo apt-get install postgresql postgresql-contrib
https://www.postgresql.org/download/linux/ubuntu/
As explained, this is because your postgresql is in old version -> update it
For Mac via homebrew:
brew tap petere/postgresql,
brew install <formula> (eg: brew install petere/postgresql/postgresql-9.6)
Remove old postgre:
brew unlink postgresql
brew link -f postgresql-9.6
If any error happen, don't forget to read and follow brew instruction in each step.
Check this out for more: https://github.com/petere/homebrew-postgresql
The answer sounds silly but if you get the above error and wanna run the pg_dump for earlier version go to bin directory of postgres and type
./pg_dump servername > out.sql ./ ignores the root and looks for pg_dump in current directory
I had same error and this is how I solved it in my case.
This means your postgresql version is 9.2.1 but you have started postgresql service of 9.1.6.
If you run psql postgres you will see:
psql (9.2.1, server 9.1.6)
What I did to solve this problem is:
brew services stop postgresql#9.1.6
brew services restart postgresql#9.2.1
Now run psql postgres and you should have: psql (9.2.1)
You can also run brew services list to see the status of your postgres.
This worked for me, a collection of solutions from above and other sites. If you specified a version like postgressql-client-11 before then you need to remove that version first.
sudo apt-get remove -y postgresql-client
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
sudo apt-get update
sudo apt-get install -y postgresql-client-12
I was facing the same issue. I used docker instead of upgrading pg_dump.
run following command to create a Docker container of postgres 14.2, or any other version as you like.
sudo docker run --name mac_postgres -p 5444:5432 -e POSTGRES_PASSWORD=password -d postgres:14.2
Then take dump using following command. Note: you should change the host, port, username and password according to your actual database credentials.
sudo docker exec -it mac_postgres pg_dump --host=xxxxx0.b.db.ondigitalocean.com --port=250xx --username=doadmin --dbname=test --password > out.sql
After entering password. Your dump will be ready in out.sql file. Then you can delete the docker-container.
sudo docker stop mac_postgres
sudo docker rm mac_postgres
If you're using Heroku's Postgres.app the pg_dump (along with all the other binaries) is in /Applications/Postgres.app/Contents/MacOS/bin/
so in that case it's
ln -s /Applications/Postgres.app/Contents/MacOS/bin/pg_dump /usr/local/bin/pg_dump
or
ln -s /Applications/Postgres.app/Contents/MacOS/bin/* /usr/local/bin/.
to just grab them all
** after install postgres version is match(9.2)
Create a symbolic link or new shortcut
**- on '/usr/bin'
syntag is = sudo ln -s [path for use] [new shortcut name]
example
sudo ln -s /usr/lib/postgresql/9.2/bin/pg_dump new_pg_dump
-- how to call : new_pg_dump -h 192.168.9.88 -U postgres database
Try that:
export PATH=/usr/local/bin:$PATH
If the database is installed on a different machine it has probably correct version of pg_dump installed. This means that you can execute pg_dump command remotely with SSH:
ssh username#dbserver pg_dump books > books.out
You can also use public key authentication for passwordless execution. Steps to achieve that:
Generate (if not yet done) a pair of keys with ssh-keygen command.
Copy the public key to the database server, usually ~/.ssh/authorized_keys.
Test if the connection works with ssh command.
Well, I had the same issue as I have two postgress versions installed.
Just use the proper pg_dump and you don't need to change anything, in your case:
$> /usr/lib/postgresql/9.2/bin/pg_dump books > books.out
For macs, use find / -name pg_dump -type f 2>/dev/null find the location of pg_dump
For me, I have following results:
Applications/Postgres.app/Contents/Versions/9.5/bin/pg_dump
/usr/local/Cellar/postgresql/9.4.5_2/bin/pg_dump
If you don't want to use sudo ln -s new_pg_dump old_pg_dump --force, just use:
Applications/Postgres.app/Contents/Versions/9.5/bin/pg_dump to replace with pg_dump in your terminal
For example:
Applications/Postgres.app/Contents/Versions/9.5/bin/pg_dump books > books.out
It works for me!
On my scenario the production version was 12, and my development version was 11, upgrading the package postgresql-client-xx was enough to solve my incident.
Reference web page : https://www.postgresql.org/download/linux/ubuntu/
sudo apt-get update && sudo apt-get -y upgrade postgresql-client
One interest thing to point out is that after the upgrade the previous version kept installed :
mlazo#mlazo-pc:~$ dpkg -l |grep -i postgresql-client
ii postgresql-client-11 11.8-1.pgdg18.04+1 amd64 front-end programs for PostgreSQL 11
ii postgresql-client-12 12.4-1.pgdg18.04+1 amd64 front-end programs for PostgreSQL 12
Hope my experience would be helpful to someone.
Greetings,
I had the same message, for me it was that I had to adjust the following:
export LD_LIBRARY_PATH=/usr/pgsql-12/lib:....
export LD_RUN_PATH=/usr/pgsql-12/lib:.....
First step: see if postgres has a repository with prebuilt binaries for the version you want for your OS: https://www.postgresql.org/download/
If that doesn't work (for instance if your distro is there but is no longer supported, so correct binaries aren't provided for it), or if you just want to go straight or the source and not have to worry about adding remote repo's, etc.
What I did is download the raw source of postgres for the desired version.
Untar it, cd into it, build it ./configure && make, then:
postgresql-12.3 $ find . -name pg_dump
./src/bin/pg_dump/pg_dump
$ ./src/bin/pg_dump/pg_dump
unable to load libpg.so.5 # if it says this...
$ find . -name libpg.so.5
$ export LD_LIBRARY_PATH=/your/path/to/the/shared/dir/of/above/file
$ ./src/bin/pg_dump/pg_dump # works now
Now you have access to any version that builds on your box. Which should be any.
Full steps tutorial
Your local version needs to match the one used by AWS on the remote server.
Unfortunately, apt-get install will lag behind the official release.
So you need to proceed the following way:
sudo apt-get remove postgresql
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/pgdg.list'
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
Then check your error message should be something like
pg_dump: server version: 12.3; pg_dump version: 10.16 (Ubuntu 10.16-0ubuntu0.18.04.1)
So it means you want version 12 (and not 13), for the install of the matching version by specifying the version number (without minor) during your fresh install:
sudo apt-get -y install postgresql-12
Now it works:
pg_dump -h {{endpoint}} -U {{username}} -f dump.sql {{tablename}}
NB: You get the endpoint in Connectivity & security go to https://us-east-2.console.aws.amazon.com/rds/home?region=us-east-2 and click on your DB instance
For Ubuntu 20.04 with the "official" postgresql repo, moving from pg12 to pg13, I had to do this:
sudo apt purge postgresql-12
This was very hard for me to pinpoint. I had played with a variety of these packages:
postgresql-client
postgresql-client-common
postgresql-##
postgresql-client-##
postgresql-server-dev-##
pgadmin