Anaconda-devel April 2014

anaconda-devel@lists.stg.fedoraproject.org

10 participants
9 discussions

OSTree <3 Anaconda
by Colin Walters 24 Apr '14

24 Apr '14

Background ---------- OSTree is a tool to replicate pre-constructed *bootable* filesystem trees over plain HTTP, including support for things like GPG keysigning. rpm-ostree is a tool which takes RPM content on a "compose" server, and stores it into an OSTree repository. This model is very useful for any deployment scenario where one wants to compose a system from the tested RPM parts, and then efficiently replicate it to many client systems. Examples are many cloud deployments, "Corporate Standard Build" laptops, all the way down to cash registers and embedded devices. To make this work, OSTree is not just a tool to download content - it's also a set of *required changes* to the operating system content, such as /usr/lib/passwd: https://sourceware.org/bugzilla/show_bug.cgi?id=16142 Anaconda -------- For Fedora and derived systems like Red Hat Enterprise Linux, Anaconda is by far subsystem impacted the most. While the system is booted normally, while you are inside a chroot, for the most part the system "feels" like a traditional Unix system. You have writable /etc and /var. However, really on disk, the operating system lives in e.g. /ostree/deploy/fedora-atomic/deploy/c79ba9b3c245fa5e256aa9217db5f4954b2639d1504d02462277cae3c30473ae.0 Anaconda however has a constant ROOT_PATH that needs to be split - some things like in the physical root, others live in what I placed in "iutil.getSysroot()". There is no /etc/fstab on the *physical* filesystem for example - it is really in /ostree/deploy/fedora-atomic/deploy/c79ba9b3c245fa5e256aa9217db5f4954b2639d1504d02462277cae3c30473ae.0/etc/fstab. Furthermore, OSTree wants to be in charge of setting bootloader configuration. (This is how the atomic updates work). So we have a multi-stage setup where Anaconda lays down the defaults (but no boot entries), then we tell OSTree to write the boot entries. pykickstart ----------- This patch is pretty simple - it's defining a new "ostreesetup" verb that holds data. blivet ------ The required changes here are similar to Anaconda - we need a distinction between ROOT_PATH and "targetSysroot". Future ------ These patches are for early architectural feedback. The next step I'll take is to factor out some of the "quick hack" things that should be fixed elsewhere. For example, OSTree should know about /boot/extlinux in addition to /boot/syslinux. Also, https://bugzilla.gnome.org/show_bug.cgi?id=726757

4 7

additional bootloader data: intersection of rpm/grub2/extlinux/ostree
by Colin Walters 24 Apr '14

24 Apr '14

Hi, The executive summary here is that at the moment additional bootloader data like the extlinux modules in /boot/extlinux and the grub2 splash screens in /boot/grub2/themes don't fit into the OSTree model. I don't have a way to update that data in an atomic/safe fashion. For more background: https://bugzilla.gnome.org/show_bug.cgi?id=726757 https://bugzilla.redhat.com/show_bug.cgi?id=1090083 http://www.syslinux.org/archives/2014-April/021973.html Now what I'm thinking is that changing the Fedora extlinux package is high risk, and also wouldn't solve things like the grub2 splash screens. The simplest option is to declare that this additional data in /boot is only laid down exactly once, by the installer. Basically for OSTreePayload, what Anaconda would do is simply copy all data in the tree's /boot into the target /boot. OSTree itself would not do this on upgrades. If we choose this path, it would still be nice to offer a mechanism (perhaps even a standardized one that detected the active bootloader) and updated it. On the other hand, if we killed grub2 splash screens, then extlinux would likely be the odd man out here. Any data points for how the other bootloaders work?

1 0

rebased ostree/atomic patches for rawhide
by Colin Walters 22 Apr '14

22 Apr '14

I still haven't had a chance to de-uglify these much from comments, but I've managed to rebase on top of the current rawhide versions of anaconda/python-blivet. This requires the PrivateNetwork= workaround I previously posted for lorax. Sending out in case anyone is interested in helping me with cleaning them up and landing.

