Bug 749407

Summary:	installer quits at the end of the installation
Product:	[openSUSE] openSUSE 12.1	Reporter:	macias - <bluedzins>
Component:	Basesystem	Assignee:	Stephan Kulow <coolo>
Status:	VERIFIED WONTFIX	QA Contact:	E-mail List <qa-bugs>
Severity:	Normal
Priority:	P5 - None
Version:	Final
Target Milestone:	---
Hardware:	x86-64
OS:	Other
Whiteboard:
Found By:	---	Services Priority:
Business Priority:		Blocker:	---
Marketing QA Status:	---	IT Deployment:	---

Description macias - 2012-02-28 19:56:58 UTC

Installer quits at the end of the installation


This is a big mistake, because the next step is restarting the machine -- this step is completely different from installation process, and you can assume that installation process is just copying the files, so it is linear and predictable (if you copied 1% of files, you will copy 100%; if correctly -- this is another story).

But with restart you cannot tell if this will be successful just by looking at the status of file copying. 

User can (at it happened) get back to computer to see black screen -- how do you from the black screen what is happening?

So please fix it -- add at the end small window -- "installation completed. Click OK to restart".

This way user could see the restart process, and tell when restart crashed/freezed.

Comment 1 Stephan Kulow 2012-07-11 05:05:08 UTC

there is a popup at the end of the installation counting down from 10 to 0. There is no waiting on purpose because it's called "automatic configuration".

Comment 2 macias - 2012-07-11 09:39:19 UTC

I would say a thing, if it would be automatic. But it is not automatic. User has to sit through ENTIRE installation just to interact when the restart kicks in.

So it should wait for user, to confirm the restart, not just count down, because it is NOT automatic.

And luckily I installed OS 12.1 yesterday. I was not at the computer, but this is how it worked:
* installation proceeded
* installation ended
* there was countdown for restart -- no waiting for user
* system restarted
* system asked for password for partition decryption (/home)
* there was countdown for that as well
* booting up proceeded
* system tried to setup up the remaining pieces --> failed because no /home
* popup shows up about the error (no /home), this time waiting for user

When I got back to computer I saw the above result. Because of 2 flaws (1st in the installation process, 2nd in boot script), this "automatic" installation can only screw installation and you have to run it again from the start (or in case of more experienced admin, setup the rest manually).

So, once again, it is NOT automatic, thus the installer should wait with restart for user. Because user has to be present when the computer boots up.

Comment 3 Stephan Kulow 2012-07-11 09:46:34 UTC

the booting shouldn't proceed without the user password. But I won't add a wait at the end of installation just because a broken boot script

Comment 4 macias - 2012-07-11 13:02:13 UTC

Stephan, partially I agree with you on this, the problem from user POV is not this or that issue, but overall experience. And since stopping at password prompt was overruled before (AFAIR), the other point is restart.

And why I don't agree fully -- because feedback matters, when I see computer booted I don't know what happened. First stage of installation is pretty important, and  I should see the result of it.

Optionally, considering installation is quite long process, a checkbox at the bottom (during installation -- i.e. copying the files)

[x] restart automatically after install

won't hurt.

Comment 5 Stephan Kulow 2012-07-20 10:24:23 UTC

put it in features.opensuse.org and let people vote for it. I'm against adding options "because they don't hurt".

Comment 6 macias - 2012-07-20 15:55:40 UTC

The option I mentioned was just remark (thinking aloud), nothing less, nothing more.


This report is however about a bug, not a feature. One can run installation process (through all valid and supported steps) which leads to undefined state --> this is a _fact_, not something requiring voting.

Comment 7 Stephan Kulow 2012-07-21 18:19:33 UTC

then file a bug report with logs and do not suggest evil work arounds.

Comment 8 macias - 2012-07-21 19:52:23 UTC

You are fully aware of the problem, yet you require logs. You won, congratulations, I don't have any more time to waste.