Announcement

Collapse
No announcement yet.

Fedora 24 Beta Looks Nice, But Will They Ever Stop Mucking Up Anaconda?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • AdamW
    replied
    Late reply, just got back from holiday. So, a few notes:

    1) We don't just run around changing stuff in anaconda for the hell of it. We change stuff to support new hardware or new requirements (e.g. the Server/Workstation/Cloud split was quite disruptive to anaconda, but everyone seems to like it), or to fix bugs.

    2) anaconda does a *hell* of a lot more than any other distro installer. Primarily in the area of storage support. It can handle things other installers (including ubiquity and calamares) would have no idea what to do with, like FCoE and multipath and RAID-on-LVM. anaconda also supports installation across a lot of platforms, which adds a lot of complexity in bootloader management (though to be fair I guess Debian also has to support that, though I don't know any details of how it does it). These are features Red Hat customers require. They *do* make the installer much more complex, though, and of course the more complex any code base is the more prone to bugs it is.

    3) this is still a Beta. It's gonna have bugs, that's why we ship it - to find bugs and fix them. It would help an awful lot if, when you hit an anaconda crash, you'd click the 'report bug' button and send a report to Bugzilla. Then we'd get a nice bug report with all the relevant logs and the complete traceback, which is what we need to have a hope in hell of fixing it. We certainly have absolutely no hope in hell of fixing it from a screenshot showing a small extract from the storage log. We can't even categorically state that it's a new bug (sorry sgallagh, you're wrong :>)

    4) anaconda's quality has in fact increased hugely in the last couple of cycles, as a result of the introduction of a couple of forms of automated testing for it: openQA and kickstart-tests ( https://github.com/rhinstaller/kickstart-tests ). If you look at the blocker bug lists from F20 to now, the proportion that are in anaconda decreases hugely over that span.

    Leave a comment:


  • mbar
    replied
    Nope, Gentoo has the best installer.

    Leave a comment:


  • gufide
    replied
    Arch has the best installer of all.

    Leave a comment:


  • speculatrix
    replied
    that said, I recently needed to reinstall my laptop running openSuse. although I told it not to, their installer totally trashed both the hard drives in my computer - the primary 128GB SSD, and the 1TB secondary spinner - it created entirely new partition tables losing everything. Luckily, being my laptop there wasn't anything on it I cared too much about.

    Leave a comment:


  • speculatrix
    replied
    a few releases ago I was trying to install it on a machine which had been already set up with mirrored drives, and I wanted it to simply reformat the old root and boot partitions but not the /home (although I'd backed it up).
    it absolutely refused to do that, and even when I tried deleting the mirrors manually to let anaconda create them, I got stuck. I raised a bug report but didn't get very far. In the end I had to do a very hacky work-round which was not something I'd expect anyone fairly new to Linux to achieve.

    once working, I found Fedora to be quite good, but there's no way I could recommend it to anyone who was new to Linux unless they had someone to help them install it.

    Leave a comment:


  • kaczu
    replied
    Will Fedora / Red Hat developers ever stop constantly changing Anaconda? I don't recall any other distribution installer where I've come across so many fatal install problems with it over the years, it seems to routinely be one of the common causes for having to delay Fedora releases, etc.


    I love Fedora because it's only place you can get a good version of Gnome. But good god is installing it the most frustrating thing on Earth, especially if you have a HBA.
    Last edited by kaczu; 11 May 2016, 12:56 AM.

    Leave a comment:


  • droidhacker
    replied
    Originally posted by MartinK View Post
    Well, this is kinda on purpose - many installations run on systems with existing user data:
    - dual boot install
    - home reuse
    - existing data volumes
    - flash drives with data connected during installation
    -etc.

    So Anaconda tries very hard to avoid any unintended data loss - this includes aborting due to any storage related errors and situations the storage code can't safely handle, as in this case.
    Whether you correct the issue now or harass the user by forcing them to reboot 17 times (several of which are repeats in order to catch the bios boot menu..) while taking the same risk is irrelevant.

    I don't think restarting would help much - in most cases (eq. not a race condition) you would just get the same crash over and over again.
    If that were true, then I am currently working from an imaginary computer running an imaginary installation of F24-alpha, and my other machines are ALL running imaginary installations of F22 or F23. Which is clearly not the case since my imagination wouldn't impact what YOU are reading here. Reboot, try again with different package selection, now it works. Or craps out on disk stuff, while it is harassing you to reboot, jump to terminal and dd a bunch of zeros over the start of some disk, rather than an option to try again now that the disks are cleaned up, we have no option besides that button that makes it reboot. I *ALWAYS* have to go through a few tries where it boots me out that way before it actually installs.

    It is frustrating as hell trying to install Fedora.

    Leave a comment:


  • MartinK
    replied
    Originally posted by droidhacker View Post
    Sounds like you work for RH?
    One thing that I would strongly suggest for anaconda, if you fixed THIS, it would really help everyone overlook whatever bugs there are.... don't bail out on the first sign of error!!!! The most frustrating part of the new anaconda is that whenever ANY stupid thing goes wrong, it completely gives up and wants a reboot.
    Well, this is kinda on purpose - many installations run on systems with existing user data:
    - dual boot install
    - home reuse
    - existing data volumes
    - flash drives with data connected during installation
    -etc.

    So Anaconda tries very hard to avoid any unintended data loss - this includes aborting due to any storage related errors and situations the storage code can't safely handle, as in this case.

    Originally posted by droidhacker View Post
    Even restarting just anaconda would be an improvement, or preferably, go back a step when something bad happens.
    I don't think restarting would help much - in most cases (eq. not a race condition) you would just get the same crash over and over again.

    Leave a comment:


  • sgallagh
    replied
    Originally posted by Michael View Post

    That system has no RAID form of any kind.

    Huh, then you definitely struck a bug none of us caught in testing. I hope you will please file a BZ so we make sure it gets fixed for Final release.

    Leave a comment:


  • sgallagh
    replied
    Originally posted by linuxjacques View Post
    "On some setups, installing Fedora over existing firmware or software RAID can cause anaconda to crash. The crash itself messes the disks a little and renders the RAID unusable."
    This is overstated and I will ask someone to correct it. The specific configuration is that if you try to create a RAID array during setup on a system that has an existing RAID configuration using the drives from that previous RAID array, the newly-created one gets produced incorrectly and is unusable (and of course, the one you deleted is no longer there).

    The common bug makes it sound like it will destroy a RAID array that wasn't already selected for replacement, which is not the case. (There's no way at all we'd have let that out the door!)

    Regarding the common bugs page, that's a little out of date because the person who usually maintains it is on vacation this week (unfortunate timing due to last week's schedule slip).

    Leave a comment:

Working...
X