Anaconda-devel November 2010

anaconda-devel@lists.fedoraproject.org

27 participants
57 discussions

Firstboot Create User screen
by Martin Gracik 23 Nov '10

23 Nov '10

Hi, I would like to make little changes to the Create User screen in firstboot. You can see the new screen here http://mgracik.fedorapeople.org/create_user.png The "Strong password" label changes while the user is typing the password. If it passes cracklib fascist check, it is Strong, otherwise it is Weak. I actually have a custom password strength library ready, which has 7 levels of password strength, and I would like to use it to have nicer password checking, but I have to add it to firstboot first, or somewhere else... The check icon after the second password entry shows up if the entered passwords are the same, otherwise it is not there. I removed the Confirm Password label, because I think it's obvious that the second entry is to confirm the password. But maybe it's not so obvious for everybody, so I can return it back. Please tell me what you think. Thanks. -- Martin Gracik

2 2

[PATCH master] Networking UI - integration of NM Applet
by Radek Vykydal 22 Nov '10

22 Nov '10

Hi list, this is another take on network enablement/configuration UI in anaconda. It follows first take: https://www.redhat.com/archives/anaconda-devel-list/2010-October/msg00201.h… the point of which was to offer functionality that NetworkManager Applet does in desktop environment - overview of available devices, its status, available APs for wireless, activate/disconnect device controls. It turned out to be quite a lot of UI, so in this patchset I tried to integrate NetworkManager Applet itself. The applet requires a panel (freedesktop.org systray to be precise) to run. I used lightweight fbpanel (gnome-panel would pull a lot of stuff in). Here are examples of what I was able to achieve with the patches: Network enablement for network repository: http://rvykydal.fedorapeople.org/repo-network-enablement.ogg Network enablement for iSCSI device: http://rvykydal.fedorapeople.org/iscsi-network-enablement.ogg Notes and things to consider: - The hostname screen (http://rvykydal.fedorapeople.org/hostname-screen.png) could be updated with information/suggestion about network configuration and its particularities (e.g. it is common for installer environment and target system, suggestions about post-boot automatic device bringup, etc.). The (hard-to-notice) Configure Network button is removed. - The panel could be used for other stuff too. (Just out of interest, I put there cpu and network monitoring plugins to watch, unfortunately memory usage plugin didn't work for me) - In this version the applet is accessible from the beginning - before storage configuration, so the FCoE devices aren't filtered-out (by setting NM_CONTROLLED=no by anaconda) for the applet. - fbpanel is not a part of rhel 6. - The growth of packed initrd img is less than 450 KB (including docs, man pages, and some other stuff that would be removed by buildinstall/ lorax) - Layout of the panel is to be UI-experted. Also panel start-up is not smoothest in this version: http://rvykydal.fedorapeople.org/panel-startup.ogg - Nice amount of code is removed from anaconda, and special handling of ONBOOT ifcfg setting which used to be needed to activate/deactivate devices, and caused quite a lot of problems due to this overoload, is gone. Radek

5 12

[PATCH 1/2] Improve CheckList class.
by Tomas Mlcoch 18 Nov '10

18 Nov '10

