Anaconda/UX Redesign/Current Install Process Analysis

Comparison Between Install Methods

For now, this just includes fresh Live Media and DVD installs. TODO I'm hoping to look at upgrades via DVD and network installs (via boot CD) at some later point.

	Live Media	DVD
Time to Complete (from syslinux to full login)	~20 minutes	1 hour
Resulting package set	TBD	TBD
Network Configuration	Achieved through live environment	New NetworkManager patch by Radek makes possible
Rescue system	Not sure	Yes
External yum repo package installs	No	Yes
Package set customization	None	Available via pirut
Upgrades existing system	No	Yes, within 2 releases
Updated packages not present on media at install-time	No	Yes
Title in Syslinux	"Welcome to Fedora-F14-x86_64-Live-Desktop!"	"Welcome to Fedora 14!"
Syslinux Memory test	Yes	Yes
Media check	No	Yes
Verify & boot	Yes	No
What happens after syslinux?	Flash of a light grey screen, then plymouth	~30s of black screen with techno-babble scroll
Newt interface parts	No	Yes
Installer language selection	Via GDM dropdown before launching anaconda	Dedicated screen in anaconda
Splash Screen	Yes	Yes
Keyboard layout selection	Yes	Yes
Basic & specialized storage device selection support	Yes	Yes
Hostname selection	Yes	Yes
Timezone selection	Yes	Yes
Root password selection	Yes	Yes
Install pattern (replace Linux, use whole drive, etc.) selection	Yes	Yes
Partition layout (optional)	Yes	Yes

User-input classification

Absolutely Essential for successful (interactive) install

• Language selection - you can't install if you can't read the installer; you can't use Fedora (very well) if you can't read it.
• Keyboard selection - a computer is not very useful if you can't input into it.
• License information - we're required to show it.
• Date & Time - (seems like we ask this twice?) User should at least confirm it's correct
  • "<pjones> also date-time has some important ramifications if it's not set before packages start getting installed"
    • See bugzilla 184248
    • <halfline> pjones: does efi fix the "bios has no timezone field" problem?
    • <pjones> halfline: it does!
    • <pjones> ... certainly completely unreliable.
  • What might be easier is to just ask the user, 'what time is it where you are now?' and give them a list of possible time zones to pick from
  • see bug 171187, there's a good reason user should be able to enter the time, manually (new computer, no network and timestamps of the installed files need be OK)

Could Be Provided By the Installer with Optional User Customization

• Hostname - we could auto-generate one and allow it to be customized.
• Root password - we could auto-generate one and allow it to be customized. Generate a solid password.
• Hard drive pattern - Pick one and give users an out to change it.
• Bootloader - you don't need to change it but only for special situations.
  • Dual-boot
• First user username - we could auto-generate this based on their human name and allow it to be customized.
• Password for first user - we could auto-generate one and allow it to be customized.
• Date & time firstboot options - why not network-sync by default; if no network connect detected, only then ask what to do.

Areas in need of serious work

• Install target - it's a confusing screen. the intention was to give users reassurance data partitions weren't being written to but will be mounted, but i think that meaning is lost.
• Partitioning layout - clunky, scary, confusing.

Optional features

• Upgrade - We only support upgrades from n-2 (?) in Fedora.
• Patterns - We *could* (not saying it's a great idea) always wipe the disk and start fresh and still have a successful install.
• Customize repos - You could have a success install without it.
• Customize package set - You could have a success install without it.
• Network login - You can always set this up later in the same exact GUI.
• No first user - If you really don't want a first user you can delete them after.
• Hardware profile - You don't need to send it.
• Media check - You can attempt install without it. In many cases it'll still work. But removing this might make installer debugging more difficult.
• Rescue mode - Could feasibly be provided by separate media.
• Specialized storage devices - You could have a successful install without these.

Could be completed outside of install and firstboot

• Timezone - you can install and run a computer successfully even if it is in the wrong timezone. (But please see TZ discussion above)
• Additional user creation - system-config-users in available on the desktop as well as in firstboot if you want 2nd and 3rd users.
• First user creation - but if you only have root, this sucks as graphical login as root is dangerous and disabled, so you're stuck with command-line tools to take care of this.
• Root password - you could set the machine by default to allow only local logins and not set a password on root at all. Does not having a password on root makes the system more secure? Enable the first user as a member of wheel, and rig console kit to accept sudo passwords.
• Human name of first user - it could be provided on the desktop if you didn't create the first user in firstboot. Maybe a 'first-login' mode for GDM where you're asked there.

Ideas for things to drop

• Any splashes. They are extraneous.
• Anything in newt mixed with GTK, please. It's not very polished-looking.
• Scrolling techno-babble.
• Boot from local disk ("Exit installer" is probably better language)

Questions & Answers with Installer team

Q: I didn't time it exactly, but I got the impression live media install was about 20 minutes, DVD a bit over an hour. Does that seem sane?

• Live can be alot faster than 20 min. It mostly depends on the USB or CDROM speed.
• DVD I'd expect to be about an hour, network (interactive or not) ~20m. DVD takes longer than network because optical drives are slow
• If you throw updates into that it can take longer via network; DVD might actually get a little faster if you've got updates on the network (depending on pipe size though).

Q: We have network install media, jigdo, and boot.fpo - which is the best network install option?

• Jigdo isn't an option. It breaks too often to depend on. Like torrent only far worse.
• kickstart is kind of orthogonal to all that
• the simplest is probably a boot.iso+defaults. you don't need to know a location or anything. boot.fpo is the same but smaller. I used it for one of my upgrades, worked just like boot.iso after selecting the release from the boot menu. 600k download is pretty nice.

Q: What is the difference between the check media newt thing that pops up during dvd install, and 'verifying' your media using the checksums on the website?

• Verifying your media based on the checksums on the website verifies that the download was correct - it doesn't verify the media, just the download.
• Check media (in stage1) tests that a) you burned the media correctly and b) that we can (linearly) read it off the disc correctly. Note that I say "(linearly)" there on purpose - that can succeed but still not be sufficient to actually do a media install :( It is linearly on the disc - but we don't necessarily read it linearly during installation and on some drives that can result in read errors because cd drives are shit.
• There is also a test in syslinux, only on live - 'verify and boot.' Does that verify 'the burn' as well?
  • I think that verifies that the live image decompresses ok

Q: Why is there a memory test in syslinux?

• Primarily because that's the only reasonable place to run it from, and it's a useful "you reported the most bizarre bug" debugging tool.
• Why not have a memory test on some specific rescue image? That menu is also how you get to rescue images ;)
• We have memory test on all the images, except for EFI (because there's a lot of work to be done before it's reasonable to do memtest86+ on uefi.)

