Anaconda-devel October 2013

anaconda-devel@lists.fedoraproject.org

24 participants
17 discussions

Idea for making custom partitioning more accessible
by Máirín Duffy 24 Dec '13

24 Dec '13

Hi, Some user feedback and usability testing we've done indicates that having custom partitioning accessible only by a pop up dialog attached to the 'done' in the storage spoke is confusing - people search for custom partitioning on the first storage spoke screen, don't see it, give up and hit done, then they see it. I think we should consider providing a better pathway to it on the main screen rather than hiding it on the dialog. I think I was overzealous in trying to shield less-technical ("non-Pokemon") users from it in the original mockups and unnecessarily hurt the users wanting to access custom part. We had a discussion about this in IRC today, and after a few iterations (we started with http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… and iterated from there) I put some more work into a set of mockups that might work. The thing is, it's hard to just add a button here or move something there without affecting a lot of other things - in this case, the display of the dialog on exit from storage entirely and the encryption and autopart type options. Okay so here's a little walkthrough: AUTO-PART USER ============== 1) You click on the storage spoke icon and you see this: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… You might opt-into disk encryption, and you leave everything else alone. 2) You click 'Done' in the upper left corner. You go straight to the hub. Yeh. So basically: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… Anything you would have been able to do in the dialog you already did in the main window. Except for choosing auto-part type. If you're not going into custom part, is the default auto-part type good enough? If not, the main screen design will need more thinking. CUSTOM PART USER ================ 1) You click on the storage spoke icon and you see this: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… 2) You click on the radio button that says "I will configure partitioning" and hit Done. Then you'll see this: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… You pick the auto part type you want in the dropdown and hit create to let it do its thing and then tweak accordingly. Or you can start from scratch if you're into that. 3) You click on the 'done' button in the upper left corner of custom part and it does the same as it does now (summary of changes, then back to the hub) RECLAIM DISK SPACE POP-UP ========================= Just a small mod to this one, since encrypt and autopart type are available else where, drop them: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… NO DISK SPACE POP-UP ==================== No changes to this guy: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Sketches/Straight-To-Custo… Does this make sense? I know Chris had concerns about having two columns of options on the screen because translations can get lengthy, so I cut the text length substantially and did a vertical stack of options, but I made the radio buttons horizontally aligned (which the HIG actually allows for, who knew.) I also scaled the disk icon down to 96x96, although 64x64 might work better (need to account for icon height of network disks too.) The only sticking point here is that auto-part folks won't get to choose their flavor unless they go into custom. But maybe it's good, people who don't really know the difference won't have to even make the choice. And it's easy enough to go into custom, hit auto part for the flavor you want, and get out? Thoughts? ~m

7 12

GPT (and ultimate UEFI)
by Gene Czarcinski 13 Nov '13

13 Nov '13

One of these days, we are going to get GPT partitioned disks good, bad, or indifferent. In "regular" install mode with automatic configuration, the "bootbios" partition is automatically allocated. In "regular" install mode with custom configuration, you cannot proceed until a 1MB "bootbios" partition have been comfigured. [I am not sure if this has to be the first thing configured or not.] So, what should be done with kickstart where gpt is specified as the kernel parameter and something like: clearpart --all --initlabel --drives=vda is specified? Alternates: 1. Add option(s) to part for creation of the "bootbios" partitions or (and better) 2. Make allocation of the "bootbios" partition part of "clearpart" processing. I notice that clearpart --initlabel not does "gpt" for itanium. Comments? Gene

5 4

Re: [PATCH] btrfs subvolume reclaim option for kickstart
by Gene Czarcinski 31 Oct '13

31 Oct '13

