Okay, newer patch implementing resizing. Still against an older tree (726a485e58706b70c8fb2b9d4febe938a7c88963) but just to get it out there while I work on the fun of rebasing to the current code and merging with dlehman's encryption bits.
The patch implements the following: 1) Adds "pulsing progress bars" for GUI where you have the progress bar bounce due to something taking an indeterminate amount of time. We should also be able to use this for other filesystem creation options that we don't know how long they take. For text mode, this just gives a message and no progress bar 2) Moves writing out partitioning and mounting filesystems to be right after the partitioning screen. Note: this still needs something to let the user know that their changes are going to be done immediately 3) Adds support for resizing partitions in the autopart loop. This requires the pyparted patch which I sent last time 4) Determines the maximum size a partition can be grown to 5) Adds support for resizing ext[23] filesystems and determining the minimum size of the ext[23] filesystem 6) Cleans up the graphical UI when editing a pre-existing partition and adds support for resize. Contrast http://katzj.fedorapeople.org/resize-poc.png to http://katzj.fedorapeople.org/new-edit-part-dialog.png
At this point, I'm pretty happy with how things are looking and am probably going to go ahead and commit once I get things rebased unless anyone has any strong concerns. There are still some more things which can be done, but they can be easily done as small follow-up patches.
Jeremy
On Wed, 2007-11-28 at 15:00 -0500, Jeremy Katz wrote:
Okay, newer patch implementing resizing. Still against an older tree (726a485e58706b70c8fb2b9d4febe938a7c88963) but just to get it out there while I work on the fun of rebasing to the current code and merging with dlehman's encryption bits.
Demo at http://katzj.fedorapeople.org/resizing-demo1.ogg
Jeremy
Very cool! This looks really promising.
Most of my installations are done by kickstart. Therefore I'm now dreaming about support for resizing using kickstart. Is this feature planned?
Cheers, Niels
On Wed, 2007-11-28 at 15:57 -0500, Jeremy Katz wrote:
On Wed, 2007-11-28 at 15:00 -0500, Jeremy Katz wrote:
Okay, newer patch implementing resizing. Still against an older tree (726a485e58706b70c8fb2b9d4febe938a7c88963) but just to get it out there while I work on the fun of rebasing to the current code and merging with dlehman's encryption bits.
Demo at http://katzj.fedorapeople.org/resizing-demo1.ogg
Jeremy
Anaconda-devel-list mailing list Anaconda-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/anaconda-devel-list
On Thu, 2007-11-29 at 11:10 +0100, Niels de Vos wrote:
Very cool! This looks really promising.
It's been a long time coming and is really pretty overdue
Most of my installations are done by kickstart. Therefore I'm now dreaming about support for resizing using kickstart. Is this feature planned?
The hardest part about exposing it in kickstart is that the syntax gets to be ... incredibly painful with our current language for describing partitioning in kickstart. Thus I'm not sure if it's really worth piling more on there.
Jeremy
On Thu, 2007-11-29 at 07:53 -0500, Jeremy Katz wrote:
On Thu, 2007-11-29 at 11:10 +0100, Niels de Vos wrote:
Very cool! This looks really promising.
It's been a long time coming and is really pretty overdue
Well, I think it's pretty good work anyway :)
Most of my installations are done by kickstart. Therefore I'm now dreaming about support for resizing using kickstart. Is this feature planned?
The hardest part about exposing it in kickstart is that the syntax gets to be ... incredibly painful with our current language for describing partitioning in kickstart. Thus I'm not sure if it's really worth piling more on there.
I understand. Maybe I'll be able to propose some possible command structure... ATM I can't get a real concept together yet. Lots of options need/should/could be available. Writing a kickstart.cfg should be as easy and straightforward as possible. I'll keep breaking my head about it in some spare moments I have.
Niels
On Wed, 2007-11-28 at 15:57 -0500, Jeremy Katz wrote:
Will this mean that when resizing, the resize will be performed immediately after leaving partitioning step? Are there any thoughts about "deferring" the resize to occur after the final "Click OK to proceed" (iow ... prior to when normal disk formatting occurs).
Thanks, James
On Thu, 2007-11-29 at 08:04 -0500, James Laska wrote:
On Wed, 2007-11-28 at 15:57 -0500, Jeremy Katz wrote:
Will this mean that when resizing, the resize will be performed immediately after leaving partitioning step? Are there any thoughts about "deferring" the resize to occur after the final "Click OK to proceed" (iow ... prior to when normal disk formatting occurs).
Given some of the other things that are in the works, we're just going to do what pretty much everyone else did years ago and move the "commit" of partitioning changes to be done immediately after exiting the partitioning stage. There's still a need for a suitable dialog making this clear to the user. This will also make it so that if resizing (or any other part of the partitioning process) fails, we can actually just drop the user back into the partitioning screen and let them try again.
Jeremy
On Thu, Nov 29, 2007 at 09:52:56AM -0500, Jeremy Katz wrote:
Given some of the other things that are in the works, we're just going to do what pretty much everyone else did years ago and move the "commit" of partitioning changes to be done immediately after exiting the partitioning stage. There's still a need for a suitable dialog making this clear to the user. This will also make it so that if resizing (or any other part of the partitioning process) fails, we can actually just drop the user back into the partitioning screen and let them try again.
Ouch. I really like the late-stage point-of-no-return we've got now. What are the other things that are in the works?
Can selecting packages / depsolving be moved to *before* the disk screen?
On Thu, 2007-11-29 at 09:57 -0500, Matthew Miller wrote:
On Thu, Nov 29, 2007 at 09:52:56AM -0500, Jeremy Katz wrote:
Given some of the other things that are in the works, we're just going to do what pretty much everyone else did years ago and move the "commit" of partitioning changes to be done immediately after exiting the partitioning stage. There's still a need for a suitable dialog making this clear to the user. This will also make it so that if resizing (or any other part of the partitioning process) fails, we can actually just drop the user back into the partitioning screen and let them try again.
Ouch. I really like the late-stage point-of-no-return we've got now. What are the other things that are in the works?
Can selecting packages / depsolving be moved to *before* the disk screen?
No, because selecting packages depends on your repo selection. If you want to add CD repos and have booted the installer off of a CD, you will need to swap CDs. That means we're going to have to put the installer image somewhere. By being able to guarantee that the partitions are committed to disk already, we can always have a place to move the installer image to.
Jeremy
On Thu, Nov 29, 2007 at 10:03:33AM -0500, Jeremy Katz wrote:
No, because selecting packages depends on your repo selection. If you want to add CD repos and have booted the installer off of a CD, you will need to swap CDs. That means we're going to have to put the installer image somewhere. By being able to guarantee that the partitions are committed to disk already, we can always have a place to move the installer image to.
Can't it just be put where it's put for network installs? At least if memory isn't critical?
It's bad enough when repository problems break an install midway, but worse if the disk has been already wiped....
On Thu, 2007-11-29 at 10:07 -0500, Matthew Miller wrote:
On Thu, Nov 29, 2007 at 10:03:33AM -0500, Jeremy Katz wrote:
No, because selecting packages depends on your repo selection. If you want to add CD repos and have booted the installer off of a CD, you will need to swap CDs. That means we're going to have to put the installer image somewhere. By being able to guarantee that the partitions are committed to disk already, we can always have a place to move the installer image to.
Can't it just be put where it's put for network installs? At least if memory isn't critical?
The multiple paths of when we commit partitioning changes to disk is already a pretty regular source of problems. And resizing is just going to add more ways for things to not go as expected
It's bad enough when repository problems break an install midway, but worse if the disk has been already wiped....
What if we instead actually, you know, recovered sanely from repository problems. Seems like the better solution ;-)
Jeremy
On Thu, Nov 29, 2007 at 10:27:46AM -0500, Jeremy Katz wrote:
What if we instead actually, you know, recovered sanely from repository problems. Seems like the better solution ;-)
Oh, sure, in theory. :) Delaying disk writes until the last possible moment is nice security against the inevitable unexpected bugs, though.
Matthew Miller (mattdm@mattdm.org) said:
On Thu, Nov 29, 2007 at 10:27:46AM -0500, Jeremy Katz wrote:
What if we instead actually, you know, recovered sanely from repository problems. Seems like the better solution ;-)
Oh, sure, in theory. :) Delaying disk writes until the last possible moment is nice security against the inevitable unexpected bugs, though.
Another thing is that it allows testing of more of the installer without the use of --test (or in the case that --test has bugs...)
Bill
anaconda-devel@lists.stg.fedoraproject.org