On 09/08/2021 09.09, -pj wrote:

On 8/7/21 7:01 PM, Carlos E. R. wrote:

On 08/08/2021 01.41, -pj wrote:

On 8/7/21 3:05 PM, Felix Miata wrote:

-pj composed on 2021-08-07 02:37 (UTC-0500):

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?

Of course: "zypper ll".

Compaq-nc6400:/etc/zypp>

Do you know why the following repository is: -> https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.11/standard

Not listed in the repository field above?

Yes, I can see this repository is installed with: System -> Yast -> Software -> Software Repositories -> tiwai_kernel_5.11 (I still have the above 6 listed packages locked obviously).

Not the only one:

cat /etc/zypp/locks

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

AFAIK that change does nothing to the menu, it only affects
"purge-kernels".

I Thank you alot for your clarification above, now multiversion.kernels
adjustments make more sense to me. I in my shallow mind was somehow
thinking that the multiversion.kernels entry affected the appearance of
kernels on the boot menu as well. :|

Does the following entry:

multiversion.kernels = latest,latest-1,running,5.11.16-1.ge06d321

Does this look correct to you?

It does, but that I know of the existence of this setting doesn't mean
I'm an expert on it :-D

You may be giving yourself less credit than deserved. Upon a few powercycles and /etc/zypp/zypp.conf line 554 modifications I have determined the following. The kernel should be added with nothing more than it's numerical syntax: e. g. 5.13.8-1.1 no syntax of .586 nor prefix of kernel-default. .

Current "zypper dup" preformed then powercycled.

I have edited /etc/zypp/zypp.conf here to the following, saved file then powercycled the machine: -> multiversion.kernels = latest,latest-1,running,5.13.8-1.1

If I edit /etc/zypp/zypp.conf to the following, save file and powercycle: -> multiversion.kernels = 5.13.8-1.1

Command "zypper -n purge-kernels --dry-run" outputs: -> "The following package is going to be Removed:" kernel-pae-5.13.6-1.2

Command "rpm -qa | egrep 'nel-pae|nel-def'" outputs: -> kernel-default-5.11.16-1.1.ge06d321.i586 kernel-pae-5.13.8-1.1.i686 kernel-pae-5.13.6-1.2.i686 Compaq-nc6400:/etc/zypp>

The procedure would be to write an entry then try if it works. Now, how
exactly to "try" without destroying the target is the problem.

What is the correct way to locate the exact label/name for the 5.11.xx
kernel in konsole? This way I can ensure I am adding the *correct* entry
to the suffix of the "multiversion.kernels" entry. Is it the output of
"uname -a"?

No, the "label" comes from the rpm name.

You mean by executing command (or something of this nature?): > "rpm -qa | egrep 'nel-pae|nel-def'"

Is there a command to list all the installed packages (and their states) similar to "dpkg-l | less" for use with openSUSE that you are aware of?

You can see the service that does it:
minas-tirith:~ # systemctl cat purge-kernels.service
# /usr/lib/systemd/system/purge-kernels.service
[Unit]
Description=Purge old kernels
After=local-fs.target
ConditionPathExists=/boot/do_purge_kernels
ConditionPathIsReadWrite=/

[Service]
Type=oneshot
Nice=19
IOSchedulingClass=idle
Environment=ZYPP_LOCK_TIMEOUT=-1
ExecStart=/usr/bin/zypper -n purge-kernels
ExecStartPost=/bin/rm -f /boot/do_purge_kernels

[Install]
WantedBy=multi-user.target
minas-tirith:~ #


Ok, it runs once soon after boot if file "/boot/do_purge_kernels"
exists,

There is no "/boot/do_purge_kernels" file living here currently. There is a boot.readme file in /boot though.

Could this be triggered by zypper perhaps? Perhaps I am incorrect completely. :|

root is writeable, then fires "/usr/bin/zypper -n
purge-kernels", and finally deletes "/boot/do_purge_kernels".

Thus, you can manually run "/usr/bin/zypper -n purge-kernels". But
perhaps reading the manual we can find if there is a way to run it
without actually /running/ it.

Mmm... I don't see what '-n' does.

You could try "--dry-run"

minas-tirith:~ # zypper --dry-run -n purge-kernels
The flag --dry-run is not known.
minas-tirith:~ #
minas-tirith:~ # zypper  -n purge-kernels --dry-run
Reading installed packages...

Preparing to purge obsolete kernels...
Configuration: latest,latest-1,running
Running kernel release: 5.3.18-lp152.84-default
Running kernel arch: x86_64

Resolving package dependencies...
Nothing to do.
minas-tirith:~ #

Ok, there you have a test method :-)

Passing command "rpm -qa | egrep 'nel-pae|nel-def' in konsole currently
returns 3 kernels:

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

I would imagine that adding the correct 5.11.xx kernel label to
multiversion.kernels that the boot menu would then have 4 various
kernel's eventually displayed is this correct?

How to display the kernels in boot is decided, I don't know how it is
decided. I suppose that at some point zypper sees what is installed and
writes the menu.

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.

If I were to disable the "purge-kernels.service" do each of the
eventually/additionally installed kernels appear on the machines
bootmenu? How many kernels can Tumbleweed successfully have installed?

I have no idea of the limit.

Disabling purge-kernels would not have effect on the menu. Something
(zypper?) would see the installed kernels and write the appropriate
menu. AFAIK, there is something you can run yourself and write the boot
menu solely, but this instant I'm unsure. Could be:

grub2-mkconfig -o /boot/grub2/grub.cfg

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 seem to recall an rpm named something like kernel-docs :-?

[...]

Yes! It still exists, I just looked. And an html version. But I have no
idea what it contains exactly. Maybe that directory, or that directory
processed and copied somewhere else.

...

Now this "kernel-docs" rpm is basically the same as kernel-sources is
for the 5.11.xx ? YaST does not appear to show a kernel-sources package
for the 5.13.xx kernel.

I'm not sure what it contains.

I assume it contains the same as the documentation in the source tree,
without having to install the huge source package, but I don't know.

What you are trying to convey is reading through "kernel-docs" package
would be my starting point for any additional packages in relation to
the 5.13.xx kernel?

Huh, no.

What I am trying to ask, is, can you suggest when the machine is running
under the 5.13.xx kernel what would be the first document to review as
far as major-minor in /dev.....

It is possible that the kernel-doc package contains that file(s) too. I
think so, but I don't know.

I have certainly noted as Felix Miata stated previously, and I quote:
"If you have any kernel that works, that one is all you need for normal
use".

I thank you for your help with this and before. I am extremely happy
with the laptop right now. I have a desktop with TDE KDE installed and
it's wonderful and robust also.

:-)