Bug #143

1.4.3: Installer hangs at timezone selection

Added by olli over 8 years ago. Updated over 5 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:swildner% Done:

0%

Category:-
Target version:-

Description

Hi,

Is this the correct group for reporting installation
problems?

I just tried to install 1.4.3 for testing purposes within
qemu. I downloaded the iso and booted it, started the
installer and went through a standard installation, which
seemed to work fine.

Afterwards (still in the installer) I went through the
configuration steps ... It asked me for UTC or local time
clock, I answered UTC, then it presented a list of time
zones, I selected "Europe" -- and then it hung: Empty blue
screen, only with the "F10=..." line at the top and the
(empty) help line at the bottom.

When I switched to vty0 (Alt-F1), I discovered that the
kernel had reported that "dfuife_curses" was aborted on
signal 11 (SIGSEGV). I had to abort the installer with
Ctrl-C, because it was impossible to revive.

However, when I rebooted, the newly installed system went
up fine, so the installation was successful. The file
/etc/wall_cmos_clock did exist, but no /etc/localtime
file.

Best regards
Oliver

History

#1 Updated by joerg over 8 years ago

On Tue, Apr 11, 2006 at 08:18:35AM +0000, Oliver Fromme wrote:
> Afterwards (still in the installer) I went through the
> configuration steps ... It asked me for UTC or local time
> clock, I answered UTC, then it presented a list of time
> zones, I selected "Europe" -- and then it hung: Empty blue
> screen, only with the "F10=..." line at the top and the
> (empty) help line at the bottom.

I know this problem. I'll prepare a debug build of the installer
packager after Eastern, so that someone can get me coredumps for this
and other problems :-)

Joerg

#2 Updated by check+ixk4k700rskmlrtl over 8 years ago

wrote:
> Oliver Fromme wrote:
> > Afterwards (still in the installer) I went through the
> > configuration steps ... It asked me for UTC or local time
> > clock, I answered UTC, then it presented a list of time
> > zones, I selected "Europe" -- and then it hung: Empty blue
> > screen, only with the "F10=..." line at the top and the
> > (empty) help line at the bottom.
>
> I know this problem. I'll prepare a debug build of the installer
> packager after Eastern, so that someone can get me coredumps for this
> and other problems :-)

Does that mean that you cannot reproduce the problem?
It's quite easy, just boot the official 1.4.3. ISO in
a standard qemu host and go through the installation.
Only takes a few minutes.

However -- The one thing which is extremely annoying is
the pause during boot, when the sshd DSA host keys are
generated. It takes 29 minutes (!) on my hardware. It
does that each time you boot the ISO, and there's no
indication how long it will take (no progress display).
Hell, it doesn't even print something like "This will
take a while, please be patient ..."

Best regards
Oliver

#3 Updated by joerg over 8 years ago

On Tue, Apr 11, 2006 at 12:27:26PM +0000, Oliver Fromme wrote:
> Does that mean that you cannot reproduce the problem?
> It's quite easy, just boot the official 1.4.3. ISO in
> a standard qemu host and go through the installation.
> Only takes a few minutes.

I haven't used the installer for ages. Old style installation :-)

Joerg

#4 Updated by rg_monde over 8 years ago

> [snip]
>However -- The one thing which is extremely annoying is
>the pause during boot, when the sshd DSA host keys are
>generated. It takes 29 minutes (!) on my hardware. It
> [/snip]

A good old "Ctrl+c" does it real fast. :)

Regards, Robert.

>Best regards
> Oliver
>
>--
>Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing
>Dienstleistungen mit Schwerpunkt FreeBSD: http://www.secnetix.de/bsd
>
>Any opinions expressed in this message may be personal to the author
>and may not necessarily reflect the opinions of secnetix in any way.

#5 Updated by tomaz.borstnar over 8 years ago

Oliver Fromme pravi:

