[Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable

[Michael Hudson-Doyle]

** Description changed:

- In mantic, we migrated livecd-rootfs to use losetup -P instead of
- kpartx, with the expectation that this would give us a reliable, race-
- free way of loop-mounting partitions from a disk image during image
- build.
+ [impact]
+ In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, 
with the expectation that this would give us a reliable, race-free way of 
loop-mounting partitions from a disk image during image build.
  
  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.
  
  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is
  
-   https://launchpad.net/~ubuntu-
+   https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790
  
  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.
  
-   https://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/noble/ppc64el
+   https://autopkgtest.ubuntu.com/packages/l/livecd-rootfs/noble/ppc64el
  
  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.
+ 
+ The losetup usage has been backported to Jammy, and sees frequent
+ failures there.
+ 
+ [test case]
+ The autopkgtests will provide enough confidence that the changes are not 
completely broken. Whether the change helps with the races on riscv can be 
"tested in prod" just as well as any other way.
+ 
+ [regression potential]
+ If the backport has been done incorrectly, image builds can fail (and the 
autopkgtests will fail if it has been completely bungled). This can be quickly 
handled. There is no foreseeable way for this to result in successful builds 
but broken images, which would be a much more difficult failure mode to unpick.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  New
Status in linux source package in Jammy:
  New
Status in livecd-rootfs source package in Jammy:
  New
Status in util-linux source package in Jammy:
  New
Status in linux source package in Mantic:
  New
Status in livecd-rootfs source package in Mantic:
  New
Status in util-linux source package in Mantic:
  New
Status in linux source package in Noble:
  New
Status in livecd-rootfs source package in Noble:
  Fix Released
Status in util-linux source package in Noble:
  New

Bug description:
  [impact]
  In mantic, we migrated livecd-rootfs to use losetup -P instead of kpartx, 
with the expectation that this would give us a reliable, race-free way of 
loop-mounting partitions from a disk image during image build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

    https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

    https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

  The losetup usage has been backported to Jammy, and sees frequent
  failures there.

  [test case]
  The autopkgtests will provide enough confidence that the changes are not 
completely broken. Whether the change helps with the races on riscv can be 
"tested in prod" just as well as any other way.

  [regression potential]
  If the backport has been done incorrectly, image builds can fail (and the 
autopkgtests will fail if it has been completely bungled). This can be quickly 
handled. There is no foreseeable way for this to result in successful builds 
but broken images, which would be a much more difficult failure mode to unpick.

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


-- 
Mailing list: https://launchpad.net/~kernel-packages
Post 

[Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable

[Michael Hudson-Doyle]

Here is a backport of the partial fix to jammy
https://code.launchpad.net/~mwhudson/livecd-rootfs/+git/livecd-
rootfs/+merge/460729

I'm not sure I am best placed to update this bug description to match
the SRU template though -- I'm not sure which builds are being affected
in practice and so should be incorporated into the test plan.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  New
Status in linux source package in Jammy:
  New
Status in livecd-rootfs source package in Jammy:
  New
Status in util-linux source package in Jammy:
  New
Status in linux source package in Mantic:
  New
Status in livecd-rootfs source package in Mantic:
  New
Status in util-linux source package in Mantic:
  New
Status in linux source package in Noble:
  New
Status in livecd-rootfs source package in Noble:
  Fix Released
Status in util-linux source package in Noble:
  New

Bug description:
  In mantic, we migrated livecd-rootfs to use losetup -P instead of
  kpartx, with the expectation that this would give us a reliable, race-
  free way of loop-mounting partitions from a disk image during image
  build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

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


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

[Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable

[Michael Hudson-Doyle]

Oh wait, we've been through something very like this before
https://bugs.launchpad.net/cloud-initramfs-tools/+bug/1834875. I suspect
a judicious application of flock may be the most correct solution
available.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  Fix Released
Status in util-linux package in Ubuntu:
  New

Bug description:
  In mantic, we migrated livecd-rootfs to use losetup -P instead of
  kpartx, with the expectation that this would give us a reliable, race-
  free way of loop-mounting partitions from a disk image during image
  build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

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


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

[Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable

[Michael Hudson-Doyle]

Here's my workaround then https://code.launchpad.net/~mwhudson/livecd-
rootfs/+git/livecd-rootfs/+merge/459380

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  In mantic, we migrated livecd-rootfs to use losetup -P instead of
  kpartx, with the expectation that this would give us a reliable, race-
  free way of loop-mounting partitions from a disk image during image
  build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

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


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

[Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable

[Michael Hudson-Doyle]

Amazing debugging Dann. Until we can get a kernel fix, what's the way
forward here? Run losetup without -P, run udevadm settle, run partprobe
on the device (then maybe run udevadm settle again??)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  In mantic, we migrated livecd-rootfs to use losetup -P instead of
  kpartx, with the expectation that this would give us a reliable, race-
  free way of loop-mounting partitions from a disk image during image
  build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

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


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

Re: [Kernel-packages] [Bug 2045586] Re: livecd-rootfs uses losetup -P for theoretically reliable/synchronous partition setup but it's not reliable in noble

[Michael Hudson-Doyle]

> Is only asking kernel to scan the device; to then generate "kernel udev"
> events; for then udev to wakeup and process/emit "udev udev" events; and
> create the required device nodes.
>

It's not udev that creates nodes like /dev/loop1p1 though is it? That's
devtmpfs surely.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2045586

Title:
  livecd-rootfs uses losetup -P for theoretically reliable/synchronous
  partition setup but it's not reliable in noble

Status in linux package in Ubuntu:
  New
Status in livecd-rootfs package in Ubuntu:
  New
Status in util-linux package in Ubuntu:
  New

Bug description:
  In mantic, we migrated livecd-rootfs to use losetup -P instead of
  kpartx, with the expectation that this would give us a reliable, race-
  free way of loop-mounting partitions from a disk image during image
  build.

  In noble, we are finding that it is no longer reliable, and in fact
  fails rather often.

  It is most noticeable with riscv64 builds, which is the architecture
  where we most frequently ran into problems before with kpartx.  The
  first riscv64+generic build in noble where the expected loop partition
  device is not available is

https://launchpad.net/~ubuntu-
  cdimage/+livefs/ubuntu/noble/cpc/+build/531790

  The failure is however not unique to riscv64, and the autopkgtest for
  the latest version of livecd-rootfs (24.04.7) - an update that
  specifically tries to add more debugging code for this scenario - has
  also failed on ppc64el.

https://autopkgtest.ubuntu.com/packages/l/livecd-
  rootfs/noble/ppc64el

  The first failure happened on November 16.  While there has been an
  update to the util-linux package in noble, this did not land until
  November 23.

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


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

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

[Michael Hudson-Doyle]

Ah no it's a bit simpler than that https://github.com/util-linux/util-
linux/issues/2528.

--disable-libmount-mountfd-support looking better tbh.

** Bug watch added: github.com/util-linux/util-linux/issues #2528
   https://github.com/util-linux/util-linux/issues/2528

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in util-linux package in Ubuntu:
  New
Status in linux source package in Mantic:
  Incomplete
Status in systemd source package in Mantic:
  Confirmed
Status in util-linux source package in Mantic:
  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 systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

[Michael Hudson-Doyle]

So the cause of this, I am fairly sure, is the new "libmount-mountfd"
support in util-linux which seems to have the consequence that "mount -o
remount $mountpoint" fails for an overlay that references paths no
longer available in the current mount namespace.

You can see the discussion of a similar-but-not-the-same issue here
https://github.com/util-linux/util-linux/issues/1992

I'm trying to come up with a reproducer but I have to head afk now. I'll
file a bug upstream when I get that done.

Maybe we should build util-linux with --disable-libmount-mountfd-support
for now (bit late in the release cycle to be uploading util-linux
though...)


** Bug watch added: github.com/util-linux/util-linux/issues #1992
   https://github.com/util-linux/util-linux/issues/1992

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in util-linux package in Ubuntu:
  New
Status in linux source package in Mantic:
  Incomplete
Status in systemd source package in Mantic:
  Confirmed
Status in util-linux source package in Mantic:
  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 systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

[Michael Hudson-Doyle]

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

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in util-linux package in Ubuntu:
  New
Status in linux source package in Mantic:
  Incomplete
Status in systemd source package in Mantic:
  Confirmed
Status in util-linux source package in Mantic:
  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 systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

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

[Michael Hudson-Doyle]

** Tags added: foundaitions-todo

** Tags removed: foundaitions-todo
** Tags added: foundations-todo

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux 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:
  Incomplete
Status in systemd package in Ubuntu:
  Confirmed
Status in linux source package in Mantic:
  Incomplete
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 systemd-remount-f鈥t Root and Kernel File 
Systems...
  [   41.940748] systemd[1]: Starting systemd-udev-trigger.service - Coldplug 
All udev Devices...
   Starting systemd-udev-trig鈥0m - Coldplug All udev 
Devices...
  [   41.964758] systemd[1]: Started systemd-journald.service - Journal Service.
  [  OK  ] Started systemd-journald.service - Journal 
Service.
  [  OK  ] Mounted dev-hugepages.mount - Huge Pages 
File System.
  [  OK  ] Mounted dev-mqueue.mount[鈥�- POSIX Message 
Queue File System.
  [  OK  ] Mounted sys-kernel-debug.m鈥t - Kernel Debug 
File System.
  [  OK  ] Mounted sys-kernel-tracing鈥t - Kernel Trace 
File System.
  [  OK  ] Finished keyboard-setup.se鈥�- Set the console 
keyboard layout.
  [  OK  ] Finished kmod-static-nodes鈥eate List of Static 
Device Nodes.
  [  OK  ] Finished lvm2-monitor.serv鈥ing dmeventd or 
progress polling.
  [  OK  ] Finished modprobe@configfs鈥0m - Load Kernel 
Module configfs.
  [  OK  ] Finished modprobe@dm_mod.s鈥 - Load Kernel 
Module dm_mod.
  [  OK  ] Finished modprobe@drm.service - Load Kernel 
Module drm.
  [  OK  ] Finished modprobe@efi_psto鈥 - Load Kernel 
Module efi_pstore.
  [  OK  ] Finished modprobe@fuse.service - Load Kernel 
Module fuse.
  [  OK  ] Finished modprobe@loop.service - Load Kernel 
Module loop.
  [  OK  ] Finished systemd-modules-l鈥ervice - Load 
Kernel Modules.
  [FAILED] Failed to start systemd-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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 2002427] Re: Subiquity segfault in ARM64 with -64k Kernel

[Michael Hudson-Doyle]

** No longer affects: linux (Ubuntu)

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

** Summary changed:

- Subiquity segfault in ARM64 with -64k Kernel
+ classic snaps do not work on ARM64 kernel configured to use 64k pages

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/2002427

Title:
  classic snaps do not work on ARM64 kernel configured to use 64k pages

Status in Snapcraft:
  New
Status in subiquity:
  New

Bug description:
  [Problem Description]

  Subiquity fails to execute when running on ARM64 with -64k Kernel. It
  exits with the "Segmentation fault" message

  [Additional Info]

  The problem seems to be with python3.8 binary in the snap. The same
  problem occurs with wget binary in the same snap, but ubuntu-distro-
  info works fine. Both python3.8 and wget are statically compiled,
  while ubuntu-distro-info is not.

  root@jammy-arm:~# file /snap/subiquity/4236/usr/bin/python3.8
  /snap/subiquity/4236/usr/bin/python3.8: ELF 64-bit LSB executable, ARM 
aarch64, version 1 (SYSV), dynamically linked, interpreter 
/snap/core20/current/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, 
BuildID[sha1]=bad3f5d001ec1e2ec539f16d8f6729a06cdd68df, stripped
  root@jammy-arm:~# /snap/subiquity/4236/usr/bin/python3.8
  Segmentation fault
  root@jammy-arm:~# ldd /snap/subiquity/4236/usr/bin/python3.8
not a dynamic executable

  root@jammy-arm:~# file /snap/subiquity/4236/usr/bin/wget
  /snap/subiquity/4236/usr/bin/wget: ELF 64-bit LSB pie executable, ARM 
aarch64, version 1 (SYSV), dynamically linked, interpreter 
/snap/core20/current/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, 
BuildID[sha1]=0f2234825d67c22b6b320139445759f6662aa01e, stripped
  root@jammy-arm:~# /snap/subiquity/4236/usr/bin/wget
  Segmentation fault
  root@jammy-arm:~# ldd /snap/subiquity/4236/usr/bin/wget
not a dynamic executable

  root@jammy-arm:~# file /snap/subiquity/4236/usr/bin/ubuntu-distro-info 
  /snap/subiquity/4236/usr/bin/ubuntu-distro-info: ELF 64-bit LSB pie 
executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter 
/snap/core20/current/lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, 
BuildID[sha1]=5d8c4c52d7ce614024eba1ba9069e48ad4192508, stripped
  root@jammy-arm:~# /snap/subiquity/4236/usr/bin/ubuntu-distro-info
  ubuntu-distro-info: You have to select exactly one of --all, --devel, 
--latest, --lts, --stable, --supported, --supported-esm, --series, 
--unsupported.
  root@jammy-arm:~# ldd /snap/subiquity/4236/usr/bin/ubuntu-distro-info
linux-vdso.so.1 (0xfffe7227)
libc.so.6 => /snap/core20/current/lib/aarch64-linux-gnu/libc.so.6 
(0xfffe720b)
/snap/core20/current/lib/ld-linux-aarch64.so.1 => 
/lib/ld-linux-aarch64.so.1 (0xfffe7228)

  The same VM, using the non -64k kernel works:

  # uname -a
  Linux jammy-arm 5.15.0-27-generic #28-Ubuntu SMP Thu Apr 14 12:56:31 UTC 2022 
aarch64 aarch64 aarch64 GNU/Linux
  # /snap/subiquity/4236/usr/bin/python3.8 -c "print('Works')"
  Works

  Tried other kernels (5.17, 5.19) with the same error.

  [Reproducer]

  1. Run a VM in ARM64 architecture:
  virt-install --arch aarch64 --boot uefi --osinfo detect=on,require=off --name 
jammy-arm --memory 8096 --vcpus 4 
--disk=jammy-server-cloudimg-arm64.img,bus=virtio 
--disk=jammy-arm-seed.qcow2,bus=virtio --network network=default,model=virtio 
--boot hd --noautoconsole

  2. Connect to the VM and install a -64k kernel
  
https://launchpad.net/~canonical-kernel-team/+archive/ubuntu/bootstrap/+build/23546569

  3. Reboot in the kernel (I disabled secure boot)
  # uname -a
  Linux jammy-arm 5.15.0-27-generic-64k #28-Ubuntu SMP Thu Apr 14 19:01:31 UTC 
2022 aarch64 aarch64 aarch64 GNU/Linux

  4. Install subiquity
  sudo snap install subiquity

  5. Try to run it
  # /snap/bin/subiquity
  Segmentation fault
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Jan 10 18:24 seq
   crw-rw 1 root audio 116, 33 Jan 10 18:24 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay'
  ApportVersion: 2.20.11-0ubuntu82.3
  Architecture: arm64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord'
  AudioDevicesInUse: Error: command ['fuser', '-v', '/dev/snd/seq', 
'/dev/snd/timer'] failed with exit code 1:
  CRDA: N/A
  CasperMD5CheckResult: unknown
  DistroRelease: Ubuntu 22.04
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  Lsusb-t:
   /:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 5000M
   /:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/15p, 480M
  MachineType: QEMU QEMU Virtual Machine
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm-256color
   

[Kernel-packages] [Bug 1998308] Re: copy_file_range fails with EXDEV on copy to or from tmpfs

[Michael Hudson-Doyle]

Digging a bit suggests this is a result of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.18.y=b9cabd2ec2ff6f452bd5744326cc5c5f503448c6?
At any rate, not a glibc issue.

** Package changed: glibc (Ubuntu) => linux (Ubuntu)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1998308

Title:
  copy_file_range fails with EXDEV on copy to or from tmpfs

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  copy_file_range(2) from ext4 to tmpfs fails.
  Same is true from tmpfs to ext4.

  gcc is already the newest version (4:11.2.0-1ubuntu1).
  libc6 is already the newest version (2.35-0ubuntu3.1).
  linux-image-lowlatency is already the newest version (5.15.0.53.48).

  See example program attached.

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


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

[Kernel-packages] [Bug 1996474] Re: Subiquity installer crashes after the custom partitioning is created

[Michael Hudson-Doyle]

By reading the LVM source I found that unpartitioned CDL formatted DASDs
cannot be included in a LVM volume group. So I guess we should update
the interface to prohibit their use! I would expect that if you add a
single partition to dasdb and put that in the VG instead things will
work.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1996474

Title:
  Subiquity installer crashes after the custom partitioning is created

Status in linux package in Ubuntu:
  New

Bug description:
  ---Problem Description---
  Subiquity installer crashes when I create a custom partitioning and continue. 
It is similar to the Bug "191598 - LP1905412- LVM install broken if other disks 
have meta-data on the VG name already"

  Attached you can find the crash logs.
   
  Contact Information = pp...@de.ibm.com 
   
  ---uname output---
  Linux ubuntu-server 5.15.0-43-generic #46-Ubuntu SMP Tue Jul 12 12:40:17 UTC 
2022 s390x s390x s390x GNU/Linux
   
  Machine Type = z/VM 7.2 
   
  ---boot type---
  QEMU direct boot kernel/initrd
   
  ---Kernel cmdline used to launch install---
  cio_ignore=all,!condev,!0.0.0194,!0.0.0195,!0.0.6000-0.0.6002 
  url=http://9.152.x.x/Ubuntu22/s390x/ubuntu-22.04.1-live-server-s390x.iso 
ip=172.20.115.20::172.20.115.1:255.255.255.0:lnxut01:enc6000:none:172.20.115.1
   
  ---Install repository type---
  Local repository
   
  ---Install repository Location---
  http://9.152.x.x/Ubuntu22/s390x/ubuntu-22.04.1-live-server-s390x.iso
   
  ---Point of failure---
  Other failure during installation (stage 1)

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


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

[Kernel-packages] [Bug 1992468] Re: segfault in ld-linux-x86-64.so

[Michael Hudson-Doyle]

The change to omit DT_HASH was only in 2.36 and so was only present in
kinetic/22.10, and then only briefly as we patched it before release. I
doubt it's that.

Have you reported this upstream at https://sourceware.org/bugzilla/ ?
Have you tried building glibc 2.35 from source? (would be interesting to
know if this is the fault of Ubuntu patches, although that seems
unlikely tbh).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1992468

Title:
  segfault in ld-linux-x86-64.so

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  My manually built elf x64 file has started crashing on load, within the last 
month or so.
  It worked fine on Ubuntu 20.04.x, but fails on 22.04 - same problem on Mint 
19.3 and Fedora 36.

  dmesg ... gives this:

  [ 107.121214] p[4370]: segfault at 0 ip 7f3d725b8350 sp 7ffea111fba0 
error 4 in ld-linux-x86-64.so.2[7f3d72598000+2a000]
  [ 107.121230] Code: ff ff 00 45 31 db 48 8d 15 c9 ac 00 00 4c 8d 05 46 8f 01 
00 4c 8d 2d 1f 8f 01 00 49 89 c2 48 8d 58 ff 48 89 f8 49 f7 da 66 90 <8b> 08 83 
f9 07 77 19 85 c9 74 45 83 f9 07 77 40 48 63 0c 8a 48 01

  You can download the offending file (a single plain 4MB ELF x64) from
  http://phix.x10.mx/p64

  It almost certainly contains older/rarer forms of relocations and suchlike, 
but 
  only about ten or so and meant to be as simple as possible.

  If I need to change the binary content of that file, I can, but might
  need a wee bit of help.

  Of course, if/once it gets through ld-linux-x86-64.so and complains
  about something else, ignore it, or should you be at all intrigued you
  can visit http://phix.x10.mx/download.php to get the full package.

  References, just in case you need them, or to ask a wider set than just me 
for more details direct:
  https://openeuphoria.org/forum/136972.wc?last_id=136973
  https://github.com/petelomax/Phix/issues/13

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


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

[Kernel-packages] [Bug 1990964] Re: FTBFS on kinetic

[Michael Hudson-Doyle]

https://github.com/strace/strace/commit/aeb29a3238ef3cc7f191f98743678d3b4ec949b9
and
https://github.com/strace/strace/commit/a30e5defe41b5b806c223865e92b20d8c9b08f4b
look relevant.

In general, does strace get a release for each kernel release? Should it
be updated in parallel?

** Tags added: foundations-todo

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1990964

Title:
  FTBFS on kinetic

Status in linux package in Ubuntu:
  Fix Released
Status in strace package in Ubuntu:
  Triaged

Bug description:
  As can be seen in [1], strace FTBFS in kinetic: this is caused by the
  kernel headers (linux-libc-dev) which do not define F_GETLK64 and
  other on 64b builds because the kernel contains a bogus commit
  (306f7cc1e906 "uapi: always define F_GETLK64/F_SETLK64/F_SETLKW64 in
  fcntl.h"). This commit actually did the opposite of what it was
  supposed to do, namely defining those macros even on 64b builds. There
  is an attempt here to fix this which was not merged yet:
  
https://lore.kernel.org/lkml/cajf2gtqtnmoeb62-63ou8y4dbrdym7iztdtfluxx9u0ltwu...@mail.gmail.com/T/

  [1]: https://launchpadlibrarian.net/625441996/buildlog_ubuntu-kinetic-
  amd64.strace_5.16-0ubuntu4_BUILDING.txt.gz

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


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

[Kernel-packages] [Bug 1985956] Re: linux-libc-dev and libc6-dev do not agree who owns fsconfig_command

[Michael Hudson-Doyle]

I think
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=774058d72942249f71d74e7f2b639f77184160a6
might help here.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1985956

Title:
  linux-libc-dev and libc6-dev do not agree who owns  fsconfig_command

Status in glibc package in Ubuntu:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Right now in kinetic-proposed builds are failing due to both sets of
  headers defining fsconfig_command.

  
  
(kinetic-amd64)root@Keschdeichel:/build/libvirt-LTnG76/libvirt-8.6.0/debian/build#
 apt-cache policy libc6-dev linux-libc-dev
  libc6-dev:
Installed: 2.36-0ubuntu1
Candidate: 2.36-0ubuntu1
Version table:
   *** 2.36-0ubuntu1 500
  500 http://archive.ubuntu.com/ubuntu kinetic-proposed/main amd64 
Packages
  100 /var/lib/dpkg/status
   2.35-0ubuntu3 500
  500 http://archive.ubuntu.com/ubuntu kinetic/main amd64 Packages
  linux-libc-dev:
Installed: 5.19.0-15.15
Candidate: 5.19.0-15.15
Version table:
   *** 5.19.0-15.15 500
  500 http://archive.ubuntu.com/ubuntu kinetic-proposed/main amd64 
Packages
  100 /var/lib/dpkg/status
   5.15.0-27.28 500
  500 http://archive.ubuntu.com/ubuntu kinetic/main amd64 Packages

  
  Actually also with "just the kernel" from proposed this happens as in the 
past only:
linux-libc-dev:amd64: /usr/include/linux/mount.h
  included that struct.

  File ownership
  $ dpkg -S /usr/include/x86_64-linux-gnu/sys/mount.h /usr/include/linux/mount.h
  libc6-dev:amd64: /usr/include/x86_64-linux-gnu/sys/mount.h
  linux-libc-dev:amd64: /usr/include/linux/mount.h

  Example error from building libvirt:
  In file included from /usr/include/linux/fs.h:19,
   from ../../src/util/virfile.c:74:
  /usr/include/linux/mount.h:95:6: error: redeclaration of 'enum 
fsconfig_command'
 95 | enum fsconfig_command {
|  ^~~~
  In file included from ../../src/util/virfile.c:46:
  /usr/include/x86_64-linux-gnu/sys/mount.h:189:6: note: originally defined here
189 | enum fsconfig_command
|  ^~~~


  Repro-test:
  $ cat test.c  
  # include 
  # include 

  #include 

  int main() {
 printf("Hello %d", FSCONFIG_SET_FLAG);
 return 0;
  }

  
  gcc test.c -o /dev/null 
  In file included from /usr/include/linux/fs.h:19,
   from test.c:2:
  /usr/include/linux/mount.h:95:6: error: redeclaration of 'enum 
fsconfig_command'
 95 | enum fsconfig_command {
|  ^~~~
  In file included from test.c:1:
  /usr/include/x86_64-linux-gnu/sys/mount.h:189:6: note: originally defined here
189 | enum fsconfig_command
|  ^~~~
  /usr/include/linux/mount.h:96:9: error: redeclaration of enumerator 
'FSCONFIG_SET_FLAG'
 96 | FSCONFIG_SET_FLAG   = 0,/* Set parameter, supplying 
no value */
| ^
  /usr/include/x86_64-linux-gnu/sys/mount.h:191:3: note: previous definition of 
'FSCONFIG_SET_FLAG' with type 'enum fsconfig_command'
191 |   FSCONFIG_SET_FLAG   = 0,/* Set parameter, supplying no 
value */
|   ^
  /usr/include/linux/mount.h:97:9: error: redeclaration of enumerator 
'FSCONFIG_SET_STRING'
 97 | FSCONFIG_SET_STRING = 1,/* Set parameter, supplying a 
string value */
| ^~~
  /usr/include/x86_64-linux-gnu/sys/mount.h:193:3: note: previous definition of 
'FSCONFIG_SET_STRING' with type 'enum fsconfig_command'
193 |   FSCONFIG_SET_STRING = 1,/* Set parameter, supplying a 
string value */
|   ^~~
  /usr/include/linux/mount.h:98:9: error: redeclaration of enumerator 
'FSCONFIG_SET_BINARY'
 98 | FSCONFIG_SET_BINARY = 2,/* Set parameter, supplying a 
binary blob value */
| ^~~
  /usr/include/x86_64-linux-gnu/sys/mount.h:195:3: note: previous definition of 
'FSCONFIG_SET_BINARY' with type 'enum fsconfig_command'
195 |   FSCONFIG_SET_BINARY = 2,/* Set parameter, supplying a 
binary blob value */
|   ^~~
  /usr/include/linux/mount.h:99:9: error: redeclaration of enumerator 
'FSCONFIG_SET_PATH'
 99 | FSCONFIG_SET_PATH   = 3,/* Set parameter, supplying 
an object by path */
| ^
  /usr/include/x86_64-linux-gnu/sys/mount.h:197:3: note: previous definition of 
'FSCONFIG_SET_PATH' with type 'enum fsconfig_command'
197 |   FSCONFIG_SET_PATH   = 3,/* Set parameter, supplying an 
object by path */
|   ^
  /usr/include/linux/mount.h:100:9: error: redeclaration of enumerator 
'FSCONFIG_SET_PATH_EMPTY'
100 | FSCONFIG_SET_PATH_EMPTY = 4,/* Set parameter, supplying 
an object by 

[Kernel-packages] [Bug 1960392] Re: Ubuntu server 22.04 installation crash with intel VROC sata raid

[Michael Hudson-Doyle]

So the reason this doesn't work is that the udev data for the container,
/dev/md/imsm0, does not contain the keys we look for to work out which
devices are part of it. We expect to find keys called things like
MD_DEVICE_dev_sda_DEV but they are not there. There is
UDISKS_MD_DEVICE_dev_sda_DEV though and this is very strange because the
code to produce the MD_DEVICE and UDISKS_MD_DEVICE keys is essentially
the same:

IMPORT{program}="BINDIR/mdadm --detail --export $devnode"

SUBSYSTEM=="block", KERNEL=="md*", ENV{DEVTYPE}!="partition",
IMPORT{program}="/bin/sh -c '/sbin/mdadm --detail --export $tempnode |
/bin/sed s/^MD_/UDISKS_MD_/g'"

I don't know why one use tempnode and one devnode -- maybe that's
significant? Or maybe it's a race where the mdadm rules run before the
devices is really ready or something. Does this happen every time?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1960392

Title:
  Ubuntu server 22.04 installation crash with intel VROC sata raid

Status in subiquity:
  New
Status in linux package in Ubuntu:
  Invalid

Bug description:
  Reproduce steps:
  1.Setup raid 0 with 2 sata disks and intel VROC SATA controller.
  2.Install Ubuntu server 22.04 with the latest image.
  3.It crash with error "devices or container for raid must be specified"

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


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

[Kernel-packages] [Bug 1929889] Re: [TGL][ADL] Enable CET(Control-flow Enforcement Technology)

[Michael Hudson-Doyle]

I had a poke at this, and although the cet-backport.diff file is present
in the source package, it is not actually applied and hasn't been since
some time in Groovy's development cycle afaict. This makes sense because
also afaict, this all went upstream in glibc 2.32, which was the version
in groovy.

So is what's needed a backport of this to focal? cet-backport.diff
applies cleanly to the package I am preparing for upload to focal, so
from that side of things it's all OK. We need a nice explicit glibc SRU
bug clearly asking for this, complete with test case before that can
happen though. I don't feel like I would be the best person to file this
bug! (to put it mildly).

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-intel in Ubuntu.
https://bugs.launchpad.net/bugs/1929889

Title:
  [TGL][ADL] Enable CET(Control-flow Enforcement Technology)

Status in intel:
  New
Status in intel lookout-canyon series:
  New
Status in linux-intel package in Ubuntu:
  Triaged
Status in linux-intel source package in Focal:
  New

Bug description:
  Description
  Enable Tiger Lake ROP CET(Control-flow Enforcement Technology)
  An upcoming Intel® processor family feature that counters 
return/jump-oriented programming (ROP) attacks

  Hardware: Tiger Lake & Alder Lake

  Target Release: 21.04
  Target Kernel: TBD

  External links:
  
https://github.com/intel/linux-intel-quilt/tree/mainline-tracking-v5.11-yocto-210223T083754Z

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


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

[Kernel-packages] [Bug 1940860] Re: Mellanox NIC interface names change between 5.4 and 5.8

[Michael Hudson-Doyle]

I should say here that I don't really know what changes to subiquity are
desirable here. I don't really like the idea of subiquity always using
set-name, that just feels wrong, but I can see the problem here too.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1940860

Title:
  Mellanox NIC interface names change between 5.4 and 5.8

Status in subiquity:
  New
Status in linux package in Ubuntu:
  Confirmed
Status in systemd package in Ubuntu:
  New

Bug description:
  I noticed on a couple of systems that my network interface names
  change when upgrading from the focal LTS (5.4) kernel to the focal HWE
  (both 5.8 & 5.11) kernels. Both systems have Mellanox Connect-X 5
  NICs.

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.4.0-81-generic #91-Ubuntu SMP Thu Jul 15 19:10:30 UTC 2021 
aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0  enp1s0f1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.8.0-63-generic #71~20.04.1-Ubuntu SMP Thu Jul 15 17:46:44 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  dannf@bizzy:~$ uname -a
  Linux bizzy 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 15:58:08 UTC 
2021 aarch64 aarch64 aarch64 GNU/Linux
  dannf@bizzy:~$ ls /sys/class/net
  enp1s0f0np0  enp1s0f1np1  enx3e8734bc294f  lo

  I bisected this down to a kernel change:
  # first bad commit: [c6acd629eec754a9679f922d51f90e44c769b80c] net/mlx5e: Add 
support for devlink-port in non-representors mode

  The impact is that your network can fail to come up after
  transitioning from the LTS kernel to the HWE kernel. Now, this isn't a
  huge problem for MAAS installs because MAAS configures netplan to
  always use the same names as were used at commissioning. It does
  impact subiquity based installs however, which do not.

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


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

[Kernel-packages] [Bug 1876011] Re: Kernel Panic when dasd-fba device is selected for install

[Michael Hudson-Doyle]

** Changed in: subiquity
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1876011

Title:
  Kernel Panic when dasd-fba device is selected for install

Status in curtin:
  Incomplete
Status in subiquity:
  In Progress
Status in Ubuntu on IBM z Systems:
  Triaged
Status in linux package in Ubuntu:
  Fix Released

Bug description:
  Stating a zVM install (either subiquity or d-i) and selecting dasd-fba
  devices leads to a kernel panic.

  Details from the installer shell before the panic:

  root@ubuntu-server:/# uname -a
  Linux ubuntu-server 5.4.0-26-generic #30-Ubuntu SMP Mon Apr 20 16:57:22 UTC 
2020 s390x s390x s390x GNU/Linux

  root@ubuntu-server:/# cat /proc/cmdline
  
ip=10.245.208.13::10.245.208.1:255.255.255.0:s5lp1-gen03:enc600:none:10.245.208.1
  url=ftp://10.13.0.2:21/ubuntu-live-server-20.04/focal-live-server-s390x.iso  
http_proxy=http://91.189.89.11:3128 --- quiet
  root@ubuntu-server:/#

  root@ubuntu-server:/# lsmod
  Module  Size  Used by
  dm_multipath   40960  0
  scsi_dh_rdac   20480  0
  scsi_dh_emc16384  0
  scsi_dh_alua   24576  0
  vmur   20480  0
  vfio_ccw   36864  0
  vfio_mdev  16384  0
  mdev   28672  2 vfio_ccw,vfio_mdev
  vfio_iommu_type1   32768  0
  vfio   36864  3 vfio_ccw,vfio_mdev,vfio_iommu_type1
  sch_fq_codel   20480  1
  drm   499712  0
  drm_panel_orientation_quirks16384  1 drm
  i2c_core   77824  1 drm
  ip_tables  32768  0
  x_tables   45056  1 ip_tables
  overlay   135168  1
  nls_utf8   16384  1
  isofs  49152  1
  qeth_l245056  1
  lcs53248  0
  zfcp  126976  0
  scsi_transport_fc  69632  1 zfcp
  raid10 65536  0
  raid456   180224  0
  async_raid6_recov  20480  1 raid456
  async_memcpy   20480  1 raid456
  async_pq   20480  1 raid456
  async_xor  20480  2 async_pq,raid456
  async_tx   20480  5 
async_pq,async_memcpy,async_xor,raid456,async_raid6_recov
  xor16384  1 async_xor
  raid6_pq  102400  3 async_pq,raid456,async_raid6_recov
  libcrc32c  16384  1 raid456
  raid1  53248  0
  raid0  28672  0
  linear 20480  0
  pkey   32768  0
  crc32_vx_s390  16384  1
  ghash_s390 16384  0
  prng   20480  4
  aes_s390   28672  0
  des_s390   20480  0
  libdes 28672  1 des_s390
  sha512_s39016384  0
  sha256_s39016384  0
  sha1_s390  16384  0
  sha_common 16384  3 sha512_s390,sha256_s390,sha1_s390
  qeth  135168  1 qeth_l2
  dasd_fba_mod   24576  0
  dasd_eckd_mod 131072  0
  qdio   61440  3 qeth,zfcp,qeth_l2
  ccwgroup   20480  3 qeth,lcs,qeth_l2
  dasd_mod  143360  2 dasd_eckd_mod,dasd_fba_mod
  zcrypt_cex420480  0
  zcrypt106496  2 pkey,zcrypt_cex4

  root@ubuntu-server:/# dmesg | tail
  [   34.458754] audit: type=1400 audit(1588204779.286:14): apparmor="STATUS" 
operation="profile_load" profile="unconfined" 
name="snap.subiquity.subiquity-service" pid=1789 comm="apparmor_parser"
  [  190.647685] ctcm.151d85: CTCM driver initialized
  [  190.663097] dasd-fba.f36f2f: 0.0.0101: New FBA DASD 9336/10 (CU 6310/80) 
with 16383 MB and 512 B/blk
  [  190.664748]  dasda: dasda1
  [  193.364797] dasd-fba.f36f2f: 0.0.0102: New FBA DASD 9336/10 (CU 6310/80) 
with 16383 MB and 512 B/blk
  [  193.366573]  dasdb:(nonl) dasdb1
  [  195.743686] dasd-fba.f36f2f: 0.0.0103: New FBA DASD 9336/10 (CU 6310/80) 
with 16383 MB and 512 B/blk
  [  195.745327]  dasdc:(nonl) dasdc1
  [  198.408631] dasd-fba.f36f2f: 0.0.0104: New FBA DASD 9336/10 (CU 6310/80) 
with 16384 MB and 512 B/blk
  [  198.411231]  dasdd:(nonl) dasdd1

  Dropped to shell after partition confirmation to run tail on syslog

  root@ubuntu-server:/# tail -f /var/log/syslog
  Apr 30 00:10:08 ubuntu-server curtin_log.2234[2946]: Shutdown Plan:
  Apr 30 00:10:08 ubuntu-server curtin_log.2234[2946]: {'level': 6, 'device': 
'/sys/class/block/dm-0', 'dev_type': 'lvm'}
  Apr 30 00:10:08 ubuntu-server curtin_log.2234[2946]: {'level': 4, 'device': 
'/sys/class/block/dasda/dasda1', 'dev_type': 'partition'}
  Apr 30 00:10:08 ubuntu-server curtin_log.2234[2946]: {'level': 2, 'device': 
'/sys/class/block/dasda', 'dev_type': 'disk'}
  Apr 30 00:10:08 ubuntu-server curtin_log.2234[2946]: shutdown running on 
holder type: 'lvm' syspath: '/sys/class/block/dm-0'
  Apr 30 00:10:08 ubuntu-server curtin_log.2234[2946]: Running 

[Kernel-packages] [Bug 1890884] Re: kernel trace of 18.04.5 daily image (20200806.1) on Hisilicon D06 arm64 arch

[Michael Hudson-Doyle]

Err. Just to check, you are booting with the right initramfs? Can you
share your pxe(linux emulation) config?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1890884

Title:
  kernel trace of 18.04.5 daily image (20200806.1) on Hisilicon D06
  arm64 arch

Status in subiquity:
  New
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  image: 18.04.5 daily image (20200806.1) bionic-live-server-arm64.iso
  kernel: 4.15.0-112-generic #113-Ubuntu
  platform: Hisilicon D06 arm64 arch

  [Reproducing Steps]
  1. setup pxe boot by following 
https://discourse.ubuntu.com/t/netbooting-the-live-server-installer/14510
  2. pxe boot the machine with the image

  [Expected Result]
  Boot to subiquity

  [Actual Result]
  Kernel trace happened during booting process. Reproducing rate: 2 out of 2.

  [8.375118] md: ... autorun DONE.
  [8.378478] VFS: Cannot open root device "(null)" or unknown-block(0,0): 
error -6
  [8.385955] Please append a correct "root=" boot option; here are the 
available partitions:
  [8.394303] Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0)
  [8.402554] CPU: 32 PID: 1 Comm: swapper/0 Not tainted 4.15.0-112-generic 
#113-Ubuntu
  [8.410369] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - 
V1.20.01 04/26/2019
  [8.418879] Call trace:
  [8.421316]  dump_backtrace+0x0/0x198
  [8.424965]  show_stack+0x24/0x30
  [8.428269]  dump_stack+0x98/0xbc
  [8.431572]  panic+0x128/0x2a4
  [8.434615]  mount_block_root+0x210/0x2e8
  [8.438610]  mount_root+0x7c/0x8c
  [8.441912]  prepare_namespace+0x144/0x1dc
  [8.445995]  kernel_init_freeable+0x218/0x23c
  [8.450341]  kernel_init+0x18/0x110
  [8.453817]  ret_from_fork+0x10/0x18
  [8.457486] SMP: stopping secondary CPUs
  [8.461836] Kernel Offset: disabled
  [8.465312] CPU features: 0x03200a38
  [8.468873] Memory Limit: none
  [8.473291] Unable to handle kernel paging request at virtual address 
09865034
  [8.481192] Mem abort info:
  [8.483972]   ESR = 0x9661
  [8.487013]   Exception class = DABT (current EL), IL = 32 bits
  [8.492918]   SET = 0, FnV = 0
  [8.495958]   EA = 0, S1PTW = 0
  [8.499086] Data abort info:
  [8.501953]   ISV = 0, ISS = 0x0061
  [8.505774]   CM = 0, WnR = 1
  [8.508729] swapper pgtable: 4k pages, 48-bit VAs, pgd = (ptrval)
  [8.515502] [09865034] *pgd=0a5fe003, 
*pud=0a5fd003, *pmd=0a5f7003, *pte=006894110703
  [8.526445] Internal error: Oops: 9661 [#1] SMP
  [8.531310] Modules linked in:
  [8.534351] Process swapper/0 (pid: 1, stack limit = 0x(ptrval))
  [8.541039] CPU: 32 PID: 1 Comm: swapper/0 Not tainted 4.15.0-112-generic 
#113-Ubuntu
  [8.548854] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - 
V1.20.01 04/26/2019
  [8.557363] pstate: 60800089 (nZCv daIf -PAN +UAO)
  [8.562144] pc : acpi_os_write_memory+0xac/0x158
  [8.566749] lr : apei_write+0xb0/0xc0
  [8.570397] sp : 09afb900
  [8.573698] x29: 09afb900 x28: fffe
  [8.578996] x27:  x26: ffa5
  [8.584294] x25: ffbe x24: 0080
  [8.589592] x23: 0005 x22: 0008
  [8.594890] x21: 0040 x20: 0010
  [8.600188] x19: 94110034 x18: 0003
  [8.605486] x17:  x16: 0009
  [8.610784] x15: 001f x14: 8205169d4225fc6e
  [8.616082] x13: 34650f577629d387 x12: 9c021ee3f3d0bcca
  [8.621380] x11: b1ae83ff50c19148 x10: b6b91ab42ae87562
  [8.626678] x9 : f469cb78cb1add9d x8 : a16fcb806efa3dd5
  [8.631976] x7 : 0001 x6 : 94110034
  [8.637274] x5 : 9411003c x4 : 09639fb8
  [8.642571] x3 :  x2 : 0034
  [8.647869] x1 : 0010 x0 : 09865034
  [8.653167] Call trace:
  [8.655601]  acpi_os_write_memory+0xac/0x158
  [8.659858]  apei_write+0xb0/0xc0
  [8.663160]  __apei_exec_write_register+0x88/0xb0
  [8.667851]  apei_exec_write_register_value+0x2c/0x38
  [8.672888]  __apei_exec_run+0xac/0x108
  [8.676711]  erst_write+0x154/0x268
  [8.680186]  erst_writer+0x26c/0x3b0
  [8.683751]  pstore_dump+0x1b4/0x330
  [8.687313]  kmsg_dump+0xd0/0x100
  [8.690615]  panic+0x164/0x2a4
  [8.693656]  mount_block_root+0x210/0x2e8
  [8.697652]  mount_root+0x7c/0x8c
  [8.700953]  prepare_namespace+0x144/0x1dc
  [8.705035]  kernel_init_freeable+0x218/0x23c
  [8.709380]  kernel_init+0x18/0x110
  [8.712855]  ret_from_fork+0x10/0x18
  [8.716418] Code: 54000380 710102bf 54000561 d5033e9f (f914)
  [8.722499] ---[ end trace 

[Kernel-packages] [Bug 1534162] Re: symlinks managed by kernel postinst are different from zipl-installer and livefs-rootfs

[Michael Hudson-Doyle]

** Changed in: subiquity
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1534162

Title:
  symlinks managed by kernel postinst are different from zipl-installer
  and livefs-rootfs

Status in curtin:
  Fix Released
Status in subiquity:
  Fix Released
Status in base-installer package in Ubuntu:
  Fix Released
Status in linux package in Ubuntu:
  Invalid
Status in livecd-rootfs package in Ubuntu:
  Invalid
Status in zipl-installer package in Ubuntu:
  Fix Released

Bug description:
  
  On Ubuntu/Debian like systems /etc/kernel-img.conf should be created by the 
"installer". It is currently done by base-installer/live-installer/ubiquity but 
not curtin, but it should be. At the moment we require kernel-img.conf and we 
do not have the correct per-arch built-in defaults for its settings in all of 
our kernels. It is not a config file, nor is it created by livecd-rootfs (after 
all our squashfs might be containers, and never live to install kernels and 
bootloaders).

  One day we might fix our kernels to not require kernel-img.conf, but
  until then curtin should be generating the right one. Making a merge
  proposal to fix this in curtin by mimicking what base-installer did.

  ==

  Symlinks are not managed correctly.

  Last installed and configured kernel, prior to purging -5- was -6-,
  yet symlinks were not updated to -6- when that happened.

  root@devac03:~# apt-get remove --purge linux-headers-4.3.0-5 
linux-headers-4.3.0-5-generic linux-image-4.3.0-5-generic 
linux-image-extra-4.3.0-5-generic
  Reading package lists... Done
  Building dependency tree
  Reading state information... Done
  The following packages will be REMOVED:
    linux-headers-4.3.0-5* linux-headers-4.3.0-5-generic* 
linux-image-4.3.0-5-generic*
    linux-image-extra-4.3.0-5-generic*
  0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.
  After this operation, 131 MB disk space will be freed.
  Do you want to continue? [Y/n] Y
  (Reading database ... 92073 files and directories currently installed.)
  Removing linux-headers-4.3.0-5-generic (4.3.0-5.16) ...
  Removing linux-headers-4.3.0-5 (4.3.0-5.16) ...
  Removing linux-image-extra-4.3.0-5-generic (4.3.0-5.16) ...
  run-parts: executing /etc/kernel/postinst.d/apt-auto-removal 4.3.0-5-generic 
/boot/vmlinuz-4.3.0-5-generic
  run-parts: executing /etc/kernel/postinst.d/initramfs-tools 4.3.0-5-generic 
/boot/vmlinuz-4.3.0-5-generic
  update-initramfs: Generating /boot/initrd.img-4.3.0-5-generic
  Using config file '/etc/zipl.conf'
  Building bootmap in '/boot/'
  Building menu 'zipl-automatic-menu'
  Adding #1: IPL section 'ubuntu' (default)
  Preparing boot device: dasda (0200).
  Done.
  run-parts: executing /etc/kernel/postinst.d/pm-utils 4.3.0-5-generic 
/boot/vmlinuz-4.3.0-5-generic
  run-parts: executing /etc/kernel/postinst.d/zz-zipl 4.3.0-5-generic 
/boot/vmlinuz-4.3.0-5-generic
  Using config file '/etc/zipl.conf'
  Building bootmap in '/boot/'
  Building menu 'zipl-automatic-menu'
  Adding #1: IPL section 'ubuntu' (default)
  Preparing boot device: dasda (0200).
  Done.
  Purging configuration files for linux-image-extra-4.3.0-5-generic 
(4.3.0-5.16) ...
  Removing linux-image-4.3.0-5-generic (4.3.0-5.16) ...
  WARN: Proceeding with removing running kernel image.
  Examining /etc/kernel/postrm.d .
  run-parts: executing /etc/kernel/postrm.d/initramfs-tools 4.3.0-5-generic 
/boot/vmlinuz-4.3.0-5-generic
  update-initramfs: Deleting /boot/initrd.img-4.3.0-5-generic
  run-parts: executing /etc/kernel/postrm.d/zz-zipl 4.3.0-5-generic 
/boot/vmlinuz-4.3.0-5-generic
  Using config file '/etc/zipl.conf'
  Error: Image file '/boot/vmlinuz' in section 'ubuntu': No such file or 
directory
  run-parts: /etc/kernel/postrm.d/zz-zipl exited with return code 1
  Failed to process /etc/kernel/postrm.d at 
/var/lib/dpkg/info/linux-image-4.3.0-5-generic.postrm line 328.
  dpkg: error processing package linux-image-4.3.0-5-generic (--purge):
   subprocess installed post-removal script returned error exit status 1
  Errors were encountered while processing:
   linux-image-4.3.0-5-generic
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  root@devac03:~# ls -latr /boot
  total 24208
  drwx--  2 root root16384 Dec  9 16:38 lost+found
  lrwxrwxrwx  1 root root   26 Jan  6 16:23 initrd.img -> 
initrd.img-4.3.0-5-generic
  lrwxrwxrwx  1 root root   23 Jan  6 16:24 vmlinuz -> 
vmlinuz-4.3.0-5-generic
  -rw---  1 root root 13026048 Jan 11 21:36 vmlinuz-4.3.0-6-generic
  -rw---  1 root root  2446124 Jan 11 21:36 System.map-4.3.0-6-generic
  -rw-r--r--  1 root root63422 Jan 11 21:36 config-4.3.0-6-generic
  -rw-r--r--  1 root root   517933 Jan 11 21:36 abi-4.3.0-6-generic
  drwxr-xr-x 22 root root 4096 Jan 14 13:03 ..
  -rw-r--r--  1 root root  8574889 Jan 14 13:03 initrd.img-4.3.0-6-generic
  

[Kernel-packages] [Bug 1866319] Re: reboot crash in qla2x00_shutdown()

[Michael Hudson-Doyle]

I don't think this was ever a bug in subiquity.

** Changed in: subiquity
   Status: New => Fix Released

** Changed in: subiquity
   Status: Fix Released => Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1866319

Title:
  reboot crash in qla2x00_shutdown()

Status in subiquity:
  Invalid
Status in linux package in Ubuntu:
  Incomplete

Bug description:
  focal daily live iso (200227)
  d06

  [Steps to Reproduce]
  1. Download the daily live iso over 
http://www.cdimage.ubuntu.com/ubuntu-server/daily-live/20200227/focal-live-server-arm64.iso
 and boot from the iso
  2. Boot into the installation process by selecting "Install Ubuntu Server"
  3. Follow the subiquity instruction and update subiquity at the very 
beginning of the installation[1]
  4. Follow the subiquity instruction to complete the installation on reboot.

  [1] If you don't update it, it will be this bug LP: #1866318 . Prompt
  of subiquity installation

  Version 19.12.2+git49.436ee1d7 of the installer is now available
  (19.10.2 is currently running).

  [Expected Result]
  The system reboots and get ready to use.

  [Actual Result]

  The system hangs on reboot. Show some of the messages:

  [FAILED] Failed unmounting /cdrom.

  [ 790.782440] Hardware name: Huawei D06 /D06, BIOS Hisilicon D06 UEFI RC0 - 
V1.20.01 04/26/2019
  [ 790.790955] pstate: 6049 (nZCv daif +PAN -UAO)
  [ 790.795747] pc : __free_pages+0x28/0x68
  [ 790.799578] lr : __iommu_dma_free_pages+0x38/0x58
  [ 790.804271] sp : 11eabb00
  [ 790.807575] x29: 11eabb00 x28: 803f7abf8ec0
  [ 790.812878] x27:  x26: 8a3f7b88e130
  [ 790.818180] x25: 11156100 x24: 10e10908
  [ 790.823481] x23:  x22: 803f515ebc80
  [ 790.828783] x21: 0010 x20: 
  [ 790.834084] x19:  x18: 0010
  [ 790.839386] x17: 8158135c x16: db594df8
  [ 790.844688] x15: 803f7abf93e8 x14: 
  [ 790.849989] x13: 91eab827 x12: 11eab82f
  [ 790.855291] x11: 118ef000 x10: 
  [ 790.860592] x9 : 11ae9000 x8 : 07ad
  [ 790.865894] x7 : 0017 x6 : 11ae8995
  [ 790.871196] x5 : 0007 x4 : 
  [ 790.876497] x3 : 11ae8930 x2 : 
  [ 790.881798] x1 : 0034 x0 : 
  [ 790.887101] Call trace:
  [ 790.889540] __free_pages+0x28/0x68
  [ 790.893020] __iommu_dma_free_pages+0x38/0x58
  [ 790.897366] __iommu_dma_free+0xb8/0xf8
  [ 790.901192] iommu_dma_free+0x48/0x58
  [ 790.904848] dma_free_attrs+0xd4/0xf0
  [ 790.908546] qla2x00_free_fw_dump+0x58/0xb8 [qla2xxx]
  [ 790.913616] qla2x00_shutdown+0xd4/0x160 [qla2xxx]
  [ 790.918402] pci_device_shutdown+0x44/0x88
  [ 790.922494] device_shutdown+0x134/0x240
  [ 790.926414] kernel_restart_prepare+0x44/0x50
  [ 790.930761] kernel_restart+0x20/0x68
  [ 790.934414] __do_sys_reboot+0x100/0x228
  [ 790.938327] __arm64_sys_reboot+0x2c/0x38
  [ 790.942328] el0_svc_common.constprop.0+0xdc/0x1d8
  [ 790.947109] el0_svc_handler+0x34/0x90
  [ 790.950847] el0_svc+0x10/0x14
  [ 790.953898] Code: d503201f 9100d261 52800020 4b0003e0 (b8e0003e)
  [ 790.960151] ---[ end trace 37539b75957dd46c ]---
  [ 790.970536] Unable to handle kernel paging request at virtual address 
10075034
  [ 790.978440] Mem abort info:
  [ 790.981223] ESR = 0x9661
  [ 790.984267] Exception class = DABT (current EL), IL = 32 bits
  [ 790.990175] SET = 0, FnV = 0
  [ 790.993218] EA = 0, S1PTW = 0
  [ 790.996347] Data abort info:
  [ 790.999217] ISV = 0, ISS = 0x0061
  [ 791.003041] CM = 0, WnR = 1
  [ 791.005999] swapper pgtable: 4k pages, 48-bit VAs, pgdp=0125b000
  [ 791.012689] [10075034] pgd=0a5ff003, pud=0a5fe003, 
pmd=0a5fd003, pte=00e894110703
  [ 850.657602] rcu: INFO: rcu_sched detected stalls on CPUs/tasks:
  [ 850.663528] rcu: 61-...0: (7 ticks this GP) idle=33a/1/0x4000 
softirq=5287/5287 fqs=5638
  [ 850.672833] (detected by 3, t=15005 jiffies, g=81461, q=101)
  [ 850.678569] Task dump for CPU 61:
  [ 850.681872] shutdown R running task 0 1 0 0x002a
  [ 850.688909] Call trace:
  [ 850.691347] __switch_to+0xe4/0x148
  [ 850.694823] 0x25

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

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

[Kernel-packages] [Bug 1871611] Re: multipath nvme, failed to install with multipath disabled install failed crashed with CalledProcessError

[Michael Hudson-Doyle]

I'm not sure of the status of this bug now. Was it all fixed by release?

** Changed in: subiquity
   Status: New => Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1871611

Title:
  multipath nvme, failed to install with multipath disabled install
  failed crashed with CalledProcessError

Status in curtin:
  Invalid
Status in subiquity:
  Incomplete
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  multipath nvme, failed to install with multipath disabled install
  failed crashed with CalledProcessError

  
  so trying to install with nvme_core.multipath=0 set on the cmdline, and that 
fails.

  ProblemType: Bug
  DistroRelease: Ubuntu 20.04
  Package: subiquity (1641)
  ProcVersionSignature: Ubuntu 5.4.0-21.25-generic 5.4.27
  Uname: Linux 5.4.0-21-generic ppc64le
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  ApportVersion: 2.20.11-0ubuntu24
  Architecture: ppc64el
  CasperVersion: 1.443
  CrashDB:
   {
  "impl": "launchpad",
  "project": "subiquity",
  "bug_pattern_url": 
"http://people.canonical.com/~ubuntu-archive/bugpatterns/bugpatterns.xml;
   }
  Date: Wed Apr  8 11:35:20 2020
  ExecutablePath: /snap/subiquity/1638/usr/bin/subiquity
  InstallerLog: Error: [Errno 2] No such file or directory: 'logfile'
  InterpreterPath: /snap/subiquity/1638/usr/bin/python3.6
  LiveMediaBuild: Ubuntu-Server 20.04 LTS "Focal Fossa" - Beta ppc64el 
(20200408)
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 1d6b:0107 Linux Foundation USB Virtual Hub
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  ProcAttrCurrent: snap.subiquity.subiquity (complain)
  ProcCmdline: /snap/subiquity/1638/usr/bin/python3 
/snap/subiquity/1638/usr/bin/subiquity
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdLine: ip=dhcp 
url=http://cdimage.ubuntu.com/hostname/daily-live/pending/focal-live-server-ppc64el.iso
 subiquity-channel=latest/edge nvme_core.multipath=0 
http_proxy=http://91.189.89.11:3128 --- quiet
  ProcLoadAvg: 0.11 1.05 0.96 1/1380 14592
  ProcLocks:
   1: FLOCK  ADVISORY  WRITE 5503 00:18:751 0 EOF
   2: POSIX  ADVISORY  WRITE 5198 00:18:647 0 EOF
   3: POSIX  ADVISORY  WRITE 5520 00:18:760 0 EOF
  ProcSwaps: Filename   TypeSizeUsed
Priority
  ProcVersion: Linux version 5.4.0-21-generic (buildd@bos02-ppc64el-028) (gcc 
version 9.3.0 (Ubuntu 9.3.0-8ubuntu1)) #25-Ubuntu SMP Sat Mar 28 13:10:37 UTC 
2020
  Python3Details: /usr/bin/python3.8, Python 3.8.2, python3-minimal, 
3.8.2-0ubuntu2
  PythonDetails: N/A
  SnapChannel:
   
  SnapRevision: 1638
  SnapUpdated: False
  SnapVersion: 20.03.3+git132.a0dae13d
  SourcePackage: subiquity
  Title: install failed crashed with CalledProcessError
  UpgradeStatus: No upgrade log present (probably fresh install)
  UsingAnswers: False
  VarLogDump_list: total 0
  cpu_cores: Number of cores present = 32
  cpu_coreson: Number of cores online = 32
  cpu_smt: SMT=4

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

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

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

** No longer affects: linux-azure (Ubuntu)

** No longer affects: systemd (Ubuntu)

** Also affects: cloud-utils (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: cloud-initramfs-tools (Ubuntu Eoan)
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-utils package in Ubuntu:
  Fix Released
Status in cloud-initramfs-tools source package in Eoan:
  New
Status in cloud-utils source package in Eoan:
  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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

Great, thanks for confirming.

I wonder if we should SRU this. You see it on Eoan I presume? The bug is
theoretically present in Bionic too aiui but if it never crops up I
don't know if it's worth it.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-utils package in Ubuntu:
  Fix Released
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

Can someone from CPC confirm that this has fixed the issues in the Azure
tests?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure in Ubuntu.
https://bugs.launchpad.net/bugs/1834875

Title:
  cloud-init growpart race with udev

Status in cloud-init:
  Incomplete
Status in cloud-utils:
  Fix Committed
Status in cloud-initramfs-tools package in Ubuntu:
  Fix Released
Status in cloud-utils package in Ubuntu:
  Fix Released
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1856045] Re: capabilities set with setcap are not honoured

[Michael Hudson-Doyle]

Talking about this more, the Ubuntu solution for this sort of thing is
to configure sudo appropriately, so we'll close the bug here.

** Changed in: iproute2 (Ubuntu)
   Status: Triaged => Won't Fix

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1856045

Title:
  capabilities set with setcap are not honoured

Status in iproute2 package in Ubuntu:
  Won't Fix
Status in iproute2 source package in Eoan:
  Confirmed

Bug description:
  Hi,

  In Ubuntu 19.10 I set capabilities as;

  setcap cap_net_admin,cap_sys_admin+ep /bin/ip
  getcap /bin/ip
  /bin/ip = cap_net_admin,cap_sys_admin+ep

  but;

  > ip addr add 20.20.20.20/32 dev lo
  RTNETLINK answers: Operation not permitted

  *exactly* the same works perfect on 18.04.3 LTS.

  BTW the set of a silly address on "lo" is just an example.
  Nothing works on Ubuntu 19.10

  Regards,

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: libcap2-bin 1:2.25-2
  ProcVersionSignature: Ubuntu 5.3.0-24.26-generic 5.3.10
  Uname: Linux 5.3.0-24-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  Date: Wed Dec 11 15:27:00 2019
  InstallationDate: Installed on 2019-12-09 (2 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: libcap2
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Kernel-packages] [Bug 1856045] Re: capabilities set with setcap are not honoured

[Michael Hudson-Doyle]

Well this is a consequence of this upstream change in iproute2:
https://git.kernel.org/pub/scm/network/iproute2/iproute2.git/commit/?h=v4.16.0=ba2fc55b99f8363c80ce36681bc1ec97690b66f5.
Upstream discussion, such as it is, of the patch appears to be here:
https://lore.kernel.org/netdev/20180327162419.8962-1-bl...@debian.org/

Probably the next step is to email the netdev list about this. Is that
something you would be interested in doing? You are probably better able
to explain your use case than I am!

** Changed in: iproute2 (Ubuntu)
   Status: New => Triaged

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1856045

Title:
  capabilities set with setcap are not honoured

Status in iproute2 package in Ubuntu:
  Triaged
Status in iproute2 source package in Eoan:
  Confirmed

Bug description:
  Hi,

  In Ubuntu 19.10 I set capabilities as;

  setcap cap_net_admin,cap_sys_admin+ep /bin/ip
  getcap /bin/ip
  /bin/ip = cap_net_admin,cap_sys_admin+ep

  but;

  > ip addr add 20.20.20.20/32 dev lo
  RTNETLINK answers: Operation not permitted

  *exactly* the same works perfect on 18.04.3 LTS.

  BTW the set of a silly address on "lo" is just an example.
  Nothing works on Ubuntu 19.10

  Regards,

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: libcap2-bin 1:2.25-2
  ProcVersionSignature: Ubuntu 5.3.0-24.26-generic 5.3.10
  Uname: Linux 5.3.0-24-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  Date: Wed Dec 11 15:27:00 2019
  InstallationDate: Installed on 2019-12-09 (2 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: libcap2
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Kernel-packages] [Bug 1856045] Re: capabilities set with setcap are not honoured

[Michael Hudson-Doyle]

** Package changed: libcap2 (Ubuntu) => iproute2 (Ubuntu)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to iproute2 in Ubuntu.
Matching subscriptions: iproute2
https://bugs.launchpad.net/bugs/1856045

Title:
  capabilities set with setcap are not honoured

Status in iproute2 package in Ubuntu:
  New
Status in iproute2 source package in Eoan:
  Confirmed

Bug description:
  Hi,

  In Ubuntu 19.10 I set capabilities as;

  setcap cap_net_admin,cap_sys_admin+ep /bin/ip
  getcap /bin/ip
  /bin/ip = cap_net_admin,cap_sys_admin+ep

  but;

  > ip addr add 20.20.20.20/32 dev lo
  RTNETLINK answers: Operation not permitted

  *exactly* the same works perfect on 18.04.3 LTS.

  BTW the set of a silly address on "lo" is just an example.
  Nothing works on Ubuntu 19.10

  Regards,

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: libcap2-bin 1:2.25-2
  ProcVersionSignature: Ubuntu 5.3.0-24.26-generic 5.3.10
  Uname: Linux 5.3.0-24-generic x86_64
  ApportVersion: 2.20.11-0ubuntu8.2
  Architecture: amd64
  Date: Wed Dec 11 15:27:00 2019
  InstallationDate: Installed on 2019-12-09 (2 days ago)
  InstallationMedia: Ubuntu 19.10 "Eoan Ermine" - Release amd64 (20191017)
  SourcePackage: libcap2
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

> Ah, no I think this might be along right lines: udev is calling blkid
> on the _partition_ of course, so it can probe for filesystem etc without
> looking at the partition table. After it's done that, it does look for
> the partition table so it can read the ID_PART_ENTRY_* values from it,
> but if it fails to load the partition table it just gives up and still
> returns success.

Ah so this was in the right direction, but not completely right: the
failure is not in reading the partition table of the disk being probed,
but failing to figure out which entry in that table corresponds to the
partition being probed:

Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: 556: libblkid: 
LOWPROBE: trying to convert devno 0x811 to partition
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: 556: libblkid: 
LOWPROBE: searching by offset/size
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: 556: libblkid: 
LOWPROBE: not found partition for device
Feb 06 00:37:42 test-xrdpdnvfctsofyygmzan systemd-udevd[556]: 556: libblkid: 
LOWPROBE: parts: end probing for partition entry [nothing]

The function of interest in libblkid here is
blkid_partlist_devno_to_partition, which (unless some apis have very
misleading names) is reading the offset and size of the partition from
sysfs. What must be happening here is that udev sees the disk being
closed by gdisk and somehow runs the builting blkid command on the
partition before the kernel has been informed of the resize of the
partition. And indeed, we can see when the kernel notices this:

Feb 06 00:37:43 test-xrdpdnvfctsofyygmzan kernel: EXT4-fs (sdb1): resizing 
filesystem from 548091 to 7836155 blocks
Feb 06 00:37:44 test-xrdpdnvfctsofyygmzan kernel: EXT4-fs (sdb1): resized 
filesystem to 7836155

At least a second later. (In passing_journalctl_output.txt, this message
is printed before udev even gets the inotify event about sdb being
closed).

So there's always a race here but I don't know why we only see this on
Azure with newer releases. A proper fix would be to get sgdisk to call
partx_resize_partition before closing the disk but it would also be
interesting to see why it takes so long to get to that part sometimes.
growpart is too much shell for me, but maybe it's possible to get it to
run partx under strace and get the output of that out somehow?

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure 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:
  Incomplete

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 

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

On another tangent, I wonder if the change that brought this to light
was the switch to booting without initrd. The timing is about right, and
fits with the fact that it doesn't occur with the generic kernel (which
cannot boot without initrd in Azure). So if someone has an excess of
time to test , testing bionic but with initrdless boot and focal
with initrdful boot would be interesting. I don't know exactly what
runes have to be cast to do this.

Getting the udevd debug output is still higher priority though.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure 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:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

Hi, could someone prepare an image with
https://paste.ubuntu.com/p/HYGv6m8gCc/ at /etc/systemd/system/systemd-
udevd.service.d/udevd-debugging.conf, boot it on azure until it fails
and put the journalctl output (probably a few megs) somewhere I can read
it? Output from a successful boot would also be interesting.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure 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:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

Oh yeah and one other thing I don't understand: why udev is processing
the partition while sgdisk is still running.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure 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:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

Ah, no I think this might be along right lines: udev is calling blkid on
the _partition_ of course, so it can probe for filesystem etc without
looking at the partition table. After it's done that, it does look for
the partition table so it can read the ID_PART_ENTRY_* values from it,
but if it fails to load the partition table it just gives up and still
returns success.

As to how this might happen, well there are certainly moments during
sgdisk's writing of the partition table when the gpt data is not
completely consistent (it contains checksums and is not written
atomically). Two things are still a bit unsatisfactory about this
explanation though: 1) it's a mighty tight race, hitting this with any
regularity borders on the incredible and 2) I have no idea why this only
occurs on Azure on Cosmic up. Although I guess 1) may explain 2) I
suppose.

Setting LIBBLKID_DEBUG=lowprobe in systemd-udevd's environment during a
failing boot would be very interesting to confirm or deny this line of
reasoning -- although this will make udevd produce gobs of output and
possibly disturb any race.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure 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:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1834875] Re: cloud-init growpart race with udev

[Michael Hudson-Doyle]

So I've been handed the job of moving this bug forward this iteration.

Having just re-read all the comments again and read some source code
while listening to loud techno music my observations/questions are
these:

1) this is a doozy

2) I would really like to see complete udevadm monitor and inotify
output for successful and failing boots

3) As far as I can read the gdisk source, there is no point when there
no entry for the partition on disk (i.e. it only writes the partition
tables once)

4) I think this comment "I believe the kernel event is emitted before
the partition table has necessarily been fully updated so when udev
processes the event and reads the partition table, sometimes it finds
the partition and sometimes it doesn't." is not quite right, or at least
there is another possibility entirely consistent with the observed
facts: the diff in comment #24 looks more like udev finds the partition
OK but fails to fill out the ID_PART_ENTRY_* entries. These come from
libblkid via udev-builtin-blkid.c. The part about this theory that
doesn't make sense is that the ID_FS_* entries are there and they come
from the same codepath. So who knows!

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux-azure 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:
  Incomplete

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/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help   : https://help.launchpad.net/ListHelp

[Kernel-packages] [Bug 1845044] Re: [Kernel 5.3.0-10] Kernel panic - not syncing: Attempting to kill init! exitcode=0x00000009

[Michael Hudson-Doyle]

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

** This bug is no longer a duplicate of bug 1844101
   5.3.0-10 crashes immediately in init_tis -> ... -> tpm_init -> ... -> 
tpm_tis_core_init.cold -> ... (never boots)
** This bug has been marked a duplicate of bug 1845454
   Kernel panic with 19.10 beta image

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1845044

Title:
  [Kernel 5.3.0-10] Kernel panic - not syncing: Attempting to kill init!
  exitcode=0x0009

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Hi,

  I upgraded to Ubuntu 19.10 Eoan Ermine (development branch). This included a 
kernel update to 5.3.0-10. With this kernel ubuntu does not boot any more. 
Fortunately it boots with the old kernel 5.0.0-29. In the attachment there is a 
picture of the failing boot process. I also tried the newer kernel 5.3.0-12 
with which I have the same problem.
  How can I provide additional information?

  Regards,
  Matthias

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

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

[Kernel-packages] [Bug 1844101] Re: 5.3.0-10 crashes immediately in init_tis -> ... -> tpm_init -> ... -> tpm_tis_core_init.cold -> ... (never boots)

[Michael Hudson-Doyle]

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

Bug 1845454 was filed later but has more useful comments, so I'm going
to mark this a duplicate of that.

** This bug has been marked a duplicate of bug 1845454
   Kernel panic with 19.10 beta image

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1844101

Title:
  5.3.0-10 crashes immediately in init_tis -> ... -> tpm_init -> ... ->
  tpm_tis_core_init.cold -> ... (never boots)

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  After the update to 5.3-10, my T480s now crashes in  TPM init. At
  least the kernel executes, unlike in bug 1843860.

  I don't have a full backtrace, as the kernel crashes and I can only take a 
screenshot at the end of the crash message.
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  jak4993 F pulseaudio
  CurrentDesktop: GNOME
  DistroRelease: Ubuntu 19.10
  HibernationDevice: RESUME=none
  InstallationDate: Installed on 2018-03-14 (550 days ago)
  InstallationMedia: Ubuntu 18.04 LTS "Bionic Beaver" - Alpha amd64 (20180313)
  MachineType: LENOVO 20L8S02D00
  Package: linux (not installed)
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-5.2.0-15-generic 
root=/dev/mapper/ubuntu--vg-root ro rootflags=subvol=@
  ProcVersionSignature: Ubuntu 5.2.0-15.16-generic 5.2.9
  RelatedPackageVersions:
   linux-restricted-modules-5.2.0-15-generic N/A
   linux-backports-modules-5.2.0-15-generic  N/A
   linux-firmware1.182
  Tags:  eoan
  Uname: Linux 5.2.0-15-generic x86_64
  UpgradeStatus: Upgraded to eoan on 2018-11-20 (299 days ago)
  UserGroups: adm cdrom dip fax input kvm lpadmin lxd plugdev sambashare sbuild 
sudo
  _MarkForUpload: True
  dmi.bios.date: 07/18/2019
  dmi.bios.vendor: LENOVO
  dmi.bios.version: N22ET56W (1.33 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 20L8S02D00
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Defined
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: None
  dmi.modalias: 
dmi:bvnLENOVO:bvrN22ET56W(1.33):bd07/18/2019:svnLENOVO:pn20L8S02D00:pvrThinkPadT480s:rvnLENOVO:rn20L8S02D00:rvrNotDefined:cvnLENOVO:ct10:cvrNone:
  dmi.product.family: ThinkPad T480s
  dmi.product.name: 20L8S02D00
  dmi.product.sku: LENOVO_MT_20L8_BU_Think_FM_ThinkPad T480s
  dmi.product.version: ThinkPad T480s
  dmi.sys.vendor: LENOVO

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

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

[Kernel-packages] [Bug 1843860] Re: 5.3.0-10 doesn't boot on my t480s with secure boot enabled

[Michael Hudson-Doyle]

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

** This bug is no longer a duplicate of bug 1844101
   5.3.0-10 crashes immediately in init_tis -> ... -> tpm_init -> ... -> 
tpm_tis_core_init.cold -> ... (never boots)
** This bug has been marked a duplicate of bug 1845454
   Kernel panic with 19.10 beta image

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1843860

Title:
  5.3.0-10 doesn't boot on my t480s with secure boot enabled

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have no further information, sadly. The boot stops at the message
  "EFI stub: UEFI Secure Boot is enabled". Disabling secure boot or
  selecting an older kernel both work fine.

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

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

[Kernel-packages] [Bug 1845454] Re: Kernel panic with 19.10 beta image

[Michael Hudson-Doyle]

This is the same bug as bug 1844101 I think? If it is, it doesn't
reproduce with secure boot off and we'll need a signed kernel to test.
I'm happy to enrol whatever key in my firmware to test a self-signed
kernel...

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1845454

Title:
  Kernel panic with 19.10 beta image

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Image: http://cdimage.ubuntu.com/daily-live/20190926/eoan-desktop-amd64.iso
  Device: Dell XPS 13 7390 (201908-27305)

  When trying to start the live session ("try Ubuntu") or trying to
  install the ISO ("install Ubuntu"), the boot process stops within 1
  second with a kernel panic (see attached screenshot).

  The system could boot with a previous version of Eoan image:
  2019-09-09 09:11 (kernel 5.3.0-10)

  Workaround: disable TPM2 in the BIOS.

  /!\ Please note: the information below (and the attached file  
ProcCpuinfoMinimal.txt) come from a 18.04 live session, since I cannot boot 
anything with 19.10 beta image.
  ==
  ProblemType: Bug
  DistroRelease: Ubuntu 18.04
  Package: syslinux 3:6.03+dfsg1-2
  ProcVersionSignature: Ubuntu 5.0.0-23.24~18.04.1-generic 5.0.15
  Uname: Linux 5.0.0-23-generic x86_64
  ApportVersion: 2.20.9-0ubuntu7.7
  Architecture: amd64
  CasperVersion: 1.394
  CurrentDesktop: ubuntu:GNOME
  Date: Thu Sep 26 07:41:16 2019
  Dependencies:
   gcc-8-base 8.3.0-6ubuntu1~18.04.1
   libc6 2.27-3ubuntu1
   libgcc1 1:8.3.0-6ubuntu1~18.04.1
   mtools 4.0.18-2ubuntu1
   syslinux-common 3:6.03+dfsg1-2
  LiveMediaBuild: Ubuntu 18.04.3 LTS "Bionic Beaver" - Release amd64 (20190805)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: syslinux
  UpgradeStatus: No upgrade log present (probably fresh install)

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

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

[Kernel-packages] [Bug 1843860] Re: 5.3.0-10 doesn't boot on my t480s with secure boot enabled

[Michael Hudson-Doyle]

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

Yes, I assume it's the same bug. Julian and I were actually sitting next
to each other yesterday trying to diagnose things. As the other bug has
logs, let's mark this a duplicate of the other.

** This bug has been marked a duplicate of bug 1844101
   5.3.0-10 crashes immediately in init_tis -> ... -> tpm_init -> ... -> 
tpm_tis_core_init.cold -> ... (never boots)

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1843860

Title:
  5.3.0-10 doesn't boot on my t480s with secure boot enabled

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have no further information, sadly. The boot stops at the message
  "EFI stub: UEFI Secure Boot is enabled". Disabling secure boot or
  selecting an older kernel both work fine.

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

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

[Kernel-packages] [Bug 1843860] Re: 5.3.0-10 doesn't boot on my t480s with secure boot enabled

[Michael Hudson-Doyle]

Update: disabling TPM is enough to allow boot.

>From dmidecode:

Handle 0x000C, DMI type 1, 27 bytes
System Information
Manufacturer: LENOVO
Product Name: 20L8S7X100
Version: ThinkPad T480s
Serial Number: xxx
UUID: xxx
Wake-up Type: Power Switch
SKU Number: LENOVO_MT_20L8_BU_Think_FM_ThinkPad T480s
Family: ThinkPad T480s

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1843860

Title:
  5.3.0-10 doesn't boot on my t480s with secure boot enabled

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have no further information, sadly. The boot stops at the message
  "EFI stub: UEFI Secure Boot is enabled". Disabling secure boot or
  selecting an older kernel both work fine.

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

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

[Kernel-packages] [Bug 1843860] Re: 5.3.0-10 doesn't boot on my t480s with secure boot enabled

[Michael Hudson-Doyle]

mwhudson@anduril:~$ apport-collect 1843860
dpkg-query: no packages found matching linux


** Changed in: linux (Ubuntu)
   Status: Incomplete => Confirmed

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1843860

Title:
  5.3.0-10 doesn't boot on my t480s with secure boot enabled

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  I have no further information, sadly. The boot stops at the message
  "EFI stub: UEFI Secure Boot is enabled". Disabling secure boot or
  selecting an older kernel both work fine.

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

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

[Kernel-packages] [Bug 1843860] [NEW] 5.3.0-10 doesn't boot on my t480s with secure boot enabled

[Michael Hudson-Doyle]

Public bug reported:

I have no further information, sadly. The boot stops at the message "EFI
stub: UEFI Secure Boot is enabled". Disabling secure boot or selecting
an older kernel both work fine.

** Affects: linux (Ubuntu)
 Importance: Undecided
 Status: Incomplete

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1843860

Title:
  5.3.0-10 doesn't boot on my t480s with secure boot enabled

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  I have no further information, sadly. The boot stops at the message
  "EFI stub: UEFI Secure Boot is enabled". Disabling secure boot or
  selecting an older kernel both work fine.

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

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

[Kernel-packages] [Bug 1840122] Re: System fails to reboot from live session or ubiquity-dm - squashfs_read_data failed to read block

[Michael Hudson-Doyle]

I had a look at this and got pretty confused! Feels more like a kernel
problem than a casper one, somehow.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1840122

Title:
  System fails to reboot from live session or ubiquity-dm -
  squashfs_read_data failed to read block

Status in casper package in Ubuntu:
  Confirmed
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Last known good image: Eoan Ubuntu Desktop 20190715

  Test Case:
  1. Boot eoan desktop to a live session
  2. Wait a couple of minutes until snapd settles
  3. Reboot the system from the system menu or from the command line

  Expected result:
  The system reboots

  Actual result:
  The systems fails to reboot or shutdown and displays some errors about 
failing to unmount /cdrom and squashfs errors in a loop.

  Unmounting /cdrom...
  [FAILED] Failed unmounting /cdrom.
  [  OK  ] Started Shuts down the "li…" preinstalled system cleanly.
  [  OK  ] Reached target Final Step.
  [  OK  ] Started Reboot.
  [  OK  ] Reached target Reboot.
  [  115.744188] print_req_error: I/O error, dev sr0, sector 1508872 flags 80700
  [  115.768139] print_req_error: I/O error, dev sr0, sector 1508872 flags 0
  [  115.771469] print_req_error: I/O error, dev loop0, sector 1501550 flags 0
  [  115.775824] SQUASHFS error: squashfs_read_data failed to read block 
0x2dd2d998

  This also causes daily tests to fail.

  ProblemType: Bug
  DistroRelease: Ubuntu 19.10
  Package: casper 1.414
  ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4
  Uname: Linux 5.2.0-10-generic x86_64
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CasperVersion: 1.414
  CurrentDesktop: ubuntu:GNOME
  Date: Wed Aug 14 08:31:30 2019
  LiveMediaBuild: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190813)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  SourcePackage: casper
  UpgradeStatus: No upgrade log present (probably fresh install)
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  CasperVersion: 1.414
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 19.10
  LiveMediaBuild: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190814)
  Package: linux
  PackageArchitecture: amd64
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4
  Tags:  eoan
  Uname: Linux 5.2.0-10-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu 1788 F pulseaudio
  CasperVersion: 1.414
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 19.10
  IwConfig:
   lono wireless extensions.
   
   ens3  no wireless extensions.
  LiveMediaBuild: Ubuntu 19.10 "Eoan Ermine" - Alpha amd64 (20190814)
  Lsusb:
   Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU USB Tablet
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
   Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
   Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
  MachineType: QEMU Standard PC (i440FX + PIIX, 1996)
  Package: linux (not installed)
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 qxldrmfb
  ProcKernelCmdLine: file=/cdrom/preseed/username.seed initrd=/casper/initrd 
---  keyboard-configuration/layoutcode=fr keyboard-configuration/variantcode=oss
  ProcVersionSignature: Ubuntu 5.2.0-10.11-generic 5.2.4
  RelatedPackageVersions:
   linux-restricted-modules-5.2.0-10-generic N/A
   linux-backports-modules-5.2.0-10-generic  N/A
   linux-firmware1.181
  RfKill:
   
  Tags:  eoan
  Uname: Linux 5.2.0-10-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 04/01/2014
  dmi.bios.vendor: SeaBIOS
  dmi.bios.version: 1.12.0-1
  dmi.chassis.type: 1
  dmi.chassis.vendor: QEMU
  dmi.chassis.version: pc-i440fx-disco
  dmi.modalias: 
dmi:bvnSeaBIOS:bvr1.12.0-1:bd04/01/2014:svnQEMU:pnStandardPC(i440FX+PIIX,1996):pvrpc-i440fx-disco:cvnQEMU:ct1:cvrpc-i440fx-disco:
  dmi.product.name: Standard PC (i440FX + PIIX, 1996)
  dmi.product.version: pc-i440fx-disco
  dmi.sys.vendor: QEMU
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu7
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  ubuntu 1788 F 

[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[Michael Hudson-Doyle]

I've verified the fix in the way I suspected I'd have to, with one extra
wrinkle.

1) In a trusty VM, I verified that the C test case from the gist failed. (It 
did).
2) I launched a xenial lxd container on the VM and built the Go test case with 
version 1.6.2-0ubuntu5~16.04.2 of golang-1.6-go.
3) It did not fail in the lxd container for reasons I couldn't understand but 
it did fail when copied out of the container on to the trusty VM (failed 563 
times out of 100k)
4) I then installed golang-1.6-go version 1.6.2-0ubuntu5~16.04.3 in the 
container and rebuilt the Go test case with the new compiler.
5) This did not fail when run directly on the trusty VM (0 failures out of 100k 
runs)

So I'm confident the fix has helped.

** Tags removed: verification-needed verification-needed-xenial
** Tags added: verification-done-xenial

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1672819

Title:
  exec'ing a setuid binary from a threaded program sometimes fails to
  setuid

Status in Linux:
  Unknown
Status in golang-1.6 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in golang-1.6 source package in Xenial:
  Fix Committed
Status in linux source package in Xenial:
  Fix Released
Status in golang-1.6 source package in Yakkety:
  Invalid
Status in linux source package in Yakkety:
  Fix Released
Status in golang-1.6 source package in Zesty:
  Invalid
Status in linux source package in Zesty:
  Fix Released

Bug description:
  == SRU template for golang-1.6 ==

  [Impact]
  The kernel bug reported below means that occasionally (maybe 1 in 1000 times) 
the snapd -> snap-confine exec that is part of a snap execution fails to take 
the setuid bit on the snap-confine binary into account which means that the 
execution fails. This is extremely confusing for the user of the snap who just 
sees a permission denied error with no explanation.

  The kernel bug has been fixed in Xenial+ but not all users of snapd are on 
xenial+ kernels (they might be on trusty or another distribution entirely).
  Backporting this fix will mean that the snapd in the core snap will get the 
workaround next time it is built and because the snapd in trusty or the other 
distro will re-exec into the snapd in the core snap before execing 
snap-confine, users should not see the above behaviour.

  [Test case]
  This will be a bit tricky as the kernel bug has been fixed. A xenial 
container on a trusty host/VM should do the trick. The test case from 
https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be 
sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded 
from proposed, the fix.

  [Regression potential]
  If there is a bug in the patch it could cause deadlocks in currently working 
programs. But the patch is pretty simple and has passed review upstream so I 
think it should be OK.

  == SRU REQUEST XENIAL, YAKKETY, ZESTY ==

  Due to two race conditions in check_unsafe_exec(),  exec'ing a setuid
  binary from a threaded program sometimes fails to setuid.

  == Fix ==

  Sauce patch for Xenial, Yakkety + Zesty:

  https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html

  This fix re-executes the unsafe check if there is a discrepancy
  between the expected fs count and the found count during the racy
  window during thread exec or exit.  This re-check occurs very
  infrequently and saves a lot of addition locking on per thread
  structures that would make performance of fork/exec/exit prohibitively
  expensive.

  == Test case ==

  See the example C code in the patch, https://lists.ubuntu.com/archives
  /kernel-team/2017-May/084102.html

  Run the test code as follows: for i in $(seq 1000); do ./a; done

  With the patch, no messages are emitted, without the patch, one sees a
  message:

  "Failed, got euid 1000 (expecting 0)"

  ..which shows the setuid program failed the check_unsafe_exec()
  because of the race.

  == Regression potential ==

  breaking existing safe exec semantics.

  

  This can be reproduced with
  https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813

  With that, and go 1.8, if you run “make” and then

  for i in `seq 99`; do ./a_go; done

  you'll see a variable number of ”GOT 1000” (or whatever your user id
  is). If you don't, add one or two more 9s on there.

  That's a simple go reproducer. You can also use “a_p” instead of
  “a_go” to see one that only uses pthreads. “a_c” is a C version that
  does *not* reproduce the issue.

  But it's not pthreads: if in a_go.go you comment out the “import "C"”,
  you'll still see the “GOT 1000” messages, in a static binary that uses
  no pthreads, just clone(2). You'll also see a bunch of warnings
  because it's not properly handling an EAGAIN from clone, but that's
  unrelated.

  If you pin the process to a single thread using taskset, you don't 

[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[Michael Hudson-Doyle]

** Changed in: golang-1.6 (Ubuntu Xenial)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1672819

Title:
  exec'ing a setuid binary from a threaded program sometimes fails to
  setuid

Status in Linux:
  Unknown
Status in golang-1.6 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in golang-1.6 source package in Xenial:
  In Progress
Status in linux source package in Xenial:
  Fix Released
Status in golang-1.6 source package in Yakkety:
  Invalid
Status in linux source package in Yakkety:
  Fix Released
Status in golang-1.6 source package in Zesty:
  Invalid
Status in linux source package in Zesty:
  Fix Released

Bug description:
  == SRU template for golang-1.6 ==

  [Impact]
  The kernel bug reported below means that occasionally (maybe 1 in 1000 times) 
the snapd -> snap-confine exec that is part of a snap execution fails to take 
the setuid bit on the snap-confine binary into account which means that the 
execution fails. This is extremely confusing for the user of the snap who just 
sees a permission denied error with no explanation.

  The kernel bug has been fixed in Xenial+ but not all users of snapd are on 
xenial+ kernels (they might be on trusty or another distribution entirely).
  Backporting this fix will mean that the snapd in the core snap will get the 
workaround next time it is built and because the snapd in trusty or the other 
distro will re-exec into the snapd in the core snap before execing 
snap-confine, users should not see the above behaviour.

  [Test case]
  This will be a bit tricky as the kernel bug has been fixed. A xenial 
container on a trusty host/VM should do the trick. The test case from 
https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be 
sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded 
from proposed, the fix.

  [Regression potential]
  If there is a bug in the patch it could cause deadlocks in currently working 
programs. But the patch is pretty simple and has passed review upstream so I 
think it should be OK.

  == SRU REQUEST XENIAL, YAKKETY, ZESTY ==

  Due to two race conditions in check_unsafe_exec(),  exec'ing a setuid
  binary from a threaded program sometimes fails to setuid.

  == Fix ==

  Sauce patch for Xenial, Yakkety + Zesty:

  https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html

  This fix re-executes the unsafe check if there is a discrepancy
  between the expected fs count and the found count during the racy
  window during thread exec or exit.  This re-check occurs very
  infrequently and saves a lot of addition locking on per thread
  structures that would make performance of fork/exec/exit prohibitively
  expensive.

  == Test case ==

  See the example C code in the patch, https://lists.ubuntu.com/archives
  /kernel-team/2017-May/084102.html

  Run the test code as follows: for i in $(seq 1000); do ./a; done

  With the patch, no messages are emitted, without the patch, one sees a
  message:

  "Failed, got euid 1000 (expecting 0)"

  ..which shows the setuid program failed the check_unsafe_exec()
  because of the race.

  == Regression potential ==

  breaking existing safe exec semantics.

  

  This can be reproduced with
  https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813

  With that, and go 1.8, if you run “make” and then

  for i in `seq 99`; do ./a_go; done

  you'll see a variable number of ”GOT 1000” (or whatever your user id
  is). If you don't, add one or two more 9s on there.

  That's a simple go reproducer. You can also use “a_p” instead of
  “a_go” to see one that only uses pthreads. “a_c” is a C version that
  does *not* reproduce the issue.

  But it's not pthreads: if in a_go.go you comment out the “import "C"”,
  you'll still see the “GOT 1000” messages, in a static binary that uses
  no pthreads, just clone(2). You'll also see a bunch of warnings
  because it's not properly handling an EAGAIN from clone, but that's
  unrelated.

  If you pin the process to a single thread using taskset, you don't get
  the issue from a_go; a_p continues to reproduce the issue. In some
  virtualized environments we haven't been able to reproduce the issue
  either (e.g. some aws instances), but kvm works (you need -smp to see
  the issue from a_go).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-64-generic 4.4.0-64.85
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   john   2354 F...m pulseaudio
   /dev/snd/controlC0:  john   2354 F pulseaudio
  CurrentDesktop: Unity
  Date: Tue Mar 

[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[Michael Hudson-Doyle]

** Description changed:

+ == SRU template for golang-1.6 ==
+ 
+ [Impact]
+ The kernel bug reported below means that occasionally (maybe 1 in 1000 times) 
the snapd -> snap-confine exec that is part of a snap execution fails to take 
the setuid bit on the snap-confine binary into account which means that the 
execution fails. This is extremely confusing for the user of the snap who just 
sees a permission denied error with no explanation.
+ 
+ The kernel bug has been fixed in Xenial+ but not all users of snapd are on 
xenial+ kernels (they might be on trusty or another distribution entirely).
+ Backporting this fix will mean that the snapd in the core snap will get the 
workaround next time it is built and because the snapd in trusty or the other 
distro will re-exec into the snapd in the core snap before execing 
snap-confine, users should not see the above behaviour.
+ 
+ [Test case]
+ This will be a bit tricky as the kernel bug has been fixed. A xenial 
container on a trusty host/VM should do the trick. The test case from 
https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813 should be 
sufficient to demonstrate the bug and then, once golang-1.6 has been upgraded 
from proposed, the fix.
+ 
+ [Regression potential]
+ If there is a bug in the patch it could cause deadlocks in currently working 
programs. But the patch is pretty simple and has passed review upstream so I 
think it should be OK.
+ 
  == SRU REQUEST XENIAL, YAKKETY, ZESTY ==
  
  Due to two race conditions in check_unsafe_exec(),  exec'ing a setuid
  binary from a threaded program sometimes fails to setuid.
  
  == Fix ==
  
  Sauce patch for Xenial, Yakkety + Zesty:
  
  https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html
  
  This fix re-executes the unsafe check if there is a discrepancy between
  the expected fs count and the found count during the racy window during
  thread exec or exit.  This re-check occurs very infrequently and saves a
  lot of addition locking on per thread structures that would make
  performance of fork/exec/exit prohibitively expensive.
  
  == Test case ==
  
  See the example C code in the patch, https://lists.ubuntu.com/archives
  /kernel-team/2017-May/084102.html
  
  Run the test code as follows: for i in $(seq 1000); do ./a; done
  
  With the patch, no messages are emitted, without the patch, one sees a
  message:
  
  "Failed, got euid 1000 (expecting 0)"
  
  ..which shows the setuid program failed the check_unsafe_exec() because
  of the race.
  
  == Regression potential ==
  
  breaking existing safe exec semantics.
  
  
  
  This can be reproduced with
  https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813
  
  With that, and go 1.8, if you run “make” and then
  
  for i in `seq 99`; do ./a_go; done
  
  you'll see a variable number of ”GOT 1000” (or whatever your user id
  is). If you don't, add one or two more 9s on there.
  
  That's a simple go reproducer. You can also use “a_p” instead of “a_go”
  to see one that only uses pthreads. “a_c” is a C version that does *not*
  reproduce the issue.
  
  But it's not pthreads: if in a_go.go you comment out the “import "C"”,
  you'll still see the “GOT 1000” messages, in a static binary that uses
  no pthreads, just clone(2). You'll also see a bunch of warnings because
  it's not properly handling an EAGAIN from clone, but that's unrelated.
  
  If you pin the process to a single thread using taskset, you don't get
  the issue from a_go; a_p continues to reproduce the issue. In some
  virtualized environments we haven't been able to reproduce the issue
  either (e.g. some aws instances), but kvm works (you need -smp to see
  the issue from a_go).
  
  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-64-generic 4.4.0-64.85
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   john   2354 F...m pulseaudio
   /dev/snd/controlC0:  john   2354 F pulseaudio
  CurrentDesktop: Unity
  Date: Tue Mar 14 17:17:23 2017
  HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf
  InstallationDate: Installed on 2014-04-27 (1051 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  MachineType: Dell Inc. Latitude E6510
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 
mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-64-generic N/A
   linux-backports-modules-4.4.0-64-generic  N/A
   linux-firmware1.157.8
  SourcePackage: linux
  SystemImageInfo: Error: command ['system-image-cli', '-i'] failed 

[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[Michael Hudson-Doyle]

** Also affects: golang-1.6 (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: golang-1.6 (Ubuntu)
   Status: New => Invalid

** Changed in: golang-1.6 (Ubuntu Yakkety)
   Status: New => Invalid

** Changed in: golang-1.6 (Ubuntu Zesty)
   Status: New => Invalid

** Changed in: golang-1.6 (Ubuntu Xenial)
 Assignee: (unassigned) => Michael Hudson-Doyle (mwhudson)

** Changed in: golang-1.6 (Ubuntu Xenial)
   Importance: Undecided => High

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1672819

Title:
  exec'ing a setuid binary from a threaded program sometimes fails to
  setuid

Status in Linux:
  Unknown
Status in golang-1.6 package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in golang-1.6 source package in Xenial:
  New
Status in linux source package in Xenial:
  Fix Released
Status in golang-1.6 source package in Yakkety:
  Invalid
Status in linux source package in Yakkety:
  Fix Released
Status in golang-1.6 source package in Zesty:
  Invalid
Status in linux source package in Zesty:
  Fix Released

Bug description:
  == SRU REQUEST XENIAL, YAKKETY, ZESTY ==

  Due to two race conditions in check_unsafe_exec(),  exec'ing a setuid
  binary from a threaded program sometimes fails to setuid.

  == Fix ==

  Sauce patch for Xenial, Yakkety + Zesty:

  https://lists.ubuntu.com/archives/kernel-team/2017-May/084102.html

  This fix re-executes the unsafe check if there is a discrepancy
  between the expected fs count and the found count during the racy
  window during thread exec or exit.  This re-check occurs very
  infrequently and saves a lot of addition locking on per thread
  structures that would make performance of fork/exec/exit prohibitively
  expensive.

  == Test case ==

  See the example C code in the patch, https://lists.ubuntu.com/archives
  /kernel-team/2017-May/084102.html

  Run the test code as follows: for i in $(seq 1000); do ./a; done

  With the patch, no messages are emitted, without the patch, one sees a
  message:

  "Failed, got euid 1000 (expecting 0)"

  ..which shows the setuid program failed the check_unsafe_exec()
  because of the race.

  == Regression potential ==

  breaking existing safe exec semantics.

  

  This can be reproduced with
  https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813

  With that, and go 1.8, if you run “make” and then

  for i in `seq 99`; do ./a_go; done

  you'll see a variable number of ”GOT 1000” (or whatever your user id
  is). If you don't, add one or two more 9s on there.

  That's a simple go reproducer. You can also use “a_p” instead of
  “a_go” to see one that only uses pthreads. “a_c” is a C version that
  does *not* reproduce the issue.

  But it's not pthreads: if in a_go.go you comment out the “import "C"”,
  you'll still see the “GOT 1000” messages, in a static binary that uses
  no pthreads, just clone(2). You'll also see a bunch of warnings
  because it's not properly handling an EAGAIN from clone, but that's
  unrelated.

  If you pin the process to a single thread using taskset, you don't get
  the issue from a_go; a_p continues to reproduce the issue. In some
  virtualized environments we haven't been able to reproduce the issue
  either (e.g. some aws instances), but kvm works (you need -smp to see
  the issue from a_go).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-64-generic 4.4.0-64.85
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   john   2354 F...m pulseaudio
   /dev/snd/controlC0:  john   2354 F pulseaudio
  CurrentDesktop: Unity
  Date: Tue Mar 14 17:17:23 2017
  HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf
  InstallationDate: Installed on 2014-04-27 (1051 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  MachineType: Dell Inc. Latitude E6510
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 
mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-64-generic N/A
   linux-backports-modules-4.4.0-64-generic  N/A
   linux-firmware1.157.8
  SourcePackage: linux
  SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit 
code 2:
  UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago)
  dmi.bios.date: 12/05/2013
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A16
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 9
 

Re: [Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[Michael Hudson-Doyle]

On 8 May 2017 at 10:32, Colin Ian King <1672...@bugs.launchpad.net>
wrote:

> exec'ing from a thread is an interesting problem; the semantics of exec
> should be to terminal all the threads before the exec occurs according
> to http://maxim.int.ru/bookshelf/PthreadsProgram/htm/r_44.html
>
> The normal idiom would be to do:
>   fork()
>   child exec's
>   parent waits for child
>
> I'm not sure in your case if you desire all the threads to terminate
> after the exec, so the wait() may be in fact be replaced by pthread
> termination calls on all the threads for your implementation.
>

The original bug report was about a process calling execve directly, not a
fork/exec situation. So yes, the expectation is that all threads are gone.


> Unfortunately there is an issue with fork'ing in a thread; any mutex
> held by another thread at the moment of fork becomes locked forever
> since we have once mutex locked by the parent and one by the child.
> Normally one would therefore use pthread_atfork() to help workaround
> this issue, see https://stackoverflow.com/questions/14407544/mixing-
> threads-fork-and-mutexes-what-should-i-watch-out-for


Go doesn't support forking (except for some very careful code that calls
exec in the child), for exactly this sort of reason.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1672819

Title:
  exec'ing a setuid binary from a threaded program sometimes fails to
  setuid

Status in Linux:
  Unknown
Status in linux package in Ubuntu:
  Triaged
Status in linux source package in Xenial:
  In Progress

Bug description:
  This can be reproduced with
  https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813

  With that, and go 1.8, if you run “make” and then

  for i in `seq 99`; do ./a_go; done

  you'll see a variable number of ”GOT 1000” (or whatever your user id
  is). If you don't, add one or two more 9s on there.

  That's a simple go reproducer. You can also use “a_p” instead of
  “a_go” to see one that only uses pthreads. “a_c” is a C version that
  does *not* reproduce the issue.

  But it's not pthreads: if in a_go.go you comment out the “import "C"”,
  you'll still see the “GOT 1000” messages, in a static binary that uses
  no pthreads, just clone(2). You'll also see a bunch of warnings
  because it's not properly handling an EAGAIN from clone, but that's
  unrelated.

  If you pin the process to a single thread using taskset, you don't get
  the issue from a_go; a_p continues to reproduce the issue. In some
  virtualized environments we haven't been able to reproduce the issue
  either (e.g. some aws instances), but kvm works (you need -smp to see
  the issue from a_go).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-64-generic 4.4.0-64.85
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   john   2354 F...m pulseaudio
   /dev/snd/controlC0:  john   2354 F pulseaudio
  CurrentDesktop: Unity
  Date: Tue Mar 14 17:17:23 2017
  HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf
  InstallationDate: Installed on 2014-04-27 (1051 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  MachineType: Dell Inc. Latitude E6510
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 
mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-64-generic N/A
   linux-backports-modules-4.4.0-64-generic  N/A
   linux-firmware1.157.8
  SourcePackage: linux
  SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit 
code 2:
  UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago)
  dmi.bios.date: 12/05/2013
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A16
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr:
  dmi.product.name: Latitude E6510
  dmi.product.version: 0001
  dmi.sys.vendor: Dell Inc.

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

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

[Kernel-packages] [Bug 1672819] Re: exec'ing a setuid binary from a threaded program sometimes fails to setuid

[Michael Hudson-Doyle]

I had a bit of a stare at the kernel source and suspected that the
downgrade of uid is happening here:
https://github.com/torvalds/linux/blob/v4.4/security/commoncap.c#L547-L548

I added a "WARN(1, "downgrading in subprocess %d %d\n", bprm->unsafe,
(int)capable(CAP_SETUID))" which revealed that bprm->unsafe is 1 aka
LSM_UNSAFE_SHARE.

The only place (I can find) that bprm->unsafe is set to LSM_UNSAFE_SHARE
is this check  in check_unsafe_exec here (from
https://github.com/torvalds/linux/blob/v4.4/fs/exec.c#L1281):

t = p;
n_fs = 1;
spin_lock(>fs->lock);
rcu_read_lock();
while_each_thread(p, t) {
if (t->fs == p->fs)
n_fs++;
}
rcu_read_unlock();

if (p->fs->users > n_fs)
bprm->unsafe |= LSM_UNSAFE_SHARE;
else
p->fs->in_exec = 1;
spin_unlock(>fs->lock);

So I think (and here it gets a bit sketchy) we're racing with
copy_process in kernel/fork.c: that calls copy_fs (which is what
increments p->fs->users) some way before it does the stuff necessary to
make the new thread be included in the while_each_thread(p, t) loop. So
n_fs is too low, the check triggers and the setuid bits get ignored.

No idea at all how to fix this of course.

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1672819

Title:
  exec'ing a setuid binary from a threaded program sometimes fails to
  setuid

Status in linux package in Ubuntu:
  Triaged
Status in linux source package in Xenial:
  Triaged

Bug description:
  This can be reproduced with
  https://gist.github.com/chipaca/806c90d96c437444f27f45a83d00a813

  With that, and go 1.8, if you run “make” and then

  for i in `seq 99`; do ./a_go; done

  you'll see a variable number of ”GOT 1000” (or whatever your user id
  is). If you don't, add one or two more 9s on there.

  That's a simple go reproducer. You can also use “a_p” instead of
  “a_go” to see one that only uses pthreads. “a_c” is a C version that
  does *not* reproduce the issue.

  But it's not pthreads: if in a_go.go you comment out the “import "C"”,
  you'll still see the “GOT 1000” messages, in a static binary that uses
  no pthreads, just clone(2). You'll also see a bunch of warnings
  because it's not properly handling an EAGAIN from clone, but that's
  unrelated.

  If you pin the process to a single thread using taskset, you don't get
  the issue from a_go; a_p continues to reproduce the issue. In some
  virtualized environments we haven't been able to reproduce the issue
  either (e.g. some aws instances), but kvm works (you need -smp to see
  the issue from a_go).

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: linux-image-4.4.0-64-generic 4.4.0-64.85
  ProcVersionSignature: Ubuntu 4.4.0-64.85-generic 4.4.44
  Uname: Linux 4.4.0-64-generic x86_64
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/pcmC0D0p:   john   2354 F...m pulseaudio
   /dev/snd/controlC0:  john   2354 F pulseaudio
  CurrentDesktop: Unity
  Date: Tue Mar 14 17:17:23 2017
  HibernationDevice: RESUME=UUID=b9fd155b-dcbe-4337-ae77-6daa6569beaf
  InstallationDate: Installed on 2014-04-27 (1051 days ago)
  InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140417)
  MachineType: Dell Inc. Latitude E6510
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/vmlinuz-4.4.0-64-generic 
root=/dev/mapper/ubuntu--vg-root ro enable_mtrr_cleanup mtrr_spare_reg_nr=8 
mtrr_gran_size=32M mtrr_chunk_size=32M quiet splash
  RelatedPackageVersions:
   linux-restricted-modules-4.4.0-64-generic N/A
   linux-backports-modules-4.4.0-64-generic  N/A
   linux-firmware1.157.8
  SourcePackage: linux
  SystemImageInfo: Error: command ['system-image-cli', '-i'] failed with exit 
code 2:
  UpgradeStatus: Upgraded to xenial on 2015-06-18 (634 days ago)
  dmi.bios.date: 12/05/2013
  dmi.bios.vendor: Dell Inc.
  dmi.bios.version: A16
  dmi.board.vendor: Dell Inc.
  dmi.chassis.type: 9
  dmi.chassis.vendor: Dell Inc.
  dmi.modalias: 
dmi:bvnDellInc.:bvrA16:bd12/05/2013:svnDellInc.:pnLatitudeE6510:pvr0001:rvnDellInc.:rn:rvr:cvnDellInc.:ct9:cvr:
  dmi.product.name: Latitude E6510
  dmi.product.version: 0001
  dmi.sys.vendor: Dell Inc.

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

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

[Kernel-packages] [Bug 1584456] Re: apparmor denial using ptmx char device

[Michael Hudson-Doyle]

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

** Also affects: snap-confine (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** No longer affects: linux (Ubuntu Xenial)

** Changed in: snap-confine (Ubuntu Xenial)
   Status: New => In Progress

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1584456

Title:
  apparmor denial using ptmx char device

Status in Snappy Launcher:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in snap-confine package in Ubuntu:
  Fix Released
Status in snap-confine source package in Xenial:
  In Progress

Bug description:
  [Impact]

  snap-confine would refuse to work on an older kernel running on an
  Nvidia Tegra X1 board. This was traced to a bug in older version of
  apparmor there that required directory-like syntax for /dev/pts/ptmx
  (with a trailing slash).

  This bug is fixed by adding an apparmor rule, identical to the normal
  rule, with an extra slash. Older kernels will use the new rule while
  current kernels will just ignore it.

  [Test Case]

  On an Nvidia Tegra X1 board, running 3.10.96 snap-confine should no
  longer fail to start. On Ubuntu Xenial (all architectures) there
  should be no perceived change.

  Snap-confine is carefully tested with a battery of spread tests that
  can be found here: https://github.com/snapcore/snap-
  confine/blob/master/spread-tests/

  The test cases are ran automatically for each pull request and for
  each final release.

  All those tests were executed successfully for this release. As a
  simple test case consider running any snap (any at all, including
  hello-world).

  [Regression Potential]

   * Regression potential is minimal as the fix simply adds another
  apparmor rule that grants additional permissions that are only picked
  up by old buggy kernels.

  * The fix was tested on Ubuntu via spread.

  [Other Info]

  * This bug is a part of a major SRU that brings snap-confine in Ubuntu
  16.04 in line with the current upstream release 1.0.41.

  * This bug was included in an earlier SRU and is now fixed in Ubuntu.
  I am updating the template here to ensure that the process is fully
  documented from 1.0.38 all the way up to the current upstream release
  1.0.41.

  * snap-confine is technically an integral part of snapd which has an
  SRU exception and is allowed to introduce new features and take
  advantage of accelerated procedure. For more information see
  https://wiki.ubuntu.com/SnapdUpdates

  == # Pre-SRU bug description follows # ==

  - Finding issues running snaps (hello-world).
  - Same issue even installing with --devmode. Even running the snap binary as 
root
  - Using a custom kernel, this is on an Nvidia Tegra X1 custom board.

  =

  ubuntu@localhost:~$ hello-world.echo plop
  unable to mount '/dev/pts/ptmx'->'/dev/ptmx'. errmsg: Permission denied
  ubuntu@localhost:~$ sudo hello-world.echo plop
  unable to mount '/dev/pts/ptmx'->'/dev/ptmx'. errmsg: Permission denied

  dmesg shows:
  =

  [  302.838046] type=1400 audit(1455208371.989:16): apparmor="DENIED"
  operation="mount" info="failed mntpnt match" error=-13 parent=911
  profile="/usr/bin/ubuntu-core-launcher" name="/dev/ptmx/" pid=912
  comm="ubuntu-core-lau" srcname="/dev/pts/ptmx/" flags="rw, bind"
  [  308.080449] type=1400 audit(1455208377.229:17): apparmor="DENIED"
  operation="mount" info="failed mntpnt match" error=-13 parent=914
  profile="/usr/bin/ubuntu-core-launcher" name="/dev/ptmx/" pid=915
  comm="ubuntu-core-lau" srcname="/dev/pts/ptmx/" flags="rw, bind"

  This is with the "hello-world" snap installed with "snap install"

  Output of an ls over the device file:
  =

  ubuntu@localhost:~$ ls -lR /dev/ptmx /dev/pts
  crw-rw-rw- 1 root tty  5, 2 Feb 11 16:28 /dev/ptmx

  /dev/pts:
  total 0
  c- 1 root root 5, 2 Jan  1  1970 ptmx

To manage notifications about this bug go to:
https://bugs.launchpad.net/snap-confine/+bug/1584456/+subscriptions

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

[Kernel-packages] [Bug 1584456] Re: apparmor denial using ptmx char device

[Michael Hudson-Doyle]

** Also affects: snap-confine (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: snap-confine (Ubuntu)
   Status: New => Fix Released

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1584456

Title:
  apparmor denial using ptmx char device

Status in Snappy Launcher:
  Fix Released
Status in linux package in Ubuntu:
  Confirmed
Status in snap-confine package in Ubuntu:
  Fix Released

Bug description:
  [Impact]

  snap-confine would refuse to work on an older kernel running on an
  Nvidia Tegra X1 board. This was traced to a bug in older version of
  apparmor there that required directory-like syntax for /dev/pts/ptmx
  (with a trailing slash).

  This bug is fixed by adding an apparmor rule, identical to the normal
  rule, with an extra slash. Older kernels will use the new rule while
  current kernels will just ignore it.

  [Test Case]

  On an Nvidia Tegra X1 board, running 3.10.96 snap-confine should no
  longer fail to start. On Ubuntu Xenial (all architectures) there
  should be no perceived change.

  Snap-confine is carefully tested with a battery of spread tests that
  can be found here: https://github.com/snapcore/snap-
  confine/blob/master/spread-tests/

  The test cases are ran automatically for each pull request and for
  each final release.

  All those tests were executed successfully for this release. As a
  simple test case consider running any snap (any at all, including
  hello-world).

  [Regression Potential]

   * Regression potential is minimal as the fix simply adds another
  apparmor rule that grants additional permissions that are only picked
  up by old buggy kernels.

  * The fix was tested on Ubuntu via spread.

  [Other Info]

  * This bug is a part of a major SRU that brings snap-confine in Ubuntu
  16.04 in line with the current upstream release 1.0.41.

  * This bug was included in an earlier SRU and is now fixed in Ubuntu.
  I am updating the template here to ensure that the process is fully
  documented from 1.0.38 all the way up to the current upstream release
  1.0.41.

  * snap-confine is technically an integral part of snapd which has an
  SRU exception and is allowed to introduce new features and take
  advantage of accelerated procedure. For more information see
  https://wiki.ubuntu.com/SnapdUpdates

  == # Pre-SRU bug description follows # ==

  - Finding issues running snaps (hello-world).
  - Same issue even installing with --devmode. Even running the snap binary as 
root
  - Using a custom kernel, this is on an Nvidia Tegra X1 custom board.

  =

  ubuntu@localhost:~$ hello-world.echo plop
  unable to mount '/dev/pts/ptmx'->'/dev/ptmx'. errmsg: Permission denied
  ubuntu@localhost:~$ sudo hello-world.echo plop
  unable to mount '/dev/pts/ptmx'->'/dev/ptmx'. errmsg: Permission denied

  dmesg shows:
  =

  [  302.838046] type=1400 audit(1455208371.989:16): apparmor="DENIED"
  operation="mount" info="failed mntpnt match" error=-13 parent=911
  profile="/usr/bin/ubuntu-core-launcher" name="/dev/ptmx/" pid=912
  comm="ubuntu-core-lau" srcname="/dev/pts/ptmx/" flags="rw, bind"
  [  308.080449] type=1400 audit(1455208377.229:17): apparmor="DENIED"
  operation="mount" info="failed mntpnt match" error=-13 parent=914
  profile="/usr/bin/ubuntu-core-launcher" name="/dev/ptmx/" pid=915
  comm="ubuntu-core-lau" srcname="/dev/pts/ptmx/" flags="rw, bind"

  This is with the "hello-world" snap installed with "snap install"

  Output of an ls over the device file:
  =

  ubuntu@localhost:~$ ls -lR /dev/ptmx /dev/pts
  crw-rw-rw- 1 root tty  5, 2 Feb 11 16:28 /dev/ptmx

  /dev/pts:
  total 0
  c- 1 root root 5, 2 Jan  1  1970 ptmx

To manage notifications about this bug go to:
https://bugs.launchpad.net/snap-confine/+bug/1584456/+subscriptions

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

[Kernel-packages] [Bug 1526113] [NEW] needs s390x support

[Michael Hudson-Doyle]

Public bug reported:

cpu-checker / kvm-ok is not available on s390x. I'm not sure what it
should do, otherwise I'd attach a patch :-)

** Affects: cpu-checker
 Importance: Undecided
 Status: New

** Affects: cpu-checker (Ubuntu)
 Importance: Undecided
 Status: New

** Also affects: cpu-checker
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to cpu-checker in Ubuntu.
https://bugs.launchpad.net/bugs/1526113

Title:
  needs s390x support

Status in CPU-Checker:
  New
Status in cpu-checker package in Ubuntu:
  New

Bug description:
  cpu-checker / kvm-ok is not available on s390x. I'm not sure what it
  should do, otherwise I'd attach a patch :-)

To manage notifications about this bug go to:
https://bugs.launchpad.net/cpu-checker/+bug/1526113/+subscriptions

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

[Kernel-packages] [Bug 982738] Re: Kernel Oops - BUG: unable to handle kernel paging request at fffffffffffffb88; RIP: 0010:[ffffffffa02bd6ed] [ffffffffa02bd6ed] ieee80211_stop_tx_ba_cb_irqsafe+0x

[Michael Hudson-Doyle]

I haven't had this problem in a long time indeed.  Don't see the point
in keeping it open.

** Changed in: linux (Ubuntu)
   Status: Incomplete = Invalid

-- 
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/982738

Title:
  Kernel Oops - BUG: unable to handle kernel paging request at
  fb88; RIP: 0010:[a02bd6ed]  [a02bd6ed]
  ieee80211_stop_tx_ba_cb_irqsafe+0x1d/0xa0 [mac80211]

Status in “linux” package in Ubuntu:
  Invalid

Bug description:
  I wasn't doing anything particular when this happened!  Just typing an
  email.

  ProblemType: KernelOops
  DistroRelease: Ubuntu 12.04
  Package: linux-image-3.2.0-23-generic 3.2.0-23.36
  ProcVersionSignature: Ubuntu 3.2.0-23.36-generic 3.2.14
  Uname: Linux 3.2.0-23-generic x86_64
  AlsaVersion: Advanced Linux Sound Architecture Driver Version 1.0.24.
  Annotation: Your system might become unstable now and might need to be 
restarted.
  ApportVersion: 2.0.1-0ubuntu3
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  mwhudson   2916 F pulseaudio
   /dev/snd/controlC1:  mwhudson   2916 F pulseaudio
  CRDA:
   country NZ:
(2402 - 2482 @ 40), (N/A, 30)
(5170 - 5250 @ 20), (3, 23)
(5250 - 5330 @ 20), (3, 23), DFS
(5735 - 5835 @ 20), (3, 30)
  Card0.Amixer.info:
   Card hw:0 'PCH'/'HDA Intel PCH at 0xd262 irq 50'
 Mixer name : 'Intel CougarPoint HDMI'
 Components : 'HDA:14f1506e,17aa21da,0010 
HDA:80862805,80860101,0010'
 Controls  : 26
 Simple ctrls  : 8
  Card1.Amixer.info:
   Card hw:1 'Headset'/'Logitech Logitech USB Headset at usb-:00:1d.0-1.2, 
full speed'
 Mixer name : 'USB Mixer'
 Components : 'USB046d:0a0b'
 Controls  : 6
 Simple ctrls  : 2
  Card29.Amixer.info:
   Card hw:29 'ThinkPadEC'/'ThinkPad Console Audio Control at EC reg 0x30, fw 
unknown'
 Mixer name : 'ThinkPad EC (unknown)'
 Components : ''
 Controls  : 1
 Simple ctrls  : 1
  Card29.Amixer.values:
   Simple mixer control 'Console',0
 Capabilities: pswitch pswitch-joined penum
 Playback channels: Mono
 Mono: Playback [off]
  Date: Mon Apr 16 14:23:39 2012
  Failure: oops
  HibernationDevice: RESUME=UUID=60adf8ef-26b5-4bda-919e-5afd1c1c37d8
  MachineType: LENOVO 4286CTO
  OopsText:
   BUG: unable to handle kernel paging request at fb88
   IP: [a02bd6ed] ieee80211_stop_tx_ba_cb_irqsafe+0x1d/0xa0 [mac80211]
   PGD 1c07067 PUD 1c08067 PMD 0 
   Oops:  [#1] SMP
  ProcFB: 0 inteldrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.2.0-23-generic 
root=UUID=4f1086ad-77f6-4ad8-ad3b-9171e2bbae3a ro quiet splash vt.handoff=7
  PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No 
PulseAudio daemon running, or not running as session daemon.
  RelatedPackageVersions: kerneloops-daemon 0.12+git20090217-1ubuntu18
  SourcePackage: linux
  StagingDrivers: mei
  Title: BUG: unable to handle kernel paging request at fb88
  UpgradeStatus: Upgraded to precise on 2012-03-26 (20 days ago)
  dmi.bios.date: 04/01/2011
  dmi.bios.vendor: LENOVO
  dmi.bios.version: 8DET42WW (1.12 )
  dmi.board.asset.tag: Not Available
  dmi.board.name: 4286CTO
  dmi.board.vendor: LENOVO
  dmi.board.version: Not Available
  dmi.chassis.asset.tag: No Asset Information
  dmi.chassis.type: 10
  dmi.chassis.vendor: LENOVO
  dmi.chassis.version: Not Available
  dmi.modalias: 
dmi:bvnLENOVO:bvr8DET42WW(1.12):bd04/01/2011:svnLENOVO:pn4286CTO:pvrThinkPadX220:rvnLENOVO:rn4286CTO:rvrNotAvailable:cvnLENOVO:ct10:cvrNotAvailable:
  dmi.product.name: 4286CTO
  dmi.product.version: ThinkPad X220
  dmi.sys.vendor: LENOVO

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

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