Anaconda-devel November 2014

anaconda-devel@lists.stg.fedoraproject.org

19 participants
9 discussions

Ideas for complex storage visualization
by Vojtěch Trefný 28 Nov '14

28 Nov '14

I'm currently trying to find a way how to visually represent complex storages (LVMs, RAIDs) in the blivet-gui[1] (and in the future for anaconda too). ------ TL;DR version: Help me find a way how to visually represent storages, my current ideas[2] sucks. ------ Even a simple Fedora installation on machine with a single harddrive can produce quite a complex storage -- installation using encrypted LVM results into seven devices with four level deep structure (luks-physical volume-volume group-logical volumes). The challenge here is to create a simple graphical representation of this situation (and of course also not so standard storages with LVMs over RAIDs and other weird configurations) that would be easy to understand and could fit into application window[3] (leaving space for other widgets). I'm currently using system similar to GParted -- colored rectangles with child devices "embedded" into their parents -- a little like rectangular contour map -- https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation1.png It looked like good idea but I think it is too complicated and hard to understand with more "layers". My second idea is derived from GNOME Disks -- https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation2.png (just a mockup created using Gimp). Problem is it would need extra space for some basic information (name, size...) and it would be worse for more storages with more layers. The idea I like the most is using tree-like visualization -- https://vtrefny.fedorapeople.org/blivet-gui/storage-visualisation3.png -- it can show the whole complex structure of the storage, unfortunately it would never fit into the window. The result is I have three options that I don't like and I'm not able to come up with something new or better. So I hope somebody will come up with some amazing solution. Feel free to share all your crazy ideas and thoughts. Vojtech T. -- [1] http://blog.vojtechtrefny.cz/blivet-gui [2] https://vtrefny.fedorapeople.org/blivet-gui/ [3] https://vtrefny.fedorapeople.org/blivet-gui/blivet-gui-window.png

5 7

Can't test Anaconda changes in RHEL7
by Jack Ngo 28 Nov '14

28 Nov '14

Hi everyone, I'm starting to develop Anaconda but when I modify source code, I don't know how to test what I changed. I did follow this URL: http://fedoraproject.org/wiki/Anaconda/Stage2DevelopmentGuide#Testing_Chang… But it's not work...This is my top level of installation dir: dr-xr-xr-x 4 asianux asianux 52 May 7 2014 addons dr-xr-xr-x 3 asianux asianux 17 May 7 2014 EFI -r--r--r-- 1 asianux asianux 8266 Apr 4 2014 EULA -r--r--r-- 1 asianux asianux 18092 Mar 6 2012 GPL dr-xr-xr-x 3 asianux asianux 54 Nov 27 11:44 images dr-xr-xr-x 2 asianux asianux 4096 May 7 2014 isolinux dr-xr-xr-x 2 asianux asianux 41 May 7 2014 LiveOS -r--r--r-- 1 asianux asianux 108 May 7 2014 media.repo dr-xr-xr-x 2 asianux asianux 225280 Nov 27 11:34 Packages dr-xr-xr-x 24 asianux asianux 4096 May 7 2014 release-notes dr-xr-xr-x 2 asianux asianux 4096 May 7 2014 repodata drwxrwxr-x 2 asianux asianux 42 Nov 27 11:44 RHupdates -r--r--r-- 1 asianux asianux 3375 Apr 1 2014 RPM-GPG-KEY-redhat-beta -r--r--r-- 1 asianux asianux 3211 Apr 1 2014 RPM-GPG-KEY-redhat-release -r--r--r-- 1 asianux asianux 1568 May 7 2014 TRANS.TBL and RHupdates dir: -rw-r--r-- 1 root root 49196 Nov 27 08:51 source.py -rw-r--r-- 1 root root 26766 Nov 27 09:30 welcome.glade I use NFS + PXE install method. I heard it's easy to test Anaconda. This is my PXE configuration file: label linux menu label ^Install system menu default kernel vmlinuz append initrd=initrd.img ip=dhcp inst.repo=nfs:nfsvers=4:x.x.x.x:/RHEL7/ So could you tell me what's wrong I did? And if there is any other ways to test Anaconda, please help me. Thanks everyone !!!

2 4

Re: Anaconda-devel-list Digest, Vol 129, Issue 12
by Jack Ngo 27 Nov '14

27 Nov '14

