Tag Archive for 'installer'

The new Anaconda installer

It’s no secret that the new Anaconda installer for Fedora 18 has caused a stir. As part of a major internal re-write, the user interface has been completely re-designed which has caused some confusion and there are bugs and missing features. This is why we included an install video in Korora 18, to help walk you through the process.

However, like all good free and open source software, while this might be the case now it will just keep getting better (especially if users report their problems and post ideas on Bugzilla). Fedora 18 was so delayed that the community didn’t have a chance to address all issues in the interface, unfortunately. Some of the badness has already been fixed for the next release however, with more improvements to come.

So, yes, it might be hard to use for this release but it’s getting better. And thankfully it’s just the installer and not the rest of the interface, so it’s a one-off pain, not an every day one. If it’s really a drama, one could install version 17 and use FedUp to upgrade without using the new installer.

Finally, Anaconda developer Will Woods an excellent blog post on the re-write, which really opens your eyes to the need for it (it’s much, much more than just the user interface).

Here’s some of the content:

Why rewrite, anyway?
Back in August 2009 we were trying to redesign the storage UI to handle modern storage needs. This turned out to require rewriting a lot of the storage back-end code (again) because the existing anaconda code was basically all duct tape and bubble gum, creaking under the strain of modern demands.

You might think I’m exaggerating, but keep in mind that anaconda was originally written in 1999, for Red Hat Linux 6.1, It was designed to run off a 1.44MB floppy, using the still-newish Linux 2.2.x kernel.

In 2009 it still had its own custom initrd init system – called “loader” – written entirely in C. (Statically-linked, too, until 2007.) So anaconda had its own copy of stuff like mount(), and losetup, and mknod.. but no bash before the GUI started. (Good luck trying to debug anything!)

The design pre-dated udev and /sys – and devfs, HAL, and NetworkManager, and dbus – and had its own builtin module loading stuff instead of depmod and modprobe. So anaconda was doing all the hardware setup (probing, module loading and unloading, network setup, disk setup, RAID setup, etc., etc.) by itself… and not always doing it well. And every time there was a new device driver for anything we had to manually add support for it to the installer.

And specifically on the user interface:

And then there’s the GUI. It was single-threaded, so (for example) while we waited for lvm or yum to do something the UI would just.. stop drawing. If you dragged a window around you just ended up with big empty gray blotches until lvm finished and let us start refreshing the UI again.

It was also designed for much smaller screens – 640×480, or 800×600 if you were lucky. You can’t fit much on a screen that size (smaller than your average smartphone!), so it made sense to break the process into a series of steps. Except by 2009 you ended up with screens that looked like this [when setting the root password]:

root password
Great use of space there!

The logic for moving between steps had also gotten really hairy and fragile. Like, as soon as you finished partitioning the disk (but before you picked software to install!) we formatted the disks, because we used to need swap space to even think about running yum. But then what happens if it turns out you need more hard drive space to install the stuff you want? TOO BAD, YOU CAN’T GO BACK NOW!

So on behalf of Korora Project please forgive us for causing you frustration, but we’re here to help and believe us when we say it is already improving!

Updated EFI GRUB2 tarball, including 64bit

I’ve updated the EFI GRUB tarball that I created for my how to install Linux on an Apple Xserve EFI only machine instructions.

The new 89MB file includes both 32bit and 64bit installers (sha1sum). For systems with a 64bit CPU, but not a 64bit EFI, installs of 64bit Linux are possible via the 32bit loader (bootia32.efi). Just boot it and select the relevant 64bit option from the GRUB menu.

It does also include a native 64bit EFI (bootx64.efi) loader which I have not been able to test because the Mac Pro I use does not have a 64bit EFI.

This version drops both Jaunty and Leonidas, but includes a newer Karmic kernel and support for Fedora 12 (Constantine). Thanks to sufehmi, there is also a sample GRUB and X.Org config file included for Debian/Ubuntu.

Instructions
This is covered in my original post, but it essentially consists of the following:

Grab a suitably sized USB memory stick and let’s prepare it. Please know what device it is you’re partitioning!! I’ll use sdz just for example purposes only.
Unmount it
su -c 'umount /dev/sdz1'

Partition and format it
su -c 'parted -s /dev/sdz mklabel gpt mkpartfs EFI fat32 0% 100% toggle 1 boot'

It should now automatically mount. If not, unplug it and plug it in again, or mount it manually.

Next you can extract my tarball onto the device, ensuring that it maintains the efi/boot/ directory structure on it and not create an extra directories because of the archiver. If it’s not right, then re-arrange things and eject the device.

You should now be able to plug it into your Mac and turn it on.

Hold down the Option key (Alt key on non-Apple keyboards) until you see the boot option. It should show “EFI” on the USB stick. Boot this and you should see the GRUB menu load. Choose the distro you want to install and away you go!

-c