Running zypper dup -l in Leap 15.5 freezes GUI

English Applications
1

https://bugzilla.suse.com/show_bug.cgi?id=1205452

Posting a new thread on the issue reported in the “bluetooth applet thread below” . . . for the second time, running zypper dup -l in console app leaves GUI “frozen” . . . requiring use of power button to shut down. Last week I logged into a TTY to finish the upgrade and shut down . . . this week I just used the power button.

Machine is a '12 Mac Pro . . . multi-boot, with a number of SUSE installs . . . so far the Leap install is the only one that is doing this issue. The others are various TW options, including a couple of Gecko rolling editions . . . .

So far bug report has not garnered a dev response . . . .

2

It’s your call, but personally I never run zypper whilst logged in to any desktop environment. :wink: …

3

@tannington:

The devil is in the details . . . and, yes, usually “pilot error” is at work whenever there is a problem . . . . But, for the “regular” package upgrades that go along with the rolling installs that I have . . . for the most part, no blow back on using zypper in the GUI console for quite awhile.

If it looks like a huge number of packages, or for what might be a new whole distro upgrade, then, right . . . I might go to a TTY . . . .

In this case, Leap . . . not as many package upgrades, didn’t see a kernel upgrade listed . . . there was “firmware” but, in the interest of linux science, I was repeating the moves as I did them last week to test . . . and it repeated.

I’ve got a fair number of linux installs and SUSE installs and largely running zypper in the GUI console is . . . problem free. Now Leap 15.5 doesn’t seem to be behaving well with it.

4

Hi
You should run screen, else drop to a tty…

5

@malcolmlewis:

“run screen”??? that’s the first time I’ve seen that phrase since playing with linux since '07 . . . don’t know what that is . . . .

Last week when I posted my dual issues with the new Leap, including this “GUI freeze” one of the regular gurus here suggested “filing a bug report on it” . . . so I did that . . . . This week you guyz are saying, “Grow up and run zypper in a TTY or . . . a screen . . . .” ?? :o:'(

Many years of running zypper in the GUI without a problem . . . it just makes it all “higher maintenance” . . . .

6

“man screen” is strong stuff. Running “zypper update” as a service is straight forward:

**erlangen:~ #** systemctl cat upd
**# /etc/systemd/system/upd.service**
[Unit] 
Description=Distribution Update 

[Service] 
ExecStart=/usr/bin/zypper --non-interactive update 
**erlangen:~ #**

The service runs in the system slice and will continue whenever the user session crashes. As bonus permanent journal is available.

Booted into leap154, typed, saved, started and succeeded:

**leap154:~ #** systemctl status upd 
○ upd.service - Distribution Update 
     Loaded: loaded (/etc/systemd/system/upd.service; static) 
     Active: inactive (dead) 

Nov 21 18:41:03 leap154 40grub2[10938]: **debug: parsing: search --fs-uuid --no-floppy --set=root --hint-ieee1275='ieee1275//disk@0,gpt9' --hint-bios=hd0,gpt9 --hint-efi=hd0,gpt9 --hint-baremetal=ahci0,gpt9  bf6ba7c9-9068-4a9b-b210-84b6d105df5c**
Nov 21 18:41:03 leap154 40grub2[10939]: **debug: parsing: linux16 /boot/memtest86+/memtest.bin**
Nov 21 18:41:03 leap154 40grub2[10943]: **debug: parsing: }**
Nov 21 18:41:03 leap154 40grub2[10944]: **result: /dev/sdb9:/dev/sdb9:Memory Tester (memtest86+):/boot/memtest86+/memtest.bin::**
Nov 21 18:41:03 leap154 40grub2[10945]: **debug: parsing: fi**
Nov 21 18:41:03 leap154 40grub2[10946]: **debug: parsing: ### END /etc/grub.d/60_memtest86+ ###**
Nov 21 18:41:04 leap154 zypper[2589]: %posttrans script 'grub2-i386-pc-2.06-150400.11.17.1.noarch.rpm' wird ausgeführt .....fertig] 
Nov 21 18:41:05 leap154 zypper[2589]: Es werden Programme ausgeführt, die immer noch die durch kürzliche Upgrades gelöschten oder aktualisierten Dateien oder Bibliotheken verwenden. Starten Sie die Programme neu, um die Aktualisierungen zu nutzen. Mit 'zypper ps -s' er>
Nov 21 18:41:05 leap154 zypper[2589]:   
Nov 21 18:41:05 leap154 systemd[1]: upd.service: Deactivated successfully. 
**leap154:~ #**
7

