[Bug 1851123] Re: Ubuntu 19.10 and focal live cloned create and mount casper-rw partition
Olivier Robert
novhak at yahoo.fr
Thu Nov 14 01:03:09 UTC 2019
Imho, the default behaviour should be overall read-only, as it's more in
line with the general perception of a live system as an "I'm just
looking" thing. Straying away from this concept could make more than a
few people uncomfortable.
Moreover, having a default write behaviour can have adverse consequences
in the long term. May a bug arise, there is an increased probability
that it would behave destructively, especially considering that we're
facing scripted automatic partitioning, which isn't quite the least
potentially destructive operation.
On one hand, I understand there are use cases when people want to have
installer logs handy on their stick, and having to pass "persistent"
each and every time on the command line can be a problem. But On the
other hand, there are people who don't want their USB stick written to
for several reasons, one being to perform an integrity check before
booting (such an unattended write operation would make subsequent
integrity checks fail). The only option for these users is to remember
adding "nopersistent" each and every time, and with no typing mistake of
course, and not forgetting to interrupt the boot process, otherwise
there's a write, and it's too late.
It seems to me there should be a solution to make both worlds happy,
such as requiring people who want log persistence to pass "persistent"
or why not "persistent-log" once on the command line. The system would
then create the partition the way it's currently done by default, and
during further boots with the default parameters, the system would check
if a "casper-rw" volume exists on the live support, and if yes, mount it
rw.
Additionnally, to address @cscameron's remark, it could be indeed useful
to be able to limit the space automatically allotted to casper-rw on the
live medium, such as defining an additional parameter to specify its
size, either absolute or relative (as a percentage), but another
solution that's already working is to create and format the volume
manually (don't forget to label "casper-rw") and specify its size, which
is a one time operation, hence should not be too much of a burden.
--
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
More information about the foundations-bugs
mailing list