[opensuse] Old kernel is used on system with 2 LEAP installations
On my desktop, there are two LEAP systems, 15.0 and 15.1. grub is managed by the older version 15.0. Now, i found that on 15.1, an old version of the kernel is used rather than the latest patch: ~\:08:39:37 > uname -a Linux linux-riut 4.12.14-lp151.27-default #1 SMP Fri May 10 14:13:15 UTC 2019 (862c838) x86_64 x86_64 x86_64 GNU/Linux ~\:08:56:31 > uname -r 4.12.14-lp151.27-default ~\:08:56:39 > The kernel patch in use seems to be the first of LEAP 15.1. Auto-Update is active and the new kernel really is installed: ~\:09:59:26 > ls -l /boot | grep vmlinuz lrwxrwxrwx 1 root root 35 16. Aug 20:23 vmlinuz -> vmlinuz-4.12.14-lp151.28.13-default -rw-r--r-- 1 root root 7331952 15. Mai 02:26 vmlinuz-4.12.14-lp151.27-default -rw-r--r-- 1 root root 7340144 15. Jul 13:25 vmlinuz-4.12.14-lp151.28.10-default -rw-r--r-- 1 root root 7344240 11. Aug 10:54 vmlinuz-4.12.14-lp151.28.13-default ~\:09:59:26 > There are no such problems on the 15.0-system. I figured, I should let grub refresh its boot entries, so I started the boot configuration in Yast on 15.0, but had no success with it. Maybe, i could simply delete the old kernels manually? But how can i avoid this from happening every time a new patch is released? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/08/2019 04:01, zb4ng wrote:
Auto-Update is active and the new kernel really is installed:
~\:09:59:26 > ls -l /boot | grep vmlinuz lrwxrwxrwx 1 root root 35 16. Aug 20:23 vmlinuz -> vmlinuz-4.12.14-lp151.28.13-default -rw-r--r-- 1 root root 7331952 15. Mai 02:26 vmlinuz-4.12.14-lp151.27-default -rw-r--r-- 1 root root 7340144 15. Jul 13:25 vmlinuz-4.12.14-lp151.28.10-default -rw-r--r-- 1 root root 7344240 11. Aug 10:54 vmlinuz-4.12.14-lp151.28.13-default ~\:09:59:26 >
new kernel? On a 15.x? I'm running cat /etc/os-release NAME="openSUSE Leap" VERSION="42.3" and I haven't updated my kernel for over a week now uname -a Linux main.HOME.SystemI.ca 5.2.8-2.ga44175e-default #1 SMP Mon Aug 12 07:11:56 UTC 2019 (a44175e) x86_64 x86_64 x86_64 GNU/Linux Now I'm sure that 4.x can be patched patched patched to look like 5.x, but why? For the effort of 'update' automation, and keeping a few back versions around for the if-but-maybe and testing. # zypper lr --uri| grep -i kernel 13 | Kernel_Stable | Kernel_Stable | Yes | (r ) Yes | Yes | http://download.opensuse.org/repositories/Kernel:/stable/standard/
I figured, I should let grub refresh its boot entries, so I started the boot configuration in Yast on 15.0, but had no success with it.
NoNoNoNo. Grub doesn't refresh, it's taken care of by zypper when the update runs. KISS.
Maybe, i could simply delete the old kernels manually? But how can i avoid this from happening every time a new patch is released?
NoNoNoNo. It's taken care of by zypper. In the file /etc/zypp/zypp.conf you can control this (along with many other things: the comments in the file are worth reading thoroughly!) ## 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-2,latest-1,running #==== THIS IS MY SETTING Yes, you can accumulate kernels until you explicitly purge them! # ls /boot/vmlinux* /boot/vmlinux-5.2.1-2.gbf5c01b-default.gz /boot/vmlinux-5.2.6-1.g187170c-default.gz /boot/vmlinux-5.2.2-2.gadfddac-default.gz /boot/vmlinux-5.2.7-2.geaa06bb-default.gz /boot/vmlinux-5.2.2-3.gafc4698-default.gz /boot/vmlinux-5.2.8-1.gbf37e83-default.gz /boot/vmlinux-5.2.3-1.gf5296b5-default.gz /boot/vmlinux-5.2.8-2.ga44175e-default.gz /boot/vmlinux-5.2.4-1.g5034dba-default.gz # purge-kernels Removed: kernel-default-5.2.1-2.1.gbf5c01b.x86_64 kernel-default-5.2.2-2.1.gadfddac.x86_64 kernel-default-5.2.2-3.1.gafc4698.x86_64 kernel-default-5.2.3-1.1.gf5296b5.x86_64 kernel-default-5.2.4-1.1.g5034dba.x86_64 kernel-default-5.2.6-1.1.g187170c.x86_64 OH MY! Look at all the space reclaimed under /lib! So what's the point of using zypper? Many things. it maintains a database of the updates, patches, for one thing. But you can think of it as a collection of smart scripts for doing updates. There's a lot of low-level details, such as getting grub updated that you mention, and the parametrized building of the kernel load image with the boot blocks and drivers that you want/need via Dracut. As has been mentioned here before, you can strip down the initrd to have just what you want for a faster boot. Yes, you COULD do all this, all these parts, separately, manually, making notes of the dates and patches in your little black book rather than the zypper database. Yes, you could have a check-list to make sure you did each step in the correct sequence with the long list of arguments on the command line in the right order with the right spelling. Think of it as a "learning experience" and after the third time you make a mistake and brick your system you might decide to run zypper instead. BTDT. Now, in order to keep what little grey hair I still have I'm working on learning from the experiences of others rather than acquiring 'wisdom' the hard way. Youthful arrogance and independence is great for the young and in circumstances where there is the 'slack' to allow you to learn from the mistakes. Personally I think scripts and automation and well documented config files are wonderful. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Am 17.08.19 um 13:51 schrieb Anton Aylward:
On 17/08/2019 04:01, zb4ng wrote: ... new kernel? On a 15.x?
Sorry for my sloppy wording! I meant with "new kernel" the latest patch in the 4.12.xx series that comes with the preconfigured update mechanism in my 15.1 system.
Now I'm sure that 4.x can be patched patched patched to look like 5.x, but why? For the effort of 'update' automation, and keeping a few back versions around for the if-but-maybe and testing.
I just want to have the current security patches for 4.12.xx.
So what's the point of using zypper? Many things. it maintains a database of the updates, patches, for one thing. But you can think of it as a collection of smart scripts for doing updates. There's a lot of low-level details, such as getting grub updated that you mention,
Well, but can this work if grub is managed by another system (15.0 - in my case ) ? If I remember correctly, a couple of years ago, you could put the actual kernel file into the grub configuration, but this was replaced by some script (grub.cfg). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 17/08/2019 14:54, zb4ng wrote:
Am 17.08.19 um 13:51 schrieb Anton Aylward:
On 17/08/2019 04:01, zb4ng wrote: ... new kernel? On a 15.x?
Sorry for my sloppy wording! I meant with "new kernel" the latest patch in the 4.12.xx series that comes with the preconfigured update mechanism in my 15.1 system.
I think you are under a misapprehension over what 'patches' are and are not. if you are up to date on the patches for 4.12 then its not really 4.12 any more! Those 'patches' are the diffs between the baseline 4.12 and my 5.x. As for the preconfigured update mechanism", well that's what zypper is! Are you telling me that 15.1 doesn't have zypper?
Now I'm sure that 4.x can be patched patched patched to look like 5.x, but why? For the effort of 'update' automation, and keeping a few back versions around for the if-but-maybe and testing.
I just want to have the current security patches for 4.12.xx.
The current security patches are the same ones I have in 5.x
So what's the point of using zypper? Many things. it maintains a database of the updates, patches, for one thing. But you can think of it as a collection of smart scripts for doing updates. There's a lot of low-level details, such as getting grub updated that you mention,
Well, but can this work if grub is managed by another system (15.0 - in my case ) ?
Yes, that's the whole point of Zypper invoking Drakut and grub2-mkconfig Why not read up on Dracut and what it does. dracut (8) - low-level tool for generating an initramfs/initrd image grub2-mkconfig (8) - generate a GRUB configuration file You don't need to use those. There's a good reason why not; try to invoke them manually you'll have to deal with command line options and the probability that you'll mistype something is asymptotically high. The whole point of using zypper and repository containing the updates (or patches, it doesn't matter) is to let zypper figure out the details that those - and other - programs need to be invoked with. I've done this: run zypper and while it's working run 'ps' from another terminal and seen the processes being created and the log command lines being generated on the fly by zypper. Consistent and error free.
If I remember correctly, a couple of years ago, you could put the actual kernel file into the grub configuration, but this was replaced by some script (grub.cfg).
What version of grub are you talking about? Aren't you getting confused with some other bootloader? https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... The whole point of grub, and even grub-classic, as well as many other bootloaders, is yto let you CHOOSE what kernel to boot. You'll see discussions on the list of using different drivers, Nvida is a particular subject, with different drivers. The idea is to build different versions of the kernel to test out these different drivers and then try booting them to test function and performance. but keeping an older, stable, version around if the new one doesn't work out. BTDT. And not just with video drivers. There's https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... which is immensely interesting IF AND ONLY IF you know what you are doing and understand the low level actions concerned. But in reality, the whole point of using zypper to update or apply patches -- RTFM for ${DEITY}'s sake! -- is to hide that micromanagement and bit-twiddly from you. If you approach things from that level there's a high probability you'll make some mistake. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/08/2019 02.49, Anton Aylward wrote:
On 17/08/2019 14:54, zb4ng wrote:
Am 17.08.19 um 13:51 schrieb Anton Aylward:
On 17/08/2019 04:01, zb4ng wrote: ... new kernel? On a 15.x?
Sorry for my sloppy wording! I meant with "new kernel" the latest patch in the 4.12.xx series that comes with the preconfigured update mechanism in my 15.1 system.
I think you are under a misapprehension over what 'patches' are and are not.
He refers to running "zypper patch". -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 18/08/2019 09:35, Carlos E. R. wrote:
He refers to running "zypper patch".
Referring to the kernel repository ... "zypper up" gives me The following NEW package is going to be installed: kernel-default-5.2.9-1.1.g80c0 "zypper patch" gives me Nothing to do. -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/08/2019 17.06, Anton Aylward wrote:
On 18/08/2019 09:35, Carlos E. R. wrote:
He refers to running "zypper patch".
Referring to the kernel repository ...
"zypper up" gives me
The following NEW package is going to be installed: kernel-default-5.2.9-1.1.g80c0
"zypper patch" gives me
Nothing to do.
Sure. The later only looks at the repositories of update type, which normally means the oss update repo. Also known as "applying mandatory updates". YaST update does the same as "zypper patch". -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
On 17/08/2019 20.54, zb4ng wrote:
So what's the point of using zypper? Many things. it maintains a database of the updates, patches, for one thing. But you can think of it as a collection of smart scripts for doing updates. There's a lot of low-level details, such as getting grub updated that you mention,
Well, but can this work if grub is managed by another system (15.0 - in my case ) ?
No, it doesn't. You have to boot the system which controls grub and make it run os-prober so that it finds the actual kernel entries of the other system. There are other ways. You can manually edit the grub file that is intended for manual edit, and create an entry for the "vmlinuz" symlink this one is maintained by zypper. Or, after making sure that both installs have their own grub installed to the root partition, not to the MBR, add manually on each one (in the file intended for manual edit) an entry for the other grub, not to the kernel. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am 18.08.19 um 15:44 schrieb Carlos E. R.:
On 17/08/2019 20.54, zb4ng wrote:
No, it doesn't.
You have to boot the system which controls grub and make it run os-prober so that it finds the actual kernel entries of the other system.
There are other ways.
You can manually edit the grub file that is intended for manual edit, and create an entry for the "vmlinuz" symlink this one is maintained by zypper.
Yeah it looks like I can use "menuentry" in /boot/grub2/custom.cfg and put the symlink in there?
Or, after making sure that both installs have their own grub installed to the root partition, not to the MBR, add manually on each one (in the file intended for manual edit) an entry for the other grub, not to the kernel.
Maybe if I can't figure out grub configurationb , I'll try to add grub to my 15.1-system -(Do I have to move the existing Grub from MBR to 15.0?) - and see if they find each other. Otherwise, I am ok with using the method mentioned in my earlier post. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/08/2019 18.03, zb4ng wrote:
Am 18.08.19 um 15:44 schrieb Carlos E. R.:
On 17/08/2019 20.54, zb4ng wrote:
No, it doesn't.
You have to boot the system which controls grub and make it run os-prober so that it finds the actual kernel entries of the other system.
There are other ways.
You can manually edit the grub file that is intended for manual edit, and create an entry for the "vmlinuz" symlink this one is maintained by zypper.
Yeah it looks like I can use "menuentry" in /boot/grub2/custom.cfg and put the symlink in there?
Yes, that's the idea.
Or, after making sure that both installs have their own grub installed to the root partition, not to the MBR, add manually on each one (in the file intended for manual edit) an entry for the other grub, not to the kernel.
Maybe if I can't figure out grub configurationb , I'll try to add grub to my 15.1-system -(Do I have to move the existing Grub from MBR to 15.0?) - and see if they find each other.
Otherwise, I am ok with using the method mentioned in my earlier post.
This is one from me: menuentry '--> ssd-test' --id cer-ssd-001 { insmod part_gpt insmod ext2 set root='hd0,gpt3' if search --no-floppy --fs-uuid --set=root 32392d31... ; then chainloader +1 else echo Could not find this OS instance, will not boot (3) sleep 1 fi } About MBR: only one of the installed systems can use the MBR, so instead I give it to none. then I mark one partition as bootable. Works even on GPT with the proper code - linuxboot? Not sure of the package name. A generic MBR code for GPT disks. -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)
Am 18.08.19 um 21:19 schrieb Carlos E. R.:
On 18/08/2019 18.03, zb4ng wrote:
Am 18.08.19 um 15:44 schrieb Carlos E. R.:
On 17/08/2019 20.54, zb4ng wrote:
No, it doesn't.
You have to boot the system which controls grub and make it run os-prober so that it finds the actual kernel entries of the other system.
There are other ways.
You can manually edit the grub file that is intended for manual edit, and create an entry for the "vmlinuz" symlink this one is maintained by zypper.
Yeah it looks like I can use "menuentry" in /boot/grub2/custom.cfg and put the symlink in there?
Yes, that's the idea.
Or, after making sure that both installs have their own grub installed to the root partition, not to the MBR, add manually on each one (in the file intended for manual edit) an entry for the other grub, not to the kernel.
Maybe if I can't figure out grub configurationb , I'll try to add grub to my 15.1-system -(Do I have to move the existing Grub from MBR to 15.0?) - and see if they find each other.
Otherwise, I am ok with using the method mentioned in my earlier post.
This is one from me:
menuentry '--> ssd-test' --id cer-ssd-001 { insmod part_gpt insmod ext2 set root='hd0,gpt3' if search --no-floppy --fs-uuid --set=root 32392d31... ; then chainloader +1 else echo Could not find this OS instance, will not boot (3) sleep 1 fi }
This works now for me: /boot/grub2/custom.cfg menuentry "openSuSE 15.1 - Custom Configuration" --class gnu-linux --class gnu --class os { insmod part_msdos insmod ext2 set root='(hd0,10)' linux /boot/vmlinuz initrd /boot/initrd } ~\:14:44:35 > uname -a Linux linux-riut 4.12.14-lp151.28.13-default #1 SMP Wed Aug 7 07:20:16 UTC 2019 (0c09ad2) x86_64 x86_64 x86_64 GNU/Linux ~\:14:45:33 > -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 18/08/2019 12:03, zb4ng wrote:
Maybe if I can't figure out grub configurationb , I'll try to add grub to my 15.1-system -(Do I have to move the existing Grub from MBR to 15.0?) - and see if they find each other.
Earlier in this thread I have a reference to the SUSE manaual. There's a link on that page to how the boot system works. I suggest you read it and it might clear up confusion. https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... Please do read that. To add grub2, please either make sure it was there at installation or use zypper to install it. I'm not sure how you could do an installation with nothing like grub or LILO. Really, I don't like the way you are wording this: it becomes so much easier, clearer and simpler of you make use of YAST to set up the boot and set the MBR. https://doc.opensuse.org/documentation/leap/reference/html/book.opensuse.ref... -- A: Yes. > Q: Are you sure? >> A: Because it reverses the logical flow of conversation. >>> Q: Why is top posting frowned upon? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Sat, Aug 17, 2019 at 11:01 AM zb4ng <zb4ng@arcor.de> wrote:
On my desktop, there are two LEAP systems, 15.0 and 15.1. grub is managed by the older version 15.0.
Show grub.cfg from 15.0 and 15.1. Actually providing result of bootinfoscript (https://raw.githubusercontent.com/arvidjaar/bootinfoscript/master/bootinfosc...) would be the best to avoid lengthy (and usually misleading) descriptions.
Now, i found that on 15.1, an old version of the kernel is used rather than the latest patch:
This is most likely incorrect. I expect grub.cfg on 15.1 to default to latest version (unless you set defaults explicitly) but grub.cfg from 15.1 is not used by bootloader of 15.0. ...
I figured, I should let grub refresh its boot entries, so I started the boot configuration in Yast on 15.0, but had no success with it.
It is not clear what you did and what "no success" means (did it fail? If yes, what was the error message?), but unless you have changed something in bootloader configuration simply entering and quitting YaST botloader module won't do anything. Try "update-bootloader --refresh" in 15.0.
Maybe, i could simply delete the old kernels manually? But how can i avoid this from happening every time a new patch is released?
Assuming you have default configuration that is using os-prober to incorporate bootloader entries from one Linux instance into bootloader configuration of another Linux instance - this is one time static process. If Linux A is managing bootloader, it scans grub.cfg of Linux B once - and is not aware of any changes in Linux B after that. You will need to refresh bootloader in Linux A (using e.g. command shown above) every time something in Linux B changes. Not that refresh happens implicitly when something changes in Linux A as well (e.g. new kernel installed). Alternative is to not use os-prober, but manually configure bootloader in Linux A to call bootloader of Linux B directly. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stumbled accidentally over a way to boot the kernel: you can select "Advanced Options ..." for every Linux installation and then you get a submenu where you can choose the kernel. It's not optimal, since the menu text is always the same ("openSuSE 15.1." or so) and I have to count to get the correct kernel. Should have found this earlier... :(, but it works for now. Am 17.08.19 um 10:01 schrieb zb4ng:
On my desktop, there are two LEAP systems, 15.0 and 15.1. grub is managed by the older version 15.0. Now, i found that on 15.1, an old version of the kernel is used rather than the latest patch:
~\:08:39:37 > uname -a Linux linux-riut 4.12.14-lp151.27-default #1 SMP Fri May 10 14:13:15 UTC 2019 (862c838) x86_64 x86_64 x86_64 GNU/Linux ~\:08:56:31 > uname -r 4.12.14-lp151.27-default ~\:08:56:39 >
The kernel patch in use seems to be the first of LEAP 15.1. Auto-Update is active and the new kernel really is installed:
~\:09:59:26 > ls -l /boot | grep vmlinuz lrwxrwxrwx 1 root root 35 16. Aug 20:23 vmlinuz -> vmlinuz-4.12.14-lp151.28.13-default -rw-r--r-- 1 root root 7331952 15. Mai 02:26 vmlinuz-4.12.14-lp151.27-default -rw-r--r-- 1 root root 7340144 15. Jul 13:25 vmlinuz-4.12.14-lp151.28.10-default -rw-r--r-- 1 root root 7344240 11. Aug 10:54 vmlinuz-4.12.14-lp151.28.13-default ~\:09:59:26 >
There are no such problems on the 15.0-system.
I figured, I should let grub refresh its boot entries, so I started the boot configuration in Yast on 15.0, but had no success with it.
Maybe, i could simply delete the old kernels manually? But how can i avoid this from happening every time a new patch is released?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (4)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
zb4ng