2011/6/22 Máirín Duffy <duffy@xxxxxxxxxxxxxxxxx>
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,
It fixes common errors and then forces windows to run a full check in the next boot.
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.
That's not a bug we can fix, that's just what windows does...
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
Which is useless, because:
Windows partitioning tools can't resize the main OS drive (drive C).
The UI is ugly and not usable, users will have problems with it.
Windows partitioning tools can't resize the main OS drive (drive C).
The UI is ugly and not usable, users will have problems with it.
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
Well, we can't do rpm transaction dry run in anaconda for network installs before we download everything.
My idea was, simply adding a new field to comps with auto-generated size requirement for the specific group defaults that will be generated on compose time. (I'm not sure Infra will like this idea though).
If we want to allow individual package selection, the filed should have the installed size for each package in comps (and be in the package definition, not group definition), not for the whole group.
My idea was, simply adding a new field to comps with auto-generated size requirement for the specific group defaults that will be generated on compose time. (I'm not sure Infra will like this idea though).
If we want to allow individual package selection, the filed should have the installed size for each package in comps (and be in the package definition, not group definition), not for the whole group.
There's a complication with upgrades here too, especially during
preupgrade.
As I've mentioned, upgrades doesn't need re-sizing, (and iirc you *can't* change the partition scheme during upgrades).
From the log:
From the log:
elad661: upgrades doesn't needs resizing though elad661: we can do this checks only in resize usecase wwoods: elad661: ...true! sorry, I think I need a cup of tea and a break before I continue thinking about this
Saving KS
=========
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??
Yes, but only when we didn't detect any saved installation. This button shouldn't replace auto-detection, it would be just another method.
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?"
Here's the full log btw
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Notes/irc-log-21june2011.txt
~m
--
-Elad.
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