Add Select All/None functionality to header. Add support for titles in header. --- pyanaconda/iw/checklist.py | 27 +++++++++++++++++++++------ pyanaconda/iw/lvm_dialog_gui.py | 3 ++- pyanaconda/iw/partition_ui_helpers_gui.py | 4 +++- pyanaconda/iw/raid_dialog_gui.py | 3 ++- 4 files changed, 28 insertions(+), 9 deletions(-) diff --git a/pyanaconda/iw/checklist.py b/pyanaconda/iw/checklist.py index 50026a1..304978a 100644 --- a/pyanaconda/iw/checklist.py +++ b/pyanaconda/iw/checklist.py @@ -31,15 +31,16 @@ class CheckList (gtk.TreeView): # override this to make your own columns if necessary def create_columns(self, columns): # add the string columns to the tree view widget - for i in range(1, columns + 1): + titles = [''] + columns + for i in range(1, len(titles)): renderer = gtk.CellRendererText() - column = gtk.TreeViewColumn('Text', renderer, text=i, + column = gtk.TreeViewColumn(titles[i], renderer, text=i, **self.sensitivity_args) column.set_clickable(False) self.append_column(column) # XXX need to handle the multicolumn case better still.... - def __init__ (self, columns = 1, custom_store=None, sensitivity=False): + def __init__ (self, columns = [''], custom_store=None, sensitivity=False): if custom_store is None: self.store = gtk.TreeStore(gobject.TYPE_BOOLEAN, gobject.TYPE_STRING, @@ -50,10 +51,10 @@ class CheckList (gtk.TreeView): gtk.TreeView.__init__ (self, self.store) # XXX we only handle two text columns right now - if custom_store is None and columns > 2: + if custom_store is None and len(columns) > 2: raise RuntimeError, "CheckList supports a maximum of 2 columns" - self.columns = columns + self.columns = len(columns) # sensitivity_col is an optional hidden boolean column that controls # the sensitive property of all of the CellRenderers in its row. @@ -76,6 +77,11 @@ class CheckList (gtk.TreeView): # column.set_fixed_width(40) column.set_clickable(True) self.checkboxrenderer.connect ("toggled", self.toggled_item) + column.connect("clicked", self.select_deselect) + column.set_alignment(0.75) + self.allButton = gtk.ToggleButton() + column.set_widget(self.allButton) + self.allButton.show_all() self.append_column(column) self.create_columns(columns) @@ -88,6 +94,7 @@ class CheckList (gtk.TreeView): # keep track of the number of rows we have so we can # iterate over them all self.num_rows = 0 + self.select_all = True self.tiptext = {} self.props.has_tooltip = True @@ -203,9 +210,17 @@ class CheckList (gtk.TreeView): if col: col.set_sort_column_id(id) + def select_deselect (self, widget, data=None): + """Select/Deselect all checkboxes""" + + self.select_all = not self.select_all + for i in xrange(self.num_rows): + self.set_active(i, self.select_all) + + def main(): win = gtk.Window() - cl = CheckList(1) + cl = CheckList(['Column']) for i in range(1, 10): cl.append_row("%s" %(i,), False, "foo: %d" %(i,)) diff --git a/pyanaconda/iw/lvm_dialog_gui.py b/pyanaconda/iw/lvm_dialog_gui.py index cef3be8..c669f6e 100644 --- a/pyanaconda/iw/lvm_dialog_gui.py +++ b/pyanaconda/iw/lvm_dialog_gui.py @@ -315,7 +315,8 @@ class VolumeGroupEditor: store = gtk.TreeStore(gobject.TYPE_BOOLEAN, gobject.TYPE_STRING, gobject.TYPE_STRING) - partlist = WideCheckList(2, store, self.clickCB) + columns = ['Drive', 'Capacity'] + partlist = WideCheckList(columns, store, self.clickCB) sw = gtk.ScrolledWindow() sw.add(partlist) diff --git a/pyanaconda/iw/partition_ui_helpers_gui.py b/pyanaconda/iw/partition_ui_helpers_gui.py index 08ba44b..ccba7e9 100644 --- a/pyanaconda/iw/partition_ui_helpers_gui.py +++ b/pyanaconda/iw/partition_ui_helpers_gui.py @@ -55,6 +55,7 @@ class WideCheckList(checklist.CheckList): sensitivity=sensitivity) # make checkbox column wider + columns = len(columns) column = self.get_column(columns) self.set_expander_column(column) column = self.get_column(0) @@ -171,7 +172,8 @@ def createAllowedDrivesList(disks, reqdrives, selectDrives=True, disallowDrives= gobject.TYPE_STRING, gobject.TYPE_STRING, gobject.TYPE_BOOLEAN) - drivelist = WideCheckList(3, store, sensitivity=True) + columns = ['Drive', 'Capacity', 'Model'] + drivelist = WideCheckList(columns, store, sensitivity=True) createAllowedDrivesStore(disks, reqdrives, drivelist, selectDrives=selectDrives, disallowDrives=disallowDrives) diff --git a/pyanaconda/iw/raid_dialog_gui.py b/pyanaconda/iw/raid_dialog_gui.py index 770344c..3256689 100644 --- a/pyanaconda/iw/raid_dialog_gui.py +++ b/pyanaconda/iw/raid_dialog_gui.py @@ -46,7 +46,8 @@ class RaidEditor: store = gtk.TreeStore(gobject.TYPE_BOOLEAN, gobject.TYPE_STRING, gobject.TYPE_STRING) - partlist = WideCheckList(2, store, + columns = ['Drive', 'Capacity'] + partlist = WideCheckList(columns, store, clickCB=self.raidlist_toggle_callback) sw = gtk.ScrolledWindow() -- 1.7.2.3

