Created attachment 684243 [details] Boot Failure Screen Description of problem: Custom formatting can go off on it's own path and delete existing partitions making existing OS's unbootable, swap reallocation from sda2 to sda3 is an example Version-Release number of selected component (if applicable): How reproducible: Attempt to add a second OS in either free space on a disk or an existing partition Steps to Reproduce: 1. Add Fedora18 to an existing multi boot system 2. 3. Actual results: On one system with sda1 - Another Linux and sda 2 - Swap it delected the swap inserted a new sda2 for Fedora and then added sda3 for swap at end of disk The original linux OS on sda1 could no longer boot See screenshot 1 Expected results: Additional info: The "auto routines" in disk partitioning are extremely poor and a regression from the last anaconda On one test with space allocated it then decided to steal other space and add its own lvm volumes as an extended partition in spare space where I specified standard disks and at no time did it indicate it was going to do so At no time did I see an option to specify primary partition or extended The language on screen is completely un intuitive, to use an existing partition the user is expected to take the risk and use the "reclaim space" button to use an existing partition. This language gives the impression of removing partitions There needs to be 3 options on layout type not 2 ie Direct (sda1 sda2 etc) / UID / LVM In it's current state I could not have any confidence in using the installer on an existing "in place" system for risk of having a non booting system
Created attachment 684244 [details] Poor description of disk format options This second attachment shows the poor language on the screen and also the totally redundant/inappropriate button to change software selection which as nothing to do with disk formatting so why oh why is it there The 2 buttons should be Reclaim Space - ie delete some or all existing partitions Use Existing - going to a screen allowing selection of partitions to use
Normally, the installer reuses existing swap space, so I am guessing that the boot hang occurs because a new swap space was created with a different UUID. You may be able to diagnose the problem by comparing the UUID in /etc/fstab with the UUID of the swap space. From rescue mode: # cat /mnt/sysimage/etc/fstab # lsblk -f /dev/sda
Yes thought about fstab and edited it to reflect the change but dracut looks elsewhere and I cant find where as yet A further test has just completed I set up a complete VM with 4 way disk partition inplace prior to running installer I put F18/Mate on first partition, then installed F18/Cinnamon on the second, left the 3rd as NTFS and the 4th as swap. Told the second install not to instal boot loader, it did (still analysing where boot actually is) and in this case it added entries for both OS, description was a bit obscure, the Cinnamon boots fine, Mate took a long time to boot after the second was installed but eventually got there (re arranging swap ?) Looks to me like it will be a miracle if there are not complaints of non working systems, hope I am wrong
solved non boot on first test VM, it was the Grub2 endtry for swap directing to LVM, removed it and it now boots so dracut as per screen shot was using that entry and not finding swap
Please attach /tmp/storage.log, /tmp/program.log, and /tmp/anaconda.log from your initial issue to this bug report so we can have some hope of actually debugging this. Despite all the text here, there's really very little data about what the initial problem was. Exactly how did you have the original system formatted? What was even installed originally? What choices did you make in anaconda? This is yet another bug report along the lines of "while I have your attention, let me mention a hundred other things". These kinds of bug reports are simply impossible to follow, impossible to know when they are fixed, and impossible to know when they can be closed.
Chris, with all due respect this is not "while I have your attention" and it is offensive to make that assertion. I have spent 3 days testing this distribution in a VM environment prior to deployment on inplace systems to avoid broken systems The problems in the disk formatting go well beyond simple debugging Re logs the location you specify does not contain logs, var/logs however does The logs are above
Created attachment 685600 [details] Annaconda log showing unwanted new swap creation This swap file should not have been created, there was an existing swap file
Created attachment 685602 [details] log as requested
Created attachment 685603 [details] Packaging Log
Created attachment 685604 [details] Program Log
Created attachment 685605 [details] Storage Log
Created attachment 685606 [details] anaconda.xlog
Created attachment 685607 [details] Syslog from anaconda directory
Beyond the logs above The system was a relatively simple setup Fedora18 Cinnamon installed sda1, swap on sda2 and unallocated space on disk Attempted to create new partition for f18mate for testing and nominated no boot sector Anaconda elected without warning to reallocate existing swap and created new swap which rendered the existing system unbootable until I found and corrected the grub2 entry There needs to be 1/ If the user does not specify a needed item then a waring needs to be given so the user can correct the problem 2/ A summary screen so the user can see what is about to occur and has the change to say no In it's current state this section of anaconda is simply dangerous and unpredictable
Thanks for the additional info. I could not reproduce the boot failure unless I explicitly removed the swap space logical volume created during the first install while configuring the second install. Here is an outline of my procedure. For simplicity, I used minimal installs from the F18 DVD. Boot installer. Install 1 (bootloader installed): sda1: fedora-root [created] fedora-swap [created] Reboot to installer. Install 2 (bootloader not installed): sda1: fedora-root fedora-swap [automatically reused by the installer, but see note below.] sda2: fedora00-root [created] After completing Install 2, fedora-swap still exists, and Install 1 is bootable. Note: The automatically reused swap space cannot be removed from the new install: Bug 874189 - Swap partition from previous installation cannot be removed from current partitioning Command-line: $ qemu-img create f18-test-2.img 12G $ qemu-kvm -m 2048 -hda f18-test-2.img -cdrom ~/xfr/fedora/F18/F18-Final/Final/Fedora-18-x86_64-DVD.iso -vga qxl -boot menu=on -usbdevice mouse
Steve, thanks, at one point in some tests I also noticed I could not delete a partition but could not see why and blew the VM disk away rather than waste time I saved a copy of the VM with only one OS installed to go back to for further tests so will try to find some time to do so and see if hard info can be isolated Have also commenced a load onto a real spare system with mirrored F14, it initally seemed It would not take over the root drive but then did and when I left the site all was proceeding so it will be interesting to see what transpires when I go back there tomorrow
> Chris, with all due respect this is not "while I have your attention" and it > is offensive to make that assertion. I have spent 3 days testing this > distribution in a VM environment prior to deployment on inplace systems to > avoid broken systems And if you'll re-read what I wrote, you'll see that I have a very specific reason. Bugs that pile on multiple issues are impossible for us to reasonably track. It becomes very difficult to know when a bug has been handled and when it can be closed. It also becomes very difficult to follow all the comments interleaved talking about different issues. We need to track one single thing in one bug.
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.
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.