Unnecessary critical updates showing up in "Software Update" ?

English Applications
1

Ok, I don’t get this…

I log in and I have a popup screen with “Security/Critical” updates before me.

Unlike most former Windoze zombies who have auto-updates set and then let them install w/o looking them over, I do it manually and pick the ones I know I need and hide/ignore the rest. (At least the updates that appear are pertinent to my OS, hardware, and software).

Because I’m less familiar with Linux updates, I take a quick look and just let things update. They are typically relevant to my system configuration.

So, I was just going to “let her rip” until I saw one that caught my eye as being totally irrelevant :

" glibc: Two ARMv7 related fixes 7.9 MB

  • Details:*
    This update is important and may solve critical problems
    This update fixes the following issues with glibc: "     
  • 1. yada yada...
    1. yada yada…

***I don’t have an ARM processor in my PC ! Why am I getting this update ??

**I’ve never known Linux to just arbitrarily install unnecessary updates… although it does sometimes install “suggested packages” if you’re not careful. But that’s a whole different matter.

  • Could it be because I have glibc installed and it’s blindly updating everything related to it?

Any insights into this?

Thanks,
Brick.

2

Maybe you might want to compile some arm code. the gcc and thus glibc supports multiple architectures

So maybe you don’t need that I know I don’t but others may. But glibc is very basic to the system and it is always good to have it fully patched. You only get updates for thing that you have installed. Unlike Windows that may install arbitrary code.

3

In any case, when there is a next security patch for glibc that is applicable for your hardware, it will contain this patch also. So you will get it then.

4

Thanks for your replies.

I feel that unless these patches are necessary, they shouldn’t be installed automagically.
If only, say 10% of people use tools directly aimed at ARM processors, then they should be optional packages
much like the barry-* packages I used for my old Blackberry phone. (But, I’m making some big assumptions here as to their necessity).

The issue is disk space on the test machine I’m using. It went from 56% full to 72% after the last update.
My goal is to install openSuSE along side Win7 on my main rig, then after awhile, get rid of Win7. I just don’t want to install a whole bunch of extra bloat in the process, if that can be avoided.

***** The software updater seems to have some major issues with it.**
I deselected the ARMv7 updates and clicked “Install”
It sat for 2 hrs, attempting to d/l only 5 MB of updates, with the CPU running at 90%.
The process that was using all the CPU time was: **GTK+something-view-**something

The GUI showed only half of the updates had been d/l’d , but evidently, it d/l’d all but the ARMv7.
It never finished and I aborted it. It did install a bunch of updates, but when I rebooted the darn ARMv7 update appeared again (much like hcvv indicated in his reply).

It seems that the updater intends to install say, 10 updates. However, during the update it drags in a whole bunch of new downloads, along with dependencies, that wind up filling up my disk.

  • This kind of thing didn’t used to happen unless I selected a new package to install. (At least in SuSE 8 and SuSE 11).

True, I haven’t tinkered with SuSE since 2010, but is this really the “new normal” now? (looking for a sanity check).

**1. Are the ARMv7 updates really necessary?
2. Am I going to have to sit and monitor all my updates in the future to avoid installing unwanted/unneeded software?
**
Brick.

5

My assumption: they changed the code to handle a problem for ARM. And then they recompiled for all processors.

Probably a harmless update, and perhaps not important for non-ARM.

6

You are probably using “btrfs”. Don’t do that on a system where disk space is tight.

7

Well you don’t HAVE to take it. But for at least the glibc library it is the foundation of all c and c++ so is a defint requirement to have. But the gcc compiler supports multiple architectures so some functions for arm or possibly other CPUs are in the basic library. but if you ignore the update at some point things might beak and if you do get a more general fix for glibc .you will get this stuff anyway.

new stuff might have new dependencies. What can I say??? If you are really that tight on space maybe you need to rethink you partitioning.

Can’t speak to th time it took does sound excessive. But I guess you are using apper and it really is not the best updater. I use zypper up or yast

Seems a little hard headed on your part not to accept an update to such a basic part of the OS but it is your machine. And if you continue updates you will eventually get those patches anyway next time glibc has say a security update. So I really don’t understand your point.

8

Also you can black list a package in yast or zypper so it no longer updates. But I very very highly recommend you take glibc it is fundamental you don’t want bugs or security problem there.

9

On 2013-12-19 20:46, brickheap wrote:

> The issue is disk space on the -test machine- I’m using. It went from
> 56% full to 72% after the last update.

Are you using btrfs partitions?

