Fix md links

near · Sep 20, 2024 · ac312e6 · ac312e6
1 parent f7188be
commit ac312e6
Show file tree

Hide file tree

Showing 4 changed files with 5 additions and 6 deletions.
diff --git a/docs/archival/run-archival-node-without-nearup.md b/docs/archival/run-archival-node-without-nearup.md
@@ -25,7 +25,7 @@ Running an archival node is very similar to running a [validator node](/validato
 
 ## Prerequisites {#prerequisites}
 
-- [Rust](https://www.rust-lang.org/). If not already installed, please [follow these instructions](https://docs.near.org/sdk/rust/introduction#install-rust-and-wasm-toolchain).
+- [Rust](https://www.rust-lang.org/)
 - [Git](https://git-scm.com/)
 - Installed developer tools:
   - MacOS

diff --git a/docs/troubleshooting/resharding.md b/docs/troubleshooting/resharding.md
@@ -54,11 +54,11 @@ You can find instructions on how to migrate to split storage on [Split Storage p
 
 #### Monitoring {#monitoring 1.37}
 To monitor resharding you can use metrics `near_resharding_status`, `near_resharding_batch_size`, and `near_resharding_batch_prepare_time_bucket`.
-You can read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md#monitoring).
+You can read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding_v2.md#monitoring).
 
 If you observe problems with block production or resharding performance, you can adjust resharding throttling configuration.
 This does not require a node restart, you can send a signal to the neard process to load the new config.
-Read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding.md#monitoring).
+Read more [on github](https://github.com/near/nearcore/blob/master/docs/architecture/how/resharding_v2.md#monitoring).
 
 ### After resharding {#after 1.37}
 If your node failed to reshard or is not able to sync with the network after the protocol upgrade, you will need to download the latest DB snapshot provided by Pagoda from s3

diff --git a/docs/validator/running-a-node-macos-linux.md b/docs/validator/running-a-node-macos-linux.md
@@ -179,8 +179,7 @@ Enter your account ID (leave empty if not going to be a validator):
 
 ## Running a Node on the Cloud {#running-a-node-on-the-cloud}
 
-Create a new instance following the [Hardware
-requirements](hardware-validator).
+Create a new instance following the [Hardware requirements](hardware-validator.md).
 
 Add firewall rules to allow traffic to port 24567 from all IPs
 (0.0.0.0/0).

diff --git a/docs/validator/validator-bootcamp.md b/docs/validator/validator-bootcamp.md
@@ -869,7 +869,7 @@ near call {pool_id}.{staking_pool_factory} update_staking_key '{"stake_public_ke
 
 In order to get a validator seat you must first submit a proposal with an appropriate amount of stake. Proposals are sent for epoch +2. Meaning if you send a proposal now, if approved, you would get the seat in 3 epochs. You should submit a proposal every epoch to ensure your seat. To send a proposal we use the ping command. A proposal is also sent if a stake or unstake command is sent to the staking pool contract.
 
-To note, a ping also updates the staking balances for your delegators. A ping should be issued each epoch to keep reported rewards current on the pool contract. You could set up a ping using a cron job or use [Cron Cat](https://cron.cat/).
+To note, a ping also updates the staking balances for your delegators. A ping should be issued each epoch to keep reported rewards current on the pool contract. You could set up a ping using a cron job.
 
 
 Staking Pools Factories for each network: