(work-in-progress flow diagram) So if you decide to upgrade Fedora, and your Fedora is actually upgradeable (it's one release back), you won't get hub #1 in the installer (http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/02-preinstall_hub.png )... you will pass go and skip directly to hub #2: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Screens/PNG-old/03-progress_hub2.png For simple system configurations, say a laptop with an upgradeable Fedora that has one local disk, this is no problem. The basic steps are: 1) Get a list of storage devices 2) Scan/probe the storage devices to look for Linux that is Fedora that is upgradeable (look at /root partition) 3) Offer to upgrade it 4) You're whisked away to the anaconda network configuration dialog followed by hub #2 and your upgrade happens happily This is sadly not so simple for more complex cases: #1 MULTIPLE UPGRADE TARGETS =========================== If we look around and find multiple copies of Fedora that could be upgraded, we don't know which one you mean to upgrade. We could either pick one (most recent? oldest? newest? first one we saw?) or ask the user which one they want. If we auto-pick, we need to let the user know in some shape or form what's going on. If we let them pick, we need a screen design for that. Here's what we came up with this week: http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Prototypes/Previews/multi-upgrade.png #2 ENCRYPTED DISKS ================== If you want to upgrade and you've got one or more encrypted disks, we can't probe the encrypted disks without prompting you for a password. And in many cases, you can't provide us the password without selecting your correct keyboard layout. Which the UI for right now is in hub #1 which you won't see during upgrade. Some users encrypt just home, but some encrypt the whole enchilada. There was some discussion that /boot or initramfs might reveal Fedora upgrade targets without the need for decrypting, so instead of having the user play peek-a-boo with every single encrypted disk looking for their Fedora we could make an intelligent guess and ask them only to unlock those that have a good possibility of being upgrade targets. But there is a possible security concern here as well if we make it too easy to discover a Fedora upgrade target on encrypted disks, I think? The approach we discussed for this encrypted disk case today roughly proceeds thusly across three sub-cases: 1) Does the user have any encrypted disks? No. Proceed as normal. 2) Does the user have both unencrypted and encrypted disks? Probe the (non-networked/advanced) unencrypted ones. 2.1) If you find valid unencrypted upgrade targets, list them out as in the "multi upgrade targets" case #1 above and allow the user to select between them, but also have an option on the screen to probe encrypted disks as well. If the user selects to probe encrypted disks as well, provide them a list of the disks with a dialog to enter the password for each. The password dialog should have a drop-down that is pre-populated with keyboard layouts related to the language they chose on the first screen, with a 'More layouts ...' option that pops up a complete searchable list of keyboard layouts. 2.2) If you do not find valid unencrypted upgrade targets, offer to allow the user to quit, do a full install, or probe the encrypted disks. If the user selects to probe encrypted disks as well, provide them a list of the disks with a dialog to enter the password for each. The password dialog should have a drop-down that is pre-populated with keyboard layouts related to the language they chose on the first screen, with a 'More layouts ...' option that pops up a complete searchable list of keyboard layouts. 3) Does the user only have encrypted disks? Same as case 2.2 above. #3 NETWORK DISKS ================ If you want to upgrade and your upgrade target is on network / advanced storage, depending on how many storage devices pop up in the list connected to the system, it may take a very, very long time to probe each and every one in search for an upgradeable Fedora target. A possible procedure to address this that we discussed today: 1) User enters Anaconda and wants to upgrade (they select upgrade from syslinux) 2) Anaconda retrieves a list of all (non-network/advanced) storage devices attached to the system. 3) Anaconda probes these non-network/advance storage devices for upgradeable targets. 4) Whether or not Anaconda finds upgradeable targets locally, it returns its findings on a screen to the user, asking them if the one they want to upgrade is there, or if they are looking for a different one. We offer both the opportunity to scan encrypted disks as in issue #2 above, or to scan network/advanced devices. (If we find no upgradeable targets, we also offer to do a full install or exit.) 5) If user opts in to scanning network/advanced devices, we present the storage filter UI to them, and ask them which devices they'd like to look for Fedora upgrade targets on 6) User selects some devices (hopefully not to many) and we do the full /root search for upgradeable Fedoras. During this process, the user sees a full-screen progress animation (not a progress bar, since we don't know how long it will take) with some status information as to what we're actually doing. 7) We present any upgradeable targets we found on the network devices alongside the local upgradeable targest and ask the user to pick which one to upgrade. If we found none, we offer the opportunity to again look in encrypted disks, select other (different) network deviecs looping back to step 5 above, or quit / do a full install. THE MOST ELEGANT SOLUTION ========================= Rather than going through the hassle of selecting and typing in the password to unlock / finding a complex storage device thru the filter UI, Will came up with an approach that eliminates the need to find what you want to upgrade - make preupgrade the defacto upgrade method. Then we don't need all this handling of these 3 odd and complex cases. However, this means preupgrade will need good CLI support. It also means it may need some kind of handling / support in repos themselves to point to the next version repo. (Most repos have a convention where just the release number changes in the repo URL, but maybe someone is using a Satellite server or otherwise has nonstandardized URLs between releases.) It also means, for disconnected users / users with poor network / users who just want to upgrade using the DVD they got from a conference, preupgrade would need to support preupgrade via install media. Maybe using some kind of autostart file on the DVD when you mount it to the system you want to upgrade? I don't know which parts of this are immediate and which are bluesky, but this is the discussion as I followed it today. :) ~m _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
