Thanks. I noticed you’ve done a lot of testing. You haven’t encountered this experience at all?
I’ve been experiencing it once every day or three. I just had it twice in a row two days ago; and then first thing the following morning. All different machines. That’s why it seemed like a good idea to have logging enabled by default. It’s not the kind of problem where you can rerun it and capture the info. (But, if I’m the only one experiencing it, I understand why it would be ho-hum to others.). I just don’t understand how I’ve experienced it so much, and nobody else has. There is nothing specific to me, or one machine.).
Yesterday, I enabled logging and the problem went away. I cancelled out (as it was formatting, or beginning to “fill disks.”). Ran it again without debug logging, and it failed again. (I ran it again with debug, and it worked.). So, I’m thinking if informative logging were turned on by default, the behavior would probably never be seen. 
[I’m not sure why it hasn’t been enabled anyway. The same rationale that this bug isn’t bad would apply to that logging too. People will only experience it once during install. They only install once. Ergo, informative logging shouldn’t be worse than the errors it would bring to light more easily]. Anyway, I’m now thinking Calamares isn’t waiting long enough to see a result. Maybe logging slows it down just enough that it catches what it needs to see. But, that still begs the question: why am I the only one seeing it?
I think I’ve carried this topic as far as I can. I didn’t intend to get this involved in any distro’s testing. I just wanted to make sure 20.04 (generally) works with the newer Ryzen hardware. I landed here because I used Lubuntu for 4 years prior to LXQt. It’s familiar (in both good and bad ways.). I shouldn’t get too involved. My thoughts are not orthodox.
I’m thankful for learning so much about how to contribute testing within Ubuntu’s corporate environment. I will definitely participate with future 20.10.
The strongest conclusion I’ve formed: Ubuntu (corporately) creates it’s own pain points by having unnecessary feast/famine cycles. If every flavor had it’s own release date, there could be more dedicated effort to each flavor. For example, I’m testing each flavor each day (almost). That has prevented me from spending more time trying different things with with any single flavor. It must be the same way with everyone. The old saying, “you can’t squeeze blood from a turnip.” Everyone has their limits.
These feast/famine cycles (along with drop-dead dates) don’t seem healthy to me. It doesn’t maximize resources. It feels toxic, actually. People learn to make excuses for buggy releases because… what’s the alternative? Wait another half year? Beat one’s self to death just to make an arbitrary date? (along with six other flavors all marching to the same arbitrary date?).
Then there are complaints about a lack of volunteers. Why would anyone intentionally walk into a spinning propeller like this? If there’s a problem with not enough people, the first obvious solution is to stagger the release dates so there can be more dedicated (migrant) help for each flavor. Not marathon exercises twice a year. If the problem is self-inflicted (as it appears to be from my perspective), why would people be eager to enable that? (bringing their personal passion to something that is fundamentally setup to exhaust resources & passions; encourage people aim low and make excuses just because they’re powerless to control resources and dates?)
That’s just my takeaway from this experience. I understand there are more “on board” ways of viewing this. I appreciate the availability of Ubuntu distros. I will definitely contribute testing again (and will continue to test until April 20).
