Page 3 of 5 FirstFirst 12345 LastLast
Results 21 to 30 of 42

Thread: Another "surprise" from apper update! - An unbootable system!!

  1. #21
    Join Date
    Dec 2013
    Location
    VA, USA
    Posts
    33

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    Quote Originally Posted by robin_listas View Post
    On 2014-02-02 15:06, Knurpht wrote:

    <snipped by brickheap>

    It would also be interesting to learn what repositories brickheap is
    using. Ie, the output of "zypper lr --details".

    And please do so inside code tags (the '#' button in the forum editor).
    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?


    Code:
    linux-oucb:~ # zypper lr --details
    # | Alias                     | Name                               | Enabled | Refresh | Priority | Type   | URI                                                                  | Service                                                  
    --+---------------------------+------------------------------------+---------+---------+----------+--------+----------------------------------------------------------------------+--------                                                  
    1 | openSUSE-13.1-1.10        | openSUSE-13.1-1.10                 | Yes     | No      |   99     | yast2  | cd:///?devices=/dev/disk/by-id/ata-DVD-ROM_DDU1621,/dev/sr0,/dev/sr1 |                                                          
    2 | repo-debug                | openSUSE-13.1-Debug                | No      | Yes     |   99     | NONE   | http://download.opensuse.org/debug/d...13.1/repo/oss/       |                                                          
    3 | repo-debug-update         | openSUSE-13.1-Update-Debug         | No      | Yes     |   99     | NONE   | http://download.opensuse.org/debug/update/13.1/                      |                                                          
    4 | repo-debug-update-non-oss | openSUSE-13.1-Update-Debug-Non-Oss | No      | Yes     |   99     | NONE   | http://download.opensuse.org/debug/update/13.1-non-oss/              |                                                          
    5 | repo-non-oss              | openSUSE-13.1-Non-Oss              | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distrib.../repo/non-oss/         |                                                          
    6 | repo-oss                  | openSUSE-13.1-Oss                  | Yes     | Yes     |   99     | yast2  | http://download.opensuse.org/distrib...13.1/repo/oss/             |                                                          
    7 | repo-source               | openSUSE-13.1-Source               | No      | Yes     |   99     | NONE   | http://download.opensuse.org/source/...13.1/repo/oss/      |                                                          
    8 | repo-update               | openSUSE-13.1-Update               | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/13.1/                            |                                                          
    9 | repo-update-non-oss       | openSUSE-13.1-Update-Non-Oss       | Yes     | Yes     |   99     | rpm-md | http://download.opensuse.org/update/13.1-non-oss/                    |                                                          
    linux-oucb:~ #

    Thanks.
    brickheap.

  2. #22

    Default Re: Apper is an annoyance to me

    Quote Originally Posted by brickheap View Post
    Looking at the Boot Loader in YaST , the only thing I question is the code inserted under

    "Optional Kernel Command Line Parameter"
    Code:
    resume=/dev/disk/by-id/ata-Maxtor_6E030L0_E162JZAE-part1 splash=silent quiet showopts
    If "-part1" references the 1st phsyical partition, then it's wrong, because the 1st partition is the swap partition.
    (some 1st partitions start at zero, in which case the 2nd would be 1). I don't know how openSuSE/Boot Loader labels these.
    The boot should be the 2nd partition as shown below, using fdisk.
    No.
    That is the partition used for hibernate/resume (it is the "resume=" option), and that has to be the swap partition.
    So that's ok.

  3. #23
    Join Date
    Sep 2012
    Posts
    4,977

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    Quote Originally Posted by brickheap View Post
    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).

  4. #24
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    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)

  5. #25
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    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)

  6. #26
    Join Date
    Feb 2009
    Location
    Spain
    Posts
    25,547

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    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)

  7. #27
    Join Date
    Dec 2013
    Location
    VA, USA
    Posts
    33

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    Quote Originally Posted by robin_listas View Post
    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)
    That's interesting.

    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*)

    Brickheap.

  8. #28
    Join Date
    Dec 2013
    Location
    VA, USA
    Posts
    33

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    Quote Originally Posted by robin_listas View Post
    On 2014-02-03 08:06, brickheap wrote:

    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.
    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).

    Thanks,
    Brickheap.

  9. #29
    Join Date
    Dec 2013
    Location
    VA, USA
    Posts
    33

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    Quote Originally Posted by JohnVV View Post
    without knowing just what had a update ......
    It could be anything

    for example :

    I am using the current NVIDIA.run driver
    if there was to be a kernel update then i would ONLY get a text only boot

    the same applies for the ATI/AMD.bin driver

    it is a GOOD idea to KNOW , YES KNOW what is being INSTALLED .

    the typical linux user is not a lemming ( 1985 apple ad ) .

    have a read through the end of
    "/var/log/zypper.log"
    and
    "/var/log/zypp/history"


    that "black" screen could be the ATI card ?
    that is if you have a ati 3d card ?


    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


    Now most of the third party repos i do not have much problems with
    -- BUT i do set the priorities !!!! ( just like i do with rhel and "yum-priorities" )
    (backtracking to an earlier posting...)

    Very true. The updates could be anything.

    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) :

    Code:
    # Kernel image:   /boot/vmlinuz-3.11.6-4-pae
    # Initrd image:   /boot/initrd-3.11.6-4-pae
    # KMS drivers:     radeon
    # Root device:    /dev/disk/by-id/ata-Maxtor_6E030L0_E162JZAE-part2 (/dev/sda2) (mounted on / as ext4)
    # Microcode: Adding Intel microcode 0f-02-04
    # Kernel Modules:    thermal_sys thermal processor fan scsi_dh scsi_dh_emc scsi_dh_hp_sw scsi_dh_rdac scsi_dh_alua i2c-algo-bit drm drm_kms_helper ttm radeon ata_piix usb-common usbcore ohci-hcd uhci-hcd ehci-hcd xhci-hcd usbhid hid-logitech-dj hid-generic hid-holtek-kbd hid-lenovo-tpkbd hid-ortek hid-roccat hid-roccat-common hid-roccat-arvo hid-roccat-isku hid-samsung ehci-pci ohci-pci
    # Firmware:    radeon/R520_cp.bin radeon/RS600_cp.bin radeon/RS690_cp.bin radeon/R420_cp.bin radeon/R300_cp.bin radeon/R200_cp.bin radeon/R100_cp.bin radeon/SUMO2_me.bin radeon/SUMO2_pfp.bin radeon/SUMO_me.bin radeon/SUMO_pfp.bin radeon/SUMO_rlc.bin radeon/PALM_me.bin radeon/PALM_pfp.bin radeon/CYPRESS_smc.bin radeon/CYPRESS_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/JUNIPER_smc.bin radeon/JUNIPER_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/REDWOOD_smc.bin radeon/REDWOOD_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/CEDAR_smc.bin radeon/CEDAR_rlc.bin radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/R700_rlc.bin radeon/R600_rlc.bin radeon/RV710_smc.bin radeon/RV710_me.bin radeon/RV710_pfp.bin radeon/RV740_smc.bin radeon/RV730_smc.bin radeon/RV730_me.bin radeon/RV730_pfp.bin radeon/RV770_smc.bin radeon/RV770_me.bin radeon/RV770_pfp.bin radeon/RS780_me.bin radeon/RS780_pfp.bin radeon/RV670_me.bin radeon/RV670_pfp.bin radeon/RV635_me.bin radeon/RV635_pfp.bin radeon/RV620_me.bin radeon/RV620_pfp.bin radeon/RV630_me.bin radeon/RV630_pfp.bin radeon/RV610_me.bin radeon/RV610_pfp.bin radeon/R600_me.bin radeon/R600_pfp.bin radeon/ARUBA_rlc.bin radeon/ARUBA_me.bin radeon/ARUBA_pfp.bin radeon/CAYMAN_smc.bin radeon/CAYMAN_rlc.bin radeon/CAYMAN_mc.bin radeon/CAYMAN_me.bin radeon/CAYMAN_pfp.bin radeon/CAICOS_smc.bin radeon/CAICOS_mc.bin radeon/CAICOS_me.bin radeon/CAICOS_pfp.bin radeon/TURKS_smc.bin radeon/TURKS_mc.bin radeon/TURKS_me.bin radeon/TURKS_pfp.bin radeon/BTC_rlc.bin radeon/BARTS_smc.bin radeon/BARTS_mc.bin radeon/BARTS_me.bin radeon/BARTS_pfp.bin radeon/HAINAN_smc.bin radeon/HAINAN_rlc.bin radeon/HAINAN_mc.bin radeon/HAINAN_ce.bin radeon/HAINAN_me.bin radeon/HAINAN_pfp.bin radeon/OLAND_smc.bin radeon/OLAND_rlc.bin radeon/OLAND_mc.bin radeon/OLAND_ce.bin radeon/OLAND_me.bin radeon/OLAND_pfp.bin radeon/VERDE_smc.bin radeon/VERDE_rlc.bin radeon/VERDE_mc.bin radeon/VERDE_ce.bin radeon/VERDE_me.bin radeon/VERDE_pfp.bin radeon/PITCAIRN_smc.bin radeon/PITCAIRN_rlc.bin radeon/PITCAIRN_mc.bin radeon/PITCAIRN_ce.bin radeon/PITCAIRN_me.bin radeon/PITCAIRN_pfp.bin radeon/TAHITI_smc.bin radeon/TAHITI_rlc.bin radeon/TAHITI_mc.bin radeon/TAHITI_ce.bin radeon/TAHITI_me.bin radeon/TAHITI_pfp.bin radeon/BONAIRE_uvd.bin radeon/TAHITI_uvd.bin radeon/SUMO_uvd.bin radeon/CYPRESS_uvd.bin radeon/RV710_uvd.bin radeon/KABINI_sdma.bin radeon/KABINI_rlc.bin radeon/KABINI_mec.bin radeon/KABINI_ce.bin radeon/KABINI_me.bin radeon/KABINI_pfp.bin radeon/BONAIRE_sdma.bin radeon/BONAIRE_rlc.bin radeon/BONAIRE_mc.bin radeon/BONAIRE_mec.bin radeon/BONAIRE_ce.bin radeon/BONAIRE_me.bin radeon/BONAIRE_pfp.bin
    # Features:       acpi intel_microcode kms plymouth block usb resume.userspace resume.kernel
    #
    2013-12-30 03:34:36|install|ucode-intel|20130906-6.2|i586|root@linux-oucb|repo-update|
    2014-01-06 01:40:57|install|libopenssl1_0_0|1.0.1e-11.10.1|i586||repo-update|
    2014-01-06 01:41:00|install|libpixman-1-0|0.30.2-2.5.1|i586||repo-update|
    2014-01-06 01:41:03|install|openssl|1.0.1e-11.10.1|i586||repo-update|
    2014-02-01 22:01:22|install|libzypp|13.9.0-10.1|i586||repo-update|
    2014-02-01 22:01:23|install|zypper-aptitude|1.9.10-12.1|noarch||repo-update|
    2014-02-01 22:01:23|install|zypper-log|1.9.10-12.1|noarch||repo-update|
    2014-02-01 22:01:26|install|zypper|1.9.10-12.1|i586||repo-update|
    2014-02-02 23:53:58|install|coreutils|8.21-7.12.1|i586||repo-update|
    2014-02-02 23:53:58|install|dbus-1-x11|1.7.4-4.8.2|i586||repo-update|
    2014-02-02 23:53:58|install|gdk-pixbuf-query-loaders|2.30.1-20.1|i586||repo-update|
    2014-02-02 23:53:59|install|glibc-extra|2.18-4.11.1|i586||repo-update|
    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? or why my zypper.log file starts on 2/3/14 with no prior history?

    Thanks,
    Brickheap.

  10. #30
    Join Date
    Dec 2013
    Location
    VA, USA
    Posts
    33

    Default Re: Another "surprise" from apper update! - An unbootable system!!

    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.)


    I found several more useful links to that end : http://en.opensuse.org/Apper
    which contains:

    Updating Fails

    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.
    This is handy too: http://en.opensuse.org/images/1/17/Z...at-sheet-1.pdf

    Brickheap.

Page 3 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •