April 2022 - openSUSE Support - openSUSE Mailing Lists

resolvable.rb crash on call super in Tumbleweed upgrade
by Fodrek Peter ml. 14 Apr '22

14 Apr '22

Dear openSUSE experts, I use tumbleweed uprgrade of damaged system via bootable USB ani resolvable.rb crahes when calling super method ilne 132 of that ruby script due to missing method inside current product Tumbleweed from March 21st 2022 on the damaged system. Is there any file that stores current snapshot name to recover such situation. All *.repo files from the damaged system are moved to /home directory from their original positions. I look forward hearing from you Yours faithfully Peter Fodrek,j.r.

1 0

Tumbleweed Repos very slow!
by Marco Calistri 14 Apr '22

14 Apr '22

Hello, I'm located in Brazil and since some time I notice the TW repos very slow, both during zypper refresh as well as during updates download. Is it a local issue or someone else is facing the same? Thanks and regards, -- Marco Calistri Build: openSUSE Tumbleweed 20220403 Kernel:5.17.1-1-default Desktop: XFCE (4.16.0)

7 14

Re: Superseding 5.11.16-1.1.ge06d321 kernel - Can Now Use - 5.13.6-1.1.21.11 kernel
by -pj 13 Apr '22

13 Apr '22

I'm to poor to buy a new laptop you jerks. On Aug-7-2021 06:40PM, -pj wrote: > > > On 8/7/21 3:05 PM, Felix Miata wrote: >> -pj composed on 2021-08-07 02:37 (UTC-0500): >> >>> Felix Miata wrote: >>>> -pj composed on 2021-08-07 00:46 (UTC-0500): >>>>> I want to install and lock every possible kernel package relating to >>>>> 5.13.6-1-pae that can be recommended. >>>> sudo zypper al kernel-pae* >>>> will keep 5.13.6 from being removed, and prevent zypper and yast from attempting >>>> to install any other kernel-pae version. >>> The faulty (for this machine) 5.12.13-1-pae kernel is currently listed >>> as an option in the bootmenu though. Using the above suggested command >>> "sudo zypper al kernel-pae*" seems like it might lock 5.12.13-1-pae >>> also? >> >> Exactly. >> >>> If the machine is currently booted/operating under the >>> 5.13.6-1-pae then does "zypper al kernel-pae*" only lock that specific >>> operating kernel instance (this may be what you are pointing out). >> >> If you want to lock only a specific kernel, the version string must be part of the >> lock string name. e.g. >> >> zypper al kernel-pae-5.13.6* >> >> If you want to lock all kernels of a specific version, then: >> >> zypper al kernel*5.13.6* > > If I issue the following command: > > zypper al kernel-pae-5.13.6-1-pae it is correct and not zypper al > kernel-pae-5.13.6-1.2.i686 correct? > > How can zypper be used to unlock a version string or a package? YaST > seems to only allow locking of packages with what are contained in the > installed repos, in my case the "tiwai 5.11.xx kernel" repo's packages > are able to be locked and unlocked using YaST. > > Is there a konsole command to list all locked packages on the machine? > >>> How can I find the exact specific package name for the 5.13.6-1-pae >>> kernel ? >> >> If it's an installed kernel: >> >> rpm -qa | grep nel-pae >> >> e.g. >> # rpm -qa | egrep 'nel-pae|nel-def' >> kernel-default-5.7.11-1.2.i586 >> kernel-default-5.8.15-1.2.i586 >> kernel-default-5.9.14-1.2.i586 >> kernel-default-5.10.16-1.3.i586 >> kernel-default-5.11.16-1.1.i586 >> kernel-default-5.12.13-1.1.i586 > > Passing command "rpm -qa | egrep 'nel-pae|nel-def' in the notebook's > konsole results as follows: > > pj@pj-Compaq-nc6400:/> rpm -qa | egrep 'nel-pae|nel-def' > kernel-default-5.11.16-1.1.ge06d321.i586 > kernel-pae-5.12.13-1.1.i686 > kernel-pae-5.13.6-1.2.i686 > pj@pj-Compaq-nc6400:/> > > I notice that today there was a kernel update > to....kernel-pae-5.13.6-1.2.i686 (machine stable :|) > > Can I safely remove kernel-pae-5.12.13-1.1.i686? How can I remove this > kernel and all remnants of it with zypper? YaST is not displaying the > 5.12.xx kernel or any packages relating to it's series when "kernel" > search pattern is used. Then the bootmenu will show the 5.11.xx and > 5.13.xx kernels correct? > > I see how command "rpm -qa | egrep 'nel-pae|nel-def' shows the above 3 > instances listed and not the below instances. This use of grep and > egrep is another topic I know. > > 1.the kernel-default-base > 2.kernel-default-base-rebuild > 3.kernel-default-devel > 5.kernel-devel > 6.kernel-source >>> I believe the purge-kernels service is active by default right? >> >> Yes. >> >>> Currently here multiversion.kernels line 554: 1 multiversion.kernels = >>> latest,latest-1,running > > I edited line 554 of /etc/zypp/zypp.conf to the following: > > multiversion.kernels = latest,latest-1,running,5.11.16-1.ge06d321 > > I powercycled (noted no change in boot menu entries) then reverted to > default: > multiversion.kernels = latest,latest-1,running > >>> Would you have any further suggestions or even a potential to keep 4 of >>> the past kernels instead of only 3? >> >> If you have any kernel that works, that one is all you need for normal use. If you >> expect to ever do any kernel bisection looking for when a bug first appeared, it's >> convenient not to have deleted older kernels. For most people, there's no point in >> changing multiversion.kernels. If you're more comfortable keeping more, go ahead >> and keep more. Another option is to disable purge-kernels.service and delete >> kernels manually at your pleasure. > > I am interested in kernel-sources for 5.13.xx series due to the > following, well basically additional documentation: > > -----> There was a text file in "/usr/src/linux/Documentation" (if the > kernel sources are installed) that described every possible device > file in /dev. I can not find it now. Ah! Found it: > > /usr/src/linux/Documentation/admin-guide/devices.txt The other > important data in /dev is the Major-Minor numbers. <----- Compliments > to Carlos E.R. > > I know more now in your response within the above paragraph, what you > are conveying. What about CVS security patches and such for the latest > kernel versions? > >> Something else to consider if your PC seems sensitive to kernel changes is locking >> all kernels, then only installing a new one when you're so inclined. Locks with >> wildcards are never deleted by zypper, even though it claims to do so when removal >> is an option presented in response to an attempt to install (or remove) any >> version the lock would apply to. What actually happens in such attempts is zypper >> ignores the lock for that one specific transaction. > > I have reread this above paragraph so it's more sense. Of course I > will have to file this for reference. > > -Best Wishes > > >

2 1

Install Zoom problem
by mark neidorff 13 Apr '22

13 Apr '22

6 7

how to prevent /etc/profile.d/ files from returning
by David T-G 13 Apr '22

13 Apr '22

Hi, all -- I'm running Leap 15.2 (and this has been happening for a while), and after a round of updates I have to go back to /etc/profile.d and wipe out files that I don't want (alias.bash + ls.bash in particular). Different from adding my own run commands to profile.local.sh thereunder, I want to NOT get the stock stuff. Is there any way to keep them from being dropped again so that I don't have to deal with this over and over? *sigh* TIA & HAND :-D -- David T-G See http://justpickone.org/davidtg/email/ See http://justpickone.org/davidtg/tofu.txt

7 14

Re: Zypper rebuilding initrd for non-installed kernels after updates (Tumbleweed)
by Manfred Hollstein 10 Apr '22

10 Apr '22

Hi Rodney, On Sun, 10 Apr 2022, 14:36:03 +0200, Rodney Baker wrote: > I all. I've noticed that after doing a zypper dup on Tumbleweed, if a rebuild > of initrd is triggered by the update, it is rebuilding initrd for multiple > superseded kernel versions that are no longer installed. > > [I'm usually rebuilding the kernel after a kernel update because I have a > module that I need that is not yet included in the mainline kernel tree (I > have no idea of the status of that).] this is probably the reason... When you remove any distribution/update supplied kernel, do you also remove the out-of-line kernel's module of your own? Take a look at /lib/modules and get rid of all directories for which you don't have a kernel anymore. HTH, cheers. l8er manfred

1 0

Re: Leap-15.3 update: lib.so.6(GLIBC_2.34)(64bit) missing
by Ben T. Fender 09 Apr '22

09 Apr '22

Thank you, that was it, I had a Tumbleweed in there somehow 5 | multimedia_proaudio | Geekos DAW (openSUSE_Tumbleweed) | Yes | (r ) Yes | No | https://download.opensuse.org/repositories/multimedia:/proaudio/openSUSE_Tu… ..probably one of them susesoftware one-clicks that ask if you want the repo added. Dumped it, problem gone. Corollary, what are Leap users SUPPOSED to update with, Yast or zypper? I use Yast on Leap & zypper on TW. On Sat, 09 Apr 2022 01:42:25 +0200 dominique(a)leuenberger.net wrote: > On 2022-04-09 01:34, Ben T. Fender wrote: > > all of approximately one dozen conflicts revolve around > > a single > > > > "nothing provides 'lib.so.6(GLIBC_2.34)(64bit)' needed by..." > > > > just so it gets noticed > > That reeks of an invalid repo added to your system > > Leap does not have glibc 2.34 and anything linked against it does but > target leap. > > Check your trips (zypper lr -u) and ensure they are actually for leap > > Cheers, > Dominique

3 2

Leap-15.3 update: lib.so.6(GLIBC_2.34)(64bit) missing
by Ben T. Fender 09 Apr '22

09 Apr '22

all of approximately one dozen conflicts revolve around a single "nothing provides 'lib.so.6(GLIBC_2.34)(64bit)' needed by..." just so it gets noticed

1 0

apropos broken for everyone on 15.3?
by Felix Miata 08 Apr '22

08 Apr '22

# apropos label label: nothing appropriate. # apropos e2label e2label: nothing appropriate. # apropos kernel kernel: nothing appropriate. # apropos apropos apropos: nothing appropriate. # apropos mkfs mkfs: nothing appropriate. # apropos edit edit: nothing appropriate. # inxi -S System: Host: 00srv Kernel: 5.3.18-150300.59.60-default arch: x86_64 bits: 64 Console: pty pts/0 Distro: openSUSE Leap 15.3 It used to work. :( -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata

3 2

Re: [Leap 15.4] zypper dup fails
by Bob Williams 08 Apr '22

08 Apr '22

On Fri, 08 Apr 2022 10:20:43 +0200 Freek de Kruijf wrote: > Op vrijdag 8 april 2022 10:07:05 CEST schreef Bob Williams: > > I am running Leap 15.4 Beta. I have just tried to do a zypper dup, > > which failed due to > > > > error: unpacking of archive failed on file > > /usr/share/bash-completion/completions/nvme: cpio: File from package > > already exists as a directory in system error: > > nvme-cli-bash-completion-2.0~7-150400.1.2.x86_64: install failed > > error: nvme-cli-bash-completion-2.0~5-150400.1.2.x86_64: erase > > skipped ( 24/385) Installing: > > nvme-cli-bash-completion-2.0~7-150400.1.2.x86_64 > > ........................................................................... > > ................[error] Installation of > > nvme-cli-bash-completion-2.0~7-150400.1.2.x86_64 failed: Error: > > Subprocess failed. Error: RPM failed: Command exited with status 1. > > > > The running system is installed on an nvme partition, btrfs with > > snapshotting enabled. > > > > I accepted the abort option, but wonder what would happen if I'd > > chosen to ignore the error. Or is there another way to resolve this? > > > > Regards > > Bob > > > > -- > > Bob Williams > > Did have the same problem. Removed the packet > nvme-cli-bash-completion and installed it again, which went OK. > Many thanks, Freek, that worked perfectly. Regards Bob -- Bob Williams

1 0

2023

2022

2021

2020

2019

2018

openSUSE Support April 2022