I was originally going to reply on the patches list but this is more appropriately a discussion so I am moving it over to the discussion list. This is the reason for all my agony over testing. On 10/31/2013 08:13 AM, Gene Czarcinski wrote: > This involves a patch to pykickstart and a patch to anaconda. > > The patch for anaconda was created on anaconda-20.25.4-1 and the patch > for pykickstart was created on r-1.99.44-1 and should easily apply or > rebase. > > The patches implement a capability currently available if you perform a > non-kickstart custom-allocation install where you can reclaim the name > (and space) of an existing btrfs subvolume and then reuse (recreate) a > new btrfs subvolume of the smae name over it. > > The are times in both virtual and real world when a reinstall is needed. > Currently, when this involves a btrfs subvolume as root, you have to manually > delete that subvolume. The capability implemented in these patches allows > a kickstart user to do that at install time. > > Note: "--reclaim" was chosen for the option since it is both different and, > at the same time, the same as the term used in a non-kickstart install. > > NOTE: While I believe that these two patches are good. However, they have > been only partially tested due to problems with pungi/lorax creating ISOs > with working BTRFS! > > Gene Czarcinski (1): > add btrfs option reclaim > > pykickstart/commands/btrfs.py | 4 ++++ > 1 file changed, 4 insertions(+) > > Gene Czarcinski (1): > add reclaim capability for btrfs subvolumes > > pyanaconda/kickstart.py | 8 ++++++++ > 1 file changed, 8 insertions(+) > OK, now that I understand how to create an updates image which includes anaconda changes AND pykickstart updates, I have conducted some additional tests. I have been testing on Fedora 19 although the submitted patches are for Fedora 20 ... they rebase easily enough. The problem: storage.destroyDevice(device) gets an "Attribute error: Blivet object has no attrribute 'destroyDevice' Now, I had done some testing with just anaconda by kluging things up. I changed the if self.preexist: to be if self.preexist and self.mountpoint != "/": and then were I now have: if self.reclam: I then had if self.preexist: The point being that the storager.destoryDevice(device) was the same and I traced it going to destoryDevice() in blivet/__init__ around line 1172. The two patches are below. What is different? This is driving me nuts. ------------------ The Fedora 19 kluge ----------------------------- diff --git a/pyanaconda/kickstart.py b/pyanaconda/kickstart.py index 5bcad3d..287d6c1 100644 --- a/pyanaconda/kickstart.py +++ b/pyanaconda/kickstart.py @@ -343,7 +343,9 @@ class BTRFSData(commands.btrfs.F17_BTRFSData): if self.mountpoint != "" and self.mountpoint[0] != '/': raise KickstartValueError, formatErrorMsg(self.lineno, msg="The mount point \"%s\" is not valid." % (self.mountpoint,)) - if not self.format: # --noformat + # FIXME: The following hack only exists until pykickstart can be updated to separate + # --noformat and --useexisting into separate parameters so they can have different meanings + if not self.format and self.mountpoint != "/": # --noformat if not self.subvol: raise KickstartValueError, formatErrorMsg(self.lineno, msg="Specifying btrfs command for existing volume %s invalid" % self.name) @@ -368,6 +370,16 @@ class BTRFSData(commands.btrfs.F17_BTRFSData): except KeyError: pass + # Handle pre-existing subvol to be deleted + if self.subvol: + device = devicetree.getDeviceByName(self.name) + if device: + if self.preexist: + storage.destroyDevice(device) + log.info("As requested by specified --useexisting, destroying existing BTRFS subvolume %s" % self.name) + else: + raise KickstartValueError, formatErrorMsg(self.lineno, msg="Specified BTRFS subvolume %s already exists, specify --useexisting to recreate" % self.name) + request = storage.newBTRFS(name=name, subvol=self.subvol, mountpoint=self.mountpoint, -- 1.8.3.1 ------------------------------------------------------------------------------------------------------------------------- --------------------The "good" Fedora 19 version ----------------------------------------------------------------------------------------- diff --git a/pyanaconda/kickstart.py b/pyanaconda/kickstart.py index e6ed38d..53d4dd4 100644 --- a/pyanaconda/kickstart.py +++ b/pyanaconda/kickstart.py @@ -387,6 +387,14 @@ class BTRFSData(commands.btrfs.F17_BTRFSData): device.format.mountpoint = self.mountpoint else: + if self.subvol: + device = devicetree.getDeviceByName(self.name) + if device: + if self.reclaim: + storage.destoryDevice(device) + log.info("As requested by specified --reclaim, destroying existing BTRFS subvolume %s" % self.name) + else: + raise KickstartValueError(formatErrorMsg("Specified BTRFS subvolume %s already exists" % self.name)) request = storage.newBTRFS(name=name, subvol=self.subvol, mountpoint=self.mountpoint, -- 1.8.3.1 ----------------------------------------------------------------------------------------------------------------------------

