On Thu, 9 Mar 2023 08:49:58 +0100, Jiri Slaby wrote:
On 07. 03. 23, 17:04, Jim Henderson wrote:
Yeah. My point is, though, that telling people running TW "read something that's not part of the actual update utility output", especially something that's on a mailing list, blog, buried in release notes (which we all know nobody really reads on a regular basis) is just bad form - just like the changes that broke (for some people) sudo a few months back.
OTOH, lockdown was present in the changelog and had a bug reference where all the risks were evaluated. Have you read the changelog at least? I believe close to noone reads that, nor any blogs, logs, or lists. Only when something breaks.
That the bug was not and still is not public is a mistake. But not of mine, sorry.
How many users read the changelog? I'm not speaking for myself, I'm speaking for users in general here - not everyone reads the changelogs prior to installation. Again, with daily releases (more or less) of TW, it would be a full-time job to keep up with every change. Maintainers are in the best position to know if a change that's being deployed is changing a default behavior or is likely to cause problems. Maybe not 100% of the time, but I'd bet money it's more than 80% of the time that they would know. There are always going to be situations where something gets missed. It happens. But having a 100% miss rate shouldn't be acceptable to anyone.
If we make changes that have the potential to break someone's system, we should do them the courtesy of telling them with specificity (not just "TW updates might break your system" - that's 100% accurate and 0% useful) what changes are being made (or proposed to be made) and give an option to avoid the update.
Provided the bug is VUL0, it had to be quick. Not much space to prepare anyone.
That's an edge case, and the worst-case scenario is one that we should be aware of, certainly, but we're not talking about letting people make informed decisions at the time of update for only the worst-case scenario. The code for zypper is open.
I believe people using TW are well aware of "zypper al" and the TW history repo. And they use btrfs by default, so can roll back too, right? And could boot with secure boot disabled. Many well known options to work around the issue, I think.
I knew about zypper al - but don't use it. Maybe I should. I didn't know about the history repo. I do use btrfs, so yes, rollback is possible too, and I don't use secure boot. I've been working with openSUSE since it was SUSE Professional (since SUSE became part of Novell in 2003 - so for 20 years now). I've used VMware Workstation for a lot of the time as well (off and on - currently 'on') and other things that required non-OSS drivers or software. I've been a TW daily-driver user since September - used to be Leap. Still learning, but I also am an admin in the forums and have been for a long time - now if, with everything that I read and follow around the project, I wasn't aware of something like the history repo.....what chance does someone who's just starting have? We can educate users about the options, but we can also make it easier for them to make informed decisions when they're updating their TW installation.
Last but not least, I do not recommend anyone with out of tree modules to run TW. I mean those users not having good enough knowledge how to fix things. And you likely know, out of tree modules break really often. And the only place where the users are supposed to complain are the companies producing those, ehm, modules.
With Leap fundamentally changing because of ALP, we're going to see more people moving to TW with less knowledge. Just saying "don't use proprietary modules" isn't sufficient. Every update, I recompile the VMware modules. VMware makes it easy to do that. Every update, I cross my fingers that I'm getting a GUI because I use the proprietary driver for my high-end nVidia card. I'm pretty tolerant of having to fix things. I don't update daily, though - I update about twice a month.
There will always be unintended consequences that get missed - but in a case like this (or the sudo change), that was a completely foreseeable issue.
Sorry, no crystal ball here. Provided, it all works in Leap, there were no doubts this will run on TW too. And see, the whole module signing machinery is broken heavily in TW and noone noticed until now. Without the trial, we wouldn't find out.
True. It just seems like we need to make sure people know before they install about something significant like this, and in a way that doesn't depend on them going and reading something when they're just doing their regular 'zypper dup'. Especially with the high degree of success that this has in Tumbleweed (and let's face it, TW is very solid - and the fact that so many use it as their daily driver is testament to that), it's easy as a user to become complacent about doing things like checking the release notes/changelog/etc. when something that could seriously break the system is introduced, it's that much more important to call attention to it.
Note that openQA passed too. We don't even test these modules there. So noone expected the lockdown patchset to fail. Maybe we can build some basic KMP (print hello world), try to load it and check the logs for hello world. I have no idea how hard that would be. KMPs should be tested. (But not the proprietary ones. Noone wants to be blocked by all those.)
It would be good to try to test at least for the common things we know about. We all know openQA is only as good as the test cases that it's got scripts to deal with - but this would be a good start.
In any way, now, the whole lockdown patchset is flushed down the toilette. After these things get fixed, we might retry. This time, after KMP maintainers confirm their modules work.
I saw that - keep up the good work. :) -- Jim Henderson Please keep on-topic replies on the list so everyone benefits