20.04 daily testing: Calamares "alongside" failed

I have tested “install alongside” on several machines (including2 laptops) and have not had any problems with that. That being said I have noticed that every once in a while “Erase disk” will fail if I click to fast on next. Of course I try again but cannot repeat it. :grinning:

I haven’t had an “alongside” problem except once. But, I just saw this bug in the “bugs to look for” today. It sounds like Calamares has been a problem for over four months. People have spent an incredible amount of time catering to its sensitivities. It sounds very similar to what I’ve been talking about the past week or two.

It’s amazing to me that extended reporting hasn’t been enabled for such an ephemeral problem. It’s like everyone’s just supposed to play along forever. You’d think by now Calamares would collect coincident information, log more stuff, point the affected person to the log (maybe hook into the automated crash reporting and keep the user out of it).

The error page is useless. It repeats the same info twice, and then says what failed without any hint about why. And this is FOUR MONTHS later? I regret that I spent as much time as I did on this. You guys have been chasing it for all this time. When the problem is Calamares not knowing what’s wrong with the environment at the time the error occurs. That’s nuts to expect people to knock themselves out this way (for this long).

I would like to point out that when the bug 1851188 that you referred to was first reported on 04.Nov.19 at that time we were using calamares version 3.2.16 if I remember correctly. Since then 6 updates to calamares have been released - so it is unfair to the developers to say nothing has been done in the past 4 months.

Everyone is doing there best to make the systems work in the desired way. That is why we are testing - to find the bugs before the official release. Software development is always about making the products better,more secure and last but not least usable for everyone.

Again I hope you will continue to test with us and help with these objectives. You have been doing just great and we need all the help we can get from people willing to commit their time and effort.

2 Likes

I don’t recall saying “nothing had been done.” What I’ve said is that it is remarkable how little information is given about the error; no context about the environment in which its occurring, what it looked like before/after the error, what was expected. I think that’s meaningful when Calamares spent a significant amount of effort developing the means to collect individuals’ hardware information. They expect you guys to spend countless hours stabbing in the dark (which you guys expected me to do, too). But, collecting user data is something they had no trouble implementing.

When I first brought this up, that Calamares should be expected to provide more error information, even notify itself through the “Ubuntu detected an error… send report?” workflow (they have their own data-collection work flow when there’s no error. But, when there’s an error, just keep stabbing in the dark. Don’t expect them to provide any information that would help identify what’s common between the random errors.). When I brought that up, I was told extended logging can be enabled with -d. Why hasn’t that been enabled as a default in the past four months? I could have had data the first time I hit the problem. It’s like we’re expected to work harder than necessary?

I don’t want to quench anyone’s passion about furthering Lubuntu, but… isn’t there more productive things to spend so much time on? If stabbing in the dark looks like a valid use of time (instead of expecting Calamares to put the same effort into error reporting that they put into collecting hardware information; or enabling debug logging as the default), doesn’t that say something about the extent to which Lubuntu can be furthered? (I’m saying this from the perspective of having used it for 4 years, until it became something else. Not just some random visitor opining.).

I was thinking about this last night. This is a perfect example of what Windows enthusiasts commonly refer to whenever Linux is mentioned as an alternative. They start talking about fragmentation, duplication of effort, everyone recreating the wheel. Here we have someone who decided to create a new installer (when Ubiquity seems fine). Now we have people spending countless hours stabbing in the dark because the duplicate installer is really good at collecting user information, but not providing actionable details when there’s an error. Nobody seems to think that’s a problem. Quite the opposite, they’re defending it.

I didn’t come here to upset anyone. I just wanted to help with testing. I appreciate all the very good information Chris and Walter provided which got me started with Ubuntu’s release testing. That was not a waste of time. I will definitely put that to good use. My previous 4-year use of Lubuntu probably makes me sensitive to how things are now. Personally, I think the common Windows-enthusiast complaint about fragmentation, duplication of effort applies to LXQt and what Lubuntu has turned into. I.e., I think it would have been more productive to just leave LXDE/Lubuntu where it was (end of life) and further other desktops that fill a similar lightweight space. I admire you guys for fighting the good fight. But, its stunning to me that anyone would spend 4+ months stabbing in the dark, not expecting the program (having the problem) to produce meaningful error information (especially when resources were spent to create data collection for other, convenience purposes.). Moreover, after almost 5 months, the debugging info hasn’t even been turned on by default. And, people seem to think there’s nothing wrong with this scenario. To me, it seems like self-inflicted work.

Good luck. I hope everything works out. I’m sorry for getting this involved. All I wanted to do was just help test Ubuntu generally, not get into community things. In some ways I feel very bad for having gotten into a discouraging discussion. But, in other ways… I’m a little outraged that I spent so much time working on something that’s been known for at least 4 months – and nobody’s expected anything better from it. I thought I stumbled onto something new, then something related to Chris’s bug. Now it’s turned into a well-known thing which is expected to be worked on using brute force. If I’d known that from the start, I would have merely said “good luck” without rocking anyone’s boat. If that’s how you guys want to work, that’s your choice. (If I had to do this, I’d just go back to Windows. I think the Windows enthusiasts have a valid point in this regard.).