3 3

Anaconda looking for "disc1" folder when creating install tree from Centos 5.5 DVD
by Matthew Macdonald-Wallace 17 Nov '10

17 Nov '10

Hi, I'm trying to get Anaconda up and running via PXELinux. The issue that I'm running in to is that Anaconda appears to be looking for a folder ("disc1") that is not in my installation tree and trying to download two files (product.img and updates.img) which are not located anywhere on my filesystem. To create the installation tree, I downloaded the Centos 5.5 DVD, mounted it using "-o loop" and copied the content into the relevant directory. I assume that the rest of the install tree is correct as Anaconda is able to start and to download minstg2.img from the tree. The entries in the Anaconda log match those in the webserver log - it'[s a simple 404. Any help or pointers would be greatly welcomed, Kind regards, Matt

2 2

[PATCH 1/4] Do not allow use of preexisting root filesystem. (#629311)
by David Lehman 16 Nov '10

16 Nov '10

--- pyanaconda/iw/lvm_dialog_gui.py | 12 +++++++++--- pyanaconda/iw/partition_dialog_gui.py | 8 +++++++- pyanaconda/iw/raid_dialog_gui.py | 8 +++++++- pyanaconda/storage/__init__.py | 11 +++++++++++ 4 files changed, 34 insertions(+), 5 deletions(-) diff --git a/pyanaconda/iw/lvm_dialog_gui.py b/pyanaconda/iw/lvm_dialog_gui.py index cef3be8..8be27dc 100644 --- a/pyanaconda/iw/lvm_dialog_gui.py +++ b/pyanaconda/iw/lvm_dialog_gui.py @@ -781,9 +781,15 @@ class VolumeGroupEditor: if format.exists and format.mountable and format.mountpoint: tempdev = StorageDevice('tmp', format=format) - if self.storage.formatByDefault(tempdev) and \ - not queryNoFormatPreExisting(self.intf): - continue + if self.storage.formatByDefault(tempdev): + reason = self.storage.mustFormat(tempdev) + if reason: + self.intf.messageWindow(_("Error"), + reason, + custom_icon="error") + continue + elif not queryNoFormatPreExisting(self.intf): + continue # everything ok break diff --git a/pyanaconda/iw/partition_dialog_gui.py b/pyanaconda/iw/partition_dialog_gui.py index 3e4af2b..c8a72c5 100644 --- a/pyanaconda/iw/partition_dialog_gui.py +++ b/pyanaconda/iw/partition_dialog_gui.py @@ -374,7 +374,13 @@ class PartitionEditor: if request.format.exists and \ getattr(request, "mountpoint", None) and \ self.storage.formatByDefault(request): - if not queryNoFormatPreExisting(self.intf): + reason = self.storage.mustFormat(request) + if reason: + self.intf.messageWindow(_("Error"), + reason, + custom_icon="error") + continue + elif not queryNoFormatPreExisting(self.intf): continue # everything ok, fall out of loop diff --git a/pyanaconda/iw/raid_dialog_gui.py b/pyanaconda/iw/raid_dialog_gui.py index 770344c..4ed2e86 100644 --- a/pyanaconda/iw/raid_dialog_gui.py +++ b/pyanaconda/iw/raid_dialog_gui.py @@ -344,7 +344,13 @@ class RaidEditor: if self.origrequest.format.exists and not format and \ self.storage.formatByDefault(self.origrequest): - if not queryNoFormatPreExisting(self.intf): + reason = self.storage.mustFormat(self.origrequest) + if reason: + self.intf.messageWindow(_("Error"), + reason, + custom_icon="error") + continue + elif not queryNoFormatPreExisting(self.intf): continue if format: diff --git a/pyanaconda/storage/__init__.py b/pyanaconda/storage/__init__.py index b8b1c90..2185902 100644 --- a/pyanaconda/storage/__init__.py +++ b/pyanaconda/storage/__init__.py @@ -843,6 +843,17 @@ class Storage(object): # be safe for anything else and default to off return False + def mustFormat(self, device): + """ Return a string explaining why the device must be reformatted. + + Return None if the device need not be reformatted. + """ + mountpoints = ['/'] + if device.format.mountable and device.format.mountpoint == "/": + return _("You must create a new filesystem on the root device.") + + return None + def extendedPartitionsSupported(self): """ Return whether any disks support extended partitions.""" for disk in self.partitioned: -- 1.7.3.2

2 11

[firstboot rhel5] Check if we are on an arch which supports GUI
by Martin Gracik 16 Nov '10

16 Nov '10

We need to check for noX before checking if the environment has a DISPLAY. This fixes the case, when the user runs firstboot manually from GUI on architectures where only firstboot-tui is supported. --- src/firstboot | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/src/firstboot b/src/firstboot index d16c086..ac3bf03 100755 --- a/src/firstboot +++ b/src/firstboot @@ -96,7 +96,7 @@ if __name__ == "__main__": # reconfig mode from a terminal under an already running X setup. # Otherwise, run in text mode if in runlevel 3, or take over rhgb's X # server if running, or start up our own if not. - if os.environ.has_key("DISPLAY") or fb.doDebug: + if (not noX and os.environ.has_key("DISPLAY")) or fb.doDebug: from firstbootWindow import firstbootWindow firstbootWindow(fb) elif (getRunlevel() == 3 and not fb.forcegui) or noX == True: -- 1.7.1.1

1 0

Re: User Experience improvements for Anaconda
by Martin Gracik 16 Nov '10

16 Nov '10

Hi, I'd like to share some of my ideas of this redesign. They are mostly about firstboot, but I think that's a part of the install process too, and some of them may concern anaconda too. I'm usually in minority with my ideas about how things should work and look, but I'm still trying, so here they are. :) 1) I would like to get rid of the left panel in firstboot showing the steps with the background, and instead show steps count in bottom part of the screen. This steps count can also be in anaconda in the same place, to make both applications look similar. 2) Instead of the background, and the big logo on top of the screen in anaconda, I think it would be better to just have a small decent logo in the bottom left part of the screen. I know marketing people may not agree with me, but when I'm installing fedora, I already downloaded it, so they got me, and I know what I'm installing, so I don't have to have the logo in my face all the time, at the top of the screen, which is the place I look at first. I think more important parts with which I interact should be there instead. Again this can be consistent in anaconda and firstboot too. Next point only applies to firstboot... 3) I would like to disable fullscreen in firstboot. Honestly I think no one will agree with me on this, but it's my opinion. For me, after rebooting the system, if the firstboot is not fullscreen, but instead centered and with window decorations, I can _feel_ that the installation has moved somewhere already, I see that I already have some window manager running, and I can see decorations, and background image, this makes me feel better, than seeing another fullscreen app, which bothers me with more questions. This also has more advantages. First people are getting bigger and bigger screens now, and you can imagine how firstboot looks at 2560x1600 resolution screens. I have to move my mouse over 1m to get from a text entry to the Forward button, if not using keyboard shortcuts. Also most of the screen is just empty and grey. Of course we can't fill it all up with widgets, because that would make it confusing. Another advantage I like about this, is that the window will have the [X] close button on top. In my opinion we should let the user close firstboot, if he wishes to. We can show a confirmation dialog, with something like "if you don't finish these steps, your system may not function properly, are you sure?", so nobody closes it accidentaly, but if someone knows what he's doing, we don't bother him with filling up all the entries. This leads me to a decision, which audience we want to target. Do we want to target mostly users who have bought their first computer, and we want to guide them by hand, and _force_ them to do every step, so they don't get hurt. In this case we should remove some of the advanced settings, and make it nice and simple. Or are we targeting a little more experienced users, and we are confident, that they have at least a little idea of what is going on during the install, and can decide what steps to take, and which to skip. In this case I think the screens may be a little more complicated, with more choices, so it's up to the user to decide which he needs, and which he doesn't. I made a mockup of how I imagine new firstboot, with the create user module visible. You can see it here http://mgracik.fedorapeople.org/firstboot.png It's not perfect, but you can see the main ideas. That's all for now. -- Martin Gracik ----- "Máirín Duffy" <duffy(a)fedoraproject.org> wrote: > Hi, > > In case you don't know me, my name is Máirín Duffy (mizmo in IRC) and > I'm the Fedora design team lead & an interaction designer with Red > Hat. > I worked a bit with Chris and Peter before Fedora 12 came out to try > to > improve Anaconda's UI for more specialized storage devices. > > I'm very interested in improving Anaconda's user interface, and in > general Fedora's installation experience from beginning to end. One > thing we've worked on for the past two releases of Fedora is an > improved > experience for downloading Fedora from the website. You may have > noticed > the redesigned 'Get Fedora' pages with Fedora 13's launch, and the > redesigned Fedora main website released with Fedora 14's launch a > couple > of weeks ago. > > I think the next logical step is to examine the current state of our > installation process, identifying the issues we see today, and > brainstorming ways to improve the experience of installing Fedora. > Here's what we have so far towards this end: > > - A wiki page to store links to discussions, record decisions, store > mockups, and any other data needed: > https://fedoraproject.org/wiki/Anaconda/UX_Redesign > > - There was a long thread on Fedora's devel list about improving the > installer experience. > (http://lists.fedoraproject.org/pipermail/devel/2010-October/144105.html > ) There are some notes distilled from that thread on the UX_Redesign > wiki page right now (although they'll probably need some more cleanup > to be useful.) > > - David put together some notes on the install experience for other > distributions: http://dcantrel.fedorapeople.org/installer-evals/ > > - James documented the supported installation methods tested in > Anaconda: > https://www.redhat.com/archives/anaconda-devel-list/2010-May/msg00305.html > > - This week I created screen-by-screen walkthroughs of the Live Media > install process in F14 > (https://fedoraproject.org/wiki/Anaconda/F14_Live_Media_Install ) and > the DVD install process as well > (https://fedoraproject.org/wiki/Anaconda/F14_DVD_Install ). I also put > together a comparison chart of the two methods - > https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Current_Install_Process… > > - Today we had some conversation in #anaconda and I wrote that up as > well on that last wiki page: > https://fedoraproject.org/wiki/Anaconda/UX_Redesign/Current_Install_Process… > > I really want to help make our installation process an easy and > pleasant > experience - so if you have any feedback on the above or ideas on how > to > get there, let's talk about it. I think even bad or crazy ideas are > good > brain food, and can lead to awesome innovation. I'm definitely > planning > to put together some pretty crazy mockups to feed our brains so be on > the lookout for those. :) > > Thanks, > ~m > > > _______________________________________________ > Anaconda-devel-list mailing list > Anaconda-devel-list(a)redhat.com > https://www.redhat.com/mailman/listinfo/anaconda-devel-list

