Anaconda-devel March 2014

anaconda-devel@lists.stg.fedoraproject.org

19 participants
11 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

Introduction and RFC on kernel cmdline based kickstart-file generation
by Fabian Deutsch 31 Mar '14

31 Mar '14

Hey, my name is Fabian Deutsch besides beeing a long time Fedora - and thus anaconda - user, I'm workin on oVirt Node (http://www.ovirt.org/Node) Node is a slimmed down Fedora (or CentOS), which is deployed in the livecd form factor. This livecd is getting installed - as in copied - on to a LV by our custom installer. At runtime the host boots the livecd image stored on the LV. Changes to configuration files are persisted by storing those files on a writable partition and bind mounting them into the appropriate place. One thing - besides others - I like about Node is that you can do a complete installation and configuration using kernel arguments. Our customer is reading the installation parameters from the kernel cmdline instead of reading them from a kickstart like anaconda does. This is very convenient when Node get's deployed via PXE boot - where the installation parameters can be just given in the pxe conf. The following patch is basically an idea of how to bring kernel arguments based installations to anaconda: https://github.com/fabiand/anaconda/compare/master...kargs The high level idea is that kickstart directives can be given on the kernel cmdline, which are then - by a small script - transformed into a kickstart. This kickstart is later picked up by anaconda. Let me illustrate how such a transformation can look: keyboard --vckeymap=us rootpw --plaintext "foo bar" repo --baseurl=ur1.ca/bar --cost=42 becomes a.keyboard(vckeymap=us) a.rootpw(plaintext)="foo bar" \ a.repo(baseurl=ur1.ca/bar;cost=42) The transformation is (or intended to be) "lossless" and thus bidirectional. I've not yet come round to build a boot image to test this. There is only a doctest validating that the transformation is right. Any thoughts on such an (isolated) feature? Greetings fabian

7 11

Any volunteer for fixing errors/warnings from tty1?
by Vratislav Podzimek 27 Mar '14

27 Mar '14

With the current state of the Rawhide Fedora and Anaconda, the TTY1 gets flooded with errors and warnings from Gtk which complicates debugging. Any volunteer willing to fix this issue? -- Vratislav Podzimek Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

3 4

UI for other payload types?
by Colin Walters 27 Mar '14

27 Mar '14

Hi, At the moment the software.py spoke assumes a PackagePayload. Which makes total sense. The previously existing payload types don't have any concept of choices really. The OSTreePayload does - you can choose between *multiple* filesystem trees: http://rpm-ostree.cloud.fedoraproject.org/composeui/#/ Also, I'd like to be able to enter a repository URL, etc. Given that one Anaconda boot.iso would support both payload types, but OSTreePayload is quite experimental, what would be the best way to have a "secret button" or something that would expose a UI for it? The easiest path is clearly a boot-time kernel argument, like dnf is now. Hm, you know what, disregard this message =) A boot time argument is makes sense for now until this is all a lot less experimental. </talking-to-myself>

1 0

problem running lorax from distill on EFI (aarch64) systems
by David A. Marlin 27 Mar '14

27 Mar '14

When Jon is running distill for aarch64 he is getting an error. This does not occur if he runs it manually as root. The primary issue seems to be: /dev/loop0 is write-protected, mounting read-only and we can't write the EFI directory to it. -------------------------------------- 2014-03-27 10:00:15,662: preparing to build output tree and boot images preparing to build output tree and boot images 2014-03-27 10:00:15,664: rebuilding initramfs images rebuilding initramfs images 2014-03-27 10:00:15,670: rebuilding boot/initramfs-3.13.0-0.rc7.27.sa2.aarch64.img rebuilding boot/initramfs-3.13.0-0.rc7.27.sa2.aarch64.img No '/dev/log' or 'logger' included for syslog logging dracut module 'mlx4' depends on 'rdma', which can't be installed dracut module 'rdma' cannot be found or installed. dracut module 'rdma' cannot be found or installed. dracut module 'rdma' cannot be found or installed. dracut module 'rdma' cannot be found or installed. cat: write error: Broken pipe 2014-03-27 10:03:18,743: populating output tree and building boot images populating output tree and building boot images 2014-03-27 10:03:18,891: running aarch64.tmpl running aarch64.tmpl ERROR:program:mount: /dev/loop0 is write-protected, mounting read-only mount: /dev/loop0 is write-protected, mounting read-only Traceback (most recent call last): File "/usr/sbin/mkefiboot", line 155, in <module> mkefiboot(opt.bootdir, opt.outfile, opt.label) File "/usr/sbin/mkefiboot", line 32, in mkefiboot mkdosimg(None, outfile, label=label, graft={'EFI/BOOT':bootdir}) File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 327, in mkdosimg mkfsargs=["-n", label], graft=graft) File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 319, in mkfsimage do_grafts(graft, mnt, preserve) File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 170, in do_grafts os.makedirs(targetdir) File "/usr/lib64/python2.7/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 30] Read-only file system: '/tmp/lorax.imgutils.PYH_RV/EFI' -------------------------------------- The full log is: http://download.lab.bos.redhat.com/devel/candidates/Acadia/RHSA-2.0-2014032… Thank you, d.marlin

