Boot partition too small for snapshotting

Bug #1898293 reported by Harald Rudell on 2020-10-02
This bug affects 2 people
Affects Status Importance Assigned to Milestone
ubiquity (Ubuntu)

Bug Description

RUnning the 20.04 desktop zfs install, the boot partition is 500 MiB

I run 512 MiB without zfs because the default 234 MiB has been too small for a long time, like two years

500 MiB is too little because snapshotting is taking place. boot cannot hold even two kernels

macOS boots from a single container that can have any number of installations

That would be a better solution for zfs, to have a single pool where any number of bootable installations can coexists, each with their own boot area and encrypted root file system

# delete all boot snapshots so system, upgrades may complete:
zfs list -H -o name -t snapshot -r bpool | xargs -n1 zfs destroy

ProblemType: Bug
DistroRelease: Ubuntu 20.04
Package: ubiquity (not installed)
ProcVersionSignature: Ubuntu 5.4.0-48.52-generic 5.4.60
Uname: Linux 5.4.0-48-generic x86_64
NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
ApportVersion: 2.20.11-0ubuntu27.9
Architecture: amd64
CasperMD5CheckResult: skip
Date: Fri Oct 2 13:26:21 2020
InstallCmdLine: BOOT_IMAGE=/casper/vmlinuz file=/cdrom/preseed/ubuntu.seed maybe-ubiquity quiet splash ---
InstallationDate: Installed on 2020-08-14 (48 days ago)
InstallationMedia: Ubuntu 20.04.1 LTS "Focal Fossa" - Release amd64 (20200731)
 PATH=(custom, no user)
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

Harald Rudell (harald-rudell) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in ubiquity (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers