FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora User

 
 
LinkBack Thread Tools
 
Old 07-12-2012, 06:48 PM
Máirín Duffy
 
Default UI status braindump, part I

Hi!

CC'ed are Ryan Lerch (new Fedora UX designer who just relocated to
Westford from Brisbane) and Mackenzie Colwell (whom you've likely
already met as pseudomonas in IRC, she's my UX summer intern.)

We met with Chris this morning (and will meet further later this
afternoon) to hash out the current status of the UI design. Here's a
rundown of what we covered this morning; I'll follow up with a part II
for what we cover this afternoon.

#1) KICKSTART DETECTION
========================

So we've had this idea that if you have a USB key with a .ks file on it
when the Anaconda UI is started, we would auto-detect it and offer to
pre-fill in all the UI fields (and add post scripts and whatever else
into the fray) for the install.

Mackenzie worked up some mockups (yet to be posted) showing how this
might look and feel. Some notes:

- If we make this feature infinitely flexible now, it's going to be very
hard to whittle it down later because people may come to rely on
different aspects of it. So we discussed limiting the scope of the
feature initially and expanding eventually based on user feedback.

- We talked about only auto-detecting ks files that are:
- in the root directory of a USB key
- in the root directory of the install media

- We made the assumption that a user is highly unlikely to have more
than 0-10 ks files auto-detected, and the UI mockups are designed
accordingly.

- We talked about a feature (that could be delayed release-by-release
depending on time / resources available to implement) to allow users to
pull in only certain named sections of a KS file. So, we auto-detect the
KS file and that it has a %packages and a %post. You could dive in an
select to only pull in the %packages section with checkbox, and uncheck
the %post to not have it apply to your install at all.

- If the stanza-by-stanza pick and choose for KS feature isn't
implemented, we default to all or nothing when we auto-detect ks files:
you either have all parts of the KS applied to your install or none.

- For picking and choosing sections of a ks file, we determined that we
should have all sections included by default, and allow the user to
'opt-out' of particular sections. (rather than vice-versa where they
would start with none and have to opt-in one-by-one.)

- We talked about how opting in to the %package section of the ks file
might be a good part of the story for folks concerned that we have
dropped individual package selection from the UI.

- A kickstart file with just one section will pass validation. Old style
kickstarts default to asking for any information not provided in the KS.
In the new anaconda UI, we will pre-fill in the defaults for any fields
the KS did not provide, and if any section is not provided we will put
the user on the 1st hub rather than the 2nd hub. (Not sure if we should
push users to the 2nd hub if every required KS option is filled out in
the KS file sucked in.)

- For picking and choosing KS files, we need a way to view each section
so you know what you're signing up for (or know what you're avoiding by
unchecking it.)

#2) CHOOSE DISKS BEFORE HUB #1
==============================

http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png

I know we came up with the "Choose Disks" flow in there to limit the
number of disks selectable later on in the UI to 10 or less because of a
discussion we had in Westford some months back. I don't remember all the
particulars (eek) so I wonder if we still need it? If so we need to mock
it up.

#3) LOCAL MEDIA PREUPGRADE
==========================

We want to choose preupgrade as the one true / supported upgrade path.
However! This is problematic for folks with crappy, expensive, or no
internet connections. Can we investigate whether it would be possible to
offer up a 'preupgrade from DVD media' option? What if the DVD media was
live, possible?

#4) KEYBOARD LAYOUT IN LANG SELECTION SCREEN #1
===============================================

So, it's been pointed out that while we allow users to select the
language the Anaconda UI is displayed in on the very first screen, we
don't allow them to select a keyboard layout. This is problematic
because we have a network dialog after that, and if they cannot type
their AP password or input their network information using the default
layout for their chosen language, they can't benefit from any of the
geo-ip and network features (like pre-downloading repo metadata) the new
UI offers.

Ryan has been looking at integrating keyboard layout selection into this
screen. As we discussed this a number of issues came up:

- We likely won't have geo-ip data for this first screen so it would be
really difficult to filter based on geo relevancy, but we can do this on
the language screen off of hub #1.

