Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update faq.md #58

Open
wants to merge 5 commits into
base: master
Choose a base branch
from
+3 −3
Open

Update faq.md #58

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
a8cd654
Fix typo
Apr 25, 2022
b9e7d38
Merge pull request #54 from yusi1/master
paradigm Apr 26, 2022
bf46bee
Use less clunky pronouns
pave-unpaved May 12, 2022
c6583b0
Merge pull request #56 from pave-unpaved/master
paradigm May 21, 2022
3284355
Update faq.md
brahad316 Jul 11, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion markdown/0.7/debugging.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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~}.
Expand Down
2 changes: 1 addition & 1 deletion markdown/0.7/distro-compatibility.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand Down
2 changes: 1 addition & 1 deletion markdown/faq.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -65,7 +65,7 @@ This process is referred to as ~{hijacking~} to emphasize the forceful way
Whichever offers the install process you like the most.

Once you've had ~+Bedrock~x hijack the install, you're no longer running that
distro - you're running ~+Bedrock~x. You can then can swap out everything
distro - you're running ~+Bedrock~x. You can then swap out everything
specific to the hijacked distro with parts from other distros. Once you've
configured the system to your liking, the result is functionally the same
irrelevant of which install process you happened to use to get there.
Expand Down