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.]
For a mirror or raidz topology, /boot/grub is on a separate dataset.
This was originally bpool/grub, then changed on 2020-05-30 to
bpool/BOOT/ubuntu_UUID/grub to work-around zsys setting canmount=off
which would result in /boot/grub not mounting. This work-around lead
to issues with snapshot restores. The underlying zsys issue
ubuntu/zsys#164 was fixed and backported to 20.04, so it is now back to
being bpool/grub.
This reverts commit b6fd009edd. It
conceptually reverts the errata notes from commit
04d3c1cee4, but includes new steps for
people in the pre-2020-05-30 state.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Fixes#55
I think (but am not absolutely certain) that things behave as follows:
- The non-zsys initramfs script expects canmount=noauto for the root
filesystem. It then mounts the active one (e.g. in the case of
clones) manually, overriding that.
- zsys manages the canmount attribute.
I am sure that when the system boots with zsys, the initial datasets,
which were created with canmount=noauto, have canmount=on.
Therefore, there seems to be no reason to set canmount=noauto for the
zsys scenario, and I have removed it. This simplifies the instructions
and may avoid issues like #73.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Fixes#73
Ubuntu 20.04's GRUB supports multiple EFI disks. There is a small
caveat in that it doesn't prompt in the chroot, but it works fine after
the reboot. Using the stock support means that the ESPs will be kept in
sync automatically.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Refs issue #55
This is how the Ubuntu 20.04 installer configures the ESP to mount at
/boot/efi, so it should be fine to use this convention everywhere.
/dev/md0's /dev/disk/by-uuid entry does not show up immediately, so I
removed the swapon there.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
On Ubuntu, console-setup, keyboard-configuration (a dependency of
console-setup), and locales are installed by default. On Debian, we
need to install them manually. (We were already doing so for locales.)
I merged the various dpkg-reconfigure lines into one to simplify. The
order isn't important.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Reported-by: Robert <technic-take3>
Fixes#59
Refresh the documentation to more clear and to account for changes
for made in the recent RHEL/CentOS releases.
- Replaced most ZFS on Linux references with OpenZFS.
- Condensed the list of repositories and made it clear which repos
are updated with new packages and which had been archived.
- Added separate instructions for RHEL/CentOS 6,7 and for RHEL/CentOS
8 and newer since the package manager was changes from yum to dnf.
- Recommend using `yum-config-manager` or `dnf config-manager` rather
than manually modifing the zfs.repo file.
- Converted the important notices to "notes" and reworded them. The
exact commands in the documention were also for much older versions
of ZFS and were removed entirely. This should be less of an issue
with more modern releases.
- Add a comment explaining the modules are automatically loaded
when a pool is detected, but they can always be loaded at boot
time by creating a /etc/modules-load.d/zfs.conf file.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Refresh the documentation to more clear and to account for changes
for made in the recent Fedora releases.
- Replaced most ZFS on Linux references with OpenZFS.
- Reworded kernel compatibility note and link directly to the
latest supported OpenZFS release to make it easy to check the
maximum supported kernel version.
- Removed the kernel-devel package from the dnf install command.
The pacakge is now correctly brought in as a dkms dependency.
- Add a comment explaining the modules are automatically loaded
when a pool is detected, but they can always be loaded at boot
time by creating a /etc/modules-load.d/zfs.conf file.
Signed-off-by: Brian Behlendorf <behlendorf1@llnl.gov>
Users following the ZFS guide may not realize their system won't
receive important security updates between minor point releases
unless additional configuration is added to sources.list.
Signed-off-by: Mathias Gibbens <mathias@calenhad.com>
