YaST2 Developers Documentation: Bootloader installation and configuration

Bootloader installation and configuration

include/bootloader/routines/lilolike.ycp
Functions common for lilo-like bootloaders only
  • Jiri Srain
  • Olaf Dabrunz

This module has an unstable interface.

Imports

  • Arch
  • BootArch
  • Map
  • Mode
  • Storage
  • StorageDevices

Includes

  • bootloader/routines/i386.ycp

Global Functions

Local Functions

Info:

Is embedding 1.5 stage of bootloader to dedicated partition area possible?

Return value:
true if it is possible
global DisksChanged () -> boolean

Check whether disk settings were changed since last checking

Return value:
true if needs to recheck
global FindMBRDisk () -> string

FindMbrDisk() try to find the system's mbr device

Return value:
mbr device
local soft_MDraid_boot_disk (list<map> partitions) -> string

function check all partitions and it tries to find /boot partition if it is MD Raid and soft-riad return correct device for analyse MBR

Parameters:
partitions
Return value:
device for analyse MBR
Info:

ConfigureLocation() Where to install the bootloader. Returns the type of device where to install: one of "boot", "root", "mbr", "mbr_md" Also sets internal global variable selected_location to this.

Sets internal global variables: - selected_location to the type of bootloader device (currently one of: "boot", "root", "mbr", "mbr_md") - loader_device to the actual device name to install the bootloader to (e.g. "/dev/hda1") or to "mbr_md" - activate to true if the loader_device needs to be activated in the MBR - activate_changed leave untouched, except when - booting from a primary /boot partition on the first disk (the one with the MBR seen by the BIOS), then set to true (FIXME: why only then?) - repl_mbr leave untouched, except when - booting from a primary /boot partition on the first disk, then set to true when - the examination of the code in the MBR - by examine_mbr.pl shows that it - DOES NOT look like a valid "stage 1" at all (not enough entropy to contain valid code) OR - DOES NOT look like a "generic MBR" (= DOS MBR) (OK as stage 1 to boot primary part. on 1st disk) OR - DOES look like a LILO or GRUB MBR (replace them with generic code (if stage 1 is not in MBR, see code in updateMBR()), they probably contain an obsolete block list for stage 2) OR - DOES look like some "stage 1" code (has enough entropy, but no known signature) OR - by KeepMBR() -> ThinkPadMBR() shows that it - DOES NOT look like a Thinkpad MBR (begins with specific code sequence from that one) otherwise set to false

Return value:
type of location proposed to bootloader
global DetectDisks () -> void

Detect /boot and / (root) partition devices If loader_device is empty or the device is not available as a boot partition, also calls ConfigureLocation to configure loader_device, set selected_location and set the activate flag if needed all these settings are stored in internal variables

global Md2Partitions (string md_device) -> map<string, integer>

Converts the md device to the list of devices building it

Parameters:
md_device string md device
Return value:
a map of devices (from device name to BIOS ID or nil if not detected) building the md device
global Md2Partition (string md_device) -> string

Converts the md device to the first of its members

Parameters:
md_device string md device
Return value:
one of devices building the md array
global RunDelayedUpdates () -> void

Run delayed updates

This is used by perl-Bootloader when it cannot remove sections from the bootloader configuration from the postuninstall-script of the kernel. It writes a command to a delayed update script that is then called here to remove these sections.

Info:

fallback list for kernel flavors (adapted from Kernel.ycp), used if we have no better information order is from special to general, but prefer "default" in favor of "xen"

global FixGlobals () -> void

Fix global section of lilo-like bootloader

This currently only tries to fix the "default" key if necessary. It is when the referenced section does not exist anymore or during a system update when a special comment in the bootloader configuration tells us that we have to update the "default" key. An empty "default" value is not changed, because this means that no default is wanted.

If we need to fix the "default" key we take the following steps:

- If we are fixing the configuration at the end of an update and the special key "former_default_image_flavor" exists, try to set the default to the first "linux.*" section with an image of this flavor (preferring "linux" entries over possibly older "linux-.*" entries).

- Otherwise go through a list of fallback kernel flavours and use the first "linux.*" section that contains a matching image (preferring "linux" entries over possibly older "linux-.*" entries).

global FixSections () -> void

Fix section of lilo-like bootloader

global UpdateSections (boolean replace) -> void

Update sections of bootloader menu modifies internal structures

Parameters:
replace boolean true if old sectinos shall be replaced
global UpdateGlobals () -> void

Update global options of bootloader modifies internal sreuctures

global UpdateDeviceMap () -> void

Update the device map according to changed device names Read device map and store it in internal structures

global RemoveUnexistentSections (string path_prefix, string relative_path_prefix) -> void

Filter sections, remove those pointing to unexistent image

Parameters:
path_prefix string prefix to be added to kernel path
relative_path_prefix prefix to be added to relative kernel paths (without leading slash)
global UpdateInitrdLine () -> void

Remove or add initrd option if needed, update append option if some parameters were changed

global UpdateAppend () -> void

Update append option if some parameters were changed

global UpdateGfxMenu () -> void

Update the gfxboot/message/... line if exists

local isHd0 (list<string> devices) -> boolean

Returns true if any device from list devices is in device_mapping marked as hd0.

Parameters:
devices
local getKey (string value, map<string, string> mapping) -> string

Returns first key from mapping associated with value. Example: map = $[ "a" : "1", "b" : "2", "c" : "3", "d" : "2"]; getDeviceFromMapping("1", map) -> "a" getDeviceFromMapping("2", map) -> "b"

Parameters:
value
mapping
local changeOrderInDeviceMapping (list<string> bad_devices) -> void

This function changes order of devices in device_mapping. All devices listed in bad_devices are maped to "hdN" are moved to the end (with changed number N). And second step is putting device with boot partition on top (i.e. device_mapping[dev_with_boot] = "hd0").

Example: device_mapping = $[ "/dev/sda" : "hd0", "/dev/sdb" : "hd1", "/dev/sdc" : "hd2", "/dev/sdd" : "hd3", "/dev/sde" : "hd4" ]; bad_devices = [ "/dev/sda", "/dev/sdc" ];

Parameters:
bad_devices
Info:

Generate device map proposal, store it in internal variables.

FATE #302075: When user is installing from USB media or any non IDE disk or bios simply set any non IDE disk as first and user is not installing on this removable (non IDE) disk, the order of disks proposed by bios must be changed because of future remove of USB disk. This function must find right place for bootloader (which is most probably boot sector of boot partition (where /boot dir is located)) and change the order of disks in device map. This method is only heuristic because order of disks after remove of usb disk can't be determined by any method.

global DisksOrder () -> list<string>

Get the order of disks according to BIOS mapping

Return value:
a list of all disks in the order BIOS sees them
global DiskOrderSummary () -> string

Get the summary of disks order for the proposal

Return value:
a line for the summary (or nil if not intended to be shown)
local ConvertXENinDomU () -> boolean

Convert XEN boot section to normal linux section if intalling in domU (bnc #436899)

Return value:
true if XEN section is converted to linux section