> Does that mean that you cannot reproduce the problem?
> It's quite easy, just boot the official 1.4.3. ISO in
> a standard qemu host and go through the installation.
> Only takes a few minutes.

Yes, you exactly described it. I reported too. I later run tzsetup in order not to hit on this bug.

Tomaž

#6 Updated by corecode over 8 years ago

On 11.04.2006, at 20:01, Tomaž Borštnar wrote:
>> Does that mean that you cannot reproduce the problem?
>> It's quite easy, just boot the official 1.4.3. ISO in
>> a standard qemu host and go through the installation.
>> Only takes a few minutes.
> Yes, you exactly described it. I reported too. I later run tzsetup in
> order not to hit on this bug.

It seems that we need to get more involved with the installer
folks/their CVS. any plans/ideas on how to do that best?

cheers
simon

#7 Updated by justin over 8 years ago

On Tue, April 11, 2006 2:32 pm, Simon 'corecode' Schubert wrote:
> On 11.04.2006, at 20:01, Tomaž Borštnar wrote:
>>> Does that mean that you cannot reproduce the problem?
>>> It's quite easy, just boot the official 1.4.3. ISO in
>>> a standard qemu host and go through the installation.
>>> Only takes a few minutes.
>> Yes, you exactly described it. I reported too. I later run tzsetup in
>> order not to hit on this bug.
>
> It seems that we need to get more involved with the installer
> folks/their CVS. any plans/ideas on how to do that best?

There is a bsdinstaller mailing list that I assume Chris Pressey / Scott
Ullrich are watching, though I haven't seen any traffic on it for some
time. Mail of patches to there is one possibility.

#8 Updated by geekgod over 8 years ago

Justin C. Sherrill wrote:
> On Tue, April 11, 2006 2:32 pm, Simon 'corecode' Schubert wrote:
>
>>On 11.04.2006, at 20:01, Tomaž Borštnar wrote:
>>
>>>>Does that mean that you cannot reproduce the problem?
>>>>It's quite easy, just boot the official 1.4.3. ISO in
>>>>a standard qemu host and go through the installation.
>>>>Only takes a few minutes.
>>>
>>>Yes, you exactly described it. I reported too. I later run tzsetup in
>>>order not to hit on this bug.
>>
>>It seems that we need to get more involved with the installer
>>folks/their CVS. any plans/ideas on how to do that best?
>
>
> There is a bsdinstaller mailing list that I assume Chris Pressey / Scott
> Ullrich are watching, though I haven't seen any traffic on it for some
> time. Mail of patches to there is one possibility.
>

Yes, we monitor the BSD Installer lists (or atleast I still do).
Haven't heard from Chris in a while as his uni studies have increased.

If someone has a patch feel free to send it over. In addition Joerg and
Simon already have CVS accounts on our server.

Scott

#9 Updated by check+ixlmlx00rsq7qo6d over 8 years ago

wrote:
> Oliver Fromme wrote:
> > Does that mean that you cannot reproduce the problem?
> > It's quite easy, just boot the official 1.4.3. ISO in
> > a standard qemu host and go through the installation.
> > Only takes a few minutes.
>
> I haven't used the installer for ages. Old style installation :-)

I see. But how does that prevent you from trying to
reproduce the problem with qemu and create the coredump
yourself?

(Don't get me wrong, I'll be happy to upload a coredump
if that helps in debugging the issue. I just don't
understand why you cannot do that yourself; it's easily
100% reproducible.)

Best regards
Oliver

#10 Updated by check+ixlmlx00rsq7qo6d over 8 years ago

wrote:
> > [snip]
> >However -- The one thing which is extremely annoying is
> >the pause during boot, when the sshd DSA host keys are
> >generated. It takes 29 minutes (!) on my hardware. It
> > [/snip]
>
> A good old "Ctrl+c" does it real fast. :)

Yes, I know that, but then you can't run sshd. :-)

