fedup is deprecated and abandoned. Let's save time and disk by not
building `upgrade.img` when nothing is going to use it anymore.
For the record, performing upgrades using an initramfs from the new
system turns out to be fragile and hard to support:
* dracut initramfs isn't generic enough to handle booting all systems
(e.g. missing vconsole.conf means you get keymaps wrong, so users
can't unlock encrypted disks)
* The ABI differences between the two versions of plymouth, systemd,
etc. requires nasty workarounds at best and causes nightmarish
systemd crashes at worst
This patch removes all the code that built and installed `upgrade.img`.
For backwards compatibility, the API retains the `doupgrade` keyword
argument, and the `--noupgrade` flag is still accepted.
I originally added --add-template to support doing something similar
to pungi, which injects content into the system to be used by default.
However, this causes the content to be part of the squashfs, which
means PXE installations have to download significantly more data that
they may not need (if they actually want to pull the tree data from
the network, which is not an unusual case).
What I actually need is to be able to modify *both* the runtime image
and the arch-specific content. For the runtime, I need to change
/usr/share/anaconda/interactive-defaults.ks to point to the new
content. (Although, potentially we could patch Anaconda itself to
auto-detect an ostree repository configured in disk image, similar to
what it does for yum repositories)
For the arch-specfic image, I want to drop my content into the ISO
root.
So this patch adds --add-arch-template and --add-arch-template-var
in order to do the latter, while preserving the --add-template
to affect the runtime image.
Further, the templates will automatically graft in a directory named
"iso-graft/" from the working directory (if it exists).
(I suggest that external templates create a subdirectory named
"content" to avoid clashes with any future lorax work)
Thus, this will be used by the Atomic Host lorax templates to inject
content/repo, but could be used by e.g. pungi to add content/rpms as
well.
I tried to avoid code deduplication by creating a new template for the
product.img bits and this, but that broke because the parent boot.iso
code needs access to the `${imggraft}` variable. I think a real fix
here would involve turning the product.img, content/, *and* boot.iso
into a new template.
Use the same stage2 location for all arches, put it in images with all
the other images. This only effects boot.iso, live images still use
LiveOS/squashfs.img because that's where dracut's 90dmsquashfs-live
module expects to find it.
For boot.iso anaconda-dracut handles finding stage2, looking at
images/install.img and LiveOS/squashfs.img
With these templates if a package has installed files in
/usr/share/lorax/product or /usr/share/lorax/updates/ they will be used
to create product.img and/or updates.img which will be included in the
images/ directory of the iso and of the final output tree.
These can be used to customize the installation environment or provide
updates. See README.product for current documentation.
Currently, yaboot is the ISO boot loader in fedora and the Fedora on
POWER team is making an effort in order to replace it by GRUB2 in the
F20 release cycle. I'm sending a lorax patch so you guys can comment
on it. I'm planning to create a feature page for that too.
This patch only change the lorax template for ppc and should not
affect other archs, like x86.
--
Paulo Flabiano Smorigo
Software Engineer
Linux Technology Center - IBM Systems & Technology Group
Using root= overrides the anaconda magic code for finding product.img
and updates.img. Anaconda can find the CDROM itself without needing
root=, though, so we can omit it safely for boot.iso.
If yaboot so much as catches a whiff of a backslash in yaboot.conf, it
will reject the entire file. No bootloader config means no booting.
So as long as we're still using yaboot on PPC, we need to use ISO volume
labels it can handle. So: filter the isolabel, replacing any non-ASCII
characters with underscores.
So there's actually two copies of yaboot on a PPC image, and they each
use different config files:
ppc/chrp/yaboot --> /etc/yaboot.conf
ppc/mac/yaboot --> /ppc/ppc{32,64}/yaboot.conf
So we need two copies of yaboot.conf - one in each place - to
boot properly (or all three if we're making hybrid images). Whee!
The comments should now make this more clear for future reference.
move arch-specific stuff to arch-specific subdirs and move all the
common stuff to a subdir named 'common'. Also, rename '.profile' and
'.bash_history' so you actually see them when you 'ls' the 'common' dir.
also added some helpful(?) comments to the templates.
New images find their root device by looking at the CDLABEL. Since pungi
is building ISO images separately from lorax, if it uses a different ISO
Volume Label we'll end up with unbootable images.
This changes the volume labels to match what pungi uses, so both should
boot OK.
Since pungi doesn't know that images/install.img needs to be moved to
LiveOS/squashfs.img for images to be "live", they aren't bootable.
This is the simple solution to the problem. Thanks to Karsten Hopp
for the original patch.
This adds the boot config files from anaconda to lorax's configdir.
They've been edited to include a '@ROOT@' placeholder, so lorax can put
the proper root=... argument in place, and to use the @VAR@ convention
everywhere (instead of some using @VAR@ and some using %VAR%).
This should probably fix EFI booting, since the EFI BOOT*.conf was
missing its root=... arg.
Also some default settings were changed in syslinux.cfg (so we don't
have to rewrite those two lines every time).
One last change - the '-magic' arg and ppc 'magic' file have been
dropped, because that's kind of silly and unnecessary.
TreeBuilder uses templates full of commands (like ramdisk.ltmpl) to
create the output tree and boot images. There are 4 arch-specific
templates, plus a bonus EFI template which can handle EFI image creation
for any arch that implements EFI.
