[Bug 1898293] [NEW] Boot partition too small for snapshotting

[Harald Rudell]

Public bug reported:

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

Get-around:
# 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)
ProcEnviron:
 TERM=xterm-256color
 PATH=(custom, no user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: ubiquity
UpgradeStatus: No upgrade log present (probably fresh install)

** Affects: ubiquity (Ubuntu)
     Importance: Undecided
         Status: New


** Tags: amd64 apport-bug focal ubiquity-20.04.15.2

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to ubiquity in Ubuntu.
https://bugs.launchpad.net/bugs/1898293

Title:
  Boot partition too small for snapshotting

Status in ubiquity package in Ubuntu:
  New

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

  Get-around:
  # 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)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: ubiquity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1898293/+subscriptions