automatic creation of casper-rw breaks installation from "disk"

Bug #1846762 reported by Mario Limonciello
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
casper (Ubuntu)
Fix Released
Critical
Michael Hudson-Doyle
Eoan
Fix Released
Critical
Michael Hudson-Doyle

Bug Description

OEM factory installation typically puts the Ubuntu media onto a recovery partition and uses a preseeding recipe to install into the remaining free space on the disk.

This casper change appears to have broken that behavior:

casper (1.415) eoan; urgency=medium

  * Persist logs on the install media by default:
    - Try to auto create a casper-rw filesystem on the install media if there
      appears to be at least 100MiB free on it.
    - Use a casper-rw filesystem for /var/log if it is not being used for
      persistence.
  * Fix some '|| continue's that got missed when check_dev got refactored into
    a function.

 -- Michael Hudson-Doyle <email address hidden> Thu, 08 Aug 2019 16:26:41 +1200

In my testing (in QEMU) I can see errors from the installer that no free space can be found. Examining the disk I see that a casper-rw partition has been created in the free space taking up the entire disk.

Would you please consider to recognize the "nopersistent" kernel command line option already supported by casper to disable this behavior?

Changed in casper (Ubuntu):
assignee: nobody → Michael Hudson-Doyle (mwhudson)
description: updated
Changed in casper (Ubuntu):
importance: Undecided → Critical
tags: added: rls-ee-incoming
tags: added: eoan regression-release
removed: rls-ee-incoming
tags: added: id-5d977fddc1b17468188cc866
Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

Oops, sorry for the disruption. Yes, having "nopersistent" suppressing this behaviour makes sense to me.

Is there any way we could have found out about this breaking your use case earlier? casper has tests now, so if you can describe other use cases sufficiently precisely we can make sure we keep them working...

Revision history for this message
Michael Hudson-Doyle (mwhudson) wrote :

I've uploaded a fix to eoan UNAPPROVED.

Changed in casper (Ubuntu Eoan):
status: New → In Progress
Revision history for this message
Mario Limonciello (superm1) wrote :

#1:

Thanks! I'll get that added to the default factory install kernel command line.

Regarding how to find this out sooner, I think some discussions internal to Canonical OEM services would be a good idea. Some automation in continuous integration for daily images doing tests like how factory install works in a VM seem possible to me.

For other use cases, everything done in initramfs currently is here:
https://github.com/dell/dell-recovery/blob/master/casper/scripts/99dell_bootstrap

Basically images are built with that in the initramfs (or initramfs is modified to put that inside).

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package casper - 1.423

---------------
casper (1.423) eoan; urgency=medium

  [ Dimitri John Ledkov ]
  * Pacify systemd about cdrom.mount on boot, and order it correctly to be
    the last one on shutdown.

  [ Michael Hudson-Doyle ]
  * Have 'nopersistent' on the command line suppress the automatic
    creation of the casper-rw partition added in 1.416. (LP: #1846762)

 -- Dimitri John Ledkov <email address hidden> Mon, 07 Oct 2019 13:13:12 +0100

Changed in casper (Ubuntu Eoan):
status: In Progress → Fix Released
tags: added: id-5daf76eda2a6e5756012409b
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.