diff --git a/markdown/0.7/debugging.md b/markdown/0.7/debugging.md index e39fd6a..f871fda 100644 --- a/markdown/0.7/debugging.md +++ b/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~}. diff --git a/markdown/0.7/distro-compatibility.md b/markdown/0.7/distro-compatibility.md index 76b6e07..e49cbd0 100644 --- a/markdown/0.7/distro-compatibility.md +++ b/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 diff --git a/markdown/0.7/feature-compatibility.md b/markdown/0.7/feature-compatibility.md index 31d3faf..febc166 100644 --- a/markdown/0.7/feature-compatibility.md +++ b/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