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
This was breaking on FreeBSD, as some of the URLs were returning 404. That
raises an HTTPError. If we catch those and skip those sources (just as we
were already doing for HTTP codes other than 200), the script completes. But
then we get a whole bunch of columns full of "no", which does not seem useful.
I added code to skip columns for sources that failed to download.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
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>
This resolves#83. While 0.6.5.11 is old, it still had feature flags.
Since the 0.6.x branch will not receive further minor releases,
this static change should be stable.
Signed-off-by: Garrett Fields <ghfields@gmail.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>
This might be useful to someone. It definitely would have been useful
for me in the past. I have a Nexenta 4 system in production, so I was
able to personally verify the feature support there.
This has a couple of hacks, like with other sources, to workaround
documentation bugs.
Fixes#82
Signed-off-by: Richard Laager <rlaager@wiktel.com>
The code for looking up Joyent versions does not work. If someone
cares about this, they can fix this in whatever way makes sense.
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
