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 > EPEL Development

 
 
LinkBack Thread Tools
 
Old 07-12-2012, 10:33 PM
Máirín Duffy
 
Default UI status braindump, part II

As promised, here's part II of the UI status braindump, starting from
where we left off with #6....

6) Show passwords checkbox for password fields
==============================================

Sort of like this screenshot from network manager:
http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/images/netconfig/network-connections-802.1x.png

See the 'show password' checkbox? This would be useful to have on
password fields before hub #1 in case authentication to an access point
fails - it will allow you to make sure the password isn't wrong because
you have the wrong keyboard layout set.

Ryan verified that we already have a 'show key' box on the wep key
dialog in the mockups now. When we're closer to a complete / integrated
set (right now each of us is working on our own copy of the mockups and
haven't merged them yet) he'll do a run-through to make sure all of the
fields that need this feature are noted in the mockups.

7) Fedora Software Selection
============================

For Fedora, we talked about:
- Left column, your option of desktop spins as well as a minimal "no
desktop" option equivalent to @core
- Right column, functional spins package groups (e.g., electronic lab,
security spin, design suite, etc.), normal package groups without
language support groups.
- adding extra repos - still needs to be worked out, we forgot to talk
about this.

8) Partition Shrinking
======================

Eg
http://blog.linuxgrrl.com/2012/04/18/rough-thoughts-on-reclaiming-space-from-partitions-during-installation/

This is waiting on me producing a mockup. I talked to dlehman in IRC
about this last week. I had a conversation with Garrett Lesage (another
open source designer) showing him our mockups so far and he gave the
feedback that we should just have one slider per device. The slider
might have various 'sticky points' where more drastic actions happen the
more you shrink. E.g., say you need 4 gb to do the install. Say you have
a pre-existing windows installation on the device with three partitions:

- partition A: windows_c with 2 GB free on filesystem
- empty space: 2 GB between parts A & B
- partition B: windows_d with 0MB free on filesystem
- partition C: windows_e with 2 GB free on filesystem

You'll have 2 points on the slider maybe:
- slide to point 1 and you'll meet the 4gb requirement. You'll resize
partition A to free the 2 GB, which is adjacent to the 2 GB empty space
between partitions A & B.
- slide to point 2 and you'll free up an additional 2 gb by resizing
partition C down 2 GB. lvm or btr could be used to make it part of the
same logical volume as the chunk of space on the other side of partition
b.

So there's a preference for resizing partitions that have bigger
potential chunks of space to free (so we use partition A first rather
than partition C, because even though they are the same size, partition
A has a bigger potential being adjacent to a large free space than
partition C does.) If you want more space for the filesystem though,
moving the slider further does the more drastic action of using a
logical volume to chain the two physically disparate chunks together
into one for your fedora install.

9) Storage auto-default if Fedora and if only one non-removable disk
detected
================================================== ==================

This is an idea Ryan had when he first reviewed the Anaconda mockups and
got started on the project. Right now, no matter what, you can't click
past the hub #1 - you have to fill out information in the storage hub.
However, a big chunk of Fedora users are setting up single-user Fedora
installations on laptops that have a single hard drive. So, if we
auto-detect that there is only one non-removable hard drive on a system,
we could allow these users to click past the storage screen by
automatically selecting the single laptop drive for install.

This doesn't mean we wipe that single disk. Instead, we autopart any
pre-existing free space on the disk. If that isn't enough space, we
automatically shrinkany filesystems as needed. If that isn't enough, we
dump 'em in hub #1 with the 'attention' ! icon on the storage part and
the user can sort it.

9) Icons for specialized disks
===============================

All the advanced / network storage disks have the same network storage
icon. It might be good to be able to distinguish between raid devices,
sans, dasd/zfcp, etc. So we could find and as necessary develop new
icons and hook them into the different types of storage when they're
displayed.

10) Subscription stuff
======================

This is something that has to be sorted out with the subscriptions team,
as well as the folks working on the F18 Initial Experience
feature. One point that Ryan made was that the GNOME first experience
mockups are very user-centric while firstboot is very system-centric and
not particular to a specific user much.

11) Bug-reporting / Debug opt-in
================================