1 0

[master] Repository setup and UI patches.
by Radek Vykydal 16 Nov '10

16 Nov '10

data/ui/addrepo.glade | 1 + pyanaconda/__init__.py | 3 +- pyanaconda/backend.py | 9 +- pyanaconda/dispatch.py | 5 +- pyanaconda/gui.py | 2 +- pyanaconda/image.py | 45 -- pyanaconda/installclass.py | 5 +- pyanaconda/iutil.py | 13 + pyanaconda/iw/task_gui.py | 624 ++++++++--------------- pyanaconda/kickstart.py | 8 +- pyanaconda/text.py | 2 +- pyanaconda/textw/task_text.py | 1 - pyanaconda/upgrade.py | 1 + pyanaconda/yuminstall.py | 1112 +++++++++++++++++++++++------------------ 14 files changed, 885 insertions(+), 946 deletions(-) This patchset aims to reorganize our repository editing UI flow so that: - we don't need hacks to reset repos/sacks of YumBase object when going back, rather use new YumBase object see [1] - we can handle some errors during configuration more gracefuly see [2], [3] with screencasts - we can offer a NFSISO (this one is in the patches) and HD for base/installation repo in editing UI quite easily more generally speaking: - the code is more comprehensible, maintainable, and less prone to fallouts rooted in using yum internals in ways not expected by yum (yes, hacks) - base/install repository is handled the same way as other where possible The patchset does not: - change UI layout, I think it needs proper design - abstracts repository/packages source completely, but moves things in this direction The trick is to move tasksel step (repo editing + task selection) before reposetup step and introduce new repocollect step preceeding tasksel in which all repo specifications are collected (from method, ks, dd, /etc/anaconda.repos.d) into objects of new class RepoSpec stored in anaconda.repos list. RepoSpec objects can be used in UI (and elsewhere, e.g. in writeconfig) instead of AnacondaYumRepo (child of YumRepository) objects, using of whose made UI and logic interwined to the point of unmaintenablity. It also alows to remove stuff added into our AnacondaYumRepo (keeping only refernce to RepoSpec there). RepoSpec should go to its own module repos.py as it should be backend independent. For now, I keep it in yuminstall.py together with YumRepoSpec which is inherited from RepoSpec. There is one problem I don't address in this series of patches: The tasksel step/screen combines repo editing and task selection which is unfortunate because task selection requires all repositories to be set. The appropriate steps would be: edit repositories (UI) -> setup repositories (nonUI) -> select tasks (UI), but the first and the third are on the same screen in present UI and threfore I have to call non-UI step from the UI screen which I wasn't able to do without hack. Making task selection a separate step or adding it to group/package selection screen (where it belongs from the yum backend point of view, not sure if also from user point of view) would make things cleaner and allow to avoid the UI flow hacking (see (*) in steps 2) and 3) in "Patched flow" below) You can see in [4] how the repositories are setup after each modification in repo list. Another important change is that all the repository setup (network enablement, mounting, repo setup, sack setup, groups setup) is done in a loop over all enabled RepoSpecs which allows for better handling of errors in UI. Some overwhelming details: Present flow: 1) "reposetup" step - create ayum (YumBackend object) - add AnacondaYumRepo objects for required repos (mehtod, ks repo=, dd) and add them to ayum object - mounting of isos (for cdrom, nfsiso, hdiso) - network enablement if needed - repo setup, sack setup, group setup - editing of invalid repos in dialog - no way to disable repo at this point, in case of fail only Edit/Exit is offered 2) UI "tasksel" step - edit repos - working directly YumRepository objects (the ayum.repos is the only store of repos we have), so all setup from step 1) has to be done here too - select tasks (note that changes in repos can make task selection list obsolete in theory) 3) "basepkgsel" step - group/package selection based on installclass and ks - hacky resetting of groups/sack information needed for going back in UI (from 4, from dialog in 5) 4) UI "group-selection" step - you can go back to 2) 5) "postselection" - create transaction - in case of conflicts you can go back to 4) from a dialog 6) "writeconfig" - write anaconda-ks.cfg using ayum.repos (AnacondaYumRepository objects) Patched flow: 1) "repocollect" step - initialze RepoSpec objects storing specs of required repos (from method, ks, DD, /etc/anaconda.repos.d, addon repos for RHEL) 2) UI "repotasksel" step (formerly "tasksel", keeping its UI layout) - edit repos - works on RepoSpec objects - select tasks - after a repo is edited/enabled/disabled, step 3) has to be called so that task list can be updated 3) "reposetup" step - is skipped if we did it as a part of 2) in UI This could be removed if task selection was separated from repo editing (*) - create ayum (YumBackend object) - for each repo RepoSpec: - enable network if needed - mount repo (nfsiso, hd, cdrom) - add corresponding YumRepository object to ayum - set cache for repository - do repository setup - do sack setup - do group setup if any of the above fails, we know what repo was the cause of fail, store failure info in its RepoSpec object, go back to 2), mark failed repo in the list (see [4]) 4) "basepkgsel" step - group selection based on installclass and ks - no reset on the way back is needed as in UI step 2), we start with new ayum object 5) UI "group-selection" - you can go back to 2) 6) "postselection" - create transaction - in case of conflicts you can go back to 5) from a dialog 7) "writeconfig" - write anaconda-ks.cfg using anaconda.repos (RepoSpec objects) [1] https://bugzilla.redhat.com/show_bug.cgi?id=622376#c5 screencasts: - the bug: http://rvykydal.fedorapeople.org/repoUI/example3.ogg - fixed with patches: http://rvykydal.fedorapeople.org/repoUI/example3patched.ogg [2] if failing nfs repo= is used in kickstart - choosing Continue lead to fatal fail: http://rvykydal.fedorapeople.org/repoUI/example1.ogg - choosing Edit and Cancel lead to fatal fail: http://rvykydal.fedorapeople.org/repoUI/example1b.ogg ... also the true cause (nfs mount error) is hidden - with the patch [Edit] means going to repo UI screen where the failing repo can be disabled: http://rvykydal.fedorapeople.org/repoUI/example1patched.ogg [3] network requiring repository set by boot param repo=, no network needed till repository steps - failing to enable network for base repository is fatal: http://rvykydal.fedorapeople.org/repoUI/example3.ogg - with patch, you can fall back to media (non network) repo: http://rvykydal.fedorapeople.org/repoUI/example3patched.ogg [4] http://rvykydal.fedorapeople.org/repoUI/example.ogg

