[Touch-packages] [Bug 1734395] [NEW] mkfs.ext4dev unrecognised file system

[Paul Graydon]

Public bug reported:

This is probably a bit of a daft one, and it's not blocking me on
anything, but I see this more as a UX bug.

mkfs.ext4dev creates a file system that mount then can't mount, unless
it is told explicitly that it is ext4.

(on a side note, what is ext4dev?  Can't seem to find a solid answer)


$ sudo mkfs.ext4dev /dev/sdb
mke2fs 1.42.13 (17-May-2015)
/dev/sdb contains a ext4 file system
last mounted on Fri Nov 24 22:40:41 2017
Proceed anyway? (y,n) y
Creating filesystem with 268435456 4k blocks and 67108864 inodes
Filesystem UUID: d5dcc961-f34e-4f59-b0f5-f58ea75dc817
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968,
10240, 214990848

Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

$ sudo mount /dev/sdb mount
mount: unknown filesystem type 'ext4dev'

$ sudo mount -t ext4 mount
$
/dev/sdb on /home/ubuntu/mount type ext4 (rw,relatime,data=ordered)


doing a normal mkfs.ext4 works perfectly fine, as you'd expect.

Version: Ubuntu 16.04
Package: e2fsprogs 1.42.13-1ubuntu1

** Affects: e2fsprogs (Ubuntu)
 Importance: Undecided
 Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to e2fsprogs in Ubuntu.
https://bugs.launchpad.net/bugs/1734395

Title:
  mkfs.ext4dev unrecognised file system

Status in e2fsprogs package in Ubuntu:
  New

Bug description:
  This is probably a bit of a daft one, and it's not blocking me on
  anything, but I see this more as a UX bug.

  mkfs.ext4dev creates a file system that mount then can't mount, unless
  it is told explicitly that it is ext4.

  (on a side note, what is ext4dev?  Can't seem to find a solid answer)

  
  $ sudo mkfs.ext4dev /dev/sdb
  mke2fs 1.42.13 (17-May-2015)
  /dev/sdb contains a ext4 file system
  last mounted on Fri Nov 24 22:40:41 2017
  Proceed anyway? (y,n) y
  Creating filesystem with 268435456 4k blocks and 67108864 inodes
  Filesystem UUID: d5dcc961-f34e-4f59-b0f5-f58ea75dc817
  Superblock backups stored on blocks:
  32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 
2654208,
  4096000, 7962624, 11239424, 2048, 23887872, 71663616, 78675968,
  10240, 214990848

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (32768 blocks): done
  Writing superblocks and filesystem accounting information: done

  $ sudo mount /dev/sdb mount
  mount: unknown filesystem type 'ext4dev'

  $ sudo mount -t ext4 mount
  $
  /dev/sdb on /home/ubuntu/mount type ext4 (rw,relatime,data=ordered)

  
  doing a normal mkfs.ext4 works perfectly fine, as you'd expect.

  Version: Ubuntu 16.04
  Package: e2fsprogs 1.42.13-1ubuntu1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1734395/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response

[Paul Graydon]

That would be a different bug, unfortunately.

Mine was specifically down to ipconfig not handling multiple network
interfaces correctly, triaged and successfully fixed by Canonical, and
exhaustively validated in our infrastructure.

Roughly speaking, it would quickly loop through the interfaces sending
out DHCP requests, and then listen on all for the responses, but it was
only able to track the request for one interface, which was whatever the
last interface it sent the request out of.  There's a session id
associated with it, and if that didn't match it would drop the packets.

Booting became dependent on the order of network interfaces returned by
the kernel, something that isn't guaranteed in any way, and explains why
it was working with some kernels and not with others, as it would only
work if the one interface that got DHCP responses was the last one
returned by the kernel.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1652348

Title:
  initrd dhcp fails / ignores valid response

Status in klibc package in Ubuntu:
  Fix Released
Status in klibc source package in Xenial:
  Fix Released
Status in klibc source package in Yakkety:
  Fix Committed

Bug description:
  [SRU justification]
  Changes to ordering of kernel enumeration of network interfaces, which may 
happen in any release, can regress network configuration from an initramfs.  
Support for netbooting should not depend on interface order, it should work 
reliably on all systems.

  [Test case]
  Detailed reproducer described in 
  .

  [Regression potential]
  Moderate regression potential, because of a relatively large patch touching a 
not-widely-used but still critical piece of code.  Regression testing should 
include verifying that MAAS-booted cloud images still work as expected in a 
variety of environments.

  
  Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced 
that is breaking dhcp booting in the initrd environment.  This is stopping 
instances that use iscsi storage from being able to connect.

  Over serial console it outputs:

  IP-Config: no response after 2 secs - giving up
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
  IP-Config: no response after 3 secs - giving up

  with increasing delays until it fails.  At which point a simple
  ipconfig -t dhcp -d "ens2f0"  works.  The console output is slightly
  garbled but should give you an idea:

  (initramfs) ipconfig -t dhcp -[  728.379793] ixgbe :13:00.0 ens2f0: 
changing MTU from 1500 to 9000
  d "ens2f0"
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f0 guessed broadcast address 10.0.1.255
  IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
   addres[  728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3
  s: 10.0.1.56broadcast: 10.0.1.255   netmask: 255.255.255.0
   gateway: 10.0.1.1   [  729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 
10 Gbps, Flow Control: RX/TX
    dns0 : 169.254.169.254  dns1   : 0.0.0.0
   rootserver: 169.254.169.254 rootpath:
   filename  : /ipxe.efi

  tcpdumps show that dhcp requests are being received from the host, and
  responses sent, but not accepted by the host.  When the ipconfig
  command is issued manually, an identical dhcp request and response
  happens, only this time it is accepted.  It doesn't appear to be that
  the messages are being sent and received incorrectly, just silently
  ignored by ipconfig.

  I was seeing this behaviour earlier this year, which I was able to fix
  by specifying "ip=dhcp" as a kernel parameter.  About a month ago that
  was identified as causing us other problems (long story) and we
  dropped it, at which point we discovered the original bug was no
  longer an issue.

  Putting "ip=dhcp" back on with this kernel no longer fixes the
  problem.

  I've compared the two initrds and effectively the only thing that has
  changed between the two is the kernel components.

  Ubuntu kernel bisect offending commit:
  # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per 
mount namespace limit on the number of mounts

  Ubuntu kernel bisect offending commit submission:
  https://lkml.org/lkml/2016/10/5/308

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response

[Paul Graydon]

Note: I've also discovered (unsurprisingly, I guess?) that I see the
exact same behaviour on Ubuntu 14.04.  Can this fix be backported?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1652348

Title:
  initrd dhcp fails / ignores valid response

Status in klibc package in Ubuntu:
  Fix Released
Status in klibc source package in Xenial:
  Fix Released
Status in klibc source package in Yakkety:
  Fix Committed

Bug description:
  [SRU justification]
  Changes to ordering of kernel enumeration of network interfaces, which may 
happen in any release, can regress network configuration from an initramfs.  
Support for netbooting should not depend on interface order, it should work 
reliably on all systems.

  [Test case]
  Detailed reproducer described in 
  .

  [Regression potential]
  Moderate regression potential, because of a relatively large patch touching a 
not-widely-used but still critical piece of code.  Regression testing should 
include verifying that MAAS-booted cloud images still work as expected in a 
variety of environments.

  
  Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced 
that is breaking dhcp booting in the initrd environment.  This is stopping 
instances that use iscsi storage from being able to connect.

  Over serial console it outputs:

  IP-Config: no response after 2 secs - giving up
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
  IP-Config: no response after 3 secs - giving up

  with increasing delays until it fails.  At which point a simple
  ipconfig -t dhcp -d "ens2f0"  works.  The console output is slightly
  garbled but should give you an idea:

  (initramfs) ipconfig -t dhcp -[  728.379793] ixgbe :13:00.0 ens2f0: 
changing MTU from 1500 to 9000
  d "ens2f0"
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f0 guessed broadcast address 10.0.1.255
  IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
   addres[  728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3
  s: 10.0.1.56broadcast: 10.0.1.255   netmask: 255.255.255.0
   gateway: 10.0.1.1   [  729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 
10 Gbps, Flow Control: RX/TX
    dns0 : 169.254.169.254  dns1   : 0.0.0.0
   rootserver: 169.254.169.254 rootpath:
   filename  : /ipxe.efi

  tcpdumps show that dhcp requests are being received from the host, and
  responses sent, but not accepted by the host.  When the ipconfig
  command is issued manually, an identical dhcp request and response
  happens, only this time it is accepted.  It doesn't appear to be that
  the messages are being sent and received incorrectly, just silently
  ignored by ipconfig.

  I was seeing this behaviour earlier this year, which I was able to fix
  by specifying "ip=dhcp" as a kernel parameter.  About a month ago that
  was identified as causing us other problems (long story) and we
  dropped it, at which point we discovered the original bug was no
  longer an issue.

  Putting "ip=dhcp" back on with this kernel no longer fixes the
  problem.

  I've compared the two initrds and effectively the only thing that has
  changed between the two is the kernel components.

  Ubuntu kernel bisect offending commit:
  # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per 
mount namespace limit on the number of mounts

  Ubuntu kernel bisect offending commit submission:
  https://lkml.org/lkml/2016/10/5/308

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response

[Paul Graydon]

I've tested and confirmed that this solves the issue on 16.04

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1652348

Title:
  initrd dhcp fails / ignores valid response

Status in klibc package in Ubuntu:
  Fix Released
Status in klibc source package in Xenial:
  Fix Committed
Status in klibc source package in Yakkety:
  Fix Committed

Bug description:
  [SRU justification]
  Changes to ordering of kernel enumeration of network interfaces, which may 
happen in any release, can regress network configuration from an initramfs.  
Support for netbooting should not depend on interface order, it should work 
reliably on all systems.

  [Test case]
  Detailed reproducer described in 
  .

  [Regression potential]
  Moderate regression potential, because of a relatively large patch touching a 
not-widely-used but still critical piece of code.  Regression testing should 
include verifying that MAAS-booted cloud images still work as expected in a 
variety of environments.

  
  Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced 
that is breaking dhcp booting in the initrd environment.  This is stopping 
instances that use iscsi storage from being able to connect.

  Over serial console it outputs:

  IP-Config: no response after 2 secs - giving up
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
  IP-Config: no response after 3 secs - giving up

  with increasing delays until it fails.  At which point a simple
  ipconfig -t dhcp -d "ens2f0"  works.  The console output is slightly
  garbled but should give you an idea:

  (initramfs) ipconfig -t dhcp -[  728.379793] ixgbe :13:00.0 ens2f0: 
changing MTU from 1500 to 9000
  d "ens2f0"
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f0 guessed broadcast address 10.0.1.255
  IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
   addres[  728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3
  s: 10.0.1.56broadcast: 10.0.1.255   netmask: 255.255.255.0
   gateway: 10.0.1.1   [  729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 
10 Gbps, Flow Control: RX/TX
    dns0 : 169.254.169.254  dns1   : 0.0.0.0
   rootserver: 169.254.169.254 rootpath:
   filename  : /ipxe.efi

  tcpdumps show that dhcp requests are being received from the host, and
  responses sent, but not accepted by the host.  When the ipconfig
  command is issued manually, an identical dhcp request and response
  happens, only this time it is accepted.  It doesn't appear to be that
  the messages are being sent and received incorrectly, just silently
  ignored by ipconfig.

  I was seeing this behaviour earlier this year, which I was able to fix
  by specifying "ip=dhcp" as a kernel parameter.  About a month ago that
  was identified as causing us other problems (long story) and we
  dropped it, at which point we discovered the original bug was no
  longer an issue.

  Putting "ip=dhcp" back on with this kernel no longer fixes the
  problem.

  I've compared the two initrds and effectively the only thing that has
  changed between the two is the kernel components.

  Ubuntu kernel bisect offending commit:
  # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per 
mount namespace limit on the number of mounts

  Ubuntu kernel bisect offending commit submission:
  https://lkml.org/lkml/2016/10/5/308

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1652348] Re: initrd dhcp fails / ignores valid response

[Paul Graydon]

Given this is a fundamental bug in klibc, is there a plan to try to
upstream this patch?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to klibc in Ubuntu.
https://bugs.launchpad.net/bugs/1652348

Title:
  initrd dhcp fails / ignores valid response

Status in klibc package in Ubuntu:
  Fix Released
Status in klibc source package in Xenial:
  Triaged

Bug description:
  [SRU justification]
  Changes to ordering of kernel enumeration of network interfaces, which may 
happen in any release, can regress network configuration from an initramfs.  
Support for netbooting should not depend on interface order, it should work 
reliably on all systems.

  [Test case]
  Detailed reproducer described in 
  .

  [Regression potential]
  Moderate regression potential, because of a relatively large patch touching a 
not-widely-used but still critical piece of code.  Regression testing should 
include verifying that MAAS-booted cloud images still work as expected in a 
variety of environments.

  
  Between kernel versions 4.4.0-53 and 4.4.0-57 a bug has been (re?)introduced 
that is breaking dhcp booting in the initrd environment.  This is stopping 
instances that use iscsi storage from being able to connect.

  Over serial console it outputs:

  IP-Config: no response after 2 secs - giving up
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f1 hardware address 90:e2:ba:d1:36:39 mtu 1500 DHCP RARP
  IP-Config: no response after 3 secs - giving up

  with increasing delays until it fails.  At which point a simple
  ipconfig -t dhcp -d "ens2f0"  works.  The console output is slightly
  garbled but should give you an idea:

  (initramfs) ipconfig -t dhcp -[  728.379793] ixgbe :13:00.0 ens2f0: 
changing MTU from 1500 to 9000
  d "ens2f0"
  IP-Config: ens2f0 hardware address 90:e2:ba:d1:36:38 mtu 1500 DHCP RARP
  IP-Config: ens2f0 guessed broadcast address 10.0.1.255
  IP-Config: ens2f0 complete (dhcp from 169.254.169.254):
   addres[  728.980448] ixgbe :13:00.0 ens2f0: detected SFP+: 3
  s: 10.0.1.56broadcast: 10.0.1.255   netmask: 255.255.255.0
   gateway: 10.0.1.1   [  729.148410] ixgbe :13:00.0 ens2f0: NIC Link is Up 
10 Gbps, Flow Control: RX/TX
    dns0 : 169.254.169.254  dns1   : 0.0.0.0
   rootserver: 169.254.169.254 rootpath:
   filename  : /ipxe.efi

  tcpdumps show that dhcp requests are being received from the host, and
  responses sent, but not accepted by the host.  When the ipconfig
  command is issued manually, an identical dhcp request and response
  happens, only this time it is accepted.  It doesn't appear to be that
  the messages are being sent and received incorrectly, just silently
  ignored by ipconfig.

  I was seeing this behaviour earlier this year, which I was able to fix
  by specifying "ip=dhcp" as a kernel parameter.  About a month ago that
  was identified as causing us other problems (long story) and we
  dropped it, at which point we discovered the original bug was no
  longer an issue.

  Putting "ip=dhcp" back on with this kernel no longer fixes the
  problem.

  I've compared the two initrds and effectively the only thing that has
  changed between the two is the kernel components.

  Ubuntu kernel bisect offending commit:
  # first bad commit: [fd4b5fa6e3487d15ede746f92601af008b2abbc0] mnt: Add a per 
mount namespace limit on the number of mounts

  Ubuntu kernel bisect offending commit submission:
  https://lkml.org/lkml/2016/10/5/308

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1652348/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1629972] Re: networking stop incorrectly disconnects from (network) root filesystem

[Paul Graydon]

I ran into this with iSCSI root.  Installing cloud-init resulted in
problems rebooting.

If I install the ifupdown patch (without cloud-init installed), that
triggers the bug for me.

Spinning up a clean instance, installing cloud-init, letting it run (so
the conditions that cause the bug are triggered), then installing the
ifupdown package also fails to fix the reboot problems.  I've confirmed
this persists after the next boot as well.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to ifupdown in Ubuntu.
https://bugs.launchpad.net/bugs/1629972

Title:
  networking stop incorrectly disconnects from (network) root filesystem

Status in MAAS:
  Triaged
Status in ifupdown package in Ubuntu:
  Confirmed
Status in ifupdown source package in Xenial:
  Confirmed

Bug description:
  With the switch to systemd, all support for iscsi root (and other)
  filesystems disappeared, since shutdown yanks the rug out from under
  us.

  Rather than just relying on /etc/iscsi/iscsi.initramfs (which d-i
  creates..), the DEV check should be expanded to include iscsi devices,
  and networking.service ExecStop should honor those checks.

  Related bugs:
* bug 1229458: grub2 needed changes
* bug 1621615: network not configured when ipv6 netbooted into cloud-init
* bug 1621507: ipv6 network boot does not work

  [Impact]

  With the changes from the above, the iscsi root (at least in the ipv6
  case) gets disconneceted prior to clean shutdown (ifdown downs the
  interface), resulting in a failure to enlist, commission, or deploy
  cleanly under MAAS. (and a failure to cleanly unmount the root
  filesystem when it is over iscsi.)

  [Test Case]

  Given a MAAS 2.0 installation, and the packages in the other bugs,
  attempt to enlist, commission, or deploy a host with xenial.

  [Regression potential]

  This restores the pre-xenial behavior of not shutting down the
  interface if there are network drives at the time that neworking is
  stopped (making it a no-op.)  The additional change is to detect
  "/dev/disk/by-path/*-iscsi-*" as a network disk, replacing the check
  for the existence of /etc/iscsi/iscsi.initramfs, which was only
  created by debian-installer (and maas until recently).

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/1629972/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 496354] Re: amixer doesn't seem to unmute audio

[Paul Graydon]

This one affects me as well.  Muting mutes the master, and headphone and
PCM.  Unmuting only unmutes Master.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to pulseaudio in Ubuntu.
https://bugs.launchpad.net/bugs/496354

Title:
  amixer doesn't seem to unmute audio

Status in pulseaudio package in Ubuntu:
  Confirmed

Bug description:
  Binary package hint: pulseaudio

  When i run
  amixer -Dhw:0 set 'Master' unmute
  The volume appears to be unmuted in alsamixer, but the sound is not actually 
unmuted, and all the GUI tools show the sound is muted. 

  I've attached a log, of the following...
  pressing the mute button on my keyboard, so the sound is muted.
  using the unmute command so the sound should be unmuted.
  playing a sound in pidgin, getting no sound, because the sound is still muted.
  hitting the mute button on my keyboard again, which actually unmutes the 
sound.
  playing a sound in pidgin, and getting sound

  I've also attached a screenshot, showing the GUI saying the sound is
  muted, while alsamixer is saying that it isn't.

  Note that while unmute doesn't work, setting the volume does.
  amixer -Dhw:0 set 'Master' 100%
  Works as expected, for example.

  I'm also affected by #352732, maybe related.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/496354/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 951929] Re: Unity launcher and Alt-Tab switcher missing entry for gnome-terminal

[Paul Graydon]

Can't say for sure if it's a problem any more or not.  I've long since
given up on Unity, in no small part due to this bug.  The response on
the bug report did little to convince me it was worth continuing to use
it either.  A whole bunch of people experiencing it, and the bug just
constantly being punted off to the next milestone.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to unity in Ubuntu.
https://bugs.launchpad.net/bugs/951929

Title:
  Unity launcher and Alt-Tab switcher missing entry for gnome-terminal

Status in Unity:
  Fix Released
Status in unity package in Ubuntu:
  Fix Released

Bug description:
  edit: Updated title, its affecting more than gnome-terminal

  1) Description:   Ubuntu precise (development branch)
  Release:  12.04

  2) unity:
    Installed: 5.4.0-0ubuntu2

  3) Gnome-Terminal to show in list of programs to alt+tab to.

  4)  Alt+Tab consistently fails to show gnome-terminal for 'a while' (I
  hate to be vague, I can't figure out what suddenly triggers it to
  appear in the box).  See attached photograph of it occurring.

  I can make it happen at will:

  1) Cold boot into Ubuntu.
  2) Open gnome-terminal.
  3) Open Firefox.
  4) Press alt+tab.  alt+tab window only shows Desktop and Firefox.

  In attached screenshot, note that gnome-terminal has a highlighted
  background and arrow, indicating an instance of it running, as is
  Firefox.

  ProblemType: Bug
  DistroRelease: Ubuntu 12.04
  Package: unity 5.4.0-0ubuntu2
  ProcVersionSignature: Ubuntu 3.2.0-18.29-generic 3.2.9
  Uname: Linux 3.2.0-18-generic x86_64
  ApportVersion: 1.94.1-0ubuntu2
  Architecture: amd64
  CompizPlugins: 
[core,composite,opengl,compiztoolbox,decor,vpswitch,snap,mousepoll,resize,place,move,wall,grid,regex,imgpng,session,gnomecompat,animation,fade,unitymtgrabhandles,workarounds,scale,expo,ezoom,unityshell]
  Date: Sat Mar 10 14:50:09 2012
  InstallationMedia: Ubuntu 12.04 LTS "Precise Pangolin" - Beta amd64 (20120301)
  ProcEnviron:
   TERM=xterm
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  SourcePackage: unity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/unity/+bug/951929/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp