with https://github.com/snapcore/snapd/pull/3130 landed, should this bug
be fix-released or is there desire to actually fix the Go implementation
that snapd uses at some point ? (in which case we probably should let it
open)
--
You received this bug notification because you are a member of
** Project changed: snappy => snapd
** Changed in: snapd (Ubuntu)
Status: New => Triaged
** Changed in: snapd
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
to gather some data i did 16 fresh installs in a row today (freshly
flashed SD for each) and captured the log between the start of the key
generation ("Generate device key") and the finalization ("System
seeded") ... http://paste.ubuntu.com/24312862/ has the captured raw data
...
in average the
http://paste.ubuntu.com/24307672/ has the log output of a test of the above
image on a pi3 ...
(with manually added rng_core.default_quality=700 to cmdline.txt in system-boot
before the first boot)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is
in case anyone wants to test:
http://people.canonical.com/~ogra/snappy/all-snaps/ssh-keygen-test/
has images for pi2, pi3 and beaglebone black with
https://github.com/snapcore/snapd/pull/3130 included in snapd
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
ssh-keygen is about 5.5 times faster than that genkey.go program on my
laptop too (it's just that the times are much smaller, obviously). AIUI,
generating an RSA key ends up benchmarking montgomery multiplication,
and I know there are SIMD tricks you can use for that. Go doesn't seem
to be using
using https://github.com/tmc/genkey/blob/master/genkey.go i see similar
slowness ...
right after boot a key generation (with 4096 bits like used in snapd) takes
between 3-5 min.
doing a 25 run loop like in http://paste.ubuntu.com/24260311/ gets me runs
between 12sec and 7min ... with an
@seth: this is with an entropy of above 900 using the
rng_core.default_quality=700 kernel boot option. even if i let the board
sit for a while before hitting enter to run console-conf the builtin key
generation never goes below 3min while the ssh-keygen run is always fast
(it goes down to 15-20sec
How much time had elapsed between the user.creation step and the manual
run of ssh-keygen? Perhaps the ssh-keygen just ran quickly because the
kernel had already accumulated enough entropy.
Do these keys need to be 4096 bit RSA keys? curve25519 ecc keys are
vastly smaller, faster to generate, and
one obvious workaround would indeed be to make snapd call out to ssh-
keygen to have it handle the key generation ... if the security team
does not see any drawbacks with this
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
we have been doing various test runs ... adding
rng_core.default_quality=700 to teh commandline on pi and dragonboard
gives a much greater entropy on boot:
$ cat /proc/sys/kernel/random/entropy_avail
958
but the user.creation step in console-conf still hangs for 3min doing
the device key
A default image on firstboot doesn't have a lot of tools available, and
I'm not sure how to modify that at image-build time... so I have only
very limited information about what exactly it's doing. It might not be
key generation after all though...
I don't recall seeing it for a while, but
What kind of device key is being constructed? For what purpose? Do the
machines have suitable randomness at boot? Are there hardware sources of
entropy that aren't feeding into the kernel's randomness pool? Where's
the slowdown?
Thanks
--
You received this bug notification because you are a
Until the device key is generated there is nothing it _can_ do (in fact
it might not even be listening to requests yet; not sure offhand). That
said, on the pi2 it takes a little over a minute to do the keygen (and
that's too long, but not much we can do about it without better hardware
support
I'm not sure if it's the same issue, but I tend to get a delay of ~8
minutes on a dragonboard on first boot. I'm booting an image with a
system-user assertion, not using the console at all.
On first boot, the system creates a new user, I confirm that ssh works,
then log in and try to run "snap
>From the moment I entered my SSO email and hit "go" to the moment it
returned telling me how to SSH in was about 7 minutes on the
dragonboard.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1638537
I see this as well on various arm based devices. Any more ideas what
could be the reason or a possible fix?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1638537
Title:
snapd eats 100% CPU for
17 matches
Mail list logo