Jiri Moskovcak brought this up in a recent email thread with me and
Chris - the main ide ahere is that it would be nice to let the user set
various debugging options at install time. So they could opt in to ABRT
and installing debuginfo packages, for example. I need to talk to Jiri
more and get more information about this because I'm still a bit
confused about the details. Some things that came up when Chris, Ryan,
Mackenzie, and I talked about it today:

- opt-in should be someone off hub #1 because it affects whether or not
abrt gets installed and particular debuginfo packages get installed
- what if it was in firstboot, and abrt / debuginfo was installed in a
post-script? or queued up in packagekit?
- could they be queued up in the offline updates system?
- is there any mechanism to autoclean debuginfo packages when they are
stale and useless?
- smolt has a new name... this might change the smolt mockups we have
- for oem usages of firstboot, there is a reconfig option in the old
firstboot, it should carry on to the new one.

12) Random point
================

- How are we handling pre-existing LUKS passwords in the new ui?



I gotta go home so no time to do the to-do list summary, maybe
tomorrow.

~m


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-13-2012, 01:02 PM
Martin Sivak
 
Default UI status braindump, part II

> 7) Fedora Software Selection
> ============================
>
> For Fedora, we talked about:
> - Left column, your option of desktop spins as well as a minimal "no
> desktop" option equivalent to @core

> - Right column, functional spins package groups (e.g., electronic
> lab,
> security spin, design suite, etc.), normal package groups without
> language support groups.

Do we have data source for this? What about offline installs? If spins are changed to be metapackages, we can just filter them by special group (Spin . If not, where do we get the list?

> - adding extra repos - still needs to be worked out, we forgot to
> talk
> about this.

There is a glade for this already. No code though.. The question still is.. are we going to support people's repositories? And where are we going to get the list from if we do?

13) Rescue mode
===============

- any plans?
- I sent a message to the list two weeks ago asking for user cases with my comments about the issues we might encounter



Martin

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

Please see the inlined comments below.

On Thu, 2012-07-12 at 18:33 -0400, Máirín Duffy wrote:
> As promised, here's part II of the UI status braindump, starting from
> where we left off with #6....
>
> 6) Show passwords checkbox for password fields
> ==============================================
>
> Sort of like this screenshot from network manager:
> http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/images/netconfig/network-connections-802.1x.png
>
> See the 'show password' checkbox? This would be useful to have on
> password fields before hub #1 in case authentication to an access point
> fails - it will allow you to make sure the password isn't wrong because
> you have the wrong keyboard layout set.
>
> Ryan verified that we already have a 'show key' box on the wep key
> dialog in the mockups now. When we're closer to a complete / integrated
> set (right now each of us is working on our own copy of the mockups and
> haven't merged them yet) he'll do a run-through to make sure all of the
> fields that need this feature are noted in the mockups.
>
> 7) Fedora Software Selection
> ============================
>
> For Fedora, we talked about:
> - Left column, your option of desktop spins as well as a minimal "no
> desktop" option equivalent to @core
> - Right column, functional spins package groups (e.g., electronic lab,
> security spin, design suite, etc.), normal package groups without
> language support groups.
> - adding extra repos - still needs to be worked out, we forgot to talk
> about this.
>
> 8) Partition Shrinking
> ======================
>
> Eg
> http://blog.linuxgrrl.com/2012/04/18/rough-thoughts-on-reclaiming-space-from-partitions-during-installation/
>
> This is waiting on me producing a mockup. I talked to dlehman in IRC
> about this last week. I had a conversation with Garrett Lesage (another
> open source designer) showing him our mockups so far and he gave the
> feedback that we should just have one slider per device. The slider
> might have various 'sticky points' where more drastic actions happen the
> more you shrink. E.g., say you need 4 gb to do the install. Say you have
> a pre-existing windows installation on the device with three partitions:
>
> - partition A: windows_c with 2 GB free on filesystem
> - empty space: 2 GB between parts A & B
> - partition B: windows_d with 0MB free on filesystem
> - partition C: windows_e with 2 GB free on filesystem
>
> You'll have 2 points on the slider maybe:
> - slide to point 1 and you'll meet the 4gb requirement. You'll resize
> partition A to free the 2 GB, which is adjacent to the 2 GB empty space
> between partitions A & B.
> - slide to point 2 and you'll free up an additional 2 gb by resizing
> partition C down 2 GB. lvm or btr could be used to make it part of the
> same logical volume as the chunk of space on the other side of partition
> b.
>
> So there's a preference for resizing partitions that have bigger
> potential chunks of space to free (so we use partition A first rather
> than partition C, because even though they are the same size, partition
> A has a bigger potential being adjacent to a large free space than
> partition C does.) If you want more space for the filesystem though,
> moving the slider further does the more drastic action of using a
> logical volume to chain the two physically disparate chunks together
> into one for your fedora install.
Do we really want to gamble with shrinking windows partitions?