Q: Can syslinux have submenus? Maybe a rescue/debug submenu?

• Yes, we could move to using hierarchical submenus if we wanted to. See /usr/share/doc/syslinux-4.02/menu.txt

Q: Can we remove media check?

• I'd be fine with removing media check if I didn't think it'd result in a flood of even more bugs. The only thing worse than media check is the bug reports we'd get without it. IIRC we removed it once for an alpha (because it was broken) and the result was lots of pain. We have to leave in media check. Its the 1st line of defense against bad drives and discs - they're still very common. Even with it we still get those bugs.
• If someone submits a weird bug, you ask them to go thru media check?
  • Yes. Usually its fairly obvious from the kernel errors. Thinks like timeout errors on the /dev/sr0. Depends on the weird bug, too. Sometimes we ask them to do memtest ;)
• Non-optional media check would annoy me greatly. I check once.
  • If you use rw media we could add back the secret bit into the program header to say not to check it, and then give you a utility to frob that bit ;)

Downside: rw media is worse than cd drives. (or, you know, add a command line flag to say you've already tested it and then don't tell anybody that doesn't read the code...)

Q: How much can syslinux be customized? Can the fonts be changed? The border? The welcome message?

• The fonts could be changed maybe, the format is psf. The follow app can convert between ttf and psf and we could experiment to see how well they work:

http://crl.nmsu.edu/~mleisher/xmbdfed.html

• Menu options available at /usr/share/doc/syslinux-4.02/menu.txt
• The welcome message could be removed.
• pjones can try to make it possible to turn off the borders.

Q: Why is basic video driver install a separate choice? Shouldn't it fall back if non-basic is broken?

• In a lot of cases either
  • a) we can't tell that it didn't work in the code, only by viewing the screen, or
  • b) when it didn't work the machine is wedged.
• That'd be nice, but that's not really something we can do. If non-basic is broken you've loaded a kms driver, unwinding from that back to text mode is not really implemented and also not really tractable -and also simply might not work.

Q: Why do we still support dual boots?

• Virt technology is pretty good...
• However,
  • KVM doesn't do passthrough GL yet.
  • If you want to play a game under windows, you probably don't want virt in the way. If you want to play a game under that windows instance, the virt 3d may not be fast enough.
  • In the context of anaconda, tthe only thing that is important to preserve is that if you install windows first and fedora second (after resizing the partition by booting live with gparted), anaconda still knows how to detect windows and configure grub to chainload it.
  • Many students in countries like India have too many things in college which they have to do in windows and vms don't have that power, and for gaming, ps3 or xbox is still too costly.

Q: Why does the DVD installer tell me I can't upgrade from RHEL 6 to Fedora 14? I never expected that.

• If the system is upgradable, it gives you a screen with two radio buttons to choose between upgrade or install.
• If your system is Fedora, but too old to upgrade, that screen is skipped and instead you're given a pop up dialog to tell you upgrade isn't possible.
• The popup appears when you replace RHEL with Fedora, but it probably shouldn't since nobody expects upgradeability there.

Q: What is the UTC clock checkbox all about? What does it mean?

• It's there to make dual-booting with Windows easier. (Windows boxes usually use the local time in BIOS, in Linux some people prefer UTC, though hwclock supports both, see man hwclock).

Q: Why is there a boot from local disk option in syslinux?

• It originated from bug 120687 (https://bugzilla.redhat.com/show_bug.cgi?id=120687)
• There was a concern that people would leave their install unattended, it would finish and reboot back into syslinux instead of into the newly-installed system
• Anaconda attempts (except in kickstart) to eject the disc post-install however kind of obsoleting the need (although we can't eject USB drives for people installing via USB)