Update the getting started instructions for Ubuntu on a Raspberry Pi to
use the new 20.04.4 LTS release.
Signed-off-by: Fernando Carolo <fcarolo@google.com>
/boot/efi is used exclusively to mirror EFI contents to
other disks, as in `cp /boot/efi/EFI /boot/efis/disk{0,1,2}`
As shown in issue #256, this approach causes trouble with
`nixos-generate-config`, which fills filesystem type as 'none'.
This commit fixes this issue by removing /boot/efi mountpoint and
directly copy from '/boot/efis/primary-disk/EFI/'.
Closes#256
Signed-off-by: Maurice Zhou <jasper@apvc.uk>
When plain '--rbind' is used, the 'umount' process executed later in the
setup process completely unmounts the bound filesystem, resulting in various
forms of breakage on the host used to do the setup. When a Live CD is used
and the system will be immediately shutdown/rebooted, this isn't an issue,
but in other scenarios it can be problematic.
Making the bind mounts 'private' avoids this problem. This patch changes
the setup guides for 'modern' distribution versions but does not touch
the older ones where this functionality may not be available.
Signed-off-by: Kevin P. Fleming <kevin@km6g.us>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
I think there might be a mixup in the errata between paths suggested
in 2020-05-30 fix and those in original/2020-12-15 fix.
Closes#244
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Fix an issue where removing zfs-fuse package will cause tons of other
packages marked for removal
Reported by @siepkes
Closes#245
Signed-off-by: Maurice Zhou <jasper@apvc.uk>
This ensures that the Live hostname does not leak into e.g. OpenSSH
server keys. It's not a huge deal either way, but this is nicer.
Closes#158
Thanks: anarcat
Signed-off-by: Richard Laager <rlaager@wiktel.com>
This now uses a /BOOT instead of /ROOT. I also changed
rpool/ROOT/debian-1 to rpool/ROOT/debian. These changes make it match
the Root on ZFS systems. I have no actually tested this.
Closes#215
Signed-off-by: Richard Laager <rlaager@wiktel.com>
The dropbear-initramfs package can be used to add dropbear SSH support
to the initramfs. That can be used to remotely unlock the root pool
using the `zfsunlock` script.
Closes#46
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Besides the obvious s/buster/bullseye/ sort of changes, this:
- Removes the use of backports. At this time, the difference is
minimal (2.0.6 vs 2.0.3) and I do not see a need to force backports
on users. They are free to add it later if they wish.
- Updates the sources.list for bullseye-security also being at
deb.debian.org.
- Updates the bpool features:
- device_rebuild has an explanation of why it is not used.
- livelist is now used.
- log_spacemap has been tested, but shares the same explanation as
spacemap_v2 for why it is not used.
Fixes#204Closes#126Closes#205
Thanks: Juri Grabowski <git-commit@jugra.de>
Thanks: Freezed <freezed@users.noreply.github.com>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
It is not necessary to install zfs-initramfs in the Live environment.
I am changing this to reduce delta with the upcoming Debian Bullseye
instructions.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
This reverts commit b81a471939.
We clashed while working on this. The Bullseye HOWTO in the above
commit was not rebased on the current Buster HOWTO, so a lot of its
delta between Buster and Bullseye is improper.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
When trying to execute this script, it fails because it doesn't move to the home directory. I think there's meant to be a `cd` after setting the `HOME` variable.
When doing `apt upgrade` on my Debian machine, I saw that two packages was being held back. The reason cited was that the names had somewhat changed I think. It is worth noting that I'm running bullseye, so this might not be applicable to buster, which is the version documented here.
This enables 3D acceleration, which is desirable for desktop
installations.
Reported-by: Scott G. Ainsworth <scott@ainsworth.us>
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Closes#224
"It turns out that stopping the service is only effective done shortly
after reboot (< 1 minute?). After that a kernel upgrade might be in
progress and the service stops only after the kernel upgrade is
complete. After the upgrade finishes, installation can continue.
However, stopping the unattended kernel upgrade can render the media
unbootable (because /etc/kernetl/postinit.d/zz-deccompress-kernel might
not have run)."
I guess we'll go back to telling people to wait (a possibly long time)
for unattended-upgrades to finish.
This reverts commit d9f50ffa89.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
Closes#225
I don't know what I was thinking last night... this was _adding_
nosplash, not removing it.
This reverts commit c5e77db483.
Signed-off-by: Richard Laager <rlaager@wiktel.com>