>
> 9) Storage auto-default if Fedora and if only one non-removable disk
> detected
> ================================================== ==================
Sorry, I don't understand this part. Please see questions below.
>
> This is an idea Ryan had when he first reviewed the Anaconda mockups and
> got started on the project. Right now, no matter what, you can't click
> past the hub #1 - you have to fill out information in the storage hub.
> However, a big chunk of Fedora users are setting up single-user Fedora
> installations on laptops that have a single hard drive. So, if we
> auto-detect that there is only one non-removable hard drive on a system,
> we could allow these users to click past the storage screen by
> automatically selecting the single laptop drive for install.
This means they get to the partitioning screen with the only available
drive selected, right?

>
> This doesn't mean we wipe that single disk. Instead, we autopart any
> pre-existing free space on the disk. If that isn't enough space, we
> automatically shrinkany filesystems as needed.
And this means that if there is only one drive and enough space on it
(shrinking the filesystems as needed), we would automatically let users
to go through the hub #1 without any note about such "brutal"
auto-partitioning done? And if they go to the Storage spoke, they will
find the auto-partitioning based layout of their partitions there?
Because if yes (and the following comment seems to be confirming my
concern), I would, as a user, strongly dislike such things happening
automatically.

> If that isn't enough, we
> dump 'em in hub #1 with the 'attention' ! icon on the storage part and
> the user can sort it.
>
> 9) Icons for specialized disks
> ===============================
>
> All the advanced / network storage disks have the same network storage
> icon. It might be good to be able to distinguish between raid devices,
> sans, dasd/zfcp, etc. So we could find and as necessary develop new
> icons and hook them into the different types of storage when they're
> displayed.
>
> 10) Subscription stuff
> ======================
>
> This is something that has to be sorted out with the subscriptions team,
> as well as the folks working on the F18 Initial Experience
> feature. One point that Ryan made was that the GNOME first experience
> mockups are very user-centric while firstboot is very system-centric and
> not particular to a specific user much.
>
> 11) Bug-reporting / Debug opt-in
> ================================
>
> Jiri Moskovcak brought this up in a recent email thread with me and
> Chris - the main ide ahere is that it would be nice to let the user set
> various debugging options at install time. So they could opt in to ABRT
> and installing debuginfo packages, for example. I need to talk to Jiri
> more and get more information about this because I'm still a bit
> confused about the details. Some things that came up when Chris, Ryan,
> Mackenzie, and I talked about it today:
>
> - opt-in should be someone off hub #1 because it affects whether or not
> abrt gets installed and particular debuginfo packages get installed
> - what if it was in firstboot, and abrt / debuginfo was installed in a
> post-script? or queued up in packagekit?
> - could they be queued up in the offline updates system?
> - is there any mechanism to autoclean debuginfo packages when they are
> stale and useless?
> - smolt has a new name... this might change the smolt mockups we have
> - for oem usages of firstboot, there is a reconfig option in the old
> firstboot, it should carry on to the new one.
This applies to both #10 and #11:
I think we should just write a guide (I could write such guide as I'm
planning to write my own custom spoke) how to write Anaconda spokes and
then help other teams with the development of *their* spokes maintained
by them (probably as separate packages installed by lorax?).

And replacing firstboot with the second run of the Anaconda UI with
unfinished spokes would allow us to use such spokes in both installation
and setting up the installed system during the first boot.

>
> 12) Random point
> ================
>
> - How are we handling pre-existing LUKS passwords in the new ui?
>
>
>
> I gotta go home so no time to do the to-do list summary, maybe
> tomorrow.
>
> ~m
>
>
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list


--
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, 01:18 PM
Martin Sivak
 
Default UI status braindump, part II

