docs: add two more cases to the troubleshooting guide (celestiaorg#2005)

* add two more cases to the troubleshooting guide

Signed-off-by: Long Zhang <[email protected]>

* chore: fix hook was ignored because it's not set as executable

Signed-off-by: Long Zhang <[email protected]>

* revert the permission change of the git hooks

it turns out that yarn lint:md will check all the .md files and it can contain lots of errors. I guess that's why the git
hooks are disabled for now.

Signed-off-by: Long Zhang <[email protected]>

* address the nitpick comments by the rabbit

Signed-off-by: Long Zhang <[email protected]>

---------

Signed-off-by: Long Zhang <[email protected]>

Author: gluckzhang

how-to-guides/celestia-node-troubleshooting.md

@@ -311,3 +311,68 @@ sudo systemctl daemon-reload
 ```bash
 sudo systemctl restart celestia-bridge
 ```
+
+## Error: "no space left on device"
+
+When a bridge or full storage node runs on `ext4` file system, there will be errors like the following due to large folder size:
+
+```bash
+ERROR   header/sync     sync/sync.go:227        syncing headers {"from": 5074102, "to": 5161144, "err": "creating file: creating ODSQ4 file: creating Q4 file: creating Q4 file: open /root/.celestia-bridge-mocha-4/blocks/C9ADF6D9F862D92993D67977DE407D17ECF7F1DACE5FB7FE9A6845F4BD0172CE.q4: no space left on device"}
+```
+
+You may also observe similar errors from the `tar` command when extracting a snapshot of an archival bridge node.
+
+There are two solutions to this problem:
+
+#### Option 1: enable the large_dir feature for ext4
+
+:::tip NOTE
+If the Node Store is on the same partition as the OS, it is recommended to take Option 2.
+:::
+
+1. Stop the node
+2. Unmount the device and run the following command:
+
+```bash
+# unmount the partition
+# the value of <target> can be either the partition name (e.g., /dev/sdc1) or the mountpoint (e.g., /mnt/celestia)
+sudo umount <target>
+
+# enable the large_dir feature, use the partition name like /dev/sdc1 here
+# if RAID is set, you can use the partition name like /dev/md0 for tune2fs
+sudo tune2fs -O large_dir </dev/partition>
+
+# perform a filesystem consistency check
+sudo fsck -f </dev/yourpartition>
+
+# mount the partition again
+sudo mount </dev/yourpartition> <mountpoint>
+```
+3. Restart the node
+
+#### Option 2: migrate to XFS/ZFS file system
+
+Make sure you have your node id backed up so that you can import them later on.
+
+## Error: "can't get key ...: too many failed passphrase attempts"
+
+If you have initialized a bridge node with option `--keyring.backend file`, you will be asked to provide a keyring passphrase. Then a bridge node key `my_celes_key` is auto-generated by the `init` command. However, this does not work well with the systemd service setup because everytime when the bridge node is started, it asks for the passphrase. The systemd service will keep failing with the following error:
+
+```bash
+ERROR        module/state        state/keyring.go:23        can't get key: `my_celes_key` from the keystore: too many failed passphrase attempts
+```
+
+Usually a bridge node wallet does not need to be funded unless you plan to do `PayForBlob` through it. We suggest using the default keyring backend (`test`) in this case which does not require a passphrase.
+
+If you don't want to init the node again, you can do the following steps:
+
+```bash
+# update the config.toml file in the home folder of the bridge node or adjust your systemd service definition
+[State]
+  DefaultKeyName = "my_celes_key"
+  DefaultBackendName = "test"
+
+# recover the key using `cel-key`
+# add `--keyring-dir </service_home_folder/keys/>` if you are using a custom home folder for the node
+cel-key add my_celes_key --recover --node.type bridge --p2p.network <network>
+```