[Bug 1851123] Re: Ubuntu 19.10 and focal live cloned create and mount casper-rw partition

[Olivier Robert]

@nio-wiklund, @mwhudson : Thanks for your replies.

@nio-wiklund : Your solution would probably do the trick, but has the
inconvenient of indiscriminately replacing a string with another in the
whole image, hence possibly in places where it's not desired.

I think I will rather do one of those two things :

1. Create a partition that occupies the remaining space on the USB
stick, hence preventing the live image from creating (and writing to)
one without my consent

2. Create a custom Grub config file on the EFI partition on the stick,
specifying my own parameters

The first solution is the most straightforward, has the advantage the
stick can be used for additional purposes, but the inconvenient that
it's hardware-dependent (not all sticks have the same size). To have the
integrity check work, I would have to rehash after modifying, and
maintain different hashes, one hash per stick.

The second solution requires more changes, but would work for all
sticks. It probably won't work if I boot the stick on a non-EFI BIOS
though. For integrity-checking purposes I would have to rehash too, but
would only require one hash for all sticks.

Concerning your change proposal, adding an additional entry to Grub
solves indeed the problem of risking a typo compared to having to type
"nopersistent" and/or "toram" at every boot, to avoid undesired writes.
However, it still requires to never forget interrupting the boot
process.

@mwhudson : Imho, the current situation of the 19.10 live image can be
considered a bug, since it changes a default that has been there for
more than a decade, and that's in many minds, that a live OS image is
volatile.

That's not due to a coding error, like most bugs are, but rather in
comparison to usually expected behaviour, or "untold specification".

Moreover, your reasons for wanting it to become a default are unclear,
especially considering that the ones who want persistence could achieve
that by passing a one-time option at boot, and being OK for subsequent
boots, which obviously people who don't want persistence can't do,
precisely because they don't want persistence.

For these reasons it can be worth clarifying, outside of a bug process
why not. I just started a thread :
https://ubuntuforums.org/showthread.php?t=2431843

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

Title:
  Ubuntu 19.10 and focal live cloned create and mount casper-rw
  partition

Status in casper package in Ubuntu:
  Fix Released

Bug description:
  It is very good that it is easy to create and use a casper-rw
  partition to run Ubuntu persistent live in the versions 19.10 and
  Focal Fossa, and that it is even created automatically, when there is
  unallocated drive space behind the used part in a live drive.

  But I think the system for doing that is 'too eager'. Maybe it is a
  feature that is left from the development and debugging phase.

  - It would be enough (best), if the casper-rw partition is created
  only when it is needed, that is when the live system is booted with
  the boot option 'persistent'.

  - We (I am talking for users who like persistent live drives) can
  accept that the casper-rw partition is created even when the drive is
  booted live only (without the boot option 'persistent').

  - But we think it is a bug, that the live-only system is also mounting
  the casper-rw partition on the mount point /var/log and/or /var/crash
  and keeps it busy so that it cannot be unmounted.

  This way the drive is not really live-only, and it is not possible to
  manage the drive space behind the system in an independent way. For
  example, it is not possible to detach the drive by using the boot
  option 'toram', and it is not possible to repair the casper-rw
  partition when running live in the same drive. It will be necessary to
  have two linux systems to do such tasks.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: casper 1.428
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu9
  Architecture: amd64
  CasperVersion: 1.428
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Nov  3 11:15:29 2019
  LiveMediaBuild: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20191103)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=<set>
   LANG=sv_SE.UTF-8
   SHELL=/bin/bash
  SourcePackage: casper
  UpgradeStatus: No upgrade log present (probably fresh install)

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