Sorry, I should have been more clear. My criticism wasn't
meant to be about the fact that the keys are created, or
that it takes so long -- you can't change that anyway if
you need sshd. My point rather was that there should be
a bit more verbose output, so the user knows that the box
isn't deadlocked or something.

(BTW, FreeBSD has the same problem. OpenBSD is even worse:
It always generates the keys if they don't exist, even if
sshd is specifically disabled. FreeBSD doesn't do that.)

Oh, one final note: I like the DF installer very much.
The GUI is easier to use than both FreeBSD's sysinstall
and NetBSD's sysinst, not to mention OpenBSD's horrible
installation script which is the worst thing since I had
to install Slackware 0.1 from a set of floppies 15 years
ago.

Best regards
Oliver

#11 Updated by corecode over 8 years ago

On 12.04.2006, at 07:56, Oliver Fromme wrote:
>>> However -- The one thing which is extremely annoying is
>>> the pause during boot, when the sshd DSA host keys are
>>> generated. It takes 29 minutes (!) on my hardware. It
> Sorry, I should have been more clear. My criticism wasn't
> meant to be about the fact that the keys are created, or
> that it takes so long -- you can't change that anyway if
> you need sshd. My point rather was that there should be
> a bit more verbose output, so the user knows that the box
> isn't deadlocked or something.

Can we launch this in the background? Installation can proceed without
sshd, and if you need remote access, well, you just have to wait.

Do you know if needs 29 minutes of CPU time, or does it just have to
wait so long until all neccessary entropy has been gathered? Maybe
there is still a but in entropy gathering somewhere.

cheers
simon

#12 Updated by check+ixlxfx00rs0gmgcu over 8 years ago

Simon 'corecode' Schubert <> wrote:
> Oliver Fromme wrote:
>>>> However -- The one thing which is extremely annoying is
>>>> the pause during boot, when the sshd DSA host keys are
>>>> generated. It takes 29 minutes (!) on my hardware. It
>> Sorry, I should have been more clear. My criticism wasn't
>> meant to be about the fact that the keys are created, or
>> that it takes so long -- you can't change that anyway if
>> you need sshd. My point rather was that there should be
>> a bit more verbose output, so the user knows that the box
>> isn't deadlocked or something.
>
> Can we launch this in the background? Installation can proceed without
> sshd, and if you need remote access, well, you just have to wait.

I didn't think of that ... But it should be possible to
run it in the background with a reasonable nice level.
However, it would have to be clearly documented, so it
doesn't lead to further confusion. It also leads to the
question how to signal to the user when the background
process is done, so he can log in from remote.

Howeven, I was rather thinking about adding one or two echo
commands to the script. Something along the lines:
<snip>
***
*** SSH host key generation may take a while, please be patient.
*** If you don't need sshd(8), you can skip this with Ctrl-C.
***
</snip>

It would also be extremely nice if ssh_keygen could display
a progress bar or percent value. But that would have to be
done by the OpenSSH folks, of course, not DragonFly.

> Do you know if needs 29 minutes of CPU time, or does it just have to
> wait so long until all neccessary entropy has been gathered? Maybe
> there is still a but in entropy gathering somewhere.

I'm pretty sure it needs 29 minutes of CPU time. Most of
the time was spent generating the DSA key. The RSA key was
much quicker, maybe half a minute (I didn't measure).
The CPU was 100% busy while generating the keys.

On a faster machine the whole process took considerably
less time; about 1 minute. But that's still a long pause
during boot which can give users (especially newbies) an
uneasy feeling.

(Just my 2 cents.)

Best regards
Oliver

#13 Updated by justin over 8 years ago

On Wed, April 12, 2006 7:51 am, Oliver Fromme wrote:

> Howeven, I was rather thinking about adding one or two echo
> commands to the script. Something along the lines:
> <snip>
> ***
> *** SSH host key generation may take a while, please be patient.
> *** If you don't need sshd(8), you can skip this with Ctrl-C.
> ***
> </snip>

Pop out a patch, and I'll happily add it.

> It would also be extremely nice if ssh_keygen could display
> a progress bar or percent value. But that would have to be
> done by the OpenSSH folks, of course, not DragonFly.

Something to suggest on , perhaps. If you
supply a patch there, too, the OpenSSH developers may be more receptive.

#14 Updated by joerg over 8 years ago

On Wed, Apr 12, 2006 at 11:51:23AM +0000, Oliver Fromme wrote:
> Howeven, I was rather thinking about adding one or two echo
> commands to the script. Something along the lines:
> <snip>
> ***
> *** SSH host key generation may take a while, please be patient.
> *** If you don't need sshd(8), you can skip this with Ctrl-C.
> ***
> </snip>

I prefer that to running it in the background. It might help to run a
"find /" or so in the background though.

Joerg

#15 Updated by dillon over 8 years ago

:...
:It would also be extremely nice if ssh_keygen could display
:a progress bar or percent value. But that would have to be
:done by the OpenSSH folks, of course, not DragonFly.
:
: > Do you know if needs 29 minutes of CPU time, or does it just have to
: > wait so long until all neccessary entropy has been gathered? Maybe
: > there is still a but in entropy gathering somewhere.
:
:I'm pretty sure it needs 29 minutes of CPU time. Most of
:the time was spent generating the DSA key. The RSA key was
:much quicker, maybe half a minute (I didn't measure).
:The CPU was 100% busy while generating the keys.
:
:On a faster machine the whole process took considerably
:less time; about 1 minute. But that's still a long pause
:during boot which can give users (especially newbies) an
:uneasy feeling.
:
:(Just my 2 cents.)
:
:Best regards
: Oliver
:
:--
:Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing

It shouldn't take that long even on a slow machine. It only takes
10 seconds or so on my test boxes (though those are fast boxes).
Even on a really slow machine it shouldn't take more then 30 seconds
or so. I'm somewhat at a loss.

In anycase, backgrounding the key generation would be fine. That
code was originally put in so people wanting to get a network link
up and ssh into the machine could do so quickly with only two edits,
and not have to deal with key generation.

-Matt
Matthew Dillon
<>

#16 Updated by justin over 8 years ago

On Thu, April 13, 2006 1:15 pm, Matthew Dillon wrote:

> :On a faster machine the whole process took considerably
> :less time; about 1 minute. But that's still a long pause
> :during boot which can give users (especially newbies) an
> :uneasy feeling.

> It shouldn't take that long even on a slow machine. It only takes
> 10 seconds or so on my test boxes (though those are fast boxes).
> Even on a really slow machine it shouldn't take more then 30 seconds
> or so. I'm somewhat at a loss.

If I recall the original thread correctly, these machines taking a long
time were emulated.

#17 Updated by dillon over 8 years ago

:
:On Thu, April 13, 2006 1:15 pm, Matthew Dillon wrote:
:
:> :On a faster machine the whole process took considerably
:> :less time; about 1 minute. But that's still a long pause
:> :during boot which can give users (especially newbies) an
:> :uneasy feeling.
:
:> It shouldn't take that long even on a slow machine. It only takes
:> 10 seconds or so on my test boxes (though those are fast boxes).
:> Even on a really slow machine it shouldn't take more then 30 seconds
:> or so. I'm somewhat at a loss.
:
:If I recall the original thread correctly, these machines taking a long
:time were emulated.

Ahhhh. Now that makes more sense. I guess '^C' is reasonable in
that case.

-Matt
Matthew Dillon
<>

#18 Updated by swildner over 5 years ago

I'll look at this.

#19 Updated by swildner over 5 years ago

I am unable to reproduce this bug. Time zone selection from the installer works
fine here, using the steps from the original report.

Assume the issue was fixed in the meantime.

Also available in: Atom PDF