2 2

btrfs install over an existing rootfs
by Gene Czarcinski 22 Apr '14

22 Apr '14

Not all directory trees are created equal and anaconda requires that the directory tree (partition) for the rootfs (that is "/") must be either new or reformatted. This works for regular partitions and the LVMLVs. However, there is no real concept of "reformatting" an existing btrfs subvolume. This applies to kickstart only as the regular gui/text installers handle the situation already. Proposal: Add code to implement a new feature for btrfs subvolumes which will implement the equivalent of reformatting. This equivalent will consist of deleting the subvolume and then recreating it. As I originally implemented this I added a new operand to the btrfs command for a subvolume: --reclaim [This involves a small patch to pykickstart] While I considered using and existing operand in some fashion, I believe that the "safe" approach is to require the user to specify this new operand is the intent is to reclaim the subvolume's name and then reuse it. Comments? Gene

2 2

how to debug dynamically anaconda for fedora19?
by 夏磊 16 Apr '14

16 Apr '14

Hi, all The anaconda of fedora19 uses threads, and the pdb is invalid. so, how to debug dynamically anaconda for fedora19? Thank you!

3 6

udevadm settle hang on rawhide
by Colin Walters 14 Apr '14

14 Apr '14

I was hitting a hang when doing ostree installs which the ever awesome Brian Lane tracked down to be generic hangs with any kickstart installation relating to udev. The problem is udevadm settle vs network namespaces. A variety of systemd services now use PrivateNetwork= which ends up creating a new network namespace, and that "eats" udev events from the perspective of the system udev. This means that udev will hang waiting for a sequence number it won't see. I talked to Kay about this and he bumped it up on his priority list, he says it's obviously a systemd bug since they're both in the same codebase now. In the meantime we may need to figure out a workaround. Options: 1) Postprocess all systemd units in lorax and remove PrivateNetwork= (I think this might work) 2) Replace "udev_settle()" calls in blivet with "sleep 1m" or something 3) Investigate a better API than udev settle; it seems to me we could more intelligently wait for just storage for example. Any other ideas? But yeah, just a generic heads up that kickstart installation with rawhide seems to trigger this reliably.

3 3

[PATCH] runtime-cleanup: Strip PrivateNetwork= from systemd units
by Colin Walters 14 Apr '14

14 Apr '14

Unfortunately, this triggers a bug in udev that causes udev_settle() to hang, which makes all kickstart installations hang for a long time. https://www.redhat.com/archives/anaconda-devel-list/2014-April/msg00010.html --- share/runtime-cleanup.tmpl | 2 ++ 1 file changed, 2 insertions(+)

2 1

copr build of nose-testconfig
by David Shea 11 Apr '14

11 Apr '14

Since that's needed now to run make check, in case you don't feel like using pip. Add http://copr.fedoraproject.org/coprs/dshea/anaconda-extras/repo/fedora-20-i3… to your repos and yum install python-nose-testconfig. python-diff-cover is in there too.

2 1

Installing image payloads
by Fabian Deutsch 10 Apr '14

10 Apr '14

Hey, as mentioned in my earlier email I'm working on oVirt Node. One special thing about Node is that we deploy an image, forming the rootfs, and not packages which then form the rootfs. Currently we have our own installer carrying all the necessary bits to do this. I now wonder if we could probably add some features to anaconda to deploy an image, instead of packages. The basic idea is that the rootfs is rolled out (as in dd'ed) using an existing image, and not yum (or the other file based solutions). Note: Important to note here is that the image should be copied/dd'ed as is, not file-wise copied into a new FS (liek it's happening with the liveimg payload IIUIC). The idea is to roll out the image into a LV, then create a write-able snapshot or thin volume and use that as the rootfs. Form that point on there shouldn't be a to big difference between a file based deployment and the image based one. Ok - Granted. There will surely be some more details which need to be addressed, e.g. the bootloader. Any thoughts on this and can someone maybe tell if this is doable with anaconda? Thanks fabian

5 7

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel April 2014