Leap 15.5 not reviving from suspend? No Packman in the repos?

English Applications
#1

Folks:

Have had a recurring issue with Leap 15.5 not reviving from suspend. Previously I thought it had to do with running a zypper dup, but today zypper brought “nothing to do” . . . .

Suspended the machine to have a bite; when I came back hit the shift key, the display power button changed from orange to blue, machine seemed to be “running” but no video?? screen stays black . . . “nothing to see here.”

On another note, tried to check to see if I could now add Packman into the repos, possibly to assist in the “non-revival” issue . . . “mission failed” was the error report on the operation??? Seems like it has been months that 15.5 has been available, but still no Packman??? What beez up?

Already on the factory list serve they are discussing the “what happens after Leap?” issue, but still haven’t gotten 15.5 Packman enabled . . . .

#2

AFAIK, 15.5 is not released. It is only available for testing. Experience shows that the Packman packages for 15.5 will be available at release date or shortly after.

#3

packnman will be there when Leap 15.5 is published and not Alpha/Beta.

#4

Gents:

Thanks for the replies on the Packman issue . . . it’s not “super-critical” to routine use of the machine via Leap.

What IS more critical is this “non-revival” issue. Since I posted this thread I had a few things to do away from the Matrix . . . not wanting to have to restart the machine just to check emails I left it “un-suspended” for like 10 minutes. When I returned, the screen was black . . . “dang it” . . . hit the shift key, and . . . GUI display came back online!!! Clicking on the FireFox tab in the tool bar . . . nothing. Repeated clicks does not drop the browser window into play?? Mouse works, clicked on the Home directory disk in XFCE DE . . . nothing.

Flipped over to TTY4 to try to reboot and login was “unsuccessful”??? Had to hit the power button and . . . cold boot . . . and back into Leap 15.5 to see what my user name is??? The user name and password were rejected by the Shell???

Leap 15.5 was more or less running OK up to last week this time. I boot a different distro each day, same machine, etc.

#5

Open an bugreport on bugzilla, Leap 15.5 is alpha/beta…

#6

Might do that, busy right now . . . I was “testing” the machine to see if it was “hardware” related, because I rebooted into a Gecko Rolling Plasma partition and had the same problem . . . in that case, it wouldn’t fully suspend the machine, just the display went black.

But, now rebooted in Manjaro and I can suspend and revive it.

I’ll check into the bugzilla report later on and I’ll post back with the link.

#7

My experience with pre-release versions, is that the packman repos are not available until around the time of the RC (release candidate) version.

1 Like
#8

bug report filed:

https://bugzilla.opensuse.org/show_bug.cgi?id=1208069

#9

So, from the bug report I was requested to from the dev, which I haven’t had to mess with kernels in openSUSE other than via zypper dup, so I asked for a “how to” and got the reply below:

Comment #4 from Takashi Iwai  ---
Go to the download URL for the OBS repo, and download kernel-default.rpm,
kernel-default-extra.rpm and kernel-default-optional.rpm for the architecture
(x86_64):
  http://download.opensuse.org/repositories/Kernel:/SLE15-SP5/pool/

Then install them via zypper install (as root):
  % zypper in kernel-default-*.rpm

But, it'd be safer to increase the number of installable kernels beforehand.
Edit /etc/zypp/zypp.conf (as root), and modify the line defining
"multiversion.kernels" to add more entries, e.g.
  multiversion.kernels = latest,latest-1,latest-2,latest-3,running

This will keep up to 4 kernels without purge.

The first part is a little “vague” for me. I recall in the ancient day of PPC linux where we had to “wget” something and then install it, but that was so long ago I have lost that data. I went to the link and rifled around in there and I only found links for “kernel-default-5.14xxxxx” and “kernel-default-extra-5.14 xxxxx” but no listing for “kernel-default-optional xxxxx” was showing.

My question is, are there some “missing” steps in the posted data, like can I go to the linked page, click on the two line items to download them to . . . assuming “Downloads” and then just blithely run

Then install them via zypper install (as root):
% zypper in kernel-default-*.rpm

And the system will know where to find those files and install them?? Or, do I have to “cd Downloads” and then run that command??

Or, can I run a “wget [the link]” or do I have to run a “wget” for each of what is two packages linked??? And then, since the “console” knows what it is wget-ing it will then install them???

The part about editing the /zypp/xxxx file I figure is straightforward enough for me.

Looks like this problem has also hit my Gecko rolling MATE install as well, so far hitting 3 openSUSE based systems, but, I believe my TW install has evaded this problem.

#10

