Bug 857607

Created attachment 613119 [details]
File: ifcfg.log

Created attachment 613120 [details]
File: anaconda-tb

Created attachment 613121 [details]
File: product

Created attachment 613122 [details]
File: type

Created attachment 613123 [details]
File: environ

Created attachment 613124 [details]
File: storage.log

Created attachment 613125 [details]
File: version

Created attachment 613126 [details]
File: program.log

Created attachment 613127 [details]
File: anaconda.log

Created attachment 613128 [details]
File: syslog

Created attachment 613129 [details]
File: hashmarkername

Created attachment 613130 [details]
File: packaging.log

Created attachment 613131 [details]
File: cmdline_file

Created attachment 613132 [details]
File: release

Created attachment 613133 [details]
File: description

but this was not the most interesting thing that happened there. the most interesting thing is that my partitions were broken and in some case, deleted

i'll copy/paste from the test-list:

"
being tired of the dracut selinux infinite loop, i've decided this morning to reinstall f18 from f18 x86 netinst disc. all attempts to boot with standard options failed with a kernel crash (maybe my video card is broken). i eventually managed to reach anaconda by booting in safe graphics mode. there, i've completed the steps required (what is the target device, what software, time zone) then pressed continue. then, i've been hit by this: https://bugzilla.redhat.com/show_bug.cgi?id=857607 . I've seen this before on same system in the previous 5 (?) years so that was not a big surprise. a big surprise was that after i reboot, something messed my existing linux partitions (actually one of them is missing). what do i mean by 'messed'? well, first, grub2 fails to load a menu saying that "no such partition" and offers a grub shell. then, in f17 rescue mode, the system complains that i have no linux partitions. going to rescue mode's shell, the partitions are marked "Linux", but the last one (#7) is missing. then i booted system rescue cd. there, mount /dev/sdb{1,5,7} /mnt/mountpoint ended with something similar to "broken ntfs signature". adding -t ext3 in the mix didn't help, error was something like "bad superblock etc".
THIS is something i don't remember to have ever seen on fedora (alpha, beta or final).

from personal experience, i believe something is deeply wrong in the anaconda logic. and of course, the back and forth mess is also a problem. why not just continue to the next required step, with back being an option, and at the end present a summary of completed and incompleted steps, if any?

btw, on systems with many hard disks (at least 2), if linux/anaconda is unable to tell which is the first hard disk system will boot, why not install grub on all hard disk, just to be sure?

"

maybe i'm wrong, but it seems to me that before this bug, there was:

https://bugzilla.redhat.com/show_bug.cgi?id=431641

and before that, 

https://bugzilla.redhat.com/show_bug.cgi?id=109987

, among others.

i performed manual partitioning, selected the first disk

i deleted all partitions (and one member of a raid0)

then i created a /boot (standar partition), a / (btrfs) and a swap.


Package: anaconda-18.37.11
Architecture: x86_64
OS Release: Fedora release 18

Attempted a minimal install of Fedora 18. Network install, auto select install source based on closest mirror. Deleted all existing partitions from disk and selected automatic layout. Wired ethernet, DHCP address.

Package: anaconda-18.37.11
Architecture: x86_64
OS Release: Fedora release 18

Hi All,

Trying to install Fedora 18 x86_64 on my server and it fails during the setup of disk , below is the error that occurs, please let me know if there are any questions.


Package: anaconda-18.37.11
Architecture: x86_64
OS Release: Fedora release 18

Said root password not set and then it failed

Package: anaconda-18.37.11
OS Release: Fedora release 18

Please retest with F19 Beta TC4. We won't be making any updates to F18.