now apper is disabled on my set up
it is way TOO much like “windows update” ( do get me started on that )
i like to know WHEN and WHAT is being updated !
That way it i am in the middle of a big project i can WAIT until i am done with the project if it might mess things up
By default, Apper isn’t set to automatically run the updates, unlike Windows, and also unlike Windows, openSUSE Linux does not nag you, trying to convince you your system is not properly protected if you don’t have it set to automatic updating; If yours was set to automatic update, it would have to be because you changed it to that.
Instead, by default, it just displays notices that there are updates. When you go to apply them, you get the list of updates, and can then scan through that list and make your decisions. You can deselect one update, or choose not to apply any of them at that time, so you get decide what gets updated and when.
So, if you don’t know WHEN and WHAT is being updated, it is your fault, not Apper’s.
On 2014-02-03 08:46, brickheap wrote:
> Hey Carlos. Here’s the output. It wrapped around even though it wasn’t
> originally. Any way to get a L->R scroll bar along the bottom?
It got fine here, thanks.
The list is fine, no problems that I can see.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2014-02-03 08:06, brickheap wrote:
> Ok. Thanks for the added level of understanding. A layer of the onion
> has been peeled back.
> If grub2 is corrupted then it should still be in the corrupted state it
> was left in. Because, when I utilized a 3rd party tool to repair grub
> it chose to fix the grub of Lubuntu, rather than the grub2 of openSuSe,
> even though openSuSE’s bootloader was previously the “active” one. Now,
> Lubuntu’s grub is the active one.
That might be the cause of the problem: you have two grubs fighting to
be the boss.
Maybe grub update replaced someparts, conflicting with the previous
install from the other system, rendering it unworkable.
Just a guess.
I think it is preferable to have only one grub configured to install on
the MBR, and the other should be configured to be installed on the root
partition only.
Then the first grub can chainload the second grub, or have entries to
directly boot the kernel of the second install.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
On 2014-02-03 13:46, arvidjaar wrote:
>
> brickheap;2621674 Wrote:
>>
>> contents of /etc/default/grub_installdevice :
>
> That looks OK as long as device name is correct (i.e. you did not change
> HDD in between).
And MBR be generic code. I think.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
When I posted from the openSuSE 13.1 box, there was only a T->B scrollbar in Firefox.
On my Win7 PC, there is a T->B scrollbar AND a L->R scrollbar in the Chrome browser.
Now back on the OS13.1 box, again the L->R scrollbar is absent.
(I guess that beckons a new thread - chuckle)
I thought about that, but then I was careful not to boot into Lubuntu prior to my original post for that very reason.
When I installed OS13.1 , GRUB2 was installed on the root partition, not the MBR. (because I read in a forum that it’s not good to install it there).
When I installed Lubuntu, I wasn’t given an option to choose where to install Grub 1.99, it simply installed it on the MBR.
Lubuntu effectively took control of the boot away from OS13.1.
That would have been OK, except for the fact that the boot menu was difficult to read, and I wanted OS13.1 GRUB2 back in the drivers seat.
Back in Dec. '13 I posted a thread about this, and was shown how to backup the MBR and then restore it, in order to give control of the boot back to OS13.1. This worked.
However, every time there’s a significant update to Lubuntu, it takes the bootloader control back, and I have to go thru this exercise again to give it back to openSuSE.
Prior to my original post here, I didn’t boot into Lubuntu. I booted into OS13.1, and ran the ill-fated update… (which I will post later, as I found something in the zypper history file).
Graphics card? No. Only Integrated Intel graphics.
It’s a very good idea to know what’s being installed, when you know what you are looking at.
This is a fresh install , less than 4 weeks old.
On any new install there are going to be updates that need to be run to make the distro current.
In a Debian LTS install , there were 650+ updates to make it current. On Linux Mint LTS, over 400. (Both worked without a hitch). It would be difficult to fathom that someone installing a new Linux distro would know what each of the several hundred updates specifically does.
I also have to point out, that a glaring bug in Apper, is the inablilty to get any useful information from clicking on the “+” to obtain a description so that one would know what’s being updated. On each item appearing in the pop-up box above the “bug” icon. the “+” displayed the message “Failed to get update details” and a big red “X”. The update icons were either yellow “!” or red “X”, which, without a key or legend are utterly meaningless.
Moving right along…
I was very interested in your suggestion to look a the zypper log and history files.
"/var/log/zypper.log" – appears to be only current for today. There is no past history to reference. I find this interesting because I didn’t initiate any updates.
I can only imagine that this is a log of attempts made by zypper to poll for available updates.(?)
"/var/log/zypp/history" - is another story. It is rich with history, back to the initial installation. **I DID find a reference to a ZYPPER update immediately preceeding a non-bootable system (2/1/14). I also saw a reference to a GRUB2 update shortly thereafter. **
(This file was immense. I didn’t know at what point to cut/paste, so I chose to start at a kernel image heading. I removed the hexidecimal strings following each update, for readability. At the very bottom I cut it off just after the reference to GRUB2.)
Here is what I found in “/var/log/zypp/history” (scoll to bottom) :
Could this be some kind of indicator that either the zypper and/or GRUB2 updates are the culprit? or why my zypper.log file starts on 2/3/14 with no prior history?
As an aside, I am going to take the advice of disabling/removing Apper and using Zypper instead. Although Apper is not likely the reason my system tanked,
it lulled me into a sense of false security, much like Windows Update did in 1998. It took a year or so to learn what really was/wasn’t a necessary update.
I never used the Automatic Updates after that. (Nor, did I enable automatic updates for Apper, as someone erroneously assumed in a prior reply. I simply ran it.)
If updating your system with Apper fails, don’t panic there are several alternatives. Try updating your system with YaST Online Update or YaST Software Management instead or using zypper in a root terminal:
To update all packages:
zypper update
To install official patches only:
zypper patch
and…
Removing Apper Completely
If Apper is causing you problems and you’d rather get rid of it completely, remove the package PackageKit and the packages which depend on it with YaST or zypper
**zypper remove PackageKit
**Afterwards reboot your system, and neither Apper nor PackageKit will bother you again.
> 2014-02-02 23:54:03|install|grub2|2.00-39.8.1|i586||repo-update|
> …
> --------------------
>
>
>
> Could this be some kind of indicator that either the zypper and/or GRUB2
> updates are the culprit?
Well, grub was upgraded, and your grub configuration is not standard,
per your other post. Originally, the system was installed with grub on a
partition, and you reinstalled grub on the mbr, I understand. But do the
files in the system know this? Will they reinstall grub in the new
place, or the old place?
> or why my zypper.log file starts on 2/3/14 with
> no prior history?
What about the “/var/log/zypper.log-DATE.bz2” files? Logs are rotated,
you know.
–
Cheers / Saludos,
Carlos E. R.
(from 12.3 x86_64 “Dartmouth” at Telcontar)
That’s because PackageKit shuts itself down after some idle time.
Normally it does this after 5 minutes, but on openSUSE that default has been changed to 15s, to not block YaST/zypper for too long.
So, this only works for 15 seconds. (if you show one update detail, you have another 15s )
After that you would have to click on “Search for new updates” to make it work again for another 15s.
The color of the update icons indicate their priority.
Red means impoartant/security patch, yellow recommended, and green are normal package updates.
Could this be some kind of indicator that either the zypper and/or GRUB2 updates are the culprit? or why my zypper.log file starts on 2/3/14 with no prior history?
The log file is rotated. You should have some more history-xxxxx files as well, compressed.
But yes, the grub2 update is the most likely “culprit” I’d say, since it reinstalls the boot loader obviously.
:good: - That’s the answer ! - crowd roars in background
My system DOESN’T know! It will install Grub2 in the OLD place, not the NEW place.
This all makes sense now.
Grub2 is originally installed in ROOT partition.
Lubuntu comes along and bulldozes over Grub2 by installing Grub 1.99 into the MBR, leaving Grub2 intact but disempowered.
Then I come along and manually restore the MBR with Grub2 and everything works (for a while) until…
Lubuntu updates Grub 1.99 , and overthrows Grub2 once again.
… and I repeat step 3
(meanwhile, all interim updates of both distro’s go smoothly) until OS13.1 decides it’s time to update Grub2.
OS13.1 updates Grub2 , but since YaST Boot Loader still says “Boot from Root Partition” it installs Grub2 THERE and NOT the MBR.
So I’m left WITHOUT A BOOTLOADER.
Way to go Sherlock!
So, in YaST, should I “Boot from MBR” on the first screen, and/or “Write generic code to MBR” on the 2nd screen (Boot Loader options)?
(I know this won’t prevent Lubuntu from doing this again (until I can figure out how to disable it), but at least when I restore Grub2 next time, OS13.1 will know where to install it after an update.)
Thanks again Carlos.
What about the “/var/log/zypper.log-DATE.bz2” files? Logs are rotated,
you know.
IMO you need to pick one OS to control the boot and do not let any other do a thing about booting. Unless Windows is involved or a UEFI BIOS I always install grub to the MBR.
There is no RIGHT way it all depends on your wants and needs.
Oh, that is funky. Even more of a reason to remove it.
IMHO, something like that really has no place in a distro as part of a standard install. It should be optional.
Anyone coming from another OS would consider that “broken”.
First impressions of a new & different OS REALLY matter!
New users seeing that are likely to wonder “What else is broken if something this fundamental is?”, or question the quality of the download, the DVD burn, or a bad internet connection.
You figure, something that has made it to production has undergone rigorous testing and QA before being released, or at the very least question the robustness and reliability of an applications “readiness” for release.
This business of “let’s throw it against the wall, and see if it sticks” when it comes to software, to me, is haphazard.
I spent years programming for a financial company that traded stock portfolios real-time. We HAD to have zero tolerance for even the slightest hint of an error, otherwise the results would have been catastrophic. We had parallel offline systems that we used for testing, throwing every imaginable wrench into the gears to TRY and break it.
I was in a similar development environment when I wrote software that controlled assembly line “robots” for manufacturing.
This probably explains my intolerance to “perceptively defective” software. I just consider it laziness, or lack of thorough testing. Rarely did our QA team find anything we missed in testing.
It might be one thing, if something slips through the cracks that is obscure or rarely used, but something so conspicuous as a desktop app that controls updating where you need a stopwatch? No.
Linux in general is all about attraction vs promotion when it comes to growing a user base.
I see something like this as a deterrent. I don’t understand why someone in the dev. teams doesn’t recognize this or speak up. I know I’m not alone on this train of thought.
And, this isn’t limited to any particular distro. An bug appears in Ubuntu, and it trickles down to most of the *buntu-family. This is why I try to stick to LTS and Independent distros.
(jumping of soapbbox)
Speaking of laziness, I was wondering where you found the info on the red/yellow/green icons? I Googled & Googled and found nothing. Could you post a link, if you have one?
…and a big “thank you” for the info. I don’t think I’d have discovered the “15 second rule” anytime soon.
I’d like to thank EVERYONE for contributing their knowledge and expertise to help me solve this most aggravating problem.
I’ve learned quite a bit that I can add to my “knowledge base”.
I hope to some day reach a place where I can pay it forward.
One of the things about this forum, in comparison to others, is the depth of knowledge and the willingness to assist.
And for that I am grateful.
Looks like I get the chance to be the first to say You Are Very Welcome!
And, you have already begun to “pay it forward” just by posting your problem, interacting with the other forum members through the process to its solution, and then providing what turned out to be your solution.
Others with the same type of problem will be able to solve it or get on the right track, thanks to your thread. Others without the problem, but who follow the thread, will learn a few valuable things, and even those of us who contributed most likely learned a few things of one sort or another.
Well, apparently nobody (except openSUSE users ) noticed that because of PackageKit’s default timeout of 5 minutes.
I am not aware of any upstream bug report about this either (there is one in the openSUSE bugtracker: https://bugzilla.novell.com/show_bug.cgi?id=855993).
It could maybe also be a bug in the zypp backend, so openSUSE specific.
I’m intending to investigate this issue, but haven’t found the time yet.
)
