version20150909/KDE.Firstly I have to say everything is working fine, however I have a couple of questions:
After zypper dup and the download comes the checking for file conflicts. Usually with a kernel update there is that the new kernel conflicts with kernel 3.something, same with kernel macros. After the last update it was as well that kernel ( and kernel macros) of 4.1.6.3 conflict with 4.1.6.2. Of course after downloading 200+ packages you have only the option to continue or to break off the update with the default set to no. I always continued and so far it was OK. Of course I can imagine that a new kernel contains lines which conflict with the old kernel but I want to boot into the new one anyway. Any comments from the experts? Is there something to look out that you better interrupt the upgrade process?
Secondly I noticed that the /boot directory is accumulating more and more files and the grub.cfg file in /boot/grub2 gets longer and longer. Now I don’t think I want to boot into e.g. the 3.11.10-17 kernel any more. Is there any maintenance which is recommended to clean out no longer used files and to shorten the grub.cfg to say the last 4 kernel versions?
Since everything is working I am in no hurry for an answer, however I am curious and any comments from you experts is appreciated.
Cheers
Uli
The new kernel was just a recompile of the previous kernel. When that happens you get the conflict. In my view, it is no problem.
Why are you accumulating kernels? The normal behavior is to keep only the last two kernels. On reboot, after a new kernel install, a process is supposed to run to delete all but the most recent two kernels. Have you changed the settings for that? (It is the setting for “multiversion.kernels” in “/etc/zypp/zypp.conf”).
You can manually delete old kernels anyway, in Yast Software Manager. Use the “version” tab.
Thank you, nrickert, I haven’t changed anything in zypp.conf. Had a quick look through, everything but 3 lines are hashed out:
[main]
multiversion = provides:multiversion(kernel)
multiversion.kernels = latest,latest-1,running
If that is how it should be then why are all the kernels still there?
Cheers
Uli
On 2015-09-13 02:26, nrickert wrote:
> Why are you accumulating kernels? The normal behavior is to keep only
> the last two kernels. On reboot, after a new kernel install, a process
> is supposed to run to delete all but the most recent two kernels. Have
> you changed the settings for that? (It is the setting for
> “multiversion.kernels” in “/etc/zypp/zypp.conf”).
A service that does that must be enabled, and sometimes it isn’t. What
was the name… ah, purge-kernels.service.
fuerstu, please run this and check the output. If in doubt, post it here:
systemctl status purge-kernels.service
You can also call that service manually and see if it works.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Thanks, robin_listas here is the command:
uli@linux-top: systemctl status purge-kernels.service
● purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; disabled; vendor preset: enabl
ed)
Active: inactive (dead)
uli@linux-top:
The command would be ‘systemctl start purge-kernels.service’? Does this change the grub.cfg file as well?
Cheers
Uli
I activated the script purge-kernels.service using Yast -> services manager. However now Yast hangs for nearly 45 minutes with the message “Writing Configuration” and does not react. I ran again
uli@linux-top:~> systemctl status purge-kernels.service
● purge-kernels.service - Purge old kernels
Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; disabled; vendor preset: enabl
ed)
Active: activating (start) since Sun 2015-09-13 14:58:40 NZST; 22min ago
Process: 6537 ExecStartPre=/bin/rm -f /boot/do_purge_kernels (code=exited, status=0/SUCCESS)
Main PID: 6538 (purge-kernels)
CGroup: /system.slice/purge-kernels.service
├─6538 /usr/bin/perl /sbin/purge-kernels
└─6768 rpm -e kernel-default-3.11.10-17.2.i586 kernel-default-devel-3.11.10-17.2.i...
uli@linux-top:~>
Now /boot still shows over 60 each config…, initrd…, symtypes…, symvers…, System.map… and vmlinuz files. I don’t know what is happening and whether I should just force the process for Yast etc to close. I will wait for a bit longer and if I don’t get any reply here I may just force to finish the processes and see what happens.
Cheers
Uli
According to systemctl status output, it is not enabled, just it started once (meaning - it will not be active again after reboot). According to status output, purge-kernels is still running; deleting kernel RPM can take quite a lot of time. You need to start purge-kernels and wait until it reports inactive status which means it finished removing extraneous kernels. You may consider enabling it using “systemctl enable purge-kernels.service”.
On 2015-09-13 09:26, arvidjaar wrote:
>
> fuerstu;2727941 Wrote:
>> I activated the script purge-kernels.service using Yast -> services
>> manager.
>
> According to systemctl status output, it is not enabled, just it started
> once (meaning - it will not be active again after reboot). According to
> status output, purge-kernels is still running; deleting kernel RPM can
> take quite a lot of time. You need to start purge-kernels and wait until
> it reports inactive status which means it finished removing extraneous
> kernels. You may consider enabling it using “systemctl enable
> purge-kernels.service”.
Yes, run it manually, once, and wait it out. It will take long.
Then also enable it via command line. It should take shorter time, once
the service has completed a run previously.
I guess it tries to update grub for each removal, and this
(autoprobing?) takes long.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Thank you, robin_listas and arvidjar. Yesterday I opened Yast → Service Manager a second time (the first stalled with writing configuration as told below) and there purge-kernels.service was disabled. So I closed all hanging processes with kill…
This morning I tried starting the service from command line (as root). The result was instantly:
**linux-top:~ #** systemctl enable purge-kernels.service
**linux-top:~ #** systemctl start purge-kernels.service
**linux-top:~ #**
But there are still over 50 kernels, initrds etc in the /boot directory.
I opened Yast → Service Manager again, selected purge-kernels (stated as inactive) and clicked details with the following response:
* purge-kernels.service - Purge old kernels Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Mon 2015-09-14 10:22:39 NZST; 1min 10s ago
ConditionPathExists=/boot/do_purge_kernels was not met
Sep 14 10:22:39 linux-top.site systemd[1]: Started Purge old kernels.
(I put this in code tags but it was in the Yast window)
So how can I rectify “ConditionPathExists=/boot/do_purge_kernels was not met” that is probably in a config file. I looked into /etc could not find anything
which looked like the relevant config file. What next?
Cheers
Uli
Maybe:
# touch /boot/do_purge_kernels
and then start the service (or reboot).
I’m not sure whether just the command (as root)
# purge-kernels
will do the job. It might be worth trying that first. Start a separate terminal session for that in case it takes a long time.
On 2015-09-14 00:46, fuerstu wrote:
> Code:
> --------------------
> * purge-kernels.service - Purge old kernels Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled; vendor preset: enabled) Active: inactive (dead) Condition: start condition failed at Mon 2015-09-14 10:22:39 NZST; 1min 10s ago ConditionPathExists=/boot/do_purge_kernels was not met
> Sep 14 10:22:39 linux-top.site systemd[1]: Started Purge old kernels.
> --------------------
Just do:
su -
touch /boot/do_purge_kernels
systemctl start purge-kernels.service
and wait.
It is not a config file, but a flag file.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Thank you, robin_listas and nrickert, the touch command did the trick and with systemctl start purge-kernels.service the computer is working now. I let you know when it is finished whether everything worked well - but as you have told me before it will take some time. Quite a lot to purge…
Cheers
uli
OK the script finished and it looks OK now. The only thing that surprises me is that there is only the 4.1.6-3 kernel left and no previous kernel. I thought this script keeps the previous kernel as well or is this only after the zypper dup (since it is in the zypp.conf file “multiversion.kernels = latest,latest-1,running”)?
Anyway it looks much better now and over the nearly 15 years I used linux I can count on one hand how often I had to boot into the previous kernel.
So thanks again for your help, robin_listas, nrickert and arvidjaar.
Cheers
Uli
On 2015-09-14 03:36, fuerstu wrote:
>
> OK the script finished and it looks OK now. The only thing that
> surprises me is that there is only the 4.1.6-3 kernel left and no
> previous kernel.
Curious…
> I thought this script keeps the previous kernel as well
> or is this only after the zypper dup (since it is in the zypp.conf file
> “multiversion.kernels = latest,latest-1,running”)?
Yes, I understand it should have kept the previous version, but it
depends what the script thinks is the previous version.
> Anyway it looks much better now and over the nearly 15 years I used
> linux I can count on one hand how often I had to boot into the previous
> kernel.
Good 
> So thanks again for your help, robin_listas, nrickert and arvidjaar.
Welcome
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
Great.
The only thing that surprises me is that there is only the 4.1.6-3 kernel left and no previous kernel.
Correct. My Tumbleweed currently has only one kernel.
If you were to check with Yast Software Management, select the kernel (probably “kernel-desktop”, and click the “Versions” tab, it will show that you have two kernels. However, both of those kernels use the same filenames, so you really do only have one. That’s what that “conflict” message was about – the one that you mentioned in the opening post.
This is a peculiarity that happens whenever a new kernel is just a recompile of the previous kernel.
On 2015-09-14 13:16, nrickert wrote:
> This is a peculiarity that happens whenever a new kernel is just a
> recompile of the previous kernel.
Ah, I forgot about that one. It is a bug, actually, that /new/ kernel
shouldn’t have been published.
–
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 “Bottle” (Minas Tirith))
You are right, nrickert, Yast shows that the kernels 4.1.6-2 are installed as well. However in the GRUB screen I have only the following options:
openSUSE, with Linux 4.1.6-3-pae
openSUSE, with Linux 4.1.6-3-pae (recovery mode)
openSUSE, with Linux 4.1.6-3-desktop
openSUSE, with Linux 4.1.6-3-desktop (recovery mode)
openSUSE, with Linux 4.1.6-3-default
openSUSE, with Linux 4.1.6-3-default (recovery mode)
And these are the options (vmlinuz, initrd, etc) which are in the /boot directory. As you see the default is the pae kernel and this seems to be working well. Is there a point of regularly installing the other kernels? If not how do I change this?
Cheers
Uli
No, but they will be installed anyway whenever there is a kernel update.
To stop that you would have to remove the unwanted kernels that are currently there. And it probably isn’t worth the effort. In any case, I would let the system settle down for a few updates, following your massive kernel removal, before you try to change what is still there.
Thank you, nrickert, I will leave it for now.
Cheers
uli