> 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 Right now, we set up yum and RPM to use the newly created filesystems for its temporary storage. Thus, we likely can't do the dry run until we create filesystems. Of course, we could always go back to using our in-memory filesystems as the temp space to get around this. I'd have to go back and look up our rationale for setting things up this way. > 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. We can't achieve a 100% solution to this. We'll just have to make educated guesses, err on the side of not destroying things, and document it. > 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'. I'll need to add resize syntax to kickstart for this to work. > Saving KS > ========= > > 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? I'd kind of seen the saving as a more intentional step, so you would be more likely to attach the storage device next time you booted up anyway. I think clever wording on the save dialog might help here. > We could have a little inconspicious 'Continue a previous installation' > on the front language selection / splash screen maybe?? Yeah, we could do that. In loader right now, there's already a dialog for changing the ks= URL should you provide an incorrect one. If we are really clever with the method selection dialog, we could reuse it for selecting your kickstart location too. Not at all related, this reminds me I should see how much of kickstart processing I can remove from loader. - Chris _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