Previously you said you have worked in development. I’m curious: where you worked, would this kind of stabbing-in-the-dark for 5 months be the way they’d conduct problem resolution? (I worked as a programmer and systems analyst for many years. People would be fired for this kind of stuff. Not so much the bug itself, but the “try again” response for 5 months – while devoting significant development resources to create a data collection process for other purposes.).

Sorry. I’ll shut up now.

I´m sorry if I offended you in anyway - I certainly was not criticizing your work. As stated in my post you have been doing a great job.

2 Likes

Admittedly, because KDE Neon requested it and it’s disabled by default.

Ubiquity doesn’t do this, unless it crashes. And if Calamares crashes, it does it, too.

Most software overall does not have extremely verbose logging. This is way more than most users— even advanced ones— generally need.

Nope. For one, you’re conflating Calamares with Lubuntu. Maybe based on the trouble you’re seeing, Calamares should be dropped. I’ll give you several reasons why not:

  1. Ubiquity is really no better. Worse, in fact, I think, based on years of doing testing and development across both installers. The other day one of the most notable members of the Kubuntu team told me they file more bugs against Ubiquity than any other package.
  2. I can actually immediately connect with developers of Calamares and they usually implement very quick fixes. Past experience with Ubiquity, despite it being a product of Canonical and having ready access to every single developer of it, has been quite the opposite.
  3. Ubiquity’s codebase sucks. It’s terribly documented and poorly organized. It’s often really hard to figure out a problem to even begin to try to suggest an actual problem. I have no such problems with Calamares.
  4. Every piece of software has its problems. The determining factor in trying to figure out whether or not it’s worth spending time on is whether or not it works for most situations. And Calamares does (so does Ubiquity, actually).

Admittedly that’s because I haven’t been able to dig in deeper into the issue because, well, you know there’s a global pandemic going on? I haven’t even had sufficient information to really do so until the 2nd, so it’s not actually been that long. That said, if there were more people that could help out that would be nice…

Nope, it gets fixed like everything else: testing, investigation, questioning, and always working towards progress rather than being mired in bad feelings.

That said, I’ve appreciated your help. I certainly hope you continue.

3 Likes

Except Ubiquity doesn’t regularly randomly fail on creating GPT tables (and resizing alongside), and expect people to spend FIVE MONTHS stabbing in the dark, without even enabling debug logging by default.

I find these line-by-line dissections to be very effective at missing the general intent of a post. (Kind of like “I encourage everyone to ignore the rest of this thread, until it’s own topic” – while other such topics are split out when it’s deemed useful, such as the “woe to those…”).

I’m sorry that I have upset some comfort zones here. If people are happy with how things are, that’s great.

Good luck!

Nope, we’re not. But we’re limited in time and energy (or at least I am; yesterday I caught up on a huge backlog here) so I’m trying to get to the meat of the matter. The reality is imperfection, the goal is to always strive for perfection, and we don’t get there or any closer to it by complaining. Let’s work towards solutions.

2 Likes

The bolded bit is what I touched upon earlier. It was frustrating (to me, at least) to see so many people donating their time and expected to (or, not having a problem with) stabbing in the dark for nearly HALF A YEAR as a valid use of time. To me, it seems like there would be better approaches (expecting Calamares to provide more context about conditions before/after the error; reporting such things to its own developers; The affected distro enabling extended logging by default to help distro supporters provide more info.).

I’m sorry that my thoughts were viewed as “complaining.” I was worried about that, and tried more than once to say that it’s simply not my cup of tea (but, others have every right to spend their time however they wish. I didn’t want to discourage anyone from doing that, nor criticize that activity if it’s deemed valid.).

A few weeks ago I made a comment about how Ubuntu’s corporate culture is something I don’t think I could ever fit into. You seemed a bit triggered into a tedious analysis of how Canonical is separate, etc. But, I was talking about the overall largeness that leads to group-think (stabbing in the dark for FIVE MONTHS; being sensitive to anyone questioning it, etc. Others expected to fold inline because group membership/agreement is more important than fixing the bug – allowing for other bugs to be found and fixed with that effort.).

What I’ve said could be energizing, and refocusing. Or, it could be unwanted (as it has appeared to be). My actions, stepping back, mirror what I said. I get mixed signals from you (and others) about the preciousness of time (while promoting the squandering of it).

Good luck. I hope things will be good. I’m sorry for the flare up. I didn’t have any reason to continue this until you revived it. I’m out now. Feel free to say all you want.

What would help, in relation to the particular issue, would be providing all the details on the bug as to what exactly the problem is. This should be as concise and as organized as possible. Long paragraphs often don’t help. Tell me in numbered steps how to reproduce this and give me logs. If there are conditions that it fails in but not others, list those, briefly.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.