> This applies to both #10 and #11:
> I think we should just write a guide (I could write such guide as I'm
> planning to write my own custom spoke) how to write Anaconda spokes
> and
> then help other teams with the development of *their* spokes
> maintained
> by them (probably as separate packages installed by lorax?).
>
> And replacing firstboot with the second run of the Anaconda UI with
> unfinished spokes would allow us to use such spokes in both
> installation
> and setting up the installed system during the first boot.
>

This is exactly what I would like to happen. IT will save us lot of code, but we need to decide fast as some partners already have firstboot plugins and those would need to be changed to support the new UI API.

Martin

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

> Do we really want to gamble with shrinking windows partitions?

We've offered Windows resizing for years now, so yeah I'm fine with
continuing to do so.

> > This doesn't mean we wipe that single disk. Instead, we autopart any
> > pre-existing free space on the disk. If that isn't enough space, we
> > automatically shrinkany filesystems as needed.
> And this means that if there is only one drive and enough space on it
> (shrinking the filesystems as needed), we would automatically let users
> to go through the hub #1 without any note about such "brutal"
> auto-partitioning done? And if they go to the Storage spoke, they will
> find the auto-partitioning based layout of their partitions there?
> Because if yes (and the following comment seems to be confirming my
> concern), I would, as a user, strongly dislike such things happening
> automatically.

Automatically shrinking is a little concerning, yeah. However
automatically selecting the single available disk and attempting to do
autopart in the free space is reasonable. If we can effectively tell
people what's going to happen, I don't see a problem with it.

> This applies to both #10 and #11:
> I think we should just write a guide (I could write such guide as I'm
> planning to write my own custom spoke) how to write Anaconda spokes and
> then help other teams with the development of *their* spokes maintained
> by them (probably as separate packages installed by lorax?).

That would be handy. I could also write a guide, or at least edit it.

> And replacing firstboot with the second run of the Anaconda UI with
> unfinished spokes would allow us to use such spokes in both installation
> and setting up the installed system during the first boot.

The firstboot situation has become extremely complex, and I don't know
what we are going to do about it.

- 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:26 PM
Chris Lumens
 
Default UI status braindump, part II

> > For Fedora, we talked about:
> > - Left column, your option of desktop spins as well as a minimal "no
> > desktop" option equivalent to @core
>
> > - Right column, functional spins package groups (e.g., electronic
> > lab,
> > security spin, design suite, etc.), normal package groups without
> > language support groups.
>
> Do we have data source for this? What about offline installs? If spins
> are changed to be metapackages, we can just filter them by special
> group (Spin . If not, where do we get the list?

We don't have a data source for this yet, no. It was being talked about
as a reworking of comps (or some other similar metadata file shipped
with the repo). I don't have any idea when we will see results which is
why newui currently just does the lame division it does.

> > - adding extra repos - still needs to be worked out, we forgot to
> > talk
> > about this.
>
> There is a glade for this already. No code though.. The question still
> is.. are we going to support people's repositories? And where are we
> going to get the list from if we do?

Last I heard, I thought we were not going to do the people repositories
thing.

> 13) Rescue mode
> ===============
>
> - any plans?
> - I sent a message to the list two weeks ago asking for user cases
> with my comments about the issues we might encounter

I haven't put in any time thinking about rescue mode, unfortunately.

- 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:55 PM
Bill Nottingham
 
Default UI status braindump, part II

