Ubuntu iso defeats the purpose of live media

[Leonard Riggs]

The whole purpose of live media is to:
1) Be able to boot into an operating system REGARDLESS of the state of the data on an internal hard drive.
2) Be able to run an alternative operating system WITHOUT making any changes to the existing system.

Casper (or whatever related components of Ubuntu iso) violates both these purposes.

1) I've had the live DVD unable to boot simply because of minor problems on my installation on the HDD. (Took the HDD out of the computer, and it booted fine -- then I could connect the HDD via a USB adapter to the running live system.)

2) The live DVD seems to think it owns your system and can just start making partitions wherever the heck it pleases without asking. Namely, "writable", which it seems to use for stuff like log files which I don't want to keep anyway! This is the sort of crap we Linux users left Microsoft years ago to avoid. You don't own my system, you don't get to unilaterally decide to scoop up the remaining 2/3 of my 1 TB HDD to use it for some damn log files. All this happens before the user is given any options whatsoever, and the options that do show suggest you can "try" it before making any changes to your system, which is false.

The log files on "writable" are not useful, and even if they were, you shouldn't need hundreds of GB for them!

Although it will definitely use it ALL if given half a chance. Example: I recently booted a computer with the iso written to a 64-GB usb stick. Thankfully in that case it made the writable partition fill the remainder of that stick INSTEAD of screwing with other hard drives (not that that is acceptable either, just preferable). But due to some kind of hardware incompatibility, the entire 64-GB stick became filled with repetitious error messages in just a few minutes of booting, after which the system became unstable or unresponsive. The only way I could get the live system to "work" was by killing the rsyslogd process as soon as I could get to a command prompt, and then delete the several GB of crap that had accumulated in the minute it took to boot.

Maybe you'll say that those log files are important to find out why the live media doesn't boot. Two things:
A) In the scenario described above (1), the live DVD didn't write any files to the 'writable' partition it made and formatted, because it never made it that far.
B) In testing something before release (e.g. alpha testing), that might be fine to unilaterally write log files, but if it doesn't boot after release, that's not the time to be writing these log files. Simply fail to boot, and let the user find something else that does boot instead. Unilaterally adding partitions to users' systems (when they only wanted to try Ubuntu) is unacceptable.

[Chris Guiver (guiverc)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please execute the following command only once, as it will automatically gather debugging information, in a terminal:

apport-collect 2000874

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://wiki.ubuntu.com/ReportingBugs.

(No product or ISO details were provided, thus details cannot currently be explored; though this maybe just changed to opinion even with ISO details - but currently no exploration is likely possible)

[Leonard Riggs (leo-riggs)]

Okay, I have now had a chance to download and look at the source code for casper and klibc-utils (the current versions in the 22.10 repos), and I think I have a good understanding of how this all went wrong, which I will explain in the next few paragraphs.

Yes, I didn't mention a particular ISO because these problems affect casper in general, not one particular ISO. The ISO I happened to be using was the Kubuntu 22.10 installation DVD.

Before looking at the code and finding out what happened, I was under the impression that casper just didn't give a darn what device it put the "writable" partition on. Correct me if I'm wrong, but I now gather that the INTENT is for casper to put the "writable" partition only on the device from which it has booted. Is that right? It still aggravates me that it is done without any user interaction/permission, but if the INTENT was to only affect the device on which is the ISO being booted from, that is better than simply willy nilly picking any place. Unfortunately, through stupid assumptions in the casper code, it CAN pick a device other than the current boot device.

The reason for this (and again, please correct me if I'm wrong) is that casper starts out not having a clue where it booted from, so it just gets a list of all block devices that might could be it and starts using heuristic tests to attempt to find one that looks right. As soon as it finds one that seems to quack like the duck it's looking for, it picks that one. But this selection is only by guessing and making assumptions, not by actually knowing. I see there's even a comment in one section admitting, "This is an ugly hack situation, the block device has an image directly on it. It's hopefully casper, so take it and run with it."

In making these stupid assumptions, casper also takes the shortcut of picking the first thing it guesses to be correct. So in the event that there are multiple devices on the system that WOULD match casper's tests, it won't even get around to considering any but the first, nor wondering whether it screwed up in its assessment of which device it was running from. This is just asking for problems. It's not at all an odd situation that someone would happen to have multiple devices with casper ISOs on them, even perfectly identical images. Let's say I write an ISO to two USB sticks, or to a DVD and USB stick, or to an SD card and a DVD or whatever combination. If casper identifies the wrong device as the one from which it's running, it MIGHT "work" (as in boot), especially if the images are identical, but the behavior is still WRONG and against intent, particularly when it ends up writing persistence data onto the wrong device. Because then I could boot from the USB stick, thinking my persistent data is written there, and expect to have it there if I take my stick and boot from it on another computer, but it won't be there; it will be on the other device that just happened to be in the system at the same time.

And, importantly, it's not just the location of the "writable" partition that is affected. Casper will at the same time fail to correctly identify the device it is supposed to be booting from. It...

[Launchpad Janitor (janitor)]

[Expired for casper (Ubuntu) because there has been no activity for 60 days.]