2 1

status of tarpayload
by Arun SAG 21 Mar '14

21 Mar '14

Hi, I was looking at anaconda's code the other day. I was surprised to see the tar payload. https://git.fedorahosted.org/cgit/anaconda.git/tree/pyanaconda/packaging/ta… I suppose this payload is used to extract tar.gz compressed file system on a disk. May i know how it can be used? Is it possible to use this feature from a kickstart? -- Arun S A G http://zer0c00l.in/

3 4

feature for building docker base images in anaconda
by Matthew Miller 21 Mar '14

21 Mar '14

Hi everyone. In the cloud sig, we want to be able to build official Fedora docker base images. There are a number of advantages if we could do this using anaconda as the primary tool for that -- first, we hope to get koji integration basically for free with the upstream work, and second, using a well-known and well-supported tool rather than some one-off which becomes unsupported. I'd like to create a fedora feature for this, but I, um, don't intend to actually do any of the coding. I can talk about what's needed until I turn blue, though, and test things and so on. Would anyone like to raise their hand to help? Basically, we need something that: - takes a kickstart in - outputs a tarball of / and it needs some of the things already in progress or done (install without a kernel, install with reduced docs and langs). More specifically: Requirements: * install without swap or any other partitioning (easy, I think) * install without any bootloader (should be done) * install with no docs (ditto) * don't add any packages not in the explictly-given package set + rpm reqs Nice to Have: We do a number of things in the image kickstart `%post` that could be handled by the tool directly. This would make it easier for end users to make their own images without complicated kickstarts. * Create /dev/tty1 and /dev/loop# devices statically * soft-link /dev/tty1 to /dev/console * anonymize images with no /var/lib/random-seed or other supposed-to-be- unique elements (/etc/hosts?) * disable /tmp on tmpfs Bonus: * anaconda run in its non-vm mode to reduce build time and resources. In fact, it'd be ideal to be able to run this _inside a docker container_. -- Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>

4 15

anaconda and initial-setup changes for: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights
by Hans de Goede 20 Mar '14

20 Mar '14

Hi, As you may've heard I'm working on making the xserver run as a normal user, see: https://fedoraproject.org/wiki/Changes/XorgWithoutRootRights This involves it delegating device node management to systemd-logind. In order for this to work, 2 conditions must be met when the xserver is started: 1) It must have a vc as controlling tty 2) It must be inside a properly registered (pam) user session For anaconda doing something like a mingetty --autologin as a certain user, and having the shell for that user be the script which starts the xserver should be enough. For initial setup you may likely want to do something similar. Of course there are other options, as long as the 2 conditions above are met things should work. Note currently the necessary Xorg changes for this are not yet in rawhide, so if you've some fixes for this you would like to see tested, drop me a mail and I'll see what I can do. Regards, Hans

1 0

non-starter HTTP installation
by Felix Miata 19 Mar '14

19 Mar '14

Target: single core 32 bit 2.4GHz P4, 1G RAM, Matrox G400 AGP video. Using 5925232 Mar 14 16:22 vmlinuz 274341888 Mar 17 11:59 squashfs.img 38301760 Mar 17 12:02 initrd.img from http://alt.fedoraproject.org/pub/fedora/linux/development/rawhide/i386/ I tried to initialize an HTTP installation from mirrors.us.kernel.org via Grub. Cmdline option inst.resolution=1024x768 was ignored (as far as it got, far short of GUI startup), as were vga=791, video=1024x768 and net.ifnames=0. Init progressed only as far as "target Initrd File Systems", about 40 seconds. Only keyboard response was to ESC toggling between bootup message and a bar at bottom of screen that ended "Fedora 21", and CAD to reboot, since a wait of more than 10 minutes produced no more activity. Should it have proceeded? -- "The wise are known for their understanding, and pleasant words are persuasive." Proverbs 16:21 (New Living Translation) Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata *** http://fm.no-ip.com/

2 3

Polishing the installer
by Luya Tshimbalanga 18 Mar '14

18 Mar '14

Now that the basic layout is set aside the customization of partition, it will be nice to provide a professional look to the installer for fedora.next workstation system. I wonder if the layout is responsive depending of the size of the screen. When starting the installer, it will be nice to display an nice graphical screen rather than a typical text mode (similar to the way Fedora starts with a bootloader). Same principle should apply when rebooting after the installation. Granted the idea is not really important. However, with the increase of Fedora as workstation, those refinements will only enhance the overall experience of Fedora Workstation and other part of Fedora.next. Considering Fedora 21 Final Release will not be avail until October 2014, I think this is a good opportunity to polish the whole installer. I was inspired by the way iOS is installed and updated on the iMac. The message was originally submitted on: https://lists.fedoraproject.org/pipermail/desktop/2014-March/009512.html with an additional note from Adam Williamson related to bootsplash missing since Fedora 12. Luya

4 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel March 2014