Comment 39 for bug 1863672

Hi Michael, thanks for looking into this.

> I don't think anyone can claim with a straight face that casper-rw is
> anything other than opaque.

It is still a lot more searchable than 'writable'. As I explained above, 'writable' yields next to nothing in terms of letting users understand why a partition might be labelled that way. 'casper-rw' does. And, considering that the label is something that the casper scripts are picking up, I don't really see how 'casper-rw' is that obtuse, because it pretty much tells you without looking anything up that it's associated with something called 'casper' and ensuring that something is both readable and writeable.

> We could have an argument about whether
> 'writable' is better or not but that's not very interesting.

We absolutely *SHOULD* because this is the crux of the issue here!

For one thing, as I mentioned, you could have used 'persistence', as other distros do, and not introduce a completely new label out of the blue.

And also, the problem is that:
- You decided to introduce support for a new label that I don't think anybody asked for.
- It seems to me like you unilaterally picked the label name that you *liked* best, without consulting much of anybody else (but I'd be more than happy to stand corrected on that).
- This introduced new *UNWARRANTED* complexity in the casper scripts, which resulted precisely in the problem we are being faced with today.

In other words, you tried to fix a problem that didn't exist, and in doing so, broke existing behaviours.

I will therefore assert the following:
- You should revert the casper scripts to the working 19.10 version (that only supports 'casper-rw) *NOW*. As far as I can tell, there is exactly zero urgency to introduce a new persitent label for 20.04, unless you can point to specific user cases that were left stranded by the inability to use something else than 'casper-rw' in 18.04 or 19.10.
- You should move the introduction of a new label to after 20.04 has been released, because, again, there is no real urgency on adding support for a new label and if this issue demonstrates anything, it's that there should exist some concertation as well as proper testing before this option is made public.
- Unless you can demonstrate otherwise, I don't believe it should be that big a deal to revert the casper script changes that pertain to additional label support from 20.04 to 19.10, but this needs to be done *now*, so that we can use the little time that is left before the release to test and ensure that the reversal doesn't introduce a new issue.

> And, well, I still can't reproduce this.

At this stage, I don't think it matters. Multiple people other than you can, so it's not something that you can release in its present state and "hope for the best".

I can consistently see the issue on intel NUC computers (I have 2 of these), which are not even PCs built with custom parts, and therefore I pretty much expect every user of a NUC platform to be unable to use 'casper-rw' persistence in 20.04.

Even if you can't reproduce the issue right now, you do have to err on the cautious side and assume that you are the exception, and that this is going to affect the majority of Ubuntu users, so please don't try to use the "I can't reproduce the issue" as an excuse not to do the right thing which is to drop the introduction of 'writable' as an alternate label, until you have had a chance to find a way to replicate the 'casper-rw' issue on your side.

Again, please understand that I am not advocating to never introduce an alternate persistent partition label ever, but simply, since multiple people are reporting that this simply doesn't work in its present form, and the release date for 20.04 is fast approaching, that a *PROBLEMATIC* change that is going to affect the many Ubuntu users who are using existing guides, scripts or applications to enable persistence should be reverted. And it's just a common occurrence of release-testing, really. If you get reports that a newly introduced change is breaking *existing* behaviour and it is clear that you may be short of time to address it in the current release cycle, you revert it and then try to fix the problem in the next release cycle (which I will be happy to help with, since I certainly can consistently replicate the issue on my side).

So can we please revert support for 'writable' in 20.04, and use the next release to try to fix the issues with trying to support 2 partition labels?

> So let's try something else. I've uploaded a hacked up initrd (...)

I tried to replace /casper/initrd with your version, but I'm afraid I too only ended up with busybox.

Again, unless you have confidence that you know precisely what the issue is, and should be able to fix it right now, I would advocate against trying to rush a fix just days before release, and instead revert the scripts, and use the leftover time to ensure that the reverted scripts still work as expected. This is an LTS release. This is not the time to introduce potentially breaking changes and/or behaviours that have not been thoroughly tested.