- A user may select one language for the display and another language
for input. An example of this is an American consultant stationed
on-site at a Japanese business, where the AP password is in Japanese but
the American (speaking English natively) would prefer to read the
Anaconda UI in English.)

- Because of the above point, we should display layouts relevant to the
selected language first on screen #1, but also allow the option to add
any other layout outside of that language. (with type-ahead)

- Will ibus work in Anaconda? If not, CJKVI (Chinese, Japanese, Korean,
Vietnamese, Indic, maybe others'?) languages' input won't be possible in
Anaconda. (We have had a specific user requests to support Japanese
input in anaconda so it is needed / useful.)

- For ibus languages, we need to indicate what the key combo is to
select between 'sublayouts' (eg. for Japanese, switching between
Romaji / Hiragana / Katakana.)

#5 UP-FRONT NETWORK AUTO-DETECTION
==================================

We had a worrisome and complicated discussion of how to handle
auto-detected / auto-connected network support (before hub #1) until
Ryan essentially pointed out that NetworkManager has a workable recipe
for auto-connecting to a network and we should probably just use
whatever scheme NM uses

Diagram:
http://www.flickr.com/photos/mairin/7557284668/in/photostream

- If you have a wired connection (that can access the internet not just
a local network), you don't see any network config screen before hitting
hub #1.
- If you have a wireless connection, we pop up a 'simple dialog' (to be
mocked up by Ryan) where you pick an access point and input the password
(if necessary)
- If you have a more complicated connection, you can visit the full
blown network dialog (before hub #1) by clicking on a 'Network Settings'
button in the 'simple dialog'

Some use cases we talked through:
- You're at a friends house. They have a MAC filter or password.
- You're at the office. All the visible APs are password-protected
(maybe using RSA tokens or certs)
- You're at a hotel / airport / conference show floor and the network
has a captive auth system. You are only connected to a local network
then, and not connected to the full internet.
- Fake 'Free Public Wifi' connection that has no internet uplink.
- You need to connect to a phone's network connection via wired (USB) or
wireless tether.
- You're at a coffeeshop and the AP is completely open, but you'd rather
connect to another AP. If you switch APs, the yum repo metadata download
will have to be restarted.

Other points -

- We could detect whether or not APs were connected to the wider
internet or not.

TO-DOs for people

Mackenzie
=========
- update the ks auto-detect mockups to allow users to view each stanza
of the ks on the same screen where they can check / uncheck
stanza-by-stanza

- update the ks auto-detect mockups to drop the 'choose sections'
button. instead of having a separate 'choose sections' screen, integrate
the choose sections widgets into the main dialog using a disclosure
widget (example:
http://xkahn.zoned.net/blog/wp-content/uploads/2007/02/evolution-compose-text.png the 'Show Attachment Bar' in the bottom left of this SS uses a disclosure widget - also called GtkExpander - but in GTK3 they look like little [+] symbols instead of a triangle.)

Ryan
====
- (deferred until complete set available) talk to Brisbane docs contents
about an audit of the language used in the UI strings to make sure it's
internally consistent and consistent with RH style
- Update screen #1 mockups to include keyboard layout selection
- On keyboard layout screen, for CJKVI languages, provide the key combo
for switching between 'sub layouts' (katakana vs hiragana vs romaji in
Japanese for example)
- Talk to Brisbane contacts about state of ibus and whether or not any
alternative input systems are under consideration or if any pending new
ibus features are coming up so we're aware
- Mock up 'simple dialog' for network connections

Mo
==
- I need to talk to dlehman about the 'choose disks' box we have in the
flow chart and whether or not it's still necessary (eg
http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png )


Chris & other Anaconda riders
=============================
- Search the install media and any USB media attached to the system for
ks files, only in the root directory.
- Modify kickstart.py as necessary so that it can determine whether or
not a given file passed to it actually is a ks file.
- If a ks file is loaded in by a user, always take them to hub #1 by
default, even if you have sufficient info to start the install.
- (low priority) Investigate what it would take to list what ks
stanzas / sections are present in a ks file and optionally,
section-by-section, turn them on or off.
- (dependent on last item above) When pulling in a user-selected ks
file, set all ks sections to ON by default.
- Investigate preupgrade off of local media feasibility
- Investigate ibus in anaconda feasibility
- Change code around popping up network dialog before hub #1 to match
rules described in section #5 above.



Okay more later hopefully Any questions etc please reply to list!

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-13-2012, 12:35 PM
Vratislav Podzimek
 
Default UI status braindump, part I

See inlined comments below, please.

On Thu, 2012-07-12 at 14:48 -0400, Máirín Duffy wrote:
> Hi!
>
> CC'ed are Ryan Lerch (new Fedora UX designer who just relocated to
> Westford from Brisbane) and Mackenzie Colwell (whom you've likely
> already met as pseudomonas in IRC, she's my UX summer intern.)
>
> We met with Chris this morning (and will meet further later this
> afternoon) to hash out the current status of the UI design. Here's a
> rundown of what we covered this morning; I'll follow up with a part II
> for what we cover this afternoon.
>
> #1) KICKSTART DETECTION
> ========================
>
> So we've had this idea that if you have a USB key with a .ks file on it
> when the Anaconda UI is started, we would auto-detect it and offer to
> pre-fill in all the UI fields (and add post scripts and whatever else
> into the fray) for the install.
>
> Mackenzie worked up some mockups (yet to be posted) showing how this
> might look and feel. Some notes:
>
> - If we make this feature infinitely flexible now, it's going to be very
> hard to whittle it down later because people may come to rely on
> different aspects of it. So we discussed limiting the scope of the
> feature initially and expanding eventually based on user feedback.
>
> - We talked about only auto-detecting ks files that are:
> - in the root directory of a USB key
> - in the root directory of the install media
>
> - We made the assumption that a user is highly unlikely to have more
> than 0-10 ks files auto-detected, and the UI mockups are designed
> accordingly.
>
> - We talked about a feature (that could be delayed release-by-release
> depending on time / resources available to implement) to allow users to
> pull in only certain named sections of a KS file. So, we auto-detect the
> KS file and that it has a %packages and a %post. You could dive in an
> select to only pull in the %packages section with checkbox, and uncheck
> the %post to not have it apply to your install at all.
>
> - If the stanza-by-stanza pick and choose for KS feature isn't
> implemented, we default to all or nothing when we auto-detect ks files:
> you either have all parts of the KS applied to your install or none.
>
> - For picking and choosing sections of a ks file, we determined that we
> should have all sections included by default, and allow the user to
> 'opt-out' of particular sections. (rather than vice-versa where they
> would start with none and have to opt-in one-by-one.)
>
> - We talked about how opting in to the %package section of the ks file
> might be a good part of the story for folks concerned that we have
> dropped individual package selection from the UI.
>
> - A kickstart file with just one section will pass validation. Old style
> kickstarts default to asking for any information not provided in the KS.
> In the new anaconda UI, we will pre-fill in the defaults for any fields
> the KS did not provide, and if any section is not provided we will put
> the user on the 1st hub rather than the 2nd hub. (Not sure if we should
> push users to the 2nd hub if every required KS option is filled out in
> the KS file sucked in.)
>
> - For picking and choosing KS files, we need a way to view each section
> so you know what you're signing up for (or know what you're avoiding by
> unchecking it.)
>
> #2) CHOOSE DISKS BEFORE HUB #1
> ==============================
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png
>
> I know we came up with the "Choose Disks" flow in there to limit the
> number of disks selectable later on in the UI to 10 or less because of a
> discussion we had in Westford some months back. I don't remember all the
> particulars (eek) so I wonder if we still need it? If so we need to mock
> it up.
>
> #3) LOCAL MEDIA PREUPGRADE
> ==========================
>
> We want to choose preupgrade as the one true / supported upgrade path.
> However! This is problematic for folks with crappy, expensive, or no
> internet connections. Can we investigate whether it would be possible to
> offer up a 'preupgrade from DVD media' option? What if the DVD media was
> live, possible?
>
> #4) KEYBOARD LAYOUT IN LANG SELECTION SCREEN #1
> ===============================================
>
> So, it's been pointed out that while we allow users to select the
> language the Anaconda UI is displayed in on the very first screen, we
> don't allow them to select a keyboard layout. This is problematic
> because we have a network dialog after that, and if they cannot type
> their AP password or input their network information using the default
> layout for their chosen language, they can't benefit from any of the
> geo-ip and network features (like pre-downloading repo metadata) the new
> UI offers.
Mentioning the geo-ip, I would like to remind everybody that we still
have no server to query for the geo-ip data. At least I don't know about
any.

>
> Ryan has been looking at integrating keyboard layout selection into this
> screen. As we discussed this a number of issues came up:
>
> - We likely won't have geo-ip data for this first screen so it would be
> really difficult to filter based on geo relevancy, but we can do this on
> the language screen off of hub #1.
>
> - A user may select one language for the display and another language
> for input. An example of this is an American consultant stationed
> on-site at a Japanese business, where the AP password is in Japanese but
> the American (speaking English natively) would prefer to read the
> Anaconda UI in English.)
>
> - Because of the above point, we should display layouts relevant to the
> selected language first on screen #1, but also allow the option to add
> any other layout outside of that language. (with type-ahead)
>
> - Will ibus work in Anaconda? If not, CJKVI (Chinese, Japanese, Korean,
> Vietnamese, Indic, maybe others'?) languages' input won't be possible in
> Anaconda. (We have had a specific user requests to support Japanese
> input in anaconda so it is needed / useful.)
>
> - For ibus languages, we need to indicate what the key combo is to
> select between 'sublayouts' (eg. for Japanese, switching between
> Romaji / Hiragana / Katakana.)
>
> #5 UP-FRONT NETWORK AUTO-DETECTION
> ==================================
>
> We had a worrisome and complicated discussion of how to handle
> auto-detected / auto-connected network support (before hub #1) until
> Ryan essentially pointed out that NetworkManager has a workable recipe
> for auto-connecting to a network and we should probably just use
> whatever scheme NM uses
>
> Diagram:
> http://www.flickr.com/photos/mairin/7557284668/in/photostream
>
> - If you have a wired connection (that can access the internet not just
> a local network), you don't see any network config screen before hitting
> hub #1.
> - If you have a wireless connection, we pop up a 'simple dialog' (to be
> mocked up by Ryan) where you pick an access point and input the password
> (if necessary)
Layouts won't be configured at this point. Obviously this is a "chicken
egg dilemma".

> - If you have a more complicated connection, you can visit the full
> blown network dialog (before hub #1) by clicking on a 'Network Settings'
> button in the 'simple dialog'
>
> Some use cases we talked through:
> - You're at a friends house. They have a MAC filter or password.
> - You're at the office. All the visible APs are password-protected
> (maybe using RSA tokens or certs)
> - You're at a hotel / airport / conference show floor and the network
> has a captive auth system. You are only connected to a local network
> then, and not connected to the full internet.
> - Fake 'Free Public Wifi' connection that has no internet uplink.
> - You need to connect to a phone's network connection via wired (USB) or
> wireless tether.
> - You're at a coffeeshop and the AP is completely open, but you'd rather
> connect to another AP. If you switch APs, the yum repo metadata download
> will have to be restarted.
>
> Other points -
>
> - We could detect whether or not APs were connected to the wider
> internet or not.
>
> TO-DOs for people
>
> Mackenzie
> =========
> - update the ks auto-detect mockups to allow users to view each stanza
> of the ks on the same screen where they can check / uncheck
> stanza-by-stanza
>
> - update the ks auto-detect mockups to drop the 'choose sections'
> button. instead of having a separate 'choose sections' screen, integrate
> the choose sections widgets into the main dialog using a disclosure
> widget (example:
> http://xkahn.zoned.net/blog/wp-content/uploads/2007/02/evolution-compose-text.png the 'Show Attachment Bar' in the bottom left of this SS uses a disclosure widget - also called GtkExpander - but in GTK3 they look like little [+] symbols instead of a triangle.)
>
> Ryan
> ====
> - (deferred until complete set available) talk to Brisbane docs contents
> about an audit of the language used in the UI strings to make sure it's
> internally consistent and consistent with RH style
> - Update screen #1 mockups to include keyboard layout selection
> - On keyboard layout screen, for CJKVI languages, provide the key combo
> for switching between 'sub layouts' (katakana vs hiragana vs romaji in
> Japanese for example)
> - Talk to Brisbane contacts about state of ibus and whether or not any
> alternative input systems are under consideration or if any pending new
> ibus features are coming up so we're aware
> - Mock up 'simple dialog' for network connections
>
> Mo
> ==
> - I need to talk to dlehman about the 'choose disks' box we have in the
> flow chart and whether or not it's still necessary (eg
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png )
>
>
> Chris & other Anaconda riders
> =============================
> - Search the install media and any USB media attached to the system for
> ks files, only in the root directory.
> - Modify kickstart.py as necessary so that it can determine whether or
> not a given file passed to it actually is a ks file.
I believe this check should go to pykickstart itself, not to
kickstart.py

> - If a ks file is loaded in by a user, always take them to hub #1 by
> default, even if you have sufficient info to start the install.
> - (low priority) Investigate what it would take to list what ks
> stanzas / sections are present in a ks file and optionally,
> section-by-section, turn them on or off.
> - (dependent on last item above) When pulling in a user-selected ks
> file, set all ks sections to ON by default.
> - Investigate preupgrade off of local media feasibility
> - Investigate ibus in anaconda feasibility
I will look at this part.

> - Change code around popping up network dialog before hub #1 to match
> rules described in section #5 above.
>
>
>
> Okay more later hopefully Any questions etc please reply to list!
How important are these things for the Fedora 18? I believe they are
somewhere at the bottom of the TODO list. Aren't they?

--
Vratislav Podzimek

Anaconda Rider | Red Hat, Inc. | Brno - Czech Republic

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-13-2012, 02:12 PM
Chris Lumens
 
Default UI status braindump, part I

> > So, it's been pointed out that while we allow users to select the
> > language the Anaconda UI is displayed in on the very first screen, we
> > don't allow them to select a keyboard layout. This is problematic
> > because we have a network dialog after that, and if they cannot type
> > their AP password or input their network information using the default
> > layout for their chosen language, they can't benefit from any of the
> > geo-ip and network features (like pre-downloading repo metadata) the new
> > UI offers.
> Mentioning the geo-ip, I would like to remind everybody that we still
> have no server to query for the geo-ip data. At least I don't know about
> any.

I think we can keep looking at this through the F19 timeframe. I'm not
concerned about it being in the initial release of newui.

> > - If you have a wireless connection, we pop up a 'simple dialog' (to be
> > mocked up by Ryan) where you pick an access point and input the password
> > (if necessary)
> Layouts won't be configured at this point. Obviously this is a "chicken
> egg dilemma".

Right, we've got some ideas for how to work in some layout selection to
the language selection screen up front. It would certainly be nice to
use geoip for this, but not required. I think we can make this work.

> > - Modify kickstart.py as necessary so that it can determine whether or
> > not a given file passed to it actually is a ks file.
> I believe this check should go to pykickstart itself, not to
> kickstart.py

Yeah, that's what she meant.

> > Okay more later hopefully Any questions etc please reply to list!
> How important are these things for the Fedora 18? I believe they are
> somewhere at the bottom of the TODO list. Aren't they?

#4 and #5 are likely F18 material, at least #4 and the related input
method stuff.. That one's pretty important. I'll probably end up doing
#1 for F18 just because it looks fun. The others are less important.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-13-2012, 02:44 PM
Máirín Duffy
 
Default UI status braindump, part I

On Fri, 2012-07-13 at 14:35 +0200, Vratislav Podzimek wrote:
> > - Modify kickstart.py as necessary so that it can determine whether or
> > not a given file passed to it actually is a ks file.
> I believe this check should go to pykickstart itself, not to
> kickstart.py

Ugh sorry That's what I meant!

~m

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-16-2012, 02:03 PM
Chris Lumens
 
Default UI status braindump, part I

> #2) CHOOSE DISKS BEFORE HUB #1
> ==============================
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png
>
> I know we came up with the "Choose Disks" flow in there to limit the
> number of disks selectable later on in the UI to 10 or less because of a
> discussion we had in Westford some months back. I don't remember all the
> particulars (eek) so I wonder if we still need it? If so we need to mock
> it up.

I don't remember why this is there, but not it comes immediately before
upgrade. Therefore, I think it might be upgrade related. Since we're
not doing anything with upgrades in anaconda anymore, this wouldn't be
needed.

> Chris & other Anaconda riders
> =============================
> - Search the install media and any USB media attached to the system for
> ks files, only in the root directory.

This is hard, because we won't be able to determine what's USB media
until storage probing is done. That could be at any time - the user
could be on some spoke. Do we just pop up a dialog as soon as we've
found things? That could look pretty awkward.

I wonder if we should tell the user to provide some command line
parameter next time they start up anaconda, and we could key on the
presence of that parameter to put the user at some point they can't go
past while we probe.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-16-2012, 02:20 PM
David Lehman
 
Default UI status braindump, part I

On Thu, 2012-07-12 at 14:48 -0400, Máirín Duffy wrote:
> #2) CHOOSE DISKS BEFORE HUB #1
> ==============================
>
> http://linuxgrrl.com/fedora-ux/Projects/Anaconda/Flows/full-flow_26sep2011.png
>
> I know we came up with the "Choose Disks" flow in there to limit the
> number of disks selectable later on in the UI to 10 or less because of a
> discussion we had in Westford some months back. I don't remember all the
> particulars (eek) so I wonder if we still need it? If so we need to mock
> it up.

We still need this. Disk filtering is now part of the main storage
flow/loop (ie: the storage spoke), as opposed to out in front like it
was before. There's so much information [1] we need from the storage
subsystem to display the storage spoke that we need a full devicetree to
drive the spoke. This means that we populate the devicetree before
device filtering happens. If the user has enough disks it could be quite
slow getting the storage spoke ready initially, so we decided that at
some arbitrary cutoff point we would force disk selection before
populating the devicetree.

Dave

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-16-2012, 03:41 PM
Adrian Cruceru
 
Default UI status braindump, part I

On 07/16/2012 05:03 PM, Chris Lumens wrote:

Chris& other Anaconda riders
> =============================
> - Search the install media and any USB media attached to the system for
> ks files, only in the root directory.

Why not document how to put KS file inside both:
- isolinux/initrd.img
- images/pxeboot/initrd.img

User can set "/ks.cfg" as kickstart path.

With USB boot, main problems would be:
- Auto-detecting install media hard disk for the "harddrive" command
- Making sure bootloader is not set on USB stick.

can provide patches to items above if anyone thinks they're useful

Thanks,
Adrian Cruceru

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-16-2012, 07:30 PM
Chris Lumens
 
Default UI status braindump, part I

> We still need this. Disk filtering is now part of the main storage
> flow/loop (ie: the storage spoke), as opposed to out in front like it
> was before. There's so much information [1] we need from the storage
> subsystem to display the storage spoke that we need a full devicetree to
> drive the spoke. This means that we populate the devicetree before
> device filtering happens. If the user has enough disks it could be quite
> slow getting the storage spoke ready initially, so we decided that at
> some arbitrary cutoff point we would force disk selection before
> populating the devicetree.

Argh, okay.

Well, I guess we'll need a mockup for this as well. It will probably be
easy to write but might need to get pushed off to post-F18. I think
we've got plenty to work on already.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-16-2012, 07:56 PM
Chris Lumens
 
Default UI status braindump, part I

> >> - Search the install media and any USB media attached to the system for
> >> ks files, only in the root directory.
> Why not document how to put KS file inside both:
> - isolinux/initrd.img
> - images/pxeboot/initrd.img
>
> User can set "/ks.cfg" as kickstart path.
>
> With USB boot, main problems would be:
> - Auto-detecting install media hard disk for the "harddrive" command
> - Making sure bootloader is not set on USB stick.

What we're talking about doing here is something new and very specific,
though. We're investigating using kickstart as a way of saving an
in-progress interactive install and then automatically detecting this
saved kickstart file upon subsequent runs of anaconda.

So we don't really want the user to have to rebuild initrds or anything
in order to do this.

- Chris

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 

Thread Tools




All times are GMT. The time now is 09:48 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org