| Age | Commit message (Collapse) | Author | Files |
|---|
|
getVar() now defaults to expanding by default, thus remove the True
option from getVar() calls with a regex search and replace.
Search made with the following regex: getVar ?\(( ?[^,()]*), True\)
Signed-off-by: Joshua Lock <joshua.g.lock@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
This sets a good example and avoids unnecessarily contributing to
perceived complexity and cargo culting.
Motivating quote below:
< kergoth> the *original* intent was for the function/task to error via
whatever appropriate means, bb.fatal, whatever, and
funcfailed was what you'd catch if you were calling
exec_func/exec_task. that is, it's what those functions
raise, not what metadata functions should be raising
< kergoth> it didn't end up being used that way
< kergoth> but there's really never a reason to raise it yourself
FuncFailed.__init__ takes a 'name' argument rather than a 'msg'
argument, which also shows that the original purpose got lost.
Signed-off-by: Ulf Magnusson <ulfalizer@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add a space between the root and append parameter, similar to
syslinux.bbclass, in creating the final grub.cfg.
Without this, the final kernel boot parameters will concatenate into
strings like root=/dev/ram0console=ttyS0...
Signed-off-by: Raymond Tan <raymond.tan@intel.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The path in startup.nsh for iso image is corrupted as follows:
fs0:\EFI\BOOT^Hootx64.efi
Using printf will emit correct path which is:
fs0:\EFI\BOOT\bootx64.efi
This happens because of echo command. Switching to printf
like the one used in efi_populate() function.
Signed-off-by: Pranav Tipnis <pranav.tipnis@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Signed-off-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
wic will be needing this for its bootimg-efi plugin.
[YOCTO #9556]
Signed-off-by: Christopher Larson <chris_larson@mentor.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Found some more syntax cleanups needed for python3.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Use APPEND for grub's root device may cause confusion, for example, when
building efi + pcbios, there maybe be two root=/dev/ram0, one of them
would be carried to the installed target, and the target would fail to
boot. Use GRUB_ROOT to fix the problem, and remove SYSLINUX_ROOT from
APPEND will fix the problem.
[YOCTO #9354]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
* Make it can build vm and live (e.g., iso + vmdk) together as we did
for syslinux.
* GRUBCFG -> GRUB_CFG as other GRUB_FOO vars
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
Fixed:
- Found potential conflicted var LABELS ...
Set LABELS to "boot install" would build out broken images when build
vm + live together, use set_live_vm_vars() to fix the problem.
- Use ROOT and LABEL in boot-directdisk.bbclass and image-foo.bbclass,
they are not only used by syslinux.bbclass, but also grub-efi.bbclass,
add "SYSLINUX_" prefix would mislead users.
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
when we generate hddimage and use it to prepare SD card
using scripts/contrib/mkefidisk.sh as described here
http://elinux.org/Minnowboard:MinnowMaxYoctoProject
The content of startup.nsh contains
bootx64.efi
but this file is actually not in same dir as startup.nsh
its in /EFI/BOOT so for this to work entry in startup.nsh
should be
fs0:\EFI\BOOT\bootx64.efi
Otherwise the image is D-O-A
Signed-off-by: Khem Raj <raj.khem@gmail.com>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
As mentioned when introducing the VM images
(https://bugzilla.yoctoproject.org/show_bug.cgi?id=7374), the
resulting images only work when the image is mounted as a disk that
results in the hard-coded path (/dev/sda in the current
default). Using the file system UUID to find the rootfs is more
flexible.
To enable this for boot-direct.bbclass and thus image-vm.bbclass (aka
FSTYPEs vdi/vmdk/qcow2), set SYSLINUX_ROOT =
"root=UUID=<<uuid-of-rootfs>>". The rootfs image must use an ext file
system.
The special string will get replaced in the APPEND line with the
actual UUID when the boot loader (grub-efi, syslinux or gummiboot)
writes the boot loader configuration files. At that time, the rootfs
image has already been created and its UUID can be extracted using
"tune2fs -l", which also should be available because the
e2fsprogs-native tools were needed to create the image in the first
place.
Signed-off-by: Patrick Ohly <patrick.ohly@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
To generate a same image both in live image type and boot-directdisk image type
and make boot-direct image boot directly on the rootfs partition without using
an initramfs we need to have the ability to generate several grub.cfg files.
Signed-off-by: Nicolas Guyomard <nicolas.guyomard@open.eurogiciel.org>
Signed-off-by: Ross Burton <ross.burton@intel.com>
|
|
The initrd image used by the Linux kernel is list of file system images
concatenated together and presented as a single initrd file at boot time.
So far the initrd is a single filesystem image. But in cases like to support
early microcode loading, the initrd image need to have multiple filesystem
images concatenated together.
This commit is extending the INITRD variable from a single filesystem image
to a list of filesystem images to satisfy the need mentioned above.
Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Add MLPREFIX to depends flag to ensure the correct grub-efi is
dependended upon.
Signed-off-by: Ming Liu <ming.liu@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Abstract away some names so one can select using EFI_PROVIDER a different
class than grub-efi for populating live images, basically allowing the use
of a different bootloader than grub-efi.
Signed-off-by: Stefan Stanacar <stefanx.stanacar@intel.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
To generate the target EFI image in a native package, it requires
the host gcc have the ability to do -m32/-m64 compiling, but gcc
doesn't have that support on the 32bit version of some distributions
(e.g. rehl, suse), it would fail when build a 64bit target on these
32bit hosts.
In fact, all we need from grub-efi-native is the grub-mkimage binary,
so change the solution to:
* grub-efi-native only install grub-mkimage
* grub-efi compiles target modules, generates EFI image
with grub-mkimage and deploy, but install nothing.
Signed-off-by: Jackie Huang <jackie.huang@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
Some revs of the EFI firmware + shell do not automatically setup the
path in a such a way as to execute a binary without an absolute
reference like "FS0:\EFI\BOOT\bootx64.efi". All the versions that I
have tested work properly by simply calling the binary which is in the
EFI\BOOT directory by name like "bootx64.efi".
The error you see on the console looks like the following:
startup.nsh> EFI\BOOT\bootx64.efi
'EFI\BOOT\bootx64.efi' is not recognized as an internal or external command, operable program, or batch file
Shell>
This patch simply drops the EFI\BOOT for greater compatibility.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
When boot-directdisk class is used and EFI boot is set the
grub-efi-${TRANSLATED_TARGET_ARCH}-native need to be dependent.
Allowing GRUB_IMAGE to be created and bootia32.efi got from the
image directory.
Signed-off-by: Joao Henrique Ferreira de Freitas <joaohf@gmail.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
|
|
The various populate methods need to accept a path as an argument vs
using hard expanded variables. In the case of the boot-directdisk
class it uses a different path for HDDDIR but it gets eclipsed by the
the class definition at the point in time ${HDDDIR} gets expanded.
The logical fix is to pass the arguments to the functions as opposed
to using globally expanded variables from the class definitions.
This patch changes 3 things:
1) syslinux_hddimg_populate takes an argument for the destination
2) syslinux_iso_populate takes an argument for the destination
3) populate is changed to boot_direct_populate because there
was a conflict with it overriding the populate in bootimg.bbclass
[YOCTO #3994]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The syslinux.bbclass already has support for automatically generated
serial and graphics menu choices. This patch adds the same concept to
the grub-efi menu. That makes it possible to generate a single image
which can boot on a PCBIOS or EFI firmware with consistent looking
boot options.
[YOCTO #4100]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Using the latest mkisofs it is possible to generate 3 different types
of ISO images, which can be used in various scenarios.
1) PCBIOS Only ISO
- This option remains unchanged by this commit
- Uses syslinux menus
- Can be directly copied with dd to a USB device
- Can be burned to optical media
2) EFI Only ISO
- Uses grub 2 menus
- Can be burned to optical media
- If you want to use this image on a USB device
extra steps must be taken in order to format the USB
device with fat32, and copy an EFI loader which will
in turn load the iso image
3) PCBIOS / EFI ISO
- This is a hybrid image ISO that will work for case 1 or 2
as above with the same restrictions and boot menu types
depending on what type of firmware is installed on
the hardware or depending on if EFI or "Legacy Boot" is
enabled on some UEFI firmwares.
The syslinux.bbclass is now always required because that is where the
isohybrid dependencies come from as well as the configuration data for
the isohybrid. The isohybrid is the secret sauce which allows the ISO
to work as optical media or as a disk image on USB or a HDD/SSD.
[YOCTO #4100]
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
Signed-off-by: Saul Wold <sgw@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
"ERROR: Nothing PROVIDES 'grub-efi-x86_64-native'" is returned when
trying to build meta-intel/meta-cedartrail with DEFAULTTUNE = "core2-64"
Used TRANSLATED_TARGET_ARCH instead of TARGET_ARCH in grub-efi.bbclass
[YOCTO #3013]
Signed-off-by: Mihai Lindner <mihaix.lindner@linux.intel.com>
|
|
It was pointed out we have a number of weird indentations in the python functions.
This patch cleans up 3, 7 and other weird indentations for the core bbclass files.
It also fixes some wierd (odd) shell function indentation which my searches picked up.
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
[YOCTO #1919]
Create a basic EFI installer script modeled after the existing installer
and add it to a new initramfs-live-install-efi recipe. Update the
init-live.sh script to distinguish between LABEL=install and
LABEL=install-efi and select the appropriate script. Add the efi
installer to core-image-minimal-initramfs.
Update grub-efi.bbclass to use "LABEL=install-efi" when it detects a
label of "install". This is clearly not ideal, but a proper fix would
involve decoupling the LABELS assignment from the image-live.bbclass
usage of SYSLINUX_LABELS. We should be able to address that in a
follow-on clean-up series.
V2: Include missing initramfs-live-install-efi_1.0.bb
V3: Rebase after Radu's console_params fix
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Fixes [YOCTO #1951]
The do_bootimg code can generate hybrid efi+pcbios images (syslinux and
grub-efi) to boot on platforms with both EFI and legacy BIOS options. The
current implementation copies the kernel, initrd, and rootfs twice,
unnecessarily bloating the image size. This is an especially egregious bug
on -sato images.
Update the classes to use a common install of the kernel, initrd, and rootfs to
the root of the boot media. Grub-efi, syslinux, and isolinux can all reference
this location explicitly with a leading slash.
Tested with an EFI+PCBIOS image in both EFI and PCBIOS boot modes on two
platforms. No ISO image testing was performed.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
|
|
[Yocto 1783] prevented us from using a proper /EFI/BOOT path in the live
images due to a bug in the -d patch for mkdosfs in dosfstools. With this
now fixed, we can place the efi payload where it belongs per spec and
the images will autoboot to the grub menu on EFI platforms.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
The syslinux and grub-efi classes were generating config files in the current
working directory. This caused a failure due to a race in the creation of the
directories leading to cwd changing and the build failing to find the config
files. While this has been addressed in bitbake, it is better to use an
explicit path.
While ${WORKDIR} may seem a more appropriate place, the recipe
already uses ${S} for the "hdd" and "cd" construction, so we use ${S}
here to keep things consolidated and consistent and address the issue
with minimal change.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
|
|
Create a new grub-efi.bbclass and integrate it into bootimg alongside the
syslinux support. This new class uses the output from the grub-efi-native
recipe. Thanks goes to Josef Ahmad <josef.ahmad@intel.com> for the original
build_grub_cfg() routine.
The EFI features are only added to the image if MACHINE_FEATURES contains
"efi". The resulting images are therefor either legacy boot only (like they
were originally) or legacy boot and EFI boot.
A new "dummy.bbclass" was added to allow for the conditional include
of grub-efi. This makes it so if efi support is not to be built in, we
don't spend time building grub-efi-native just because the include adds
the dependency.
There is a bug in the mkdosfs tool from the dosfstools package which causes
it to crash when the directory passed with the -d parameter contains
sub-directories. An /EFI/BOOT directory is required for a proper EFI
installation. Until it is fixed, we install to the top level directory
for the hddimg.
Signed-off-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Josef Ahmad <josef.ahmad@intel.com>
|