Hi Vratislav Podzimek, First, thank you very much for helping me. But I did follow you and after reboot PXE Client, nothing changed :( 1. I find Anaconda version (anaconda-19.31.79-1) 2. Run scripts/makeupdates script: $ scripts/makeupdates -t anaconda-19.31.79-1 3. Upload updates.img into my webserver (/var/www/html/) 3.1 Append inst.updates=http://x.x.x.x/updates.img I changed a very simple code to test, remove "WELCOME TO" in welcome.glade But when I reboot PXE Client to test, nothing changed. Did I miss something? Hmm, I have a question....how many updates.img I have to create? one for version without my changes and one for version with my changes, right? But I only use one Anaconda version: 19.31.79-1

1 0

Does "--asprimary" make any sense when doing GPT partitioning?
by Spike White 13 Nov '14

13 Nov '14

All, In a ks.cfg when doing MBR partition, I realize the value of --asprimary. Here's an example: part /boot --fstype ext3 --size=300 --asprimary part pv.2 --size=38000 --grow --asprimary volgroup osvg pv.2 logvol / --fstype ext4 --name=root.fs --vgname=osvg --size=4000 .... But when doing GPT partitioning (i.e., inst.gpt in your grub.conf kernel line), does --asprimary even make sense? ksvalidator didn't flag it as an error, so syntactically it's legal. Is it just ignored by the part command if doing GPT partitioning? Spike

3 2

specifying the default kernel
by Gene Czarcinski 12 Nov '14

12 Nov '14

For a long time, anaconda has been going to a lot of trouble to specify the default kernel setting in /boot/grub2/grubenv. In late may, I submitted a patch to simply set saved_entry=0 https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-May/011336.h… According to grub2 documentation, setting the value to "0" will boot the first menuentry (kernel) it finds ... this is what most, if not all, users expect ... boot the latest kernel. This even works after installing a new kernel since new menuentry definitions are inserted at the front of the list. This patch was accepted: https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-June/011369.… and added to anaconda in commit 5c26c8689bc55e3c5fadc74cfa3636475cb54b1a While this patch is necessary to "get things correct" as far as what kernel should be booted by default, it is not sufficient. So, I submitted another patch to anaconda which changes the setting of UPDATEDEFAULT from "yes" to "no" in /etc/sysconfig/kernel. https://lists.fedorahosted.org/pipermail/anaconda-patches/2014-October/0140… So, that should fix things ... right? No! As of grubby-8.35-8, grubby ignores UPDATEDEFAULt=no Before plunging into doing an update fopr grubby, I would like some confirmation as to what should be happening ... that is, what should the user expect when the kernel is updated and there are settings for saved_entry= in /boot/grub2/grubenv ad well as for UPDATEDEFAULT= in /etc/sysconfig/kernel 1. UPDATEDEFAULT=no *Do nothing*! * The user may have set saved_entry to point at a menuentry in /etc/grub.d/40_custom and does not want that to change (this is a big issue for me). * saved_entry=0 will do the "right thing" booting the new kernel whose menuentry is at the head of the list. * saved_entry=xyz ... still OK becuase grub2 will boot the first menuentry if it does not find a match * saved_entry=5 ... who knows but most likely nothing good. On the other hand, the user had to specifiocally set this. 2. UPDATEDEFAULT=yes * saved_entry=0 ... there is a choice here. We can set saved_entry to the id for the new kernel *or* we can do nothing in which case the menuentry at the head of the list will be booted ... which is the kernel just installed. * saved_entry=5 ... update with saved_entry=0 or ID from new kernel * saved_entry=xyz ... update with ID from the new kernel IMO (maybe not so humble) is that if UPDATEDEFAULT=no, grubby should do nothing. That is, leave saved_entry set to whatever it is set to. Currently, grubby-8.35-8 unconditionally updates even if UPDATEDEFAULT=no is specified in /etc/sysconfig/kernel. OK, before I go and create yet another patch for grubby, how do you want this to work? And, also answer the question: "How does a user exp[ect things to work?". Gene

1 1

Two alternate ideas for Fedora's Anaconda
by Leslie S Satenstein 12 Nov '14

12 Nov '14

I am a Fedora end-user since Fedora core. I have an appreciation of improving Fedora deployment. Here is my take. Current Anaconda Status Anaconda software selection consists of a two column presentation. On the left are the overall groups of software, and corresponding to the right are the packages related to that left side collection. With the split of Fedora into three versions (server, cloud and workspace), is there an advantage to make one higher menu at the top of the page? That Category menu entry would be a roller type presentation, used to select server, cloud or workspace. When the "workspace" download is selected, the packages pertaining to workspace are presented. Similarly the same is done for cloud or server. A better Installation fix There is even a better way to dynamically manage software. "Let anaconda only install the minimum for each group (server, cloud, workspace)". After reboot, allow a post-boot "startup setup program" present and perform the download selection that was normally done as part of anaconda's installation work. This moves software selection to post boot. It could have four major benefit options-- network install, --creation of a local iso image or --creation of a local kickstart file.The fourth benefit is "A single version of anaconda for all Fedora versions". This alternate approach has the advantage that one version of anaconda can remain fixed for every version of Fedora. One single version for live, cloud, server, workspace. Installation software maintenance could be minimized where it would cut the time and cost for producing every newer Fedora version. __________________ Leslie in Montreal Regards Leslie Mr. Leslie Satenstein Montréal Québec, Canada

1 0

Release criteria for dual/multi-booting with other Fedora and other Linux installs
by Adam Williamson 11 Nov '14

11 Nov '14

Hi folks. We've had a discussion going for a few months now over on test@ about release criteria for dual/multi-booting with other Linux installations. I actually thought this discussion had made it here to a-d-l at some point, but it seems I was mistaken in that. So I mistakenly proposed an F21 Final criterion requiring dual-boot with Fedora to work (on the false assumption everyone was already working under that expectation already). I'm withdrawing it as a proposal for F21, but I think it makes sense for F22, so I'm keeping it as a live proposal, and I'll re-post it here: === When installing to a system containing an existing installation of the same Fedora release or either of the two previous releases, the installer must configure the new installation's bootloader such that it can successfully boot the existing installation. [Footnote] Typical configurations only: This criterion applies only to installations (both existing and new) using default or very common storage and bootloader configurations. [Footnote] Platforms: This criterion applies to all supported configurations described in [[Fedora_22_Alpha_Release_Criteria#Release-blocking_images_must_boot|the Alpha criteria]], but does not apply to mixed configurations, e.g. it does not require that a UEFI native installation of one Fedora release be able to configure its bootloader to boot a BIOS native installation of another Fedora release. === What do folks think about that as an F22 Final criterion? In the test@ discussion there's a rather broader proposal from cmurf which covers dual booting with other distros and is less restrictive as to the supported configurations, but I thought it might be easier to get consensus for something more restricted at least as a starting point. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net

6 7

Option to create bridge during kickstart install ?
by Gabriel Somlo 11 Nov '14

11 Nov '14

I'm trying to automate deployment of a server with a single ethernet interface in a way that easily permits vm guests and/or vtun clients to share the (layer-2, ethernet) connection of the host. What i need is for the host to have its own IP address on the bridge interface (e.g br0), which enslaves the physical interface (eth0), and then allow guest or tunnel clients to automatically add their interfaces to br0 (e.g. via "brctl addif br0 <new_dev>"). I found a couple of places on the Web that show how this can be retrofitted to NetworkManager running on an already existing machine: https://avi.alkalay.net/2014/01/fedora-20-virtualization-networkmanager-nat… https://www.happyassassin.net/2014/07/23/bridged-networking-for-libvirt-wit… but what I'd really like is to figure out how to express this during server build via anaconda/kickstart. Looking through http://fedoraproject.org/wiki/Anaconda/Kickstart the "--bond*" and "--team*" options look intrigueing, but details on specific options (e.g. "--bondopts=mode=<foo>") are hard to come by. Would "--bondopts" and "--bondslaves" actually allow me to create a *bridge* rather than an *etherchannel* ? If so, any place to RTFM on the details ? If not, is there something else I could use ? Ultimately, I can probably hack /etc/sysconfig/networ-scripts/ifcfg-eth0 and add /etc/sysconfig/network-scripts-ifcfg-br0 during %post, but I'd really rather not do that if there's a "canonical" way of getting the job done :) Thanks much, --Gabriel

2 1

Re: Revisit Product-ized install repos for Final?
by Brian C. Lane 10 Nov '14

10 Nov '14

On Tue, Nov 04, 2014 at 11:01:08PM -0800, Adam Williamson wrote: > On Tue, 2014-11-04 at 23:33 -0600, Dennis Gilmore wrote: > > On Mon, 03 Nov 2014 07:22:06 -0800 > > Adam Williamson <awilliam(a)redhat.com> wrote: > > > > > On Mon, 2014-11-03 at 08:35 -0500, Matthew Miller wrote: > > > > Adam Williamson <awilliam(a)redhat.com> wrote: > > > > > This isn't about the trees, but about the repository packages we > > > > > created that point to the trees, as part of the alpha attempt to > > > > > do productized netinsts. > > > > > > > > Ah, yes. In that case, +1. However, it has the unfortunate > > > > side-effect of making it harder to count productized repo access > > > > without direct dnf/yum support. > > > > > > The repos weren't designed to be installed in any case, only used > > > during installation. > > > > > > umm we can not remove them, anaconda expects there to be a repo called > > fedora-server or fedora-cloud due to how the compose is done and that > > is not changing. > > why not? we added it in a hurry for alpha, we can remove it easily > enough now. I don't think the anaconda guys want the memory overhead of > the useless extra repos, they seemed in favour of removing them when I > mentioned it in #anaconda. > > CCing bcl. IIRC the change either way is a one-liner to > pyanaconda/packaging/__init__.py which we've already ping-ponged back > and forth like twice. Which change, I'm losing track. We should certainly NOT be shipping f21 with all the repos installed and enabled, it slows down the installation and chews up memory unnecessarily. > > > they need to stick around for f21, we can look at > > doing different things in f22. We need to work with the anaconda guys > > to see what we can do and what changes they will need to make. IIRC the 'include all the enabled repos' hack was a quick fix because nobody had sorted out how to make just the right ones get included during the compose time. IMHO this is a releng problem. Give anaconda the right repos with the right names and it will do the right thing. When you run lorax/pungi and you want to customize the repos you need to install them in /etc/yum.repos.d/ so that lorax will copy them to the image. Also, this discussion should be on anaconda-devel, not a cc list. So I've added it to the cc list. I don't have any particular authority in this, just strong opinions :) -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

7 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 November 2014