How to Hold/Lock a specific kernel in place openSUSE TW?
I recently attempted to Hold/Lock a specific kernel in place on openSUSE TW. My hardware is 32 bit so I am currently inhibited by having to load a specific kernel-release (a newer release is not allowing the computer to boot). See the following link if you are interested in more details on the filed bug report: -> https://bugzilla.opensuse.org/show_bug.cgi?id=1185542 I edited the following file with Kate text editor /etc/zypp/zypp.conf scrolled down to line 554 and edited the following entry to: multiversion.kernels = latest,running,5.11.16-1-pae " Keep the last two kernels and the one currently running. multiversion.kernels = latest,running,5.11.16-1-pae " I saved the edited file and closed Kate. I then opened /etc/zypp/zypp.conf and verified that in fact the entry I created had been saved. Then I powercycled the computer (maybe twice I am not certain-most likely only once). Needless to say that the boot menu has no more listing for "kernel-5.11.16-1-pae". There were 2 listing's for kernel-5.12.series (both unbootable). I have been reviewing the following link concerning this: > https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-tuning-multiker... 1. I really would like to ask as to if the reason for failing to hold the "kernel-5.11.16-1-pae" was/is this because of the fact I edited the zypp.conf file's entry incorrectly by adding the "kernel-flavor" suffix (5.11.16-1-pae <-Not Entering-> 5.11.16-1) instead? 2. What is the best way to Hold/Lock the running kernel? 3. is YaST2 sometimes used for this task? Thanks :|
-pj wrote:
I recently attempted to Hold/Lock a specific kernel in place on openSUSE TW. My hardware is 32 bit so I am currently inhibited by
I have never had the need to lock a specific kernel version, but otherwise I simply use 'zypper al whatever'. To prevent installation or upgrade. For instance, I have postfix and bind packages that I need to build/patch myself, so they are locked. -- Per Jessen, Zürich (12.1°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland.
On 2021-05-06 11:03, Per Jessen wrote:
Paul wrote:
I recently attempted to Hold/Lock a specific kernel in place on openSUSE TW. My hardware is 32 bit so I am currently inhibited by I have never had the need to lock a specific kernel version, but otherwise I simply use 'zypper al whatever'. To prevent installation or upgrade. For instance, I have postfix and bind packages that I need to build/patch myself, so they are locked.
I choose another way. See:https://en.opensuse.org/SDB:Keep_multiple_kernel_versions in /etc/zypp/zypp.conf I have: multiversion = provides:multiversion(kernel) multiversion.kernels = latest,latest-5,running,5.8.12-1-default,5.8.12-1 This keeps 5.8.12-1-default or 5.8.12-1 as a persistent kernel entry for me. I did this in October 2020 and it has worked since then. I'm not sure if some of "latest,latest-5,running,5.8.12-1-default,5.8.12-1" is redundant but as long as it doesn't remove 5.8.12 I'm good. -- /bengan
On 06/05/2021 10.58, -pj wrote:
I recently attempted to Hold/Lock a specific kernel in place on openSUSE TW. My hardware is 32 bit so I am currently inhibited by having to load
a specific kernel-release (a newer release is not allowing the computer
to boot). See the following link if you are interested in more details on the filed bug report: -> https://bugzilla.opensuse.org/show_bug.cgi?id=1185542
I edited the following file with Kate text editor /etc/zypp/zypp.conf scrolled down to line 554 and edited the following entry to: multiversion.kernels = latest,running,5.11.16-1-pae
" Keep the last two kernels and the one currently running.
multiversion.kernels = latest,running,5.11.16-1-pae "
I think it is correct.
I saved the edited file and closed Kate. I then opened /etc/zypp/zypp.conf and verified that in fact the entry I created had been saved. Then I powercycled the computer (maybe twice I am not certain-most likely only once). Needless to say that the boot menu has no more listing for "kernel-5.11.16-1-pae". There were 2 listing's for kernel-5.12.series (both unbootable).
Wait, what you edited does not touch the boot menu at all. What it does is making zypper keep that kernel when you do updates. And rebooting is pointless to test that edit, you have to try "zypper up --test" or something like that. The boot menu is handled by grub2. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 5/6/21 4:17 AM, Carlos E. R. wrote:
On 06/05/2021 10.58, -pj wrote:
I recently attempted to Hold/Lock a specific kernel in place on openSUSE TW. My hardware is 32 bit so I am currently inhibited by having to load
a specific kernel-release (a newer release is not allowing the computer
to boot). See the following link if you are interested in more details on the filed bug report: -> https://bugzilla.opensuse.org/show_bug.cgi?id=1185542
I edited the following file with Kate text editor /etc/zypp/zypp.conf scrolled down to line 554 and edited the following entry to: multiversion.kernels = latest,running,5.11.16-1-pae
" Keep the last two kernels and the one currently running.
multiversion.kernels = latest,running,5.11.16-1-pae "
I think it is correct.
I saved the edited file and closed Kate. I then opened /etc/zypp/zypp.conf and verified that in fact the entry I created had been saved. Then I powercycled the computer (maybe twice I am not certain-most likely only once). Needless to say that the boot menu has no more listing for "kernel-5.11.16-1-pae". There were 2 listing's for kernel-5.12.series (both unbootable).
Wait, what you edited does not touch the boot menu at all. What it does is making zypper keep that kernel when you do updates. And rebooting is pointless to test that edit, you have to try "zypper up --test" or something like that.
The boot menu is handled by grub2.
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b... -Regards
-pj composed on 2021-05-06 07:12 (UTC-0500):
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b...
That section is obsolete for any openSUSE release of the past several years. Grub (Legacy) and Grub2 (current) are very different bootloaders. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/
On 06/05/2021 20.39, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b...
That section is obsolete for any openSUSE release of the past several years. Grub (Legacy) and Grub2 (current) are very different bootloaders.
You are right, the first photo in that documentation is obsolete. pj, the official docs are at https://doc.opensuse.org/ There is: <https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-boot.html#sec-boot-proc> 9.2.1 The Initialization and Boot Loader Phase and: <https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-grub2.html> 12 The Boot Loader GRUB 2 In particular, you may need to use the variable "GRUB_DEFAULT". Pr using YaST, see "12.3.3.1 Boot Loader Options Tab", there is a "default boot section" entry. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 5/6/21 2:53 PM, Carlos E. R. wrote:
On 06/05/2021 20.39, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b...
That section is obsolete for any openSUSE release of the past several years. Grub (Legacy) and Grub2 (current) are very different bootloaders.
You are right, the first photo in that documentation is obsolete.
pj, the official docs are at https://doc.opensuse.org/
There is:
9.2.1 The Initialization and Boot Loader Phase
and:
<https://doc.opensuse.org/documentation/leap/reference/html/book-opensuse-reference/cha-grub2.html>
12 The Boot Loader GRUB 2
In particular, you may need to use the variable "GRUB_DEFAULT". Pr using YaST, see "12.3.3.1 Boot Loader Options Tab", there is a "default boot section" entry. Thank you for the links above: I really like this "Configuring boot loader with YaST" capability. :|
On 06/05/2021 23.17, -pj wrote:
On 5/6/21 2:53 PM, Carlos E. R. wrote:
On 06/05/2021 20.39, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
12 The Boot Loader GRUB 2
In particular, you may need to use the variable "GRUB_DEFAULT". Pr using YaST, see "12.3.3.1 Boot Loader Options Tab", there is a "default boot section" entry. Thank you for the links above: I really like this "Configuring boot loader with YaST" capability. :|
Then, a trick. To force YaST bootloader module to write and update all the boot files, just change 1 second up or down the timeout (figure 12.4) -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 5/6/21 5:30 PM, Carlos E. R. wrote:
On 06/05/2021 23.17, -pj wrote:
On 5/6/21 2:53 PM, Carlos E. R. wrote:
On 06/05/2021 20.39, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
12 The Boot Loader GRUB 2
In particular, you may need to use the variable "GRUB_DEFAULT". Pr using YaST, see "12.3.3.1 Boot Loader Options Tab", there is a "default boot section" entry. Thank you for the links above: I really like this "Configuring boot loader with YaST" capability. :|
Then, a trick.
To force YaST bootloader module to write and update all the boot files, just change 1 second up or down the timeout (figure 12.4)
That's a neat trick above. So if I were to only click "OK" which then leads to YaST exiting. I should go to Bootloader Options adjust the timeout then click ok (Just for certain). Now the following question is I feel still on topic for the post in a way perhaps I am incorrect on this: 1. What about now being able to enable "Trusted Boot Support"? Since the issue (for this terminal/computer) has in fact been repaired upstream (see here): > https://bugzilla.opensuse.org/show_bug.cgi?id=1185023 < I can verify on my terminal/computer that the (TDE) installation DOES COMPLETE NOW while connected to the mirrors/internet. The only problem of course being kernel 5.12.0-2-pae will fail to load once being selected at bootmenu. That is why I installed (TDE) offline with a kernel 5.11.series .iso then was able to use " zypper install https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.11/standar..." to draw in the most current (kernel 5.11.16-1.ge06d321-default) and use YaST to lock the package. 2. So I believe I can use the YaST bootloader module to enable "Trusted Boot Support" at this point. Then change timeout - tick OK....Powercycle....Without issues? 3. Would this be a fairly safe assumption? Thanks
On 07/05/2021 01.15, -pj wrote:
On 5/6/21 5:30 PM, Carlos E. R. wrote:
On 06/05/2021 23.17, -pj wrote:
On 5/6/21 2:53 PM, Carlos E. R. wrote:
On 06/05/2021 20.39, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
12 The Boot Loader GRUB 2
In particular, you may need to use the variable "GRUB_DEFAULT". Pr using YaST, see "12.3.3.1 Boot Loader Options Tab", there is a "default boot section" entry. Thank you for the links above: I really like this "Configuring boot loader with YaST" capability. :|
Then, a trick.
To force YaST bootloader module to write and update all the boot files, just change 1 second up or down the timeout (figure 12.4)
That's a neat trick above. So if I were to only click "OK" which then leads to YaST exiting. I should go to Bootloader Options adjust the timeout then click ok (Just for certain).
Yep :-)
Now the following question is I feel still on topic for the post in a way perhaps I am incorrect on this:
1. What about now being able to enable "Trusted Boot Support"? Since the issue (for this terminal/computer) has in fact been repaired upstream (see here): > https://bugzilla.opensuse.org/show_bug.cgi?id=1185023 < I can verify on my terminal/computer that the (TDE) installation DOES COMPLETE NOW while connected to the mirrors/internet. The only problem of course being kernel 5.12.0-2-pae will fail to load once being selected at bootmenu. That is why I installed (TDE) offline with a kernel 5.11.series .iso then was able to use " zypper install https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.11/standar..." to draw in the most current (kernel 5.11.16-1.ge06d321-default) and use
YaST to lock the package.
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though. I assume it is not the same thing as signed boot files and kernels used by EFI. But your machine being 32 bits, it can not have EFI.
2. So I believe I can use the YaST bootloader module to enable "Trusted
Boot Support" at this point. Then change timeout - tick OK....Powercycle....Without issues?
3. Would this be a fairly safe assumption?
I don't know, and it is not something I want to test on real hardware. Maybe on a virtual machine. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 5/6/21 7:14 PM, Carlos E. R. wrote:
On 07/05/2021 01.15, -pj wrote:
On 5/6/21 5:30 PM, Carlos E. R. wrote:
On 06/05/2021 23.17, -pj wrote:
On 5/6/21 2:53 PM, Carlos E. R. wrote:
On 06/05/2021 20.39, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
12 The Boot Loader GRUB 2
In particular, you may need to use the variable "GRUB_DEFAULT". Pr using YaST, see "12.3.3.1 Boot Loader Options Tab", there is a "default boot section" entry. Thank you for the links above: I really like this "Configuring boot loader with YaST" capability. :|
Then, a trick.
To force YaST bootloader module to write and update all the boot files, just change 1 second up or down the timeout (figure 12.4)
That's a neat trick above. So if I were to only click "OK" which then leads to YaST exiting. I should go to Bootloader Options adjust the timeout then click ok (Just for certain).
Yep :-)
Now the following question is I feel still on topic for the post in a way perhaps I am incorrect on this:
1. What about now being able to enable "Trusted Boot Support"? Since the issue (for this terminal/computer) has in fact been repaired upstream (see here): > https://bugzilla.opensuse.org/show_bug.cgi?id=1185023 < I can verify on my terminal/computer that the (TDE) installation DOES COMPLETE NOW while connected to the mirrors/internet. The only problem of course being kernel 5.12.0-2-pae will fail to load once being selected at bootmenu. That is why I installed (TDE) offline with a kernel 5.11.series .iso then was able to use " zypper install https://download.opensuse.org/repositories/home:/tiwai:/kernel:/5.11/standar..." to draw in the most current (kernel 5.11.16-1.ge06d321-default) and use
YaST to lock the package.
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though.
I assume it is not the same thing as signed boot files and kernels used by EFI. But your machine being 32 bits, it can not have EFI. You are correct I believe. The machine has legacy boot option with no UEFI capability nor does it have secure boot capability.
2. So I believe I can use the YaST bootloader module to enable "Trusted
Boot Support" at this point. Then change timeout - tick OK....Powercycle....Without issues?
3. Would this be a fairly safe assumption?
I don't know, and it is not something I want to test on real hardware. Maybe on a virtual machine.
That's a good point. Setup a Container with Virtualbox. hmm Thanks for all the advice on this matter.
On 2021-05-06 8:14 p.m., Carlos E. R. wrote:
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though.
indeed. Anything that Microsoft has 'touched' scares me. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
On 5/7/21 6:04 AM, Anton Aylward wrote:
On 2021-05-06 8:14 p.m., Carlos E. R. wrote:
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though.
indeed. Anything that Microsoft has 'touched' scares me. My implementation of Grub2 Trusted Boot Support on this laptop appears to me to function. Obviously I do not know any real details about the difference between Grub2 and Grub2 Trusted Boot Support. I would have never thought at a glance that Microsoft had involvement in the development of this. Thanks for your input on this matter.
On 08/05/2021 05.43, -pj wrote:
On 5/7/21 6:04 AM, Anton Aylward wrote:
On 2021-05-06 8:14 p.m., Carlos E. R. wrote:
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though.
indeed. Anything that Microsoft has 'touched' scares me. My implementation of Grub2 Trusted Boot Support on this laptop appears to me to function. Obviously I do not know any real details about the difference between Grub2 and Grub2 Trusted Boot Support. I would have never thought at a glance that Microsoft had involvement in the development of this. Thanks for your input on this matter.
Generally, people think that all that is a Microsoft thing. After all, the keys used by Linux have to vetted by Microsoft or something. A quick search - the "microsoft" word appears many times in these two articles: <https://wiki.ubuntu.com/UEFI/SecureBoot> <https://en.opensuse.org/openSUSE:UEFI> Google "What is secure boot and trusted boot?" http://cdn.openpowerfoundation.org/wp-content/uploads/resources/openpower-re... "Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. ... Secure Boot prevents the system from executing either accidentally or maliciously modified firmware.Apr 19, 2018" 2.3. Trusted Boot and Secure Boot Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. Trusted Boot artifacts can be used to remotely verify system integrity or to seal secrets to that they are only available after certain firmware has executed. Secure Boot is the cryptographic signing and verification of firmware boot components, failure of which is flagged for system administrator investigation and action, including logging an error and halting the system boot. Secure Boot prevents the system from executing either accidentally or maliciously modified firmware. To achieve Trusted Boot and Secure Boot OpenPOWER Readiness, a system must: 1 Include a Trusted Platform Module (TPM), a small embedded security processor that conforms to the Trusted Computing Group TPM 2.0 specification that can securely store data. 2 Create a firmware measurement log and extend appropriate measurements to PCRs in the TPM as documented in the op-build source code and design documentation when in Trusted Boot mode. 3 Be able to store firmware components in Processor NOR (PNOR) flash memory that are packaged and signed in accordance with the op-build source code and design documentation, to support secure boot of firmware 4 Reserve a region in PNOR for storing OS-specific signatures and keys, to support secure boot of the target Operating System. 5 Provide a platform-specific method to assert physical presence to bypass Secure Boot for system recovery. In order to use existing OpenPOWER firmware support: 1 The TPM processor should be compatible with the Nuvoton NPCT 650 and should be connected to the CPU via an I2C bus. 2 Firmware components must be packaged and signed in accordance with the op-build source code and design documentation. The foregoing applies to systems satisfying OpenPOWER Foundation Section 2.1, “ISA Profile rev 1.0.0 based systems” or Section 2.2, “ISA Profile rev 2.0.0 based systems”. Systems capable of supporting Trusted Boot and Secure Boot for firmware and operating system integrity verification and protection are recommended. -- Cheers / Saludos, Carlos E. R. (from 15.2 x86_64 at Telcontar)
On 5/8/21 5:32 AM, Carlos E. R. wrote:
On 08/05/2021 05.43, -pj wrote:
On 5/7/21 6:04 AM, Anton Aylward wrote:
On 2021-05-06 8:14 p.m., Carlos E. R. wrote:
I know nothing about Trusted Boot Support, sorry. It scares me a bit, though.
indeed. Anything that Microsoft has 'touched' scares me. My implementation of Grub2 Trusted Boot Support on this laptop appears to me to function. Obviously I do not know any real details about the difference between Grub2 and Grub2 Trusted Boot Support. I would have never thought at a glance that Microsoft had involvement in the development of this. Thanks for your input on this matter.
Generally, people think that all that is a Microsoft thing. After all, the keys used by Linux have to vetted by Microsoft or something.
A quick search - the "microsoft" word appears many times in these two articles:
<https://wiki.ubuntu.com/UEFI/SecureBoot> <https://en.opensuse.org/openSUSE:UEFI>
Google "What is secure boot and trusted boot?"
http://cdn.openpowerfoundation.org/wp-content/uploads/resources/openpower-re...
"Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. ... Secure Boot prevents the system from executing either accidentally or maliciously modified firmware.Apr 19, 2018"
2.3. Trusted Boot and Secure Boot
Trusted Boot is the measurement (hashing) of system firmware boot components and the creation of secure cryptographic artifacts that unambiguously demonstrate that particular firmware has been executed by the system. Trusted Boot artifacts can be used to remotely verify system integrity or to seal secrets to that they are only available after certain firmware has executed. Secure Boot is the cryptographic signing and verification of firmware boot components, failure of which is flagged for system administrator investigation and action, including logging an error and halting the system boot. Secure Boot prevents the system from executing either accidentally or maliciously modified firmware.
To achieve Trusted Boot and Secure Boot OpenPOWER Readiness, a system must:
1 Include a Trusted Platform Module (TPM), a small embedded security processor that conforms to the Trusted Computing Group TPM 2.0 specification that can securely store data.
2 Create a firmware measurement log and extend appropriate measurements to PCRs in the TPM as documented in the op-build source code and design documentation when in Trusted Boot mode.
3 Be able to store firmware components in Processor NOR (PNOR) flash memory that are packaged and signed in accordance with the op-build source code and design documentation, to support secure boot of firmware
4 Reserve a region in PNOR for storing OS-specific signatures and keys, to support secure boot of the target Operating System.
5 Provide a platform-specific method to assert physical presence to bypass Secure Boot for system recovery.
In order to use existing OpenPOWER firmware support:
1 The TPM processor should be compatible with the Nuvoton NPCT 650 and should be connected to the CPU via an I2C bus.
2 Firmware components must be packaged and signed in accordance with the op-build source code and design documentation. The foregoing applies to systems satisfying OpenPOWER Foundation Section 2.1, “ISA Profile rev 1.0.0 based systems” or Section 2.2, “ISA Profile rev 2.0.0 based systems”.
Systems capable of supporting Trusted Boot and Secure Boot for firmware and operating system integrity verification and protection are recommended. Thanks for the information on this.
Thank you for your response's. What I did in order to hold the 5.11.16-1.1.ge06d321 series kernel is open YaST2 -> Search (input -"kernel-default")....4 packages appeared 1. kernel-default The Standard Kernel 5.11.16-1.1.ge06d321 (5.12.0-2.1) 284.2 MiB <---- Right click square icon to left of package..scroll down to (Protected - Do Not Modify) selected the option. 2. kernel-default-base The standard Kernel - base modules (5.12.0-2.1.19.16) 53.3 MiB <---- Right click square icon to left of package...scroll down to (Taboo - Never Install) selected the option. 3. kernel-default-base-rebuild Empty package to ensure rebuilding kernel-default-base in OBS (5.12.0-2.1.19.16) 0 MiB <---- Right click square icon to left of package...scroll down to (Taboo - Never Install) selected the option. 4. kernel-default-devel Development files necessary for building kernel modules (5.12.0-2.1) 4.4 MiB <---- Right click square icon to left of package...scroll down to (Taboo - Never Install) selected the option. 5. Clicked Accept......YaST2 exited automatically 6. Powercycled the computer/terminal :| 7. At bootmenu selected "Advanced options for openSUSE Tumbleweed" went to selection "openSUSE Tumbleweed. with linux 5.11.16-1-ge06d321-default <- selected kernel 8. Upon completely logging into KDE..opened Konsole...entered following command "uname-r"...5.11.16-1.ge06d321-default Done.....maybe :| -Regards On 5/6/21 1:39 PM, Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b...
That section is obsolete for any openSUSE release of the past several years. Grub (Legacy) and Grub2 (current) are very different bootloaders.
On 2021-05-06 2:39 p.m., Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b...
That section is obsolete for any openSUSE release of the past several years. Grub (Legacy) and Grub2 (current) are very different bootloaders.
More to the point: if you encounter the Legacy Grub what does that say about the machine, the OS, you are working with? While grub2 is way-fully more capable (for example in the sort of file system it can boot from [q.v. Gogoogle]) you don't NEED anything esoteric like a cryptoFS, RAID, UFI or whatever. In fact most of this thread is baffle-gab to me. It's not so much abut 'KISS' as s "it works fine (out of the box), why do you want to complicate it. I spent a great deal of my working life administering different flavours of UNIX, BSD, Linux (and on one occasion -shock/horror- even DEC VAX and in every case worked to simplify procedures and document them. often against management that wanted unwarranted complexity (people like lawyers of venture capitalists/deal brokers who are used to the 'rococo'). There are some good programmers out there who have given us powerful tools and gone to length to make them easy to apply. I think Grub2 comes into that category. -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg
On 5/7/21 6:03 AM, Anton Aylward wrote:
On 2021-05-06 2:39 p.m., Felix Miata wrote:
-pj composed on 2021-05-06 07:12 (UTC-0500):
I am reviewing this article (section: 11.2 Configuring the Boot Loader with YaST): > https://documentation.suse.com/sles/11-SP4/html/SLES-all/cha-grub.html#sec-b...
That section is obsolete for any openSUSE release of the past several years. Grub (Legacy) and Grub2 (current) are very different bootloaders.
More to the point: if you encounter the Legacy Grub what does that say about the machine, the OS, you are working with?
While grub2 is way-fully more capable (for example in the sort of file system it can boot from [q.v. Gogoogle]) you don't NEED anything esoteric like a cryptoFS, RAID, UFI or whatever. In fact most of this thread is baffle-gab to me. It's not so much abut 'KISS' as s "it works fine (out of the box), why do you want to complicate it.
I spent a great deal of my working life administering different flavours of UNIX, BSD, Linux (and on one occasion -shock/horror- even DEC VAX and in every case worked to simplify procedures and document them. often against management that wanted unwarranted complexity (people like lawyers of venture capitalists/deal brokers who are used to the 'rococo').
There are some good programmers out there who have given us powerful tools and gone to length to make them easy to apply. I think Grub2 comes into that category. That's interesting to hear your thoughts on this matter. I really do appreciate the insight that you provided. Also the help is really appreciated.
participants (6)
-
-pj -
Anton Aylward -
Bengt Gördén -
Carlos E. R. -
Felix Miata -
Per Jessen