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@xxxxxxxxxx> 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@xxxxxxxxxx > https://www.redhat.com/mailman/listinfo/anaconda-devel-list _______________________________________________ Anaconda-devel-list mailing list Anaconda-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/anaconda-devel-list