@karlmistelberger:

. . . “man” again . . . other stuff going on right now, maybe on a “rainy” day in SoCal I’ll have time to read “man” . . . .

And, thanks for the suggestion on the service . . . I set that up in my TW install, but doesn’t actually help me significantly in that I’m running multi-boot on the machine for a few hours in the morning, then shutting down. Next day booting the next system . . . and in order, so that on Monday when I’m back in grub controller I run your suggestion of #update-bootloader to bring everybody up to the newest kernel.

If one of the systems was running the service when I shut down, it’ll resume possibly, but I’d have to check it . . . . It’s cleaner for me to just run the zypper . . . in the GUI, so I can see when it’s done . . . . If I was running the machine 24/7 and one system then the service makes total sense . . . .

8

Don’t worry. Zypper blocks sleep, shutdown and more until done. BTW: All my hosts sleep 24/7 and resume on demand. This works like a charm with all distributions and all hardware unless openSUSE happens to add another wait of 10 seconds with post 5.18.11-1-default kernels.

9

@karlmistelberger:

Cool. I’m not worried . . . I just run zypper . . . in the GUI and then, when I have to go . . . I shut it down, without remorse, concern or worry.

Main point is change in behavior of the Leap system . . . reported in the bug report and now here . . . . The floor is open for questions . . . but shut down will be occurring in a few minutes . . . . After running #update-bootloader . . . .

10

I normally login to Icewm for zypper dup. Before I do that update, I use

screen -L

I have occasionally had the desktop crash during the update. But the update continues because of the “screen”. I wait for it to finish (I run tail -f on the log from “screen -L” to see when it is finished).

11

@nrickert:

Thanks for sharing that info . . . and thanks on the icewm suggestion . . . . Most of my GUI’s I’m either running MATE or XFCE . . . so not exactly resource hogs . . . . I’ll see what happens if I try out “the screen” . . . .

12

You keep confounding yourself. It’s not “the screen”, just “screen”. It refers to a program (/usr/bin/screen), not a device.

13

@kerijan:

That was a little bit of “humor” . . . obviously not appreciated . . . but, sure . . . it’s all about self-confoundation . . . .

14

I’ll just add a comment here.

I updated 15.5 yesterday (with “zypper dup”. It was a relatively small update.

I logged into Icewm for the update, and ran “screen -L” before running “zypper dup”.

All went well. Nothing hung or crashed. After updating, I rebooted and logged into KDE.

15

@nrickert:

Since I was back in Leap 15.5 right now, trying to get a log file attached to the bug report, which keeps failing . . . . I ran your commands in an icewm session and it showed:

# zypper dup -l
Loading repository data...
Warning: Repository 'Update repository of openSUSE Backports' appears to be outdated. Consider using a different mirror or server.
Warning: Repository 'Main Update Repository' appears to be outdated. Consider using a different mirror or server.
Reading installed packages...
Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command.
Computing distribution upgrade...
Nothing to do.

So, this is a relatively new install . . . month or two max . . . already repos are “outdated”?? Did not see this warning the other day, yesterday, when I ran the zypper dup -l . . . but, possibly I missed that?? Or that is only a function of using “screen -L”???

16

Yes, I get those messages. The “update” repo is not used this early in the development, so there’s nothing to update it. I’m not sure what’s up with the main repo, but I’m not concerned about it.

17

@nrickert:

OK, thanks for the reply on it . . . since the system had just been upgraded the day before, “nothing to do,” so . . . couldn’t run a test on extensively using “the screen” . . . . :wink: