This one is tricky, since I can't just identify the package and file a bug concerning the package, because it's not a problem concerning its behaviour in a regular desktop environment.

Actually the problem is that the live system keeps /var/crash and /var/log mounted on the support. Not quite read-only any more huh ?

Because of this :

  • The live image is modified (failing further checksum-based integrity checks one would want to make before booting)
  • It's not possible to load to RAM and eject

Actually it's possible to load to RAM and eject (what's impossible with Linux after all ?), but that requires more steps :

# umount /var/crash
# fuser -m -k -TERM /var/log ; umount /var/log # repeat until it works (usually once is enough)

And then eject, the usual way, e.g. from the Nautilus interface.

But it's not supposed to be a place to report bugs here, hence my question : how shall I report ?

EDIT : I found out that persistence is enabled by default. One has to pass the nopersistent parameter at boot to prevent the live system from creating an additional r/w partition on the support. This is annoying...

  • 1
    A real Ubuntu Live .iso really is read-only. You cannot accidentally create a new squashfs image, and write it to the USB, except through a spectacular comedy of errors. Perhaps you enabled persistence?
    – user535733
    Nov 5, 2019 at 19:15
  • 1
    When I say the image has been modified, I mean the image I dd'd to the USB support. If I check like this : dd if=/dev/my_usb_stick count=imgblocknum | shasum -a 256, I don't get what I should get. In the present case (current 19.10 live image), imgblocknum is 4812192 blocks. I tried before booting it, and it was giving me the correct value. No persistence is activated, I only passed the "locale=fr_FR.UTF-8" and "toram" parameters to the kernel. I tried without passing anything, and the problem is the same. Anyway, just try for yourself and you will see. I had no problems with the 19.04 image
    – NovHak
    Nov 5, 2019 at 19:36
  • @user535733 : It turns out persistence must be enabled by default. I tried on qemu by crafting a disk image containing the live image followed by 1 GiB of zeroes to simulate my USB stick, and had the same behaviour. Passing the nopersistent parameter prevents the live image from creating an additional r/w partition on the support.
    – NovHak
    Nov 13, 2019 at 2:28
  • I was just bitten by this. I used a USB drive as boot medium, wrote the .iso, and added an additional partition (sda5) to use as a writeable location. But, when booting, both /var/crash and /var/log are mounted to sda5. I didn't even know you could have multiple mount points to the same partition :) Anyway, install logs persist from one boot to the next...
    – bitsmack
    Nov 29, 2021 at 6:00
  • Actually, with further research, it looks like the installer created sda5 and just started using it automatically. Frustrating!
    – bitsmack
    Nov 29, 2021 at 6:17

1 Answer 1


I finally found out that reporting a bug in the casper package is the way to go when reporting bugs that are specific to the live image.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.