Bug 880319

Created attachment 652102 [details]
File: anaconda-tb

Created attachment 652103 [details]
File: product

Created attachment 652104 [details]
File: type

Created attachment 652105 [details]
File: ifcfg.log

Created attachment 652106 [details]
File: storage.log

Created attachment 652107 [details]
File: version

Created attachment 652108 [details]
File: environ

Created attachment 652109 [details]
File: executable

Created attachment 652110 [details]
File: anaconda.log

Created attachment 652111 [details]
File: syslog

Created attachment 652112 [details]
File: hashmarkername

Created attachment 652113 [details]
File: packaging.log

Created attachment 652114 [details]
File: cmdline_file

Created attachment 652115 [details]
File: release

Created attachment 652116 [details]
File: program.log

Do you remember what kind of disks you started with (blank vs. populated somehow), and what steps you took?

I don't remember the starting state for this bugzilla. I think the difference between this one and 880277 was here I accidentally set some partitions to be standard partitions but others were set to LVM. Which I suppose is valid, but silly. 

I suspect the disks started off as having a previous f18 LVM install on them, but I'm not certain.

EFI Based Install

Chose autopartition.
Re-Chose Partitioning to manual.
Selected F18 Auto Partition Link
Deleted EFI System Partition it wanted to create.
Mapped Unknown EFI system partition to /boot/efi
Resized Swap to 4g
Resized /boot to 1g
Proceeded to install.

Installer bombed.


Package: anaconda-18.28-1.fc18.x86_64
Architecture: x86_64
OS Release: Fedora 18 Live Nightly

This bug occured during an x86_64 install on a Macbook Pro 8,2 (late 2011).

I've started installation with automatic partitioning on reclaimed space on 8 DASDs where was an older F-18 installation using LVM.

Package: anaconda-18.37
Architecture: s390x
OS Release: Fedora 18

The problem isn't ppc specific.

I've cleaned the old installation in custom partitioning and let anaconda to create the default LVM setup

Package: anaconda-18.37
OS Release: Fedora 18

install & format ext2 to SSD

Package: anaconda-18.37.11
OS Release: Fedora release 18

Whenever I try to install Fedora 18, I receive the error message "this program has encountered an unknown error," then the system crashes

Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Was performing installation of F18. Went through normal configuration, told it to start installation, this error occurred while it was creating the ext4 /home partition. I setup custom partitioning for dual-boot with Mac OS X, both split across two disks (500GB disk and 120GB SSD). Both /home and / were on separate disks, both LVM partitions and both encrypted.

Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Now that I've seen a few of the other comments (okay, `abrt` is cool) a few things I'll add:

this is on a mid-2010 MacBook Pro 6,2 laptop, EFI booting, dual-boot with Mac OS X.

This is my *second* F18 install on the hardware - the first one overwrote rEFIt in the MBR (see Bug 901933) and I wanted to re-install to confirm proper behavior, and also set up the root partition, in addition to /home, to be LUKS encrypted. So there was an existing F18 install on the disk, setup as a mix of physical and LVM partitions. This error did not occur in the original install, which I attempted to replicate as closely as possible by just adding mountpoints to the existing partitions, and setting a number of them to reformat with new disklabels.

Install just started when I was prompted to configure the root password.  Crash happened while I was in the middle of inputing the password.

Package: anaconda-18.37.11
OS Release: Fedora release 18

Created attachment 683549 [details]
traceback and anaconda.log - error window contents

I tried deleting all of the partitions I created for Fedora through Mac's Disk Utility tool (theoretically bringing the disk back to its initial, Mac-only state) and then re-running Anaconda. Same error. Looking at anaconda.log here, it looks like this may be something related to my selection of encrypted partitions.

(In reply to comment #27)
> Install just started when I was prompted to configure the root password. 
> Crash happened while I was in the middle of inputing the password.
> 
> Package: anaconda-18.37.11
> OS Release: Fedora release 18

lmickh, these are really just hunches, but can you answer the following:
1) what type of hardware you're running (does it happen to be a Mac? if so, what model?)
2) did you choose to encrypt any/all of the partitions?
3) are you installing to an SSD (solid-state/flash disk)?
4) what was installed on the disk when the error happened? Had you already tried to install Fedora or another Linux? If so, which one(s)?

Thanks.

I have an updates image that should fix this issue. To use it, add the following to the boot command line when booting the installation media:

 updates=http://dlehman.fedorapeople.org/updates/updates-880319.0.img

Jason,

1) It is a Lenovo U410 laptop.
2) No encryption
3) It is a hybrid system.  /boot and /root were being installed on the SSD.  Everything else on a SATA drive.
4) Fedora 17 was installed previously.  All partitions aside from /home were reformated for the F18 install.

