operating system updates

Snorkel1 · 07-05-2020, 03:39 PM

hello, I hope everyone is well.
On Lenovo 110, intel core i5 inside I am running Linux Mint 19.1 Cinnamon, 64 bit.
I am just installing updates suggested by the system but after some update the system did not start anymore. I was lucky enough to recover previous version before the update using the function "advanced options for Linux Mint 19.1 Cinnamon". (there were three options when I tried to start my Linux. "Advanced options" was one of them.)
After the recovery I have accepted another "suggested" update and the system is working ok.
Could anybody suggest what to do to avoid such problems in the future?
Are there any particular updates that I would need to avoid?
How can I protect my system ?
Many thanks in advance for your kind response.
Best Regards
Lech

shruggy · 07-05-2020, 04:06 PM

Your description is too vague, so I can only speculate. Selecting the "Advanced options" in boot menu would usually boot you to a previously installed Linux kernel. So the failed update probably installed new kernel.

I don't know how Linux Mint GUI updater handles this, but apt upgrade usually won't upgrade the kernel outright, but suggest you run apt full-upgrade instead. It's always preferable to run the latter from the command line: that way you won't miss any error messages should something have gone wrong. Often, it will even suggest what you can do to fix it.

ondoho · 07-06-2020, 06:56 AM

Quote:

Originally Posted by Snorkel1

After the recovery I have accepted another "suggested" update and the system is working ok.
Could anybody suggest what to do to avoid such problems in the future?
Are there any particular updates that I would need to avoid?

That's the one thing where Linux Mint differs significantly from Ubuntu.
Personally, I don't like it.
Aren't these updates colour coded? You should only do the green ones?!
People here often recommend to do an apt command line upgrade but that overrides the colour coding completely AFAIK.

JeremyBoden · 07-06-2020, 09:12 AM

You can look at the updates, including its purpose etc
For example:- security fix, bug fix, function upgrade...

If you consider a few of the updates are high risk, wait a week or two before accepting them.
Personally, I've never found any problems in using mint or LMDE - I've used them since the first stable release.

rtmistler · 07-06-2020, 09:45 AM

Not any solution, except maybe for my last bullet, but just some thoughts:

I resist updates generally, but do understand that they many times do include critical security improvements.
I try to do them command line, and one at a time, versus using an update manager application.
I find that over time the update list grows a lot and it sometimes seems better to upgrade the whole distro.
Sadly I do not feel that certain distributions such as Mint and Ubuntu have cracked "in place" upgrades to be reliable enough. As a result, I will prepare backup, I'll try them, but I'll be prepared to install the new distro clean with my data backup.
Sometimes they work, sometimes they don't is my opinion and experience. My recommendation is to practice protective actions (as always) when changing your system.

Along with JeremyBoden I regularly do use Mint Debian Edition and I find it to be very stable.

jefro · 07-06-2020, 03:53 PM

I personally endorse all updates however I need to point out the answer to your question. "How can I protect my system ?"

It's called a backup plan. One that has been tested is better.

shruggy · 07-06-2020, 04:03 PM

I also use apt-listdifferences, so when doing an upgrade, sometimes I see:

Code:

diffstat qemu_4.2-3ubuntu6.2 qemu_4.2-3ubuntu6.3

 changelog                                                                     |    9
 patches/lp-1882774-target-i386-do-not-set-unsupported-VMX-secondary-exe.patch |  103 ++++++++++
 patches/series                                                                |    2
 patches/ubuntu/lp-1878973-fix-assert-regression.patch                         |   41 +++
 4 files changed, 155 insertions(+)

diff -Nru qemu-4.2/debian/changelog qemu-4.2/debian/changelog
--- qemu-4.2/debian/changelog   2020-05-27 23:19:20.000000000 +0200
+++ qemu-4.2/debian/changelog   2020-06-02 10:42:49.000000000 +0200
@@ -1,3 +1,12 @@
+qemu (1:4.2-3ubuntu6.3) focal; urgency=medium
+
+  * debian/patches/ubuntu/lp-1878973-*: fix assert in qemu-guest-agent that
+    crashes it on shutdown (LP: #1878973)
+  * d/p/ubuntu/lp-1882774-*: fix issues with VMX subfeatures on systems not
+    supporting to set them (LP: #1882774)
+
+ -- Christian Ehrhardt <christian.ehrhardt@canonical.com>  Tue, 02 Jun 2020 10:42:49 +0200
+
 qemu (1:4.2-3ubuntu6.2) focal; urgency=medium

   * d/p/ubuntu/lp-1805256*: Fixes for QEMU on aarch64 ARM hosts
diff -Nru qemu-4.2/debian/patches/lp-1882774-target-i386-do-not-set-unsupported-VMX-secondary-exe.patch qemu-4.2/deb$
--- qemu-4.2/debian/patches/lp-1882774-target-i386-do-not-set-unsupported-VMX-secondary-exe.patch       1970-01-01 0$
+++ qemu-4.2/debian/patches/lp-1882774-target-i386-do-not-set-unsupported-VMX-secondary-exe.patch       2020-06-02 1$
@@ -0,0 +1,103 @@
+From 4a910e1f6ab4155ec8b24c49b2585cc486916985 Mon Sep 17 00:00:00 2001
+From: Vitaly Kuznetsov <vkuznets@redhat.com>
+Date: Tue, 31 Mar 2020 18:27:52 +0200
+Subject: [PATCH] target/i386: do not set unsupported VMX secondary execution
+ controls
+
+Commit 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for
+secondary execution controls") added a workaround for KVM pre-dating
+commit 6defc591846d ("KVM: nVMX: include conditional controls in /dev/kvm
+KVM_GET_MSRS") which wasn't setting certain available controls. The
+workaround uses generic CPUID feature bits to set missing VMX controls.
+
+It was found that in some cases it is possible to observe hosts which
+have certain CPUID features but lack the corresponding VMX control.
+
+In particular, it was reported that Azure VMs have RDSEED but lack
+VMX_SECONDARY_EXEC_RDSEED_EXITING; attempts to enable this feature
+bit result in QEMU abort.
+
+Resolve the issue but not applying the workaround when we don't have
+to. As there is no good way to find out if KVM has the fix itself, use
+95c5c7c77c ("KVM: nVMX: list VMX MSRs in KVM_GET_MSR_INDEX_LIST") instead
+as these [are supposed to] come together.
+
+Fixes: 048c95163b4 ("target/i386: work around KVM_GET_MSRS bug for secondary execution controls")
+Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
+Message-Id: <20200331162752.1209928-1-vkuznets@redhat.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+
+Backport-Note: MSR_IA32_UCODE_REV didn't exist in qemu 4.2 yet but is in the context
+Origin: backport, https://git.qemu.org/?p=qemu.git;a=commit;h=4a910e1f6ab4155ec8b24c49b2585c
+Bug-Ubuntu: https://bugs.launchpad.net/bugs/1882774
+Last-Update: 2020-06-09
+
+---
+ target/i386/kvm.c | 41 ++++++++++++++++++++++++++---------------
+ 1 file changed, 26 insertions(+), 15 deletions(-)
-- MOST: *stdin*                                                                                         (1,1) 0%
Press `Q' to quit, `H' for help, and SPACE to scroll.