Hi,
I'm an end user. I do very frequent installations of Fedora Remixes, Spins and Workstation. Here is what I note.
On the spoke wheel, behind the scenes, there is an update from the repositories in the ISO. Some of the times, if one is on a slower than average mirror, it appears that the system is locked up.
A wait here during software update may take up to five minutes. During during the wait for Software Selection update, I update my hostname, the keyboard layout and timezones. I noted that until the software selection action is completed, I am unable to select and update disk selections. I thought that disk selection and software selection were independent tasks.
Is there a possibility, during the redesign of anaconda, to add a spinner, with an indication that infact, data is being transferred?
For the device selection and partition management, this part needs some rework. We should have the ability, when selecting the option to make additional disk space available, to allow us to delete partitions located on the disks shown in the window. My last recall, it was a "all or nothing" against a chosen disk. My practice now is to use gparted to make a contiguous unallocated partition. Can this kind of facility be improved upon?
I have also thought about other presentations regarding allocations
Here is an idea..
Considered a three columns layout,The first has listed, the partitions such as / home, boot root, opt, swap var etc. A middle column where partitions are presented, and a third column where the disks with those partition areas that I want to use shown linked to entries in the middle column. In the text mode, this three column concept can be included.
The final feedback I have is about the spoke menu is to improve help facility by providing more information. Helpful would be an extra spoke for the release notes.
If I look at the actual installation operation, one frustration I had is with anaconda's use of the ram /tmp. May I present the following idea.
Before /mnt/sysimage is setup with /var, allow anaconda to do the logging to the mentioned /tmp directory. Once the physical disk has a /var, Allow anaconda to immediately create a /var/log/anaconda. Anaconda should stop logging to /tmp and immediately begin writing the log files to /var/log/anaconda. The initial /tmp log files may be copied to the /var/log/anaconda prior to the switch, or at the very end of anaconda execution, as is currently done.
Why that change? Some older versions of anaconda crashed before the installation was completed. I was using a USB flashdrive (dd if=Fedora.iso of=/myflash bs=1M && sync; ). With dd, there is no space left on the USB drive onto which to store the /tmp file data, needed if one is asked to create bugzilla output. Because of my frequent use of anaconada, when problems arise, I copy the /tmp files to /mnt/sysimage/var/log/anaconda. Don't want to make changes, then document this option.
Make the user experience easier, especially when problems arise.
What about the cloud facility. Why can't one of my disks be in the cloud?
Thanks for reading this email.
Regards
Leslie
Leslie
Mr. Leslie Satenstein
Montréal Québec, Canada
From: Brian C. Lane <bcl@xxxxxxxxxx>
To: anaconda-devel-list@xxxxxxxxxx
Sent: Monday, January 4, 2016 12:48 PM
Subject: Re: Anaconda spoke workflow
On Mon, Jan 04, 2016 at 11:32:19AM -0600, Pat Riehecky wrote:
>
>
> On 01/04/2016 11:20 AM, Brian C. Lane wrote:
> >On Wed, Dec 30, 2015 at 12:49:20PM -0600, Pat Riehecky wrote:
> >>I'm focusing a bit on my GUI spoke workflow and ran into an odd snag.
> >>
> >>The spoke is optional (@property mandatory = False and @property completed =
> >>True).
> >>It only makes sense to manipulate the spoke's data after the network has
> >>come online.
> >>If nothing is set on the spoke, this is fine and no actions are performed.
> >>
> >>My initial thoughts were to make @property ready return the value of
> >>pyanaconda.nm.nm_is_connected(). However, if the network is never connected
> >>then spoke is never ready and therefore install can never proceed.
> >>
> >>Are there any suggestions for how I can get what I'm looking for where the
> >>user can't use the spoke without the network but the spoke doesn't block the
> >>install?
> >>
> >>anaconda-19.31.123
> >Is there any state where you want the spoke to block the install, or are
> >you just trying to block entry into the spoke when the network is down?
> >Looking at the current code I'm not sure there is a way to block spoke
> >entry for always ready non-mandatory spokes.
> >
>
> There is no state where I want this spoke to block the install. I'd prefer
> to prevent users from entry into the spoke until the network is up.
>
> For now I'll just set the various properties in the interface read-only when
> the network is down.
That looks like how you'll have to do it. Maybe also set the info bar at
the bottom to tell them why.
--
Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT)
_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
_______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
