SLES10SP3 32 Bit - Unable to boot a kernel after all packages are installed
This document (7004961) is provided subject to the disclaimer at the end of this document.
Environment
SUSE Linux Enterprise Server 10 SP3
Situation
After selecting all packages for the installation of SUSE Linux Enterprise Server 10 Service Pack 3 32 Bit, the kernel is missing in menu.lst after the installation has finished, and server is rebooted.
Resolution
The reason for this behavior is that on i386, vmi, vmipae and kdumppae kernel flavours were added to the media
From the SUSE Linux Enterprise Server 10 SP3 Release Notes:
"Be aware that selecting all patterns will cause the VMI kernel to be installed and set as the default boot kernel. VMI is intended only for VMware guests and is not guaranteed to boot on bare metal.
If you do not intend to install the VMI kernel, deselect the package by choosing "Details", then search for VMI package and clear the installation checkbox."
How to fix this problem:
--------------------------
Enable configuration of all kernels during installation is discouraged. It is not impossible to do, but it is discouraged. Outside the User Interface itself the existing code is not usable for this and in addition it is really complicated. There are some other supported features which are not easy for maintenance like allow existing old versions of kernels after update etc. Enable configuration of all kernels increase maintenance for any update/downgrade of kernel and it is not usable with existing code.
When you really have a need to add multiple kernels to menu.lst this needs to be done manually after the initial server installation by using yast2-bootloader and not at installation time.
An alternative may be the usage of an autoyast.xml file where the bootloader configuration is already defined.
From the SUSE Linux Enterprise Server 10 SP3 Release Notes:
"Be aware that selecting all patterns will cause the VMI kernel to be installed and set as the default boot kernel. VMI is intended only for VMware guests and is not guaranteed to boot on bare metal.
If you do not intend to install the VMI kernel, deselect the package by choosing "Details", then search for VMI package and clear the installation checkbox."
How to fix this problem:
--------------------------
Enable configuration of all kernels during installation is discouraged. It is not impossible to do, but it is discouraged. Outside the User Interface itself the existing code is not usable for this and in addition it is really complicated. There are some other supported features which are not easy for maintenance like allow existing old versions of kernels after update etc. Enable configuration of all kernels increase maintenance for any update/downgrade of kernel and it is not usable with existing code.
When you really have a need to add multiple kernels to menu.lst this needs to be done manually after the initial server installation by using yast2-bootloader and not at installation time.
An alternative may be the usage of an autoyast.xml file where the bootloader configuration is already defined.
Additional Information
Background information :
Installation SLE10 SP3:
-------------------------------------
During the installation, yast2-bootloader proposes 2 basic boot sections: being default and failsafe for the kernel. Both of them use symlinks /boot/initrd and /boot/vmlinuz.
A standard installation chooses only one kernel and the goal of yast2-bootloader is to propose a bootloader configuration for booting the OS. It doesn't handle multiple types of kernels (with exception of the XEN kernel).
yast2-bootloader also prepares the OS for booting, and therefore when a user selects more than 1 kernel for installation (with exception of the XEN kernel) the proposal of yast2-bootloader ignores this and still only works with the 2 proposed boot sections (default and failsafe).
At the end of the installation (after the installation of all the packages) are the symlinks (/boot/initrd and /boot/vmlinuz) resolved and the result is that default and failsafe boot section points to the last installed kernel.
This finally results in the fact that menu.lst includes 2 boot sections for one kernel. When several kernels are selected and installed, only one of them is configured for booting (the last installed kernel).
The main goal is enable booting of the OS, not to add all available kernels to menu.lst and enable the configuration for booting each of these kernels. It is possible to add other kernel flavors later manually, or during installation, but yast2-bootloader proposes only 2 basic boot sections without any special handling type of selected kernel (except XEN kernel).
When a user wants to add his own boot section during installation time, it is necessary for him to know what he really wants to do. The adding 'own boot section' appears to be easy, but often leads to adding wrong configuration data and finally end up in the boot section being deleted. It is for example necessary to take care off the absolute path for options: "Kernel Image" and "Initial RAM Disk".
Installation SLE11:
--------------------------
This works similar as the installation of SLE10 SP3 but there is difference in the handling of installation for the kernel packages.
During installation time the yast2-bootloader proposes two basic boot sections, but before installation of the packages it saves the configuration, resp. kernel args to /etc/sysconfig/bootloader.
During installation of the kernel package this post-install script (from perl-Bootloader) reads the configuration from /etc/sysconfig/bootloader and it uses the saved configuration for adding the kernel to the bootloader configuration resp. add the kernel to menu.lst. This is what is causing all selected kernels to be added to menu.lst respectively why it is possible to select them from the boot menu in GRUB.
This is the same problem for all kernels (except for the XEN kernel) as it is uses the same configuration data. It is not possible to add different kernel args for e.g. PAE kernel and VMI kernel.
When the user will modify the data that is proposed in the boot sections during installation, these changes will be applied for all installed kernels. A proposed "default" boot section is used like a template at this point and this configuration data is than used by the post-install script of the kernel package.
Finally at the end of the installation, the yast2-bootloader re-reads the configuration of the bootloader and makes a few modifications, like for example it deletes the same boot sections, resolve symlinks or delete invalid boot sections etc. The result of all this is that the bootloader configuration will include all kernels, with the same arguments for each kernel.
Please remember that the primary goal is still to enable and boot the Operating System, not to enable the configuration of all selected kernels at, or during, installation time. Therefor when a user is not satisfied with the configuration of the boot section for specific kernels, he should change this manually later after the installation by using yast2-bootloader.
(BTW: This problem for both SLE10SP3 and SLE11 can be resolved by using an autoyast profile where the completed configuration of the bootloader is defined.
Installation SLE10 SP3:
-------------------------------------
During the installation, yast2-bootloader proposes 2 basic boot sections: being default and failsafe for the kernel. Both of them use symlinks /boot/initrd and /boot/vmlinuz.
A standard installation chooses only one kernel and the goal of yast2-bootloader is to propose a bootloader configuration for booting the OS. It doesn't handle multiple types of kernels (with exception of the XEN kernel).
yast2-bootloader also prepares the OS for booting, and therefore when a user selects more than 1 kernel for installation (with exception of the XEN kernel) the proposal of yast2-bootloader ignores this and still only works with the 2 proposed boot sections (default and failsafe).
At the end of the installation (after the installation of all the packages) are the symlinks (/boot/initrd and /boot/vmlinuz) resolved and the result is that default and failsafe boot section points to the last installed kernel.
This finally results in the fact that menu.lst includes 2 boot sections for one kernel. When several kernels are selected and installed, only one of them is configured for booting (the last installed kernel).
The main goal is enable booting of the OS, not to add all available kernels to menu.lst and enable the configuration for booting each of these kernels. It is possible to add other kernel flavors later manually, or during installation, but yast2-bootloader proposes only 2 basic boot sections without any special handling type of selected kernel (except XEN kernel).
When a user wants to add his own boot section during installation time, it is necessary for him to know what he really wants to do. The adding 'own boot section' appears to be easy, but often leads to adding wrong configuration data and finally end up in the boot section being deleted. It is for example necessary to take care off the absolute path for options: "Kernel Image" and "Initial RAM Disk".
Installation SLE11:
--------------------------
This works similar as the installation of SLE10 SP3 but there is difference in the handling of installation for the kernel packages.
During installation time the yast2-bootloader proposes two basic boot sections, but before installation of the packages it saves the configuration, resp. kernel args to /etc/sysconfig/bootloader.
During installation of the kernel package this post-install script (from perl-Bootloader) reads the configuration from /etc/sysconfig/bootloader and it uses the saved configuration for adding the kernel to the bootloader configuration resp. add the kernel to menu.lst. This is what is causing all selected kernels to be added to menu.lst respectively why it is possible to select them from the boot menu in GRUB.
This is the same problem for all kernels (except for the XEN kernel) as it is uses the same configuration data. It is not possible to add different kernel args for e.g. PAE kernel and VMI kernel.
When the user will modify the data that is proposed in the boot sections during installation, these changes will be applied for all installed kernels. A proposed "default" boot section is used like a template at this point and this configuration data is than used by the post-install script of the kernel package.
Finally at the end of the installation, the yast2-bootloader re-reads the configuration of the bootloader and makes a few modifications, like for example it deletes the same boot sections, resolve symlinks or delete invalid boot sections etc. The result of all this is that the bootloader configuration will include all kernels, with the same arguments for each kernel.
Please remember that the primary goal is still to enable and boot the Operating System, not to enable the configuration of all selected kernels at, or during, installation time. Therefor when a user is not satisfied with the configuration of the boot section for specific kernels, he should change this manually later after the installation by using yast2-bootloader.
(BTW: This problem for both SLE10SP3 and SLE11 can be resolved by using an autoyast profile where the completed configuration of the bootloader is defined.
Disclaimer
This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.
- Document ID:7004961
- Creation Date: 02-Dec-2009
- Modified Date:21-Dec-2021
-
- SUSE Linux Enterprise Server
For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com
