Bug 865765

I would point you to the fedora-devel-list discussion about installer which happened about two years ago. (it has Ubuntu in the topic)

This is the exact thing that was requested by the community. While the packages are copying, you can do additional setup without prolonging the whole installation.

So we are not changing this and we will add more "spokes" (as we call them) to the progress screen. If you do not configure them there, the new firstboot will show them again (or defer them to Gnome Inital Experience when applicable).

How about then actually pointing me to that discussion then referring me to some 2 here old thread that has "Ubuntu" topic in it and when did we start chacing ubuntu? 

Trying to set the root password while the packages are being installed does not work I might add. 

If we cant do minimal install with root password set just before beta the installer should be removed from the distribution, the old installer used and this newUI which clearly is in no ready state be deferred to F19 instead.

Why doesn't it work? The time consumed is exactly the same only the order is different.

I responded to the mail you posted to the mailing list, but we are making the root password mandatory for F18. F19 will change that as we will have new firstboot (with text mode).

Reverting installer is not going to happen.

Created attachment 625938 [details]
Current master branch's behaviour regarding root password

This is what happens on current anaconda version when root password is not set.

(In reply to comment #3)
> Why doesn't it work? The time consumed is exactly the same only the order is
> different.

You tell me why setting the root password does not work it's your code

> I responded to the mail you posted to the mailing list, but we are making
> the root password mandatory for F18. F19 will change that as we will have
> new firstboot (with text mode).

You dont install firstboot on minimal installs 

> Reverting installer is not going to happen.

We have slipped on numerous occasion but even now we still we cant do the most basic installation of them something is seriously wrong so answer me this why are you guys rushing the newUI for F18 when it is clearly no where ready?

> You tell me why setting the root password does not work it's your code

I thought you were talking about the idea.

It is the same code and executed at the same place as if you set the password on the main hub. And the same place as if you use kickstart. If it does not work for you, fill a bug.

> You dont install firstboot on minimal installs 

Well we will have to for F19 text mode if sudo is going to be preferred. Or we just detect minimal install in Anaconda and require root password in that case.

> > Reverting installer is not going to happen.
> 
> We have slipped on numerous occasion but even now we still we cant do the
> most basic installation of them something is seriously wrong so answer me
> this why are you guys rushing the newUI for F18 when it is clearly no where
> ready?

This does not belong here. Report individual bugs (real ones) or take it to FESCo.

(In reply to comment #6)
> > You tell me why setting the root password does not work it's your code
> 
> I thought you were talking about the idea.
> 
> It is the same code and executed at the same place as if you set the
> password on the main hub. And the same place as if you use kickstart. If it
> does not work for you, fill a bug.

For the love of me what you do think this is! 

> 
> > You dont install firstboot on minimal installs 
> 
> Well we will have to for F19 text mode if sudo is going to be preferred. Or
> we just detect minimal install in Anaconda and require root password in that
> case.
> 
> > > Reverting installer is not going to happen.
> > 
> > We have slipped on numerous occasion but even now we still we cant do the
> > most basic installation of them something is seriously wrong so answer me
> > this why are you guys rushing the newUI for F18 when it is clearly no where
> > ready?
> 
> This does not belong here. Report individual bugs (real ones) or take it to
> FESCo.

Oh sorry for reporting a fake bug!

> For the love of me what you do think this is! 

"Root password spoke missing from the main hub"

This is a design bug, not "Root password setting does not work.".

> Oh sorry for reporting a fake bug!

Again.. this is a bug filled against design. Design which has been agreed upon and widely publicized since FUDCon Tempe last January (that is 21 months ago).

If you complain about slips (which really aren't just our fault) then this is a really great time to tell us that you do not like the design and we should start from scratch...

I just tested this spoke a ton last night and it works fine for me. 

If it does not work, please explain what happens. Can you enter the spoke?  Does it allow you to type passwords? Does it properly validate the passwords?  Does it apply the password to the root user?

Just saying "doesn't work" will get the bug closed because it works for me and others. Details and logs are needed.

(In reply to comment #8)
> > For the love of me what you do think this is! 
> 
> "Root password spoke missing from the main hub"
> 
> This is a design bug, not "Root password setting does not work.".

In alpha the root password dialog was present and working in the main hub so design bug or not a design bug when it shows up in the installation section of anaconda.   

Am I supposed to throw a dice and guess where he finally ends up in final? 

> 
> > Oh sorry for reporting a fake bug!
> 
> Again.. this is a bug filled against design. Design which has been agreed
> upon and widely publicized since FUDCon Tempe last January (that is 21
> months ago).

Beside the obvious point that not everybody can attend "fudcon" to share their idea or keep track of everyone blogs and keep track of what actually was discussed there, the ui design does not seem to be more stable then so that everybody have to guess where the root password dialog will appear before final.  

Instead of listening to the critic of the overall design you just choose to dismiss and ignore it instead of actually try to improve the usability issue end users themselves are pointing out in the design. ( wtf)  

Seriously I know that you are a developer but let me ask you this dont you think it's odd that the design team is laying things out here, that... 

In the welcome screen, the first screen presented to the end user, the buttons [quit] and [Continue ] are in the left and right corner at the bottom of screen immediately indicating to the end user that this is the place you should look for to move forwards and backwards installer.. 

In the main hub that tradition is continue you have quit and begin installation at the button of the screen further indicating to the user that this is the way to move forwards and backwards in installer...

Then when the user enters his first spoke to configure ( Date and Time ) the done button is placed at the upper left corner while every application, your email client, your terminal window, your office applications, your web browser puts the close a.k.a "done using" button in the upper right corner which makes it the *least* place he expects it to be once he has look at the bottom of the screen looking for continue.

Heck even ntp is left there "on" while having it unconfigured and the installer giving warning that it's unconfigured and the end user scratching it's head what he is supposed to configure there which btw he has absolutly no idea how to do...

In different spoke configurable options for that spoke are placed all over the UI instead of in one coherent place .. 

Then finally when the user enters is last spoke of them all the "storage" spoke these so called "Designers" throw in both an "Done" button and "Continue to just give it that final confusing touch. 

Does the above really seem OK for you? Do you really trust those designers to actually know what they are doing? 

> If you complain about slips (which really aren't just our fault) then this
> is a really great time to tell us that you do not like the design and we
> should start from scratch...

Keep your sarcastic remarks towards me to your self. If you really think I'm amused by the state of the distribution installer at this stage and time in our development cycle you are sadly mistaken and up to this point I have been support of moving forward instead of backwards with it...

(In reply to comment #9)
> I just tested this spoke a ton last night and it works fine for me. 
> 
> If it does not work, please explain what happens. Can you enter the spoke? 

If you want reliably re-create what seems to sometimes happen to me which is based maybe on the when I'm entering in the install progress spoke enter the password spoke as soon as it appears there, then click done then re-enter the set password spoke and you wind up with a black screen ( no-gui ) 

I cannot test if the actual password was set or is valid after the installation since every time I press a key in virt-manager I get

atkbd serio0: Unknown key pressed ( translated set 2, code 0x0 on isa0060&serio0).
atkbd serio0: Use 'setkeykeycodes 00 <keycode>' to make it known

> In alpha the root password dialog was present and working in the main hub so
> design bug or not a design bug when it shows up in the installation section
> of anaconda.   

The root password has always been planned to appear on the installation hub.  We only added it to the first hub because at the last minute, Fedora decided it wanted a way to set the root password and we didn't have any code ready for adding spokes to the installation hub.

(In reply to comment #11)
> (In reply to comment #9)
> > I just tested this spoke a ton last night and it works fine for me. 
> > 
> > If it does not work, please explain what happens. Can you enter the spoke? 
> 
> If you want reliably re-create what seems to sometimes happen to me which is
> based maybe on the when I'm entering in the install progress spoke enter the
> password spoke as soon as it appears there, then click done then re-enter
> the set password spoke and you wind up with a black screen ( no-gui ) 

This should be it's own bug report.  Please do try to reproduce with VNC, but I suspect it's actually a problem with the virt manager graphics support.

> 
> I cannot test if the actual password was set or is valid after the
> installation since every time I press a key in virt-manager I get
> 
> atkbd serio0: Unknown key pressed ( translated set 2, code 0x0 on
> isa0060&serio0).
> atkbd serio0: Use 'setkeykeycodes 00 <keycode>' to make it known

This sounds like another bug for virtmanager.

If you're just doing a quick minimal install, why not text mode?

"I cannot test if the actual password was set or is valid after the installation since every time I press a key in virt-manager I get"

I have that bug too, but you can still test it. just type root for the user name, hit enter, type the password. in amongst all the spam you can still see whether the login succeeded or not.

"If you want reliably re-create what seems to sometimes happen to me which is based maybe on the when I'm entering in the install progress spoke enter the password spoke as soon as it appears there, then click done then re-enter the set password spoke and you wind up with a black screen ( no-gui ) "

I can recreate this one quite readily at present, I think it may be timing based (if you go into the spoke very quickly and complete it fast, the black screen happens). I'll see how virt-manager specific it is.