<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 10/23/2013 08:10 AM, Jim Kinney
wrote:<br>
</div>
<blockquote
cite="mid:CAEo=5Pyec5rtQET4V0CSJkkk2CoQR9dKjvFFj7fax2i75AAg8g@mail.gmail.com"
type="cite">As a l o n g time red hat then fedora user, I
thought the new installer in fedora 18 was bad implementation of a
decent but unpolished idea. </blockquote>
<br>
I can't comment on Fedora 18's installer, as I've never used it. I
installed Fedora 17 and then used fedup to update to 18, 19, and
then 20 alpha.<br>
<br>
However, due to a problem in 20 alpha (actually, several problems,
but the primary one was its failure to interact with my FreeIPA
domain) I had to roll my system back to Fedora 19, so I used the
installer.<br>
<br>
I found more than one problem with it, and I was actually going to
start a thread about it, but since you've already done so...<br>
<br>
My system is an MSI 970A-G46, which has UEFI as well as a BIOS which
can run in the context of the UEFI firmware. The firmware
implementation is, so far, just fine. However, Fedora 17 would <i><b>not</b></i>
install in UEFI mode, so I had to install it using the BIOS
emulation. That was less than ideal, but whatever.<br>
<br>
Fedora 19 <i>did</i> install in UEFI mode, <i>but it required two
separate installs!</i> Well, actually, <i>three</i>. Ish.<br>
<br>
<b>Attempt the first</b>: Found that booting in UEFI mode didn't
matter to the installer if the disk had an existing MBR but no GPT.
Could have been handled in the installer code, but for whatever
reason, it was not. Not terribly surprising, though; I can see the
assumption that the user wishes to keep the familiar unless they're
installing on a brand-new disk to be reasonable. So, I used parted
and created a new GPT table on the device. The installer refused to
see the changes, though, so a restart of the installer was required.<br>
<br>
<b>Attempt the </b><b><i>second</i></b>: Again, booted in UEFI
mode. Selected Cinnamon desktop (it's what I've been using the most
lately, outside of my experimental GNUstep environment) and all
add-on features. After about an hour or so of churning (egads, I <u><b><i>really</i></b></u>
hate the inefficiencies of the RH method of package management), the
installer <b>crashed</b>. Why? "Failed to remove the existing
bootloader." Duh, there wasn't one to remove. Okay, well, fine.
So, I spent another hour trying to get the mostly-installed system
functional. At this point, I really want to have a talk to the
person that thought it was a good idea to run all of the
post-installation tasks after the bootloader installation. <i>The
bootloader installation should be the last blooody thing done, so
that if it fails, the system can at least be bootstrapped manually
and repaired.</i> Instead, the system had all its binaries and no
configuration, and the amount of configuration in the post-install
process performed by Anaconda is non-trivial, so...<br>
<br>
<b>Attempt the <i>third</i>:</b> Again, UEFI booted the install
media. Overwrote the installation with just a Cinnamon install, no
add-ons. Waited another hour (<i>what?! I asked the installer to
install nearly 800 less packages, and it took the same amount of
time?! Next time, I'm just going to go ahead and install them all
anyway, then.</i>) for the system to churn about and <i>this</i>
time the bootloader installation worked, post-install tasks ran, and
I was on my merry frickin' way.<br>
<br>
I <b>did</b> check out the manual installer. I reasoned that it
was about as usable as lead for disk partitioning, so I simply used
parted. Luckily, that can be done in a VT alongside the installer,
but as I mentioned above, a restart of the installer is required for
it to detect that you've made any changes to the media; simply
running partprobe or kpartx isn't enough.<br>
<br>
Sigh.<br>
<br>
— Mike<br>
<br>
<div class="moz-signature">-- <br>
<table border="0">
<tbody>
<tr>
<td> <br>
</td>
<td> Michael B. Trausch<br>
<br>
President, <strong>Naunet Corporation</strong><br>
☎ (678) 287-0693 x130 or (855) NAUNET-1 x130<br>
FAX: (678) 783-7843<br>
</td>
</tr>
</tbody>
</table>
</div>
</body>
</html>