Update Manager

[smurphos]

My other point is that we should have the option as we used to have to disable things like certain updates in an easy-to-use fashion.

I don't think at this stage anyone will convince Clem to reinstate the level system as it was, and the pros and cons of the Levels system have been discussed to death since Clem first started slowly weaning users off of it with Mint 18.2 and 18.3.

I think it is better to focus on the usability of the blacklist functionality E.g. best ways to find package names to manually add to the blacklist, or a curated list of package names a more cautious user may wish to blacklist and also using the export tool to implement the blacklist in automatic upgrades.

I never used the level system prevent any update (and unlike Pjotr am yet to suffer a regression that's required any rollback or imacted the use of my machine (since 2014)) I did think it had some use as a tool to give users an indication of the scope of particular updates, that they may want to delay upgrading if they were in the midst of mission critical work etc.

[JoeBingo]

Kernel 4.15.9-24 was released about this time last year as an update in Mint 19 and many users found their computer would not boot past grub. And this was shortly after the release of Mint 19 and the change from the level system in Mint Update. It was a good couple of weeks before a corrected kernel was available. That experience left a sour taste for me on the way updates are currently suggested to be handled. Used to be the Mint motto was something like, "if it ain't broke don't fix it". Seems to be now the motto is "If it breaks, it breaks".

When SOooo many experienced problems with Kernel 4.15.9-24, not a peep was heard about it from Mint. Not a caution, not a workaround, not a reason maybe why we couldn't boot past grub and an explanation that it might be a kernel update ... nada, nothing, nothing whatsoever at all. Only discussion of the issue here among end users. AND that darn kernel is STILL listed today in the Update Manager, although thankfully superseded many times over. My computer is a Linux Mint branded Mint Box and I was shocked that Kernel did what it did on my Linux Mint computer. Lesson learned.

So for the time being I have Pjotr's tip on how to Lock The Most Vital System Parts in place. I have lost confidence in the way Update Manager forces updates. But yeah ... there are always workarounds ... blacklists ... TimeShifts ... and locking vital system parts. Was easier with the level system GUI.

[gm10]

It was a good couple of weeks before a corrected kernel was available. That experience left a sour taste for me on the way updates are currently suggested to be handled.

That was before my time contributing to Mint but one of the first things I fixed because that situation was plainly untenable. The kernel did actually get rolled back nearly immediately, but Mint's Update Manager thought it knew better and completely ignored that and would force you onto it.

I wasn't using Update Manager at the time and at first could never understand why people kept updating to that long revoked kernel, until I looked at the code and realized what was going on.

When SOooo many experienced problems with Kernel 4.15.9-24, not a peep was heard about it from Mint. Not a caution, not a workaround, not a reason maybe why we couldn't boot past grub and an explanation that it might be a kernel update ... nada, nothing, nothing whatsoever at all. Only discussion of the issue here among end users.

Yep, that was quite unfortunate I thought as well in particular because this was at the end of the day a Mint home-made situation.

[JoeBingo]

Kernel 4.15.9-24 was released about this time last year as an update in Mint 19 and many users found their computer would not boot past grub. And this was shortly after the release of Mint 19 and the change from the level system in Mint Update. It was a good couple of weeks before a corrected kernel was available. That experience left a sour taste for me on the way updates are currently suggested to be handled. Used to be the Mint motto was something like, "if it ain't broke don't fix it". Seems to be now the motto is "If it breaks, it breaks".

When SOooo many experienced problems with Kernel 4.15.9-24, not a peep was heard about it from Mint. Not a caution, not a workaround, not a reason maybe why we couldn't boot past grub and an explanation that it might be a kernel update ... nada, nothing, nothing whatsoever at all. Only discussion of the issue here among end users. AND that darn kernel is STILL listed today in the Update Manager, although thankfully superseded many times over. My computer is a Linux Mint branded Mint Box and I was shocked that Kernel did what it did on my Linux Mint computer. Lesson learned.

So for the time being I have Pjotr's tip on how to Lock The Most Vital System Parts in place. I have lost confidence in the way Update Manager forces updates. But yeah ... there are always workarounds ... blacklists ... TimeShifts ... and locking vital system parts. Was easier with the level system GUI.

My post wasn't intended as a bash on Update Manager or Linux Mint, but rather just a sharing of personal experience and perspective. I KNOW there are MANY good people doing their very best to continue to make Linux Mint the secure and reliable distro that it always has been. For that I am most grateful. I am also grateful for Pjotr's tips. MOST grateful indeed. Pjotr's tips are my go-to Mint "user's manual". There was a learning curve when I committed to using Linux Mint exclusively in 2009 when XP went away and I tired of Windows. And there is still a learning curve as Mint evolves. I too proceed cautiously. Especially since the 4.15.9-24 Kernel fiasco.

[karlchen]

the 4.15.9-24 Kernel fiasco.

Uhm. Was that not the kernel 4.15.0-24 fiasco? - Sorry for being picky about such small details.

[JerryF]

...
I don't think at this stage anyone will convince Clem to reinstate the level system as it was, and the pros and cons of the Levels system have been discussed to death since Clem first started slowly weaning users off of it with Mint 18.2 and 18.3.
...

Nor would I try to convince Clem to do that.

[JoeBingo]

Uhm. Was that not the kernel 4.15.0-24 fiasco? - Sorry for being picky about such small details.

You are correct sir. I was going off memory, I'm old and it was late (typo) D'OH
But yeah, kernel update fiasco about this time last year was the gist of it.

[halregen]

My other point is that we should have the option as we used to have to disable things like certain updates in an easy-to-use fashion.

I don't think at this stage anyone will convince Clem to reinstate the level system as it was, and the pros and cons of the Levels system have been discussed to death since Clem first started slowly weaning users off of it with Mint 18.2 and 18.3.

I think it is better to focus on the usability of the blacklist functionality E.g. best ways to find package names to manually add to the blacklist, or a curated list of package names a more cautious user may wish to blacklist and also using the export tool to implement the blacklist in automatic upgrades.

I never used the level system prevent any update (and unlike Pjotr am yet to suffer a regression that's required any rollback or imacted the use of my machine (since 2014)) I did think it had some use as a tool to give users an indication of the scope of particular updates, that they may want to delay upgrading if they were in the midst of mission critical work etc.

The level system gave a probability based on the level where there could be bugs in software updates. When I first started using Mint 12, I had most of the levels up to 4, checked in preferences. I had a more unstable system. I then only had levels checked to 3. My system became a lot more stable. Just before the loss of level preferences, I had them checked only to 2. My system was rock stable. With the new no levels how is one to know the probability of certain software having bugs before allowing the updater to install? Is it only after experiencing a bug that a future update to that software can be blacklisted. If a bad update is installed it is difficult to go back to a previous version. How do you remember the names of buggy software from a list of more than one installed which was the one, that caused it. Only knowing this can allow blacklisting. Maybe now software is developed nearly bug free, I don't think so.

[michael louwe]

With the new no levels how is one to know the probability of certain software having bugs before allowing the updater to install? Is it only after experiencing a bug that a future update to that software can be blacklisted. If a bad update is installed it is difficult to go back to a previous version.

.
The change to the default setting(= install all updates when applied, instead of only up to Level 3 updates) and removal of Levels from LM 18.2 onward was prompted by the introduction of Timeshift, ie the cure for buggy/dangerous/sensitive updates borking a system is a Timeshift system recovery or Linux kernel recovery = prevention was done away with.

This change seems to be developer-friendly but noob/newbie-unfriendly, eg less work for the developers. Similarly for Canonical's new Snap packages in Ubuntu 16.04 onward. Such moves/changes in desktop Linux may make it less appealing to noobs/newbies and ordinary/average users.

[smurphos]

The level system gave a probability based on the level where there could be bugs in software updates.

It didn't give any indication of the probability of bugs in any particular update. That's the kind of misunderstanding that led to the level system being deprecated. It did give an indication of how severe the impact would be if a particular update did have bugs. It was also flawed, being a simple arbitrary list of packages. The one major system breaker in the last couple of years that impacted the majority of Mint users was a marked as a level 2 at the time.

Still, should you wish to recreate the level system via blacklist here's the definition of level 3 and 4 as per mintupdate 5.4.7

Source - https://github.com/linuxmint/mintupdate ... date/rules

Code: Select all

# Level 3
3|*caja|*
3|*cinnamon|*
3|*cjs|*
3|*libgtk|*
3|*marco|*
3|*mate|*
3|*metacity|*
3|*muffin|*
3|*nemo|*
3|dbus|*
3|glibc|*
3|mountall|*

# Level 4
4|acpid|*
4|*lightdm|*
4|*slick-greeter|*
4|*linux-|*
4|*mdm|*
4|*nvidia|*
4|*xorg|*
4|bcmwl|*
4|ndiswrapper|*
4|grub2|*
4|grub|*
4|linux|*
4|mesa|*
4|plymouth|*
4|systemd|*
4|ubuntu-drivers-common|*
4|upstart|*

[halregen]

The level system gave a probability based on the level where there could be bugs in software updates.

It didn't give any indication of the probability of bugs in any particular update . That's the kind of misunderstanding that led to the level system being deprecated. It did give an indication of how severe the impact would be if a particular update did have bugs. It was also flawed, being a simple arbitrary list of packages. The one major system breaker in the last couple of years that impacted the majority of Mint users was a marked as a level 2 at the time.

Still, should you wish to recreate the level system via blacklist here's the definition of level 3 and 4 as per mintupdate 5.4.7

Source - https://github.com/linuxmint/mintupdate ... date/rules

Code: Select all

# Level 3
3|*caja|*
3|*cinnamon|*
3|*cjs|*
3|*libgtk|*
3|*marco|*
3|*mate|*
3|*metacity|*
3|*muffin|*
3|*nemo|*
3|dbus|*
3|glibc|*
3|mountall|*

# Level 4
4|acpid|*
4|*lightdm|*
4|*slick-greeter|*
4|*linux-|*
4|*mdm|*
4|*nvidia|*
4|*xorg|*
4|bcmwl|*
4|ndiswrapper|*
4|grub2|*
4|grub|*
4|linux|*
4|mesa|*
4|plymouth|*
4|systemd|*
4|ubuntu-drivers-common|*
4|upstart|*

What exactly do you mean

It didn't give any indication of the probability of bugs in any particular update

Do you mean that in each level category the bug probability could be low or high at that time of update or that taken over all times of update the probability average could be represented by the level? Or alternatively just that the level represented the impact on the system when bugs were present.

[smurphos]

Or alternatively just that the level represented the impact on the system when bugs were present.

[halregen]

I have just got my first problem after the levels preferences not existing now. I installed some updates today that have messed up resume from sleep. Resume from sleep or hibernate has mostly always worked especially when I only allowed up to level 2. Unfortunately I did a timeshift snapshot only after the updates and the snapshot before that is in july before I upgraded to Mint 19.2. I don't think this would have happened if the levels were still available. I know I should have done the snapshot before the update but that means making a snapshot nearly every day because I receive updates nearly every day. So there is a lot more system maintenance now without update levels.

[Pjotr]

I have just got my first problem after the levels preferences not existing now. I installed some updates today that have messed up resume from sleep. Resume from sleep or hibernate has mostly always worked especially when I only allowed up to level 2. Unfortunately I did a timeshift snapshot only after the updates and the snapshot before that is in july before I upgraded to Mint 19.2. I don't think this would have happened if the levels were still available. I know I should have done the snapshot before the update but that means making a snapshot nearly every day because I receive updates nearly every day. So there is a lot more system maintenance now without update levels.

You need just one Timeshift snapshot of a system that works well. Even if it's more than a year old, that doesn't really matter.

In case of problems you can simply restore that snapshot, and disable the usual suspects in the list of updates that you get after booting the restored snapshot. Kernel, firmware, stuff like that.

[halregen]

My problem with resume from sleep was solved in another thread:
viewtopic.php?f=47&t=299842
Thanks for the advice though.