All three packages are there in the repo (you need to switch the pages as not all kernels fit on one page :wink:

https://download.opensuse.org/repositories/Kernel:/SLE15-SP5/pool/x86_64/kernel-default-optional-5.14.21-150500.80.1.g301438f.x86_64.rpm

https://download.opensuse.org/repositories/Kernel:/SLE15-SP5/pool/x86_64/kernel-default-extra-5.14.21-150500.80.1.g301438f.x86_64.rpm

https://download.opensuse.org/repositories/Kernel:/SLE15-SP5/pool/x86_64/kernel-default-5.14.21-150500.80.1.g301438f.x86_64.rpm

If you open the links in a browser, you will get asked to download. Or you can use wget…this doesn’t matter. Wget downloads it to a directory you define, or to the directory where you start the wget command from…

To install the downladed rpms, you either cd first into the download directory or you specify the full path to the downloaded rpm.

Thats some basics…

1 Like
#11

@hui

OK, thanks for providing those links . . . that is a little more data as far as providing the “default-optional” link that didn’t seem to be there when I scanned through the list, but, I’m an old guy . . . .

So, it seems like you are saying that I would have to run a “cd Downloads” if I manually downloaded the files and then run his suggested “in” command?

In the meanwhile, once I got logged into Leap 15.5 I ran a zypper and it shows that it would “remove 37.1” and it would install “37.3” kernel . . . .

I think my first easiest step will be to run that through and see if 37.3 kernel gets it done . . . .

#12

In most cases i save some time and specify the full path to a rpm:

zypper in /home/yourname/Downloads/orwhatever/kernel-default-5.14.21-150500.80.1.g301438f.x86_64.rpm

You can easily get the full path by right-clicking on the downloaded rpm → copy address (or path…I’m at a german DE atm…)
Now you can paste the full path into a terminal with right-click → paste

1 Like
#13

Right click on the downloaded rpm, and then pick install with yast, should work too.

1 Like
#14

@Gps2010

Cool, that looks like my “speed” . . . . I’ll check all this out when I get back to the Leap install . . . which is now affected by several dysfunctions . . . .

#15

Mainly linux beginners use this way. But if you only gain a little bit of experience, you will find that the console way is better as it is way more verbose and you don’t get stuck or lost that easily as with the GUI way…

#16

@hui

Right now, speed would be my primary interest, rather than “doing it the right way.” I’m a tad bit irritated that in routine maintenance of most of my openSUSE systems “X” has been “lost” and/or suspend function also lost. So, having to mess around with kernels to try to “fix” the potential problems just adds to the chores of it, rather than the joys of it.

As mentioned, as of yesterday Leap 15.5 is now going to “emergency” mode via grub menu, have to use SuperGrub2 to boot it to GUI . . . if I can download files and then right-click to install them that is a time-saver, because I have at least two other installs with the same problem . . . . I like multi-boot, because if there is a problem in one system, there is another one usually OK, but recently many of them are snafu’d . . . .

#17

As an alpha tester you should know that it makes no sense to do “it the fast way”. You should gather as much as possible informations why your system fails, debug, analyze, create bugreports and help the developers to fix the problems. If you don’t report the problems they may never get fixed and it then makes no sense to be an “alpha-tester”…

Being an alpha-tester also requires some advanced troubleshooting knowledge to not to despair at simple crashes or errors…

1 Like
#18

I am not a fan of command lines, I hate them since DOS, many times I was talking to my pc.
Your a bad command or file name yourself.

That being said hui is right about that there are advantages of using the cli.

Also if you want to have the least possible amount of issues, don’t use a beta version.

My pc is dual boot win 10 and tumbleweed. Then there is a leap install for emergencies.
I do not even update that leap install because I know its working.
Dual booting the same os, same version, does not make sense to me, but maybe I am not understanding the topic starter right.

#19

@hui

I’m seriously considering revoking my membership in the “Alpha Tester society” and requesting a refund. I have been an “alpha/beta tester” for many years, much of it in the 'buntu realm and never really noticed much difference between “alpha” and “release” versions . . . up until the last year or so, sorry to say, chiefly in the SUSE realm. Before that I could run my 6 or 7 distros without having to know very much in the way of cli skillz, especially after PPC linux went away–PPC did require some cli manipulations, but that was years ago.

I’ve been running TW since roughly '13 and even that didn’t take the kind of attention and high maintenance that it has in the last year± . . . . Seems like every single month something is breaking or causing some kind of issue that goes beyond what even “alpha” used to mean. Even, as of late Debian Sid is more well-behaved than Leap, which Leap is supposed to be “stable” in comparison to TW . . . Leap is breaking itself every other zypper upgrade. It doesn’t seem like the devs are giving it the level of concern that they seemed to be doing a few years back . . . ???

So, yes, having similar installs based on the same system now “isn’t making sense” the way it used to when SUSE seemed to comport itself quite ably and all it took was running a “zypper dup” and all was well . . . now I have to su, then screen, then run the zypper . . . and then I have to wait for 40 minutes to install 200 packages and let all of the dracut lines be processed.

If I wouldn’t have my other distros installed and running more or less the same deal, “apt dist-upgrade” and done in 15 mins and system working fine . . . I would have nothing to compare it to, and nothing to complain about . . . but, in that comparo lately SUSE is coming up “lame.”

Sorry for that rant . . . when I get back to Leap Alpha I’ll try to upgrade the kernel stuff and post back to the bug report and here with the update.

1 Like
#20

I consider my 3 Tumbleweed machines to be low maintenance systems. Two of these machines are multiboot with an additional linux distribution. Daily update routine lasts between seconds to some minutes (there is not even a difference of the update speed between my old machines and my high end machine). All 3 machines are using 3 different Nvidia cards with the proprietary drivers (G04. G05, G06). I don’t have problems with these, and i consider them superior to the AMD stuff (much marketing bla bla but low performance). Sure, sometimes there is a small problem whilst the driver/kernel update, but this problem is in most cases fixed in some hours and doesn’t take much effort if you know how to use a search machine and bugzilla.

So my humble opinion, if you have that much problems with a stable release like Leap, there must be a fundamental problem how you operate your systems.

I’m also a tester for a development version of an other linux distribution. It is expected that your system brakes earlier or later with the need for a new installation. It is also possible that you can’t use this system for days until a solution is found how to recover your system via terminal.

An alpha version passed initial QA but is not that far from a development version. Other linux distributions even restrict the alpha tests to a small circle of registered testers to prevent complaining of unexperienced “stable distribution users” which don’t know how to deal with problems that occur at a early release stage.

1 Like