from:"Francis Ginther"

[Touch-packages] [Bug 1960094] Re: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal

2022-02-08 Thread Francis Ginther

I've retested two released kernels that passed the lxc test last cycle:

* focal/azure 5.4.0-1068.71
* focal/azure-5-11 5.11.0-1028.31~20.04.1

Both tests now show the same testcase failures where they were passing
before. Will start digging into any other changes in the environment.

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

Title:
  lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal

Status in linux package in Ubuntu:
  New
Status in lxc package in Ubuntu:
  Incomplete
Status in linux source package in Focal:
  New
Status in lxc source package in Focal:
  Incomplete

Bug description:
  There are failures in ubuntu_lxc regression tests on Focal/linux/5.4.0-99.112 
sru cycle 2022.01.03 with the error
  lxc-create: symbol lookup error: lxc-create: undefined symbol: strlcat

  These errors did not appear on previous kernels in the same cycle and
  now have a few tests failing on all architectures and systems as of
  Feb 4th 2022 it seems. Log with details is attached in the comments.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1960094/+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 1961800] [NEW] Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4

2022-02-22 Thread Francis Ginther

Public bug reported:

I started seeing errors parsing XML files today (Feb 22, 2022) after my
system was updated to 2.2.5-3ubuntu0.4. This is on a bionic server.

The parsing is being done by python3's xmltodict module, which uses
python3 expat as the actual parser. This is the error it raises:

xml.parsers.expat.ExpatError: out of memory: line 1, column 0

So far this is happening on multiple xml files, although they all come
from the same source (these are jenkins config.xml files). I'm working
on coming up with a minimal test case which I'll provide once I have it
cleaned up of any private data.

[System info]
$ lsb_release -rd
Description:Ubuntu 18.04.6 LTS
Release:18.04

$ apt-cache policy libexpat1
libexpat1:
  Installed: 2.2.5-3ubuntu0.4
  Candidate: 2.2.5-3ubuntu0.4
  Version table:
 *** 2.2.5-3ubuntu0.4 500
500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 Packages
500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 Packages
100 /var/lib/dpkg/status
 2.2.5-3 500
500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

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

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

Title:
  Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4

Status in expat package in Ubuntu:
  New

Bug description:
  I started seeing errors parsing XML files today (Feb 22, 2022) after
  my system was updated to 2.2.5-3ubuntu0.4. This is on a bionic server.

  The parsing is being done by python3's xmltodict module, which uses
  python3 expat as the actual parser. This is the error it raises:

  xml.parsers.expat.ExpatError: out of memory: line 1, column 0

  So far this is happening on multiple xml files, although they all come
  from the same source (these are jenkins config.xml files). I'm working
  on coming up with a minimal test case which I'll provide once I have
  it cleaned up of any private data.

  [System info]
  $ lsb_release -rd
  Description:Ubuntu 18.04.6 LTS
  Release:18.04

  $ apt-cache policy libexpat1
  libexpat1:
Installed: 2.2.5-3ubuntu0.4
Candidate: 2.2.5-3ubuntu0.4
Version table:
   *** 2.2.5-3ubuntu0.4 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.2.5-3 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1961800/+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 1961800] Re: Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4

2022-02-22 Thread Francis Ginther

I was able to workaround the issue by downgrading to the release version
of the package:

$ sudo apt-get install libexpat1=2.2.5-3 libexpat1-dev=2.2.5-3

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

Title:
  Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4

Status in expat package in Ubuntu:
  New

Bug description:
  I started seeing errors parsing XML files today (Feb 22, 2022) after
  my system was updated to 2.2.5-3ubuntu0.4. This is on a bionic server.

  The parsing is being done by python3's xmltodict module, which uses
  python3 expat as the actual parser. This is the error it raises:

  xml.parsers.expat.ExpatError: out of memory: line 1, column 0

  So far this is happening on multiple xml files, although they all come
  from the same source (these are jenkins config.xml files). I'm working
  on coming up with a minimal test case which I'll provide once I have
  it cleaned up of any private data.

  [System info]
  $ lsb_release -rd
  Description:Ubuntu 18.04.6 LTS
  Release:18.04

  $ apt-cache policy libexpat1
  libexpat1:
Installed: 2.2.5-3ubuntu0.4
Candidate: 2.2.5-3ubuntu0.4
Version table:
   *** 2.2.5-3ubuntu0.4 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.2.5-3 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1961800/+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 1961800] Re: Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4

2022-02-22 Thread Francis Ginther

Attached is an example config file and python script which demonstrates
the parsing error. This was reproduced on focal with:

$ apt-cache policy libexpat1
libexpat1:
  Installed: 2.2.9-1ubuntu0.2
  Candidate: 2.2.9-1ubuntu0.2
  Version table:
 *** 2.2.9-1ubuntu0.2 500
500 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages
500 http://security.ubuntu.com/ubuntu focal-security/main amd64 Packages
100 /var/lib/dpkg/status
 2.2.9-1build1 500
500 http://archive.ubuntu.com/ubuntu focal/main amd64 Packages


This example worked with 2.2.9-1build1 but not 2.2.9-1ubuntu0.2.

To run the example:

$ ./parser_example.py ./sample-config.xml


The sample-config.xml was generated by jenkins (version 2.303.2) of a freestyle 
project with only the job name and description set.

** Attachment added: "sample-config-and-parser.tgz"
   
https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1961800/+attachment/5562745/+files/sample-config-and-parser.tgz

** Summary changed:

- Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4
+ Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4 (bionic) or 
2.2.9-1ubuntu0.2 (focal)

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

Title:
  Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4 (bionic)
  or 2.2.9-1ubuntu0.2 (focal)

Status in expat package in Ubuntu:
  New

Bug description:
  I started seeing errors parsing XML files today (Feb 22, 2022) after
  my system was updated to 2.2.5-3ubuntu0.4. This is on a bionic server.

  The parsing is being done by python3's xmltodict module, which uses
  python3 expat as the actual parser. This is the error it raises:

  xml.parsers.expat.ExpatError: out of memory: line 1, column 0

  So far this is happening on multiple xml files, although they all come
  from the same source (these are jenkins config.xml files). I'm working
  on coming up with a minimal test case which I'll provide once I have
  it cleaned up of any private data.

  [System info]
  $ lsb_release -rd
  Description:Ubuntu 18.04.6 LTS
  Release:18.04

  $ apt-cache policy libexpat1
  libexpat1:
Installed: 2.2.5-3ubuntu0.4
Candidate: 2.2.5-3ubuntu0.4
Version table:
   *** 2.2.5-3ubuntu0.4 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.2.5-3 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1961800/+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 1961800] Re: Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4 (bionic) or 2.2.9-1ubuntu0.2 (focal)

2022-02-22 Thread Francis Ginther

This may be an issue with the python3 xmltodict module. Further testing
indicates that parsing a file with just xml.parsers.expat is working
just fine.

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

Title:
  Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4 (bionic)
  or 2.2.9-1ubuntu0.2 (focal)

Status in expat package in Ubuntu:
  New

Bug description:
  I started seeing errors parsing XML files today (Feb 22, 2022) after
  my system was updated to 2.2.5-3ubuntu0.4. This is on a bionic server.

  The parsing is being done by python3's xmltodict module, which uses
  python3 expat as the actual parser. This is the error it raises:

  xml.parsers.expat.ExpatError: out of memory: line 1, column 0

  So far this is happening on multiple xml files, although they all come
  from the same source (these are jenkins config.xml files). I'm working
  on coming up with a minimal test case which I'll provide once I have
  it cleaned up of any private data.

  [System info]
  $ lsb_release -rd
  Description:Ubuntu 18.04.6 LTS
  Release:18.04

  $ apt-cache policy libexpat1
  libexpat1:
Installed: 2.2.5-3ubuntu0.4
Candidate: 2.2.5-3ubuntu0.4
Version table:
   *** 2.2.5-3ubuntu0.4 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.2.5-3 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1961800/+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 1961800] Re: Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4 (bionic) or 2.2.9-1ubuntu0.2 (focal)

2022-02-22 Thread Francis Ginther

Moving this to xmltodict as I've been able to parse multiple xml files
through just python3's xml.parsers.expat without error, but none of them
through xmltodict.

** Also affects: python-xmltodict (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: python-xmltodict (Ubuntu)
   Status: New => Confirmed

** Changed in: expat (Ubuntu)
   Status: Confirmed => Invalid

** Summary changed:

- Seeing out of memory errors after upgrade to 2.2.5-3ubuntu0.4 (bionic) or 
2.2.9-1ubuntu0.2 (focal)
+ Seeing out of memory errors after libexpat1 upgrade to 2.2.5-3ubuntu0.4 
(bionic) or 2.2.9-1ubuntu0.2 (focal)

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

Title:
  Seeing out of memory errors after libexpat1 upgrade to
  2.2.5-3ubuntu0.4 (bionic) or 2.2.9-1ubuntu0.2 (focal)

Status in expat package in Ubuntu:
  Invalid
Status in python-xmltodict package in Ubuntu:
  Confirmed

Bug description:
  I started seeing errors parsing XML files today (Feb 22, 2022) after
  my system was updated to 2.2.5-3ubuntu0.4. This is on a bionic server.

  The parsing is being done by python3's xmltodict module, which uses
  python3 expat as the actual parser. This is the error it raises:

  xml.parsers.expat.ExpatError: out of memory: line 1, column 0

  So far this is happening on multiple xml files, although they all come
  from the same source (these are jenkins config.xml files). I'm working
  on coming up with a minimal test case which I'll provide once I have
  it cleaned up of any private data.

  [System info]
  $ lsb_release -rd
  Description:Ubuntu 18.04.6 LTS
  Release:18.04

  $ apt-cache policy libexpat1
  libexpat1:
Installed: 2.2.5-3ubuntu0.4
Candidate: 2.2.5-3ubuntu0.4
Version table:
   *** 2.2.5-3ubuntu0.4 500
  500 http://archive.ubuntu.com/ubuntu bionic-updates/main amd64 
Packages
  500 http://archive.ubuntu.com/ubuntu bionic-security/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.2.5-3 500
  500 http://archive.ubuntu.com/ubuntu bionic/main amd64 Packages

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/expat/+bug/1961800/+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 2016908] Re: Unable to deploy hosts with lunar images after 20230319 - fails to connect and download squashfs

2023-04-20 Thread Francis Ginther

We discussed fixes to the maas bootloader builds and as a result, we
have a new maas bootloader which should have the latest shim and grub:

http://images.maas.io/ephemeral-v3/candidate/bootloaders/uefi/amd64/20230420.0/

I manually copied these to my test maas, it did not resolve the issue
(or have any other visible change).

Paolo built a kernel to try and debug this from the prctl interface.
With this (and udev with -debug), I see these two additional console log
entries:

[   18.029479] __do_sys_prctl::2375
[   18.042840] __do_sys_prctl::2380

There are lots of these, but only the same two lines.

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

Title:
  Unable to deploy hosts with lunar images after 20230319 - fails to
  connect and download squashfs

Status in maas-images:
  Incomplete
Status in systemd package in Ubuntu:
  New

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  
  Still gathering logs and info and will update as I go.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2016908/+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 2016908] Re: udev fails to make prctl() syscall with apparmor=0 (as used by maas by default)

2023-04-20 Thread Francis Ginther

I can confirm @xnox's findings with my maas server deploying lunar.
Adding `apparmor=1` to the settings/configuration/kernel-parameters
allows for a successful deployment with the lunar 6.2.0-20.20 kernel.

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

Title:
  udev fails to make prctl() syscall with apparmor=0 (as used by maas by
  default)

Status in MAAS:
  Triaged
Status in maas-images:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Invalid

Bug description:
  I'm assuming the image being used for these deploys is 20230417 or
  20230417.1 based on the fact that I saw a 6.2 kernel being used which
  I don't believe was part of the 20230319 serial. I don't have access
  to the maas server, so I can't directly check any log files.

  MAAS Version: 3.3.2

  Here's where the serial log indicates it can't download the squashfs. The 
full log is attached as scobee-lunar-no-squashfs.log (there are some other 
console message intermixed):
  no search or nameservers found in /run/net-BOOTIF.conf /run/net-*.conf 
/run/net6
  -*.conf
  :: 
root=squash:http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.04/lunar/candi
  date/squa[  206.804704] Btrfs loaded, crc32c=crc32c-generic, zoned=yes, 
fsverity
  =yes
  shfs
  :: mount_squash downloading 
http://10.229.32.21:5248/images/ubuntu/arm64/ga-23.0
  4/lunar/candidate/squashfs to /root.tmp.img
  Connecting to 10.229.32.21:5248 (10.229.32.21:5248)
  wget: can't connect to remote host (10.229.32.21): Network is unreachable
  :: mount -t squashfs -o loop  '/root.tmp.img' '/root.tmp'
  mount: mounting /root.tmp.img on /root.tmp failed: No such file or directory
  done.

  Still gathering logs and info and will update as I go.

  
  Kernel Bug / Apparmor
  reproducer

  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-kernel
  $ wget 
https://images.maas.io/ephemeral-v3/candidate/lunar/amd64/20230419/ga-23.04/generic/boot-initrd
  $ qemu-system-x86_64 -nographic -m 2G -kernel ./boot-kernel -initrd 
./boot-initrd -append 'console=ttyS0 break=modules apparmor=0'

  #start the VM
  
  Starting systemd-udevd version 252.5-2ubuntu3
  Spawning shell within the initramfs

  BusyBox v1.35.0 (Ubuntu 1:1.35.0-4ubuntu1) built-in shell (ash)
  Enter 'help' for a list of built-in commands.

  (initramfs) udevadm info --export-db
  Failed to set death signal: Invalid argument

  Observe that udevadm fails to setup death signal, with in systemd code
  is this

  
https://github.com/systemd/systemd/blob/08c2f9c626e0f0052d505b1b7e52f335c0fbfa1d/src/basic/process-
  util.c#L1252

  if (flags & (FORK_DEATHSIG|FORK_DEATHSIG_SIGINT))
  if (prctl(PR_SET_PDEATHSIG, (flags & FORK_DEATHSIG_SIGINT) ? 
SIGINT : SIGTERM) < 0) {
  log_full_errno(prio, errno, "Failed to set death 
signal: %m");
  _exit(EXIT_FAILURE);
  }

  
  workaround set kernel commandline to `apparmor=1`
  

  MAAS bug
  Why is maas setting `apparmor=0` ? Ubuntu shouldn't be used without apparmor. 
Even for deployment and commisioning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas/+bug/2016908/+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 2037417] Re: mantic arm64 images are failing to deploy with failure to mount root and kernel filesystems

2023-09-26 Thread Francis Ginther

I have done some debugging, but I'm at a loss for what to do next.

Booting with 'apparmor=0' did not help.

Here's what the mounts look like:

# mount
sysfs on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)
udev on /dev type devtmpfs 
(rw,nosuid,relatime,size=262851016k,nr_inodes=65712754,mode=755,inode64)
devpts on /dev/pts type devpts 
(rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)
tmpfs on /run type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=52585616k,mode=755,inode64)
efivarfs on /sys/firmware/efi/efivars type efivarfs 
(rw,nosuid,nodev,noexec,relatime)
/root.tmp.img (deleted) on /media/root-ro type squashfs 
(ro,relatime,errors=continue,threads=single)
tmpfs-root on /media/root-rw type tmpfs (rw,relatime,inode64)
overlayroot on / type overlay 
(ro,relatime,lowerdir=/media/root-ro,upperdir=/media/root-rw/overlay,workdir=/media/root-rw/overlay-workdir/_,xino=off,nouserxattr)
copymods on /usr/lib/modules type tmpfs (rw,relatime,inode64)
securityfs on /sys/kernel/security type securityfs 
(rw,nosuid,nodev,noexec,relatime)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev,inode64)
tmpfs on /run/lock type tmpfs 
(rw,nosuid,nodev,noexec,relatime,size=5120k,inode64)
cgroup2 on /sys/fs/cgroup type cgroup2 
(rw,nosuid,nodev,noexec,relatime,nsdelegate,memory_recursiveprot)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
bpf on /sys/fs/bpf type bpf (rw,nosuid,nodev,noexec,relatime,mode=700)
tmpfs on /etc/machine-id type tmpfs 
(ro,relatime,size=52585616k,mode=755,inode64)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime,pagesize=2M)
mqueue on /dev/mqueue type mqueue (rw,nosuid,nodev,noexec,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,nosuid,nodev,noexec,relatime)
tracefs on /sys/kernel/tracing type tracefs (rw,nosuid,nodev,noexec,relatime)
fusectl on /sys/fs/fuse/connections type fusectl 
(rw,nosuid,nodev,noexec,relatime)
configfs on /sys/kernel/config type configfs (rw,nosuid,nodev,noexec,relatime)
ramfs on /run/credentials/systemd-sysctl.service type ramfs 
(ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-tmpfiles-setup-dev.service type ramfs 
(ro,nosuid,nodev,noexec,relatime,mode=700)
ramfs on /run/credentials/systemd-tmpfiles-setup.service type ramfs 
(ro,nosuid,nodev,noexec,relatime,mode=700)

I can boot into single user mode and interact with the console to
perform further debugging.

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

Title:
  mantic arm64 images are failing to deploy with failure to mount root
  and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log.

[Touch-packages] [Bug 2037417] Re: mantic arm64 images are failing to deploy with failure to mount root and kernel filesystems

2023-09-26 Thread Francis Ginther

journalctl -b --no-pager

** Attachment added: "kopter-journal.log"
   
https://bugs.launchpad.net/maas-images/+bug/2037417/+attachment/5704620/+files/kopter-journal.log

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

Title:
  mantic arm64 images are failing to deploy with failure to mount root
  and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic arm64 images are failing to deploy with failure to mount root and kernel filesystems

2023-09-26 Thread Francis Ginther

The last working maas image had kernel 6.3.0-7-generic, the first one to
fail has 6.5.0-5-generic.

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

Title:
  mantic arm64 images are failing to deploy with failure to mount root
  and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-09-27 Thread Francis Ginther

I've confirmed this problem on amd64 and ppc64el
(https://bugs.launchpad.net/maas/+bug/2037475).

** Summary changed:

- mantic arm64 images are failing to deploy with failure to mount root and 
kernel filesystems
+ mantic images after 20230917 are failing to deploy with failure to mount root 
and kernel filesystems

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-09-27 Thread Francis Ginther

The 6.5.0-6.6 linux kernel in mantic-proposed also fails.

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-09-29 Thread Francis Ginther

I have tested booting with various initrd/kernel/squashfs combinations.

 * The mantic 6.5.0-5 kernel and modules repacked into a jammy (20230927) or 
lunar (20230927) initrd and squashfs result in a deployed host.
 * The mantic initrd and squashfs from 20230908 with the 6.5.0-5 kernel did not 
deploy.
 * The original 20230908 mantic maas image (with the 6.3.0-7-generic kernel) 
does boot.

So the 6.5.0-5 kernel works with older images, but not any of the recent
mantic images.

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-02 Thread Francis Ginther

My experiments with the workaround mentioned in
https://bugs.launchpad.net/ubuntu/+source/initramfs-
tools/+bug/2037202/comments/1 did not help.

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in The Ubuntu-power-systems project:
  Confirmed
Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-04 Thread Francis Ginther

** Also affects: linux
   Importance: Undecided
   Status: New

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in The Ubuntu-power-systems project:
  Confirmed
Status in linux package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Mantic:
  New
Status in systemd source package in Mantic:
  Confirmed

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-04 Thread Francis Ginther

** Project changed: linux => linux (Ubuntu)

** Changed in: linux (Ubuntu)
Milestone: None => ubuntu-23.10

** Also affects: linux (Ubuntu Mantic)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Mantic)
   Importance: Undecided
   Status: Confirmed

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in maas-images:
  New
Status in The Ubuntu-power-systems project:
  Confirmed
Status in linux package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Mantic:
  New
Status in systemd source package in Mantic:
  Confirmed

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/maas-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-06 Thread Francis Ginther

Special maas image built with util-linux, 2.39.1-4ubuntu2, from
https://ppa.launchpadcontent.net/xnox/release-critical/ubuntu is looking
good. I have one machine deployed with this:

ubuntu@rumford:~$ uname -r
6.5.0-5-lowlatency
ubuntu@rumford:~$ apt-cache policy util-linux
util-linux:
  Installed: 2.39.1-4ubuntu2
  Candidate: 2.39.1-4ubuntu2
  Version table:
 *** 2.39.1-4ubuntu2 500
500 https://ppa.launchpadcontent.net/xnox/release-critical/ubuntu 
mantic/main amd64 Packages
100 /var/lib/dpkg/status
 2.39.1-4ubuntu1 500
500 http://archive.ubuntu.com/ubuntu mantic/main amd64 Packages
ubuntu@rumford:~$ cat /etc/cloud/build.info 
build_name: server
serial: 20231006.1732

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in cloud-images:
  New
Status in maas-images:
  Confirmed
Status in The Ubuntu-power-systems project:
  Invalid
Status in Release Notes for Ubuntu:
  New
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in util-linux package in Ubuntu:
  Triaged
Status in linux source package in Mantic:
  Invalid
Status in systemd source package in Mantic:
  Invalid
Status in util-linux source package in Mantic:
  Triaged

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2037417/+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 2037417] Re: mantic images after 20230917 are failing to deploy with failure to mount root and kernel filesystems

2023-10-09 Thread Francis Ginther

The latest maas images from 20231008 are booting without issue:

ubuntu@akis:~$ lsb_release -sc
No LSB modules are available.
mantic
ubuntu@akis:~$ cat /etc/cloud/build.info 
build_name: server
serial: 20231008
ubuntu@akis:~$ uname -a
Linux akis 6.5.0-7-generic #7-Ubuntu SMP PREEMPT_DYNAMIC Fri Sep 29 09:14:56 
UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

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

Title:
  mantic images after 20230917 are failing to deploy with failure to
  mount root and kernel filesystems

Status in cloud-images:
  New
Status in maas-images:
  Confirmed
Status in The Ubuntu-power-systems project:
  Invalid
Status in Release Notes for Ubuntu:
  New
Status in linux package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Invalid
Status in util-linux package in Ubuntu:
  Fix Released
Status in linux source package in Mantic:
  Invalid
Status in systemd source package in Mantic:
  Invalid
Status in util-linux source package in Mantic:
  Fix Released

Bug description:
  Mantic arm64 deploys started failing on Sept 18th with:

  [   41.913552] systemd[1]: Starting systemd-remount-fs.service - Remount Root 