Chris Lumens (clumens@redhat.com) said:
> > > - Right column, functional spins package groups (e.g., electronic
> > > lab,
> > > security spin, design suite, etc.), normal package groups without
> > > language support groups.
> >
> > Do we have data source for this? What about offline installs? If spins
> > are changed to be metapackages, we can just filter them by special
> > group (Spin . If not, where do we get the list?
>
> We don't have a data source for this yet, no. It was being talked about
> as a reworking of comps (or some other similar metadata file shipped
> with the repo). I don't have any idea when we will see results which is
> why newui currently just does the lame division it does.

Working on it.

Bill

_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-13-2012, 03:18 PM
David Lehman
 
Default UI status braindump, part II

On Fri, 2012-07-13 at 15:04 +0200, Vratislav Podzimek wrote:
> Please see the inlined comments below.
>
> On Thu, 2012-07-12 at 18:33 -0400, Máirín Duffy wrote:
> > 9) Storage auto-default if Fedora and if only one non-removable disk
> > detected
> > ================================================== ==================
> Sorry, I don't understand this part. Please see questions below.
> >
> > This is an idea Ryan had when he first reviewed the Anaconda mockups and
> > got started on the project. Right now, no matter what, you can't click
> > past the hub #1 - you have to fill out information in the storage hub.
> > However, a big chunk of Fedora users are setting up single-user Fedora
> > installations on laptops that have a single hard drive. So, if we
> > auto-detect that there is only one non-removable hard drive on a system,
> > we could allow these users to click past the storage screen by
> > automatically selecting the single laptop drive for install.
> This means they get to the partitioning screen with the only available
> drive selected, right?
>
> >
> > This doesn't mean we wipe that single disk. Instead, we autopart any
> > pre-existing free space on the disk. If that isn't enough space, we
> > automatically shrinkany filesystems as needed.

And how will we configure the bootloader in this case? If we don't feel
comfortable removing existing partitions from disk, do we feel
comfortable removing their existing bootloader without asking?

> And this means that if there is only one drive and enough space on it
> (shrinking the filesystems as needed), we would automatically let users
> to go through the hub #1 without any note about such "brutal"
> auto-partitioning done? And if they go to the Storage spoke, they will
> find the auto-partitioning based layout of their partitions there?
> Because if yes (and the following comment seems to be confirming my
> concern), I would, as a user, strongly dislike such things happening
> automatically.
>
> > If that isn't enough, we
> > dump 'em in hub #1 with the 'attention' ! icon on the storage part and
> > the user can sort it.
> >
> > 9) Icons for specialized disks
> > ===============================
> >
> > All the advanced / network storage disks have the same network storage
> > icon. It might be good to be able to distinguish between raid devices,
> > sans, dasd/zfcp, etc. So we could find and as necessary develop new
> > icons and hook them into the different types of storage when they're
> > displayed.
> >
> > 10) Subscription stuff
> > ======================
> >
> > This is something that has to be sorted out with the subscriptions team,
> > as well as the folks working on the F18 Initial Experience
> > feature. One point that Ryan made was that the GNOME first experience
> > mockups are very user-centric while firstboot is very system-centric and
> > not particular to a specific user much.
> >
> > 11) Bug-reporting / Debug opt-in
> > ================================
> >
> > Jiri Moskovcak brought this up in a recent email thread with me and
> > Chris - the main ide ahere is that it would be nice to let the user set
> > various debugging options at install time. So they could opt in to ABRT
> > and installing debuginfo packages, for example. I need to talk to Jiri
> > more and get more information about this because I'm still a bit
> > confused about the details. Some things that came up when Chris, Ryan,
> > Mackenzie, and I talked about it today:
> >
> > - opt-in should be someone off hub #1 because it affects whether or not
> > abrt gets installed and particular debuginfo packages get installed
> > - what if it was in firstboot, and abrt / debuginfo was installed in a
> > post-script? or queued up in packagekit?
> > - could they be queued up in the offline updates system?
> > - is there any mechanism to autoclean debuginfo packages when they are
> > stale and useless?
> > - smolt has a new name... this might change the smolt mockups we have
> > - for oem usages of firstboot, there is a reconfig option in the old
> > firstboot, it should carry on to the new one.
> This applies to both #10 and #11:
> I think we should just write a guide (I could write such guide as I'm
> planning to write my own custom spoke) how to write Anaconda spokes and
> then help other teams with the development of *their* spokes maintained
> by them (probably as separate packages installed by lorax?).
>
> And replacing firstboot with the second run of the Anaconda UI with
> unfinished spokes would allow us to use such spokes in both installation
> and setting up the installed system during the first boot.
>
> >
> > 12) Random point
> > ================
> >
> > - How are we handling pre-existing LUKS passwords in the new ui?
> >
> >
> >
> > I gotta go home so no time to do the to-do list summary, maybe
> > tomorrow.
> >
> > ~m
> >
> >
> > _______________________________________________
> > Anaconda-devel-list mailing list
> > Anaconda-devel-list@redhat.com
> > https://www.redhat.com/mailman/listinfo/anaconda-devel-list
>
>


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

