DragonFlyBSD

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

joerg@britannica.bec.de 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

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

[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.

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ž

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

On Tue, April 11, 2006 2:32 pm, Simon 'corecode' Schubert wrote:

On 11.04.2006, at 20:01, Toma Bortnar 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.

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

joerg@britannica.bec.de 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

rg_monde@yahoo.fr 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

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

Simon 'corecode' Schubert <corecode@fs.ei.tum.de> 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.

• 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

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 openssh-unix-dev@mindrot.org, perhaps. If you
supply a patch there, too, the OpenSSH developers may be more receptive.

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

:...
: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 
                    <dillon@backplane.com>

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.

:
: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 
                    <dillon@backplane.com>

I'll look at this.

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.