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".
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 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 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, 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.
:-) -- Cheers / Saludos, Carlos E. R. (from oS Leap 15.2 x86_64 (Minas Tirith))