1 0

help ... please
by Gene Czarcinski 31 Oct '13

31 Oct '13

Testing patches made to anaconda is relatively easy given the capability of using an updates image. However, when a change involves anaconda and python-blivet and/or (as in my case) pykickstart, it is more complicated because, to the best of my knowledge, you need to respin an ISO to do the test. Now a bunch of years ago (ten to twelve to be exact) I did do some work requiring that I rebuild the anaconda boot and found it a faily easy thing to do. Time passes and anaconda code has changed. in addition, we now have pungi, lorax, etc. to help us build ISOs. Well, I have just spent the last three days beating my head against the wall. First of all, pungi/lorax does not work well if it is working with anything other than the single rawhide repository -- e.g., it expects the syslinux package (and other packages too) to be in the first repository or it cannot find it and the build fails. Most important for me is that pungi/lorax cannot build an ISO with a working BTRFS. So ... help ... please! Can someone tel me how to make pungi/lorax produce an ISO with a working BTRFS? Or, can someone point me to the software you folks use to build an ISO when you want to test changes to anaconda/pykickstart/python-blivet/etc.? This may not be specifiic software but more of a process or procedure but the current pungi/lorax it is not. Gene

6 9

Fedora 20 Beta blocker bug status: fix and karma requests
by Adam Williamson 28 Oct '13

28 Oct '13

Hi folks, and welcome to the Fedora 20 Beta blocker bug news... The bad news is that we're still some way from a viable Beta RC. We need work on several blockers, all of which is outlined below. I'll start with bugs that need work from developers; QA folks, there are tasks for us listed later on. Accepted blockers - anaconda and python-blivet ---------------------------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=986575 - "installer fails to apply lower bound to resize requests in custom spoke" - this bug has been open for a while and needs a fix from anaconda team, when they have time. * https://bugzilla.redhat.com/show_bug.cgi?id=1010495 - "Apple Mac EFI: you have not created a bootloader stage1 target device" - this bug breaks the most common installation scenarios for Apple systems (guided install alongside an existing OS X install). bcl has been working on fixing it: back in September he posted an initial patch, then decided that it was not sufficient - https://lists.fedorahosted.org/pipermail/anaconda-patches/2013-September/00… . There is no information since then that I can find. * https://bugzilla.redhat.com/show_bug.cgi?id=1016959 - "ValueError: Cannot remove non-leaf device 'btrfs.14'" - this is a crasher with certain existing btrfs volumes. dlehman posted a plan on how to fix it, but there is no proposed patch that I can find. Accepted blockers - other ------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=1000891 - "DVD is oversized (larger than 4.7 GB)" (spin-kickstarts, comps, pungi) - a fix for this was scheduled for TC3, but it caused the DVD compose to break, and was backed out to produce a testable TC4. TC5 continued without the problematic fix (and hence is still over-size). AIUI, dgilmore was supposed to be looking into the compose issue, but I believe he is now on vacation, so we may need someone else to step in: CCing nirik and notting. * https://bugzilla.redhat.com/show_bug.cgi?id=1013767 - "rootfs on thinp not found, startup failure" (dracut) - an update containing a fix for this has been submitted - https://admin.fedoraproject.org/updates/dracut-034-18.git20131018.fc20 - but one reliable tester has reported that it breaks boot on their system, so further developer work may be required here, harald: https://bugzilla.redhat.com/show_bug.cgi?id=1021083 * https://bugzilla.redhat.com/show_bug.cgi?id=1015234 - "F20 Beta TC1 ARM disk images unable to find root filesystem" (dracut) - this bug is marked as an unresolved blocker but has in fact been worked around since, I believe, TC2. We can probably ship Beta with the workaround, and this may just need some Bugzilla Bureaucracy rather than developer attention at this point. Proposed blockers ----------------- * https://bugzilla.redhat.com/show_bug.cgi?id=1020974 - "incorrectly treats a disk with partially corrupt GPT as having no partition at all" (anaconda) - this looks like it could well be accepted as a blocker, so developer attention would be appreciated. * https://bugzilla.redhat.com/show_bug.cgi?id=1005895 - "Upgrade to f20 fails because of deltarpms" (fedup) - Will posted a proposed fix for informal testing; Will, one of the reporters has confirmed the fix is good, so can you please submit an update? Thanks! Bugs requiring QA attention --------------------------- * https://bugzilla.redhat.com/show_bug.cgi?id=1017435 - "Anaconda uses LVM when Standard Partition is selected in text mode" (anaconda) - this bug has been verified fixed by the update https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anacond… , but that update needs more karma to go stable. That is the build that is in TC5, so anyone who's tested TC5 and found it generally OK (no worse than previous builds) can +1 the update: please do! * https://bugzilla.redhat.com/show_bug.cgi?id=1013800 - "devicetree.py:1293:handleVgLvs:DeviceTreeError: failed to look up thin pool" (python-blivet) - this is believed to be fixed by the https://admin.fedoraproject.org/updates/python-blivet-0.23.1-1.fc20,anacond… update (and hence in TC5). We need to verify the fix and add karma to the update so it can be pushed stable and the bug closed. * https://bugzilla.redhat.com/show_bug.cgi?id=1019500 - "device factories need to set a default name if empty name given for defined device" - exactly the same as 1013800: this should be fixed in TC5, please confirm the fix and up-karma the update. This has been your blocker bug news, folks - if everyone can help out with fixing the remaining issues and testing the anaconda/blivet update, that'd be a great help. Thanks! -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin DOT net http://www.happyassassin.net