2 12

Single UI install screen for the novice end users.
by "Jóhann B. Guðmundsson" 15 Nov '10

15 Nov '10

A while back I filed 445701 and since you guys are actively looking at what to do with the UI as a whole I'm going to share with you again more or less the same idea that I had back then. It is my experience through out the years that dealing with novice end users installing Fedora is that they do not understand what the installer is asking them about and explaining it to them is just futile attempt because they simple do not care or do not understand and respond to you with aha... So I ask you this why bother to let them jump through all those hoops and ui screens clicking next next nex to accept the default anyway that and why not present them with a single ui screen after the welcome/licence screen instead that collects all the required user input and offers him to simply click install with the rest of the option defaulting to sane defaults ( same as he would have clicked next next next install ). something that has this all presented on the same ui screen ( could be drop down menu ). "select language" "select keyboard layout" if Anaconda had network connection ( which would have been detected by dhcp ) it could potential guess those fields via geoip and ofcourse offer the user to change the "detected" value if no network connection exist it could guess those values based on the field selected. "set root password." You can throw in there the option to "set time date" thou I personally fail to see why this is necessary since the user is asked to provide this information during firstboot. [ Button Upgrade] [ Button Install ] [ Button Advanced users or Custom Configuration ] Clicking upgrade would upgrade you previous installation. Clicking Install would require you to fill in the above and with rest as if user had selected/clicked next next next install.. Clicking Advanced/Custom install users would present experienced users that might have any idea what's being ask for to customize other variables such as the hostname partitioning bootloader order boot loader password so fourth and so on. Máirín is possible for you to sketch an design with the simple single ui design in mind ? JBG

1 0

list-harddrives lists partitions, too
by Ian Ward Comfort 12 Nov '10

12 Nov '10

As of commit 86b2508 (2009-08-03, No longer use HAL in list-harddrives), the list-harddrives stub lists partitions, as well as devices themselves. I'm curious -- what was the rationale for this change? I just stumbled across the new functionality in RHEL6's Anaconda (where it broke my standard kickstart file) and it seems a bit odd, given the command's name. -- Ian Ward Comfort <icomfort(a)stanford.edu> Systems Team Lead, Academic Computing Services, Stanford University

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Anaconda-devel November 2010