The same problem on an HP server and there is a smarter solution found here: https://www.novell.com/support/kb/doc.php?id=7010449
Instead of disabling sensors in netdata altogether, you can just disable the acpi_power_meter kernel module, which doesn't work anyway on affected HP servers due to a BIOS bug. This way netdata can still get the temperature readings.
This is how you can disable the module immediately:
sudo modprobe -r acpi_power_meter
And this is how you make it permanent:
It deploys an app with the 10GiB of persistent storage mounted over /opt/data path.
The image used ubuntu:22.04 with sleep infinity, so it does nothing, just sleeps..
So you can akash provider lease-shell into your deployment and inspect the storage.
---
Follow this doc https://gist.github.com/andy108369/da1279257c018be6370310c990c25738
With the 0.14.x client's TX create certificate transaction sent over 0.16.4 RPC causing the majority of 0.16.3 to reject that TX, it in turn caused the minority of 0.16.4 validators halt at 6955214 block.
This is due to this commit in 0.16.4 which allowed old type of TX be present in the block whilst 0.16.3 - did not.
sudo snap remove --purge firefox
sudo snap remove --purge snap-store
sudo snap remove --purge snapd-desktop-integration
sudo snap remove --purge gtk-common-themes
sudo snap remove --purge gnome-3-38-2004
sudo snap remove --purge core20
sudo snap remove --purge bare
sudo snap remove --purge snapd
Make sure you are running your archival node with pruning = nothing since height=0 to keep all historic states (i.e. archiving node).
With akash 0.18.0 (aka mainnet4) you HAVE TO start the chain with AKASH_PRUNING=nothing set. (This is fixed in akash 0.20.0)
Do NOT change pruning in between the restarts since this can corrupt the chain data (IAVL) cosmos/cosmos-sdk#6370 (comment)
| import WebSocket from 'ws'; | |
| const ws = new WebSocket('wss://rpc-akash-ia.notional.ventures/websocket'); | |
| ws.on('open', function open() { | |
| console.log('Connected on Akash blockchain from WebSocket'); | |
| ws.send(JSON.stringify({ | |
| "method":"subscribe", | |
| "params": ["tm.event='NewBlock'"], | |
| "id":"1", | |
| "jsonrpc":"2.0" |
Impact: Akash deployments using Persistent storage will temporarily stall due to having their I/O stuck to the RBD mounted devices.
This will be needed in later steps.
kubectl -n rook-ceph get pods -l "app=rook-ceph-mon" -o wide
I've been playing with Rook Ceph, have been able to helm uninstall it (all the K8s bits including ceph CRDs), and installing it back again without the data loss while having the Pods using the persistent storage (the RBD).
The impact: the Akash deployments using persistent storage disks will hang for the time until Ceph services are restored.
They key locations which need to be preserved are:
/var/lib/rook/*isn't removed when you uninstall akash-rook helm chart
/var/lib/rook/mon-a;/var/lib/rook/rook-ceph;rook-ceph-mon secret;
This procedure is for removing all OSD off of a selected storage node in the environment with more than a single
storage node in the cluster and enough free disk space.
If you have a single storage node only, then you'll have to remove disk by disk.
If you have only a single disk, then you'll have to remove OSD by OSD, reclaiming the freed disk space in the VG (if that is your case)
using this and that hints or waiting until rook-ceph will support this.
osdsPerDevice from 3 to 1 and apply the rook-ceph-cluster helm chart;