Max grabbed the journal (attached), which explains what's going on:
openssh-server is not already installed, the first boot installs it. But
this happens in /etc/rc.local, which we run fairly early (right after
the network is up). In the journal we see roughly this order:
784:Apr 08 13:52:27 utah
So, originally I assumed this meant that ssh wasn't running right after
"apt-get install openssh-server". But you are saying that it does not
work after the first *boot*? Otherwise having these VMs and booting them
would not be useful for debugging anything.
So the expectation is that booting max-
I now ssh'ed in with -X and dropped -nographic. Painfully slow, and the
screen is weirdly condensed, but this works in principle. What is the
password for the UTAH user? I tried "utah", "UTAH", "ubuntu", and empty,
but no luck..
--
You received this bug notification because you are a member of Ub
Sorry, but through ssh -X it is just impossible to type (a lot of
characters get repeated 10 times, and others dropped, even if I just
type one char every 5 seconds), and the mouse is also useless. How do
you interact with these VMs?
--
You received this bug notification because you are a member
Ah, I can log in with upgrade-tester@. How do you launch these VMs? I
tried
$ qemu-system-x86_64 -enable-kvm -m 2048 -drive file=./max-ssh-recreate-
base-clone.qcow2,if=virtio -snapshot -nographic
but I don't see a thing because apparently these VMs don't have
console=ttyS0. I suppose everything
Sorry, upgrade-tester is the user, I mistyped it before.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1554266
Title:
sshd does not start on newly installed desktop system
To manage notifications a
Note: When running this kind of VM images, always run qemu with
-snapshot to not modify the image. This will create an internal
transient overlay for the given image and leave it untouched.
For me, ssh venonat.ubuntu-ci fails as ubuntu@, pitti@, and root@, which
user name did you use?
--
You rec
I've created some VMs to recreate this on venonat.ubuntu-ci (accessible
via the vpn.) The user is upgrade-test, and I've added ssh keys for
pitti and cyphermox. The problem only occurs on the first boot, so once
we start a VM, we'll need to clone another if we want to recreate again.
As such, pleas
If I use the default server preseed:
lp:ubuntu-test-cases/server/preseeds/default.preseed
it starts ssh on server images, but not on desktop images.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/155426
My attempts at manual recreation so far have failed. I'm going to see if
I can narrow down what potential elements of a preseed might be causing
this.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1554
The actual command running on venonat under jenkins is this:
sudo -u utah -i
UTAH_CONFIG_DIR=/var/lib/jenkins-utah-iso/workspace/ubuntu-xenial-desktop-amd64-smoke-default/config
run_utah_tests.py -i /var/cache/utah/iso/xenial-desktop-amd64.iso -p
lp:ubuntu-test-cases/desktop/preseeds/default.cfg
Are there any steps how this can be reproduced? I already tried on a
cloud image and on a desktop, Mathieu tried with pre-seeding, etc. A
reproduction recipe based on downloading a current image would be most
helpful here to understand what's going on here.
** Changed in: openssh (Ubuntu)
S
If we enable oem config in the preseed, this problem doesn't occur.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1554266
Title:
sshd does not start on newly installed desktop system
To manage noti
I've confirmed that openssh-server is installed on the system, and can
be started manually after the first reboot. I previously saw that it
started automatically after the second reboot, but I haven't confirmed
that this week.
--
You received this bug notification because you are a member of Ubun
This is blocking current image promotions. Is there something I can do
to provide more data for getting it fixed?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1554266
Title:
sshd does not start on
FWIW, this doesn't happen on current server installs, just desktop.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1554266
Title:
sshd does not start on newly installed desktop system
To manage noti
I re-ran this job:
https://platform-qa-jenkins.ubuntu.com/view/smoke-default/job/ubuntu-xenial-desktop-amd64-smoke-default/
It installs from the daily iso using utah. It uses a preseed here:
http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/desktop/view/head:/preseeds/default.cfg
I tried to purge and reinstall openssh-server on today's cloud image
(with i-s-h 1.29ubuntu1) and ssh.service does start up right away as
expected. So this naïve reproducer doesn't work. Max, how does openssh-
server get installed in your case? Sorry for my ignorance, I don't know
much about presee
Can I pin i-s-h during install or is there some other way I can help
verify this?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1554266
Title:
sshd does not start on newly installed desktop system
IRC speculation is that this might be due to
https://launchpad.net/ubuntu/+source/init-system-helpers/1.29ubuntu1,
although that isn't enough to determine whether it's a regression in
i-s-h or something that openssh is doing wrong that was just exposed by
that upload.
--
You received this bug not
20 matches
Mail list logo