FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 08-16-2012, 11:51 PM
Jesse Keating
 
Default Handling updates and product images

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@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 08-24-2012, 10:59 PM
Will Woods
 
Default Handling updates and product images

On Thu, 2012-08-16 at 16:51 -0700, Jesse Keating wrote:
> 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 [...]

...since it seems to be causing some serious, unexpected problems, we
have to deal with this immediately. Here's my take:

- It's silly for anaconda to expect anything in /tmp at startup,
since /tmp is (by definition) empty at system startup, so we should
switch to /run/install/{updates,product}. (That's option C)

- There are a lot of places that reference /tmp/{updates,product} in
anconda, so we probably can't do that for Alpha.

- We *can* easily change makeupdates etc. and add a symlink
to /tmp/{updates,product} during anaconda startup, for backwards
compatibility. (That's option D). Yes, it's definitely a hack, but it's
just a temporary fix while we work on the Proper Solution.

So - Jesse, could you post your code for options C/D?

Thanks for looking into this!

-w

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 07:06 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org