After updating OSx Big Mister Can't start mini kube - minikube

It works fine before the update.
After updating Big Boss I can't start mini-kube.
minikube minikube start --kubernetes-version=v1.19.2
Exiting due to K8S_INSTALL_FAILED: updating control plane: copy: copy: sudo test -d /var/tmp/minikube && sudo scp -t /var/tmp/minikube: Process exited with status 1
output: �scp: /var/tmp/minikube/kubeadm.yaml.new: Read-only file system
scp: protocol error: expected control record
Maybe I need to add some settings? 🙂

Big Sur is a bit unstable. I use a MBA 2015 and couldn't upgrade to Big Sur. I am using Catalina right now. Because of 128GB space that I have is not enough to free up 42GB of free space.
But at least I decided to stay in Catalina is better because there are lots of comments about bugs and problems in Big Sur. And if I would upgrade, my computer may be slower because it is 5 years old.
Install it if there is a snapshot version or a newer version compatible with Big Sur. If there isn't, I'm afraid you have to wait for a BigBoss compatible version.

Related

Red Hat needs-restarting

I have some problems trying to test "needs-restarting -r ; echo $?" inside a RedHat distribution. The command works for cases where a reboot is not required, but I have not been able to voluntarily generate the need to reboot in the operating system, which has made it impossible for me to know if the response to the command works. That is to say the output in 1 of the needs-restarting. Do you know of any way to generate the need to reboot in a controlled manner in RedHat?
You can find which packages require a system reboot after the update to Redhat KB. If you can downgrade one of these packages, you can generate reboot required state. But this is not recommended in production systems. glibc and kernel downgrades can cause problems. You can try it at new installed Rhel server after "yum update".

PostgreSQL installation fails with macOS Big Sur(M1)

I am struggling to install PostgreSQL on my macOS Big Sur with M1 chip.
These are the message I get when I try to install PostgreSQL in the last step. I tried installing version 12, 11, 10. Anyone knows how to solve this problem?
A non-fatal error occur whilst creating menu shortcuts.
Problem running post-install step. Installation may not complete correctly
Failed to start the database server.
There is a permissions issue produced by Big Sur sec policies. https://pgsnake.blogspot.com/2020/11/macos-big-sur-upgrade-breaking.html
This will happen if you're installing in the default location, which in this case is Library. I was struggling with this for a few days and found that if I define my own installation path not located in the Library folder(say some folder in my Desktop), I was able to install without issue.
Give that a try and see if it works for you.
Edit: Be sure to delete all previous failed installations if any exist.

Old ZFS recovery/upgrade strategy

The motherboard of a ZFS-based NAS died, and I'm now trying to access the data and move it, or revive the NAS. Debian and ZFS haven't been updated since 2015 or so, however. What I can glean from the log-files is:
ZFS 0.6.4
ZFS pool version 5000
ZFS filesystem 5
Debian Wheezy
Linux 3.2.0-4
So far so good. This Debian is rather old, though, and ZFS and some dependencies have to be compiled by hand to get it all going again - the apt repos have been largely purged of this old stuff, it seems.
So, I'm wondering if it's safe to just spin up a modern Ubuntu, say, and simply create the ZFS pools again.
The ZFS should get updated in any case, so it would be really neat if this just worked with Ubuntu 20, for example...
What came up after a bit of digging is that the ZFS pool version today is still 5000 according to Wikipedia. I can't find any information about what this "ZFS filesystem 5" refers to. I'm not sure at all what the right upgrade strategy is, or what the relevant documentation might be. Any pointers would be very welcome.
Here's what I did:
Install Ubuntu 20.04, install zfsutils-linux.
Run zpool import, this will list all the pools the system can find.
Run zpool import -f <poolname> (the -f is required because ZFS will otherwise complain that the "pool was previously in use from another system").

Upgrading postgresql on redhat failing "version"

I'm new to postgres, and the environment started with the redhat 64bit default install of 9.2. Postgres quickly shot from a proof of concept to everyone wanting a db, and I'm trying to get up to speed with 9.6.
When I run the upgrade, it errors with the following:
-bash-4.2$ /usr/pgsql-9.6/bin/pg_upgrade -b /bin -B /usr/pgsql-9.6/bin -d /var/lib/pgsql/9.2.old/data -D /var/lib/pgsql/9.6/data
Performing Consistency Checks
-----------------------------
Checking cluster versions
This utility can only upgrade to PostgreSQL version 9.6.
Failure, exiting
I'm ensuring that I'm calling the pg_upgrade in the new binary location. --read that in one article.
I have spent the better part of the morning searching google, and searching here...trying this and that. It's been an interesting, yet ridiculous worm hole.
I'm not using home brew or anything like that. I am just doing a yum install.
Can someone tell me, or point me to a good document that works around the glitches? The postgres manual document states that the pg_upgrade is valid from versions 8.4 up.
Any suggestions would be greatly appreciated.

I installed nvm n and now I keep getting "dyld: bad external relocation length"

I installed nvm, n, using sudo and decided to test it out by downloading several versions of node on my system. When I tried to switch between the node versions I kept getting "Permissions denied." So I decided to sudo the command for switching between versions too. That's when all hell broke loose. I keep getting
dyld:bad external relocation length
I've tried to reboot my terminal with some hope that it would magically fix itself out. Alas, I was wrong.Thanks in Advance.
Update 1: I've tried to use npm to install yo and it gives me the same "dyld" prompt, along with the following:
Trace/BPT trap: 5
Essentially I can't use npm anymore.
I had the same thing happen.
I was using a mac, so I downloaded the .pkg for the version of node I was interested in and re-installed it (which reinstalls npm at the same time).
Everything was back up and running after that.
I had the same this morning because of n package via npm,
Node was installed via brew (without npm), so i removed it this way;
brew uninstall node
then reinstalled the newer version via n package
n lts
if this is not enough because of policy rules of your mac, try
sudo npm lts
this solved my problem and saved a big time from reinstalling all global node modules.
Just use n reinstall node that you break in.
i solved my problem wihout uninstalling the nodejs,just update the node version by n, and it works.
sudo n latest