On 06/29/2014 09:04 AM, ellanios82 wrote:
> On 06/29/2014 03:16 PM, Anton Aylward wrote:
>> I've run 'purge-kernels' and it hasn't cleaned them out.
>> ________________
>  - maybe, as root, command :
> 
>  #rpm -qa kern* | sort
> 
>  - then use command :
> 
>  #rpm -e 
> 
> .....................


Yes, I'm doing that right now.

But WHY were the kernels accumulating in the first place?
There were only supposed to be 2 generations (plus maybe the running one).

This is supposed to be dealt with automatically, there shouldn't be the
need for the manual intervention.



-- 
Any sufficiently advanced technology is undistinguishable from magic.
- Arthur Clarke
-- 
To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org
To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/29/2014 09:37 AM, ellanios82 wrote:

On 06/29/2014 04:05 PM, Anton Aylward wrote:

...

But WHY were the kernels accumulating in the first place? There were only supposed to be 2 generations (plus maybe the running one). This is supposed to be dealt with automatically, there shouldn't be the need for the manual intervention.

---

- could be something needs adjusting in :

//etc/zypp/zypp.conf

Please read my original message. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Hi, This is supposedly a job for "purge-kernels.service" run at boot. Due to mistakes it was not default enabled. Please all run once: systemctl enable purge-kernels.service On next reboot the superflous kernels will be cleaned. (You can trigger it manually with systemctl start purge-kernels.service Ciao, Marcus On Sun, Jun 29, 2014 at 09:50:20AM -0400, Charles Philip Chan wrote:

Anton Aylward writes:

Same thing is happening with the kernel-devel package:

,----[ ls /usr/src | grep linux ] | linux | linux-3.13.0-9.g4b6e17a | linux-3.13.0-9.g4b6e17a-obj | linux-3.13.1-10.g5531b68 | linux-3.13.1-10.g5531b68-obj | linux-3.13.1-12.gfc9498b | linux-3.13.1-12.gfc9498b-obj | linux-3.13.2-13.g97cc2ff | linux-3.13.2-13.g97cc2ff-obj | linux-3.13.2-14.gb59b809 | linux-3.13.2-14.gb59b809-obj | linux-3.13.3-15.g7ccf96b | linux-3.13.3-15.g7ccf96b-obj | linux-3.13.4-16.g6eda950 | linux-3.13.4-16.g6eda950-obj | linux-3.13.5-17.g4e9ddcc | linux-3.13.5-17.g4e9ddcc-obj | linux-3.13.5-18.gbb654e2 | linux-3.13.5-18.gbb654e2-obj | linux-3.13.6-19.g4727218 | linux-3.13.6-19.g4727218-obj | linux-3.13.6-20.g0509ce5 | linux-3.13.6-20.g0509ce5-obj | linux-3.13.7-21.ga68bc7c | linux-3.13.7-21.ga68bc7c-obj | linux-3.14.0-23.gfa168d7 | linux-3.14.0-23.gfa168d7-obj | linux-3.14.1-24.geafcebd | linux-3.14.1-24.geafcebd-obj | linux-3.14.2-25.g1474ea5 | linux-3.14.2-25.g1474ea5-obj | linux-3.14.3-29.g07d82b6 | linux-3.14.3-29.g07d82b6-obj | linux-3.14.4-30.gbebeb6f | linux-3.14.4-30.gbebeb6f-obj | linux-3.14.4-31.g0de0f93 | linux-3.14.4-31.g0de0f93-obj | linux-3.14.5-32.gf1c1b51 | linux-3.14.5-32.gf1c1b51-obj | linux-3.15.0-33.g9194b64 | linux-3.15.0-33.g9194b64-obj | linux-obj `----

and /boot is also littered with files from the kernel packages.

...

But WHY were the kernels accumulating in the first place?

This I want to know also.

...

There were only supposed to be 2 generations (plus maybe the running one).

Agreed.

...

This is supposed to be dealt with automatically, there shouldn't be the need for the manual intervention.

Agreed.

Charles

-- "I once witnessed a long-winded, month-long flamewar over the use of mice vs. trackballs...It was very silly." (By Matt Welsh)

-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 29/06/14 10:56, Marcus Meissner wrote:

Hi,

This is supposedly a job for "purge-kernels.service" run at boot.

Due to mistakes it was not default enabled.

Please all run once:

systemctl enable purge-kernels.service

On next reboot the superflous kernels will be cleaned. (You can trigger it manually with systemctl start purge-kernels.service

Ciao, Marcus On Sun, Jun 29, 2014 at 09:50:20AM -0400, Charles Philip Chan wrote:

...

Anton Aylward writes:

Same thing is happening with the kernel-devel package:

[snip]

and /boot is also littered with files from the kernel packages.

...

But WHY were the kernels accumulating in the first place?

This I want to know also.

...

There were only supposed to be 2 generations (plus maybe the running one).

Agreed.

...

This is supposed to be dealt with automatically, there shouldn't be the need for the manual intervention.

Agreed.

Charles

-- "I once witnessed a long-winded, month-long flamewar over the use of mice vs. trackballs...It was very silly." (By Matt Welsh)

I think keeping the other kernels is a plus. I use the proprietary nvidia driver (nvidia repo) and also the latest kernel (Kernel:stable:standard). Sometimes the nvidia driver does not work with a new kernel. When this happens, I use yast (in console as there is no X) and uninstall the newest kernel. Eventually nvidia releases a new driver, then I can use the newest kernel. I just remove older kernels when I know I won't need them as a fallback any longer. In the past, I would loose the newer kernels when a new one was released. Then I would have to go back to the default kernel for the version of openSUSE at the time. Accumulating them allows me to fallback to a newer kernel when it is no longer available in Kernel:stable:standard. BTW, thanks for mentioning purge-kernels.service. I didn't know about it. It was enabled on my system but inactive. I've disabled it now. This is just my use case and my 2 cents. Cheers, Alvin openSUSE 12.3 Kernel 3.14.4-2.g0de0f93-desktop (3.15.* is available but the nvidia driver [RPM] doesn't like it) KDE 4.13.2 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Il 29/06/2014 10:56, Marcus Meissner ha scritto:

systemctl enable purge-kernels.service

Looks something weird here on my 13.1 64bits: marco@linux-turion64:~> systemctl status purge-kernels.service purge-kernels.service - Purge old kernels Loaded: loaded (/usr/lib/systemd/system/purge-kernels.service; enabled) Active: inactive (dead) start condition failed at dom 2014-06-29 09:28:43 BRT; 4h 18min ago ConditionPathExists=/boot/do_purge_kernels was not met Cheers, -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.11.10-11-default Gnome 3.10.1 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 06/29/2014 03:42 PM, Anton Aylward pecked at the keyboard and wrote:

On 06/29/2014 03:12 PM, Ken Schneider - openSUSE wrote:

...

On 06/29/2014 08:16 AM, Anton Aylward pecked at the keyboard and wrote:

...

In /boot I have

/boot/initrd-3.11.10-11-desktop /boot/initrd-3.11.10-17-desktop /boot/initrd-3.11.10-71.gfba7c1f-desktop /boot/initrd-3.11.10-72.g744d90f-desktop /boot/initrd-3.11.10-73.g2829293-desktop /boot/initrd-3.11.10-74.g7d34bef-desktop /boot/initrd-3.11.10-75.ge012def-default /boot/initrd-3.11.10-75.ge012def-desktop /boot/initrd-3.11.10-76.g7c0c2b5-default /boot/initrd-3.11.10-76.g7c0c2b5-desktop

I don't think I should have all those.

In /etc/zypp/zypp.conf I have

multiversion = provides:multiversion(kernel) multiversion.kernels = latest,latest-1,running

I'm running 3.11.10-75.ge012def-desktop

Certainly 10-11 and 10-17 should be gone.

I've run 'purge-kernels' and it hasn't cleaned them out.

What's up?

It's a side effect of using TumbleWeed, you will need to remove the extra kernels by hand.

I'm not using Tumbleweed.

OK, I have only seen kernel naming like that on my laptop running TW. -- Ken Schneider SuSe since Version 5.2, June 1998 -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sun, Jun 29, 2014 at 03:59:19PM -0400, Felix Miata wrote:

On 2014-06-29 15:52 (GMT-0400) Ken Schneider - openSUSE composed:

...

I have only seen kernel naming like that on my laptop running TW.

I'm pretty sure all BS kernels for openSUSE are named that way.

The gxxxx releases are kernels in the non-update branches built from GIT. So e.g. Tumbleweed, or kernels in "Kernel:*". Ciao, Marcus -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 30/06/14 05:42, Anton Aylward wrote:

On 06/29/2014 03:12 PM, Ken Schneider - openSUSE wrote:

...

On 06/29/2014 08:16 AM, Anton Aylward pecked at the keyboard and wrote:

...

In /boot I have

/boot/initrd-3.11.10-11-desktop /boot/initrd-3.11.10-17-desktop /boot/initrd-3.11.10-71.gfba7c1f-desktop /boot/initrd-3.11.10-72.g744d90f-desktop /boot/initrd-3.11.10-73.g2829293-desktop /boot/initrd-3.11.10-74.g7d34bef-desktop /boot/initrd-3.11.10-75.ge012def-default /boot/initrd-3.11.10-75.ge012def-desktop /boot/initrd-3.11.10-76.g7c0c2b5-default /boot/initrd-3.11.10-76.g7c0c2b5-desktop

I don't think I should have all those.

In /etc/zypp/zypp.conf I have

multiversion = provides:multiversion(kernel) multiversion.kernels = latest,latest-1,running

I'm running 3.11.10-75.ge012def-desktop

Certainly 10-11 and 10-17 should be gone.

I've run 'purge-kernels' and it hasn't cleaned them out.

What's up?

It's a side effect of using TumbleWeed, you will need to remove the extra kernels by hand.

I'm not using Tumbleweed.

I don't use TW either and what I do is first backup '/boot' to '/boot-backup' then (using mc, of course) delete the other kernel(s) and associated files (there are 8 files in total per kernel version) and then execute 'grub2-mkconfig -o /boot/grub2/grub.cfg'. Works a treat. BC -- Using openSUSE 13.1, KDE 4.13.2 & kernel 3.15.2-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 02/07/14 21:38, Carl Hartung wrote:

On Wed, 02 Jul 2014 17:07:46 +1000 Basil Chupin wrote:

...

I don't use TW either and what I do is first backup '/boot' to '/boot-backup' then (using mc, of course) delete the other kernel(s) and associated files (there are 8 files in total per kernel version) and then execute 'grub2-mkconfig -o /boot/grub2/grub.cfg'. Works a treat. Hi Basil,

Side question: If you leave more than one kernel in place, this method is supposed to generate a couple of boot menu entries for each one, correct (regular & 'failsafe')?

thx!

Ouch! :-( You are asking a question which really comes in 2 parts: 1) does leaving more than one kernel in place generate more than one boot menu entry; and 2) do those extra boot menus for the other (old) kernels actually work? The answer to the (1) is YES, but the answer to (2) is something which I have to answer with some trepidation because I don't remember - but I do seem to recall that it does not: only the latest kernel will boot the system. But try it for yourself. BC -- Using openSUSE 13.1, KDE 4.13.2 & kernel 3.15.2-2 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 07/04/2014 06:52 AM, Carl Hartung wrote:

I'd already tried and it hadn't worked. That's what prompted my question. Actually, what _really_ prompted it was the kernel update where the boot menu was left untouched. [Note: 12.3 x86_64 KDE4.] It booted into the same kernel afterward and there was no new entry in the boot menu. After invoking 'grub2-mkconfig,' there was still only one entry in the boot menu, but it booted the updated kernel.

What bothers me about your description, Carl, is that the kernel update, if it came from one of the suse repositories and was downloaded with yast/zypper is that it should have automatically triggered the 'grub2-mkconfig' and not required you to do that manually. The 'only one entry' .... Well see the settings in /etc/zypp/zypp.conf. You might check the responses earlier in this thread for some ideas about how to (or not) retain more than one kernel during updates. -- /"\ \ / ASCII Ribbon Campaign X Against HTML Mail / \ -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 04/07/14 23:12, Carl Hartung wrote:

On Fri, 04 Jul 2014 08:21:52 -0400 Anton Aylward wrote:

...

What bothers me about your description, Carl, is that the kernel update, if it came from one of the suse repositories and was downloaded with yast/zypper is that it should have automatically triggered the 'grub2-mkconfig' and not required you to do that manually. Hi Anton, this was exactly my point. "Never" is kind of strong, but I can't recall seeing this happen before with a normal zypper update.

...

The 'only one entry' .... Well see the settings in /etc/zypp/zypp.conf. These were as I expected:

multiversion = provides:multiversion(kernel) multiversion.kernels = latest,running

...

You might check the responses earlier in this thread for some ideas about how to (or not) retain more than one kernel during updates. Before grub2, my standard configuration was always 'latest' plus the previous two and the boot menu entries for each were created automatically.

I'm beginning to think there's some kind of 'if in doubt, don't touch' logic being triggered by the other installed operating systems. Maybe more than one kernel under this scenario is too much for it to figure out? :-)

I just noted Anton's reference above to "..downloaded with yast/zypper.." . For this reason I must add to what I wrote earlier in answer to your question about what appears in the grub menu, and that is that I NEVER update the kernel using YaST but always use zypper. The kernel I use comes not from the oS update repo but from the ../Kernel:/stable/standard/ repo, and the first thing I do when I first boot the computer in the morning is to do 'zypper refresh', 'zypper patch', 'zypper up' - so YaST doesn't ever come into the picture. If a new kernel is downloaded I then do 'grub2-mkconfig....' followed by recompiling the nVidia driver to suit the new kernel. BC -- Using openSUSE 13.1, KDE 4.13.2 & kernel 3.15.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On 05/07/14 20:29, Patrick Shanahan wrote:

* Basil Chupin [07-05-14 05:46]: [...]

...

The kernel I use comes not from the oS update repo but from the ../Kernel:/stable/standard/ repo, and the first thing I do when I first boot the computer in the morning is to do 'zypper refresh', 'zypper patch', 'zypper up' - so YaST doesn't ever come into the picture. If a new kernel is downloaded I then do 'grub2-mkconfig....' followed by recompiling the nVidia driver to suit the new kernel. I also use zypper rather than yast for software/kernel updates, but I fail to understand the need to "grub2-mkconfig" as zypper performs that task, iiuc???

I have six operating systems installed and use a bootloader (sda1 which I mount in /mnt/btldr) which produces the grub menu from which I boot the appropriate system I need. At the moment it is either 13.1 or Windows 7 Professional - and as soon as I get this 13.2 and Factory thing worked out (it's now being tested on the laptop) it will replace oS 12.3 Tumbleweed. With the above, when I install a new kernel I: * first make backups of the '/mnt/btldr' and the 'boot' directories; * then edit '/boot' to delete any old kernels, leaving the latest in place; * run 'grub2-mkconfig......' firstly against '/boot' followed by running it against '/mnt/btldr/......' (after mounting the latter of course); * reboot the system into level 3 where I then compile the nVidia driver; * then reboot into 13.1 with the latest kernel (with the nVidia driver compiled for it). Following this procedure I then always know where a problem may have arisen should things go wrong - in other words, I have a "level playing field" so to speak :-) . For example, when one runs 'grub2-mkconfig...." while being booted in another oS version, let's say 12.2, then the first entry in the boot grub menu will be 12.2 and not 13.1. But mainly I do what I do is because I manually delete the old kernels after I found at one time around 6 of them sitting in '/boot' taking up ~49MB each - and so I now zap them manually. BC -- Using openSUSE 13.1, KDE 4.13.2 & kernel 3.15.3-1 on a system with- AMD FX 8-core 3.6/4.2GHz processor 16GB PC14900/1866MHz Quad Channel RAM Gigabyte AMD3+ m/board; Gigabyte nVidia GTX660 GPU -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

On Sat, 5 Jul 2014 06:29:49 -0400 Patrick Shanahan wrote:

I also use zypper rather than yast for software/kernel updates, but I fail to understand the need to "grub2-mkconfig" as zypper performs that task, iiuc???

Hi Patrick, In my case, on this system (12.3), 'zypper update' installed the latest kernel but the boot menu didn't change. This is why I asked about grub2-mkconfig creating boot menu entries for each installed kernel. And this has me wondering if the recent migration of my regular operating systems to a single SSD is involved. regards, Carl -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

Il 05/07/2014 09:40, Carl Hartung ha scritto:

On Sat, 5 Jul 2014 06:29:49 -0400 Patrick Shanahan wrote:

...

I also use zypper rather than yast for software/kernel updates, but I fail to understand the need to "grub2-mkconfig" as zypper performs that task, iiuc???

Hi Patrick,

In my case, on this system (12.3), 'zypper update' installed the latest kernel but the boot menu didn't change. This is why I asked about grub2-mkconfig creating boot menu entries for each installed kernel. And this has me wondering if the recent migration of my regular operating systems to a single SSD is involved.

regards,

Carl

I have openSUSE 13.1 with latest STABLE kernel installed and by executing the command sudo /sbin/purge-kernels I don't obtain any older kernels removing. The return message of sudo /sbin/purge-kernels is: marco@linux-turion64:~> sudo /sbin/purge-kernels /sbin/purge-kernels: Running kernel 3.15.5-1.g01d2774-x86_64/default not installed. NOT removing any packages for flavor x86_64/default. /sbin/purge-kernels: Nothing to do. But if I issue uname -r I get: marco@linux-turion64:~> uname -r 3.15.5-1.g01d2774-default And if I check inside my /boot I have: marco@linux-turion64:~> ls -l /boot|grep vmlinuz lrwxrwxrwx 1 root root 33 11 lug 13.03 vmlinuz -> vmlinuz-3.15.5-1.g01d2774-default -rw-r--r-- 1 root root 5385312 3 lug 10.16 vmlinuz-3.15.3-1.g42bf625-default -rw-r--r-- 1 root root 5385472 8 lug 06.43 vmlinuz-3.15.4-1.g2b59ae6-default -rw-r--r-- 1 root root 5385760 11 lug 06.51 vmlinuz-3.15.5-1.g01d2774-default This is my current configuration in /etc/zypp/zypp.conf, may be I have to remove the first "latest" statement in order to have just one running + latest-1 installed on my system: ## Comma separated list of kernel packages to keep installed in parallel, if the ## above multiversion variable is set. Packages can be specified as ## 2.6.32.12-0.7 - Exact version to keep ## latest - Keep kernel with the highest version number ## latest-N - Keep kernel with the Nth highest version number ## running - Keep the running kernel ## oldest - Keep kernel with the lowest version number (the GA kernel) ## oldest+N - Keep kernel with the Nth lowest version number ## ## Note: This entry is not evaluated by libzypp, but by the ## purge-kernels service (via /sbin/purge-kernels). ## ## Default: Do not delete any kernels if multiversion = provides:multiversion(kernel) is set multiversion.kernels = latest,latest-1,running Thanks. Cheers, -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.15.5-1.g42bf625-default Gnome 3.12.2 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Il 12/07/2014 15:46, Carlos E. R. ha scritto:

On 2014-07-12 17:19, Marco Calistri wrote:

...

I have openSUSE 13.1 with latest STABLE kernel installed and by executing the command sudo /sbin/purge-kernels I don't obtain any older kernels removing.

The return message of sudo /sbin/purge-kernels is:

marco@linux-turion64:~> sudo /sbin/purge-kernels /sbin/purge-kernels: Running kernel 3.15.5-1.g01d2774-x86_64/default not installed. NOT removing any packages for flavor x86_64/default. /sbin/purge-kernels: Nothing to do.

If I recall correctly, the purge script has problems detecting some name patterns. Known bug.

Thanks Carlos, Effectively, despite I removed the first "latest" statement from my config: multiversion.kernels = *latest*,latest-1,running and re-executed purge-kernels, the only one removed has been the kernel-xen-devel-3.15.3 package. Cheers, - -- Marco Calistri opensuse 13.1 (Bottle) 64 bit - Kernel 3.15.5-1.g42bf625-default Gnome 3.12.2 Intel® Core™ i5-2410M CPU @ 2.30GHz × 4 - Intel® Sandybridge Mobile -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlPBteoACgkQi4zJuA3lyFf6jACfV5xLSAmjFFMAproMdVw7zqdm oZMAnjdmmcnHE3U6x8Kj+3xXRPPyMFKP =omdK -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org