On Fri, 2012-07-13 at 10:18 -0500, David Lehman wrote:
> > On Thu, 2012-07-12 at 18:33 -0400, Máirín Duffy wrote:
> doesn't mean we wipe that single disk. Instead, we autopart any
> > > pre-existing free space on the disk. If that isn't enough space, we
> > > automatically shrinkany filesystems as needed.
>
> And how will we configure the bootloader in this case? If we don't feel
> comfortable removing existing partitions from disk, do we feel
> comfortable removing their existing bootloader without asking?

Hm, let's walk through the bootloaders involved maybe?

Pre-existing Fedora / Red Hat / CentOS / etc install - Can we add an
entry to the existing one?

Pre-existing Linux install - likely to be grub. Do we have to remove it
or can we add an entry to the existing one?

Pre-existing OS X install - Will Woods had an idea for detecting OS X
machines. So we could maybe give any pre-existing OS X users some kind
of special message, like, 'go to bootcamp' or whatnot. We better not
blow away their OS X bootloader unless they just want to wipe it all (+1
to those folks.) What kind of config is needed to chainload the linux
install for Macs? If it requires manual config, is there any way to have
some kind of walkthrough for doing that manual config available and
referenced both in the installer and elsewhere? Is that manual config
hard?

Pre-existing Windows XP and up install - Same thing here, better to not
blow away and chain load? What manual config is involved here?


Also, is there ever a case where it's possible to blow away the
pre-existing OS X or Windows bootloader and configure grub to point to
the boot sector instead?

~m


_______________________________________________
Anaconda-devel-list mailing list
Anaconda-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/anaconda-devel-list
 
Old 07-13-2012, 08:54 PM
David Lehman
 
Default UI status braindump, part II

On Fri, 2012-07-13 at 12:08 -0400, Máirín Duffy wrote:
> On Fri, 2012-07-13 at 10:18 -0500, David Lehman wrote:
> > > On Thu, 2012-07-12 at 18:33 -0400, Máirín Duffy wrote:
> > doesn't mean we wipe that single disk. Instead, we autopart any
> > > > pre-existing free space on the disk. If that isn't enough space, we
> > > > automatically shrinkany filesystems as needed.
> >
> > And how will we configure the bootloader in this case? If we don't feel
> > comfortable removing existing partitions from disk, do we feel
> > comfortable removing their existing bootloader without asking?
>
> Hm, let's walk through the bootloaders involved maybe?
>
> Pre-existing Fedora / Red Hat / CentOS / etc install - Can we add an
> entry to the existing one?

I don't think we've ever practiced modifying other OS' bootloader
configurations. Does anyone have a sense that this might be an okay
thing to do?

>
> Pre-existing Linux install - likely to be grub. Do we have to remove it
> or can we add an entry to the existing one?

Pretty much same as above.

>
> Pre-existing OS X install - Will Woods had an idea for detecting OS X
> machines. So we could maybe give any pre-existing OS X users some kind
> of special message, like, 'go to bootcamp' or whatnot. We better not
> blow away their OS X bootloader unless they just want to wipe it all (+1
> to those folks.) What kind of config is needed to chainload the linux
> install for Macs? If it requires manual config, is there any way to have
> some kind of walkthrough for doing that manual config available and
> referenced both in the installer and elsewhere? Is that manual config
> hard?
>
> Pre-existing Windows XP and up install - Same thing here, better to not
> blow away and chain load? What manual config is involved here?

We'd have to ask someone who's used the windows/osx bootloader how much
work it is to add a linux entry. I have no idea.

>
>
> Also, is there ever a case where it's possible to blow away the
> pre-existing OS X or Windows bootloader and configure grub to point to
> the boot sector instead?

Again, you'd have to ask users of windows and osx about this. You can
probably guess my personal preference.

People are going to be pissed no matter what happens here. Some would be
mad if we took over the system bootloader role, while others would be
mad if we didn't set things up to boot their new Fedora install without
any intervention on their part.

There's something to be said for the notion that if you care about what
we're going to do to your system you should probably click on some stuff
and check on it before you proceed with the actual install process. To
me, that suggests we should default to taking over the system bootloader
role, if that's even possible on all platforms.

Dave

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


_______________________________________________
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:40 AM.

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