Either your test setup is too small, or you are using btrfs. The final
disk usage should be about the same.

> I deselected the ARMv7 updates and clicked “Install”
> It sat for 2 hrs, attempting to d/l only 5 MB of updates, with the CPU
> running at 90%.

Well, you have some other problem, which is not related to selecting a
partial update.

> It never finished and I aborted it. It did install a bunch of updates,
> but when I rebooted the darn ARMv7 update appeared again (much like hcvv
> indicated in his reply).

If you want some update not to be ever selected, you have to taboo it.

> It seems that the updater intends to install say, 10 updates. However,
> during the update it drags in a whole bunch of new downloads, along with
> -dependencies-, that wind up filling up my disk.

Wait. What you see is a number of patches. Each patch can contain
several packages that are downloaded separately. Perhaps you are using
the GTK yast flavour, so you do not see this clearly. At least in the QT
flavour there is a summary screen where you can see every selected package.

> *1. Are the ARMv7 updates really necessary?

I don’t know. I don’t care. I install it. >:-)

> 2. Am I going to have to sit and monitor all my updates in the future to
> avoid installing unwanted/unneeded software?

Yes.

> *
> Brick.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

10

On Thu, 19 Dec 2013 19:46:02 +0000, brickheap wrote:

> I feel that unless these patches are necessary, they shouldn’t be
> installed automagically.
> If only, say 10% of people use tools directly aimed at ARM processors,
> then they should be optional packages much like the barry-* packages I
> used for my old Blackberry phone. (But,
> I’m making some big assumptions here as to their necessity).

It’s also possible that the fix is in the ARM version of the library, but
the build service automatically rebuilt everything for all platforms (as
it will tend to do), so an update got pushed out that contains no code
changes for your particular platform. The comment applies just to the
ARM libraries.

There’s really no way to know how many people need an update like that
(if it is a cross-compilation issue). As others said, glibc is a pretty
important library, and if it were me, I’d install it, even if I didn’t
think that it applied directly to me (as I don’t currently do ARM
development).

If I ended up doing something that required that update and I didn’t have
it, I might spend hours or days trying to figure out why something wasn’t
working, only to discover that if I had applied the update, I wouldn’t
have had the issue.

There may be other circumstances when such an update would apply, even if
you aren’t a developer.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

11

On 2013-12-19 21:08, Carlos E. R. wrote:
> On 2013-12-19 20:46, brickheap wrote:
>
>> The issue is disk space on the -test machine- I’m using. It went from
>> 56% full to 72% after the last update.
>
> Are you using btrfs partitions?
>
> Either your test setup is too small, or you are using btrfs. The final
> disk usage should be about the same.

Mmmm. I didn’t write it well. I meant that the final disk usage after a
“mandatory update” is about the same, because the old package and the
new replacement typically have the same size.

However, btrfs automatically saves both copies, that’s a feature.

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

12

You should allow at least 2X the space you think you need if you use BTRFS with snapper on.

Unless you just want to experiment I would recommend you stick with ext4. I have seen several reports here of systems with apparently failed BTRFS partitions with no real way to recover. ie fsck did not work. .

13

On Fri, 20 Dec 2013 04:56:02 +0000, gogalthorp wrote:

> You should allow at least 2X the space you think you need if you use
> BTRFS with snapper on.
>
> Unless you just want to experiment I would recommend you stick with
> ext4. I have seen several reports here of systems with apparently failed
> BTRFS partitions with no real way to recover. ie fsck did not work. .

There was a very long discussion in the beta group about this - btrfs is
much better now than it used to be, and recovery is not necessary very
often. The discussion came up because the developers working on btrfs
for openSUSE feel that there’s a set of features that /is/ stable enough
for production use. (and the intention, if btrfs had been selected as
default, was to use only those features deemed production-ready).

It’s important to remember that anecdotal evidence is not data - and the
data around btrfs seems to say that it is production ready, at least with
a subset of features.

See the thread in the beta group for more info, including discussion from
one of the developers.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

14

On 2013-12-20 06:08, Jim Henderson wrote:
> It’s important to remember that anecdotal evidence is not data - and the
> data around btrfs seems to say that it is production ready, at least with
> a subset of features.

I know how to reliably crash an btrfs filesystem beyond repair… >:-)

–
Cheers / Saludos,

Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)

15

LOL.

Even without that, I wouldn’t use “btrfs”. Yes, it has nice features, but you have to do too much work to use them.

