[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

UX Redesign: Dual Boots / Resize issues / Saving KS



Here's some UX redesign discussion notes from #anaconda today, with the
todos/questions 'action items' upfront:

Action items / Questions
========================

* Figure out boot camp instructions for mac users, a test run-through
might be good (anybody got a mac and a copy of bootcamp?)

* 'BOOTCAMP' partition auto-detection

* Check / if !BOOTCAMPpart && hw = mac, display 'you need to run
bootcamp' screen as very first screen

* Figure out chkdsk instructions for Windows users

* Work with websites team on redesign for get.fpo to accommodate all
this

* Documents for root of install disc for Mac boot camp / VM install /
windows

* (mo) Investigate non-grub issues users are currently complaining about
re: linux+linux dual boots

* grub2 upgrade, will it make linux+linux dual boot better?

* Investigate/implement resize dry-run mode, including resize estimate &
rpm test run to see how much space selected sw choices will take

* Need solution for not-enough-space for upgrades issues (because of
scriptlets' temp space?)

* KS file save to usb option, incl. screen under quit button to ask if
you'd like to save

* KS file auto-detect functionality, incl. screen to ask if you'd like
to continue from previous KS or start fresh

Dual Boots
==========

We talked about the user experience for three types of users who already
have an operating system installed:

- Mac users with OS X installed (<= likely a key portion of our target
userbase we're not accommodating very well today)
- Windows users
- Non-Fedora Linux users
- RHEL users

The story here is a user who's already using a non-Fedora OS, who is
ready to try Fedora but doesn't want to blow away their old OS in case
they decide to bail out. 

The recommended path for these users is going to be dependent on their
starting point:

- Windows users: chkdsk, then Anaconda
- Mac users: Boot Camp, then Anaconda
- non-Fedora Linux users: resize

Let's walk through each user scenario, going over the points that were
brought up for each:

Windows User
============

Install path:

chkdsk => anaconda resize => dual-boot install

The Windows users need to run chkdsk before going into anaconda. They
need to run chkdsk because if their filesystem is dirty, chances are
high that a resize operation will corrupt their filesystem (the chances
of filesystem corruption when you resize without chkdsk are even greater
if they are using Vista or Windows 7.)

There isn't much we can do for them; they really need to run chkdsk on
their own. One resource we do have at our disposal is ntfsfix, which is
a utility that can fix common errors, but the downside to this is that
if users press any key while it runs, it'll skip the filesystem check
operation, rendering the whole process useless. So we'll need to lean on
them and make sure we document well the chkdsk process. Will found this
following documentation on shrinking partitions in Windows:

http://technet.microsoft.com/en-us/library/cc731894.aspx

Elad has experience supporting Windows users and is familiar with the
tools involved as well.

Mac User
========

(The doom some Mac users have experienced getting grub working to start,
and GNOME 3 graphics working to finish aside)

Boot Camp => anaconda auto-detect bootcamp partition => dual-boot
install

We don't have any support for resizing HFS/HFS+ partitions which is the
main filesystem Macs use. So out-of-the-gate, Anaconda resizing is not
possible for Mac users. Boot Camp is the Apple supported way of
dual-booting, so we need to advise our Mac users starting out that they
should work in Boot Camp first, then install Fedora.

Will had the amazing idea that we could autodetect bootcamp partitions
in anaconda so when these Mac users end up in the installer, we'll have
the storage settings they need ready-to-go and they won't need to touch
them. The Boot Camp partitions are easy to detect: look for a FAT32
partition labeled "BOOTCAMP".

We had another idea: we can detect if a user is using Mac hardware. In
the case they are using Mac hardware AND we don't detect a "BOOTCAMP"
partition, we could push a warning screen before hub #1 that tells them
"You should run Boot Camp before installing Fedora (unless you really,
really know what you're doing." and offer a quit button.

Grub issues will hopefully be improved when we upgrade to Grub2.

Non-Fedora Linux Users
======================

anaconda resize => dual-boot install

We have a few problems in our dual-boot Fedora + another Linux story
today:

* We don't label other distros properly in GRUB
* We don't tell other bootloaders about Fedora. If you install Fedora
first, then install another Linux, you won't have a boot entry in your
bootloader for Fedora by default. For less-experienced dual-booters,
this means they won't be able to boot Fedora (fail)

I think we need to do some more research on folks' complaints about
Linux+Linux dual boot scenarios with Fedora, these are mostly GRUB
issues but I think there might be issues too in the storage section,
when we auto-detect a Linux partition I don't think we say what distro
it is either.

RHEL users
==========

Folks looking to try out RHEL usually install to a virtual machine, so
they don't face the storage quandries that would be a lot more common
for the Fedora use cases above.


Supporting Users in these scenarios
===================================

Some of these (Mac most notably) paths aren't documented at all today on
the Fedora website. Others could stand to use a bit more documentation &
guidance (*especially* on the download Fedora pages of the Fedora
website.) 

Some ideas:

* More information on the get.fedoraproject.org webpages to guide users
depending on which OS they are starting out with

* Peter's awesome idea: have QR codes so that folks can read the
instructions on their smart phone as they install on their machine
(useful if they have a smartphone and only one laptop)

* Have documentation in the root of the disc for these scenarios,
especially important if the users received a physical disc from a
conference and did not go through the website. Document suggestions:

  * Mac Boot Camp instructions
  * VM Installation instructions
  * Windows instructions

* Have blurbs on the sleeves for printed Fedora media for each of these
scenarios as well


Resize issues
=============

We also talked about how the storage UI pieces fit into the overall UI
screen map. 

There's a complication that resizing introduces. The designers would
like all options in hub #1 to be non-commital and reversable until the
users hit the 'proceed with installation' button. However, the resize
case is not reversible at this time.

A solution could be to implement a dry-run version of resize.

Here's the issue: we don't know how much space we'll have available
post-resize. We can only know by running it today, since there is no
dry-run version.

A dry-run version of resize would need two components:
(1) Dry run of the resize to determine how much space we'd get
(2) A dry run of the RPM transaction to determine how much space we'll
need

There's a complication with upgrades here too, especially during
preupgrade. The amount of space an install needs - the estimate can be
off enough to cause the upgrade to fail. In Will's words:

"We can *guess* how much room RPM will want for the install but it's not
a guarantee until we actually try to run the transaction with the disks
live."

Confounding factors include the temp space scriptlets consume.

One potential work-around is to save out the resize operation commands
in the kickstart, and not run it until the user hits 'proceed to
install'. 

'Apply', in the context of Hub #1, is 'save to kickstart object.

Saving KS
=========

This all led into a discussion about our plans to save out partial KS
for users who bail out before installation.

There's a couple of ways we could go:
- Save out to a KS file every time a field in a hub spoke is modified
AND  when the user hits 'proceed' or 'quit'
- Save out to a KS file only when the user hits 'proceed' or 'quit'

Not sure which is best, the later is easier to do but maybe work would
be lost if we didn't do the former and a crash occurred.

The story for saving a kickstart:

You're jamming around anaconda filling stuff out, and you realize it's
5:30 and it's time to go home. No time for an install. You hit
'Quit' (maybe not intuitive, maybe needs to be 'Save and Quit') and a
dialog pops up:

"If you'd like to save your selections to a kickstart file to use later,
insert a USB key with at least $FILESIZE free, and press the 'Save'
button below. Insert some awesome instructions here on how you'd proceed
with the install later on. \n Otherwise, you can quit using the 'Quit'
button below." <= okay not the best verbiage but you get the gist

Okay, so you go home, eat dinner, sleep, head back into the office where
Anaconda awaits you. You turn the machine back on. It looks for a saved
KS file. Oh crap, you forgot to insert your USB key. Okay, so now that
I'm writing this up, I'm realizing auto-detection is maybe stupid
because who would remember to insert the USB key before turning anaconda
on?  

We could have a little inconspicious 'Continue a previous installation'
on the front language selection / splash screen maybe??

In either case, somehow you are miraculously compelled to insert a USB
key with a KS file valid for the version of Fedora you're installing. If
we find this KS file, a dialog pops up, before you hit hub #1:

"We've found a previous install attempt from $DATE. Would you like to
continue with this previous installation, or would you like to start
fresh?"



---

Okay I'll try to integrate this into the wiki discussions page now. I'm
a bit behind on documentation here; I've got tons of notes; just need to
get them in the wiki. :)

Here's the full log btw
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Notes/irc-log-21june2011.txt

~m



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]