package; drop Artix Linux
Arch Linux: index.rst punctuation
Arch Linux: Boot pool encryption key must not be in child dataset
Arch Linux: delete backup after restoration
Remove trailing blanks
Move topology spec above pool creation
Arch Linux: Reintroduce INST_UUID
Arch Linux: secure permissions for key file
Signed-off-by: Maurice Zhou <ja@apvc.uk>
index:
Numbered steps
Arch guide:
Reduce RAM requirement to 2G
March 2021 live image build
Use `pacman -S --needed` to skip reinstalling up-to-date packages
Use "Xonzfs" hostname instead of "localhost"
Remove pool encryption tips: Not relevant
Tip for encrypting boot pool
Add archzfs-testing repo; but commented out
Fix find-root-pool-name-in-grub link
Add missing steps in LUKS bpool
Warn about bricked motherboard for Secure Boot
Remove INST_UUID INST_MNT
Artix guide:
mostly same as above
I have tested the guide with a VM,
including LUKS bpool and hibernation section.
Signed-off-by: Maurice Zhou <ja@apvc.uk>
This is a basic HOWTO page for OpenSUSE. This pages not official. This is a personal work represents how I do it.
* Added openSUSE on ZFS basic pages. For Leap and Tumbleweed this pages generated in lights of Debian and Ubuntu pages.
Signed-off-by: Suleyman Poyraz <zaryob.dev@gmail.com>
Arch Linux Root on ZFS: Encrypt boot pool with LUKS
Typo fixes; tweaks
Add Secure Boot
Secure Boot key enrollment differs
Secure Boot: rm HP laptop ref
Strictly follow manu. instructions. I bricked my EliteBook 820 G2 with KeyTool.efi
Example Secure Boot customization links
Back up Secure Boot signing keys
Secure Boot: Add link to bricked motherboard
Replace Secure Boot with a link; out of scope
Signed-off-by: Maurice Zhou <ja@apvc.uk>
This was mentioned in #99 and I added it as an alternative option.
However, it seems to break GRUB; see #107. GRUB tries to parse
/proc/mounts and see a line like this:
systemd-1 /boot/efi autofs ...
From there, it gets "systemd-1" as the device name, and breaks.
Closes#107
Signed-off-by: Richard Laager <rlaager@wiktel.com>
We need the bpool to end up in zpool.cache. For some reason, this is
not happening normally on Ubuntu 20.04. I added the same steps to
Debian too, for good measure.
This was discussed in #120.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
The previous approach to installation is: try this easy one first, and
if it fails, try the hard one.
This commit streamlines the installation experience by minimizing
references to such procedures.
This commit also removes verbose comments from Root on ZFS installation
guides.
As the upstream has fixed glibc, its section is also removed.
Signed-off-by: Maurice Zhou <ja@apvc.uk>
We were getting errors about failing to parse some blocks as "sh"
because they weren't.
I made one small textual change when cleaning this up.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
If the disk has been used before (with partitions at the same offsets),
previous filesystems (e.g. the ESP) will automount if not disabled.
Co-authored-by: attero <service-github@attero.me>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Closes#119
"The /root dataset is created with default world-readable permissions
(755). debootstrap would create /root with 700 permissions, but it
does not change the permissions if it already exists."
Reported-by: zxyrepf
Closes#115
I made Debian follow the Ubuntu approach, which comes from the Ubuntu
installer. There was a report (#99) of a problem with the old approach
used on Debian. In that issue, user foo-git linked to a Fedora feature
request which discusses automounting /boot/efi instead. I've offered
that as an alternative.
I am not switching to that outright, as following the Ubuntu installer
(where possible) is a goal of mine.
Suggested-by: foo-git
Closes#99
The fix for #97, 66233a1138, seems to
have created yet another issue (beyond #100):
"the link /etc/resolv.conf -> ../run/systemd/resolve/stub-resolv.conf
is dangling (since /run has just been clobbered by an empty tmpfs).
debootstrap seems to populate all manner of stuff in /run."
f1721edda7 (commitcomment-45770519)
I considered just reverting all of this, since the original issue only
occurred when copying in an existing system. Ignoring it was my
decision the first time this came up. But it's come up twice now.
Also, this mode is mentioned in the guide. Most importantly, if we are
not mounting a /tmpfs at /run in the normal case, then we could end up
with cruft in /run in the root filesystem which could potentially break
something or be confusing later if the /run tmpfs ever failed to mount.
So in the interest of correctness, I'd like to try to handle this.
I am now mounting a tmpfs at /mnt/run before the debootstrap step.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
The zpool.cache file is getting cleared by zfs-import-bpool.service. A
work-around is to move the cache file out of the way before the import
and restore it after:
https://github.com/openzfs/zfs/discussions/8549#discussioncomment-231334
The suggestion there is suppressing errors with `|| true`, which can
also be done by prefixing the command with `-`. (I verified that the
systemd in Buster is new enough to support that.) If we are
suppressing errors anyway, I'm not sure there's a benefit to checking
for the file rather than just trying the move and letting it fail. The
latter approach avoids the shell entirely. So I changed it.
Closes#97
Suggested-by: Andrey Prokopenko <9478806+terem42@users.noreply.github.com>
Tested-by: Hevisko <hvjunk@gmail.com>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
It was reported, in #97, that this is required when copying an existing
system installation into the root filesystem. It is probably a good
idea to do this all the time, to avoid the risk of stray junk ending up
in /run during the install process.
Suggested-by: Hevisko <hvjunk@gmail.com>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Move the CentOS/Fedora release packages to a secure https address
at the official zfsonlinux.org domain.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
The convention here is to add a blank line between commands that
cannot be copied-and-pasted together. apt is such a command, as it
will eat the input from the paste.
It is not necessary to enable universe in the Live CD. zfs-initramfs is
in main these days.
I left universe (and multiverse) enabled in the installed system.
People who care can customize.
Fixed small typo, missing "i" in either "After installing the *zfs-release* package and verifying the public key
users can opt to install `either` the DKMS or..."
In general apt is the preferred way to interact with packages, and I
think in this case there is no need/advantage to use dpkg.
Closes#88
Signed-off-by: Richard Laager <rlaager@wiktel.com>
[Fixed the other two instances too.]