and Kernel File Systems...
   Starting [0;1;39msystemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting [0;1;39msystemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [[0;32m  OK  [0m] Started [0;1;39msystemd-journald.service[0m - Journal 
Service.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-hugepages.mount[0m - Huge Pages 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39mdev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-debug.m鈥t[0m - Kernel Debug 
File System.
  [[0;32m  OK  [0m] Mounted [0;1;39msys-kernel-tracing鈥t[0m - Kernel Trace 
File System.
  [[0;32m  OK  [0m] Finished [0;1;39mkeyboard-setup.se鈥�- Set the console 
keyboard layout.
  [[0;32m  OK  [0m] Finished [0;1;39mkmod-static-nodes鈥eate List of Static 
Device Nodes.
  [[0;32m  OK  [0m] Finished [0;1;39mlvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@dm_mod.s鈥[0m - Load Kernel 
Module dm_mod.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@drm.service[0m - Load Kernel 
Module drm.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@fuse.service[0m - Load Kernel 
Module fuse.
  [[0;32m  OK  [0m] Finished [0;1;39mmodprobe@loop.service[0m - Load Kernel 
Module loop.
  [[0;32m  OK  [0m] Finished [0;1;39msystemd-modules-l鈥ervice[0m - Load 
Kernel Modules.
  [[0;1;31mFAILED[0m] Failed to start [0;1;39msystemd-re鈥unt Root and 
Kernel File Systems.
  See 'systemctl status systemd-remount-fs.service' for details.

  After this many other services and cloud-init fails. See the full
  kopter-0918.log. For comparison, a log from the prior day's test is
  also attached.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/2037417/+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 1775018] Re: Fix for openssl 1.0.2 backport

2019-02-22 Thread Francis Ginther

** Tags added: id-5c6e7940730252541b970add

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

Title:
  Fix for openssl 1.0.2 backport

Status in Ubuntu on IBM z Systems:
  Confirmed
Status in openssl package in Ubuntu:
  Fix Released
Status in openssl1.0 package in Ubuntu:
  Confirmed
Status in openssl source package in Xenial:
  Invalid
Status in openssl1.0 source package in Xenial:
  Invalid
Status in openssl source package in Bionic:
  Fix Released
Status in openssl1.0 source package in Bionic:
  Confirmed
Status in openssl source package in Cosmic:
  Fix Released
Status in openssl1.0 source package in Cosmic:
  Confirmed

Bug description:
  [Impact]

   * Fix hw accelerated performance impact on s390x with non-default
  openssl1.0.

  [Test Case]

   * Test that performance of hw accelerated crypto is improved / i.e.
  ssl speed test

   * Test that openssh still works, just in case.

  [Regression Potential]

   * This only changes accelerated codepath on s390x, for specific algos when 
CPACF is enabled on the system cpu, which is usually on.
   * Same fix is already in use by 1.1.0 default openssl package, and well 
excercised on bionic and up.

  [Other Info]
   
   * original bug report.

  
  This is a fix for this feature's backport to openssl 1.0.2 ( 1.1.0 and 
upstream code are not affected ).

  Original LP ticket :
  https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1743750

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1775018/+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 1818953] Re: mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by executing perl script, multiple architectures

2019-03-12 Thread Francis Ginther

** Tags added: id-5c868875e54e05183ffb1732

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

Title:
  mblen() failing in Perl / Perl core dumping core on UBUNTU 19.04 by
  executing perl script, multiple architectures

Status in The Ubuntu-power-systems project:
  Confirmed
Status in perl package in Ubuntu:
  Confirmed

Bug description:
  == Comment: #0 - NAGENDRA P. DONTAMSETTY  - 2019-02-28 
00:14:49 ==
  ---Problem Description---
  Perl core dumping core on UBUNTU 19.04 by executing perl script
   
  ---uname output---
  root@p8ct1p13:/tmp# uname -a Linux p8ct1p13.in.ibm.com 4.19.0-13-generic 
#14-Ubuntu SMP Thu Feb 7 21:50:00 UTC 2019 ppc64le ppc64le ppc64le GNU/Linux
   
  Machine Type = ppc64le and power8 
   
  ---Debugger Data---
  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'
   
   
  ---Steps to Reproduce---
   Description:  Perl core dumpinmg core on UBUNTU 19.04 by exec cmd "mkrsrc"

  
  root@p8ct1p13:/tmp# uname -a
  Linux p8ct1p13.in.ibm.com 4.19.0-13-generic #14-Ubuntu SMP Thu Feb 7 21:50:00 
UTC 2019 ppc64le ppc64le ppc64le GNU/Linux

  
  root@p8ct1p13:~# cat /etc/os-release
  NAME="Ubuntu"
  VERSION="19.04 (Disco Dingo)"
  ID=ubuntu
  ID_LIKE=debian
  PRETTY_NAME="Ubuntu Disco Dingo (development branch)"
  VERSION_ID="19.04"
  HOME_URL="https://www.ubuntu.com/";
  SUPPORT_URL="https://help.ubuntu.com/";
  BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/";
  
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy";
  VERSION_CODENAME=disco
  UBUNTU_CODENAME=disco

  
  root@p8ct1p13:~# ctversion -bv
  RSCT_Build_Name=rsholxs002a 3.2.4.2 RSCT_Build_Time=19043.16:11:49 
RSCT_Build_Context=ppc64le_linux_2

  
  root@p8ct1p13:/tmp# mkrsrc IBM.Ray Name="fvt1" 
NodeNameList={"p8ct1p09.in.ibm.com"} ManualMode=0 Int32=00 String="Initial Test 
String 2"
  perl: mbrtowc.c:105: __mbrtowc: Assertion `__mbsinit (data.__statep)' failed.
  Aborted (core dumped)

  root@p8ct1p13:/tmp# file core
  core: ELF 64-bit LSB core file, 64-bit PowerPC or cisco 7500, version 1 
(SYSV), SVR4-style, from '/usr/bin/perl /usr/bin/mkrsrc IBM.Ray Name=fvt1 
NodeNameList={p8ct1p09.in.ibm.c', real uid: 0, effective uid: 0, real gid: 0, 
effective gid: 0, execfn: '/usr/bin/mkrsrc', platform: 'power8'

  
  root@p8ct1p13:/tmp# which mkrsrc
  /usr/bin/mkrsrc

  root@p8ct1p13:/tmp# file /usr/bin/mkrsrc

  /usr/bin/mkrsrc: symbolic link to /opt/rsct/bin/mkrsrc

  root@p8ct1p13:/tmp# file /opt/rsct/bin/mkrsrc
  /opt/rsct/bin/mkrsrc: Perl script text executable
   
  Contact Information = Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com 
   
  Userspace tool common name: perl 5 
   
  The userspace tool has the following bit modes: 64bit 

  Userspace rpm: ii  perl  5.28.1-4
  ppc64el

  Userspace tool obtained from project website:  na 
   
  *Additional Instructions for Nagendra Dontamsetty/ndont...@in.ibm.com, 
Anirban/anirb...@in.ibm.com: 
  -Post a private note with access information to the machine that is currently 
in the debugger.
  -Attach ltrace and strace of userspace application.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1818953/+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 1817453] Re: 19.04 installer displays keyboard layouts in the wrong language

2019-03-15 Thread Francis Ginther

** Tags added: id-5c8a78260a33937a98c3c550

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

Title:
  19.04 installer displays keyboard layouts in the wrong language

Status in console-setup package in Ubuntu:
  In Progress
Status in console-setup source package in Disco:
  In Progress

Bug description:
  When you select the Spanish language in the installer, when you go to
  the keyboard layout selection these are in another language. The
  options for Latin American Spanish do not appear.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: ubiquity 19.04.5
  ProcVersionSignature: Ubuntu 4.19.0-13.14-generic 4.19.20
  Uname: Linux 4.19.0-13-generic x86_64
  ApportVersion: 2.20.10-0ubuntu21
  Architecture: amd64
  CasperVersion: 1.402
  CurrentDesktop: ubuntu:GNOME
  Date: Sun Feb 24 06:51:45 2019
  InstallCmdLine: file=/cdrom/preseed/ubuntu.seed boot=casper 
initrd=/casper/initrd quiet splash --- maybe-ubiquity
  LiveMediaBuild: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20190223)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=es_ES.UTF-8
   SHELL=/bin/bash
  SourcePackage: ubiquity
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/console-setup/+bug/1817453/+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 1816812] Re: pull seb patch

2019-03-15 Thread Francis Ginther

** Tags added: id-5c8a7453b51c3d8c15443e74

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

Title:
  pull seb patch

Status in systemd package in Ubuntu:
  New
Status in systemd source package in Disco:
  New

Bug description:
  https://github.com/systemd/systemd/pull/11697

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1816812/+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 1820886] Re: Potential inconsistency due to system halt/reboot being allowed when package installation in progress

2019-03-20 Thread Francis Ginther

** Tags added: id-5c912dccec34916fc8563ef9

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

Title:
  Potential inconsistency due to system halt/reboot being allowed when
  package installation in progress

Status in apt package in Ubuntu:
  New

Bug description:
  [System]
  Any current Ubuntu Desktop/Server supported release (Trusty, Xenial, Bionic, 
Cosmic).

  [Impact]
  Package installation turns into an inconsistent state if system is rebooted 
in the middle of an apt install/upgrade.

  [Test Case]
  1. User1 at Ubuntu box issues "sudo apt-get upgrade";
  2. User2 at Ubuntu box issues "shutdown -r" or reboots it using the GUI;
  3. System reboots and potentially turns into an inconsistent state.

  [Remarks]
  APT should automatically inhibit system halts/reboots while packages being 
installed/removed. A similar behavior to what is shown by unattended-upgrades.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1820886/+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 1821308] Re: apt-get upgrade ignores pinning preferences since 1.0.1ubuntu2.22

2019-03-22 Thread Francis Ginther

** Tags added: id-5c94c4fd0a7a583861e90c88

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

Title:
  apt-get upgrade ignores pinning preferences since 1.0.1ubuntu2.22

Status in apt package in Ubuntu:
  Invalid
Status in apt source package in Trusty:
  Triaged

Bug description:
  I have updated apt this morning:

  Start-Date: 2019-03-22  09:36:18
  Commandline: apt-get dist-upgrade
  Upgrade: apt:amd64 (1.0.1ubuntu2.20, 1.0.1ubuntu2.22), ...

  
  Afterwards, apt-get ignores my pinning preferences:

  # apt-get --dry-run upgrade
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  Calculating upgrade... Done
  The following packages will be DOWNGRADED:
burp
  0 upgraded, 0 newly installed, 1 downgraded, 0 to remove and 0 not upgraded.
  Inst burp [2.0.54-1] (1.3.48-4 Ubuntu:14.04/trusty [amd64])
  Conf burp (1.3.48-4 Ubuntu:14.04/trusty [amd64])

  
  # cat /etc/apt/preferences.d/burp.pref
  Package: burp
  Pin: version 2.0.54*
  Pin-Priority: 1000

  
  This might be caused by bug 1814727 as it's the only thing I can see in the 
changelog regarding apt/pinning.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1821308/+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 1822270] Re: Debconf readline frontend does not show options

2019-03-29 Thread Francis Ginther

** Tags added: id-5c919ca2a4ae741f19d59ad9

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

Title:
  Debconf readline frontend does not show options

Status in debconf package in Ubuntu:
  New

Bug description:
  AFFECTED RELEASE:

  Bionic

  PACKAGE VERSION:

  debconf - 1.5.66

  DESCRIPTION:

  When upgrading the kernel on a recent Bionic minimal image, the user
  is prompted to resolve a conflict in the file /boot/grub/menu.lst.

  The minimal images do not have dialog/whiptail installed, so debconf
  falls back to using the readline frontend.

  The user sees the prompt: "What would you like to do about menu.lst?"
  but is not presented with the list of options to choose from.

  If a valid option is typed in, debconf will continue processing
  correctly and the list of options  appears on the screen. See also
  https://pastebin.ubuntu.com/p/8xvSn88SKG/

  STEPS TO REPRODUCE:

  Launch the minimal Bionic image with serial 20190212 http://cloud-
  images.ubuntu.com/minimal/releases/bionic/release-20190212/ubuntu-18.04
  -minimal-cloudimg-amd64.img

  for example via multipass and run `apt-get update` and `apt-get dist-
  upgrade`.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/debconf/+bug/1822270/+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 1822118] Re: Kernel Panic while rebooting cloud instance

2019-03-30 Thread Francis Ginther

** Tags added: id-5c9e3d984ba1ad4df84a6b1c

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

Title:
  Kernel Panic while rebooting cloud instance

Status in linux-azure package in Ubuntu:
  In Progress
Status in systemd package in Ubuntu:
  New

Bug description:
  Description:   In the event a particular Azure cloud instance is
  rebooted it's possible that it may never recover and the instance will
  break indefinitely.

  In My case, it was a kernel panic. See specifics below..

  
  Series: Disco
  Instance Size: Basic_A3
  Region: (Default) US-WEST-2
  Kernel Version: 4.18.0-1013-azure #13-Ubuntu SMP Thu Feb 28 22:54:16 UTC 2019 
x86_64 x86_64 x86_64 GNU/Linux

  
  I had a simple script to reboot an instance (X) amount of times, I chose 50, 
so the machine would power cycle by issuing a "reboot" from the terminal prompt 
just as a user would.   Once the machine came up, it captured dmesg and other 
bits then rebooted again until it reached 50. 

  After the 4th attempt, my script timed out, I took a look at the
  instance console log and the following displayed on the console.

  
  [  OK  ] Reached target Reboot.
  /shutdown: error while loading shared libra[   89.498980] Kernel panic - not 
syncing: Attempted to kill init! exitcode=0x7f00
  [   89.498980]
  [   89.500042] CPU: 0 PID: 1 Comm: shutdown Not tainted 4.18.0-1013-azure 
#13-Ubuntu
  [   89.508026] Hardware name: Microsoft Corporation Virtual Machine/Virtual 
Machine, BIOS 090007  06/02/2017
  [   89.508026] Call Trace:
  [   89.508026]  dump_stack+0x63/0x8a
  [   89.508026]  panic+0xe7/0x247
  [   89.508026]  do_exit.cold.23+0x26/0x75
  [   89.508026]  do_group_exit+0x43/0xb0
  [   89.508026]  __x64_sys_exit_group+0x18/0x20
  [   89.508026]  do_syscall_64+0x5a/0x110
  [   89.508026]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [   89.508026] RIP: 0033:0x7f7bf0154d86
  [   89.508026] Code: Bad RIP value.
  [   89.508026] RSP: 002b:7ffd6be693b8 EFLAGS: 0206 ORIG_RAX: 
00e7
  [   89.508026] RAX: ffda RBX: 7f7bf015e420 RCX: 
7f7bf0154d86
  [   89.508026] RDX: 007f RSI: 003c RDI: 
007f
  [   89.508026] RBP: 7f7bef9449c0 R08: 00e7 R09: 

  [   89.508026] R10: 7ffd6be6974c R11: 0206 R12: 
0018
  [   89.508026] R13: 7f7bef944ac8 R14: 7f7bef944a00 R15: 

  [   89.508026] Kernel Offset: 0x1600 from 0x8100 (relocation 
range: 0x8000-0xbfff)
  [   89.508026] ---[ end Kernel panic - not syncing: Attempted to kill init! 
exitcode=0x7f00
  [   89.508026]  ]---

  
  this only occurred once in my testing.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-azure/+bug/1822118/+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 1786940] Re: Enable arm-linux-gnueabi target on ppc64el toolchain

2019-03-30 Thread Francis Ginther

** Tags added: id-5c9e35f8430a6623f7fabf6b

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

Title:
  Enable arm-linux-gnueabi target on ppc64el toolchain

Status in The Ubuntu-power-systems project:
  Incomplete
Status in binutils package in Ubuntu:
  Fix Released
Status in gcc-7-cross package in Ubuntu:
  New
Status in gcc-8-cross package in Ubuntu:
  New
Status in gcc-defaults package in Ubuntu:
  Incomplete

Bug description:
  Dear Canonical.

  We would like to have arm-linux-gnueabi target on ppc64el cross
  toolchain. This would enable us to use a ppc64el host to do cross
  compilation for aarch64.

  I talked to Matthias Klose already, and he is aware of this request.

  Thank you,
  Breno

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1786940/+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 1822341] Re: [FFE][SRU] Please add ubuntu-wsl binary package

2019-03-30 Thread Francis Ginther

** Tags added: id-5be3256b704279166ce21e99

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

Title:
  [FFE][SRU] Please add ubuntu-wsl binary package

Status in ubuntu-meta package in Ubuntu:
  New

Bug description:
  [Impact]
  * The newly added wsl seed includes the packages to be installed by default 
on Ubuntu running in the Windows Subsystem for Linux. In addition to the 
packages in ubuntu-minimal the added ubuntu-wsl metapackage depends on on 
utilities useful only in the WSL environment.

  [Test Case]
  * The package is a new metapackage, just try installing it

  [Fix]
  * The change add the new package and also adds the wsl seed to watch.

  [Regression potential]
  * Nothing, it is a new meta package, with no breaks, etc.

  [Other Info]
  * Please consider accepting this new binary package to Disco, because it 
needs to be SRU-d to all supported releases. The ubuntu-wsl metapackage will 
allow adding new packages for WSL installations only when more integration 
utilities become available.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ubuntu-meta/+bug/1822341/+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 1804997] Re: Improve timer spread after resume

2018-11-25 Thread Francis Ginther

** Tags added: id-5bfa7ee6688aa343ceac3d72

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

Title:
  Improve timer spread after resume

Status in apt package in Ubuntu:
  Triaged

Bug description:
  When resuming a machine that should have run unattended-upgrades in
  the time it was down, and it has containers for which the same
  applies, the host and all containers run their upgrades in parallel,
  creating a lot of load.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1804997/+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 1805183] Re: systemd-resolved constantly restarts on Bionic upgraded from Xenial

2018-11-30 Thread Francis Ginther

** Tags added: id-5c0011e969ed904c67dda9ee

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

Title:
  systemd-resolved constantly restarts on Bionic upgraded from Xenial

Status in systemd package in Ubuntu:
  New
Status in ubuntu-release-upgrader package in Ubuntu:
  New

Bug description:
  If a cloud server is upgraded from Xenial to Bionic, the dhclient
  system remains in place and any DHCP lease refreshes cause a needless
  restart of the system-resolved daemon

  
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPREQUEST of 10.226.209.106 on 
ens3 to 10.226.209.105 port 67 (xid=0x2bd41d7d)
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: DHCPACK of 10.226.209.106 from 
10.226.209.105
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopping Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Stopped Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting Network Name Resolution...
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Positive Trust Anchors:
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 19036 8 2 
49aac11d7b6f6446702e54a1607371607a1a41855200fd2ce1cdde32f24e8fb5
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: . IN DS 20326 8 2 
e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Negative trust anchors: 
10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 1
  Nov 26 16:59:41 srv-qvjhx systemd-resolved[1609]: Using system hostname 
'srv-qvjhx'.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Started Network Name Resolution.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Starting 
resolvconf-pull-resolved.service...
  Nov 26 16:59:41 srv-qvjhx dhclient[825]: bound to 10.226.209.106 -- renewal 
in 1466 seconds.
  Nov 26 16:59:41 srv-qvjhx systemd[1]: Started 
resolvconf-pull-resolved.service.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: ubuntu-release-upgrader-core 1:16.04.25
  ProcVersionSignature: Ubuntu 4.4.0-139.165-generic 4.4.160
  Uname: Linux 4.4.0-139-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.18
  Architecture: amd64
  CrashDB: ubuntu
  Date: Mon Nov 26 16:17:52 2018
  PackageArchitecture: all
  SourcePackage: ubuntu-release-upgrader
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1805183/+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 1807288] Re: mkfs.ext4 -d $directory_with_acls leads to EINVAL

2018-12-07 Thread Francis Ginther

** Tags added: id-5c09fa23626104848f94e45e

-- 
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/1807288

Title:
  mkfs.ext4 -d $directory_with_acls leads to EINVAL

Status in e2fsprogs package in Ubuntu:
  New
Status in e2fsprogs source package in Bionic:
  New
Status in e2fsprogs source package in Cosmic:
  New
Status in e2fsprogs source package in Disco:
  New

Bug description:
  [Justification]
  `mkfs.ext4 -d` can produce broken filesystems when there are acls in the tree 
used as input.

  [Test case]
  1. dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
  2. mkdir -p stuff/journal
  3. setfacl -m g:adm:rwx stuff/journal
  4. mkfs.ext4 -L lala -O -metadata_csum -T default -O uninit_bg fake.img -d 
./stuff/
  5. sudo mount ./fake.img /mnt
  6. Verify that `getfacl /mnt/journal/` returns an error.
  7. sudo umount /mnt
  8. install libext2fs2 from -proposed.
  9. mkfs.ext4 -L lala -O -metadata_csum -T default -O uninit_bg fake.img -d 
./stuff/
  10. sudo mount ./fake.img /mnt
  11. Verify that `getfacl /mnt/journal/` returns acl information, not an error.
  12. sudo umount /mnt

  [Original description]

  This looks an awful lot like bug 1645232 but that is claimed to be
  fixed:

  mwhudson@ringil:~/tmp$ mkfs.ext4 -V
  mke2fs 1.44.1 (24-Mar-2018)
   Using EXT2FS Library version 1.44.1
  mwhudson@ringil:~/tmp$ dd if=/dev/zero count=0 bs=1M seek=100 of=./fake.img
  0+0 records in
  0+0 records out
  0 bytes copied, 0.0015871 s, 0.0 kB/s
  mwhudson@ringil:~/tmp$ mkdir -p stuff/journal
  mwhudson@ringil:~/tmp$ setfacl -m g:adm:rwx stuff/journal
  mwhudson@ringil:~/tmp$ mkfs.ext4 -L lala -O -metadata_csum -T default -O 
uninit_bg fake.img -d ./stuff/
  mke2fs 1.44.1 (24-Mar-2018)
  Discarding device blocks: done
  Creating filesystem with 25600 4k blocks and 6400 inodes

  Allocating group tables: done
  Writing inode tables: done
  Creating journal (1024 blocks): done
  Copying files into the device: done
  Writing superblocks and filesystem accounting information: done

  mwhudson@ringil:~/tmp$ sudo mount ./fake.img /mnt
  mwhudson@ringil:~/tmp$ getfacl /mnt/journal/
  getfacl: /mnt/journal/: Invalid argument

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/e2fsprogs/+bug/1807288/+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 1805027] Re: systemd-resolved can't resolve Comcast mail server addresses

2018-12-07 Thread Francis Ginther

** Tags added: id-5c094e11580a2f05d67fe6f3

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

Title:
  systemd-resolved can't resolve Comcast mail server addresses

Status in systemd package in Ubuntu:
  Triaged

Bug description:
  1) Ubuntu release:  18.10
  2) systemd-resolved version: (Default latest version that comes with Ubuntu 
18.10)
  3) Expected behavior: Comcast's POP3 mail server addresses to be resolved to 
IP addresses
  4) Actual behavior:  Comcast's POP3 mail server addresses can't be resolved 
to IP addresses

  Starting on Monday, November 19, 2018, Comcast made a DNS change
  related to its POP3 mail servers (mail.comcast.net and
  pop3.comcast.net) that prevent resolved from being able to resolve
  those domains into IP addresses.  When I try to ping either host
  (mail.comcast.net or pop2.comcast.net), I get this error:

  tom@deathstar:~$ ping mail.comcast.net
  ping: mail.comcast.net: Name or service not known
  tom@deathstar:~$

  When I manually lookup up the domain, I get these results:

  tom@deathstar:~$ nslookup mail.comcast.net
  Server:   127.0.0.53
  Address:  127.0.0.53#53

  Non-authoritative answer:
  mail.comcast.net  canonical name = imap.ge.xfinity.com.
  Name: imap.ge.xfinity.com
  Address: 96.118.242.209
  Name: imap.ge.xfinity.com
  Address: 96.118.242.197
  Name: imap.ge.xfinity.com
  Address: 96.118.242.233
  Name: imap.ge.xfinity.com
  Address: 96.118.242.225
  Name: imap.ge.xfinity.com
  Address: 96.118.242.226
  Name: imap.ge.xfinity.com
  Address: 96.118.242.217
  Name: imap.ge.xfinity.com
  Address: 96.118.242.208
  Name: imap.ge.xfinity.com
  Address: 96.118.242.230
  Name: imap.ge.xfinity.com
  Address: 96.118.242.232
  Name: imap.ge.xfinity.com
  Address: 96.118.242.218
  Name: imap.ge.xfinity.com
  Address: 96.118.242.211
  Name: imap.ge.xfinity.com
  Address: 96.118.242.242
  Name: imap.ge.xfinity.com
  Address: 96.118.242.221
  Name: imap.ge.xfinity.com
  Address: 96.118.242.196
  Name: imap.ge.xfinity.com
  Address: 96.118.208.40
  Name: imap.ge.xfinity.com
  Address: 96.118.208.99
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fee8:4f07
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe7d:1b0c
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe25:5ae5
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fef6:babc
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe87:c172
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fee6:7a57
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:9:f816:3eff:fe0f:a4a
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc11:2:f816:3eff:fec7:cb93
  Name: imap.ge.xfinity.com
  Address: 2001:558:fee2:1000:f816:3eff:fe42:4f14
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe33:9aaa
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:feb2:8c0d
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fef1:25a5
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:febd:320a
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe36:aba3
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe3f:76f2
  Name: imap.ge.xfinity.com
  Address: 2001:558:fc18:0:f816:3eff:fe45:1d1e

  tom@deathstar:~$ dig mail.comcast.net

  ; <<>> DiG 9.11.4-3ubuntu5-Ubuntu <<>> mail.comcast.net
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15037
  ;; flags: qr rd ra; QUERY: 1, ANSWER: 17, AUTHORITY: 0, ADDITIONAL: 1

  ;; OPT PSEUDOSECTION:
  ; EDNS: version: 0, flags:; udp: 65494
  ;; QUESTION SECTION:
  ;mail.comcast.net.IN  A

  ;; ANSWER SECTION:
  mail.comcast.net. 15  IN  CNAME   imap.ge.xfinity.com.
  imap.ge.xfinity.com.  12  IN  A   96.117.3.119
  imap.ge.xfinity.com.  12  IN  A   96.117.3.96
  imap.ge.xfinity.com.  12  IN  A   96.117.3.143
  imap.ge.xfinity.com.  12  IN  A   96.117.3.145
  imap.ge.xfinity.com.  12  IN  A   96.117.3.129
  imap.ge.xfinity.com.  12  IN  A   96.117.3.148
  imap.ge.xfinity.com.  12  IN  A   96.117.3.201
  imap.ge.xfinity.com.  12  IN  A   96.117.3.136
  imap.ge.xfinity.com.  12  IN  A   96.118.133.238
  imap.ge.xfinity.com.  12  IN  A   96.117.3.128
  imap.ge.xfinity.com.  12  IN  A   96.117.3.144
  imap.ge.xfinity.com.  12  IN  A   96.117.2.238
  imap.ge.xfinity.com.  12  IN  A   96.117.3.110
  imap.ge.xfinity.com.  12  IN  A   96.117.3.140
  imap.ge.xfinity.com.  12  IN  A   96.117.3.154
  imap.ge.xfinity.com.  12  IN  A   96.117.3.132

  ;; Query time: 13 msec
  ;; SERVER: 127.0.0.53#53(127.0.0.53)
  ;; WHEN: Tue Nov 20 06:58:31 PST 2

[Touch-packages] [Bug 1807749] Re: NFS V4 does not mount at system start

2018-12-11 Thread Francis Ginther

** Tags added: id-5c0edd402116a7823a36c543

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

Title:
  NFS V4 does not mount at system start

Status in network-manager package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  New

Bug description:
  Hi,

  i'm running a view Ubuntu 18.10 Clients on a Ubuntu 18.04 NFS V4
  Server. I'm using Kerberos for user authentication and LDAP for user
  and group synchronisation.

  The shares are added to the /etc/fstab on my clients and they should be 
mounted automatically at system boot. Here is an example line from fstab:
  nfs.server:/users /home   nfs4
sec=krb5i,soft,_netdev,auto  0  0

  But after the system has booted and the Login-Screen appears the nfs
  shares are not mounted on the client. Attached to this bug, you can
  find an export of my journald entries from my last boot.

  When I read this log carefully I find the following start order of relevant 
services:
  Begin start nss_ldap (from line 822 on)
  Begin start NetworkManager (from line 1198) 
  Get IP from DHCP (line 2542)
  NetworkManager Online (line 2551)
  Try to mount NFS Shares (from line 2253)
  nss_ldap connected (line 2761)

  As far as I understand my setup, I do not have DNS before nss_ldap is
  started. But since mounting the NFS shares needs DNS, the NFS mount
  sequence should start after nss_ldap is fully started.

  Thanks for your help

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1807749/+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 1806487] Re: [regression] Crashing with dbus.exceptions.DBusException when logind can't be started (yet)

2018-12-15 Thread Francis Ginther

** Tags added: id-5c1281350678792b80fdc206

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

Title:
  [regression] Crashing with dbus.exceptions.DBusException when logind
  can't be started (yet)

Status in unattended-upgrades package in Ubuntu:
  Fix Released
Status in unattended-upgrades source package in Xenial:
  Fix Committed
Status in unattended-upgrades source package in Bionic:
  Fix Committed
Status in unattended-upgrades source package in Cosmic:
  Fix Committed

Bug description:
  [Impact]

   * Unattended-upgrades.service may crash due to starting earlier than dbus 
and logind are up or due to logind failing to start.
   * Unattended-upgrades.service not starting prevents installation of upgrades 
on shutdown (when u-u is configured to do that) and also prevents gracefully 
stopping running u-u _before_ shutdown as implemented in LP: #1803137. U-u is 
still stopped gracefully after the shutdown transaction is started, but that 
may let service restarts hang the upgrade process.
   * The fix is adding an After service dependency on systemd-logind to ensure 
starting u-u.service after logind at least tried to start and also changing 
u-u-s to start even with logind's absence.

  [Test Case]

   * Stop systemd-logind and make it unable to start for example by
  masking it:

  root@bb-logind:~# ln -s /dev/null /etc/systemd/system/systemd-logind.service
  root@bb-logind:~# systemctl daemon-reload
  root@bb-logind:~# service systemd-logind stop
  root@bb-logind:~# service systemd-logind status
  ● systemd-logind.service
     Loaded: masked (/dev/null; bad)
     Active: inactive (dead) since Thu 2018-12-13 13:02:44 UTC; 1s ago
   Main PID: 1938 (code=killed, signal=TERM)
     Status: "Processing requests..."
  ...

   * Run u-u-s and observe it crashing in unfixed version and starting
  with falling back to polling logind instead taking the inhibition lock
  at its start:

  root@bb-logind:~# /usr/share/unattended-upgrades/unattended-upgrade-shutdown 
--debug 
  root@bb-logind:~# tail 
/var/log/unattended-upgrades/unattended-upgrades-shutdown.log 
  ...
  2018-12-13 14:30:17,600 WARNING - Could not get delay inhibitor lock
  2018-12-13 14:30:17,601 DEBUG - Skip waiting for signals, starting operation 
now
  2018-12-13 14:30:17,601 DEBUG - Starting countdown of 25.0 minutes
  2018-12-13 14:30:17,602 DEBUG - Initializing apt_pkg configuration
  2018-12-13 14:30:17,602 DEBUG - get_lock returned 7
  2018-12-13 14:30:17,602 DEBUG - lock not taken

  
   * Restore logind's ability to start

  root@bb-logind:~# rm /etc/systemd/system/systemd-logind.service
  root@bb-logind:~# systemctl daemon-reload

   * Restart unattended-upgrades.service

  root@bb-logind:~# service unattended-upgrades restart
  root@bb-logind:~# service unattended-upgrades status 
  ● unattended-upgrades.service - Unattended Upgrades Shutdown
 Loaded: loaded (/lib/systemd/system/unattended-upgrades.service; enabled; 
vendor preset: enabled)
 Active: active (running) since Thu 2018-12-13 14:31:43 UTC; 3s ago
   Docs: man:unattended-upgrade(8)
   Main PID: 4129 (unattended-upgr)
  Tasks: 2 (limit: 4915)
 CGroup: /system.slice/unattended-upgrades.service
 └─4129 /usr/bin/python3 
/usr/share/unattended-upgrades/unattended-upgrade-shutdown --wait-for-signal

  Dec 13 14:31:43 bb-logind systemd[1]: Started Unattended Upgrades Shutdown.
  root@bb-logind:~# tail 
/var/log/unattended-upgrades/unattended-upgrades-shutdown.log 
  2018-12-13 14:30:17,601 DEBUG - Starting countdown of 25.0 minutes
  2018-12-13 14:30:17,602 DEBUG - Initializing apt_pkg configuration
  2018-12-13 14:30:17,602 DEBUG - get_lock returned 7
  2018-12-13 14:30:17,602 DEBUG - lock not taken
  2018-12-13 14:31:43,595 WARNING - SIGTERM or SIGHUP received, stopping 
unattended-upgradesonly if it is running
  2018-12-13 14:31:43,688 WARNING - Could not get delay inhibitor lock
  2018-12-13 14:31:43,691 WARNING - Unable to monitor PrepareForShutdown() 
signal, polling instead.
  2018-12-13 14:31:43,691 WARNING - Maybe systemd-logind service is not running.
  2018-12-13 14:31:43,691 WARNING - Unable to monitor PrepareForShutdown() 
signal, polling instead.
  2018-12-13 14:31:43,691 WARNING - To enable monitoring the 
PrepareForShutdown() signal instead of polling please install the python3-gi 
package

  root@bb-logind:~# systemd-analyze dot | grep unattended
  ...
  "unattended-upgrades.service"->"systemd-logind.service" [color="green"];
  ...

  [Regression Potential]

   * The change to service ordering is unlikely to cause any issue, but
  the graceful handling of missing logind involved a small-scale
  refactoring of u-u-s's code. Extensive testing did not reveal
  regressions in that area, but potential bugs may cause u-u.service
  fail to start and affect graceful shutdown of u-u the same way as
  deta

[Touch-packages] [Bug 1796193] Re: DistUpgradeViewNonInteractive crashes / requires interaction

2019-05-11 Thread Francis Ginther

** Tags added: id-5cd5d40bf1c69c651a522b2f

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

Title:
  DistUpgradeViewNonInteractive crashes / requires interaction

Status in apt package in Ubuntu:
  Incomplete
Status in ubuntu-release-upgrader package in Ubuntu:
  Fix Released
Status in apt source package in Cosmic:
  New
Status in ubuntu-release-upgrader source package in Cosmic:
  In Progress
Status in apt source package in Disco:
  New
Status in ubuntu-release-upgrader source package in Disco:
  In Progress
Status in apt source package in Eoan:
  Incomplete
Status in ubuntu-release-upgrader source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  The NonInteractive view of ubuntu-release-upgrader doesn't work so it is hard 
to automate upgrade testing.

  [Test Case]
  You need to create a situation where you'll receive a conffile prompt since 
the handling of those is broken.

  1) On a bionic system modify /etc/update-manager/release-upgrades so that 
Prompt=normal
  2) Test an upgrade from bionic to cosmic or disco i.e. run do-release-upgrade
  3) Observe the upgrade hang on the '/etc/update-manager/release-upgrades' 
conffifle and the following in /var/log/dist-upgrade/main.log
  "2019-05-10 21:21:21,313 WARNING got a conffile-prompt from dpkg for file: 
'/etc/update-manager/release-upgrades'
  2019-05-10 21:21:26,319 ERROR error 'a bytes-like object is required, not 
'str'' when trying to write to the conffile"

  With the version of the release-upgrader from -proposed you'll no
  longer observe the upgrade process hanging.

  [Regression Potential]
  The fix is making it so that a byte object is passed to the prompt instead of 
a string one so there really isn't one.

  [Original Description]
  I'm trying to do some automated testing that involved upgrading a system from 
xenial to bionic, so I need it to not ask for user input.

  Before running do-release-upgrade, the system got a fresh dist-upgrade
  and reboot.

  To avoid interactive responses, I'm using:
  $ sudo do-release-upgrade -d -f DistUpgradeViewNonInteractive

  Part way through the upgrade, I do get prompted for something though:
  Preparing to unpack .../apt_1.6.3ubuntu0.1_amd64.deb ...

  Unpacking apt (1.6.3ubuntu0.1) over (1.2.27) ...

  Processing triggers for libc-bin (2.27-3ubuntu1) ...

  /sbin/ldconfig.real: Warning: ignoring configuration file that cannot
  be opened: /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf: No such file
  or directory

  /sbin/ldconfig.real: Warning: ignoring configuration file that cannot
  be opened: /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf: No such file or
  directory

  Setting up apt (1.6.3ubuntu0.1) ...

  Installing new version of config file /etc/apt/apt.conf.d/01autoremove
  ...

  Configuration file '/etc/cron.daily/apt-compat'

   ==> Deleted (by you or by a script) since installation.

   ==> Package distributor has shipped an updated version.

     What would you like to do about it ?  Your options are:

  Y or I  : install the package maintainer's version

  N or O  : keep your currently-installed version

    D : show the differences between the versions

    Z : start a shell to examine the situation

   The default action is to keep your current version.

  Comparing the sha1 of apt-compat before the upgrade to another xenial
  system that has been unmodified, they are the same:

  In /var/log/dist-upgrade/main.log, I also found this:
  2018-10-04 14:20:24,575 WARNING got a conffile-prompt from dpkg for file: 
'/etc/cron.daily/apt-compat'
  2018-10-04 14:20:29,580 ERROR error 'a bytes-like object is required, not 
'str'' when trying to write to the conffile

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1796193/+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 1821640] Re: Missing pattern for linux-image-unsigned keeps autoremovable kernels on the system

2019-05-14 Thread Francis Ginther

** Tags added: id-5ca77e29a04a8142d5a182be

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

Title:
  Missing pattern for linux-image-unsigned keeps autoremovable kernels
  on the system

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Xenial:
  In Progress
Status in apt source package in Bionic:
  In Progress
Status in apt source package in Cosmic:
  In Progress
Status in apt source package in Disco:
  Fix Committed
Status in apt source package in Eoan:
  Fix Released

Bug description:
  [Impact]
  Unattended-upgrades keeps versioned kernel packages because they don't match 
known kernel package patterns:

  ...
  Keeping auto-removable linux-modules-4.18.0-14-generic package(s) because it 
would also remove the following packages which should be kept in this step: 
linux-image-unsigned-4.18.0-14-generic
  ...

  For reproduction see LP: #1795696, but running u-u with --verbose.

  And APT does not apply proper kernel-version based protection to it.

  [Test case]
  linux-image-unsigned should popup in the same list in 01autoremove-kernels as 
linux-signed-image, and should be autoremovable iff it's signed counterpart is 
autoremovable.

  [Regression potential]
  Not really any, it's just an additional string in the entry. The only 
difference really possible therefore is that the set of autoremovable packages 
changes and unattended-upgrades and friends might autoremove different sets of 
them.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1821640/+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 1543799] Re: isc-dhcp-server & isc-dhcp-server6 systemd service units use the same RuntimeDirectory leading to loss of pid files

2019-05-15 Thread Francis Ginther

** Tags added: id-5cdaf962074a7f2d10cef7b9

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

Title:
  isc-dhcp-server & isc-dhcp-server6 systemd service units use the same
  RuntimeDirectory leading to loss of pid files

Status in isc-dhcp package in Ubuntu:
  Triaged
Status in isc-dhcp source package in Xenial:
  Triaged
Status in isc-dhcp source package in Bionic:
  Triaged
Status in isc-dhcp source package in Cosmic:
  Triaged
Status in isc-dhcp source package in Disco:
  Triaged

Bug description:
  dhcpd reports 'Can't create PID file /run/dhcp-server/dhcpd.pid' (or
  '/run/dhcp-server/dhcpd6.pid' for isc-dhcp-server6), and no file is
  found /run/dhcp-server.

  Additionally, both isc-dhcp-server & isc-dhcp-server6 service unit
  files specify the RuntimeDirectory 'dhcp-server', which is removed
  when either unit stops (and thus would wipe out the other unit's pid
  file, were it being successfully written).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: isc-dhcp-server 4.3.3-5ubuntu4
  ProcVersionSignature: Ubuntu 4.4.0-2.16-generic 4.4.0
  Uname: Linux 4.4.0-2-generic x86_64
  ApportVersion: 2.19.4-0ubuntu2
  Architecture: amd64
  Date: Tue Feb  9 21:34:08 2016
  InstallationDate: Installed on 2016-02-09 (0 days ago)
  InstallationMedia: Ubuntu-Server 16.04 LTS "Xenial Xerus" - Alpha amd64 
(20160206)
  ProcEnviron:
   LANGUAGE=en_GB:en
   TERM=linux
   PATH=(custom, no user)
   LANG=en_GB.UTF-8
   SHELL=/bin/bash
  SourcePackage: isc-dhcp
  UpgradeStatus: No upgrade log present (probably fresh install)
  modified.conffile..etc.dhcp.dhcpd.conf: [modified]
  mtime.conffile..etc.dhcp.dhcpd.conf: 2016-02-09T21:11:20.104056

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/isc-dhcp/+bug/1543799/+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 1811471] Re: local resolver stub fails to handle multiple TCP dns queries

2019-05-17 Thread Francis Ginther

** Tags added: id-5cde5f8331588344774efccb

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

Title:
  local resolver stub fails to handle multiple TCP dns queries

Status in systemd:
  Fix Released
Status in resolvconf package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Fix Released
Status in resolvconf source package in Bionic:
  Triaged
Status in systemd source package in Bionic:
  Fix Released
Status in resolvconf source package in Cosmic:
  Triaged
Status in systemd source package in Cosmic:
  Fix Released
Status in resolvconf source package in Disco:
  Triaged
Status in systemd source package in Disco:
  Fix Released

Bug description:
  [Impact]

  The systemd local 'stub' resolver handles all local DNS queries (by
  default configuration used in Ubuntu), and essentially proxies all
  requests to its configured upstream DNS resolvers.

  Most local DNS resolution by applications uses glibc's getaddrinfo()
  function.  This function is configured in various ways by the
  /etc/resolv.conf file, which tells glibc what nameserver/resolver to
  contact as well as how to talk to the name server.

  By default, glibc performs UDP DNS queries, with a single DNS query
  per UDP packet.  The UDP packet size is limited per DNS spec to 512
  bytes.  For some DNS lookups, a 512 byte UDP packet is not large
  enough to contain the entire response - for example, an A record
  lookup with a large number (e.g. 30) of A record addresses.  This
  number of A record entries is possible in some cases of load
  balancing.  When the DNS UDP response size is larger than 512 bytes,
  the server puts as much response as it can into the DNS UDP response,
  and marks the "trunacted" flag.  This lets glibc know that the DNS UDP
  packet did not contain the entire response for all the A records.

  When glibc sees a UDP response that is "trunacted", by default it
  ignores the contents of that response and issues a new DNS query,
  using TCP instead of UDP.  The TCP packet size has a higher size limit
  (though see bug 1804487 which is a bug in systemd's max-sizing of TCP
  DNS packets), and so *should* allow glibc to receive the entire DNS
  response.

  However, glibc issues DNS queries for both A and  records.  When
  it uses UDP, those DNS queries are separate (i.e. one UDP DNS packet
  with a single A query, and one UDP DNS packet with a single 
  query).  When glibc uses TCP, it puts both DNS queries into a single
  TCP DNS packet - the RFC refers to this as "pipelining"
  (https://tools.ietf.org/html/rfc7766#section-6.2.1.1) and states that
  clients SHOULD do this, and that servers MUST expect to receive
  pipelined queries and SHOULD respond to all of them.  (Technically
  pipelining can be separate DNS queries, one per TCP packet, but both
  using the same TCP connection - but the clear intention of pipelining
  is to improve TCP performance, and putting both DNS queries into a
  single TCP packet is clearly more performant than using separate TCP
  packets).

  Unfortunately, systemd's local stub resolver has only very basic
  support for TCP DNS, and it handles TCP DNS queries almost identically
  to UDP DNS queries - it reads the DNS query 2-byte header (containing
  the length of the query data), reads in the single DNS query data,
  performs lookup and sends a response to that DNS query, and closes the
  TCP connection.  It does not check for "pipelined" queries in the TCP
  connection.

  That would be bad enough, as glibc is (rightly) expecting a response
  to both its A and  queries; however what glibc gets is a TCP
  connection-reset error.  That is because the local systemd stub
  resolver has closed its TCP socket while input data was still pending
  (i.e. it never even read the second pipelined DNS query).  When the
  kernel sees unread input bytes in a TCP connection that is closed, it
  sends a TCP RST to the peer (i.e. glibc) and when the kernel sees the
  RST, it dumps all data in its socket buffer and passes the ECONNRESET
  error up to the application.  So glibc gets nothing besides a
  connection reset error.

  Note also that even if the systemd local stub resolver's socket
  flushes its input buffer before closing the TCP connection (which will
  avoid the TCP RST), glibc still expects responses to both its A and
   queries before systemd closes the TCP connection, and so a simple
  change to systemd to flush the input buffer is not enough to fix the
  bug (and would also not actually fix the bug since glibc would never
  get the  response).

  [Test Case]

  This can be reproduced on any system using a local systemd stub
  resolver, when using an application that uses getaddrinfo() - such as
  ssh, telnet, ping, etc - or with a simple C program that uses
  getaddrinfo().  The dns name looked up must have enough A records to
  overflow

[Touch-packages] [Bug 1572752] Re: improve UTC setting migration on upgrades

2019-05-18 Thread Francis Ginther

** Tags added: id-5cdeb9fd019d774244463b71

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

Title:
improve UTC setting migration on upgrades

Status in sysvinit package in Ubuntu:
Invalid
Status in sysvinit source package in Xenial:
Triaged

Bug description:
[SRU Justification]
On upgrade, some users who have selected a non-default setting for their
clock handling in the installer will see prompts for a conffile they never
edited by hand.

[Regression potential]
Because we are adding a pre-dependency to a package, there is risk of this
causing upgrade failures. The upgrade path should be tested aggressively with
different profiles from both 14.04 and 15.10 before publishing to -updates.

[Test case]
1. On a newly-installed 14.04 system, edit /etc/default/rcS to contain
'UTC=no' instead of 'UTC=yes'. Make no other changes to this file.
2. Enable -proposed in your apt sources.
3. Run do-release-upgrade or update-manager to upgrade to 16.04.
4. Confirm that the upgrade succeeds.
5. Confirm that you are not shown a conffile prompt for /etc/default/rcS on
upgrade.
6. Confirm that /etc/adjtime has been created, with 'LOCAL' as the third line
of the file.
7. Repeat steps 1-6 for a newly-installed 15.10 system.

slangasek | pitti: I see sysvinit Breaks: systemd (<< 228-5ubuntu3), but that
doesn't enforce systemd 228-5ubuntu3 being configured before sysvinit, which
means the conffile may already be migrated away before systemd postinst runs...
I think the right way to do this is with initscripts Pre-Depends: systemd, and
for initscripts' preinst script to handle any conffile cleaning so that users
are spared conffile prompts on upgrade
pitti | slangasek: ah, good point; this needs to be tested thoroughly,
pre-depends have some habit of causing trouble

See bug 1541532 and

http://launchpadlibrarian.net/236311219/systemd_228-5ubuntu2_228-5ubuntu3.diff.gz
and

http://launchpadlibrarian.net/236367969/sysvinit_2.88dsf-59.3ubuntu1_2.88dsf-59.3ubuntu2.diff.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/sysvinit/+bug/1572752/+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 1829347] Re: systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

2019-05-21 Thread Francis Ginther

** Tags added: id-5ccb0d8d44da805739b5de37

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

Title:
  systemd autopkgtest 'storage' fails adding/rmmoding scsi_debug

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  In Progress
Status in systemd source package in Disco:
  In Progress
Status in systemd source package in Eoan:
  In Progress

Bug description:
  [impact]

  systemd autopkgtest fails

  [test case]

  run systemd autopkgtest, check for output like:

  LUKS device with "tmp" option ... rmmod: ERROR: Module scsi_debug is in use
  FAIL

  ==
  FAIL: test_luks_tmp (__main__.CryptsetupTest)
  LUKS device with "tmp" option
  --
  Traceback (most recent call last):
    File "/tmp/autopkgtest.It858Q/build.e7O/src/debian/tests/storage", line 59, 
in setUp
  self.fail('%s exists already' % self.plaintext_dev)
  AssertionError: /dev/mapper/testcrypt1 exists already

  or for older releases something like:

  autopkgtest [19:27:26]: test storage: [---
  modprobe: FATAL: Module scsi_debug not found in directory 
/lib/modules/4.18.0-1011-kvm
  ERROR

  ==
  ERROR: setUpClass (__main__.CryptsetupTest)
  --
  Traceback (most recent call last):
File "/tmp/autopkgtest.azsL0q/build.Hbd/src/debian/tests/storage", line 21, 
in setUpClass
  subprocess.check_call(['modprobe', 'scsi_debug'])
File "/usr/lib/python3.6/subprocess.py", line 291, in check_call
  raise CalledProcessError(retcode, cmd)
  subprocess.CalledProcessError: Command '['modprobe', 'scsi_debug']' returned 
non-zero exit status 1.

  
  this has attempted to be fixed in disco/eoan so the output is a bit different 
across different releases, but all of them have the common point of failing to 
modprobe or rmmod the scsi_debug module, which by itself doesn't indicate a 
failure.

  [regression potential]

  low; this is fixing a testcase only.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1829347/+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 1829401] Re: gi.repository.GLib.GError: pk-client-error-quark: could not do untrusted question as no klass support

2019-05-24 Thread Francis Ginther

** Tags added: id-5ce6bfe06de363297ab7cde9

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

Title:
  gi.repository.GLib.GError: pk-client-error-quark: could not do
  untrusted question as no klass support

Status in packagekit package in Ubuntu:
  Triaged
Status in packagekit source package in Eoan:
  Triaged

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
software-properties.  This problem was most recently seen with package version 
0.98.2, the problem page at 
https://errors.ubuntu.com/problem/300ff7bf9068dc50ace4c5db5c4a34ba0dfc926d 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

  [Back trace]
  Traceback (most recent call last):
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/DialogCacheOutdated.py", 
line 86, in on_pktask_finish
  results = self._pktask.generic_finish(result)
  gi.repository.GLib.GError: pk-client-error-quark: could not do untrusted 
question as no klass support (8)

  During handling of the above exception, another exception occurred:

  Traceback (most recent call last):
File 
"/usr/lib/python3/dist-packages/softwareproperties/gtk/DialogCacheOutdated.py", 
line 89, in on_pktask_finish
  Gtk.ButtonsType.CANCEL, _("Error while refreshing cache"))
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 319, 
in new_init
  return super_init_func(self, **new_kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 575, in 
__init__
  self._init(*args, **new_kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 319, 
in new_init
  return super_init_func(self, **new_kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/Gtk.py", line 521, in 
__init__
  _window_init(self, *args, **kwargs)
File "/usr/lib/python3/dist-packages/gi/overrides/__init__.py", line 319, 
in new_init
  return super_init_func(self, **new_kwargs)
  TypeError: could not convert value for property `transient_for' from 
DialogCacheOutdated to GtkWindow

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/packagekit/+bug/1829401/+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 1829968] Re: motd [on at least some instances] does not auto-update daily

2019-05-25 Thread Francis Ginther

** Tags added: id-5ce840b53fe9fc1ccbddc1fa

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

Title:
  motd [on at least some instances] does not auto-update daily

Status in base-files package in Ubuntu:
  Triaged
Status in base-files source package in Bionic:
  Triaged

Bug description:
  I have a VM running on AWS. It was launched on May 9th:

$ uptime
 05:26:21 up 12 days,  6:34,  1 user,  load average: 0.00, 0.00, 0.00
$ date
Wed May 22 05:26:24 UTC 2019

  I touched none of the system defaults, and yet the motd has not
  updated automatically.

$ ls -l /var/cache/motd-news
-rw-r--r-- 1 root root 0 May  9 22:53 /var/cache/motd-news

  The systemd timer unit looks like this:

$ systemctl status motd-news.timer 
● motd-news.timer - Message of the Day
   Loaded: loaded (/lib/systemd/system/motd-news.timer; enabled; vendor 
preset: enabled)
   Active: active (elapsed) since Thu 2019-05-09 22:51:58 UTC; 1 weeks 5 
days ago
  Trigger: n/a

May 09 22:51:58 ip-172-31-23-224 systemd[1]: Started Message of the
  Day.

  If I run /etc/update-motd.d/50-motd-news --force manually, the file
  does update correctly.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1829968/+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 1830169] Re: lvm udev rule fails to call systemd-run

2019-06-03 Thread Francis Ginther

** Tags added: id-5cf4e60af7841930654ed12b

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

Title:
  lvm udev rule fails to call systemd-run

Status in Ubuntu on IBM z Systems:
  In Progress
Status in lvm2 package in Ubuntu:
  Fix Released
Status in lvm2 source package in Xenial:
  New
Status in lvm2 source package in Bionic:
  New
Status in lvm2 source package in Cosmic:
  New
Status in lvm2 source package in Disco:
  New
Status in lvm2 source package in Eoan:
  Fix Released

Bug description:
  In /lib/udev/rules.d/69-lvm-metad.rules file, it calls /bin/systemd-run 
command during removal ---  
 ACTION!="remove", ENV{LVM_PV_GONE}=="1", RUN+="/bin/systemd-run /sbin/lvm 
pvscan --cache $major:$minor", GOTO="lvm_end"

  But /bin/systemd-run is not found,  in fact systemd-run is in /usr/bin
  /systemd-run.

  xx:~$ cat /etc/issue
  Ubuntu 18.04.2 LTS \n \l

  xx:~$ ls /bin/systemd-run
  ls: cannot access '/bin/systemd-run': No such file or directory

  xx:~$ ls /usr/bin/systemd-run
  /usr/bin/systemd-run

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1830169/+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 1825000] Re: Add ability for mirrors to distinguish interactive and non-interactive apt runs

2019-06-07 Thread Francis Ginther

** Tags added: id-5cf9354bf2165a4e38392bbb

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

Title:
  Add ability for mirrors to distinguish interactive and non-interactive
  apt runs

Status in apt package in Ubuntu:
  Triaged
Status in apt source package in Eoan:
  Triaged

Bug description:
  As part of a larger scale plan to manage traffic to the main archive
  servers it would be useful if apt could provide a facility for us to
  identify interactive vs. non-interactive traffic on the server side,
  ideally via a header of some kind.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1825000/+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 1831252] Re: panic=-1 is completely ignored by the initrd causing unexpected behaviour

2019-06-07 Thread Francis Ginther

** Tags added: id-5cf9304627a12b717bdbab7a

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

Title:
  panic=-1 is completely ignored by the initrd causing unexpected
  behaviour

Status in initramfs-tools package in Ubuntu:
  New
Status in initramfs-tools source package in Xenial:
  New
Status in initramfs-tools source package in Bionic:
  New
Status in initramfs-tools source package in Eoan:
  New

Bug description:
  in Ubuntu Core we default to using panic=-1 on the kernel command line
  (documented at [1]) to speed up the auto-rollback mechanism of the
  kernel. on a kernel level this works just fine and the system reboots
  immediately ...

  when in the initramfs during boot and a panic occurs, no reboot
  happens at all, the initrd spawns a shell regardless of the panic=
  value ...

  this is caused by a filter in  /usr/share/initramfs-tools/init

  panic=*)
  panic="${x#panic=}"
  case ${panic} in
  *[![:digit:].]*)
  panic=
  ;;
  esac
  ;;

  this function only lets positive values through, else panic= simply
  gets unset

  the panic() function itself is also not capable of handling negative
  values, it has a sleep call that interprets negative values as
  commandline options instead of simply ignoring a negative sleep time
  [2] (line 11).

  the filter in the init script should allow the -1 value (to comply
  with the kernel documentation and behaviour) and the panic() function
  should properly skip the sleep call when a negative value for panic=
  is set.

  [1] 
https://github.com/torvalds/linux/blob/v4.17/Documentation/admin-guide/kernel-parameters.txt#L2931
  [2] https://paste.ubuntu.com/p/mswD8Cd869/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831252/+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 1798369] Re: Reinstall Ubuntu (with preserving existing data) shows error message due to "Could not get lock /target/var/cache/apt/archives/lock"

2019-06-07 Thread Francis Ginther

** Tags added: id-5cf932c4a06ae8470c614fa6

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

Title:
  Reinstall Ubuntu (with preserving existing data) shows error message
  due to "Could not get lock /target/var/cache/apt/archives/lock"

Status in APT:
  New
Status in ubiquity:
  New
Status in apt package in Ubuntu:
  Invalid
Status in ubiquity package in Ubuntu:
  Confirmed

Bug description:
  When trying to reinstall an existing Ubuntu cosmic installation using
  latest 18.10 desktop images, the install shows an error dialog around
  the end of the installation with an "Error restoring installed
  applications". Looking at the syslog such a traceback can be seen:

  apt_pkg.Error: E:Could not get lock
  /target/var/cache/apt/archives/lock - open (11: Resource temporarily
  unavailable), E:Unable to lock directory
  /target/var/cache/apt/archives/

  After reproducing this on a live session, after chrooting into /target
  indeed any apt-get install operations result in the same lock-file
  error. The whole syslog of the reinstall attached to the bug.

  Test case:
   * Download latest cosmic image
   * Install cosmic on the whole disk (can be on a VM)
   * (optional) Boot into the system and leave a file in the home directory (to 
leave a trace, just in case)
   * Reboot and install cosmic using the first option in ubiquity: Reinstall 
Ubuntu
   * Finish configuration

  The install itself doesn't fail, but around the end of the
  installation process the error dialog appears. System is still
  bootable but left with old packages.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apt/+bug/1798369/+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 1832120] Re: i386 - Test fails 'test_get_file_package_uninstalled_multiarch'

2019-06-11 Thread Francis Ginther

** Tags added: id-5cfe7e5d8c5fcb19686df874

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

Title:
  i386 - Test fails 'test_get_file_package_uninstalled_multiarch'

Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Version: 2.20.11-0ubuntu2
  Release: Eoan 19.10

  This failure is currently blocking Konsole 19.04.2-0ubuntu1 from
  migrating from proposed.

  The test 'test_get_file_package_uninstalled_multiarch' now appears to
  be failing, at least the majority of the time, on i386 with:

  FAIL: test_get_file_package_uninstalled_multiarch (__main__.T)
  get_file_package() on foreign arches and releases
  --
  Traceback (most recent call last):
    File "./test_backend_apt_dpkg.py", line 346, in 
test_get_file_package_uninstalled_multiarch
  True, cache_dir, arch='even')
  AssertionError: OSError not raised by get_file_package

  The test history can be seen here:

  http://autopkgtest.ubuntu.com/packages/a/apport/eoan/i386

  This fails against multiple triggers, including itself in the release
  pocket.

  I would also note that the same failure has been seen recently on
  amd64:

  http://autopkgtest.ubuntu.com/packages/a/apport/eoan/amd64

  however that then passed on subsequent retries. Something that does
  not seem to be the case after multiple retries on i386.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1832120/+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 1831736] Re: [MIR] lz4 by default

2019-06-13 Thread Francis Ginther

** Tags added: id-5d0162d5caee4b55443d4eda

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

Title:
  [MIR] lz4 by default

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in live-build package in Ubuntu:
  Fix Released
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in lz4 package in Ubuntu:
  Fix Released
Status in partman-auto package in Ubuntu:
  Triaged
Status in ubuntu-release-upgrader package in Ubuntu:
  Triaged

Bug description:
  Use `lz4 -9 -l` compression for initramfs by default as discussed on
  ubuntu-devel.

  This would also pull the lz4 package into main

  https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040726.html

  [Regression Potential]

  We are trying to optimize for total boot speed, but performing a
  micro-optimization upon time to create/unpack kernel/initrd is an
  insufficient benchmark for total boot speed. This is because it
  ignores time to load the kernel/initrd, and whether the
  firmware/bootloader were able to stream decompress it whilst loading
  it. I.e. it is argued that in the real world, subsecond decompression
  gains are irrelevant if UEFI firmware, tftp boot, etc. take a lot
  longer than that to read extra 10s of MBs of boot material.

  [TODO]
  Measure pure i/o load speed with stopwatch, to figure out MB/s speed of 
loading initrds/kernel off FAT32, EXT4, TFTP, HTTP.
  Re-evaluate if we should provide different compression mechanisms:
  - ie. gzip instead of lz4 for most cases (revert)
  - ie. xz for painful i/o cases (e.g. netboot)

  I booted grub2 and measured loading largish amount of files, ie. $
  date; initrd (hd0,gpt5)/initrd.img;  initrd (hd0,gpt5)/initrd.img;
  initrd (hd0,gpt5)/initrd.img; initrd (hd0,gpt5)/initrd.img; initrd
  (hd0,gpt5)/initrd.img; date

  To get a rough speed between 30 and 44 MB/s of loading these files off
  ext4 on nvme.

  With lz4 initrd taking 67M, and gzip initrd taking 59M, the grub i/o
  penalty is 0.18s whilst I gain over a second in faster decompression
  time. Overall a win.

  xz initrd is 36M meaning saving e.g. 0.8s of i/o time whilst gaining
  2.4s of decompression time, meaning overall worse than gzip.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1831736/+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 1832356] Re: Upgrade OpenSSH to 7.9p1-10 or better in stable series

2019-06-13 Thread Francis Ginther

** Tags added: id-5cf798031b7b1b7ce9d91438

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

Title:
  Upgrade OpenSSH to 7.9p1-10 or better in stable series

Status in openssh package in Ubuntu:
  Fix Released
Status in openssh source package in Bionic:
  Confirmed
Status in openssh source package in Cosmic:
  Confirmed
Status in openssh source package in Disco:
  Fix Released
Status in openssh source package in Eoan:
  Fix Released

Bug description:
  [Impact]

   * 18.04 LTS release with a long support time frame
   * There are two versions of OpenSSL shipped in 18.04:
 - obsolete 1.0.2
 - current long term supported 1.1.1 series
   * OpenSSH in 18.04 is the only package in main using libcrypto from 1.0.2
   * The fact that OpenSSH uses a different libcrypto implementation impacts 
certification, 
 compliance, and security maintenance.
   * Furthermore OpenSSH does not benefit from hardware accelerated crypto, as 
available in 1.1.1
   * Thus there is a desire to upgrade OpenSSH in 18.04 from 1:7.6p1-4 to 
1:7.9p1-10 and compile 
 against OpenSSL 1.1.1
   * 1:7.9p1-10 is currently shipped in Disco/Eoan, and it is likely that 20.04 
will ship with 
 1:8.0p1 or newer. Thus security maintainance burden is slightly increased. 
However, 1:7.9p1-10
 is likely to be shipped in the next stable Debian release, and supported 
there for a long-ish
 time including debian-lts efforts. Thus there are some synergies.

  [Upstream Changelogs]

   * https://www.openssh.com/txt/release-7.9
   * https://www.openssh.com/txt/release-7.8
   * https://www.openssh.com/txt/release-7.7

  [Test Case]

   * Install openssh-server and openssh-client, check that they depend on 
libssl1.1 and do not depend 
 on libssl1.0
   
   * Check that there are no new connectivity issues between old/new servers 
and clients,
 at the very least between various Ubuntu releases in the public clouds.

  [Regression Potential]

  v7.9

   * ssh(1), sshd(8): the setting of the new CASignatureAlgorithms
 option (see below) bans the use of DSA keys as certificate
 authorities.

  DSA keys as certificate authorities are widely banned already. May
  affect connectivity.

   * sshd(8): the authentication success/failure log message has
 changed format slightly. It now includes the certificate
 fingerprint (previously it included only key ID and CA key
 fingerprint).

  This may impact log parsers, i.e. logwatch and similar. Possibly worth
  a NEWS entry.

  v7.8

   * ssh-keygen(1): write OpenSSH format private keys by default
 instead of using OpenSSL's PEM format. The OpenSSH format,
 supported in OpenSSH releases since 2014 and described in the
 PROTOCOL.key file in the source distribution, offers substantially
 better protection against offline password guessing and supports
 key comments in private keys. If necessary, it is possible to write
 old PEM-style keys by adding "-m PEM" to ssh-keygen's arguments
 when generating or updating a key.

  Normally, it shouldn't matter which format newly generated keys use.
  Existing keys remain unchanged. Systems that automatically
  generate/parse/store keys may be impacted. The risk here is low. As
  potential mitigation we can revert the default back to PEM for the SRU
  into bionic.

   * sshd(8): remove internal support for S/Key multiple factor
 authentication. S/Key may still be used via PAM or BSD auth.

  S/Key is not widely deployed. Most common OTP implementations use PAM
  stack, and use HOTP, TOTP, Yubikey and similar one time passwords,
  rather than S/Key. This is deemed low.

   * ssh(1): remove vestigal support for running ssh(1) as setuid. This
 used to be required for hostbased authentication and the (long
 gone) rhosts-style authentication, but has not been necessary for
 a long time. Attempting to execute ssh as a setuid binary, or with
 uid != effective uid will now yield a fatal error at runtime.

  This is security and hardening improvement. We do not ship sshd
  setuid.

   * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar
 HostbasedAcceptedKeyTypes options have changed. These now specify
 signature algorithms that are accepted for their respective
 authentication mechanism, where previously they specified accepted
 key types. This distinction matters when using the RSA/SHA2
 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their
 certificate counterparts. Configurations that override these
 options but omit these algorithm names may cause unexpected
 authentication failures (no action is required for configurations
 that accept the default for these options).

  This is potentially a problem. We can add upgrade hooks to warn users
  about these, or abort the upgrade. This will require user
  conf

[Touch-packages] [Bug 1832370] Re: Unable to configure or disable TLS 1.3 via openssl.cnf

2019-06-14 Thread Francis Ginther

** Tags added: id-5d0269c526b1af4a5c615490

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

Title:
  Unable to configure or disable TLS 1.3 via openssl.cnf

Status in openssl package in Ubuntu:
  Incomplete
Status in openssl source package in Bionic:
  Incomplete
Status in openssl source package in Cosmic:
  Incomplete
Status in openssl source package in Disco:
  Incomplete
Status in openssl source package in Eoan:
  Incomplete

Bug description:
  [Description]

  Since OpenSSL 1.1.1 was backported to Bionic, some (all?) applications
  gained access to TLS 1.3 by default. The applications that were not
  rebuilt against OpenSSL 1.1.1 can't tune the TLS 1.3 settings
  (protocol, ciphersuites selection, ciphersuites order) like it's
  possible with 1.2 and below. As such, one should turn to configuring
  /etc/ssl/openssl.cnf to alter TLS 1.3 settings.

  Here is how I'd expect to be able to turn off TLS 1.3:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:15:23.805113804 -0400
  @@ -12,6 +12,16 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +MaxProtocol = TLSv1.2
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  This doesn't work as 'openssl s_client -connect
  rproxy.sdeziel.info:443' negotiates TLS 1.3 with
  TLS_AES_256_GCM_SHA384.

  
  Similarly, trying to change the 'Ciphers' or the 'Ciphersuites' list with:

  # diff -Naur /etc/ssl/openssl.cnf{.orig,}
  --- /etc/ssl/openssl.cnf.orig 2019-06-11 10:33:02.330143086 -0400
  +++ /etc/ssl/openssl.cnf  2019-06-11 11:37:23.362889367 -0400
  @@ -12,6 +12,17 @@
   HOME = .
   RANDFILE = $ENV::HOME/.rnd
   
  +ssl_conf = ssl_sect
  +
  +[ssl_sect]
  +
  +system_default = system_default_sect
  +
  +[system_default_sect]
  +
  +Ciphers = TLS_AES_128_GCM_SHA256
  +Ciphersuites = TLS_AES_128_GCM_SHA256
  +
   # Extra OBJECT IDENTIFIER info:
   #oid_file= $ENV::HOME/.oid
   oid_section  = new_oids

  Doesn't work as s_client keeps negotiating TLS 1.3 with
  TLS_AES_256_GCM_SHA384 (!= 128)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: openssl 1.1.1-1ubuntu2.1~18.04.1
  ProcVersionSignature: Ubuntu 4.15.0-51.55-generic 4.15.18
  Uname: Linux 4.15.0-51-generic x86_64
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.9-0ubuntu7.6
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  Date: Tue Jun 11 11:22:47 2019
  InstallationDate: Installed on 2018-07-15 (331 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Release amd64 (20180714)
  ProcEnviron:
   LANG=en_CA.UTF-8
   TERM=xterm-256color
   SHELL=/bin/bash
   XDG_RUNTIME_DIR=
   PATH=(custom, no user)
  SourcePackage: openssl
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1832370/+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 1833237] Re: skiboot ftbfs in eoan

2019-06-21 Thread Francis Ginther

** Tags added: id-5d0ba2fcdd3f47767d5ae86d

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

Title:
  skiboot ftbfs in eoan

Status in binutils:
  In Progress
Status in binutils package in Ubuntu:
  Confirmed
Status in skiboot package in Ubuntu:
  Confirmed
Status in binutils source package in Eoan:
  Confirmed
Status in skiboot source package in Eoan:
  Confirmed

Bug description:
  skiboot ftbfs in eoan

  https://launchpad.net/ubuntu/+archive/test-
  rebuild-20190614/+build/17038512/+files/buildlog_ubuntu-eoan-
  amd64.skiboot_6.2-1_BUILDING.txt.gz

  powerpc64-linux-gnu-gcc-I/<>/include -Iinclude -MMD 
-include /<>/include/config.h -I/<>/libfdt 
-I/<>/libflash -I/<>/libxz 
-I/<>/libc/include -I/<> -I/<>/libpore 
-D__SKIBOOT__ -nostdinc -isystem 
/usr/lib/gcc-cross/powerpc64-linux-gnu/8/include -DBITS_PER_LONG=64 
-DHAVE_BIG_ENDIAN -ffreestanding -DHAS_STACK_PROT -D__ASSEMBLY__ -mbig-endian 
-m64 -mabi=elfv1  -c asm/dummy_map.S -o asm/dummy_map.o
  powerpc64-linux-gnu-gcc -I/<>/include -Iinclude -MMD -include 
/<>/include/config.h -I/<>/libfdt 
-I/<>/libflash -I/<>/libxz 
-I/<>/libc/include -I/<> -I/<>/libpore 
-D__SKIBOOT__ -nostdinc -isystem 
/usr/lib/gcc-cross/powerpc64-linux-gnu/8/include -DBITS_PER_LONG=64 
-DHAVE_BIG_ENDIAN -ffreestanding -DHAS_STACK_PROT -P -E skiboot.lds.S -o 
skiboot.lds
  powerpc64-linux-gnu-ld -EB -m elf64ppc --no-multi-toc -N --build-id=none 
--whole-archive -static -nostdlib -pie -Ttext-segment=0x0 
--oformat=elf64-powerpc -o skiboot.tmp.elf -T skiboot.lds skiboot.tmp.a 
asm/dummy_map.o
  powerpc64-linux-gnu-ld: BFD (GNU Binutils for Ubuntu) 2.32.51.20190614 
internal error, aborting at ../../bfd/elf64-ppc.c:15381 in 
ppc64_elf_relocate_section

  powerpc64-linux-gnu-ld: Please report this bug.

  make[2]: *** [/<>/Makefile.main:262: skiboot.tmp.elf] Error 1
  make[2]: Leaving directory '/<>'
  make[1]: *** [debian/rules:19: override_dh_auto_build-indep] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/binutils/+bug/1833237/+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 1833236] Re: whoopsie ftbfs in eoan

2019-06-21 Thread Francis Ginther

** Tags added: id-5d0ba7e6aecdb9565b8ad098

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

Title:
  whoopsie ftbfs in eoan

Status in whoopsie package in Ubuntu:
  New
Status in whoopsie source package in Eoan:
  New

Bug description:
  whoopsie ftbfs in eoan

  https://launchpad.net/ubuntu/+archive/test-
  rebuild-20190614/+build/17048048/+files/buildlog_ubuntu-eoan-
  amd64.whoopsie_0.2.64_BUILDING.txt.gz

 dh_auto_build
make -j1
  make[1]: Entering directory '/<>'
  Package NetworkManager was not found in the pkg-config search path.
  Perhaps you should add the directory containing `NetworkManager.pc'
  to the PKG_CONFIG_PATH environment variable
  No package 'NetworkManager' found
  cc -std=c99 -c   -g -Ilib -Wall -Werror -Os -DVERSION=\"0.2.64\" -fPIC -g -O2 
-fdebug-prefix-map=/<>=. -fstack-protector-strong -Wformat 
-Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -o src/whoopsie.o 
src/whoopsie.c
  src/whoopsie.c:26:10: fatal error: glib.h: No such file or directory
   #include 
^~~~
  compilation terminated.
  make[1]: *** [Makefile:58: src/whoopsie.o] Error 1
  make[1]: Leaving directory '/<>'
  dh_auto_build: make -j1 returned exit code 2
  make: *** [debian/rules:17: build] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1833236/+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 1832651] Re: jackdbus fails to start: cannot allocate memory

2019-06-21 Thread Francis Ginther

** Tags added: id-5d0babe141a9fa1a8a1210f7

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

Title:
  jackdbus fails to start: cannot allocate memory

Status in systemd:
  Fix Released
Status in jackd2 package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Confirmed
Status in jackd2 source package in Eoan:
  Invalid
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  The `.log/jack/jackdbus.log` shows the following after trying to
  start/restart jack using "Ubuntu Studio Controls" (also tried using
  `jack_control start`):

  ERROR: Cannot lock down 82280346 byte memory area (Cannot allocate
  memory)

  This is a fresh install of Ubuntu Studio 19.04, installed via USB. The
  first thing I did after installing was check to see if jack was
  running, but unfortunately it's not working. The error would seem to
  indicate that I'm not in the `audio` group, however checking `groups`
  shows that I am in the audio group.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: jackd2 1.9.12~dfsg-2build1
  ProcVersionSignature: Ubuntu 5.0.0-13.14-lowlatency 5.0.6
  Uname: Linux 5.0.0-13-lowlatency x86_64
  ApportVersion: 2.20.10-0ubuntu27
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Wed Jun 12 18:13:25 2019
  InstallationDate: Installed on 2019-06-12 (0 days ago)
  InstallationMedia: Ubuntu-Studio 19.04 "Disco Dingo" - Release amd64 
(20190416)
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.utf8
   SHELL=/bin/bash
  SourcePackage: jackd2
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/systemd/+bug/1832651/+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 1509717] Re: Wily LVM-RAID1 – md: personality for level 1 is not loaded

2019-06-21 Thread Francis Ginther

** Tags added: id-5d0ba914f340e31a8e9f2cf1

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

Title:
  Wily LVM-RAID1 – md: personality for level 1 is not loaded

Status in linux package in Ubuntu:
  Invalid
Status in lvm2 package in Ubuntu:
  In Progress
Status in linux source package in Bionic:
  New
Status in lvm2 source package in Bionic:
  New
Status in linux source package in Cosmic:
  New
Status in lvm2 source package in Cosmic:
  New
Status in linux source package in Disco:
  New
Status in lvm2 source package in Disco:
  New
Status in linux source package in Eoan:
  Invalid
Status in lvm2 source package in Eoan:
  In Progress
Status in lvm2 package in Debian:
  Unknown

Bug description:
  After upgrading to Wily, raid1 LVs don't activate during the initrd
  phase. Since the root LV is also RAID1-mirrored, the system doesn't
  boot.

  I get the following message each time LVM tries to activate a raid1 LV:
  md: personality for level 1 is not loaded!

  Everything was fine with Vivid. I had to downgrade to Vivid kernel
  (3.19.0-30) to get my system to a usable state. I pretty much hope it
  to be a temporary workaround and I'll get the new 4.2.0 kernel work
  with Wily in days.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1509717/+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 1771858] Re: /snap/bin not in default PATH for units, snapd should ship system-environment-generators to inject /snap/bin into $PATH

2019-06-21 Thread Francis Ginther

** Tags added: id-5d0bec28939a024305398e2a

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

Title:
  /snap/bin not in default PATH for units, snapd should ship system-
  environment-generators to inject /snap/bin into $PATH

Status in snapd package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  Fix Released
Status in snapd source package in Xenial:
  Confirmed
Status in systemd source package in Xenial:
  Confirmed
Status in snapd source package in Bionic:
  Confirmed
Status in systemd source package in Bionic:
  Fix Committed
Status in snapd source package in Cosmic:
  Confirmed
Status in systemd source package in Cosmic:
  Fix Released

Bug description:
  [Impact]

   * This means that software installed via snap isn't transparently
  available for units to use.  As snaps are first-class citizens in
  Ubuntu, we should update the PATH.

   * When a generator started to be provided by systemd, it was
  recognized that $PATH is not correctly set, nonetheless, due to an
  environment bug that systemd generators run in.

  [Testcase]

  $ systemd-run /usr/bin/env
  $ journalctl -e | grep PATH

  Output should contain /snap/bin

  Output should contain a complete and a valid PATH, i.e.
  PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/snap/bin" 
or similar.

  [Regression Potential]

   * snapd generator was already fixed separately to cause no harm, when
  running under a broken systemd. With the corrected environment,
  generators will now run with a correct PATH out of the box. A slight
  change of PATH will be observed by all generators, when running in
  containers/initramfs-less boots. However most generators will not be
  affected as they typically do not execute external binaries.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1771858/+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 857472] Re: net-update verifcation checking insecure

2019-06-24 Thread Francis Ginther

** Tags added: id-5d106c1d683546484e9cb04e

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

Title:
  net-update verifcation checking insecure

Status in apt package in Ubuntu:
  Fix Released
Status in apt source package in Oneiric:
  Fix Released

Bug description:
  From:
  http://seclists.org/fulldisclosure/2011/Sep/222

  its easy to bypass the verification checking in apt-key net-update.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/857472/+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 1775457] Re: /usr/bin/pip3:ImportError:/usr/bin/pip3@9

2019-06-26 Thread Francis Ginther

** Tags added: id-5d127347b179250b9b79f461

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

Title:
  /usr/bin/pip3:ImportError:/usr/bin/pip3@9

Status in apport package in Ubuntu:
  New
Status in python-pip package in Ubuntu:
  New

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
python-pip.  This problem was most recently seen with package version 
9.0.1-2.3~ubuntu1, the problem page at 
https://errors.ubuntu.com/problem/4e26eab10247fe3383fb8c84ca8a0d8eb21abc83 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1775457/+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 1813581] Re: gpgme1.0 ftbfs in 18.04 LTS

2019-06-26 Thread Francis Ginther

** Tags added: id-5d126ca59ddb0c88fa166051

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

Title:
  gpgme1.0 ftbfs in 18.04 LTS

Status in gpgme1.0 package in Ubuntu:
  Won't Fix
Status in gpgme1.0 source package in Bionic:
  Confirmed

Bug description:
  according to
  
http://people.canonical.com/~doko/ftbfs-report/test-rebuild-20181222-bionic.html

  gpgme1.0 ftbfs.

  * Start testing of TofuInfoTest *
  Config: Using QtTest library 5.9.5, Qt 5.9.5 (x86_64-little_endian-lp64 
shared (dynamic) release build; by GCC 7.3.0)
  PASS   : TofuInfoTest::initTestCase()
  PASS   : TofuInfoTest::testTofuNull()
  PASS   : TofuInfoTest::testTofuInfo()
  PASS   : TofuInfoTest::testTofuSignCount()
  PASS   : TofuInfoTest::testTofuKeyList()
  PASS   : TofuInfoTest::testTofuPolicy()
  FAIL!  : TofuInfoTest::testTofuConflict() 'sig.validity() == 
Signature::Marginal' returned FALSE. ()
 Loc: [t-tofuinfo.cpp(458)]
  PASS   : TofuInfoTest::cleanupTestCase()
  Totals: 7 passed, 1 failed, 0 skipped, 0 blacklisted, 2386ms
  * Finished testing of TofuInfoTest *
  FAIL: t-tofuinfo

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gpgme1.0/+bug/1813581/+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 1832882] Re: libcurl-gnutls segfaults spotify client

2019-06-28 Thread Francis Ginther

** Tags added: id-5d14f42606a1fc59984d531b

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

Title:
  libcurl-gnutls segfaults spotify client

Status in curl package in Ubuntu:
  Fix Released
Status in curl source package in Disco:
  Confirmed

Bug description:
  The latest release of Spotify client segfaults in libcurl-gnutls as can be 
read in this thread on spotify support forum:
  
https://community.spotify.com/t5/Desktop-Linux/Ubuntu-19-04-deb-package-segfault/td-p/4761479

  According to one participant the work-around is to install debian
  packages libgnutls30_3.6.8-1_amd64.deb and
  libcurl3-gnutls_7.64.0-3_amd64.deb

  Ubuntu 19.04 version of the packages:
  libgnutls30 3.6.5-2ubuntu1.1
  libcurl3-gnutls 7.64.0-2ubuntu1.1

  As the bug can be resolved by installing debian packages, I assume
  Ubuntu's version of the packages is at fault and should be upgraded to
  match debian's level as soon as possible.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/1832882/+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 1843468] Re: nftables based iptables wrapper break userspace

2019-09-11 Thread Francis Ginther

** Tags added: id-5d784b79b60ef9779cc530ed

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

Title:
  nftables based iptables wrapper break userspace

Status in iptables package in Ubuntu:
  Triaged

Bug description:
  iptables just got replaced by the nftables wrappers, effectively
  changing all Ubuntu systems to using nftables rather than regular
  iptables/ip6tables/ebtables.

  Unfortunately those wrappers aren't perfect and don't convert every
  option properly, nor know about some of the available plugins for
  those commands.

  This means that unless the software using those commands are aware
  that those are wrappers and adapt their use, they may break at some
  random point in time.

  
  While nftables is clearly the way forward, just silently switching the 
existing native tools with the compat wrappers will lead to widespread breakage 
both from packages in the archive, snaps and a variety of scripts our users may 
be running.

  So far, looking around, known breakages post-nft are expected with at
  least Docker, Kubernetes and LXD but the same may be true with the
  many other packages we have that call iptables, ip6tables, ebtables or
  arptables today.

  A migration should include a proper audit of all in-archive users, see
  if they have a plan/patch for native nft interaction and if not,
  validate their use of the tools is compatible with the wrappers.

  We should also extend that to popular snaps / those we ship by
  default. Snaps make things worse as they use the tools from their base
  snap, which in LXD's case is currently 16.04 (soon to switch to
  18.04).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/iptables/+bug/1843468/+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 1843755] Re: [FFe] Please accept systemd 242 to Eoan

2019-09-13 Thread Francis Ginther

** Tags added: id-5d6fb9fb2ac215651795ec78

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

Title:
  [FFe] Please accept systemd 242 to Eoan

Status in systemd package in Ubuntu:
  Incomplete

Bug description:
  Eoan currently has 241-7ubuntu1, Debian stable has 241 and Debian testing 
moved to 242 last week.
  While version 241 is the safer choice for Eoan (from v241 and v242) since it 
is widely tested updating to v242 will allow us to carry fewer patches in Eoan 
and makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing (except 
for a few unrelated failures):
  https://bileto.ubuntu.com/#/ticket/3797

  The final version will be 242-6ubuntu1 and I'm tidying up the
  changelog, too.

  I plan merging 242-7, too, going forward but this will not need an
  FFe.

  CHANGES WITH 242:

  * In .link files, MACAddressPolicy=persistent (the default) is changed
    to cover more devices. For devices like bridges, tun, tap, bond, and
    similar interfaces that do not have other identifying information,
    the interface name is used as the basis for persistent seed for MAC
    and IPv4LL addresses. The way that devices that were handled
    previously is not changed, and this change is about covering more
    devices then previously by the "persistent" policy.

    MACAddressPolicy=random may be used to force randomized MACs and
    IPv4LL addresses for a device if desired.

    Hint: the log output from udev (at debug level) was enhanced to
    clarify what policy is followed and which attributes are used.
    `SYSTEMD_LOG_LEVEL=debug udevadm test-builtin net_setup_link 
/sys/class/net/`
    may be used to view this.

    Hint: if a bridge interface is created without any slaves, and gains
    a slave later, then now the bridge does not inherit slave's MAC.
    To inherit slave's MAC, for example, create the following file:
    ```
    # /etc/systemd/network/98-bridge-inherit-mac.link
    [Match]
    Type=bridge

    [Link]
    MACAddressPolicy=none
    ```

  * The .device units generated by systemd-fstab-generator and other
    generators do not automatically pull in the corresponding .mount 
unit
    as a Wants= dependency. This means that simply plugging in the 
device
    will not cause the mount unit to be started automatically. But 
please
    note that the mount unit may be started for other reasons, in
    particular if it is part of local-fs.target, and any unit which
    (transitively) depends on local-fs.target is started.

  * networkctl list/status/lldp now accept globbing wildcards for 
network
    interface names to match against all existing interfaces.

  * The $PIDFILE environment variable is set to point the absolute path
    configured with PIDFile= for processes of that service.

  * The fallback DNS server list was augmented with Cloudflare public 
DNS
    servers. Use `-Ddns-servers=` to set a different fallback.

  * A new special target usb-gadget.target will be started automatically
    when a USB Device Controller is detected (which means that the 
system
    is a USB peripheral).

  * A new unit setting CPUQuotaPeriodSec= assigns the time period
    relatively to which the CPU time quota specified by CPUQuota= is
    measured.

  * A new unit setting ProtectHostname= may be used to prevent services
    from modifying hostname information (even if they otherwise would
    have privileges to do so).

  * A new unit setting NetworkNamespacePath= may be used to specify a
    namespace for service or socket units through a path referring to a
    Linux network namespace pseudo-file.

  * The PrivateNetwork= setting and JoinsNamespaceOf= dependencies now
    have an effect on .socket units: when used the listening socket is
    created within the configured network namespace instead of the host
    namespace.

  * ExecStart= command lines in unit files may now be prefixed with ':'
    in which case environment variable substitution is
    disabled. (Supported for the other ExecXYZ= settings, too.)

  * .timer units gained two new boolean settings OnClockChange= and
    OnTimezoneChange= which may be used to also trigger a unit when the
    system clock is changed or the local timezone is
    modified. systemd-run has been updated to make these options easily
    accessible from the command line for transient timers.

  * Two n

[Touch-packages] [Bug 1843812] Re: apt info "please use the '-a' switch"

2019-09-13 Thread Francis Ginther

** Tags added: id-5d7aa5d50ab4905dcdc54c44

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

Title:
  apt info "please use the '-a' switch"

Status in apt package in Ubuntu:
  Triaged

Bug description:
  When getting info about a package, I see a notice asking me to "Please
  use the '-a' switch", but the apt program does not accept an '-a'
  switch.

  Steps to reproduce:
  $ apt info docker.io
  ...
  N: There is 1 additional record. Please use the '-a' switch to see it
  $ apt -a info docker.io
  $ apt info -a docker.io
  $ apt info docker.io -a

  Expected outcome:
  same output as `apt info docker.io` but with the 1 additional record.

  Seen outcome:
  E: Command line option 'a' [from -a] is not understood in combination with 
the other options.

  Also seen:
  `apt info $pkg` gives the same output as `apt show $pkg` including the Notice 
message, but where `apt info -a $pkg` fails, `apt show -a $pkg` succeeds.

  Workaround:
  Use `apt show -a $pkg` instead.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: apt 1.8.1
  ProcVersionSignature: Ubuntu 5.0.0-23.24-generic 5.0.15
  Uname: Linux 5.0.0-23-generic x86_64
  NonfreeKernelModules: nvidia_modeset nvidia
  ApportVersion: 2.20.10-0ubuntu27.1
  Architecture: amd64
  CurrentDesktop: KDE
  Date: Thu Sep 12 14:16:09 2019
  InstallationDate: Installed on 2018-10-30 (316 days ago)
  InstallationMedia: Ubuntu 18.04.1 LTS "Bionic Beaver" - Release amd64 
(20180725)
  SourcePackage: apt
  UpgradeStatus: Upgraded to disco on 2019-04-18 (147 days ago)
  modified.conffile..etc.logrotate.d.apport: [modified]
  modified.conffile..etc.logrotate.d.apt: [modified]
  mtime.conffile..etc.logrotate.d.apport: 2018-12-13T12:13:33.355709
  mtime.conffile..etc.logrotate.d.apt: 2018-12-13T12:13:41.355709

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1843812/+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 1843743] Re: klibc ftbfs in eoan

2019-09-16 Thread Francis Ginther

** Tags added: id-5d7f798147e05c832903635b

-- 
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/1843743

Title:
  klibc ftbfs in eoan

Status in klibc package in Ubuntu:
  Confirmed
Status in klibc source package in Eoan:
  Confirmed

Bug description:
  https://launchpadlibrarian.net/441262209/buildlog_ubuntu-eoan-
  amd64.klibc_2.0.6-1ubuntu1_BUILDING.txt.gz

  gcc -Wp,-MD,usr/klibc/.sigsuspend.o.d  -nostdinc -iwithprefix include 
-I/<>/usr/include/arch/x86_64 -Iusr/include/arch/x86_64 
-I/<>/usr/include/bits64 -Iusr/include/bits64 
-I/<>/usr/klibc/../include -Iusr/klibc/../include 
-I/<>/usr/include -Iusr/include -I/<>/linux/include 
-Ilinux/include -D__KLIBC__=2 -D__KLIBC_MINOR__=0 -D_BITSIZE=64 
-fno-stack-protector -fwrapv -fno-PIE -ggdb -m64 -Os -fomit-frame-pointer 
-mno-sse -falign-functions=1 -falign-jumps=1 -falign-loops=1 
-fno-asynchronous-unwind-tables -W -Wall -Wno-sign-compare 
-Wno-unused-parameter -c -o usr/klibc/sigsuspend.o usr/klibc/sigsuspend.c
  usr/klibc/sigsuspend.c:8:10: fatal error: klibc/havesyscall.h: No such file 
or directory
  8 | #include 
|  ^
  compilation terminated.
  make[4]: *** [/<>/scripts/Kbuild.klibc:252: 
usr/klibc/sigsuspend.o] Error 1
  make[3]: *** [/<>/./Kbuild:9: all] Error 2
  make[2]: *** [Makefile:118: klibc] Error 2

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/klibc/+bug/1843743/+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 1843381] Re: Dell system takes a long time to connect network with external dock

2019-09-20 Thread Francis Ginther

** Tags added: id-5d84ab32951ae364f0c9f3b7

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

Title:
  Dell system takes a long time to connect network with external dock

Status in OEM Priority Project:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  This is a bug reopen from
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1837700
  The original one caused systemd regressed.
  https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1842651

  This issue needs an alternative solution.
  

  Dell has a feature called MAC addrss passthrough[1] that would force usb 
ethernet adapters to be assigned with a predefined MAC address stored in BIOS 
or so. This feature has been landed to mainline kernel in driver r8152[2]. So 
whenever a r8152 managed device is plugged into Dell devices with MAC addrss 
passthrough enabled, this driver will set NIC MAC to a predefined one.

  And some Dell devices have already one built-in r8152 NIC port. On
  these devices, when a second r8152 NIC is plugged in, a Debian
  originated udev rules file 73-usb-net-by-mac.rules[3] will invoke udev
  built-in command `net_id` to give a persistent name, and that will be
  based on MAC address. However, since the system has already
  initialized the built-in r8152 NIC with that name, renaming the second
  interface with this name will always fail.

  While Debian still carries a patch called "Revert-udev-network-device-
  renaming-immediately-give.patch"[4] that tries to keep support of
  already deprecated "75-persistent-net-generator.rules" based interface
  renaming mechanism, this patch also propagated into Ubuntu[5]. This
  patch will retry renaming with a 90 seconds timeout when the error
  code is -EEXIST, so the uevent processing will always be blocked in
  the last ifrename step in the victim system.

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: udev 237-3ubuntu10.24 [modified: lib/udev/rules.d/50-firmware.rules 
lib/udev/rules.d/50-udev-default.rules 
lib/udev/rules.d/73-special-net-names.rules 
lib/udev/rules.d/73-usb-net-by-mac.rules]
  ProcVersionSignature: Ubuntu 4.15.0-1043.48-oem 4.15.18
  Uname: Linux 4.15.0-1043-oem x86_64
  ApportVersion: 2.20.9-0ubuntu7.2
  Architecture: amd64
  CurrentDesktop: ubuntu:GNOME
  CustomUdevRuleFiles: 70-snap.core.rules 95-oem-hotkey-osd.rules
  Date: Wed Jul 24 15:30:59 2019
  DistributionChannelDescriptor:
   # This is the distribution channel descriptor for the OEM CDs
   # For more information see 
http://wiki.ubuntu.com/DistributionChannelDescriptor
   canonical-oem-somerville-bionic-amd64-20180608-47+beaver-jorah+X90
  InstallationDate: Installed on 2019-07-03 (20 days ago)
  InstallationMedia: Ubuntu 18.04 "Bionic" - Build amd64 LIVE Binary 
20180608-09:38
  MachineType: Dell Inc. Latitude 7424 Rugged Extreme
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-1043-oem.efi.signed 
root=UUID=5da90c85-3500-49a2-b989-71a604f9eec4 ro mem_sleep_default=deep quiet 
splash systemd.log_level=debug udev.log-priority=debug log_buf_len=8M 
vt.handoff=1
  SourcePackage: systemd
  UpgradeStatus: No upgrade log present (probably fresh install)
  dmi.bios.date: 05/27/2019
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: 1.5.0
  dmi.board.name: 0Y7FK3
  dmi.board.vendor: Dell Inc.
  dmi.board.version: X03
  dmi.chassis.type: 10
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvr1.5.0:bd05/27/2019:svnDellInc.:pnLatitude7424RuggedExtreme:pvr:rvnDellInc.:rn0Y7FK3:rvrX03:cvnDellInc.:ct10:cvr:
  dmi.product.family: Latitude
  dmi.product.name: Latitude 7424 Rugged Extreme
  dmi.sys.vendor: Dell Inc.

  [1]: 
https://www.dell.com/support/article/tw/zh/twdhs1/sln301147/what-is-mac-address-pass-through?lang=en
  [2]: 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/usb/r8152.c
  [3]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/extra/rules/73-usb-net-by-mac.rules
  [4]: 
https://salsa.debian.org/systemd-team/systemd/blob/master/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch
  [5]: 
https://git.launchpad.net/~ubuntu-core-dev/ubuntu/+source/systemd/tree/debian/patches/debian/Revert-udev-network-device-renaming-immediately-give.patch?h=ubuntu-bionic

To manage notifications about this bug go to:
https://bugs.launchpad.net/oem-priority/+bug/1843381/+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 1832050] Re: chrony autopkgtest "time-sources-from-dhcp-servers" fails (produces stderr)

2019-09-25 Thread Francis Ginther

** Tags added: id-5d8a536c3eb49122f14145aa

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

Title:
  chrony autopkgtest "time-sources-from-dhcp-servers" fails (produces
  stderr)

Status in systemd package in Ubuntu:
  Confirmed
Status in systemd source package in Eoan:
  Confirmed

Bug description:
  iproute2 fix in -proposed
  (https://launchpad.net/ubuntu/+source/iproute2/4.18.0-1ubuntu3) has
  showed regressions in chrony autopkgtest (object of this bug report).

  From autopkgtest output:

  """
  Generating /etc/default/isc-dhcp-server...
  Created symlink 
/etc/systemd/system/multi-user.target.wants/isc-dhcp-server.service → 
/lib/systemd/system/isc-dhcp-server.service.
  Created symlink 
/etc/systemd/system/multi-user.target.wants/isc-dhcp-server6.service → 
/lib/systemd/system/isc-dhcp-server6.service.
  Setting up autopkgtest-satdep (0) ...
  Processing triggers for systemd (240-6ubuntu9) ...
  Processing triggers for man-db (2.8.5-2) ...
  Processing triggers for libc-bin (2.29-0ubuntu2) ...
  (Reading database ... 62774 files and directories currently installed.)
  Removing autopkgtest-satdep (0) ...
  autopkgtest [20:50:33]: test time-sources-from-dhcp-servers: 
[---
  Preparing the dummy network interface and dhcpd configuration…
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v4-dummy0.conf: No such file or 
directory
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-dummy0.conf: No such file or 
directory
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v4-dummy0.conf: No such file or 
directory
  md5sum: /run/systemd/resolved.conf.d/isc-dhcp-v6-dummy0.conf: No such file or 
directory
  Done!

  Check if the NTP server is made available to chronyd…
  SUCCESS!

  Release the current lease and check if the NTP server has been correctly 
removed…
  SUCCESS!
  """

  It is likely that the stdout from md5sum coming out of the dhclient
  command caused the "regression".

  I have reproduced the issue by hand doing:

  $ apt-get install isc-dhcp-server
  $ modprobe dummy

  $ ip link add name dummy0 type dummy
  $ ip address add 192.168.1.1/24 dev dummy0
  $ ip link set dev dummy0 up

  cat < /etc/dhcp/dhcpd.conf
  default-lease-time 600;
  max-lease-time 7200;
  authorative;

  subnet 192.168.1.0 netmask 255.255.255.0 {
  option subnet-mask  255.255.255.0;
  option broadcast-address192.168.1.255;
  option ntp-servers  192.168.1.50;
  range 192.168.1.42 192.168.1.100;
  }
  EOF

  $ sed -i 's/INTERFACESv4=""/INTERFACESv4="dummy0"/' /etc/default/isc-
  dhcp-server

  and

  $ systemctl restart isc-dhcp-server

  $ dhclient dummy0 <- problem happens here

  It could be a "isc-dhcp-client"problem, but I'll keep this bug linked
  to another bug if that is the case.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1832050/+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 1845314] Re: udisks2 fails to install in a container with systemd 243

2019-09-25 Thread Francis Ginther

** Tags added: id-5d6fba2cac409d12ddb60a25

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

Title:
  udisks2 fails to install in a container with systemd 243

Status in systemd package in Ubuntu:
  Confirmed

Bug description:
  santa_ | rbalint: hey while systemd 243 was available in eoan I still
  got one of "my" issues (udisks2 fails to install in a container)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1845314/+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 1845245] Re: Behaviour change in systemd 243 breaks netplan.io ethernets autopkgtest

2019-09-25 Thread Francis Ginther

** Tags added: id-5d6fba2cac409d12ddb60a25

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

Title:
  Behaviour change in systemd 243 breaks netplan.io ethernets
  autopkgtest

Status in netplan.io package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  The commit introducing the regression is this one:

  commit bd08ce56156751d58584a44e766ef61340cdae2d
  Author: Yu Watanabe 
  Date:   Mon Apr 15 17:34:00 2019 +0900

  network: prevent interfaces to be initialized multiple times

  When a uevent is received during the relevant interface is in
  LINK_STATE_PENDING, then the interface may be initialized twice.
  To prevent that, this introduces LINK_STATE_INITIALIZED.

  
  I'll triage further and possibly revert the change in the next 243-based 
upload.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/netplan.io/+bug/1845245/+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 1796501] Re: systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

2019-10-01 Thread Francis Ginther

** Tags added: id-5d92536b4bcd9c68caddc01c

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

Title:
  systemd-resolved tries to mitigate DVE-2018-0001 even if DNSSEC=yes

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  In Progress

Bug description:
  I ask systemd-resolved through dig to resolve the SOA of test.asdf. (doesn't 
exist) but it returns SERVFAIL instead of NXDOMAIN. It seems to do the 
following steps:
  1. Ask upstream for SOA of test.asdf. with EDNS0, DO-bit and 4k size.
  2. Ask upstream for SOA of test.asdf. with EDNS0 and DO-bit.
  3. Ask upstream for SOA of test.asdf. with EDNS0.
  4. Ask upstream for SOA of test.asdf. without EDNS0.
  5. Repeat 1-4 for DS of test.asdf.
  6. Repeat 1-5 for asdf.
  7. Ask upstream for SOA of . with EDNS0, DO-bit and 4k size.
  8. Ask upstream for DNSKEY of . with EDNS0, DO-bit and 4k size.

  The upstream returns an unfragmented NXDOMAIN response for steps 1-6,
  an unfragmented NOERROR response for step 7 and a fragmented NOERROR
  response for step 8 which is the correct behaviour. DNSSEC records are
  included in the response if the DO-bit in the request was set.

  systemd-resolved should take the response from step 1 and start with
  validation instead of starting useless retries with reduced feture
  set. Step 3 and 4 are completely useless and probably lead to the
  SERVFAIL because I have configured it with DNSSEC=yes to prevent
  downgrade attacks.

  This regression seems to be caused by the patch resolved-Mitigate-
  DVE-2018-0001-by-retrying-NXDOMAIN-with.patch. The downgrade logic
  should only be executed if it is configured as DNSSEC=allow-downgrade
  or DNSSEC=no. See also
  https://github.com/systemd/systemd/pull/8608#issuecomment-396927885.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1796501/+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 1847496] Re: [trusty] policy not always initialized when building depcache

2019-10-10 Thread Francis Ginther

** Tags added: id-5d9e47ddb1dcee0e7664e479

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

Title:
  [trusty] policy not always initialized when building depcache

Status in apt package in Ubuntu:
  Invalid
Status in apt source package in Trusty:
  In Progress

Bug description:
  [Impact]
  apt in trusty does not always initialize the policy before constructing the 
depcache. This means that if you access the depcache, it does not respect 
pinning when calculating upgrades.

  This is not a general problem - according to current knowledge, it
  only affects apt list. It does affect any code that requests a
  depCache from pkgCacheFile without having explicitly build caches, or
  explicitly initialized policy (which other parts of apt do).

  
  [Test case]

  1. Add deb https://esm.ubuntu.com/ubuntu/ trusty-infra-security main to 
sources.list
  2. Pin it down

  Package: *
  Pin: release trusty-infra-security
  Pin-Priority: -1

  3. Look at apt list apport

  Currently it shows:

  apport/trusty-updates,trusty-security,now 2.14.1-0ubuntu3.29 all
  [installed,upgradable to: 2.14.1-0ubuntu3.29]

  because when calculating whether the package is upgradable, it did not
  see the pinning.

  Correct would be:

  apport/trusty-updates,trusty-security,now 2.14.1-0ubuntu3.29 all
  [installed]

  [Regression potential]
  Behavior of code that only initializes depcache, but not policy will change. 
For example, pinning will be applied in such code (as it is in later versions, 
and should be). This adds some more error cases as well, such as parsing 
failures for preferences files.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1847496/+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 1840510] Re: Please enable PGO and LTO for arm64

2019-10-11 Thread Francis Ginther

** Tags added: id-5d926655f9e2a5107c03e668

** Tags added: id-5d9f8a1e11e3927e713981ef

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

Title:
  Please enable PGO and LTO for arm64

Status in python3-defaults package in Ubuntu:
  Fix Released
Status in python3-defaults source package in Bionic:
  New
Status in python3-defaults package in Debian:
  Fix Released

Bug description:
  The rules file conditionally enables PGO and LTO in the python3 build
  and while it's enabled for many platforms it's not enabled for arm64.
  This is worth about 30% performance. Please enable it.

  A patch is available here with the original debian bug report:
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=934812

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python3-defaults/+bug/1840510/+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 1847896] Re: Unable to shutdown or restart from log-in screen

2019-10-15 Thread Francis Ginther

** Tags added: id-5da4c44b2f3bee7a637eb2b0

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

Title:
  Unable to shutdown or restart from log-in screen

Status in gnome-shell package in Ubuntu:
  Invalid
Status in systemd package in Ubuntu:
  Triaged

Bug description:
  When selecting the shutdown icon from the log-in screen you are
  prompted with a dialog that allows you to either cancel, restart or
  shutdown.

  It has been noted that the restart and shutdown options no longer
  work.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: gnome-shell 3.34.1-1ubuntu1
  ProcVersionSignature: Ubuntu 5.3.0-18.19-generic 5.3.1
  Uname: Linux 5.3.0-18-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8
  Architecture: amd64
  CurrentDesktop: GNOME
  Date: Sun Oct 13 09:08:23 2019
  DisplayManager: gdm3
  InstallationDate: Installed on 2019-05-17 (148 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190517)
  RelatedPackageVersions: mutter-common 3.34.1-1ubuntu1
  SourcePackage: gnome-shell
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1847896/+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 1848064] Re: /usr/share/apport/whoopsie-upload-all:PermissionError:/usr/share/apport/whoopsie-upload-all@168:collect_info:process_report

2019-10-26 Thread Francis Ginther

** Tags added: id-5db1d6f13d7e2c1b89dbb9de

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

Title:
  /usr/share/apport/whoopsie-upload-
  all:PermissionError:/usr/share/apport/whoopsie-upload-
  all@168:collect_info:process_report

Status in apport package in Ubuntu:
  Confirmed
Status in apport source package in Eoan:
  Confirmed

Bug description:
  The Ubuntu Error Tracker has been receiving reports about a problem regarding 
apport.  This problem was most recently seen with package version 
2.20.11-0ubuntu8, the problem page at 
https://errors.ubuntu.com/problem/d9f09f3b3e7aa8ab77434ef30f33416a856971ae 
contains more details, including versions of packages affected, stacktrace or 
traceback, and individual crash reports.
  If you do not have access to the Ubuntu Error Tracker and are a software 
developer, you can request it at http://forms.canonical.com/reports/.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1848064/+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 1839795] Re: PID recycling enables an unprivileged user to generate and read a crash report for a privileged process

2019-10-30 Thread Francis Ginther

** Tags added: id-5db7d98b9aa43003f76d70d0

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

Title:
  PID recycling enables an unprivileged user to generate and read a
  crash report for a privileged process

Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Dear Ubuntu Security Team,

  I would like to report a vulnerability in Apport, which enables an
  unprivileged user to read important information about a privileged
  process.

  From an attacker's point of view, the main value of the vulnerability
  is that it enables them to obtain the ASLR offsets for a privileged
  process, provided that they have the ability to deliberately crash the
  privileged process. This is very useful for an attacker if they have
  discovered a memory corruption vulnerability in a privileged service.
  It is often very difficult to obtain code execution from a memory
  corruption vulnerability unless you have access to the ASLR offsets.
  But it is usually very easy to trigger a crash by corrupting the
  memory with random data. The vulnerability in Apport enables the
  attacker to obtain the ASLR offsets for the service after it is has
  restarted due to an attacker-controlled crash.

  I have attached an exploit proof of concept which demonstrates the
  vulnerability on the whoopsie process. As you know, whoopsie has a
  memory corruption vulnerability which is currently still unfixed:
  1830865. The vulnerability in whoopsie is very difficult to exploit
  without knowing the ASLR offsets. But it is easy for an unprivileged
  user to cause whoopsie to crash. The PoC uses this to deliberately
  crash whoopsie and obtain ASLR offsets for the new whoopsie after it
  has been restarted automatically by systemd.

  To run the PoC:

  gunzip Apport_PoC.tar.gz
  tar -xf Apport_PoC.tar
  cd Apport_PoC/
  make
  ./restart_whoopsie init 10

  The PoC is slightly non-deterministic, so it might take several tries
  before it succeeds. (It will print messages to tell you what is going
  on while it is running.) When it succeeds, Apport will create a file
  named something like this:

  /var/crash/_usr_bin_whoopsie.1001.crash

  If you run apport-unpack on that crash report then you will see that
  it contains the ProcMaps file for the currently running whoopsie.

  The source of the problem is here:

  
https://git.launchpad.net/ubuntu/+source/apport/tree/data/apport?h=applied/ubuntu
  /bionic-devel&id=20c98691144e843bf1ab8428603beedd34e993ad#n452

  Apport determines which user the crashed process belongs to by reading
  the contents of /proc/[pid]. But pids can get recycled. The exploit
  works by pausing Apport while it is in the middle of generating a
  crash report and then sending a SIGKILL to the crashed process so that
  its pid gets recycled. When Apport resumes, it starts generating a
  crash report for a new process which has been assigned the same pid as
  the crashed process.

  I am happy to help out if you would like to discuss what the best
  solution is for this vulnerability. I have some ideas, but they might
  be naive. This is a very tricky area of the code and I am sure that I
  am not yet aware of all the subtle reasons why it is currently written
  the way it is.

  Please let me know when you have fixed the vulnerability, so that I
  can coordinate my disclosure with yours. For reference, here is a link
  to Semmle's vulnerability disclosure policy:
  https://lgtm.com/security#disclosure_policy

  Thank you,

  Kevin Backhouse

  Semmle Security Research Team

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1839795/+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 1839413] Re: TOCTTOU ("time of check to time of use") "cwd" variable race condition

2019-10-30 Thread Francis Ginther

** Tags added: id-5d640ed806b8601dd0ea00ab

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

Title:
  TOCTTOU ("time of check to time of use") "cwd" variable race condition

Status in Apport:
  New
Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Author: Sander Bos, 

  Date: 2019-07-30

  
  In data/apport, Apport reads out the current working directory of a
  crashed process in get_pid_info() and puts it into the "cwd" variable:

   83 cwd = os.readlink('/proc/' + pid + '/cwd')

  Later, this variable gets used in calls to write_user_coredump() for
  writing the core dump file:

  181 core_path = os.path.join(cwd, 'core')

  The time between setting the "cwd" variable and using the variable forms
  a TOCTTOU issue, and can be abused by a user to create a core dump file
  in a different directory than the actual current working directory of
  the crashed process (being Apport's intended destination directory for
  the core dump file).  This can for example be abused replacing (any path
  component of) the directory to which "cwd" points with a FUSE bindfs(1)
  or similar file system mount point, or by a symbolic link to an arbitrary
  (and potentially root owned) directory.

  Moreover, when using FUSE, basically "anything" could be put behind the
  "mount point" leading to various potential exploitation scenarios, e.g.,
  an indefinite sleep() would lead to (some form of) DoS for Apport.

  Proposed fix: if possible, use a file descriptor for handling "cwd".

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1839413/+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 1839418] Re: Partially user controllable lock file due to incorrect, too broad permissions

2019-10-30 Thread Francis Ginther

*** This bug is a duplicate of bug 1839415 ***
https://bugs.launchpad.net/bugs/1839415

** Tags added: id-5d640fd329dff226b88f059a

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

Title:
  Partially user controllable lock file due to incorrect, too broad
  permissions

Status in Apport:
  New
Status in apport package in Ubuntu:
  New

Bug description:
  Author: Sander Bos, 

  Date: 2019-07-30

  
  Apport creates its lock file, /var/crash/.lock, without providing a
  file permission mode.  Thus, the file gets created with file permission
  mode 777.  Users can exploit this, leading to system storage resource
  DoS issues (either for mount point "/", or for a potentialy separate
  "/var" mount point) as well as Apport service DoS.

  Users can thus fill up disks / partitions (although probably not including
  the root reserved blocks: even though the file is root owned, the process
  writing to the file would be started by the user, not by root, thus
  the reserved blocks can probably not be used up).  Also, the user may
  "hide" data in the file, as well as circumvent a potentially existing
  disk quota set on their account.  Also, a user putting a lock on the
  file leads to DoS on Apport, both individual Apport instances as well
  as Apport as a service, as new Apport instances are not able to acquire
  the lock and can thus not run.  In addition, the file being executable
  could have separate security implication on itself.

  Note: this issue does not appear on all Ubuntu releases, and / or not when
  Ubuntu is installed in an LXC container.  This might be due to differences
  in the kernel version, differences in the Python version or perhaps
  because Ubuntu 14.04 ESM, on which the file gets mode 660 for example,
  does not have systemd.  More specifically, the issue is probably due to
  Apport being called by the kernel via sysctl(8)'s "kernel.core_pattern"
  and the kernel not having applied an umask, combined with Python not
  creating regular files with "a-x" (as shells do).  Also, in the LXC case,
  Apport in an LXC container gets called by Apport on the host OS, which
  is a "plain" root owned process to which the umask then _does_ apply.

  In any case Apport should simply set the correct permissions itself
  (probably permission mode 600), which is also the proposed fix for
  this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1839418/+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 1839415] Re: Fully user controllable lock file due to lock file being located in world-writable directory

2019-10-30 Thread Francis Ginther

** Tags added: id-5d640fd329dff226b88f059a

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

Title:
  Fully user controllable lock file due to lock file being located in
  world-writable directory

Status in Apport:
  New
Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Author: Sander Bos, 

  Date: 2019-07-30

  
  In data/apport, Apport creates a lock file:

   35 # create a lock file
   36 lockfile = os.path.join(apport.fileutils.report_dir, '.lock')
   37 try:
   38 fd = os.open(lockfile, os.O_WRONLY | os.O_CREAT | 
os.O_NOFOLLOW)

  The value of "apport.fileutils.report_dir" is /var/crash/, which is a
  world-writable (but sticky) directory.

  Placing the lock file in a world-writable directory as done here
  effectively makes the lock file fully controllable by any user, at least
  as long as the lock file does not already exist, i.e., in case Apport has
  not been executed before (but a different issue exists which completely
  defeats this precondition).

  This issue can be exploited in several ways, with various impacts.

  Probably being its most severe impact, a simple shell one-liner like
  the following will lead to a complete system DoS, i.e., DoS on the OS
  resource level (e.g., memory):

 $ mkfifo /var/crash/.lock && while sleep 100 & do sleep 1; kill -11
  "$!"; kill -9 "$!"; done

  This will make the os.open() in data/apport stall forever due to the FIFO
  file, as well as create more than one and up to an indefinite amount of
  (root owned) Apport processes due to the failing of the locking mechanism,
  which should normally prevent subsequent Apport processes from running,
  because the lock is not yet set at that point.  The "kill -9" prevents
  the user from hitting its "RLIMIT_NPROC" limit, and "RLIMIT_CORE" itself
  does not apply to the root user.

  The locking mechanism failing when using a FIFO file, i.e., circumventing
  the locking mechanism thus making it possible to run more than one
  Apport process at the same time (even when they are in a stalled state)
  is an impact on its own, not just in the OS DoS scenario in which it is
  abused up to the point creating many Apport instances ultimately leading
  to OS DoS.

  Also, the issue in the first place leads to DoS for Apport both for
  individual instances as well as it as a service as a whole, i.e., making
  Apport unable to function, as one user could create a /var/crash/.lock
  FIFO file and prevent Apport from doing its work in case of program
  crashes of other users.

  This issue when used with a FIFO file can also be abused to "time"
  Apport, i.e., let Apport stall for some period of time (and do whatever
  is needed to control the further flow of Apport during that time, e.g.,
  as part of a larger exploit scenario) and have it continue at a specific,
  user defined moment by then reading out the FIFO file.

  As a different method of exploitation of this issue, a user can simply
  create /var/crash/.lock (as a regular file) and put an indefinite lock
  on it, thereby preventing Apport from succesfully doing its work, again
  leading to service DoS for Apport.  Apport DoS could also be achieved by
  for example creating /var/crash/.lock as a directory or as a socket file,
  meaning Apport can't os.open() /var/crash/.lock as a file, again making
  Apport fail (i.e., service DoS).

  The above scenarios prevent legitimate Apport processes from creating,
  opening and / or locking the lock file, leading to DoS for both invidual
  Apport instances as well as Apport as a whole, i.e., service DoS.

  Note that the impact of this issue might be even worse on systems without
  sysctl(8)'s "fs.protected_symlinks=1" set, which in default installations
  provides effective protection due to /var/crash/ being a sticky directory,
  or without "fs.protected_hardlinks=1" being set.

  Also note that, besides all of the impacts above due to /var/crash/
  being world-writable, /var/crash/ isn't a logical location to place a
  lock file to begin with; using a more appropriate location like /var/lock/
  would make more sense, and is also the proposed fix for this issue.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1839415/+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 1839417] Re: Potentially existing (legitimate, root owned) lock file getting deleted by Apport daily cron(8) script

2019-10-30 Thread Francis Ginther

** Tags added: id-5d640fd329dff226b88f059a

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

Title:
  Potentially existing (legitimate, root owned) lock file getting
  deleted by Apport daily cron(8) script

Status in Apport:
  New
Status in apport package in Ubuntu:
  New

Bug description:
  Author: Sander Bos, 

  Date: 2019-07-30

  
  As an unintended side effect of removing old crash reports,
  Apport's etc/cron.daily/apport daily cron(8) job file also deletes
  the /var/crash/.lock file, a lock file which Apport normally creates
  (as root) when it first runs:

4 find /var/crash/. ! -name . -prune -type f \( \( -size 0 -a \!
  -name '*.upload*' -a \! -name '*.drkonqi*' \) -o -mtime +7 \) -exec rm
  -f -- '{}' \;

  The /var/crash/.lock lock file not already existing, i.e., Apport not
  having run yet, is a precondition for a different issue (the issue of
  /var/crash/.lock being fully user controllable due to it being placed
  in a world-writable directory) to get exploited.  However, removing the
  file on a daily basis means that precondition is then met, even if the
  lock file existed beforehand.  This means exploit possibilities for that
  other issue are opened up again on a daily basis, even when a legitimate
  lock file was previously present.

  On a side note: issues might or might not arise in case the lock file
  happens to get deleted during a run of Apport, i.e., when Apport is using
  it or having set a lock on it.  This might or might not especially apply
  in combination with the "30 seconds timeout" code in check_lock().

  Proposed fix: exclude the lock file from being deleted by the daily
  cron(8) job (but note that there may also be other packages cleaning up
  /var/crash/, potentially not excluding the lock file) from being deleted.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1839417/+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 1839420] Re: Per-process user controllable Apport socket file

2019-10-30 Thread Francis Ginther

** Tags added: id-5d9e45ccd0f15c2eef59e1b0

** Tags added: id-5db7d7dd9955e4200bf58f02

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

Title:
  Per-process user controllable Apport socket file

Status in Apport:
  New
Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Author: Sander Bos, 

  Date: 2019-07-30

  
  As defined in data/apport, when Apport thinks a crash
  originated in a container it will forward the crash handling to a
  /proc//root/run/apport.socket file, using /proc/ information from
  the crashed process:

  424 if not is_same_ns(host_pid, "pid") and not is_same_ns(host_pid, 
"mnt"):
  425 # If the crash came from a container, don't attempt to handle
  426 # locally as that would just result in wrong system 
information.
  427
  428 # Instead, attempt to find apport inside the container and
  429 # forward the process information there.
  ...
  436 try:
  437 sock.connect('/proc/%d/root/run/apport.socket' % host_pid)

  Normally, a user can't change the root directory of a process since the
  chroot(2) system call can only be used by root / privileged processes.
  This also means only processes set up by the super user may have a
  different root directory, e.g., legitimate LXC containers, and that root
  can trust the value of the root directory.

  However, a user can create a user namespace using unshare(2), define
  itself root in it, and then in fact be able to use chroot(2).  Then,
  /proc//root/ for that process can lead anywhere.  Thus, the root
  directory should not be trusted by Apport, since it is user controllable,
  meaning the /root/run/apport.socket path can't be trusted either to
  be in fact an actual, legitimate Apport socket file within an actual,
  legitimate container.

  The same applies to the /run/ directory within the root directory of the
  process, even when not using chroot(2): the user can define a /run mount
  point within a user namespace when combined with unsharing the mount
  namespace (actually equal to what is the case with an actual container
  OS), and Apport on the host OS would access that in-namespace mount
  point via /proc//root/run/.

  Thus, both /proc//root/ and /proc//root/run/ are
  user-controllable, and neither can be trusted by Apport.

  Example of manipulating the root directory via a user namespace:

 user@ubuntu$ chroot /bin/ ./busybox sleep 100 # normal situation, 
chroot(2) not permitted
 chroot: cannot change root directory to '/bin/': Operation not permitted

 user@ubuntu$ unshare -Ufmpr chroot /bin/ ./busybox sleep 100 # this
  works

 root@ubuntu# readlink /proc/$(pgrep busybox)/root
 /bin

  Example of manipulating /run/ via a user namespace (the two command
  lines are started simultaneously):

 user@ubuntu$ echo 'sleep 5; mount -t tmpfs tmpfs /run; touch
  /run/apport.socket; sleep 5' | unshare -Ufmpr sh

 root@ubuntu# sleep 2; ls /proc/$(pgrep unshare)/root/run/apport.socket; 
sleep 5; ls /proc/$(pgrep unshare)/root/run/apport.socket
 ls: cannot access '/proc/6118/root/run/apport.socket': No such file or 
directory
 /proc/6118/root/run/apport.socket

  Thus, per-process, the user controls the socket file (via two separate
  path locations, as shown above).

  This can for example be abused to "catch" a core dump of a "tainted"
  process: for such process a "core" core dump file is normally not
  written, and the crash report file in /var/crash/ is created as root.
  This makes a user unable to read such core dump, which is intended for
  security since it might contain privileged contents.  However, using
  the methods above the apport.socket file is user controllable and may
  for example be an (altered) Apport systemd socket file registered to a
  "systemd --user" user initiated systemd process, so that the host Apport
  instance can still communicate properly with the socket.  Such altered
  and user controlled apport.socket file may then for example save the
  core dump in a file owned by the user effectively making a tainted,
  "privileged" core dump user readable to the user (instead of just to
  root) and thus defeating the intention of "fs.suid_dumpable=2" dumping a
  "tainted" core dump non-readable to the user, as root.  Due to things
  happening in a root user namespace this might be difficult to exploit
  for a setuid process, but it it easily doable for non-readable binaries,
  as those also fall under the category of "tainted" core dumps.

  As a different exploit example, the /proc//root/run/apport.socket
  file may be created as a symbolic link pointing to an arbitrary file
  (which could even point to a destination outside the unshared namespace),
  for example an actual socket file, enabling other damage /

[Touch-packages] [Bug 1830862] Re: Apport reads arbitrary files if ~/.config/apport/settings is a symlink

2019-10-30 Thread Francis Ginther

** Tags added: id-5db7d829ab21655404d94dff

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

Title:
  Apport reads arbitrary files if ~/.config/apport/settings is a symlink

Status in Apport:
  New
Status in apport package in Ubuntu:
  Fix Released

Bug description:
  Dear Ubuntu Security Team,

  I would like to report a local denial of service vulnerability in
  Apport. This issue is a variant of issue 1830858, but I believe it is
  less severe because I was only able to use it to trigger a denial of
  service. To trigger the bug:

  mkdir -p ~/.config/apport
  ln -s /dev/zero ~/.config/apport/settings
  gcc segv.c -o segv
  ./segv

  (I have tested these steps on an up-to-date Ubuntu 18.04.)

  Apport will happily follow the symlink, even if it points to a file
  that requires root privileges to read. The reason why it is more
  difficult to exploit than issue 1830858 is that Apport will error out
  if the file is not formatted correctly. But if the symlink points to
  /dev/zero then Apport will keep reading until it uses all the system's
  memory, thereby DOS-ing the machine.

  Please let me know when you have fixed the vulnerability, so that I
  can coordinate my disclosure with yours. For reference, here is a link
  to Semmle's vulnerability disclosure policy:
  https://lgtm.com/security#disclosure_policy

  Thank you,

  Kevin Backhouse

  Semmle Security Research Team

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1830862/+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 1839414] Re: Apport follows symbolic links in path components when creating core dump file

2019-10-30 Thread Francis Ginther

*** This bug is a duplicate of bug 1839413 ***
https://bugs.launchpad.net/bugs/1839413

** Tags added: id-5d640f669cd10e562c3038cf

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

Title:
  Apport follows symbolic links in path components when creating core
  dump file

Status in Apport:
  New
Status in apport package in Ubuntu:
  New

Bug description:
  Author: Sander Bos, 

  Date: 2019-07-30

  
  In data/apport, Apport (implicitly) protects against symbolic link
  following for to be created core dump files, but not sufficiently:

  181 core_path = os.path.join(cwd, 'core')
  ...
  186 core_file = os.open(core_path, os.O_WRONLY | os.O_CREAT | 
os.O_EXCL, 0o600)

  When Apport opens (creates, actually) the core dump file in the
  second line, symbolic link following is (implicitly) prevented due to
  the combination of "os.O_CREAT" and "os.O_EXCL".  However, this only
  applies to the final path component of "core_path" (the core dump file
  name of "core"), _not_ for the earlier path components (taken from
  "cwd").  For those path components, no such prevention is explicitly
  applied either.  Thus, symbolic links in path components before "core"
  are followed.  Combined with a different issue of "cwd" being replaced
  after reading out the current working directory but before using the "cwd"
  variable's value, users may be able to replace any path component of the
  "cwd" file system entry with a symbolic link pointing to an arbitrary
  location on the file system.

  This can for example be used to place core dumps in arbitrary (but
  user-writable) directories different than the actual current working
  directory of the crashed process, or even (user-writable) directories
  outside the root directory in case of a chroot()ed crashed process or
  outside of a container / sandbox in case of a containerized / sandboxed
  process (because Apport is ran from the host's root file system, not
  within such environment).

  Proposed fix: make Apport not follow symbolic links in non-last path
  components when writing core dump files.

To manage notifications about this bug go to:
https://bugs.launchpad.net/apport/+bug/1839414/+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 1830865] Re: Integer overflow in bson_ensure_space (bson.c:613)

2019-10-30 Thread Francis Ginther

** Tags added: id-5d6412d0de485863a95da846

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

Title:
  Integer overflow in bson_ensure_space (bson.c:613)

Status in whoopsie package in Ubuntu:
  Fix Released

Bug description:
  Dear Ubuntu Security Team,

  I would like to report an integer overflow vulnerability in whoopsie.
  In combination with issue 1830858, this vulnerability may enable an
  local attacker to read arbitrary files on the system.

  I have attached a proof-of-concept which triggers the vulnerability. I
  have tested it on an up-to-date Ubuntu 18.04. Run it as follows:

  bunzip2 PoC.tar.bz2
  tar -xf PoC.tar
  cd PoC
  make
  ./killwhoopsie2

  The PoC works by creating a file named
  `/var/crash/killwhoopsie.crash`, just over 2GB in size. It then
  creates a file named `/var/crash/killwhoopsie.upload`, which prompts
  whoopsie to start processing the .crash file.

  This is the source location of the integer overflow bug:

  http://bazaar.launchpad.net/~daisy-
  pluckers/whoopsie/trunk/view/698/lib/bson/bson.c#L613

  The problem is that the types of pos, bytesNeeded, and b->dataSize are
  all int. My PoC triggers an integer overflow in the calculation of pos
  + bytesNeeded, which causes bson_ensure_space to return immediately on
  line 614 without allocating more space. This leads subsequently to a
  heap buffer overflow on line 738:

  http://bazaar.launchpad.net/~daisy-
  pluckers/whoopsie/trunk/view/698/lib/bson/bson.c#L738

  Please let me know when you have fixed the vulnerability, so that I
  can coordinate my disclosure with yours. For reference, here is a link
  to Semmle's vulnerability disclosure policy:
  https://lgtm.com/security#disclosure_policy

  Thank you,

  Kevin Backhouse

  Semmle Security Research Team

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/whoopsie/+bug/1830865/+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 1849156] Re: systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed

2019-11-01 Thread Francis Ginther

** Tags added: id-5dbb33265d09bf5e5d2ca5df

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

Title:
  systemd-timesyncd.service broken on upgrade to 19.10 if ntp was
  installed

Status in ntp package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Confirmed
Status in ntp source package in Eoan:
  New
Status in systemd source package in Eoan:
  New
Status in ntp source package in Focal:
  New
Status in systemd source package in Focal:
  Confirmed

Bug description:
  Ubuntu 19.10's systemd package introduced /lib/systemd/system/systemd-
  timesyncd.service.d/disable-with-time-daemon.conf.  This prevents
  systemd-timesyncd.service from starting if the ntp package has been
  installed.  However, ntp.service has a Conflicts directive for
  systemd-timesyncd.service.  If both services are enabled, neither will
  start on boot.  This breaks upgrades from < 19.10 to 19.10 for systems
  that have both ntp and systemd installed.

  Possible workarounds:

  - Uninstall ntp
  - Disable systemd-timesyncd.service

  % lsb_release -rd
  Description:Ubuntu 19.10
  Release:19.10

  % apt-cache policy systemd
  systemd:
Installed: 242-7ubuntu3
Candidate: 242-7ubuntu3
Version table:
   *** 242-7ubuntu3 500
  500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu eoan/main amd64 
Packages
  100 /var/lib/dpkg/status

  % apt-cache policy ntp
  ntp:
Installed: 1:4.2.8p12+dfsg-3ubuntu2
Candidate: 1:4.2.8p12+dfsg-3ubuntu2
Version table:
   *** 1:4.2.8p12+dfsg-3ubuntu2 500
  500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu eoan/universe 
amd64 Packages
  100 /var/lib/dpkg/status

  % dpkg -S 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf
  systemd: 
/lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf

  % sudo systemctl status ntp
  ● ntp.service - Network Time Service
 Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: 
enabled)
 Active: inactive (dead)
   Docs: man:ntpd(8)

  % sudo systemctl status systemd-timesyncd.service
  ● systemd-timesyncd.service - Network Time Synchronization
 Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
vendor preset: enabled)
Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
 └─disable-with-time-daemon.conf
 Active: inactive (dead)
  Condition: start condition failed at Mon 2019-10-21 12:05:38 EDT; 29s ago
   Docs: man:systemd-timesyncd.service(8)

  Oct 21 12:05:38 ubuntu systemd[1]: Condition check resulted in Network
  Time Synchronization being skipped.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1849156/+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 1834875] Re: cloud-init growpart race with udev

2019-11-01 Thread Francis Ginther

** Tags added: id-5dbb311b74e3f364d8f98c56

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

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  New
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  On Azure, it happens regularly (20-30%), that cloud-init's growpart
  module fails to extend the partition to full size.

  Such as in this example:

  

  2019-06-28 12:24:18,666 - util.py[DEBUG]: Running command ['growpart', 
'--dry-run', '/dev/sda', '1'] with allowed return codes [0] (shell=False, 
capture=True)
  2019-06-28 12:24:19,157 - util.py[DEBUG]: Running command ['growpart', 
'/dev/sda', '1'] with allowed return codes [0] (shell=False, capture=True)
  2019-06-28 12:24:19,726 - util.py[DEBUG]: resize_devices took 1.075 seconds
  2019-06-28 12:24:19,726 - handlers.py[DEBUG]: finish: 
init-network/config-growpart: FAIL: running config-growpart with frequency 
always
  2019-06-28 12:24:19,727 - util.py[WARNING]: Running module growpart () failed
  2019-06-28 12:24:19,727 - util.py[DEBUG]: Running module growpart () failed
  Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/cloudinit/stages.py", line 812, in 
_run_modules
  freq=freq)
File "/usr/lib/python3/dist-packages/cloudinit/cloud.py", line 54, in run
  return self._runners.run(name, functor, args, freq, clear_on_fail)
File "/usr/lib/python3/dist-packages/cloudinit/helpers.py", line 187, in run
  results = functor(*args)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
351, in handle
  func=resize_devices, args=(resizer, devices))
File "/usr/lib/python3/dist-packages/cloudinit/util.py", line 2521, in 
log_time
  ret = func(*args, **kwargs)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
298, in resize_devices
  (old, new) = resizer.resize(disk, ptnum, blockdev)
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
159, in resize
  return (before, get_size(partdev))
File "/usr/lib/python3/dist-packages/cloudinit/config/cc_growpart.py", line 
198, in get_size
  fd = os.open(filename, os.O_RDONLY)
  FileNotFoundError: [Errno 2] No such file or directory: 
'/dev/disk/by-partuuid/a5f2b49f-abd6-427f-bbc4-ba5559235cf3'

  

  @rcj suggested this is a race with udev. This seems to only happen on
  Cosmic and later.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1834875/+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 1850929] Re: python3-apport regression: missing argument in Report.add_proc_environ call

2019-11-02 Thread Francis Ginther

** Tags added: id-5dbc822dcc0dac05a81cabce

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

Title:
  python3-apport regression: missing argument in Report.add_proc_environ
  call

Status in apport package in Ubuntu:
  Confirmed

Bug description:
  This is a regression in the 2.20.9-0ubuntu7.8 security update of
  apport

  # lsb_release -rd
  Description:  Ubuntu 18.04.3 LTS
  Release:  18.04

  Reproduce the bug:

  $ python3
  Python 3.6.8 (default, Oct  7 2019, 12:59:55) 
  [GCC 8.3.0] on linux
  Type "help", "copyright", "credits" or "license" for more information.
  >>> import apport
  >>> import os
  >>> report = apport.Report()
  >>> report.add_proc_info(os.getpid(), extraenv=['PYTHONHOME', 'PYTHONPATH'])
  Traceback (most recent call last):
File "", line 1, in 
File "/usr/lib/python3/dist-packages/apport/report.py", line 543, in 
add_proc_info
  self.add_proc_environ(pid, extraenv)
File "/usr/lib/python3/dist-packages/apport/report.py", line 610, in 
add_proc_environ
  env = _read_file('environ', dir_fd=proc_pid_fd).replace('\n', '\\n')
File "/usr/lib/python3/dist-packages/apport/report.py", line 73, in 
_read_file
  with open(path, 'rb', opener=lambda path, mode: os.open(path, mode, 
dir_fd=dir_fd)) as fd:
File "/usr/lib/python3/dist-packages/apport/report.py", line 73, in 
  with open(path, 'rb', opener=lambda path, mode: os.open(path, mode, 
dir_fd=dir_fd)) as fd:
  TypeError: argument should be integer or None, not list

  Patch below:

  # diff -u  /usr/lib/python3/dist-packages/apport/report.py 
/usr/lib/python3/dist-packages/apport/report.py.new 
  --- /usr/lib/python3/dist-packages/apport/report.py   2019-11-01 
14:16:39.375968798 +0100
  +++ /usr/lib/python3/dist-packages/apport/report.py.new   2019-11-01 
14:17:58.035128006 +0100
  @@ -540,7 +540,7 @@
   self['ProcCwd'] = os.readlink('cwd', dir_fd=proc_pid_fd)
   except OSError:
   pass
  -self.add_proc_environ(pid, extraenv)
  +self.add_proc_environ(pid, proc_pid_fd, extraenv)
   self['ProcStatus'] = _read_file('status', dir_fd=proc_pid_fd)
   self['ProcCmdline'] = _read_file('cmdline', 
dir_fd=proc_pid_fd).rstrip('\0')
   self['ProcMaps'] = _read_maps(proc_pid_fd)

  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: python3-apport 2.20.9-0ubuntu7.8
  ProcVersionSignature: Ubuntu 4.15.0-58.64-generic 4.15.18
  Uname: Linux 4.15.0-58-generic x86_64
  ApportLog:
   
  ApportVersion: 2.20.9-0ubuntu7.8
  Architecture: amd64
  CrashReports: 640:1000:1004:35152:2019-11-01 14:00:47.150214442 
+0100:2019-11-01 14:00:47.150214442 +0100:/var/crash/_usr_bin_snimpy.1000.crash
  Date: Fri Nov  1 14:18:16 2019
  PackageArchitecture: all
  SourcePackage: apport
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1850929/+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 1835257] Re: update tzdata package to 2019b

2019-07-05 Thread Francis Ginther

** Tags added: id-5d1bd552ad841d3ac3865d14

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

Title:
  update tzdata package to 2019b

Status in tzdata package in Ubuntu:
  Fix Released

Bug description:
  Update tzdata package to 2019b.

  https://mm.icann.org/pipermail/tz-announce/2019-July/56.html

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/tzdata/+bug/1835257/+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 1834226] Re: update-notifier doesn't respect "automatically check for updates: Never"

2019-07-12 Thread Francis Ginther

** Tags added: id-5d2752b415f430133d5cd4a1

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

Title:
  update-notifier doesn't respect "automatically check for updates:
  Never"

Status in software-properties package in Ubuntu:
  New
Status in software-properties source package in Eoan:
  New

Bug description:
  This has been a long-standing problem with various ubuntu
  installations, and I'm sensing some reticence in doing anything about
  it. This attitude also seems to be purposeful to try to cajole updates
  on people who make bad choices due to confusion/fud/paranoia.

  apt install fails due to:

  E: Could not get lock /var/lib/dpkg/lock-frontend - open (11: Resource 
temporarily unavailable)
  E: Unable to acquire the dpkg frontend lock (/var/lib/dpkg/lock-frontend), is 
another process using it?

  A great deal of networking is taking place despite setting automatic
  upgrades to "never". Cycling this doesn't seem to do anything. This
  action is hostile to programmers and the setting should be respected.

  Wisdom on threads is to let it update until it's out of updates, and
  then it supposedly respects the "never" flag, but the experience I'm
  having is much more non-deterministic. have been using 19.04 for weeks
  now and still get the background notifier using data and getting in
  the way of aptitude package installations. I prefer manual update &&
  upgrade once my code is ready to push.

  Is there another way around this or are people just living with it?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1834226/+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 1837443] Re: [Power9][Witherspoon dd2.3] unable to set hwclock

2019-07-26 Thread Francis Ginther

** Tags added: id-5d39d20d64e1ea1822b8d25d

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

Title:
  [Power9][Witherspoon dd2.3] unable to set hwclock

Status in The Ubuntu-power-systems project:
  Triaged
Status in util-linux package in Ubuntu:
  New

Bug description:
  On the upgraded witherspoon Power9 system we are unable to set
  hwclock.

  ubuntu@bobone:~$ uname -a 
  Linux bobone 5.0.0-20-generic #21-Ubuntu SMP Mon Jun 24 09:31:42 UTC 2019 
ppc64le ppc64le ppc64le GNU/Linux
  ubuntu@bobone:~$ cat /etc/issue
  Ubuntu 19.04 \n \l

  ubuntu@bobone:~$ date 
  Mon Jul 22 18:25:04 UTC 2019
  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock
  2019-07-22 18:25:26.799805+00:00
  ubuntu@bobone:~$ 

  ubuntu@bobone:~$ sudo /sbin/hwclock --set --date "2004/11/22 04:10:00"; sleep 
5s; sudo /sbin/hwclock --verbose
  hwclock from util-linux 2.33.1
  System Time: 1563820048.938797
  Trying to open: /dev/rtc0
  Using the rtc interface to the clock.
  Last drift adjustment done at 1101096600 seconds after 1969
  Last calibration done at 1101096600 seconds after 1969
  Hardware clock is on UTC time
  Assuming hardware clock is kept in UTC time.
  Waiting for clock tick...
  ioctl(4, RTC_UIE_ON, 0): Invalid argument
  Waiting in loop for time from /dev/rtc0 to change
  ...got clock tick
  Time read from Hardware Clock: 2019/07/22 18:27:29
  Hw clock time : 2019/07/22 18:27:29 = 1563820049 seconds since 1969
  Time since last adjustment is 462723449 seconds
  Calculated Hardware Clock drift is 0.00 seconds
  2019-07-22 18:27:28.877732+00:00
  ubuntu@bobone:~$

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-power-systems/+bug/1837443/+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 1838258] Re: Unable to configure VLAN on an additional OSA interface

2019-07-30 Thread Francis Ginther

** Tags added: id-5d3f1092c9ff2f192b03a448

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

Title:
  Unable to configure VLAN on an additional OSA interface

Status in Ubuntu on IBM z Systems:
  Triaged
Status in iproute2 package in Ubuntu:
  New
Status in linux package in Ubuntu:
  New

Bug description:
  After installing a base Ubuntu 18.04.1 server, an additional OSA device 
"e530" is attached and configured with chzdev. Then a VLAN configuration should 
be applied using the ip command.
  However this results in the error message "RTNETLINK answers: File exists". 

  >snip
  ip link add link ence530 name ence530.209 type vlan id 209
  RTNETLINK answers: File exists
  snip<

  Executing the same steps on an Ubuntu 16.04.5 server, the ip command
  finishes without an error message but the VLAN interface is also not
  configured.

  Reproduction:

  - Install a 18.04.1 server
  - attach an additional OSA interface
  - configure a VLAN using the ip command

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1838258/+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 1838322] Re: Support Japanese new era "令和 (Reiwa)"

2019-08-02 Thread Francis Ginther

** Tags added: id-5d42faf102235814f5011aa4

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

Title:
  Support Japanese new era "令和 (Reiwa)"

Status in icu package in Ubuntu:
  Fix Released
Status in icu source package in Xenial:
  New
Status in icu source package in Bionic:
  New
Status in icu source package in Disco:
  New

Bug description:
  [Background]
  Many packages are affected by the requirement to support the new era "Reiwa" 
(令和）

  This is the meta bug to track packages that need fixes; which packages
  have already been SRUd to previous releases, how to prioritize the
  work needed, and general test cases for verifying that things are
  working as expected.

  [Impact]
  Users who run Ubuntu in Japanese.

  [Test cases]

  Unicode data embedded into icu should include REIWA like it includes
  HEISEI.

  == Date conversion ==

  On applications that support writing dates in long form, or with
  symbols to denote era (either in X00.00.00 format or in GG1G5G1G
  format (G- glyph; X- character):

  1) Enable date formatting in each of the above formats that are supported 
(long form or symbols)
  2) Type in '2019/05/01' to be formatted, verify that it shows as "令和1年5月1日" 
or "R1.05.01"
  3) Type in '2019/04/30' to be formatted, verify that it shows as "平成31年4月30日" 
or "H31.4.30"

  == Character maps / font support ==

  1) Search for character "SQUARE ERA NAME"
  2) Verify that the results include at least "SQUARE ERA NAME HEISEI" and 
"SQUARE ERA NAME REIWA" (there should also be Syouwa, Taisyou and Meizi), and 
that the glyphs are readable:

   - SQUARE ERA NAME HEISEI: ㍻
   - SQUARE ERA NAME REIWA: 令和 (in a single glyph)

  Display of the Reiwa square glyph is font-specific; it may show simply
  as a empty square or a square with hex characters. If that is the
  case, the unicode data supports the new character, but the selected
  font does not include the new glyph.


  [Regression potential]
  This is a potentially large change as it impacts font display, character sets 
as well as date conversions. As such, extreme care should be taken to ensure 
that regressions are avoided, such that dates previous to May 1, 2019 continue 
to display as before, and dates onward are displayed with the new era symbols. 
The included test cases account for verifying the continued behavior or 
previous dates.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/icu/+bug/1838322/+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 1814611] Re: turning off "Send error reports to Canonical" prevents using ubuntu-bug

2019-08-02 Thread Francis Ginther

** Tags added: id-5d436db42180090edb58cd96

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

Title:
  turning off "Send error reports to Canonical" prevents using ubuntu-
  bug

Status in apport package in Ubuntu:
  Triaged
Status in apport source package in Bionic:
  Triaged
Status in apport source package in Disco:
  Triaged
Status in apport source package in Eoan:
  Triaged

Bug description:
  Impact
  --
  apport was modified (bug 1778497) to reduce the number of times people have 
to respond to crash reports, however the changes introduced a check to see if 
whoopsie is enabled. That check is done for any type of report, not just 
crashes, and subsequently people can not use ubuntu-bug to report bugs if 
whoopsie is disabled which is wrong as whoopsie is only for uploading crashes 
to the Error Tracker.

  Test Case
  -
  1) On a system with Gnome installed use the Privacy control panel and set 
"Send error reports to Canonical" to Off
  2) In a terminal run 'ubuntu-bug gnome-terminal'
  3) Click "Send" and observe nothing happening (if something does happen 
confirm that whoopsie is disabled via 'systemctl is-enabled whoopsie' - there 
may be a bug in the control panel)

  
  Original Description
  
  Ubuntu 18.04.1 LTS, X11 gnome session.

  For some reason ubuntu-bug  no longer opens a browser
  window, so it is not possible to enter useful bug detauls, or even
  know the bug number.

  After prompting whether or not to Send the report, clicking "Send"
  just closes appport and nothing else ever happens.  The exit status of
  "ubuntu-bug" is zero.

  This worked fine before, but it has been many months since I tried to
  submit a bug.

  strace shows many stat calls on plausible browser paths, including the
  one that is correct (/usr/bin/firefox, which returned a successful
  stat call).  I'll attach the trace output from

     strace -f -o /tmp/strace.log ubuntu-bug apport

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1814611/+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 1837926] Re: snapd snap ftbfs in eoan due to python-apt regression

2019-08-02 Thread Francis Ginther

** Tags added: id-5d430dac9171f0572da1bba1

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

Title:
  snapd snap ftbfs in eoan due to python-apt regression

Status in python-apt package in Ubuntu:
  New
Status in snapd package in Ubuntu:
  New
Status in python-apt source package in Eoan:
  New
Status in snapd source package in Eoan:
  New

Bug description:
  snapd snap FTBFS in launchpad snap build due to python-apt regression
  in eoan

  https://launchpad.net/~xnox/+snap/snapd/+build/626157

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1837926/+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 1840965] Re: dhclient initramfs code writes invalid net-eth0.conf

2019-08-27 Thread Francis Ginther

** Tags added: id-5d6458d075c1a113cb9c2e57

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

Title:
  dhclient initramfs code writes invalid net-eth0.conf

Status in initramfs-tools package in Ubuntu:
  New
Status in isc-dhcp package in Ubuntu:
  Triaged
Status in initramfs-tools source package in Eoan:
  New
Status in isc-dhcp source package in Eoan:
  Triaged

Bug description:
  Since 18.10, Ubuntu switched to using dhclient instead of ipconfig in 
initramfs configure_networking(). And now a malformed /run/net-enp0s3.conf is 
generated, with unquoted values like the following, which are a shell syntax 
error:
  IPV4DNS0=1.2.3.1 1.2.3.2 1.2.3.3

  This file is sourced by initramfs-tools/init in various places, and produces 
the following message a lot of times:
  /init: /run/net-enp0s3.conf: line 8: 1.2.3.2: not found

  I.e. values should be quoted, and 2 DNS entries should go in
  IPV4DNS0/IPV4DNS1, not multiple unquoted ones in IPV4DNS0.

  Here is the erroneous file that dhclient-enter-hooks.d/config produces:
  DEVICE=enp0s3
  PROTO=dhcp
  IPV4PROTO=dhcp
  IPV4ADDR=10.161.254.38
  IPV4NETMASK=255.255.255.0
  IPV4BROADCAST=10.161.254.255
  IPV4GATEWAY=10.161.254.1
  IPV4DNS0=194.63.237.4 194.63.239.164 194.63.238.4
  ROOTSERVER=10.161.254.1
  HOSTNAME=
  DNSDOMAIN=

  Here is the correct one that ipconfig produces:
  DEVICE='enp0s3'
  PROTO='dhcp'
  IPV4ADDR='10.161.254.38'
  IPV4BROADCAST='10.161.254.255'
  IPV4NETMASK='255.255.255.0'
  IPV4GATEWAY='10.161.254.1'
  IPV4DNS0='194.63.237.4'
  IPV4DNS1='194.63.239.164'
  HOSTNAME=''
  DNSDOMAIN=''
  NISDOMAIN=''
  ROOTSERVER='10.161.254.1'
  ROOTPATH=''
  filename=''
  UPTIME='594'
  DHCPLEASETIME='25200'
  DOMAINSEARCH=''

  I.e. please either fix dhclient-enter-hooks.d/config, or revert the
  ipconfig => dhclient change.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1840965/+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 1311056] Re: apt-add-repository adds duplicate commented/disabled source lines

2019-08-27 Thread Francis Ginther

** Tags added: id-5d65087107d6ae450d988462

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

Title:
  apt-add-repository adds duplicate commented/disabled source lines

Status in python-apt package in Ubuntu:
  Triaged
Status in software-properties package in Ubuntu:
  Triaged

Bug description:
  Trusty Tahr 14.04

  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list 
  deb http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#apt-add-repository -y 
ppa:aims/aims-desktop
  gpg: keyring `/tmp/tmp0ufdhnmv/secring.gpg' created
  gpg: keyring `/tmp/tmp0ufdhnmv/pubring.gpg' created
  gpg: requesting key BE796FF2 from hkp server keyserver.ubuntu.com
  gpg: /tmp/tmp0ufdhnmv/trustdb.gpg: trustdb created
  gpg: key BE796FF2: public key "Launchpad PPA for AIMS" imported
  gpg: Total number processed: 1
  gpg:   imported: 1  (RSA: 1)
  OK
  0 root@osprey:/etc/apt/sources.list.d#cat aims-aims-desktop-trusty.list deb 
http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  # deb-src http://ppa.launchpad.net/aims/aims-desktop/ubuntu trusty main
  0 root@osprey:/etc/apt/sources.list.d#

  That deb-src line should have stayed commented out, and not been
  duplicated. (Commented deb lines should of course be uncommented, as
  already fixed per https://bugs.launchpad.net/ubuntu/+source/python-
  apt/+bug/1042916 .)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1311056/+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 1841790] Re: [FFe] Please accept systemd 241 to Eoan

2019-08-29 Thread Francis Ginther

** Tags added: id-5d2e4c813a5b1a58c17d63f6

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

Title:
  [FFe] Please accept systemd 241 to Eoan

Status in systemd package in Ubuntu:
  New

Bug description:
  Eoan currently has 240-6ubuntu13, but it is not used widely, Debian stable 
already has 241 and Debian testing moved to 242 last week.
  Version 241 is the safest choice for Eoan (from v240, v241 and v242) since it 
is widely tested, while going forward 20.04 will most likely ship a systemd 
release which is not released yet, probably v244+.

  Updating to v241 will allow us to carry fewer patches in Eoan and
  makes moving to the next release easier.

  The proposed package is tested in Bileto and all tests are passing:
  https://bileto.ubuntu.com/#/ticket/3789

  The final version will be 241-7ubuntu1 and I'm tidying up the
  changelog, too.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1841790/+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 1671951] Re: networkd should allow configuring IPV6 MTU

2019-08-30 Thread Francis Ginther

** Tags added: id-5d67fe691c14484db556d212

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

Title:
  networkd should allow configuring IPV6 MTU

Status in cloud-init package in Ubuntu:
  Confirmed
Status in netplan.io package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released
Status in cloud-init source package in Bionic:
  Confirmed
Status in netplan.io source package in Bionic:
  Fix Committed
Status in systemd source package in Bionic:
  Fix Committed

Bug description:
  = netplan.io =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]
   * Apply a netplan configuration that specifices ipv6-mtu:

  network:
version: 2
ethernets:
  eth0:
dhcp4: true
dhcp6: true
ipv6-mtu: 6000

   * Check that MTU bytes, is at least IPv6MTUBytes on the interface:

  $ sysctl net.ipv6.conf.eth0.mtu
  net.ipv6.conf.eth0.mtu = 6000

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of netplan.io =

  = systemd =

  [Impact]

   * IPv6 traffic failing to send/receive due to incompatible/low MTU
  setting. Specifically, IPv6 traffic may have higher MTU requirements
  than IPv4 traffic and thus may need to be overridden and/or set to a
  higher value than IPv6 traffic.

  [Test Case]

   * Use IPv6MTUBytes= setting in a .network unit
   * Restart systemd-network
   * Check that there no error messages / warnings about not-recognizing this 
option
   * Check that MTU bytes, is at least IPv6MTUBytes on the interface

  [Regression Potential]

   * This is a future compatible backport of an additional keyword not
  used by default. It may result in MTU change to a higher value, which
  should not cause loss of connectivity.

  [Other Info]

   * Original bug report below

  = end of systemd =

  1) Zesty
  2) systemd-232-19
  3) I need to configure the IPV6 MTU for tunneling by adding an 
IPv6MTUBytes=1480 value in the .network file for an interface with an IPV6 
static address in the [Network] section
  4) networkd does not parse or read the value and does not apply this 
configuration to the interface.

  Upstream has discussed this issue here:

  https://github.com/systemd/systemd/pull/1533

  But it's been closed in favor of only setting via RA.

  However, we know of multiple use-case which are currently supported in
  ifdupdown where we want to retain control over IPV6 MTU values outside
  of PMTU Discovery configurations.

  Some context from those discussions

  >> Client systems that route their ipv6 packets to a 6in4 router also
  >> have to have their ipv6 mtu lowered.  They could lower their link mtu,
  >> so their ipv6 packets are small enough, but that reduces performance
  >> of their ipv4 network.

  Yes.  Anything that creates a PMTUD black hole can result in
  situations where the higher header overhead of IPv6 will cause IPv4 to
  pass but IPv6 traffic to be dropped.

  One example here is egress from an ipsec tunnel wherein the next
  hop MTU is too low for IPv6 datagrams to pass.  Another is VM ->
  whatever -> host bridge -> tunnel ingress.  If the datagram cannot enter
  the tunnel due to size, it is dropped, and an ICMP response uses the
  tunnel address as a source, which may not be routable back to the
  origin.  This one is an issue with IPv4 as well, and is one case where
  manually setting the IPv6 MTU lower than the (also manually set) device
  MTU is of benefit.

  In essence, any of these sort of cases that require an explicit
  setting of the device MTU will likely require a setting of the IPv6 mtu
  as well to account for its larger header overhead.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1671951/+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 1842436] Re: [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups

2019-09-04 Thread Francis Ginther

** Tags added: id-5d6e87bc40caa37d15c1d145

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

Title:
  [UBUNTU] Avoid creation of mixed-blocksize PV on LVM volume groups

Status in Ubuntu on IBM z Systems:
  New
Status in lvm2 package in Ubuntu:
  New

Bug description:
  efault blocksize of a file-system seems to be dependent on the volume-size.
  Big volume (at least ext4) does have 4k blk-size, even the underlaying devise 
with a smaller phyiscal blk-size.

  The patch, avoiding define mixed-sized volume groups is now upstream
  in the master branch of LVM2
  
https://sourceware.org/git/?p=lvm2.git;a=commit;h=0404539edb25e4a9d3456bb3e6b402aa2767af6b

  Using this patch within the distribution is for sanity reasons.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-z-systems/+bug/1842436/+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 1843007] Re: namespace: make MountFlags=shared work again

2019-09-06 Thread Francis Ginther

** Tags added: id-5d7225829edbf089d659f6d9

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

Title:
  namespace: make MountFlags=shared work again

Status in systemd package in Ubuntu:
  New

Bug description:
  Systemd in Bionic fails to handle MountFlags correctly. Would you mind
  to include
  
https://github.com/systemd/systemd/commit/37ed15d7edaf59a1fc7c9e3552cd93a83f3814ef
  into Bionic? This bug seriously affects Docker > 18.6, see the Docker
  release notes for 18.09.1 (https://docs.docker.com/engine/release-
  notes/#18091).

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1843007/+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 1809174] Re: apt doesn't detect file corruption in /var/lib/apt/lists

2019-01-08 Thread Francis Ginther

** Tags added: id-5c336e5b216dc852b7a80d86

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

Title:
  apt doesn't detect file corruption in /var/lib/apt/lists

Status in apt package in Ubuntu:
  Triaged

Bug description:
  The Problem
  ==

  /var/lib/apt/lists contains the repository index caches or similar;
  I'm not sure what the correct  apt-terminology is.

  I've installed Chrome on my laptop, so I have:

  smacdonald@L247:/var/lib/apt/lists$ dir *goog*
  -rw-r--r-- 1 root root  943 Dec 19 14:02 
dl.google.com_linux_chrome_deb_dists_stable_Release
  -rw-r--r-- 1 root root  819 Dec 19 14:02 
dl.google.com_linux_chrome_deb_dists_stable_Release.gpg
  -rw-r--r-- 1 root root 4457 Dec 19 14:02 
dl.google.com_linux_chrome_deb_dists_stable_main_binary-amd64_Packages

  for example.

  
  dl.google.com_linux_chrome_deb_dists_stable_Release contains checksums for 
the dl.google.com_linux_chrome_deb_dists_stable_main_binary-amd64_Packages file:

  smacdonald@L247:/var/lib/apt/lists$ cat 
dl.google.com_linux_chrome_deb_dists_stable_Release
  Origin: Google LLC
  Label: Google
  Suite: stable
  Codename: stable
  Version: 1.0
  Date: Wed, 19 Dec 2018 18:51:54 UTC
  Architectures: amd64
  Components: main
  Description: Google chrome-linux software repository
  MD5Sum:
   9e0d0ad6a4f5ccf8e3971c32e9bb22d3 4457 main/binary-amd64/Packages
   a17f6de0ef487b82af58ccd91df52d04 1109 main/binary-amd64/Packages.gz
   156e5ea7a0c6bed5973a68a45e546dc9 151 main/binary-amd64/Release
  SHA1:
   4c2cde4f71476d7881262d9a07e33cf4506232a7 4457 main/binary-amd64/Packages
   e002924c9ddfe41ee2033594ec768ed9e4545909 1109 main/binary-amd64/Packages.gz
   0f4348c2d4d7cc1f8e59b5934d87f1ca872f6e34 151 main/binary-amd64/Release
  SHA256:
   fb0e586c2b5ec5afa17965d0bbc6bd46c2071336f75e2b0f0c7f3e7b090a7844 4457 
main/binary-amd64/Packages
   2462cff732765679a56373a7ca9a5b8b029fdb445e707b1aba10d01fbdb853b3 1109 
main/binary-amd64/Packages.gz
   c1e3c9318381862306adcdc4fd4fe2d85be8aa4c4f3dcbb40fce80413f588286 151 
main/binary-amd64/Release

  
  If the dl.google.com_linux_chrome_deb_dists_stable_main_binary-amd64_Packages 
file has become corrupt in the specific manner of being 0 bytes in length, apt 
does not detect this, and the repository is effectively unreachable until one 
of two things occurs: a) the repository has an update causing apt to re-fetch 
the repository information and accidentally fix-by-over-writing the corrupt 0 
byte file, or, b) the user removes the corrupt 0-byte file and does an apt 
update to refetch the repository information.

  
  The Context
  ==

  Our IoT devices run Ubuntu 16.04, and their main storage is eMMC.
  Sometimes there are catastrophic power cuts, and, despite other
  precautions, files are occasionally corrupted in the manner of
  becoming 0 bytes in length. We're not sure exactly why or how.

  Today a deployed device suffered the above scenario. We maintain a
  debian package repository for updating our devices in the field, and
  we suddenly couldn't install packages from it. A bit of investigation
  turned up the 0 byte *_Packages file for our repo, and we worked
  around the problem.

  Part of the situation is our debian repository doesn't have updates
  very often, so 'sudo apt-get update' was giving a Hit: instead of a
  Get: result all the time, and everything from the "normal user command
  line" side of things looked okay. There were no logs in
  /var/log/syslog either. We just could not see our packages from our
  repo, despite 'apt-get update' looking good.

  
  What I Expected to Happen
  ==

  Given that the the *_Release file contains checksums for the *_Package
  file, I would expect that apt verifies the checksum, and if it fails,
  refetches the repository information even if there hasn't been an
  update, during any given 'apt update' operation.

  
  Further Information
  ==

  I checked apt's project in Debian at https://bugs.debian.org/cgi-
  bin/pkgreport.cgi?pkg=apt and there don't appear to be any bugs about
  this filed already, so I'm starting by filing one here.

  The situation occurred on an Ubuntu 16.04 system, but is 100%
  reproducible with Google's chrome repository on my Ubuntu 18.04.1
  laptop. I can provide a set of reproduction steps if needed, but it's
  fairly straight-forward.

  The fact that this corruption appears to be "everything working okay"
  to the end user, except that apt doesn't know about packages it says
  it knows about, and there is no error logging for any sort, is partly
  why I'm filing this.

  Note the "if one of two things happens" case a) above

[Touch-packages] [Bug 1808508] Re: Valgrind doesn't work in disco [Fatal error at startup: a function redirection which is mandatory for this platform-tool combination cannot be set up.]

2019-01-11 Thread Francis Ginther

** Tags added: id-5c3776fa4cafca4421242879

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

Title:
  Valgrind doesn't work in disco [Fatal error at startup: a function
  redirection which is mandatory for this platform-tool combination
  cannot be set up.]

Status in base-files package in Ubuntu:
  Won't Fix
Status in valgrind package in Ubuntu:
  Triaged

Bug description:
  $ valgrind /bin/ls
  ==25995== Memcheck, a memory error detector
  ==25995== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
  ==25995== Using Valgrind-3.14.0 and LibVEX; rerun with -h for copyright info
  ==25995== Command: /bin/ls
  ==25995== 

  valgrind:  Fatal error at startup: a function redirection
  valgrind:  which is mandatory for this platform-tool combination
  valgrind:  cannot be set up.  Details of the redirection are:
  valgrind:  
  valgrind:  A must-be-redirected function
  valgrind:  whose name matches the pattern:  strlen
  valgrind:  in an object with soname matching:   ld-linux-x86-64.so.2
  valgrind:  was not found whilst processing
  valgrind:  symbols from the object with soname: ld-linux-x86-64.so.2
  valgrind:  
  valgrind:  Possible fixes: (1, short term): install glibc's debuginfo
  valgrind:  package on this machine.  (2, longer term): ask the packagers
  valgrind:  for your Linux distribution to please in future ship a non-
  valgrind:  stripped ld.so (or whatever the dynamic linker .so is called)
  valgrind:  that exports the above-named function using the standard
  valgrind:  calling conventions for this platform.  The package you need
  valgrind:  to install for fix (1) is called
  valgrind:  
  valgrind:On Debian, Ubuntu: libc6-dbg
  valgrind:On SuSE, openSuSE, Fedora, RHEL:   glibc-debuginfo
  valgrind:  
  valgrind:  Note that if you are debugging a 32 bit process on a
  valgrind:  64 bit system, you will need a corresponding 32 bit debuginfo
  valgrind:  package (e.g. libc6-dbg:i386).
  valgrind:  
  valgrind:  Cannot continue -- exiting now.  Sorry.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.04
  Package: valgrind 1:3.14.0-0ubuntu3
  ProcVersionSignature: Ubuntu 4.18.0-11.12-generic 4.18.12
  Uname: Linux 4.18.0-11-generic x86_64
  ApportVersion: 2.20.10-0ubuntu14
  Architecture: amd64
  Date: Fri Dec 14 17:06:03 2018
  InstallationDate: Installed on 2018-12-04 (10 days ago)
  InstallationMedia: Ubuntu 19.04 "Disco Dingo" - Alpha amd64 (20181203)
  SourcePackage: valgrind
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1808508/+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

1 2 3 4 5 >

1 - 100 of 419 matches

Mail list logo