Anaconda-devel June 2013

anaconda-devel@lists.stg.fedoraproject.org

16 participants
10 discussions

27 Jun '13

This[1] patch provides facility to utilise EXTLINUX under the RAID1. Successfully tested in a two disc setup with a standalone /boot array and as a part of the / array. Grub is good reference, as always. You can test via updates image[2]. poma [1] 'bootloader-extlinux-mdraid1.diff' - attach. [2] ftp://ftp.leeds.ac.uk/incoming/extlinux/updates-extlinux-mdraid1.img

1 0

anaconda crash, obviously invalid disk config
by Chris Murphy 27 Jun '13

27 Jun '13

https://bugzilla.redhat.com/show_bug.cgi?id=969684 This bug is sortof a mess in terms of comments because the crash can be triggered with multiple boot loader install failure causes. But the consistently triggerable ones are LDM partition scheme (which grub2 doesn't support at all apparently) and a disk without an MBR gap. So technically it's a release blocking bug because it's an obviously invalid layout, and anaconda crashes. But at the same time: a.) both are rare cases, with LDM being more common; b.) we're an inch from release so a fix would add more risk than benefit; c.) no prior anaconda could make such a system bootable, although F17's anaconda doesn't crash. The crash itself is a regression. Chris Murphy

2 2

Anaconda Kickstart + Creating a btrfs volume issues
by Amit Saha 18 Jun '13

18 Jun '13

Hello, (Apologies if this seems to be an abuse of this list) I want to create a btrfs volume in my kickstart file apart from the ones needed for installing the OS (Fedora 19) (assume ext4 for those). These are the relevant lines from my kickstart file: clearpart --all --initlabel part / --fstype=ext4 --size=5000 part /boot --fstype=ext4 --size=500 part swap --recommended part btrfs.01 --size=1024 btrfs none --label=f17 btrfs.01 I expect this to work as per [1]. However, it doesn't. Here is the traceback: anaconda 19.30.3-1 exception report Traceback (most recent call first): File "/usr/lib/python2.7/site-packages/blivet/devices.py", line 789, in create raise DeviceCreateError(str(e), self.name) File "/usr/lib/python2.7/site-packages/blivet/deviceaction.py", line 272, in execute self.device.create() File "/usr/lib/python2.7/site-packages/blivet/devicetree.py", line 237, in processActions action.execute() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 310, in doIt self.devicetree.processActions() File "/usr/lib/python2.7/site-packages/blivet/__init__.py", line 169, in turnOnFilesystems storage.doIt() File "/usr/lib64/python2.7/site-packages/pyanaconda/install.py", line 138, in doInstall turnOnFilesystems(storage, mountOnly=flags.flags.dirInstall) File "/usr/lib64/python2.7/threading.py", line 764, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.7/site-packages/pyanaconda/threads.py", line 168, in run threading.Thread.run(self, *args, **kwargs) DeviceCreateError: ('1', 'f17') Local variables in innermost frame: self: non-existent 1024MB btrfs volume f17 (13) with non-existent btrfs filesystem e: 1 Here is the anaconda-tb-OwFcOY file [2]. These lines seem really strange to me: 23:14:00,396 INFO program: Running... mkfs.btrfs --label=f17 /dev/vda7 23:14:00,458 INFO program: 23:14:00,460 INFO program: WARNING! - Btrfs v0.20-rc1 IS EXPERIMENTAL 23:14:00,461 INFO program: WARNING! - see http://btrfs.wiki.kernel.org before using 23:14:00,462 INFO program: 23:14:00,463 INFO program: fs created label f17 on /dev/vda7 23:14:00,465 INFO program: nodesize 4096 leafsize 4096 sectorsize 4096 size 1.00GB 23:14:00,465 INFO program: Btrfs v0.20-rc1 23:14:00,466 DEBUG program: Return code: 0 23:14:00,480 INFO program: Running... udevadm settle --timeout=300 23:14:00,505 DEBUG program: Return code: 0 23:14:00,506 INFO program: Running... udevadm settle --timeout=300 23:14:00,516 DEBUG program: Return code: 0 23:14:00,518 INFO program: Running... udevadm settle --timeout=300 23:14:00,532 DEBUG program: Return code: 0 23:14:00,535 INFO program: Running... udevadm settle --timeout=300 23:14:00,545 DEBUG program: Return code: 0 23:14:00,550 INFO program: Running... mkfs.btrfs --label=f17 /dev/vda7 23:14:00,562 INFO program: /dev/vda7 appears to contain an existing filesystem (btrfs). 23:14:00,563 INFO program: Use the -f option to force overwrite. 23:14:00,563 INFO program: Why does it invoke mkfs.btrfs twice? The storage.log is here [3]. [1] http://fedoraproject.org/wiki/Anaconda/Kickstart#btrfs [2] http://paste.fedoraproject.org/19514/37159847 [3] http://paste.fedoraproject.org/19515/37159861 Thanks for any help. Best, Amit. -- Amit Saha <http://echorand.me> Infrastructure Engineering and Development Red Hat, Inc.

