Add "Shadow password hashing and login" Entry

markdown/0.7/debugging.md

@@ -41,7 +41,7 @@ Many bootloaders allow users to alter the kernel line for a session.
 
 Bedrock is dependent on various runtime items being in placed, and thus one may not simply mount a Bedrock partition and `chroot` into it.
 
-One common need to `choot` into some system is to fix a broken `/boot`.  While a generalized `chroot` is not available, a limited one for this purpose is.  There are three main differences from a typical rescue `chroot`:
+One common need to `chroot` into some system is to fix a broken `/boot`.  While a generalized `chroot` is not available, a limited one for this purpose is.  There are three main differences from a typical rescue `chroot`:
 
 - Instead of setting up and `chroot`'ing directly into the mount, setup and `chroot` into `~(mount~)/bedrock/strata/~(stratum~)` for some ~{stratum~} which will perform the repair operation.
 - In addition to the typical `proc`, `dev`, etc setup, also bind-mount `~(mount~)/boot` to `~(mount~)/bedrock/strata/~(stratum~)/boot`.  This will make the ~{global~} `/boot` accessible for manipulation by the given ~{stratum~}.

markdown/0.7/distro-compatibility.md

@@ -61,7 +61,7 @@ non-local components, such as `/etc` files, changing out from under it.
 over `/etc` file changes.
 
 ~+Solus~x _does_ provide default versions of these files, but outside of
-`/etc`.  The expectation might be that the user copies them over at his/her
+`/etc`.  The expectation might be that the user copies them over at their
 whim.
 
 This is likely removable with adequate effort.  ~+Bedrock~x could be configured

markdown/0.7/feature-compatibility.md

@@ -61,6 +61,7 @@ Miscellaneous known feature-specific issues and limitations.
 | pamac/octopi                                    | ~!Inconsistent Reports~x | [Inconsistent reports](#pamac) |
 | ptrace (e.g. gdb, strace)                       | ~^Minor Work-around~x    | Install in same ~{stratum~} as traced program, `strat -r` |
 | SELinux                                         | ~!Does Not Work~x        | ~+Bedrock~x disabled on hijack |
+| Shadow password hashing and login               | ~^Minor Work-around~x    | [Differing shadow versions(#shadow-login)]
 | systemd-shim                                    | ~!Major Issue~x          | [logind access denied](#systemd-shim) |
 | timeshift                                       | ~!Major Issue~x          | Confused by filesystem layout; do not use with ~+Bedrock~x |
 
@@ -193,6 +194,23 @@ It is not clear why this might not be happening during SysV shutdown.
 ~+Bedrock~x's `etcfs` code does not do any direct signal handling.  Debugging
 this may require digging into `libfuse`'s code to see how it handles signals.
 
+### {id="shadow-login"}
+On some ~{strata~}, certian hashing algorithms aren't supported due to differences
+in `shadow` versions. This can cause faliure to login with a `login incorrect`
+error or equivalent when using a ~{stratum~}'s init that didn't create the hash with
+`passwd`.
+
+The solution to this is to rehash your password using the `passwd` command from
+whichever ~{stratum~} you are having problems logging in with:
+```
+# strat void passwd myuser
+```
+In extreme cases, you may choose not to do this as newer hashing algortithms can
+improve upon security.
+
+Note: this only happens generally in a few specific cases, such as with a
+fetched ~+Void Linux~x ~{stratum~} with passwords created with ~+Fedora~x's `passwd`.
+
 ### {id="systemd-shim"} systemd-shim
 
 On ~+MX Linux~x, the logged in user is expected to get certain permissions granted