I'm trying what seems to be a fairly unusual install: from an x86-64 live image on USB on to a UEFI system using GPT partitioning.  The GPT labels contain a LUKS set consisting of an LVM physical volume, which has my root and swap parititons.

After targeting the disk as the boot device, I came up against the 'you have not created a bootloader stage1 target device'.  As there was no way to create a 'BIOS boot' partition, which the internet suggested would help, removing the bootable flag from the disk allowed me to continue.  Unfortunately I was thwarted at the very next step, by Anaconda dying.


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

(In reply to comment #30)
> I have an updates image that should fix this issue. To use it, add the
> following to the boot command line when booting the installation media:
> 
>  updates=http://dlehman.fedorapeople.org/updates/updates-880319.0.img

David - this has fixed the immediate problem for me.  Hopefully the rest of the install works too! Thanks.

see below 

Package: anaconda-18.37.11
OS Release: Fedora release 18

Install of Fedora 18. 

Install source: Fedora 18 KDE Live iso burnt ont a USB stick with persistent memory. dracut and initramfs updated. Anaconda not updated (no update available).

Platform: Macbook Air mid-2012 (hardware 5,2)

Problem occurred during disk setup part of install after diskpartitioning.

The disk had been partitioned prior to the install using "gdisk" for partitioning, mkfs.ext2 for creating separate 2 GB partition for /boot, pvcreate, vgcreate and lvcreate to make two partitions on a LVM, one encrypted and one plain.

The install let me define mount points for the selected partitions, then started formatting the disks and crashed somewhere in/after creating EXT4 file system on the encrypted LV. 


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Should be duplicating 880319.

I added updates=http::.... .img to the beginning of the boot line (hit e at install medium GRUB boot menu) I do not know if this had any effect


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

Assuming this is goinmg to turn up in 880319 again.

I don't think the "updates" boot argument is getting through (anaconda.log doesn't show it). So, I tried calling anaconda manually. Which did get me a change to "PRE-RELEASE/TESTING" but it still crashes. A bit later (after initialising my encrypted volume). 

One perhaps unusual thing: I'm not asking for a bootloader (since it's a Mac I'm sort of hoping to just use the built-in UEFI). So, I have no disk marked as bootloader install target (i.e. the green tick removed from the SSD which is the only disk; I no longer an error about not having selected a target for bootloader installation).


Package: anaconda-18.37.11-1.fc18.x86_64
OS Release: Fedora release 18

(In reply to comment #37)
> Assuming this is goinmg to turn up in 880319 again.
> 
> I don't think the "updates" boot argument is getting through (anaconda.log
> doesn't show it). So, I tried calling anaconda manually. Which did get me a
> change to "PRE-RELEASE/TESTING" but it still crashes. A bit later (after
> initialising my encrypted volume). 

Still do not have a clue about this.

However:

> 
> One perhaps unusual thing: I'm not asking for a bootloader (since it's a Mac
> I'm sort of hoping to just use the built-in UEFI). So, I have no disk marked
> as bootloader install target (i.e. the green tick removed from the SSD which
> is the only disk; I no longer an error about not having selected a target
> for bootloader installation).
> 

OK. I defintely had to learn to stop worrying and love the automatic partitioning :).

This was my first UEFI install and I went into it wanting to do mainly what I had done for F17 and so on. This was a mistake.

So, by deleting anything except the OS X partitions I wanted to keep and letting anaconda make its own layout and by setting the main disk as bootable, I got a system which works (modulos the GRUB-to-OS-X boot know problem ; holding down "option" when booting gets me the built-in boot selector so that's hardly fatal).

I'm experiencing the same error on my Asus UX31A (EFI based laptop). Adding a check whether boot is of NoneType fixes the error for me (installation works fine, doesn't crash).

same issue on system76 gazelle p8. do not want grub installed or fedora to touch my boot sectors in any way. much cleaner with native efistub setup and refind (arch, suse, ubuntu are all playing nice already this way.)

looks like Frank's solution could work, but I do not understand exactly what 'adding a check whether boot is of nonetype' means.

appreciate any help.

no grub install, separate ssd and hdd partitions, adding below to grub boot line from grub menu allows a normal install and subsequent native kernel efi stub boot.

updates=http://dlehman.fedorapeople.org/updates/updates-880319.0.img

still interested in frank's solution for later use.

thanks.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

dlehman, this is very old, but I can't see the magic word 880319 in anaconda or blivet git logs, or on anaconda-patches list: do you recall if the fix for this actually got pushed? thanks!

Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

This got fixed in python-blivet-0.5-1.

let's change its status then. I'm helping! I'm helping!