19.10 Ubuntu live image has a persistent write behaviour by default, why not r/o*?

[NovHak]

Dear forum readers,

It all started with current 19.10 live image, and that bug report.

To sum it up, whenever the live image is on a writable medium that has 100 MB free space or more, it automatically creates a partition on the medium, that takes all available remaining space, and mounts /var/log and /var/crash read-write on it.

My opinion is that a live image should not be persistent by default, and there are a few reasons for that :

1. That's how live systems are generally perceived, in the "I'm just trying, don't write anything anywhere" spirit

2. Assuming persistent storage is free and can be written to, without asking, is potentially dangerous as a general rule

3. There are practical use cases, such as integrity checking before booting the image (but I certainly can't list these exhaustively)

4. Being persistent by default poses a problem to users who don't want it persistent, since they would necessarily have to request non-persistence at each and every boot. "Persistent users", on the other hand, could benefit a mechanism where they could enable persistence once and for all on the current live system, benefiting from persistence, precisely, even if it's not enabled by default

Any opinions ?

[deadflowr]

moved to ubuntu linux and os chat

You might be better served posting over at discourse:
https://discourse.ubuntu.com/
Ubuntu developers frequent over there more than they ever do here.
They might have better insights into why it's done the way it is.

[NovHak]

I will, too.

This breaks with a custom that's more than a decade long (it came with the inception of Knoppix, if not before), that I think should be upheld. Not that I'm the kind of person that want customs to remain untouched "just because they're customs". Times have changed, and some could argue that that read-only policy is inherited from the CD/DVD times, but imho is goes beyond that, and should be recognised nowadays as good practice.

[Skaperen]

or how about releasing 2 images, one with the persistence and one without. but, i think the one without would be unpopular despite being more consistent. at least the persistence is limited. you can't change the system and see those changes persist. if you want that, just do an install directly onto another memory stick of sufficient size. BTDT on 8GB.

[sudodus]

We are discussing the behavior of live Ubuntu family systems of 19.10 and newer systems made by cloning from the iso file to a (read/write) mass storage device (typically a USB pendrive).

0. The behaviour has changed from completely live-onle only to live with a persistent log, which is useful to debug problems during installation (into an internal drive).

It is possible to switch from this hybrid mode, no persistence of the operating system except the logging.

1. As described in the opening post. users can have good reasons to use a completely live-only system.

This can be provided by the boot option nopersistent. If always used, there will be no partition for persistence. If used temporarily, it can be used during one particular session.

2. Users can also have good reasons to use a persistent live system.

This can be provided by the boot option persistent. A 'casper-rw' partition for persistence will be [created and] used unless the user replaces the boot option with another one temporarily.

The new default behaviour as well a read-only system and a persistent live system can be created with a tool that can either clone directly or replace the cosmetic boot options 'quiet splash' with 'persistent ' or 'nopersistent' (12 characters to avoid offset). See this link,

help.ubuntu.com/community/mkusb/minp

and you can also do it manually if you wish.

---

But you may find the method above cumbersome and ugly.

Please suggest other ways to make it possible to get the kind of live system that you want.

One solution is to fill the whole drive with a partition or partitions, that are not fit for persistence (other than an ext2, ext3 or ext4 file system in a partition named 'casper-rw'). Then there will be no persistence. This is done more or less by default, when using extracting methods to create a live drive. See these links,

help.ubuntu.com/community/Installation/iso2usb

help.ubuntu.com/community/Installation/iso2usb/diy

It is possible to ask the developers to modify the program package 'casper' to make it more flexible, so that there can be an explicit choice of live mode during the first run (when the live drive is booted into the first time).

- Should we suggest three choices according to items 0,1,2 above?

- Please suggest other ways to get what you want!

[sudodus]

I will, too.

Please post a link here, and in the bug report too, when you create a thread at Ubuntu Discourse

[sudodus]

or how about releasing 2 images, one with the persistence and one without. but, i think the one without would be unpopular despite being more consistent. at least the persistence is limited. you can't change the system and see those changes persist. if you want that, just do an install directly onto another memory stick of sufficient size. BTDT on 8GB.

Please explain:

- Do you mean an installed system in a USB drive (installed like into an internal drive)?

- What is BTDT?

I notice the idea with 2 images

I can add: There could be a barebone live iso file without any graphical desktop environment, but with a simple menu to install the desktop environments and default application program packages of the Ubuntu family flavours (Kubuntu, ... Xubuntu). Compare with the Debian live standard iso file.

I am not sure if the new Ubuntu Server live iso file with the Curtin installer would fit into this or if it is too dedicated to the server tasks. This might be worth looking into.

[C.S.Cameron]

If you do not like the casper-rw partition created with 19.10, you can always convert the casper-rw partition to a NTFS data partition.
this will allow the partition to be used for data on both Linux and Windows computers.

sudo mkfs.ntfs -f -L data /dev/sdx3

[sudodus]

I suggest a simple method to prepare the iso files for binary editing without 'sacrificing' anythng.

What do you think of the following idea for Ubuntu Focal Fossa?

It is possible to add the boot option

- 'persistent' in order to create a persistent live drive
or
- 'nopersistent' in order to create a live-only drive.

I am looking for a method to edit the iso file (binary edit) without loss of any current feature.

$ echo -n ' nopersistent '| wc -c
14

In order to add one of these boot options we need an unused space of 14 blank (alias 'space') characters in the iso file. I suggest that it is made so that the image contains such space in the image of grub.cfg and the corresponding file for syslinux.

So for the 'linux lines' in grub.cfg put 14 blanks (not 1 blank as it is now) after quiet splash,

'linux ... quiet splash              ---'
'linux ... quiet splash persistent   ---'
'linux ... quiet splash nopersistent ---'

and for the 'append lines' in isolinux/txt.cfg

'append ... quiet splash              ---'
'append ... quiet splash persistent   ---'
'append ... quiet splash nopersistent ---'

This way we can add those boot options without removing anything except blank characters and at the same time without offset of the code after the substitutions.

I have tested that this kind of substitution works in a straightforward way with 'sed' from the iso file. I have a method with a shellscript that 'wraps a safety belt' around the process and can write directly to the device without creating a modified file,

ubuntu.iso < sed 's/quiet splash              ---/quiet splash persistent   ---/' > /dev/sdx

or

ubuntu.iso < sed 's/quiet splash              ---/quiet splash nopersistent ---/' > /dev/sdx

It is easy to modify the current tool mkusb-minp for this task. (Now it is replacing 'quiet splash'.)

[sudodus]

You may want to participate in this thread at Ubuntu Discourse.