| 2019-04-10 19:38:14 |
Robert C Jennings |
bug |
|
|
added bug |
| 2019-04-10 19:41:09 |
Robert C Jennings |
attachment added |
|
journal https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1824227/+attachment/5254776/+files/journal |
|
| 2019-04-10 19:43:39 |
Steve Langasek |
console-setup (Ubuntu): importance |
Undecided |
High |
|
| 2019-04-10 19:43:42 |
Steve Langasek |
console-setup (Ubuntu): status |
New |
Triaged |
|
| 2019-04-10 19:43:57 |
Steve Langasek |
nominated for series |
|
Ubuntu Disco |
|
| 2019-04-10 19:43:57 |
Steve Langasek |
bug task added |
|
console-setup (Ubuntu Disco) |
|
| 2019-04-10 19:43:57 |
Steve Langasek |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-04-10 19:43:57 |
Steve Langasek |
bug task added |
|
console-setup (Ubuntu Bionic) |
|
| 2019-04-10 19:43:57 |
Steve Langasek |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-04-10 19:43:57 |
Steve Langasek |
bug task added |
|
console-setup (Ubuntu Cosmic) |
|
| 2019-04-10 19:44:12 |
Steve Langasek |
console-setup (Ubuntu Bionic): status |
New |
Triaged |
|
| 2019-04-10 19:44:15 |
Steve Langasek |
console-setup (Ubuntu Bionic): importance |
Undecided |
High |
|
| 2019-04-10 19:44:19 |
Steve Langasek |
console-setup (Ubuntu Cosmic): status |
New |
Triaged |
|
| 2019-04-10 19:44:21 |
Steve Langasek |
console-setup (Ubuntu Cosmic): importance |
Undecided |
High |
|
| 2019-04-10 19:55:02 |
Steve Langasek |
console-setup (Ubuntu Disco): status |
Triaged |
Fix Committed |
|
| 2019-04-10 19:55:05 |
Steve Langasek |
console-setup (Ubuntu Disco): assignee |
|
Steve Langasek (vorlon) |
|
| 2019-04-10 20:01:48 |
Steve Langasek |
description |
I'm seeing a console-setup.service failure quite regularly in testing
where the temp file that should have been created can't be found.
This is a regular xenial cloud image.
19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
...
19:51:13 systemd[1]: Starting Set console font and keymap...
19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file
19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
19:51:15 systemd[1]: Failed to start Set console font and keymap.
19:51:15 systemd[1]: console-setup.service: Unit entered failed state.
19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'.
...
/bin/setupcon has a lovely tempfile function that looks like:
if \
TMPFILE=`mktemp /tmp/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /run/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /dev/.tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp 2>/dev/null`
Here's our edited IRC conversation on the bug:
<@vorlon> so I do think you're being hit by the tmp cleaner
<@vorlon> also this seems like bad pathological default behavior for
the tmp cleaner, to delete files that have just been created
<@vorlon> but we should fix console-setup to not rely on /tmp
<@vorlon> and I prefer that we do that instead of trying to fiddle with
the ordering of the systemd units on startup
<@vorlon> i.e. console-setup has an undeclared dependency
on systemd-tmpfiles-clean; let's remove the dependency
instead of declaring it
<@vorlon> are you failing the race more often now than in the past?
<@rcj> vorlon: it feels like it's failing more often but I don't have
data to answer that.
<@vorlon> are we shipping an image with a dirty rootfs?
<@vorlon> dirty in the sense that e2fsck doesn't take one look at it,
say "yep, nothing to do here" and exit
<@vorlon> in the sense that this is what would make dev-sda1.device slow
to complete AIUI
<@rcj> would filesystem resize on first boot mark it dirty? Because
that will happen
<@vorlon> huh good question
<@vorlon> it might
<xnox> rcj, unclean shutdown?
<@rcj> xnox: first boot
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: console-setup 1.108ubuntu15.4
ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18
Uname: Linux 4.15.0-1029-gcp x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 19:24:12 2019
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: console-setup
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU Justification]
I'm seeing a console-setup.service failure quite regularly in testing
where the temp file that should have been created can't be found.
This is a regular xenial cloud image.
19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
...
19:51:13 systemd[1]: Starting Set console font and keymap...
19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file
19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
19:51:15 systemd[1]: Failed to start Set console font and keymap.
19:51:15 systemd[1]: console-setup.service: Unit entered failed state.
19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'.
...
/bin/setupcon has a lovely tempfile function that looks like:
if \
TMPFILE=`mktemp /tmp/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /run/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /dev/.tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp 2>/dev/null`
Here's our edited IRC conversation on the bug:
<@vorlon> so I do think you're being hit by the tmp cleaner
<@vorlon> also this seems like bad pathological default behavior for
the tmp cleaner, to delete files that have just been created
<@vorlon> but we should fix console-setup to not rely on /tmp
<@vorlon> and I prefer that we do that instead of trying to fiddle with
the ordering of the systemd units on startup
<@vorlon> i.e. console-setup has an undeclared dependency
on systemd-tmpfiles-clean; let's remove the dependency
instead of declaring it
<@vorlon> are you failing the race more often now than in the past?
<@rcj> vorlon: it feels like it's failing more often but I don't have
data to answer that.
<@vorlon> are we shipping an image with a dirty rootfs?
<@vorlon> dirty in the sense that e2fsck doesn't take one look at it,
say "yep, nothing to do here" and exit
<@vorlon> in the sense that this is what would make dev-sda1.device slow
to complete AIUI
<@rcj> would filesystem resize on first boot mark it dirty? Because
that will happen
<@vorlon> huh good question
<@vorlon> it might
<xnox> rcj, unclean shutdown?
<@rcj> xnox: first boot
[Test case]
1. Install console-setup from -proposed
2. Reboot
3. Verify that `systemctl status console-setup` shows that the service has completed successfully.
Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE.
[Regression potential]
None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: console-setup 1.108ubuntu15.4
ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18
Uname: Linux 4.15.0-1029-gcp x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 19:24:12 2019
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: console-setup
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2019-04-10 20:01:55 |
Steve Langasek |
nominated for series |
|
Ubuntu Xenial |
|
| 2019-04-10 20:01:55 |
Steve Langasek |
bug task added |
|
console-setup (Ubuntu Xenial) |
|
| 2019-04-10 20:05:57 |
Steve Langasek |
description |
[SRU Justification]
I'm seeing a console-setup.service failure quite regularly in testing
where the temp file that should have been created can't be found.
This is a regular xenial cloud image.
19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
...
19:51:13 systemd[1]: Starting Set console font and keymap...
19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file
19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
19:51:15 systemd[1]: Failed to start Set console font and keymap.
19:51:15 systemd[1]: console-setup.service: Unit entered failed state.
19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'.
...
/bin/setupcon has a lovely tempfile function that looks like:
if \
TMPFILE=`mktemp /tmp/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /run/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /dev/.tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp 2>/dev/null`
Here's our edited IRC conversation on the bug:
<@vorlon> so I do think you're being hit by the tmp cleaner
<@vorlon> also this seems like bad pathological default behavior for
the tmp cleaner, to delete files that have just been created
<@vorlon> but we should fix console-setup to not rely on /tmp
<@vorlon> and I prefer that we do that instead of trying to fiddle with
the ordering of the systemd units on startup
<@vorlon> i.e. console-setup has an undeclared dependency
on systemd-tmpfiles-clean; let's remove the dependency
instead of declaring it
<@vorlon> are you failing the race more often now than in the past?
<@rcj> vorlon: it feels like it's failing more often but I don't have
data to answer that.
<@vorlon> are we shipping an image with a dirty rootfs?
<@vorlon> dirty in the sense that e2fsck doesn't take one look at it,
say "yep, nothing to do here" and exit
<@vorlon> in the sense that this is what would make dev-sda1.device slow
to complete AIUI
<@rcj> would filesystem resize on first boot mark it dirty? Because
that will happen
<@vorlon> huh good question
<@vorlon> it might
<xnox> rcj, unclean shutdown?
<@rcj> xnox: first boot
[Test case]
1. Install console-setup from -proposed
2. Reboot
3. Verify that `systemctl status console-setup` shows that the service has completed successfully.
Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE.
[Regression potential]
None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: console-setup 1.108ubuntu15.4
ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18
Uname: Linux 4.15.0-1029-gcp x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 19:24:12 2019
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: console-setup
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU Justification]
I'm seeing a console-setup.service failure quite regularly in testing
where the temp file that should have been created can't be found.
This is a regular xenial cloud image.
19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
...
19:51:13 systemd[1]: Starting Set console font and keymap...
19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file
19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
19:51:15 systemd[1]: Failed to start Set console font and keymap.
19:51:15 systemd[1]: console-setup.service: Unit entered failed state.
19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'.
...
/bin/setupcon has a lovely tempfile function that looks like:
if \
TMPFILE=`mktemp /tmp/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /run/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /dev/.tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp 2>/dev/null`
Here's our edited IRC conversation on the bug:
<@vorlon> so I do think you're being hit by the tmp cleaner
<@vorlon> also this seems like bad pathological default behavior for
the tmp cleaner, to delete files that have just been created
<@vorlon> but we should fix console-setup to not rely on /tmp
<@vorlon> and I prefer that we do that instead of trying to fiddle with
the ordering of the systemd units on startup
<@vorlon> i.e. console-setup has an undeclared dependency
on systemd-tmpfiles-clean; let's remove the dependency
instead of declaring it
<@vorlon> are you failing the race more often now than in the past?
<@rcj> vorlon: it feels like it's failing more often but I don't have
data to answer that.
<@vorlon> are we shipping an image with a dirty rootfs?
<@vorlon> dirty in the sense that e2fsck doesn't take one look at it,
say "yep, nothing to do here" and exit
<@vorlon> in the sense that this is what would make dev-sda1.device slow
to complete AIUI
<@rcj> would filesystem resize on first boot mark it dirty? Because
that will happen
<@vorlon> huh good question
<@vorlon> it might
<xnox> rcj, unclean shutdown?
<@rcj> xnox: first boot
[Test case]
1. Install console-setup from -proposed
2. Reboot
3. Verify that `systemctl status console-setup` shows that the service has completed successfully.
Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE.
[Regression potential]
None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount.
This could cause a regression if setupcon is run as a user who has permissions to modify consoles but does not have permission to write to /run. This is a stretch, since consoles are generally expected to be managed only by the root user.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: console-setup 1.108ubuntu15.4
ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18
Uname: Linux 4.15.0-1029-gcp x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 19:24:12 2019
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: console-setup
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2019-04-10 20:07:31 |
Steve Langasek |
description |
[SRU Justification]
I'm seeing a console-setup.service failure quite regularly in testing
where the temp file that should have been created can't be found.
This is a regular xenial cloud image.
19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
...
19:51:13 systemd[1]: Starting Set console font and keymap...
19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file
19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
19:51:15 systemd[1]: Failed to start Set console font and keymap.
19:51:15 systemd[1]: console-setup.service: Unit entered failed state.
19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'.
...
/bin/setupcon has a lovely tempfile function that looks like:
if \
TMPFILE=`mktemp /tmp/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /run/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /dev/.tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp 2>/dev/null`
Here's our edited IRC conversation on the bug:
<@vorlon> so I do think you're being hit by the tmp cleaner
<@vorlon> also this seems like bad pathological default behavior for
the tmp cleaner, to delete files that have just been created
<@vorlon> but we should fix console-setup to not rely on /tmp
<@vorlon> and I prefer that we do that instead of trying to fiddle with
the ordering of the systemd units on startup
<@vorlon> i.e. console-setup has an undeclared dependency
on systemd-tmpfiles-clean; let's remove the dependency
instead of declaring it
<@vorlon> are you failing the race more often now than in the past?
<@rcj> vorlon: it feels like it's failing more often but I don't have
data to answer that.
<@vorlon> are we shipping an image with a dirty rootfs?
<@vorlon> dirty in the sense that e2fsck doesn't take one look at it,
say "yep, nothing to do here" and exit
<@vorlon> in the sense that this is what would make dev-sda1.device slow
to complete AIUI
<@rcj> would filesystem resize on first boot mark it dirty? Because
that will happen
<@vorlon> huh good question
<@vorlon> it might
<xnox> rcj, unclean shutdown?
<@rcj> xnox: first boot
[Test case]
1. Install console-setup from -proposed
2. Reboot
3. Verify that `systemctl status console-setup` shows that the service has completed successfully.
Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE.
[Regression potential]
None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount.
This could cause a regression if setupcon is run as a user who has permissions to modify consoles but does not have permission to write to /run. This is a stretch, since consoles are generally expected to be managed only by the root user.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: console-setup 1.108ubuntu15.4
ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18
Uname: Linux 4.15.0-1029-gcp x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 19:24:12 2019
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: console-setup
UpgradeStatus: No upgrade log present (probably fresh install) |
[SRU Justification]
I'm seeing a console-setup.service failure quite regularly in testing
where the temp file that should have been created can't be found.
This is a regular xenial cloud image.
19:51:13 systemd-tmpfiles[485]: [/usr/lib/tmpfiles.d/var.conf:14] Duplicate line for path "/var/log", ignoring.
...
19:51:13 systemd[1]: Starting Set console font and keymap...
19:51:15 setupcon[455]: /bin/setupcon: 809: /bin/setupcon: cannot open /tmp/tmpkbd.a8FGSs: No such file
19:51:15 systemd[1]: console-setup.service: Main process exited, code=exited, status=1/FAILURE
19:51:15 systemd[1]: Failed to start Set console font and keymap.
19:51:15 systemd[1]: console-setup.service: Unit entered failed state.
19:51:15 systemd[1]: console-setup.service: Failed with result 'exit-code'.
...
/bin/setupcon has a lovely tempfile function that looks like:
if \
TMPFILE=`mktemp /tmp/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /run/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /dev/.tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp /lib/init/rw/tmpkbd.XXXXXX 2>/dev/null` \
|| TMPFILE=`mktemp 2>/dev/null`
Here's our edited IRC conversation on the bug:
<@vorlon> so I do think you're being hit by the tmp cleaner
<@vorlon> also this seems like bad pathological default behavior for
the tmp cleaner, to delete files that have just been created
<@vorlon> but we should fix console-setup to not rely on /tmp
<@vorlon> and I prefer that we do that instead of trying to fiddle with
the ordering of the systemd units on startup
<@vorlon> i.e. console-setup has an undeclared dependency
on systemd-tmpfiles-clean; let's remove the dependency
instead of declaring it
<@vorlon> are you failing the race more often now than in the past?
<@rcj> vorlon: it feels like it's failing more often but I don't have
data to answer that.
<@vorlon> are we shipping an image with a dirty rootfs?
<@vorlon> dirty in the sense that e2fsck doesn't take one look at it,
say "yep, nothing to do here" and exit
<@vorlon> in the sense that this is what would make dev-sda1.device slow
to complete AIUI
<@rcj> would filesystem resize on first boot mark it dirty? Because
that will happen
<@vorlon> huh good question
<@vorlon> it might
<xnox> rcj, unclean shutdown?
<@rcj> xnox: first boot
[Test case]
1. Install console-setup from -proposed
2. Reboot
3. Verify that `systemctl status console-setup` shows that the service has completed successfully.
Since this is a race, additional fuzz testing may be warranted for the cloud images to confirm that the issue experienced in GCE is really fixed. However, that should not block promotion of this SRU fix since there definitely is a race here that should be fixed per se even if there are other issues still causing a failure in GCE.
[Regression potential]
None known. /run is guaranteed to be mounted rw very early in boot - generally before /tmp is mounted, due to /tmp being on the rootfs that needs to be fscked before remount.
ProblemType: Bug
DistroRelease: Ubuntu 16.04
Package: console-setup 1.108ubuntu15.4
ProcVersionSignature: User Name 4.15.0-1029.31~16.04.1-gcp 4.15.18
Uname: Linux 4.15.0-1029-gcp x86_64
ApportVersion: 2.20.1-0ubuntu2.18
Architecture: amd64
Date: Wed Apr 10 19:24:12 2019
PackageArchitecture: all
ProcEnviron:
TERM=xterm-256color
PATH=(custom, no user)
XDG_RUNTIME_DIR=<set>
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: console-setup
UpgradeStatus: No upgrade log present (probably fresh install) |
|
| 2019-04-10 20:13:58 |
Steve Langasek |
console-setup (Ubuntu Cosmic): status |
Triaged |
In Progress |
|
| 2019-04-10 20:13:59 |
Steve Langasek |
console-setup (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2019-04-10 20:14:04 |
Steve Langasek |
console-setup (Ubuntu Xenial): status |
New |
In Progress |
|
| 2019-04-10 20:14:55 |
Steve Langasek |
console-setup (Ubuntu Cosmic): assignee |
|
Steve Langasek (vorlon) |
|
| 2019-04-10 20:14:57 |
Steve Langasek |
console-setup (Ubuntu Bionic): assignee |
|
Steve Langasek (vorlon) |
|
| 2019-04-10 20:14:59 |
Steve Langasek |
console-setup (Ubuntu Xenial): assignee |
|
Steve Langasek (vorlon) |
|
| 2019-04-10 20:17:11 |
Steve Langasek |
console-setup (Ubuntu Xenial): importance |
Undecided |
High |
|
| 2019-04-10 21:14:42 |
Brian Murray |
console-setup (Ubuntu Cosmic): status |
In Progress |
Fix Committed |
|
| 2019-04-10 21:14:44 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-04-10 21:14:45 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-04-10 21:14:48 |
Brian Murray |
tags |
amd64 apport-bug uec-images xenial |
amd64 apport-bug uec-images verification-needed verification-needed-cosmic xenial |
|
| 2019-04-10 21:16:11 |
Brian Murray |
console-setup (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-04-10 21:16:17 |
Brian Murray |
tags |
amd64 apport-bug uec-images verification-needed verification-needed-cosmic xenial |
amd64 apport-bug uec-images verification-needed verification-needed-bionic verification-needed-cosmic xenial |
|
| 2019-04-10 21:17:19 |
Brian Murray |
console-setup (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
| 2019-04-10 21:17:26 |
Brian Murray |
tags |
amd64 apport-bug uec-images verification-needed verification-needed-bionic verification-needed-cosmic xenial |
amd64 apport-bug uec-images verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial xenial |
|
| 2019-04-11 09:17:04 |
Launchpad Janitor |
console-setup (Ubuntu Disco): status |
Fix Committed |
Fix Released |
|
| 2019-04-11 12:22:09 |
Francis Ginther |
tags |
amd64 apport-bug uec-images verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial xenial |
amd64 apport-bug id-5caba54405de185b64adc2db uec-images verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial xenial |
|
| 2019-04-11 12:37:32 |
Francis Ginther |
tags |
amd64 apport-bug id-5caba54405de185b64adc2db uec-images verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial xenial |
amd64 apport-bug id-5caba54405de185b64adc2db id-5cae47869ef68677a65c1e71 uec-images verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial xenial |
|
| 2019-04-16 17:31:42 |
Robert C Jennings |
tags |
amd64 apport-bug id-5caba54405de185b64adc2db id-5cae47869ef68677a65c1e71 uec-images verification-needed verification-needed-bionic verification-needed-cosmic verification-needed-xenial xenial |
amd64 apport-bug id-5caba54405de185b64adc2db id-5cae47869ef68677a65c1e71 uec-images verification-done verification-done-bionic verification-done-cosmic verification-done-xenial xenial |
|
| 2019-04-16 17:47:55 |
Launchpad Janitor |
console-setup (Ubuntu Cosmic): status |
Fix Committed |
Fix Released |
|
| 2019-04-16 17:48:00 |
Brian Murray |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
| 2019-04-16 17:48:18 |
Launchpad Janitor |
console-setup (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-04-16 17:50:32 |
Launchpad Janitor |
console-setup (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
