mk-s390-cdboot has stopped working because the kernel outgrew the
hard-coded offset it used when creating cdboot.img. IBM now has a script
in s390utils that can do the same thing so use the upstream script
instead.
This drops mk-s390-cdboot script, switches the s390 templates to use
mk-s390image from s390utils.
It adds @ROOT@ to cdboot.prm, and sets inst.stage2 so that the installer
image will be found when booting the iso.
Related: rhbz#1892404
This adds a new livemedia-creator argument, --extra-boot-args, which can
be used to add arguments to the kernel command-line in the templates.
Related: rhbz#1687743
In order to support iso creation on multiple arches with the templates
we need to be able to select different packages based on arch.
lorax-composer uses the arch-specific Lorax templates in order to
generate the output iso so this patch:
1. Creates a new template and type to parse it, live-install.tmpl
which contains only installpkg commands and #if clauses for arch
2. Removes bootloader related packages from the live-iso.ks
3. Remove dracut-config-rescue exclusion because it can cause problems
with some blueprints.
4. Switch logo requirement to system-logos which is satisfied by
generic-logos or fedora-logos. This prevents conflicts when a blueprint
installs fedora-release-workstation.
So in the future, if x86.tmpl, etc. need a new package to support
creating the iso it should be added to the correct section in
./share/live/live-install.tmpl
Resolves: rhbz#1673744
The previous attempt to fix this failed because of operator
ordering, so we actually still tried to build EFI images on
i386, so i386 lives failed. This really fixes it. I tested. I
actually built a 32-bit live and it worked.
Resolves: rhbz#1539085
Signed-off-by: Adam Williamson <awilliam@redhat.com>
This shouldn't have been turned on when we switched to doing ia32-efi
images on x86_64; just having the file available isn't where we want
that policy decision to be.
Resolves: rhbz#1539085
Signed-off-by: Peter Jones <pjones@redhat.com>
pjones and I happened to notice this suspicious line in the
lmc log for a Fedora 27 live image compose:
2017-08-25 16:04:55,327 DEBUG pylorax.ltmpl: template line 25: installimg None usr/share/lorax//product/ images/product.img
That 'None' does not look right. I believe this is the problem.
The command is defined as `installimg ${compressargs} ...`, and
a few lines earlier, `compressargs` is initially assigned (in
Python) as `None`. `None`, in Python, stringifies to the string
'None'. So unless we're on i386 (where `compressargs` gets
defined to an actual string of arguments in a conditional), we
wind up passing in the string 'None' as the first arg to the
`installimg` command.
To fix this, `compressargs` should be initially set to the empty
string rather than `None`.
This enables Baytrail and similar atom CPUs that typically ship with a
32-bit firmware, but have a 64-bit capable CPU.
Signed-off-by: Peter Jones <pjones@redhat.com>
When using the template install command copying the same file to itself
shouldn't crash. Just log the error and continue.
Also copy the s390 configuration files for use with livemedia-creator
Resolves: rhbz#1269213
commit 66241f7cd7 added a check on
runtime_img to create UDF iso's. Ends up it is only in outroot for live,
so switch all the checks to look at it in inroot instead.
Some images are becoming REALLY large. When a file is >= 4GiB we need to
pass -allow-limited-size to mkisofs to tell it to make a UDF image. Note
that the manpage says that this may result in it not booting on all
systems.