Maybe it will one day be better integrated. For example, maybe all updating will be made to a snapshot, instead of to the running system, and the snapshot will become the running system after reboot. And maybe it will become possible to install the next version to a snapshot, which becomes available on reboot.

There are lots of possibilities. But they require changes outside of “btrfs”. Until some of those changes are in place, there is little benefit for the average user to go with “btrfs” (in my opinion).

16

On Fri, 20 Dec 2013 11:43:08 +0000, Carlos E. R. wrote:

> On 2013-12-20 06:08, Jim Henderson wrote:
>> It’s important to remember that anecdotal evidence is not data - and
>> the data around btrfs seems to say that it is production ready, at
>> least with a subset of features.
>
> I know how to reliably crash an btrfs filesystem beyond repair… >:-)

Good for you…I guess. I can reliably crash any filesystem with dd.
[shrug]

Have you submitted it as a bug? Seems like something someone might want
to fix.

Jim

–
Jim Henderson
openSUSE Forums Administrator
Forum Use Terms & Conditions at http://tinyurl.com/openSUSE-T-C

17

**I’ll try to answer all replies in one posting.
**
Thanks for your replies. *(I didn’t realize my 2nd post , #4, went thru, due to tech. errors, so I didn’t check back).
*Your responses were very informative, particularly #10 (hendersj), which elaborates on some of the other postings related to the importance of glibc and keeping it updated. As a former software developer that makes sense.

  • I’m not familiar with zypper. I’ll have to check it out. It’s probably easy to understand that I’m not yet aware of all the different choices I have available to do updates. Seeing the screen screaming at me to do “important updates” compels me to just do it (memories of Windows OS “forced” compliance creeping back).

  • It’s good to know that updates will not significantly affect disk space.

  • I’m using the EXT4 file system exclusively.

  • The partition I’m using is small. (10 GB for the “/” and 10 GB for “/home”, of a 40 GB HDD). (this is a test system I’m using to refamiliarize myself with SuSE before I go and install it on my main rig).
    It’s also easier to detect disk usage on a small HDD than a 1TB HDD.

  • My original posting came from a concern I have regarding a complete and total abandonment of Windows.
    Having seen most of my PC’s suffer from increasing and crippling bloat of Win XP service packs (particularly SP3!, security updates, .NET runtimes, etc. has made me very cautious about the updates in Linux.
    Just looking to avoid “trading a $1 bill for 4 quarters”.

I’m trying to gauge the performance of SuSE on 1 of my most resource limited machines to predict the performance on those with more resources. So far, so good. I’ll obviously be using the entire HDD , not just a partition.

Most of my dozen or so PC’s have volume licenses of Win XP on them, which will soon be obsolete,
and I won’t fall prey to replacing hardware just to accommodate Win 8. (clever collaborative marketing scheme). I have Win7 on 1 machine, which is enough.

That being said, I was drawn back to SuSE by tinkering with the 11.0 on my P3-1000 (which runs incredibly well, even with KDE!). This was probably a mistake, because I’ve noticed that a LOT has changed in 5 years with SuSE 13.1, and I’m just trying to get myself familiar and up to speed with these changes.
As I get “down and dirty” with it, I realize I have a long way to go.

So once again,
Thanks for** all** of your input!
I know I’ll be back again with more questions :wink:

Brick.

18

Apart from trying to get used to openSUSE and to get rid of what you know about Windows (it helps enormously when you erase all Windows knowledge and habits from your mind ;)), als get used to the fact that these forums are about openSUSE. All other ways of spelling it are either outdated, or may even confuse people thinking you use with SUSE Linux SLES/SLED.

19

On 2013-12-20 18:37, Jim Henderson wrote:
> On Fri, 20 Dec 2013 11:43:08 +0000, Carlos E. R. wrote:
>
>> On 2013-12-20 06:08, Jim Henderson wrote:
>>> It’s important to remember that anecdotal evidence is not data - and
>>> the data around btrfs seems to say that it is production ready, at
>>> least with a subset of features.
>>
>> I know how to reliably crash an btrfs filesystem beyond repair… >:-)
>
> Good for you…I guess. I can reliably crash any filesystem with dd.
> [shrug]

No, I don’t mean that type of trick… I simply write normal files in certain fashion.

> Have you submitted it as a bug? Seems like something someone might want
> to fix.

Absolutely. During RC phase. Not solved yet. Bug 846807.

Bugzilla database is down now, by the way:

Software error:

Can’t connect to the database.
Error: Too many connections
Is your database installed and up and running?
Do you have the correct username and password selected in localconfig?

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” (Elessar))