[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Removing the number of installation screens (F-14)



Hi,

as Steffen said, we need root access with a password to run firstboot on s390 in the first place.
Also firstboot in text mode does not have user creation, so how would we be solving this then?


--

  Martin Gracik

----- "Hans de Goede" <hdegoede redhat com> wrote:

> Hi,
> 
> On 05/11/2010 04:12 PM, David Cantrell wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > On Tue, 11 May 2010, Hans de Goede wrote:
> >
> >> Hi,
> >>
> >> For F-14, I would like to see the number of
> >> installation screens reduced, thus making the installer more
> >> friendly for less experienced users.
> >>
> >> Some ideas:
> >>
> >> 1) Add an "advanced" cmdline option, and when this is not present:
> >> * Do not ask for advanced storage use
> >> * Do not ask what sort of installation (workstation / development
> >> machine /
> >> server) to do, simply do a default install
> >> * Maybe hide "review partitioning" and "custom layout"
> partitioning
> >> options
> >>
> >> I know people don't like this, but since we target a rather wide
> audience
> >> from beginning users to people who want to use SAN's, I really
> believe we
> >> need to differentiate between the two, and as has been argued
> before
> >> adding
> >> a UI to differentiate between the two will only lead to everyone
> simply
> >> selecting advanced as they are afraid they will miss out on some
> >> choices, so
> >> moving this to the cmdline where power users will be able to find
> it,
> >> seems
> >> like a possible answer to me.
> >
> > I think you are correct in that we need to differentiate between
> the
> > types of
> > users. I am not a big fan of adding command line options to
> enable/disable
> > screens in the installer, so maybe we could do a variation on the
> > command line
> > option.
> >
> > We could configure what screens are shown or skipped in the
> > installclass. Do
> > we still have 'expert' as a boot option? If so, we could key on that
> to
> > enable the screens we hide by default in the installclass. The
> fedora
> > installclass could skip the ones you mention and the rhel one could
> show
> > them
> > by default.
> >
> 
> Yes this is what I was thinking of, for Fedora not showing iscsi /
> fcoe / etc.
> by default makes sense to me IMHO, otoh we do want Fedora users to be
> able
> to use this code. For RHEL we obviously do want to allow these by
> default
> (well based on the product), so yes this belong inside the
> installclass.
> 
> I'm afraid that for the case of still allowing the use of then even
> though
> not asking be default in Fedora will require a cmdline option. Maybe
> we
> could do a cmdline option to set the installClass (could be handy for
> testing
> anyways) and have 2 Fedora install-classes ?
> 
> > Of course, this would probably require some work on the
> installclass
> > design.
> >
> >> 2) There is no need to configure the root password during
> >> installation, move
> >> this to firstboot preferably to the user configuration screen.
> >
> > I am not opposed to moving this screen to firstboot, but I think
> this is
> > more
> > of a policy decision for Fedora rather than a technical decision. In
> which
> > case, I guess we should ask FESCo.
> >
> 
> If people feel this should be asked to FESco that is fine. It seems
> this is
> something which we could only do for interactive GUI installs anyways,
> but still
> I think it would be good to move the root password entry, as currently
> it feels
> out of place, and having it together with the regular user creation
> feels more
> logical to me, and also has the advantage of a new user being made
> aware of
> the administrator versus regular user roles (and preferably different
> passwords)
> more clearly.
> 
> Regards,
> 
> Hans
> 
> _______________________________________________
> Anaconda-devel-list mailing list
> Anaconda-devel-list redhat com
> https://www.redhat.com/mailman/listinfo/anaconda-devel-list


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]