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