2 2

Re: Bug 963998 - IVB RHEL7 AlphaRC3 with iSCSI installation due to bootdev argument not found
by Harald Hoyer 18 Jun '13

18 Jun '13

On 06/17/2013 05:18 PM, Jason Willeford wrote: > Harald, > Cisco would like to test this fix. With it being an anaconda bug how to you go > about testing install fixes? Do you build an iso image with the patched package > added? > Thanks, > --J > > -- > Jason Willeford, RHCE > Senior Technical Account Manager > Red Hat > 1-888-RED-HAT1 x 47219 > 919-754-4219 Direct > 919-754-3701 Fax > > jwilleford(a)redhat.com <mailto:jwilleford@redhat.com> > www.redhat.com <http://www.redhat.com> > > I personally don't build iso images... CC'ing anaconda team.

2 1

Thoughts on bug 969327 - possible threading problem
by Brian C. Lane 14 Jun '13

14 Jun '13

https://bugzilla.redhat.com/show_bug.cgi?id=969327 I'm unable to reproduce this myself, but after much staring at the code and the provided logs (and logs from my own successful runs) I'm worried we may have a problem with hubQ. Notice that in both sets of anaconda logs the "spoke is ready: ..." and "setting <object> status to: ..." come in batches, right next to each other. They are nowhere near the threads that send the messages, most are happening after their associated threads are actually done. This could be a logging artifact, maybe they just aren't being logged until later for some reason. But since the reporters are seeing actual problems I am suspicious that something is holding up hubQ and it is processing them all at about the same time. If you look at the successful run they all happen early. In the failed run they are late, and something in their ordering triggers running AnaExecuteStorageThread a second time which seems to be the source of the actual error. Even in the successful run they don't look the way I'd expect. For example DatetimeSpoke being set ready should be near AnaDateTimeThread, but it isn't -- even in the successful run it is after the thread finishes running. Anyone have any ideas for debugging this? -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)

2 1

New failure to compose on f19 x86_64.
by William F. Acker WB2FLW +1 303 722 7209 14 Jun '13

14 Jun '13

It looks like the mkfs.msdos command disappeared from the latest version of dosfstools (3.0.20). I have no idea why this only affects x86_64 and not i686. Maybe it's an EFI thing. HTH. -- Bill in Denver

1 1

Unable to compose on x86_64.
by William F. Acker WB2FLW +1 303 722 7209 11 Jun '13

11 Jun '13

Hi all, I don't know if this should go here or buildsys, but I thought I'd try here first. Around the time of anaconda-19.30.3, I'm getting this. rebuilding boot/upgrade-3.9.4-301.fc19.x86_64.img /usr/lib/dracut/modules.d/99base/dracut-lib.sh: line 80: /proc/cmdline: No such file or directory populating output tree and building boot images running x86.tmpl template command error in x86.tmpl: install boot/efi/EFI/*/MokManager.efi EFI/BOOT/ IOError: nothing matching /home/wacker/19/work/x86_64/installroot/boot/efi/EFI/*/MokManager.efi in / Traceback (most recent call last): File "/bin/pungi", line 256, in <module> main() File "/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 316, in run treebuilder.build() File "/usr/lib/python2.7/site-packages/pylorax/treebuilder.py", line 220, in build self._runner.run(templatefile, kernels=self.kernels) File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 180, in run self._run(commands) File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 199, in _run f(*args) File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 232, in install for src in rglob(self._in(srcglob), fatal=True): File "/usr/lib/python2.7/site-packages/pylorax/ltmpl.py", line 95, in rglob raise IOError, "nothing matching %s in %s" % (pathname, root) IOError: nothing matching /home/wacker/19/work/x86_64/installroot/boot/efi/EFI/*/MokManager.efi in / Any ideas? TIA. -- Bill in Denver

4 11

Anaconda usability testing
by Filip Kosík 10 Jun '13

10 Jun '13

Hi all, there is my final report from usability testing at DevConf.cz (including my recommendations) for Anaconda 19.8 (Fedora 18). It was supplemented by my review of Anaconda in Fedora 19 Beta RC4. http://www.visionplus.cz/anaconda/Analysis-v-2013-06-08.pdf Filip

1 0

re:
by Leslie S Satenstein 05 Jun '13

05 Jun '13

http://seminarski-diplomski.co.rs/likeit.php?mdau862ykxcge lsatenstein Leslie S Satenstein ================ People in networked markets have figured out that they get far better information and support from a rock than from most Linux distributors. -- Joshua Nowell

1 0

F19 beta crash specifying extlinux
by Chris Murphy 04 Jun '13

04 Jun '13

Is extlinux expected to work with the extlinux parameter passed at boot? I'm getting a crash at bootloader install time. https://bugzilla.redhat.com/show_bug.cgi?id=970184 Chris Murphy

4 6

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel June 2013