Bootloader installation and configuration |
include/bootloader/routines/lilolike.ycp |
Functions common for lilo-like bootloaders only | |
|
|
This module has an unstable interface. |
Imports
Includes
Global Functions
Local Functions |
Is embedding 1.5 stage of bootloader to dedicated partition area possible?
- Return value:
-
true if it is possible
Check whether disk settings were changed since last checking
- Return value:
-
true if needs to recheck
FindMbrDisk() try to find the system's mbr device
- Return value:
-
mbr device
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
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
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
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
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
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.
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"
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).
Fix section of lilo-like bootloader
Update sections of bootloader menu modifies internal structures
- Parameters:
-
replace boolean true if old sectinos shall be replaced
Update global options of bootloader modifies internal sreuctures
Update the device map according to changed device names Read device map and store it in internal structures
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)
Remove or add initrd option if needed, update append option if some parameters were changed
Update append option if some parameters were changed
Update the gfxboot/message/... line if exists
Returns true if any device from list devices is in device_mapping marked as hd0.
- Parameters:
-
devices
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
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
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.
Get the order of disks according to BIOS mapping
- Return value:
-
a list of all disks in the order BIOS sees them
Get the summary of disks order for the proposal
- Return value:
-
a line for the summary (or nil if not intended to be shown)
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