4 16

PyCon PL 2013 Anaconda slides
by Martin Kolman 24 Oct '13

24 Oct '13

Slides from my Anaconda talk on PyCon PL 2013[1] are available here: http://modrana.org/pyconpl2013/the_anaconda_installer.pdf The talk was being recorded and according to the organizers it should show up online with the other conference videos in about a month. Kind regards Martin Kolman PS.: I've also talked about developing Android application in Python, slides & examples are here: http://modrana.org/pyconpl2013/python_and_qt_for_android.pdf http://modrana.org/pyconpl2013/examples/ http://modrana.org/pyconpl2013/pyconpl.apk [1] http://pl.pycon.org/2013/en/

1 0

patch to improve display of keyboard layouts
by Jens Petersen 22 Oct '13

22 Oct '13

Hi, I wanted to have this patch for some releases now and finally found time now to work on it this week. (Also attached to https://bugzilla.redhat.com/show_bug.cgi?id=1021907) Short summary is that this changes the display of keyboard layouts from "English (English (US))" to "English (US)", ie it avoids the unnecessary repetition. The final patch is actually quite simple, almost simpler than the current code perhaps. It checks is if the translated xkb layout description starts with translation of the language and if so just displays the translated description, otherwise it displays "lang (description)" as now. I feel this makes the layout display less confusing and easier to read so I hope this small patch could be reviewed and accepted for Fedora 20. I have tested it pretty carefully for most of the major languages and it seems to work well. Thanks, Jens

1 0

splash image and the progress bar under it
by Kun Huang 17 Oct '13

17 Oct '13

Hi all The splash image and the progress bar under it occer

2 4

One more translation question
by Gianluca Sforna 16 Oct '13

16 Oct '13

Can anyone help me understand what the following strings in blivet refers to? create format destroy format resize format Thanks Gianluca -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu

2 1

Translation question
by Gianluca Sforna 16 Oct '13

16 Oct '13

While translating anaconda to Italian I noticed there are several instances of the string "custom partitioning" but the corresponding screen in the interface is then titled "MANUAL PARTITIONING" Is this difference intentional? You can probably think this is just bikeshedding, in fact I think I noticed just because the translation for "manual partitioning" is much easier and sound more native than the one for "custom partitioning" By the way, I tried an F20 installation in a VM after several releases where I just upgraded all my machines; you guys surely did a lot of improvements over the first iteration, really smoother than I remembered. Thanks for all the hard work! Regards Gianluca -- Gianluca Sforna http://morefedora.blogspot.com http://identi.ca/giallu - http://twitter.com/giallu

2 1

Patch submit/review/? process
by Gene Czarcinski 16 Oct '13

16 Oct '13

Could someone explain just what to process is for patches submitted for anaconda and related packages. There is the patch mailing list but that seems to be something of a black hole. Many of the submitted patch messages are not even in plain-text (mbox) format so that they can be used as input to patch/git without a lot of manual effort. This is very different from other projects that I have worked on. Just how does one go about getting a patch accepted so that it gets added to the anaconda, pykickstart or python-blivet repositories? With respect to BTRFS, I am simply trying to get things so that anaconda-kickstart has basic functionality. The two areas my recently submitted patches address are currently supported by the GUI. Gene

3 5

support for existing BTRFS subvolumes
by Gene Czarcinski 15 Oct '13

15 Oct '13

II have complete creation and testing of a patch which adds kickstart support for existing BTRFS subvolumes to be added to the /etc/fstab when it is created. This patch includes having each existing subvolume specified using the UUID of it parent BTRFS volume. The patches are available as part of bugzilla report: https://bugzilla.redhat.com/show_bug.cgi?id=892747 Each patch can be applied to anaconda in a git repository and used to create an updates disk for testing. Therefore I have created two versions of the patch: Fedora 19 with anaconda-19.30.13-1 and Fedora 20-beta-TC2 with anaconda-20.22-1. The updates disk for Fedora 20 was build on a Fedora 20 TC1+ hardware system and then tested installing on kvm virtuals with F20-beta-TC2+all-repos. That is all I can say is ... it works. I sure would like to see this in Fedora 20!! As I have currently implemented things, the patch changed things so that either --noformat or --useexisting can be specified for an existing BTRFS volume with the same results. For an existing subvolume if --noformat is specified, then the patch adds code so that that subvolume will be added to the anaconda created /etc/fstab with the UUID of the subvolume's BTRFS volume. For an existing subvolume if --useexisting is specified, then you get exactly the same thing that you get right now ... nothing! Proposal: As I examined the code, it became obvious to me that it would be easy to add the equivalent of "reformat" for a BTRFS subvolume by simply deleting the current subvolume of the specified name and then recreating it. Not only that but if "--useexisting" is used to specify that functionality, this would be consistent with what is done for logical volumes where --noformat is used to mean "leave it alone: and --useexisting to mean reformat. I do not like cross-posts so I will be posting a duplicate of this message to the kickstart mailing list. Gene

2 4

Stabilize anaconda development earlier in the cycle.
by "Jóhann B. Guðmundsson" 15 Oct '13

15 Oct '13

Greetings I have been thinking about how we in QA are supposed to be able to manage covering 3 or more products ( depending how the outcome of the directions end up being ). Now given that Anaconda is one of our larger time consumer in QA it will requires us to stabilize anaconda development earlier in the cycle and be completely done at branch time or alpha so we can dedicate the remaining time of the development cycle to try to cover the "products" as well as any test days and other QA related activities. Now obviously we will need an extra development to be able to implement this from both ends as well as formulate how we go about testing this etc and FESCo wanted solid justifications for possibly providing extra development time for F21 before their meeting next so it would be good to get some thoughts comment on this from you guys/girls since this probably is the only time we will have to be able to do this for the next years. Is this something we could/should do? How much time would it be required to achieve this from your end? Is this something we cant do? if so why? JBG

9 23

question about network installs
by Jeremy Eder 13 Oct '13

13 Oct '13

Hi all, The servers I have have a large number of NICs. Anaconda is waiting 120 seconds on each NIC for DHCP, even if there is no link. Only one NIC, em1, has a cable attached. This is on a lab network and em1 gets a DHCP address just fine. So far we've tried: ip=em2:off ip=em3:off etc...but anaconda bails on this to emergency dracut shell despite what's on this page https://fedoraproject.org/wiki/Anaconda_Boot_Options?rd=Anaconda/Options Then we tried dhcptimeout=10 ... but that only seems to apply to the first NIC. subsequent NICs take 120s. Also tried ksdevice=em1 ... worth a shot even though we're not kickstarting. Then someone showed me this: http://wwoods.fedorapeople.org/doc/boot-options.html#_ip So I tried adding this: ip=:::::em1:dhcp ip=:::::em2:off ip=:::::em3:off ip=:::::em4:off bootdev=em1 But no luck, em2,em3,em4 still waiting 120sec on each. I understand the ip:::::em1:dhcp might conflict with the "only one interface" thing on the page above. But...we need one interface to be dhcp in order to install. So, what's the correct way to have the install commence immediately when dhcp succeeds on the first NIC ? Thanks.

3 3

RFE: journalctl in /var/log/anaconda by default for F20
by Chris Murphy 12 Oct '13

12 Oct '13

syslog is disabled by default. While anaconda crashing bugs now get a journalctl automatically attached to the bug report, a successful install does not contain the journal in /var/log/anaconda which can be useful for troubleshooting why certain things aren't working on reboot despite a successful installation. Is it possible to have anaconda drop in a journalctl -b > /var/log/anaconda/anaconda.journalctl.log file? I suggest explicitly -b in case the install media is live with overlay which might mean persistent logging is enabled. Chris Murphy

2 1

[Wanted] Stories, ideas and other tidbits for a conference talk about Anaconda
by Martin Kolman 02 Oct '13

02 Oct '13

I'll be attending as an invited special speaker[1] the PyCon PL[2] conference that takes place on 17-20 of October in southern Poland. One of my talks is titled "The Anaconda Fedora and RHEL installer"[3]. With the date of the conference getting closer, I've started preparing for the Anaconda talk and wanted to ask you to also chime in with any interesting Anaconda-related stories, anecdotes, interesting technical tidbits, funny pictures, achievements, heroic bugfixing sagas, newly born projects, ghost stories, bold plans for the future, elaborate programming constructs, etc. Basically anything you thing an appropriate conference talk about anaconda can't miss. :) I'm looking forward to your responses ! :) Best wishes Martin Kolman [1] http://pl.pycon.org/2013/en/aktualnosci,Announcing-invited-special-speakers… [2] http://pl.pycon.org/2013/en/ [3] http://pl.pycon.org/2013/en/agenda - Saturday 19.10. 16:00 in the conference room nr. 1

