With F18 we have a wrinkle with handling of updates and product images.
Previously in dracut we would unpack them and then overlay them on top
of the newroot (/sysroot/). To make this work, our updates and product
images would have a path within them, /tmp/updates/ or /tmp/product/.
This worked fine, until /tmp became a tmpfs mount created by systemd
during system bring up. When this mount happens it will cover up
anything we've put in /tmp/ during dracut and thus we'll lose our updates.
The quick and easy fix we've gone with for F18 Alpha is to mask the
tmpfs service so that it won't run. This brings things inline with how
it worked in F17. Will has expressed concern that we shouldn't deviate
from the system like this and instead work around it, so I've explored
some options. There is no order to these options.
Option A) Make use of an init service that copies everything from
/run/initramfs/state/ onto the / filesystem during bootup. To
accomplish this we would have our updates image use
/run/initramfs/state/tmp/updates (and /run/initramfs/state/product) as
the location of the files. Provided the fedora-import-state service
runs after the tmpfs mount, we will have our content in
/tmp/updates,product by the time anaconda runs. Pros: small amount of
code change, no change in anaconda code for dealing with update content.
Cons: possible ram overusage. Copying files from one ramfs to a tmpfs
may double the amount of ram the files are using.
scripts/makeupdates | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
Option B) Create a symlink from /run/initramfs/inst.{updates,product} to
/tmp/{updates,product} when anaconda launches. This option still makes
use of the /run/initramfs/ pass through, but instead of relying on a
service to copy files into / we'll just make a symlink early in the
anaconda process (right at the top of when we'll deal with the python
updates). Pros: still a small amount of code change, and potentially
reduces memory footprint vs option A. Cons: It feels like a hack on top
of a hack.
anaconda | 6 ++++++
scripts/makeupdates | 7 ++++---
2 files changed, 10 insertions(+), 3 deletions(-)
Option C) Just directly use update content from
/run/initramfs/inst.{updates,product}. Don't rely on a service to copy,
nor make a crutch symlink, just directly use the content from those
directories. This requires the most code change, and even breaks
running tests as non-root (as there is a test that creates a bogus
product .buildstamp and that fails if you're creating it in /run/ as
non-root). Pros: It's not a crutch or a paperover, it's a direct use.
Doesn't rely upon a service out of our control or timing issues. Cons:
Lots of code churn, breaks tests as nonroot.
anaconda | 16 ++++++++--------
data/liveinst/liveinst | 12 ++++++------
pyanaconda/constants.py | 2 +-
pyanaconda/installclass.py | 4 ++--
pyanaconda/localeinfo.py | 4 ++--
pyanaconda/packaging/yumpayload.py | 8 ++++----
pyanaconda/product.py | 2 +-
pyanaconda/ui/gui/__init__.py | 2 +-
pyanaconda/ui/gui/hubs/progress.py | 4 ++--
pyanaconda/yuminstall.py | 2 +-
scripts/makeupdates | 9 +++++----
tests/pyanaconda_test/product_test.py | 4 +++-
12 files changed, 36 insertions(+), 33 deletions(-)
Option D) Keep masking the tmpfs mount. Pros: very simple change in
lorax, no other code changes. No file duplication in ram. Cons:
Potential to overflow the overlay, cannot be swapped to disk, diverges
from Standard System.
My personal preference would be option D, because it involves the least
amount of code change and is the most simple solution. Secondary to
that I'm leaning toward option D, again little code change.
I'm posting here for more opinions, perhaps options I haven't thought of.
--
Jesse Keating
Fedora -- Freedom² is a feature!
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