1 0

creating iso images
by Gene Czarcinski 02 Oct '13

02 Oct '13

I am not sure where to ask this question. If it is not this list, please point me to the correct one. I decided that I wanted to get ahead of things and be able to boot a version which was not currently available as an iso image. After some googling, I found this: https://fedoraproject.org/wiki/How_to_create_a_Fedora_install_ISO_for_testi… A few years ago I had manually recreated iso images but this looked to be lots simpler. I have used mock to build rpms but I have not previously used pungi. Anyway, I plunged in but with NO success. I thried hostin on both F19 and F18. I tried building on both F19 and F18 (my intent was to do this on F20 & rawhide but first get it working on a good system). Besides my "netinst.ks" file. I tried the fedora-install-fedora.ks file and the fedora-livecd-desktop.ks file. All had the same error which I show below. Since iso images are being produced, it must be something i am or am not doing ... in other words: pilot error. --------------fedora-netinst.ks--------------- # A simple kickstart file for creating a netinstall iso # Tue 01 Oct 2013 11:50:43 AM EDT lang en_US.UTF-8 keyboard us timezone US/Eastern auth --enableshadow --passalgo=sha512 selinux --disabled firewall --disabled xconfig --startxonboot ################### repo config ############################ #repo --name=rawhide --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=rawhide&arch=$basearch repo --name=fedora --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=fedora-$releasever&arch=$basearch repo --name=updates --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-released-f$releasever&arch=$basearch #repo --name=updates-testing --mirrorlist=http://mirrors.fedoraproject.org/mirrorlist?repo=updates-testing-f$releasever&arch=$basearch --------------------------------------------------------------------------------------------------------------------------------------- <mock-chroot>[root@falcon /]# pungi --nosource --nodebuginfo --flavor Fedora \ --name Fedora --ver 18 \ -c /usr/share/spin-kickstarts/fedora-netinst.ks \ -G -C --force <mock-chroot>[root@falcon /]# pungi --nosource --nodebuginfo --flavor Fedora \ --name Fedora --ver 18 \ -c /usr/share/spin-kickstarts/fedora-netinst.ks \ -B --force -------------------------------------------------------------------------------------- running runtime-cleanup.tmpl creating the runtime image losetup: /work/Fedora/x86_64/installroot/images/runtime-workdir/LiveOS/rootfs.img: failed to setup loop device: No such file or directory Traceback (most recent call last): File "/usr/bin/pungi", line 256, in <module> main() File "/usr/bin/pungi", line 146, in main mypungi.doBuildinstall() File "/usr/lib/python2.7/site-packages/pypungi/__init__.py", line 937, in doBuildinstall workdir=workdir, outputdir=outputdir) File "/usr/lib/python2.7/site-packages/pylorax/__init__.py", line 272, in run compression=compression, compressargs=compressargs) File "/usr/lib/python2.7/site-packages/pylorax/treebuilder.py", line 158, in create_runtime label="Anaconda", size=fssize) File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 328, in mkext4img mkfsargs=["-L", label, "-b", "1024", "-m", "0"], graft=graft) File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 308, in mkfsimage with LoopDev(outfile, size) as loopdev: File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 213, in __enter__ self.loopdev = loop_attach(self.filename) File "/usr/lib/python2.7/site-packages/pylorax/imgutils.py", line 73, in loop_attach dev = runcmd_output(["losetup", "--find", "--show", outfile]) File "/usr/lib/python2.7/site-packages/pylorax/executils.py", line 420, in runcmd_output return execWithCapture(cmd[0], cmd[1:], **kwargs) File "/usr/lib/python2.7/site-packages/pylorax/executils.py", line 263, in execWithCapture raise subprocess.CalledProcessError(proc.returncode, [command]+argv) subprocess.CalledProcessError: Command '['losetup', '--find', '--show', '/work/Fedora/x86_64/installroot/images/runtime-workdir/LiveOS/rootfs.img']' returned non-zero exit status 1 <mock-chroot>[root@falcon /]# ls 18 builddir fedora lib64 mnt proc sbin tmp var bin dev home logs opt root srv updates work boot etc lib media ourtree run sys usr <mock-chroot>[root@falcon /]# ls 18/ Fedora <mock-chroot>[root@falcon /]# ls 18/Fedora/ x86_64 <mock-chroot>[root@falcon /]# ls 18/Fedora/x86_64/ os <mock-chroot>[root@falcon /]# ls 18/Fedora/x86_64/os/ Packages repodata repoview <mock-chroot>[root@falcon /]# ls work/ Fedora <mock-chroot>[root@falcon /]# ls work/Fedora/ x86_64 <mock-chroot>[root@falcon /]# ls work/Fedora/x86_64/ docs Fedora--name-18-comps.xml installroot yumroot <mock-chroot>[root@falcon /]# ls work/Fedora/x86_64/docs/ <mock-chroot>[root@falcon /]# ls work/Fedora/x86_64/installroot/ bin etc home lib64 modules root srv usr boot firmware images media opt run sys var dev fonts.scale lib mnt proc sbin tmp <mock-chroot>[root@falcon /]# ls work/Fedora/x86_64/yumroot/ bin etc fonts.scale lib64 modules root sbin tmp var dev firmware lib mnt proc run sys usr --------------------------------------------------------------------------------------------- Gene

3 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel October 2013