[Kernel-packages] [Bug 1967131] Re: CONFIG_NR_CPUS=64 in -kvm is too low compared to -generic

2023-03-27 Thread Stéphane Graber
Re-opening as until linux-kvm is deprecated or the CPC team moves over
to using linux-virtual for KVM images, this is the kernel we're dealing
with and that kernel should be functional.

** Changed in: linux-kvm (Ubuntu)
   Status: Invalid => Triaged

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

Title:
  CONFIG_NR_CPUS=64 in -kvm is too low compared to -generic

Status in linux-kvm package in Ubuntu:
  Triaged

Bug description:
  -kvm flavor has CONFIG_NR_CPUS=64 although -generic has
  CONFIG_NR_CPUS=8192 these days.

  It will be a problem especially when launching a VM on top of a
  hypervisor with more than 64 CPU threads available. Then the guest can
  only use up to 64 vCPUs even when more vCPUs are allocated by a
  hypervisor.

  I've checked the latest available package for Jammy, but there was no change 
around CONFIG_NR_CPUS.
  https://launchpad.net/ubuntu/+source/linux-kvm/5.15.0-1003.3

  $ lsb_release -r
  Release:20.04

  $ dpkg -S /boot/config*
  linux-modules-5.4.0-105-generic: /boot/config-5.4.0-105-generic
  linux-modules-5.4.0-1059-kvm: /boot/config-5.4.0-1059-kvm

  $ grep CONFIG_NR_CPUS /boot/config*
  /boot/config-5.4.0-105-generic:CONFIG_NR_CPUS_RANGE_BEGIN=8192
  /boot/config-5.4.0-105-generic:CONFIG_NR_CPUS_RANGE_END=8192
  /boot/config-5.4.0-105-generic:CONFIG_NR_CPUS_DEFAULT=8192
  /boot/config-5.4.0-105-generic:CONFIG_NR_CPUS=8192
  /boot/config-5.4.0-1059-kvm:CONFIG_NR_CPUS_RANGE_BEGIN=2
  /boot/config-5.4.0-1059-kvm:CONFIG_NR_CPUS_RANGE_END=512
  /boot/config-5.4.0-1059-kvm:CONFIG_NR_CPUS_DEFAULT=64
  /boot/config-5.4.0-1059-kvm:CONFIG_NR_CPUS=64

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-kvm/+bug/1967131/+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 1966499] Re: Recent 5.13 kernel has broken KVM support

2022-03-25 Thread Stéphane Graber
Ah yeah, that could be. I figured I'd test what's in -proposed but if
-proposed is a security only fix on top of -37, that wouldn't help much.

It's a bit frustrating because users would have gotten the busted kernel
as part of -37 which includes a security fix but then the only real
option to get a booting system back now is to go to pre-security-fix.

Unfortunately this is a production server and I already spent half of
the week dealing with this mess so don't have more time to play kernel
bingo. Server is now running a clean upstream build.

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

Title:
  Recent 5.13 kernel has broken KVM support

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Upgrading to 5.13.0-37 or 5.13.0-39 immediately crashes my production servers 
as they hit:
  
https://lore.kernel.org/all/f1ea22d3-cff8-406a-ad6a-cb8e0124a...@leemhuis.info/T/#md1f5c8c4aa01130a449a47f3e7559f06b0372f55

  It looks like we need to get e90e51d5f01d included in those kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1966499/+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 1966499] Re: Recent 5.13 kernel has broken KVM support

2022-03-25 Thread Stéphane Graber
This repeats in a loop and fills tens of GBs of space with kernel logs
in just a few minutes before crashing the entire system.

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

Title:
  Recent 5.13 kernel has broken KVM support

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Upgrading to 5.13.0-37 or 5.13.0-39 immediately crashes my production servers 
as they hit:
  
https://lore.kernel.org/all/f1ea22d3-cff8-406a-ad6a-cb8e0124a...@leemhuis.info/T/#md1f5c8c4aa01130a449a47f3e7559f06b0372f55

  It looks like we need to get e90e51d5f01d included in those kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1966499/+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 1966499] Re: Recent 5.13 kernel has broken KVM support

2022-03-25 Thread Stéphane Graber
Mar 25 16:18:30 abydos kernel: [ 1319.549186] [ cut here 
]
Mar 25 16:18:30 abydos kernel: [ 1319.549191] WARNING: CPU: 12 PID: 15052 at 
arch/x86/kvm/vmx/vmx.c:6336 vmx_sync_pir_to_irr+0x9f/0xc0 [kvm_intel]
Mar 25 16:18:30 abydos kernel: [ 1319.549213] Modules linked in: wireguard 
curve25519_x86_64 libchacha20poly1305 chacha_x86_64 poly1305_x86_64 libblake2s 
blake2s_x86_64 libcurve25519_generic libchacha libblake2s_generic xt_HL 
xt_MASQUERADE xt_TCPMSS xt_tcpudp binfmt_misc rbd unix_diag 
nf_conntrack_netlink veth ceph libceph fscache netfs zfs(PO) zunicode(PO) 
zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) ebtable_filter 
ebtables ip6table_raw ip6table_mangle ip6table_nat ip6table_filter ip6_tables 
iptable_raw iptable_mangle iptable_nat iptable_filter bpfilter nf_tables 
vhost_vsock vmw_vsock_virtio_transport_common vhost vhost_iotlb vsock shiftfs 
sch_ingress geneve ip6_udp_tunnel udp_tunnel nfnetlink_cttimeout nfnetlink 
openvswitch nsh nf_conncount nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 
8021q garp mrp nls_iso8859_1 dm_multipath scsi_dh_rdac scsi_dh_emc scsi_dh_alua 
ipmi_ssif intel_rapl_msr intel_rapl_common sb_edac x86_pkg_temp_thermal 
intel_powerclamp coretemp kvm_intel kvm rapl intel_cstate
Mar 25 16:18:30 abydos kernel: [ 1319.549305]  efi_pstore joydev input_leds 
cdc_acm mei_me mei ioatdma bridge stp llc bonding acpi_ipmi tls ipmi_si 
ipmi_devintf ipmi_msghandler acpi_power_meter acpi_pad mac_hid sch_fq_codel 
ip_tables x_tables autofs4 btrfs blake2b_generic zstd_compress raid10 raid456 
async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq 
libcrc32c raid1 raid0 multipath linear hid_generic usbhid hid ast 
drm_vram_helper drm_ttm_helper ttm drm_kms_helper syscopyarea sysfillrect 
sysimgblt crct10dif_pclmul fb_sys_fops crc32_pclmul ghash_clmulni_intel cec 
nvme rc_core aesni_intel crypto_simd ixgbe igb i2c_i801 xfrm_algo nvme_core drm 
i2c_smbus ahci i2c_algo_bit cryptd lpc_ich dca xhci_pci mdio libahci 
xhci_pci_renesas wmi
Mar 25 16:18:30 abydos kernel: [ 1319.549394] CPU: 12 PID: 15052 Comm: 
qemu-system-x86 Tainted: P   O  5.13.0-39-generic #44~20.04.1-Ubuntu
Mar 25 16:18:30 abydos kernel: [ 1319.549399] Hardware name: Supermicro 
PIO-618U-T4T+-ST031/X10DRU-i+, BIOS 3.2a 11/19/2019
Mar 25 16:18:30 abydos kernel: [ 1319.549402] RIP: 
0010:vmx_sync_pir_to_irr+0x9f/0xc0 [kvm_intel]
Mar 25 16:18:30 abydos kernel: [ 1319.549415] Code: 83 c4 10 5b 5d c3 48 89 df 
e8 5d dc eb fd 8b 93 00 03 00 00 89 45 ec 83 e2 20 85 d2 75 d2 89 c7 e8 f6 fd 
ff ff 8b 45 ec eb c6 <0f> 0b eb 86 f0 80 4b 39 40 8b 93 00 03 00 00 8b 45 ec 83 
e2 20 eb
Mar 25 16:18:30 abydos kernel: [ 1319.549419] RSP: 0018:aed30c577cd8 
EFLAGS: 00010246
Mar 25 16:18:30 abydos kernel: [ 1319.549423] RAX:  RBX: 
98162a4f8000 RCX: 
Mar 25 16:18:30 abydos kernel: [ 1319.549425] RDX: 0400 RSI: 
c0c38509 RDI: 98162a4f8000
Mar 25 16:18:30 abydos kernel: [ 1319.549428] RBP: aed30c577cf0 R08: 
0400 R09: 98161e73fc00
Mar 25 16:18:30 abydos kernel: [ 1319.549430] R10:  R11: 
 R12: 98162a4f8000
Mar 25 16:18:30 abydos kernel: [ 1319.549433] R13: 7f272bff9dd0 R14: 
98161e73fc00 R15: 98162a4f8000
Mar 25 16:18:30 abydos kernel: [ 1319.549435] FS:  7f272bffe700() 
GS:981c9f80() knlGS:
Mar 25 16:18:30 abydos kernel: [ 1319.549439] CS:  0010 DS:  ES:  CR0: 
80050033
Mar 25 16:18:30 abydos kernel: [ 1319.549442] CR2: 7f2a31708001 CR3: 
0009ea4ac001 CR4: 001726e0
Mar 25 16:18:30 abydos kernel: [ 1319.549445] Call Trace:
Mar 25 16:18:30 abydos kernel: [ 1319.549447]  
Mar 25 16:18:30 abydos kernel: [ 1319.549450]  kvm_arch_vcpu_ioctl+0x8fd/0x1260 
[kvm]
Mar 25 16:18:30 abydos kernel: [ 1319.549590]  ? 
kvm_arch_vcpu_ioctl+0xc1/0x1260 [kvm]
Mar 25 16:18:30 abydos kernel: [ 1319.549659]  ? kfree+0xd8/0x2a0
Mar 25 16:18:30 abydos kernel: [ 1319.549669]  kvm_vcpu_ioctl+0x3a7/0x5f0 [kvm]
Mar 25 16:18:30 abydos kernel: [ 1319.549720]  ? __fget_light+0xce/0xf0
Mar 25 16:18:30 abydos kernel: [ 1319.549728]  __x64_sys_ioctl+0x91/0xc0
Mar 25 16:18:30 abydos kernel: [ 1319.549734]  do_syscall_64+0x61/0xb0
Mar 25 16:18:30 abydos kernel: [ 1319.549739]  ? do_syscall_64+0x6e/0xb0
Mar 25 16:18:30 abydos kernel: [ 1319.549742]  ? 
syscall_exit_to_user_mode+0x27/0x50
Mar 25 16:18:30 abydos kernel: [ 1319.549747]  ? do_syscall_64+0x6e/0xb0
Mar 25 16:18:30 abydos kernel: [ 1319.549750]  ? 
syscall_exit_to_user_mode+0x27/0x50
Mar 25 16:18:30 abydos kernel: [ 1319.549755]  ? do_syscall_64+0x6e/0xb0
Mar 25 16:18:30 abydos kernel: [ 1319.549758]  
entry_SYSCALL_64_after_hwframe+0x44/0xae
Mar 25 16:18:30 abydos kernel: [ 1319.549771] RIP: 0033:0x7f2a3b2b33db
Mar 25 16:18:30 abydos kernel: [ 1319.549775] Code: 0f 1e fa 48 8b 05 b5 7a 0d 
00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 0f 1f 44 

[Kernel-packages] [Bug 1966499] [NEW] Recent 5.13 kernel has broken KVM support

2022-03-25 Thread Stéphane Graber
Public bug reported:

Upgrading to 5.13.0-37 or 5.13.0-39 immediately crashes my production servers 
as they hit:
https://lore.kernel.org/all/f1ea22d3-cff8-406a-ad6a-cb8e0124a...@leemhuis.info/T/#md1f5c8c4aa01130a449a47f3e7559f06b0372f55

It looks like we need to get e90e51d5f01d included in those kernels.

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

** Changed in: linux (Ubuntu)
   Status: New => 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/1966499

Title:
  Recent 5.13 kernel has broken KVM support

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  Upgrading to 5.13.0-37 or 5.13.0-39 immediately crashes my production servers 
as they hit:
  
https://lore.kernel.org/all/f1ea22d3-cff8-406a-ad6a-cb8e0124a...@leemhuis.info/T/#md1f5c8c4aa01130a449a47f3e7559f06b0372f55

  It looks like we need to get e90e51d5f01d included in those kernels.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1966499/+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 1935880] Re: lxc c2-m2 focal VM causes KVM internal error during PCI init

2022-03-24 Thread Stéphane Graber
Adding linux-kvm to the bug. It looks like if we can have the commit
above backported, it would take care of this issue for most users.

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

** Changed in: linux-kvm (Ubuntu)
   Status: New => 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/1935880

Title:
  lxc c2-m2 focal VM causes KVM internal error during PCI init

Status in linux package in Ubuntu:
  Confirmed
Status in linux-kvm package in Ubuntu:
  Confirmed

Bug description:
  Launching a 2 CPU 2G VM with lxc often cause a KVM internal error
  during boot.

  Reproducer:
  lxc launch ubuntu:20.04 dannf-test2 -t c2-m2 --vm

  QEMU will report a KVM internal error:

  KVM internal error. Suberror: 3
  extra data[0]: 80ec
  extra data[1]: 31
  extra data[2]: 81
  extra data[3]: 3
  RAX= RBX=0001 RCX=0001 
RDX=021e
  RSI=88807851cba8 RDI=0001 RBP=c9077e90 
RSP=c9077e78
  R8 =29417eca R9 = R10=0400 
R11=0400
  R12=0001 R13=8880001c8c80 R14= 
R15=
  RIP=81757a74 RFL=0246 [---Z-P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
  ES =   00c0
  CS =0010   00a09b00 DPL=0 CS64 [-RA]
  SS =   00c0
  DS =   00c0
  FS =   00c0
  GS = 88807850  00c0
  LDT=   00c0
  TR =0040 fe036000 206f 8b00 DPL=0 TSS64-busy
  GDT= fe034000 007f
  IDT= fe00 0fff
  CR0=80050033 CR2= CR3=0240a000 CR4=001006a0
  DR0= DR1= DR2= 
DR3=
  DR6=0ff0 DR7=0400
  EFER=0d01
  Code=00 85 c0 7e 07 0f 00 2d 16 93 4b 00 fb f4 8b 05 14 61 78 00 <65> 44 8b 
25 b4 86 8b 7e 85 c0 0f 8f 85 00 00 00 5b 41 5c 41 5d 5d c3 65 8b 05 9e 86 8b 7e

  The last lines on the console:
  acpi PNP0A08:00: _OSC: OS supports [ASPM ClockPM Segments MSI HPX-Type3]
  acpi PNP0A08:00: _OSC: not requesting OS control; OS requires [ExtendedConfig 
ASPM ClockPM MSI]
  PCI host bridge to bus :00
  pci_bus :00: root bus resource [io  0x-0x0cf7 window]
  pci_bus :00: root bus resource [io  0x0d00-0x window]
  pci_bus :00: root bus resource [mem 0x000a-0x000b window]
  pci_bus :00: root bus resource [mem 0x7a10-0xafff window]
  pci_bus :00: root bus resource [mem 0xc000-0xfebf window]
  pci_bus :00: root bus resource [mem 0x8-0xf window]
  pci_bus :00: root bus resource [bus 00-ff]
  pci :00:00.0: [8086:29c0] type 00 class 0x06
  pci :00:01.0: [1b36:000c] type 01 class 0x060400
  pci :00:01.0: reg 0x10: [mem 0xc1245000-0xc1245fff]
  pci :00:01.1: [1b36:000c] type 01 class 0x060400
  pci :00:01.1: reg 0x10: [mem 0xc1244000-0xc1244fff]
  pci :00:01.2: [1b36:000c] type 01 class 0x060400
  pci :00:01.2: reg 0x10: [mem 0xc1243000-0xc1243fff]
  pci :00:01.3: [1b36:000c] type 01 class 0x060400

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1935880/+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 1960094] Re: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal

2022-02-08 Thread Stéphane Graber
Closing the LXC task for now as that seems to be unrelated to a LXC
change (we haven't uploaded in a while) and not related to a new kernel
release which could actually cause such a change.

If you track this down to something other than an issue in your test
environment, please add lxc to this issue 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/1960094

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

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

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

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

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


-- 
Mailing list: https://launchpad.net/~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 1960094] Re: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal

2022-02-08 Thread Stéphane Graber
** Changed in: lxc (Ubuntu)
   Status: Incomplete => Invalid

** Changed in: lxc (Ubuntu Focal)
   Status: Incomplete => Invalid

** No longer affects: lxc (Ubuntu)

** No longer affects: lxc (Ubuntu Focal)

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

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

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

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

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

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


-- 
Mailing list: https://launchpad.net/~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 1960094] Re: lxc/1:4.0.6-0ubuntu1~20.04.1 undefined symbol: strlcat in Focal

2022-02-07 Thread Stéphane Graber
I think the strlcat thing is a red herring or an indication that the
test environment is somehow in a bad shape. This could be explained if
there was two versions of liblxc on the system for example.

Outside of that, I'm also seeing:
```
  lxc-start tmp.KEpxw2rh0e 20220205081512.354 ERRORutils - 
utils.c:__safe_mount_beneath_at:1106 - Function not implemented - Failed to 
open 30(full)
```

Which isn't a test issue but an actual failure. It could once again come
from a bad test environment with mismatching library/binary somehow, but
if the test environment isn't the issue, then you have a kernel
regression on your hands as that's not one of those transient test
failures.

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

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

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

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

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

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


-- 
Mailing list: https://launchpad.net/~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 1226855] Re: Cannot use open-iscsi inside LXC container

2022-02-02 Thread Stéphane Graber
Closing the LXC side of this bug as there's nothing we can really do here.
It's either a kernel issue (needs support for their socket option within a 
network namespace) or an open-iscsi issue where they could have some kind of 
fallback mechanism.

** Changed in: lxc (Ubuntu)
   Status: Confirmed => 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/1226855

Title:
  Cannot use open-iscsi inside LXC container

Status in linux package in Ubuntu:
  Confirmed
Status in lxc package in Ubuntu:
  Invalid

Bug description:
  Trying to use open-iscsi from within an LXC container, but the iscsi
  netlink socket does not support multiple namespaces, causing: "iscsid:
  sendmsg: bug? ctrl_fd 6" error and failure.

  Command attempted: iscsiadm -m node -p $ip:$port -T $target --login

  Results in:

  Exit code: 18
  Stdout: 'Logging in to [iface: default, target: $target, portal: $ip,$port] 
(multiple)'
  Stderr: 'iscsiadm: got read error (0/0), daemon died?
  iscsiadm: Could not login to [iface: default, target: $target, portal: 
$ip,$port].
  iscsiadm: initiator reported error (18 - could not communicate to iscsid)
  iscsiadm: Could not log into all portals'

  ProblemType: Bug
  DistroRelease: Ubuntu 13.04
  Package: lxc 0.9.0-0ubuntu3.4
  ProcVersionSignature: Ubuntu 3.8.0-30.44-generic 3.8.13.6
  Uname: Linux 3.8.0-30-generic x86_64
  ApportVersion: 2.9.2-0ubuntu8.3
  Architecture: amd64
  Date: Tue Sep 17 14:38:08 2013
  InstallationDate: Installed on 2013-01-15 (245 days ago)
  InstallationMedia: Xubuntu 12.10 "Quantal Quetzal" - Release amd64 
(20121017.1)
  MarkForUpload: True
  SourcePackage: lxc
  UpgradeStatus: Upgraded to raring on 2013-05-16 (124 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1226855/+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 1642767] Re: starting any container with umask 007 breaks host system shutdown. lxc-stop just hangs.

2022-02-02 Thread Stéphane Graber
Moving over to the kernel as a userspace process shouldn't be able to
cause such a hang regardless of what it does so this looks like a kernel
bug (lock related by the looks of it).

** Package changed: lxc (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/1642767

Title:
  starting any container with umask 007 breaks host system shutdown.
  lxc-stop just hangs.

Status in linux package in Ubuntu:
  Confirmed

Bug description:
  If I have umask 007 (or any other value that masks the world-execute
  bit) when I run lxc-start for the first time after logging in, my host
  system enters a state with the following problems:

  * lxc-stop hangs forever instead of stopping any container, even one that 
wasn't started with umask 007.
  * lxc-stop --kill --nolock hangs in the same way.
  * Attempts to reboot or shut down the host system fail, requiring a hard 
reset to recover.

  When lxc-stop hangs, messages like these appear in syslog every couple
  of minutes:

  Nov 17 01:22:11 hostbox kernel: [ 3360.091624] INFO: task systemd:12179 
blocked for more than 120 seconds.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091629]   Tainted: P   OE  
 4.4.0-47-generic #68-Ubuntu
  Nov 17 01:22:11 hostbox kernel: [ 3360.091631] "echo 0 > 
/proc/sys/kernel/hung_task_timeout_secs" disables this message.
  Nov 17 01:22:11 hostbox kernel: [ 3360.091633] systemd D 
8800c6febb58 0 12179  12168 0x0104
  Nov 17 01:22:11 hostbox kernel: [ 3360.091638]  8800c6febb58 
8800d318d280 88040c649b80 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091641]  8800c6fec000 
8800345bc088 8800345bc070 
  Nov 17 01:22:11 hostbox kernel: [ 3360.091644]  fffe0001 
8800c6febb70 81830f15 8800d318d280
  Nov 17 01:22:11 hostbox kernel: [ 3360.091647] Call Trace:
  Nov 17 01:22:11 hostbox kernel: [ 3360.091653]  [] 
schedule+0x35/0x80
  Nov 17 01:22:11 hostbox kernel: [ 3360.091657]  [] 
rwsem_down_write_failed+0x202/0x350
  Nov 17 01:22:11 hostbox kernel: [ 3360.091662]  [] ? 
kernfs_sop_show_options+0x40/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091666]  [] 
call_rwsem_down_write_failed+0x13/0x20
  Nov 17 01:22:11 hostbox kernel: [ 3360.091669]  [] ? 
down_write+0x2d/0x40
  Nov 17 01:22:11 hostbox kernel: [ 3360.091672]  [] 
grab_super+0x30/0xa0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091674]  [] 
sget_userns+0x152/0x450
  Nov 17 01:22:11 hostbox kernel: [ 3360.091677]  [] ? 
kernfs_sop_show_path+0x50/0x50
  Nov 17 01:22:11 hostbox kernel: [ 3360.091680]  [] 
kernfs_mount_ns+0x7e/0x230
  Nov 17 01:22:11 hostbox kernel: [ 3360.091685]  [] 
cgroup_mount+0x2eb/0x7f0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091687]  [] 
mount_fs+0x38/0x160
  Nov 17 01:22:11 hostbox kernel: [ 3360.091691]  [] 
vfs_kern_mount+0x67/0x110
  Nov 17 01:22:11 hostbox kernel: [ 3360.091694]  [] 
do_mount+0x269/0xde0
  Nov 17 01:22:11 hostbox kernel: [ 3360.091698]  [] 
SyS_mount+0x9f/0x100
  Nov 17 01:22:11 hostbox kernel: [ 3360.091701] [] 
entry_SYSCALL_64_fastpath+0x16/0x71

  When system shutdown hangs, similar messages appear on the console
  every couple of minutes.

  I can reproduce this at will with a freshly-installed and fully-
  updated host OS in VirtualBox, and with either an old-ish container or
  a new one.

  I'm running lxc 2.0.5-0ubuntu1~ubuntu16.04.2 on xubuntu 16.04.1 LTS
  amd64.

  My containers are all unprivileged.

  My umask at container creation time does not seem to matter.  As far
  as I have seen, my umask only matters the first time I start a
  container in my login session.

  I can work around the bug by manually setting my umask to something
  more permissive before I start my first container of the day, and then
  setting it back again, but that's rather a hassle.  (Even worse, it's
  very easy to forget this workaround and be left with containers that
  can't be stopped and a host system that won't shut down cleanly.)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1642767/+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 1948573] Re: Failure to start container “Failed to start device “eth0”: Error: Unknown device type.

2021-10-24 Thread Stéphane Graber
** Package changed: lxd (Ubuntu) => linux-raspi (Ubuntu)

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

Title:
  Failure to start container “Failed to start device “eth0”:  Error:
  Unknown device type.

Status in linux-raspi package in Ubuntu:
  New

Bug description:
  I know probably wrong place. Tried understand where to send bug report
  but very confusing. Hopefully someone knows where to send it.

  Raspberry pi 4B, Ubuntu 21.10,

  ~lxc launch ubuntu:20.04
  ~lxc start container
  Error: Failed preparing container for start: Failed to start device “eth0”: 
Failed to create the veth interfaces veth34cbc1ee and veth84f13473: Failed to 
run: ip link add veth34cbc1ee type veth peer name veth84f13473: Error: Unknown 
device type.

  Default profile with lxdbr0

  lxc init with defaults.

  Tried different containers with the same error. Error: Unknown device
  type

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1948573/+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 1946437] Re: snap install lxd fails

2021-10-09 Thread Stéphane Graber
Your `dmesg` output shows some serious kernel errors related to ZFS, I
bet that's the source of this.

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

Title:
  snap install lxd fails

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  This is what I get:

  sudo snap install lxd
  error: cannot perform the following tasks:
  - Setup snap "lxd" (21624) security profiles for auto-connections (cannot 
setup profiles for snap "lxd": cannot load apparmor profiles: exit status 1
  apparmor_parser output:
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.activate 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.activate at line 632: 
Could not open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.benchmark 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.benchmark at line 632: 
Could not open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.buginfo 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.buginfo at line 632: Could 
not open 'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel in profile 
/var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.daemon in 
profile /etc/apparmor.d/abstractions/nameservice at line 115: Could not open 
'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.hook.configure in profile 
/etc/apparmor.d/abstractions/nameservice at line 115: Could not open 
'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.hook.remove in profile 
/var/lib/snapd/apparmor/profiles/snap.lxd.hook.remove at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.lxc in 
profile /var/lib/snapd/apparmor/profiles/snap.lxd.lxc at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.lxc-to-lxd in profile 
/var/lib/snapd/apparmor/profiles/snap.lxd.lxc-to-lxd at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.lxd in 
profile /var/lib/snapd/apparmor/profiles/snap.lxd.lxd at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.migrate 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.migrate at line 632: Could 
not open 'abstractions/dbus-strict'
  )
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  berend 3841 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 21.10
  HibernationDevice: RESUME=none
  InstallationDate: Installed on 2021-10-07 (0 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Beta amd64 (20210922)
  MachineType: HP HP ZBook Firefly 14 inch G8 Mobile Workstation PC
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: lxd
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_cfqyq8@/vmlinuz-5.13.0-16-generic 
root=ZFS=rpool/ROOT/ubuntu_cfqyq8 ro quiet splash
  ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
  RelatedPackageVersions:
   linux-restricted-modules-5.13.0-16-generic N/A
   linux-backports-modules-5.13.0-16-generic  N/A
   linux-firmware 1.201
  Tags:  wayland-session impish
  Uname: Linux 5.13.0-16-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 06/25/2021
  dmi.bios.release: 4.2
  dmi.bios.vendor: HP
  dmi.bios.version: T76 Ver. 01.04.02
  dmi.board.name: 880D
  dmi.board.vendor: HP
  dmi.board.version: KBC Version 30.2E.00
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.ec.firmware.release: 48.46
  dmi.modalias: 
dmi:bvnHP:bvrT76Ver.01.04.02:bd06/25/2021:br4.2:efr48.46:svnHP:pnHPZBookFirefly14inchG8MobileWorkstationPC:pvr:sku4A6P8PA#ABG:rvnHP:rn880D:rvrKBCVersion30.2E.00:cvnHP:ct10:cvr:
  dmi.product.family: 103C_5336AN HP ZBook
  dmi.product.name: HP ZBook Firefly 14 inch G8 Mobile Workstation PC
  dmi.product.sku: 4A6P8PA#ABG
  dmi.sys.vendor: HP
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  berend 3841 F pulseaudio
  CasperMD5CheckResult: pass
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 21.10
  HibernationDevice: RESUME=none
  InstallationDate: Installed on 2021-10-07 (0 days ago)
  

[Kernel-packages] [Bug 1946437] Re: snap install lxd fails

2021-10-08 Thread Stéphane Graber
Removing the LXD task as this isn't a LXD bug, the error is coming from
snapd when setting up the apparmor profiles. Most likely explanation is
that there's something pretty wrong going on with your /etc/apparmor.d
on your system. The errors indicate a variety of missing abstractions
files.

** Changed in: lxd (Ubuntu)
   Status: New => Invalid

** No longer affects: lxd (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/1946437

Title:
  snap install lxd fails

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  This is what I get:

  sudo snap install lxd
  error: cannot perform the following tasks:
  - Setup snap "lxd" (21624) security profiles for auto-connections (cannot 
setup profiles for snap "lxd": cannot load apparmor profiles: exit status 1
  apparmor_parser output:
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.activate 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.activate at line 632: 
Could not open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.benchmark 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.benchmark at line 632: 
Could not open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.buginfo 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.buginfo at line 632: Could 
not open 'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel in profile 
/var/lib/snapd/apparmor/profiles/snap.lxd.check-kernel at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.daemon in 
profile /etc/apparmor.d/abstractions/nameservice at line 115: Could not open 
'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.hook.configure in profile 
/etc/apparmor.d/abstractions/nameservice at line 115: Could not open 
'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.hook.remove in profile 
/var/lib/snapd/apparmor/profiles/snap.lxd.hook.remove at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.lxc in 
profile /var/lib/snapd/apparmor/profiles/snap.lxd.lxc at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for 
/var/lib/snapd/apparmor/profiles/snap.lxd.lxc-to-lxd in profile 
/var/lib/snapd/apparmor/profiles/snap.lxd.lxc-to-lxd at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.lxd in 
profile /var/lib/snapd/apparmor/profiles/snap.lxd.lxd at line 632: Could not 
open 'abstractions/dbus-strict'
  AppArmor parser error for /var/lib/snapd/apparmor/profiles/snap.lxd.migrate 
in profile /var/lib/snapd/apparmor/profiles/snap.lxd.migrate at line 632: Could 
not open 'abstractions/dbus-strict'
  )
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  AudioDevicesInUse:
   USERPID ACCESS COMMAND
   /dev/snd/controlC0:  berend 3841 F pulseaudio
  CurrentDesktop: ubuntu:GNOME
  DistroRelease: Ubuntu 21.10
  HibernationDevice: RESUME=none
  InstallationDate: Installed on 2021-10-07 (0 days ago)
  InstallationMedia: Ubuntu 21.10 "Impish Indri" - Beta amd64 (20210922)
  MachineType: HP HP ZBook Firefly 14 inch G8 Mobile Workstation PC
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: lxd
  ProcFB: 0 i915drmfb
  ProcKernelCmdLine: BOOT_IMAGE=/BOOT/ubuntu_cfqyq8@/vmlinuz-5.13.0-16-generic 
root=ZFS=rpool/ROOT/ubuntu_cfqyq8 ro quiet splash
  ProcVersionSignature: Ubuntu 5.13.0-16.16-generic 5.13.13
  RelatedPackageVersions:
   linux-restricted-modules-5.13.0-16-generic N/A
   linux-backports-modules-5.13.0-16-generic  N/A
   linux-firmware 1.201
  Tags:  wayland-session impish
  Uname: Linux 5.13.0-16-generic x86_64
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: adm cdrom dip lpadmin lxd plugdev sambashare sudo
  _MarkForUpload: True
  dmi.bios.date: 06/25/2021
  dmi.bios.release: 4.2
  dmi.bios.vendor: HP
  dmi.bios.version: T76 Ver. 01.04.02
  dmi.board.name: 880D
  dmi.board.vendor: HP
  dmi.board.version: KBC Version 30.2E.00
  dmi.chassis.type: 10
  dmi.chassis.vendor: HP
  dmi.ec.firmware.release: 48.46
  dmi.modalias: 
dmi:bvnHP:bvrT76Ver.01.04.02:bd06/25/2021:br4.2:efr48.46:svnHP:pnHPZBookFirefly14inchG8MobileWorkstationPC:pvr:sku4A6P8PA#ABG:rvnHP:rn880D:rvrKBCVersion30.2E.00:cvnHP:ct10:cvr:
  dmi.product.family: 103C_5336AN HP ZBook
  dmi.product.name: HP ZBook Firefly 14 inch G8 Mobile Workstation PC
  dmi.product.sku: 4A6P8PA#ABG
  dmi.sys.vendor: HP
  --- 
  ProblemType: Bug
  ApportVersion: 2.20.11-0ubuntu70
  Architecture: amd64
  

[Kernel-packages] [Bug 1906476] Re: PANIC at zfs_znode.c:335:zfs_znode_sa_init() // VERIFY(0 == sa_handle_get_from_db(zfsvfs->z_os, db, zp, SA_HDL_SHARED, >z_sa_hdl)) failed

2021-08-19 Thread Stéphane Graber
In my case I was constantly getting corruption of /etc/apparmor.d with
the matching zfs PANIC. I'd fix that directory and it'd break again on
next boot.

System is impish with 5.13 kernel (same on 5.11) using zfs encryption.

After fighting with this for over a day, I just gave the 2.1.0 dkms a go
(won't recommend as that's quite hackish on impish and doesn't play
super well with the initrd scripts) and so far so good, scanned the
entire filesystem and all broken files are now readable.

Let's see if it ends up coming back for me...

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

Title:
  PANIC at zfs_znode.c:335:zfs_znode_sa_init() // VERIFY(0 ==
  sa_handle_get_from_db(zfsvfs->z_os, db, zp, SA_HDL_SHARED,
  >z_sa_hdl)) failed

Status in Native ZFS for Linux:
  New
Status in zfs-linux package in Ubuntu:
  In Progress

Bug description:
  Since today while running Ubuntu 21.04 Hirsute I started getting a ZFS
  panic in the kernel log which was also hanging Disk I/O for all
  Chrome/Electron Apps.

  I have narrowed down a few important notes:
  - It does not happen with module version 0.8.4-1ubuntu11 built and included 
with 5.8.0-29-generic

  - It was happening when using zfs-dkms 0.8.4-1ubuntu16 built with DKMS
  on the same kernel and also on 5.8.18-acso (a custom kernel).

  - For whatever reason multiple Chrome/Electron apps were affected,
  specifically Discord, Chrome and Mattermost. In all cases they seem
  (but I was unable to strace the processes so it was a bit hard ot
  confirm 100% but by deduction from /proc/PID/fd and the hanging ls)
  they seem hung trying to open files in their 'Cache' directory, e.g.
  ~/.cache/google-chrome/Default/Cache and ~/.config/Mattermost/Cache ..
  while the issue was going on I could not list that directory either
  "ls" would just hang.

  - Once I removed zfs-dkms only to revert to the kernel built-in
  version it immediately worked without changing anything, removing
  files, etc.

  - It happened over multiple reboots and kernels every time, all my
  Chrome apps weren't working but for whatever reason nothing else
  seemed affected.

  - It would log a series of spl_panic dumps into kern.log that look like this:
  Dec  2 12:36:42 optane kernel: [   72.857033] VERIFY(0 == 
sa_handle_get_from_db(zfsvfs->z_os, db, zp, SA_HDL_SHARED, >z_sa_hdl)) 
failed
  Dec  2 12:36:42 optane kernel: [   72.857036] PANIC at 
zfs_znode.c:335:zfs_znode_sa_init()

  I could only find one other google reference to this issue, with 2 other 
users reporting the same error but on 20.04 here:
  https://github.com/openzfs/zfs/issues/10971

  - I was not experiencing the issue on 0.8.4-1ubuntu14 and fairly sure
  it was working on 0.8.4-1ubuntu15 but broken after upgrade to
  0.8.4-1ubuntu16. I will reinstall those zfs-dkms versions to verify
  that.

  There were a few originating call stacks but the first one I hit was

  Call Trace:
   dump_stack+0x74/0x95
   spl_dumpstack+0x29/0x2b [spl]
   spl_panic+0xd4/0xfc [spl]
   ? sa_cache_constructor+0x27/0x50 [zfs]
   ? _cond_resched+0x19/0x40
   ? mutex_lock+0x12/0x40
   ? dmu_buf_set_user_ie+0x54/0x80 [zfs]
   zfs_znode_sa_init+0xe0/0xf0 [zfs]
   zfs_znode_alloc+0x101/0x700 [zfs]
   ? arc_buf_fill+0x270/0xd30 [zfs]
   ? __cv_init+0x42/0x60 [spl]
   ? dnode_cons+0x28f/0x2a0 [zfs]
   ? _cond_resched+0x19/0x40
   ? _cond_resched+0x19/0x40
   ? mutex_lock+0x12/0x40
   ? aggsum_add+0x153/0x170 [zfs]
   ? spl_kmem_alloc_impl+0xd8/0x110 [spl]
   ? arc_space_consume+0x54/0xe0 [zfs]
   ? dbuf_read+0x4a0/0xb50 [zfs]
   ? _cond_resched+0x19/0x40
   ? mutex_lock+0x12/0x40
   ? dnode_rele_and_unlock+0x5a/0xc0 [zfs]
   ? _cond_resched+0x19/0x40
   ? mutex_lock+0x12/0x40
   ? dmu_object_info_from_dnode+0x84/0xb0 [zfs]
   zfs_zget+0x1c3/0x270 [zfs]
   ? dmu_buf_rele+0x3a/0x40 [zfs]
   zfs_dirent_lock+0x349/0x680 [zfs]
   zfs_dirlook+0x90/0x2a0 [zfs]
   ? zfs_zaccess+0x10c/0x480 [zfs]
   zfs_lookup+0x202/0x3b0 [zfs]
   zpl_lookup+0xca/0x1e0 [zfs]
   path_openat+0x6a2/0xfe0
   do_filp_open+0x9b/0x110
   ? __check_object_size+0xdb/0x1b0
   ? __alloc_fd+0x46/0x170
   do_sys_openat2+0x217/0x2d0
   ? do_sys_openat2+0x217/0x2d0
   do_sys_open+0x59/0x80
   __x64_sys_openat+0x20/0x30

To manage notifications about this bug go to:
https://bugs.launchpad.net/zfs/+bug/1906476/+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 1624540] Re: please have lxd recommend zfs

2021-08-19 Thread Stéphane Graber
Let's close this as our kernels pretty much all support ZFS and LXD is a
snap and therefore does not need additional userspace tools.

** Changed in: zfs-linux (Ubuntu)
   Status: In Progress => Won't Fix

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

Title:
  please have lxd recommend zfs

Status in lxd package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Won't Fix

Bug description:
  Since ZFS is now in Main (Bug #1532198), LXD should recommend the ZFS
  userspace package, such that 'sudo lxd init' just works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1624540/+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 1063354] Re: [Dell Studio XPS 1640] Sudden Read-Only Filesystems

2021-08-19 Thread Stéphane Graber
** Changed in: linux (Ubuntu)
   Status: Incomplete => Won't Fix

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

Title:
  [Dell Studio XPS 1640] Sudden Read-Only Filesystems

Status in linux package in Ubuntu:
  Won't Fix

Bug description:
  After upgrading to ubuntu 12.10, I experience sudden locks of my
  filesystems (I have a root and a home partition with ext4), in which
  the filesystems suddenly become mounted readonly. /var/log/syslog
  shows the following entries:

  Oct  7 20:00:42 StudioXPS signond[3510]: signondaemon.cpp 345 init Failed to 
SUID root. Secure storage will not be available.
  Oct  7 20:02:12 StudioXPS kernel: [  249.193555] ata1.00: exception Emask 0x0 
SAct 0x7 SErr 0x0 action 0x0
  Oct  7 20:02:12 StudioXPS kernel: [  249.193561] ata1.00: irq_stat 0x4001
  Oct  7 20:02:12 StudioXPS kernel: [  249.193565] ata1.00: failed command: 
READ FPDMA QUEUED
  Oct  7 20:02:12 StudioXPS kernel: [  249.193572] ata1.00: cmd 
60/20:00:90:6f:53/00:00:1a:00:00/40 tag 0 ncq 16384 in
  Oct  7 20:02:12 StudioXPS kernel: [  249.193572]  res 
41/40:20:98:6f:53/00:00:1a:00:00/40 Emask 0x409 (media error) 
  Oct  7 20:02:12 StudioXPS kernel: [  249.193575] ata1.00: status: { DRDY ERR }
  Oct  7 20:02:12 StudioXPS kernel: [  249.193578] ata1.00: error: { UNC }
  Oct  7 20:02:12 StudioXPS kernel: [  249.193581] ata1.00: failed command: 
WRITE FPDMA QUEUED
  Oct  7 20:02:12 StudioXPS kernel: [  249.193587] ata1.00: cmd 
61/18:08:18:fb:0e/00:00:2b:00:00/40 tag 1 ncq 12288 out
  Oct  7 20:02:12 StudioXPS kernel: [  249.193587]  res 
41/40:08:98:6f:53/00:00:1a:00:00/40 Emask 0x9 (media error)
  Oct  7 20:02:12 StudioXPS kernel: [  249.193590] ata1.00: status: { DRDY ERR }
  Oct  7 20:02:12 StudioXPS kernel: [  249.193593] ata1.00: error: { UNC }
  Oct  7 20:02:12 StudioXPS kernel: [  249.193596] ata1.00: failed command: 
WRITE FPDMA QUEUED
  Oct  7 20:02:12 StudioXPS kernel: [  249.193602] ata1.00: cmd 
61/d8:10:a0:bd:8b/00:00:0d:00:00/40 tag 2 ncq 110592 out
  Oct  7 20:02:12 StudioXPS kernel: [  249.193602]  res 
41/40:08:98:6f:53/00:00:1a:00:00/40 Emask 0x9 (media error)
  Oct  7 20:02:12 StudioXPS kernel: [  249.193605] ata1.00: status: { DRDY ERR }
  Oct  7 20:02:12 StudioXPS kernel: [  249.193607] ata1.00: error: { UNC }
  Oct  7 20:02:12 StudioXPS kernel: [  249.196606] ata1.00: configured for 
UDMA/100
  Oct  7 20:02:12 StudioXPS kernel: [  249.196622] sd 0:0:0:0: >[sda] Unhandled 
sense code
  Oct  7 20:02:12 StudioXPS kernel: [  249.196624] sd 0:0:0:0: >[sda]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196626] Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
  Oct  7 20:02:12 StudioXPS kernel: [  249.196628] sd 0:0:0:0: >[sda]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196629] Sense Key : Medium Error 
[current] [descriptor]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196633] Descriptor sense data with 
sense descriptors (in hex):
  Oct  7 20:02:12 StudioXPS kernel: [  249.196634] 72 03 11 04 00 00 00 
0c 00 0a 80 00 00 00 00 00
  Oct  7 20:02:12 StudioXPS kernel: [  249.196642] 1a 53 6f 98
  Oct  7 20:02:12 StudioXPS kernel: [  249.196645] sd 0:0:0:0: >[sda]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196648] Add. Sense: Unrecovered read 
error - auto reallocate failed
  Oct  7 20:02:12 StudioXPS kernel: [  249.196650] sd 0:0:0:0: >[sda] CDB:
  Oct  7 20:02:12 StudioXPS kernel: [  249.196651] Read(10): 28 00 1a 53 6f 90 
00 00 20 00
  Oct  7 20:02:12 StudioXPS kernel: [  249.196658] end_request: I/O error, dev 
sda, sector 441675672
  Oct  7 20:02:12 StudioXPS kernel: [  249.196674] sd 0:0:0:0: >[sda] Unhandled 
sense code
  Oct  7 20:02:12 StudioXPS kernel: [  249.196676] sd 0:0:0:0: >[sda]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196678] Result: hostbyte=DID_OK 
driverbyte=DRIVER_SENSE
  Oct  7 20:02:12 StudioXPS kernel: [  249.196679] sd 0:0:0:0: >[sda]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196681] Sense Key : Medium Error 
[current] [descriptor]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196683] Descriptor sense data with 
sense descriptors (in hex):
  Oct  7 20:02:12 StudioXPS kernel: [  249.196684] 72 03 11 04 00 00 00 
0c 00 0a 80 00 00 00 00 00
  Oct  7 20:02:12 StudioXPS kernel: [  249.196692] 1a 53 6f 98
  Oct  7 20:02:12 StudioXPS kernel: [  249.196695] sd 0:0:0:0: >[sda]
  Oct  7 20:02:12 StudioXPS kernel: [  249.196697] Add. Sense: Unrecovered read 
error - auto reallocate failed
  Oct  7 20:02:12 StudioXPS kernel: [  249.196699] sd 0:0:0:0: >[sda] CDB:
  Oct  7 20:02:12 StudioXPS kernel: [  249.196700] Write(10): 2a 00 2b 0e fb 18 
00 00 18 00
  Oct  7 20:02:12 StudioXPS kernel: [  249.196706] end_request: I/O error, dev 
sda, sector 722402072
  Oct  7 20:02:12 StudioXPS kernel: [  249.196710] Buffer I/O error on device 
sda6, logical block 82899555
  Oct  7 20:02:12 StudioXPS kernel: [  249.196718] 

[Kernel-packages] [Bug 1940083] Re: zfs send encrypt causes kernel NULL pointer dereference

2021-08-19 Thread Stéphane Graber
** Changed in: linux (Ubuntu)
   Status: Incomplete => 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/1940083

Title:
  zfs send encrypt causes kernel NULL pointer dereference

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  zfs send -I works well:

  # uname -a
  Linux sdeziel-desktop 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 
15:58:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  # zfs send -I data/simon/musique@laptop-2020-11-30 data/simon/musique@o | wc 
-c
  5660616
  # dmesg -c
  #

  but when sending encrypted data sets, some snapshot combinations cause
  problem:

  # zfs send -wI data/simon/musique@laptop-2020-11-30 data/simon/musique@o | wc 
-c
  # # hung as nothing is written to the pipe.

  # dmesg -c
  [ 1179.862792] BUG: kernel NULL pointer dereference, address: 0030
  [ 1179.862798] #PF: supervisor read access in kernel mode
  [ 1179.862801] #PF: error_code(0x) - not-present page
  [ 1179.862803] PGD 0 P4D 0 
  [ 1179.862806] Oops:  [#5] SMP PTI
  [ 1179.862809] CPU: 1 PID: 13834 Comm: zfs Tainted: P  D   IO  
5.11.0-27-generic #29~20.04.1-Ubuntu
  [ 1179.862813] Hardware name:  /D54250WYK, BIOS 
WYLPT10H.86A.0054.2019.0902.1752 09/02/2019
  [ 1179.862815] RIP: 0010:dmu_dump_write+0x22c/0x320 [zfs]
  [ 1179.862922] Code: d0 48 89 43 58 49 8b 45 60 48 89 43 38 49 8b 45 68 48 89 
43 40 49 8b 45 70 48 89 43 48 49 8b 45 78 48 89 43 50 e9 9f fe ff ff <49> 8b 45 
30 45 85 c0 74 39 48 85 c0 78 04 80 4b 31 02 48 8d 53 70
  [ 1179.862924] RSP: 0018:a51ae62678f0 EFLAGS: 00010206
  [ 1179.862927] RAX: d1141450686f75df RBX: 952730fdde00 RCX: 

  [ 1179.862929] RDX: 80f7 RSI: 0013 RDI: 
952730fddf38
  [ 1179.862931] RBP: a51ae6267938 R08: 0100 R09: 
0002
  [ 1179.862933] R10: 80f7 R11: 0002 R12: 
a51ae6267ab8
  [ 1179.862935] R13:  R14: 0002 R15: 

  [ 1179.862937] FS:  7fa6a03ac7c0() GS:95298fa8() 
knlGS:
  [ 1179.862939] CS:  0010 DS:  ES:  CR0: 80050033
  [ 1179.862941] CR2: 0030 CR3: 00025a648001 CR4: 
001706e0
  [ 1179.862943] Call Trace:
  [ 1179.862945]  ? wait_woken+0x80/0x80
  [ 1179.862951]  do_dump+0x5da/0x900 [zfs]
  [ 1179.863035]  ? spl_kmem_free+0x28/0x30 [spl]
  [ 1179.863046]  dmu_send_impl+0xdf6/0x1570 [zfs]
  [ 1179.863129]  ? dbuf_rele_and_unlock+0x32e/0x6d0 [zfs]
  [ 1179.863204]  ? dbuf_rele+0x3d/0x50 [zfs]
  [ 1179.863279]  ? dmu_buf_rele+0xe/0x10 [zfs]
  [ 1179.863354]  dmu_send_obj+0x24c/0x360 [zfs]
  [ 1179.863435]  ? mze_find+0xd4/0xf0 [zfs]
  [ 1179.863551]  zfs_ioc_send+0x11d/0x2c0 [zfs]
  [ 1179.863665]  ? zfs_ioc_send+0x2c0/0x2c0 [zfs]
  [ 1179.863778]  zfsdev_ioctl_common+0x679/0x930 [zfs]
  [ 1179.863892]  ? __kmalloc_node+0x40d/0x4e0
  [ 1179.863899]  zfsdev_ioctl+0x57/0xe0 [zfs]
  [ 1179.864008]  __x64_sys_ioctl+0x91/0xc0
  [ 1179.864012]  do_syscall_64+0x38/0x90
  [ 1179.864018]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [ 1179.864023] RIP: 0033:0x7fa6a09a050b
  [ 1179.864026] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48
  [ 1179.864028] RSP: 002b:7ffdb9687fb8 EFLAGS: 0246 ORIG_RAX: 
0010
  [ 1179.864032] RAX: ffda RBX: 55dd6be41f60 RCX: 
7fa6a09a050b
  [ 1179.864033] RDX: 7ffdb968b5c0 RSI: 5a1c RDI: 
0003
  [ 1179.864035] RBP: 7ffdb968b580 R08: 5a1c R09: 
0003
  [ 1179.864037] R10: 0009 R11: 0246 R12: 
7ffdb968b5c0
  [ 1179.864038] R13: 55dd6be41f70 R14:  R15: 
0001
  [ 1179.864041] Modules linked in: vhost_vsock 
vmw_vsock_virtio_transport_common vhost vhost_iotlb vsock ccm nf_log_ipv6 
ip6table_filter ip6table_nat ip6t_rpfilter ip6table_mangle ip6table_raw 
ip6_tables nf_log_ipv4 nf_log_common xt_owner xt_LOG xt_conntrack 
iptable_filter xt_MASQUERADE xt_nat xt_tcpudp iptable_nat nf_nat iptable_mangle 
iptable_raw bpfilter nls_iso8859_1 zfs(PO) zunicode(PO) zzstd(O) zlua(O) 
zavl(PO) icp(PO) zcommon(PO) znvpair(PO) intel_rapl_msr spl(O) 
intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio 
x86_pkg_temp_thermal snd_hda_codec_hdmi intel_powerclamp coretemp snd_hda_intel 
snd_intel_dspcfg mei_hdcp kvm_intel soundwire_intel at24 
soundwire_generic_allocation kvm soundwire_cadence snd_hda_codec snd_hda_core 
soundwire_bus crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_soc_core 
rapl snd_usb_audio snd_compress ac97_bus intel_cstate snd_pcm_dmaengine iwldvm 
uvcvideo videobuf2_vmalloc btusb snd_usbmidi_lib btrtl snd_hwdep btbcm mac80211
  [ 

[Kernel-packages] [Bug 1940083] Re: zfs send encrypt causes kernel NULL pointer dereference

2021-08-17 Thread Stéphane Graber
** Package changed: zfs-linux (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/1940083

Title:
  zfs send encrypt causes kernel NULL pointer dereference

Status in linux package in Ubuntu:
  New

Bug description:
  zfs send -I works well:

  # uname -a
  Linux sdeziel-desktop 5.11.0-27-generic #29~20.04.1-Ubuntu SMP Wed Aug 11 
15:58:17 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  # zfs send -I data/simon/musique@laptop-2020-11-30 data/simon/musique@o | wc 
-c
  5660616
  # dmesg -c
  #

  but when sending encrypted data sets, some snapshot combinations cause
  problem:

  # zfs send -wI data/simon/musique@laptop-2020-11-30 data/simon/musique@o | wc 
-c
  # # hung as nothing is written to the pipe.

  # dmesg -c
  [ 1179.862792] BUG: kernel NULL pointer dereference, address: 0030
  [ 1179.862798] #PF: supervisor read access in kernel mode
  [ 1179.862801] #PF: error_code(0x) - not-present page
  [ 1179.862803] PGD 0 P4D 0 
  [ 1179.862806] Oops:  [#5] SMP PTI
  [ 1179.862809] CPU: 1 PID: 13834 Comm: zfs Tainted: P  D   IO  
5.11.0-27-generic #29~20.04.1-Ubuntu
  [ 1179.862813] Hardware name:  /D54250WYK, BIOS 
WYLPT10H.86A.0054.2019.0902.1752 09/02/2019
  [ 1179.862815] RIP: 0010:dmu_dump_write+0x22c/0x320 [zfs]
  [ 1179.862922] Code: d0 48 89 43 58 49 8b 45 60 48 89 43 38 49 8b 45 68 48 89 
43 40 49 8b 45 70 48 89 43 48 49 8b 45 78 48 89 43 50 e9 9f fe ff ff <49> 8b 45 
30 45 85 c0 74 39 48 85 c0 78 04 80 4b 31 02 48 8d 53 70
  [ 1179.862924] RSP: 0018:a51ae62678f0 EFLAGS: 00010206
  [ 1179.862927] RAX: d1141450686f75df RBX: 952730fdde00 RCX: 

  [ 1179.862929] RDX: 80f7 RSI: 0013 RDI: 
952730fddf38
  [ 1179.862931] RBP: a51ae6267938 R08: 0100 R09: 
0002
  [ 1179.862933] R10: 80f7 R11: 0002 R12: 
a51ae6267ab8
  [ 1179.862935] R13:  R14: 0002 R15: 

  [ 1179.862937] FS:  7fa6a03ac7c0() GS:95298fa8() 
knlGS:
  [ 1179.862939] CS:  0010 DS:  ES:  CR0: 80050033
  [ 1179.862941] CR2: 0030 CR3: 00025a648001 CR4: 
001706e0
  [ 1179.862943] Call Trace:
  [ 1179.862945]  ? wait_woken+0x80/0x80
  [ 1179.862951]  do_dump+0x5da/0x900 [zfs]
  [ 1179.863035]  ? spl_kmem_free+0x28/0x30 [spl]
  [ 1179.863046]  dmu_send_impl+0xdf6/0x1570 [zfs]
  [ 1179.863129]  ? dbuf_rele_and_unlock+0x32e/0x6d0 [zfs]
  [ 1179.863204]  ? dbuf_rele+0x3d/0x50 [zfs]
  [ 1179.863279]  ? dmu_buf_rele+0xe/0x10 [zfs]
  [ 1179.863354]  dmu_send_obj+0x24c/0x360 [zfs]
  [ 1179.863435]  ? mze_find+0xd4/0xf0 [zfs]
  [ 1179.863551]  zfs_ioc_send+0x11d/0x2c0 [zfs]
  [ 1179.863665]  ? zfs_ioc_send+0x2c0/0x2c0 [zfs]
  [ 1179.863778]  zfsdev_ioctl_common+0x679/0x930 [zfs]
  [ 1179.863892]  ? __kmalloc_node+0x40d/0x4e0
  [ 1179.863899]  zfsdev_ioctl+0x57/0xe0 [zfs]
  [ 1179.864008]  __x64_sys_ioctl+0x91/0xc0
  [ 1179.864012]  do_syscall_64+0x38/0x90
  [ 1179.864018]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [ 1179.864023] RIP: 0033:0x7fa6a09a050b
  [ 1179.864026] Code: 0f 1e fa 48 8b 05 85 39 0d 00 64 c7 00 26 00 00 00 48 c7 
c0 ff ff ff ff c3 66 0f 1f 44 00 00 f3 0f 1e fa b8 10 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d 55 39 0d 00 f7 d8 64 89 01 48
  [ 1179.864028] RSP: 002b:7ffdb9687fb8 EFLAGS: 0246 ORIG_RAX: 
0010
  [ 1179.864032] RAX: ffda RBX: 55dd6be41f60 RCX: 
7fa6a09a050b
  [ 1179.864033] RDX: 7ffdb968b5c0 RSI: 5a1c RDI: 
0003
  [ 1179.864035] RBP: 7ffdb968b580 R08: 5a1c R09: 
0003
  [ 1179.864037] R10: 0009 R11: 0246 R12: 
7ffdb968b5c0
  [ 1179.864038] R13: 55dd6be41f70 R14:  R15: 
0001
  [ 1179.864041] Modules linked in: vhost_vsock 
vmw_vsock_virtio_transport_common vhost vhost_iotlb vsock ccm nf_log_ipv6 
ip6table_filter ip6table_nat ip6t_rpfilter ip6table_mangle ip6table_raw 
ip6_tables nf_log_ipv4 nf_log_common xt_owner xt_LOG xt_conntrack 
iptable_filter xt_MASQUERADE xt_nat xt_tcpudp iptable_nat nf_nat iptable_mangle 
iptable_raw bpfilter nls_iso8859_1 zfs(PO) zunicode(PO) zzstd(O) zlua(O) 
zavl(PO) icp(PO) zcommon(PO) znvpair(PO) intel_rapl_msr spl(O) 
intel_rapl_common snd_hda_codec_realtek snd_hda_codec_generic ledtrig_audio 
x86_pkg_temp_thermal snd_hda_codec_hdmi intel_powerclamp coretemp snd_hda_intel 
snd_intel_dspcfg mei_hdcp kvm_intel soundwire_intel at24 
soundwire_generic_allocation kvm soundwire_cadence snd_hda_codec snd_hda_core 
soundwire_bus crct10dif_pclmul crc32_pclmul ghash_clmulni_intel snd_soc_core 
rapl snd_usb_audio snd_compress ac97_bus intel_cstate snd_pcm_dmaengine iwldvm 
uvcvideo videobuf2_vmalloc btusb snd_usbmidi_lib btrtl snd_hwdep btbcm mac80211
  [ 1179.864103]  

[Kernel-packages] [Bug 1927108] [NEW] Raspberry Pi kernel config doesn't match generic for NFT, breaks LXD

2021-05-04 Thread Stéphane Graber
Public bug reported:

Reported here: https://github.com/lxc/lxd/issues/8735

After investigation, the issue is:

```
# CONFIG_NFT_FIB_INET is not set
```

As found on current 5.11 raspberry pi kernel.
Generic Ubuntu kernel has:

```
CONFIG_NFT_FIB_INET=m
```

The rest of the config related to nft/netfilter looks identical. I
thought all our kernels were derived from a shared config, any idea how
it's possible that the raspberry pi kernel ended up diverging on this
one?

** Affects: linux-raspi (Ubuntu)
 Importance: Undecided
 Status: New

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

Title:
  Raspberry Pi kernel config doesn't match generic for NFT, breaks LXD

Status in linux-raspi package in Ubuntu:
  New

Bug description:
  Reported here: https://github.com/lxc/lxd/issues/8735

  After investigation, the issue is:

  ```
  # CONFIG_NFT_FIB_INET is not set
  ```

  As found on current 5.11 raspberry pi kernel.
  Generic Ubuntu kernel has:

  ```
  CONFIG_NFT_FIB_INET=m
  ```

  The rest of the config related to nft/netfilter looks identical. I
  thought all our kernels were derived from a shared config, any idea
  how it's possible that the raspberry pi kernel ended up diverging on
  this one?

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-raspi/+bug/1927108/+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 1921969] Re: lxd 2.0.11-0ubuntu1~16.04.4 ADT test failure with linux 4.4.0-207.239

2021-03-30 Thread Stéphane Graber
Confirmed that on a working system, just updating to the new kernel breaks it.
So that SRU kernel is definitely broken and should not be shipped.


[8.996651] BUG: unable to handle kernel NULL pointer dereference at 
e12c1a77
[8.998738] IP: [] fuse_do_setattr+0x52/0x640
[9.000546] PGD 8002717c7067 PUD 270e5d067 PMD 0 
[9.001915] Oops:  [#1] SMP 
[9.003041] Modules linked in: binfmt_misc veth ip6table_filter ip6_tables 
xt_CHECKSUM iptable_mangle xt_comment xt_tcpudp iptable_filter ip_tables 
x_tables kvm_intel kvm irqbypass bridge stp llc joydev input_leds serio_raw 
lpc_ich 9pnet_virtio 9pnet virtio_rng virtio_input shpchp 8250_fintek mac_hid 
ib_iser rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp 
libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 
multipath linear crct10dif_pclmul crc32_pclmul ghash_clmulni_intel virtio_gpu 
ttm aesni_intel drm_kms_helper aes_x86_64 lrw syscopyarea gf128mul glue_helper 
ablk_helper sysfillrect ahci sysimgblt cryptd fb_sys_fops psmouse drm libahci 
virtio_scsi
[9.019982] CPU: 2 PID: 1929 Comm: mount Not tainted 4.4.0-207-generic 
#239-Ubuntu
[9.021887] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)/LXD, BIOS 
0.0.0 02/06/2015
[9.023893] task: b85f1580 ti: 46f8cfc7 task.ti: 
46f8cfc7
[9.025775] RIP: 0010:[]  [] 
fuse_do_setattr+0x52/0x640
[9.027974] RSP: 0018:880272eb7c20  EFLAGS: 00010246
[9.029627] RAX:  RBX: 880272eb7e28 RCX: 000e
[9.031507] RDX:  RSI: 880272eb7e28 RDI: 880272eb7cf8
[9.033447] RBP: 880272eb7d98 R08: 00019580 R09: 8122c764
[9.035159] R10: ea0009cd8400 R11: 88027203c300 R12: 
[9.037004] R13: 880272eb7e28 R14: 88027203c470 R15: 88027203c300
[9.038737] FS:  7f01e82d9840() GS:88027fd0() 
knlGS:
[9.040811] CS:  0010 DS:  ES:  CR0: 80050033
[9.042470] CR2: 0458 CR3: 000273654000 CR4: 00160670
[9.044488] Stack:
[9.045578]  81227c54 880272eb7c84 0001 
00028186639d
[9.047599]  5318e6f4d6b61d94 880272eb7d70 880272eb7d80 
880272eb7d70
[9.049606]   880272eb7cf8 880272eb7cf0 
880270e50320
[9.051576] Call Trace:
[9.052746]  [<4f4fb5e7>] ? lookup_fast+0x184/0x340
[9.054366]  [<4f4fb5e7>] ? lookup_fast+0x184/0x340
[9.055970]  [] ? unlazy_walk+0xc1/0x150
[9.057542]  [] ? terminate_walk+0x66/0xd0
[9.059307]  [<51dc2989>] ? putname+0x54/0x60
[9.060934]  [<5d276838>] fuse_setattr+0xa5/0xf0
[9.062454]  [] notify_change+0x2dc/0x430
[9.064177]  [<8ae20288>] utimes_common+0xd1/0x1b0
[9.065694]  [<3571704c>] do_utimes+0x125/0x160
[9.067102]  [] SyS_utimensat+0x67/0xa0
[9.068721]  [] entry_SYSCALL_64_fastpath+0x22/0xd0
[9.070383] Code: 4c 8b 77 30 65 48 8b 04 25 28 00 00 00 48 89 84 24 48 01 
00 00 31 c0 48 8d bc 24 d8 00 00 00 c7 44 24 14 00 00 00 00 49 8b 46 28 <4c> 8b 
b8 58 04 00 00 31 c0 f3 48 ab 41 0f b6 9f 2c 01 00 00 c0 
[9.076396] RIP  [] fuse_do_setattr+0x52/0x640
[9.078006]  RSP 
[9.079316] CR2: 0458
[9.080677] ---[ end trace 05c28a02c4628343 ]---

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

** Changed in: linux (Ubuntu)
   Importance: Undecided => Critical

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

Title:
  lxd 2.0.11-0ubuntu1~16.04.4 ADT test failure with linux 4.4.0-207.239

Status in linux package in Ubuntu:
  Triaged

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20210331_002001_322ce@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/arm64/l/lxd/20210330_023432_11c32@/log.gz
  i386: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxd/20210331_001905_1aecd@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/lxd/20210331_001557_b82c6@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/l/lxd/20210331_001215_7b9ae@/log.gz


  
  Starting c1
  action=start creation 

[Kernel-packages] [Bug 1921969] Re: lxd 2.0.11-0ubuntu1~16.04.4 ADT test failure with linux 4.4.0-207.239

2021-03-30 Thread Stéphane Graber
When a single test fails occasionally, it can be an issue with LXD or
with the test, but when a bugfix release of a stable kernel suddenly
causes one of the most trivial tests to fail on all architectures, this
strongly suggests that the kernel is the issue.

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

Title:
  lxd 2.0.11-0ubuntu1~16.04.4 ADT test failure with linux 4.4.0-207.239

Status in linux package in Ubuntu:
  New

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20210331_002001_322ce@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/arm64/l/lxd/20210330_023432_11c32@/log.gz
  i386: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxd/20210331_001905_1aecd@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/lxd/20210331_001557_b82c6@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/l/lxd/20210331_001215_7b9ae@/log.gz


  
  Starting c1
  action=start creation date=2021-03-30T02:42:13+ ephemeral=false lvl=eror 
msg="Failed starting container" name=c1 stateful=false 
t=2021-03-30T02:42:14+
  error: Error calling 'lxd forkstart c1 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/containers 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/logs/c1/lxc.conf': 
err='Failed to run: /usr/bin/lxd forkstart c1 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/containers 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/logs/c1/lxc.conf: '
lxc 20210330024214.649 ERROR lxc_conf - conf.c:run_buffer:286 - Script 
exited with status 137.
lxc 20210330024214.649 ERROR lxc_conf - conf.c:lxc_setup:3356 - failed to 
run mount hooks for container 'c1'.
lxc 20210330024214.649 ERROR lxc_start - start.c:do_start:1248 - Failed to 
setup container "c1".
lxc 20210330024214.649 ERROR lxc_sync - sync.c:__sync_wait:59 - An error 
occurred in another process (expected sequence number 5)
lxc 20210330024214.662 ERROR lxc_start - start.c:__lxc_start:1802 - Failed 
to spawn container "c1".
lxc 20210330024214.663 ERROR lxc_container - 
lxccontainer.c:wait_on_daemonized_start:804 - Received container state 
"ABORTING" instead of "RUNNING"

  Try `lxc info --show-log lxd2:c1` for more info
  ==> Cleaning up
  ==> Killing LXD at /tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/zOt
  ==> Deleting all containers
  ==> Deleting all images
  ==> Deleting all profiles
  Profile default deleted
  Profile docker deleted
  ==> Checking for locked DB tables
  ==> Checking for leftover files
  ==> Checking for leftover DB entries
  ==> Tearing down directory backend in 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/zOt
  ==> Killing LXD at /tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt
  ==> Deleting all containers
  ==> Deleting all images
  ==> Deleting all profiles
  Profile default deleted
  Profile docker deleted
  ==> Checking for locked DB tables
  ==> Checking for leftover files
  ==> Checking for leftover DB entries
  ==> Tearing down directory backend in 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt

  
  ==> TEST DONE: remote usage
  ==> Test result: failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921969/+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 1921969] Re: lxd 2.0.11-0ubuntu1~16.04.4 ADT test failure with linux 4.4.0-207.239

2021-03-30 Thread Stéphane Graber
This looks like a kernel regression to me.

** Package changed: lxd (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/1921969

Title:
  lxd 2.0.11-0ubuntu1~16.04.4 ADT test failure with linux 4.4.0-207.239

Status in linux package in Ubuntu:
  New

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/lxd/20210331_002001_322ce@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/arm64/l/lxd/20210330_023432_11c32@/log.gz
  i386: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/i386/l/lxd/20210331_001905_1aecd@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/ppc64el/l/lxd/20210331_001557_b82c6@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/s390x/l/lxd/20210331_001215_7b9ae@/log.gz


  
  Starting c1
  action=start creation date=2021-03-30T02:42:13+ ephemeral=false lvl=eror 
msg="Failed starting container" name=c1 stateful=false 
t=2021-03-30T02:42:14+
  error: Error calling 'lxd forkstart c1 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/containers 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/logs/c1/lxc.conf': 
err='Failed to run: /usr/bin/lxd forkstart c1 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/containers 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt/logs/c1/lxc.conf: '
lxc 20210330024214.649 ERROR lxc_conf - conf.c:run_buffer:286 - Script 
exited with status 137.
lxc 20210330024214.649 ERROR lxc_conf - conf.c:lxc_setup:3356 - failed to 
run mount hooks for container 'c1'.
lxc 20210330024214.649 ERROR lxc_start - start.c:do_start:1248 - Failed to 
setup container "c1".
lxc 20210330024214.649 ERROR lxc_sync - sync.c:__sync_wait:59 - An error 
occurred in another process (expected sequence number 5)
lxc 20210330024214.662 ERROR lxc_start - start.c:__lxc_start:1802 - Failed 
to spawn container "c1".
lxc 20210330024214.663 ERROR lxc_container - 
lxccontainer.c:wait_on_daemonized_start:804 - Received container state 
"ABORTING" instead of "RUNNING"

  Try `lxc info --show-log lxd2:c1` for more info
  ==> Cleaning up
  ==> Killing LXD at /tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/zOt
  ==> Deleting all containers
  ==> Deleting all images
  ==> Deleting all profiles
  Profile default deleted
  Profile docker deleted
  ==> Checking for locked DB tables
  ==> Checking for leftover files
  ==> Checking for leftover DB entries
  ==> Tearing down directory backend in 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/zOt
  ==> Killing LXD at /tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt
  ==> Deleting all containers
  ==> Deleting all images
  ==> Deleting all profiles
  Profile default deleted
  Profile docker deleted
  ==> Checking for locked DB tables
  ==> Checking for leftover files
  ==> Checking for leftover DB entries
  ==> Tearing down directory backend in 
/tmp/autopkgtest.mceqas/build.1QA/src/test/tmp.MBH/dyt

  
  ==> TEST DONE: remote usage
  ==> Test result: failure

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1921969/+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 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-08-24 Thread Stéphane Graber
We weren't planning to as the previous releases (xenial and bionic) did
not have "-kvm" image and their default image includes an initrd making
them boot just fine under LXD.

So it's really just groovy+focal that we need before we can start using those 
images.
focal has been taken care of so we're just waiting for linux-kvm to hit the 
release pocket on groovy before we can switch over to those.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Released

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - 

[Kernel-packages] [Bug 1884767] Re: shiftfs: fix btrfs regression

2020-08-03 Thread Stéphane Graber
** Changed in: linux (Ubuntu)
   Status: In Progress => 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/1884767

Title:
  shiftfs: fix btrfs regression

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Eoan:
  Fix Released

Bug description:
  SRU Justification

  Impact: The patch
  commit cfaa482afb97e3c05d020af80b897b061109d51f
  Author: Christian Brauner 
  Date:   Tue Apr 14 22:26:53 2020 +0200

  UBUNTU: SAUCE: shiftfs: fix dentry revalidation

  BugLink: https://bugs.launchpad.net/bugs/1872757

  to fix https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757
  regresses various btrfs + shiftfs users. Creating a btrfs subvolume,
  deleting it, and then trying to recreate it will cause EEXIST to be returned.
  It also leaves some files in a half-visible state because they are not 
revalidated
  correctly.
  Faulty behavior such as this can be reproduced via:

  btrfs subvolume create my-subvol
  btrfs subvolume delete my-subvol

  Fix: We need to revert this patch restoring the old behavior. This will 
briefly
  resurface https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 which 
I will fix in a follow-up patch on top of this revert. We basically split the 
part that fixes https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872757 
out of the revert.

  Regression Potential: Limited to shiftfs.

  Test Case: Build a kernel with fix applied and run above reproducer.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1884767/+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 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-27 Thread Stéphane Graber
Confirmed, 1018 boots fine here under Secure Boot, all good!

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

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-27 Thread Stéphane Graber
@smb what's the state of groovy, did you push the config update there
too?

For the cloud images, we'll want to switch over to those using linux-kvm
in groovy first, then focal, so just want to make sure we'll get a
working kernel on there too!

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 

[Kernel-packages] [Bug 1874519] Re: ZFS installation on Raspberry Pi is problematic

2020-06-23 Thread Stéphane Graber
Good to hear. I just ran into this today when working on a LXD appliance based 
on Ubuntu Core.
btrfs isn't exactly great as an alternative and the 8GB Pi is definitely ZFS 
capable so would be great to have :)

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

Title:
  ZFS installation on Raspberry Pi is problematic

Status in zfs-linux package in Ubuntu:
  Triaged

Bug description:
  Version: Ubuntu Server 20.04 - preinstalled 64-bit image for Raspberry
  Pi.

  ZFS on the Pi under 20.04 is currently a bit problematic. Upon issuing
  the command 'zpool status', I'm helpfully directed to install
  zfsutils-linux. When I do this, it complains that it cannot find the
  ZFS module, then errors out. Worse than that, the zfsutils-linux
  package does not depend on the zfs-dkms package, so it doesn't attempt
  to build the ZFS kernel modules automatically.

  The workaround is to install zfs-dkms, which builds the required
  kernel modules. (Once this has been done, the usual errors when
  installing the zfsutils-linux package, caused by there being no ZFS
  pools on the system, can be worked around by creating a zpool, then
  rerunning 'sudo apt install zfsutils-linux', as with previous versions
  of Ubuntu and Debian).

  I have not tested on other hardware platforms - this problem may also
  exist on other platforms where the user has not selected to install to
  ZFS.

  I have selected 'zfsutils' as the affected package, which is not the
  name of an actual current package, since launchpad won't let me submit
  the bug without selecting a package, however it's not clear to me that
  the problem is caused by that package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/zfs-linux/+bug/1874519/+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 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
It's not the log above clearly shows the kernel loading an initrd.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find image based 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
"""
stgraber@castiana:~$ lxc launch images:ubuntu/focal f1 --vm
Creating f1
Starting f1
stgraber@castiana:~$ lxc exec f1 bash
root@f1:~# echo "deb http://archive.ubuntu.com/ubuntu focal-proposed main 
restricted universe multiverse" >> /etc/apt/sources.list
root@f1:~# apt-get update
Hit:1 http://archive.ubuntu.com/ubuntu focal InRelease
Get:2 http://archive.ubuntu.com/ubuntu focal-updates InRelease [107 kB]
Get:3 http://security.ubuntu.com/ubuntu focal-security InRelease [107 kB]
Get:4 http://archive.ubuntu.com/ubuntu focal-proposed InRelease [265 kB]
Get:5 http://archive.ubuntu.com/ubuntu focal-updates/main amd64 Packages [201 
kB]
Get:6 http://archive.ubuntu.com/ubuntu focal-updates/main Translation-en [80.2 
kB]
Get:7 http://archive.ubuntu.com/ubuntu focal-updates/restricted amd64 Packages 
[11.1 kB]
Get:8 http://archive.ubuntu.com/ubuntu focal-updates/restricted Translation-en 
[3036 B]
Get:9 http://archive.ubuntu.com/ubuntu focal-updates/universe amd64 Packages 
[114 kB]
Get:10 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages 
[82.4 kB]
Get:11 http://archive.ubuntu.com/ubuntu focal-proposed/main Translation-en 
[35.0 kB]
Get:12 http://archive.ubuntu.com/ubuntu focal-proposed/restricted amd64 
Packages [7132 B]
Get:13 http://archive.ubuntu.com/ubuntu focal-proposed/restricted 
Translation-en [2144 B]
Get:14 http://archive.ubuntu.com/ubuntu focal-proposed/universe amd64 Packages 
[35.8 kB]
Get:15 http://archive.ubuntu.com/ubuntu focal-proposed/universe Translation-en 
[24.5 kB]
Get:16 http://archive.ubuntu.com/ubuntu focal-proposed/multiverse 
Translation-en [3404 B]
Fetched 1079 kB in 1s (794 kB/s)   
Reading package lists... Done
root@f1:~# apt-get install linux-kvm
Reading package lists... Done
Building dependency tree   
Reading state information... Done
The following additional packages will be installed:
  linux-headers-5.4.0-1017-kvm linux-headers-kvm linux-image-5.4.0-1017-kvm 
linux-image-kvm linux-kvm-headers-5.4.0-1017 linux-modules-5.4.0-1017-kvm
Suggested packages:
  fdutils linux-kvm-doc-5.4.0 | linux-kvm-source-5.4.0 linux-kvm-tools
The following NEW packages will be installed:
  linux-headers-5.4.0-1017-kvm linux-headers-kvm linux-image-5.4.0-1017-kvm 
linux-image-kvm linux-kvm linux-kvm-headers-5.4.0-1017
  linux-modules-5.4.0-1017-kvm
0 upgraded, 7 newly installed, 0 to remove and 18 not upgraded.
Need to get 28.4 MB of archives.
After this operation, 126 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
linux-kvm-headers-5.4.0-1017 all 5.4.0-1017.17 [11.3 MB]
Get:2 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
linux-headers-5.4.0-1017-kvm amd64 5.4.0-1017.17 [1254 kB]
Get:3 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
linux-headers-kvm amd64 5.4.0.1017.16 [4376 B]
Get:4 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
linux-modules-5.4.0-1017-kvm amd64 5.4.0-1017.17 [10.6 MB]
Get:5 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
linux-image-5.4.0-1017-kvm amd64 5.4.0-1017.17 [5158 kB]
Get:6 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 
linux-image-kvm amd64 5.4.0.1017.16 [ B]
Get:7 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 linux-kvm 
amd64 5.4.0.1017.16 [4416 B]
Fetched 28.4 MB in 2s (14.2 MB/s)
Selecting previously unselected package linux-kvm-headers-5.4.0-1017.
(Reading database ... 46372 files and directories currently installed.)
Preparing to unpack .../0-linux-kvm-headers-5.4.0-1017_5.4.0-1017.17_all.deb ...
Unpacking linux-kvm-headers-5.4.0-1017 (5.4.0-1017.17) ...
Selecting previously unselected package linux-headers-5.4.0-1017-kvm.
Preparing to unpack .../1-linux-headers-5.4.0-1017-kvm_5.4.0-1017.17_amd64.deb 
...
Unpacking linux-headers-5.4.0-1017-kvm (5.4.0-1017.17) ...
Selecting previously unselected package linux-headers-kvm.
Preparing to unpack .../2-linux-headers-kvm_5.4.0.1017.16_amd64.deb ...
Unpacking linux-headers-kvm (5.4.0.1017.16) ...
Selecting previously unselected package linux-modules-5.4.0-1017-kvm.
Preparing to unpack .../3-linux-modules-5.4.0-1017-kvm_5.4.0-1017.17_amd64.deb 
...
Unpacking linux-modules-5.4.0-1017-kvm (5.4.0-1017.17) ...
Selecting previously unselected package linux-image-5.4.0-1017-kvm.
Preparing to unpack .../4-linux-image-5.4.0-1017-kvm_5.4.0-1017.17_amd64.deb ...
Unpacking linux-image-5.4.0-1017-kvm (5.4.0-1017.17) ...
Selecting previously unselected package linux-image-kvm.
Preparing to unpack .../5-linux-image-kvm_5.4.0.1017.16_amd64.deb ...
Unpacking linux-image-kvm (5.4.0.1017.16) ...
Selecting previously unselected package linux-kvm.
Preparing to unpack .../6-linux-kvm_5.4.0.1017.16_amd64.deb ...
Unpacking linux-kvm (5.4.0.1017.16) ...
Setting up linux-kvm-headers-5.4.0-1017 (5.4.0-1017.17) ...
Setting up linux-modules-5.4.0-1017-kvm (5.4.0-1017.17) ...
Setting up linux-headers-5.4.0-1017-kvm 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
https://paste.ubuntu.com/p/7yHDCFt75m/ for additional proof that the
initrd is never executed (break=top would immediately drop to a shell).

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
@smb Can you confirm that your system indeed goes through the initrd and
isn't just silently falling back to directly mounting and booting /?

Booting with break=mount would likely be a valid way to test this
(should drop you in a shell).

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
Hmm, actually no luck at booting either 1015 or 1017 on
security.secureboot=false here, poked at grub and it does load both
kernel and initrd...

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
"""
Loading Linux 5.4.0-1015-kvm ...
Loading initial ramdisk ...
Linux version 5.4.0-1015-kvm (buildd@lcy01-amd64-027) (gcc version 9.3.0 
(Ubuntu 9.3.0-10ubuntu2)) #15-Ubuntu SMP Fri Jun 5 00:55:20 UTC 2020 (Ubuntu 
5.4.0-1015.15-kvm 5.4.41)
Command line: BOOT_IMAGE=/boot/vmlinuz-5.4.0-1015-kvm 
root=UUID=03167f19-fb7f-4ba9-b4da-5e4acc0d97e3 ro single nomodeset
x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers'
x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers'
x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers'
x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers'
x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR'
x86/fpu: xstate_offset[2]:  576, xstate_sizes[2]:  256
x86/fpu: xstate_offset[3]:  832, xstate_sizes[3]:   64
x86/fpu: xstate_offset[4]:  896, xstate_sizes[4]:   64
x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 
'compacted' format.
BIOS-provided physical RAM map:
BIOS-e820: [mem 0x-0x0009] usable
BIOS-e820: [mem 0x0010-0x3ee6afff] usable
BIOS-e820: [mem 0x3ee6b000-0x3ef2bfff] reserved
BIOS-e820: [mem 0x3ef2c000-0x3f8eefff] usable
BIOS-e820: [mem 0x3f8ef000-0x3faeefff] reserved
BIOS-e820: [mem 0x3faef000-0x3fb75fff] usable
BIOS-e820: [mem 0x3fb76000-0x3fb7efff] ACPI data
BIOS-e820: [mem 0x3fb7f000-0x3fbfefff] ACPI NVS
BIOS-e820: [mem 0x3fbff000-0x3ffd] usable
BIOS-e820: [mem 0x3ffe-0x3fff] reserved
BIOS-e820: [mem 0xb000-0xbfff] reserved
BIOS-e820: [mem 0xffe0-0x] reserved
NX (Execute Disable) protection: active
extended physical RAM map:
reserve setup_data: [mem 0x-0x0009] usable
reserve setup_data: [mem 0x0010-0x3df4b017] usable
reserve setup_data: [mem 0x3df4b018-0x3df86457] usable
reserve setup_data: [mem 0x3df86458-0x3df87017] usable
reserve setup_data: [mem 0x3df87018-0x3df90a57] usable
reserve setup_data: [mem 0x3df90a58-0x3ee6afff] usable
reserve setup_data: [mem 0x3ee6b000-0x3ef2bfff] reserved
reserve setup_data: [mem 0x3ef2c000-0x3f8eefff] usable
reserve setup_data: [mem 0x3f8ef000-0x3faeefff] reserved
reserve setup_data: [mem 0x3faef000-0x3fb75fff] usable
reserve setup_data: [mem 0x3fb76000-0x3fb7efff] ACPI data
reserve setup_data: [mem 0x3fb7f000-0x3fbfefff] ACPI NVS
reserve setup_data: [mem 0x3fbff000-0x3ffd] usable
reserve setup_data: [mem 0x3ffe-0x3fff] reserved
reserve setup_data: [mem 0xb000-0xbfff] reserved
reserve setup_data: [mem 0xffe0-0x] reserved
efi: EFI v2.70 by EDK II
efi:  SMBIOS=0x3f915000  ACPI=0x3fb7e000  ACPI 2.0=0x3fb7e014  
MEMATTR=0x3e115118 
secureboot: Secure boot disabled
SMBIOS 2.8 present.
DMI: QEMU Standard PC (Q35 + ICH9, 2009)/LXD, BIOS 0.0.0 02/06/2015
Hypervisor detected: KVM
kvm-clock: Using msrs 4b564d01 and 4b564d00
kvm-clock: cpu 0, msr 14630001, primary cpu clock
kvm-clock: using sched offset of 4626558194 cycles
clocksource: kvm-clock: mask: 0x max_cycles: 0x1cd42e4dffb, 
max_idle_ns: 881590591483 ns
tsc: Detected 2712.000 MHz processor
last_pfn = 0x3ffe0 max_arch_pfn = 0x4
x86/PAT: Configuration [0-7]: WB  WT  UC- UC  WB  WT  UC- UC  
Using GB pages for direct mapping
secureboot: Secure boot disabled
RAMDISK: [mem 0x2c111000-0x2cbadfff]
ACPI: Early table checksum verification disabled
ACPI: RSDP 0x3FB7E014 24 (v02 BOCHS )
ACPI: XSDT 0x3FB7D0E8 4C (v01 BOCHS  BXPCFACP 0001  
0113)
ACPI: FACP 0x3FB7A000 F4 (v03 BOCHS  BXPCFACP 0001 BXPC 
0001)
ACPI: DSDT 0x3FB7B000 001E86 (v01 BOCHS  BXPCDSDT 0001 BXPC 
0001)
ACPI: FACS 0x3FBDD000 40
ACPI: APIC 0x3FB79000 78 (v01 BOCHS  BXPCAPIC 0001 BXPC 
0001)
ACPI: HPET 0x3FB78000 38 (v01 BOCHS  BXPCHPET 0001 BXPC 
0001)
ACPI: MCFG 0x3FB77000 3C (v01 BOCHS  BXPCMCFG 0001 BXPC 
0001)
ACPI: BGRT 0x3FB76000 38 (v01 INTEL  EDK2 0002  
0113)
No NUMA configuration found
Faking a node at [mem 0x-0x3ffd]
NODE_DATA(0) allocated [mem 0x3ff8-0x3ff82fff]
Zone ranges:
  DMA32[mem 0x1000-0x3ffd]
  Normal   empty
Movable zone start for each node
Early memory node ranges
  node   0: [mem 0x1000-0x0009]
  node   0: [mem 0x0010-0x3ee6afff]
  node   0: [mem 0x3ef2c000-0x3f8eefff]
  node   0: [mem 0x3faef000-0x3fb75fff]
  node   0: [mem 0x3fbff000-0x3ffd]
Zeroed struct page in 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-23 Thread Stéphane Graber
Yeah, I think you're right, I also had the exact same panic happen now
on 1015, so it's likely some grub weirdness rather than kernel
regression.

It just so happened that in my last test I managed to get a working grub
config after moving to 1015 and not with 1017. Looks like we'll need to
poke at grub...

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-18 Thread Stéphane Graber
@Stefan, so actually this is an actual regression.

1015 will boot just fine in LXD with secureboot disabled.
1017 will not boot at all in LXD with or without secureboot disabled.

I don't know if it's switching to a signed kernel which causes the lz4
issue but the result is a clear regression so I would not consider this
kernel suitable for release to anyone.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - 

[Kernel-packages] [Bug 1835660] Re: initramfs unpacking failed

2020-06-18 Thread Stéphane Graber
All LXD virtual machines are hitting this too.

Run:
 - lxc launch images:ubuntu/focal/cloud f1 && lxc console f1

And you'll see it show that message. As mentioned above, boot then still
goes ahead and you get a login prompt, but as that may not always be the
case.

For example in linux-kvm, that fallback mechanism doesn't appear to work and we 
instead get a kernel panic unless we've manually modified the initrd to be gzip:
https://bugs.launchpad.net/cloud-images/+bug/1873809

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

Title:
  initramfs unpacking failed

Status in initramfs-tools package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Confirmed

Bug description:
  "initramfs unpacking failed: Decoding failed",  message appears on
  boot up.

  If I "update-initramfs" using gzip instead of lz, then boot up passes
  without decoding failed message.

  ---

  However, we currently believe that the decoding error reported in
  dmesg is actually harmless and has no impact on usability on the
  system.

  Switching from lz4 to gzip compression, simply papers over the
  warning, without any benefits, and slows down boot.

  Kernel should be fixed to correctly parse lz4 compressed initrds, or
  at least lower the warning, to not be user visible as an error.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1835660/+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 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-18 Thread Stéphane Graber
"""
Jun 18 13:56:15 f1 kernel: [0.383207] Trying to unpack rootfs image as 
initramfs...
Jun 18 13:56:15 f1 kernel: [0.463102] Initramfs unpacking failed: Decoding 
failed
"""

Is what we're getting on current generic kernel, though boot continues after 
that.
I don't know if when that happens we're actually skipping the initrd entirely 
and just get lucky that the generic kernel has everything we need builtin so it 
boots or if the error in that case is just wrong and the initrd is still 
properly unpacked and run.

Either way, this needs sorting, looking at the other bug report, there's
been something wrong with our kernel and lz4 initrd for a long time and
it's apparently biting us a lot more now.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-18 Thread Stéphane Graber
Trying to boot the proposed kernel in LXD:

"""
BdsDxe: loading Boot0007 "ubuntu" from 
HD(1,GPT,25633192-5DBD-412A-8A50-E29B79F72A50,0x800,0x32000)/\EFI\ubuntu\shimx64.efi
BdsDxe: starting Boot0007 "ubuntu" from 
HD(1,GPT,25633192-5DBD-412A-8A50-E29B79F72A50,0x800,0x32000)/\EFI\ubuntu\shimx64.efi
RAMDISK: incomplete write (4194304 != 8388608)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-1017-kvm #17-Ubuntu
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009)/LXD, BIOS 0.0.0 02/06/2015
Call Trace:
 0x9392230d
 0x932a8a21
 0x9412e5c1
 0x9412e80f
 0x9412e976
 0x9412e274
 ? 0x93938a70
 0x93938a79
 0x93a00215
Kernel Offset: 0x1220 from 0x8100 (relocation range: 
0x8000-0xbfff)
---[ end Kernel panic - not syncing: VFS: Unable to mount root fs on 
unknown-block(0,0) ]---
"""


This appears to be lz4 related. Changing the initramfs to gzip makes the VM 
boot just fine.
It's worth noting that when booting the generic kernel, we get the unpack error 
showed in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1835660 but 
things still boot fine.

Marking verification as failed based on this. We need images to work
properly with a standard Ubuntu config so need lz4 fixed.

** Tags removed: verification-needed-focal
** Tags added: verification-failed-focal

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged
Status in linux-kvm source package in Focal:
  Fix Committed

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " 

[Kernel-packages] [Bug 1882955] [NEW] LXD 4.2 broken on linux-kvm due to missing VLAN filtering

2020-06-10 Thread Stéphane Graber
Public bug reported:

This is another case of linux-kvm having unexplained differences
compared to linux-generic in areas that aren't related to hardware
drivers (see other bug we filed for missing nft).

This time, CPC is reporting that LXD no longer works on linux-kvm as we
now set vlan filtering on our bridges to prevent containers from
escaping firewalling through custom vlan tags.

This relies on CONFIG_BRIDGE_VLAN_FILTERING which is a built-in on the
generic kernel but is apparently missing on linux-kvm (I don't have any
system running that kernel to confirm its config, but the behavior
certainly matches that).

We need this fixed in focal and groovy.

** Affects: linux-kvm (Ubuntu)
 Importance: Undecided
 Status: Triaged

** Changed in: linux-kvm (Ubuntu)
   Status: New => Triaged

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

Title:
  LXD 4.2 broken on linux-kvm due to missing VLAN filtering

Status in linux-kvm package in Ubuntu:
  Triaged

Bug description:
  This is another case of linux-kvm having unexplained differences
  compared to linux-generic in areas that aren't related to hardware
  drivers (see other bug we filed for missing nft).

  This time, CPC is reporting that LXD no longer works on linux-kvm as
  we now set vlan filtering on our bridges to prevent containers from
  escaping firewalling through custom vlan tags.

  This relies on CONFIG_BRIDGE_VLAN_FILTERING which is a built-in on the
  generic kernel but is apparently missing on linux-kvm (I don't have
  any system running that kernel to confirm its config, but the behavior
  certainly matches that).

  We need this fixed in focal and groovy.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-kvm/+bug/1882955/+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 1645037] Re: apparmor_parser hangs indefinitely when called by multiple threads

2020-06-01 Thread Stéphane Graber
** No longer affects: apparmor (Ubuntu)

** No longer affects: linux (Ubuntu 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/1645037

Title:
  apparmor_parser hangs indefinitely when called by multiple threads

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Yakkety:
  Won't Fix
Status in linux source package in Zesty:
  Fix Released

Bug description:
  This bug surfaced when starting ~50 LXC container with LXD in parallel
  multiple times:

  # Create the containers
  for c in c foo{1..50}; do lxc launch images:ubuntu/xenial $c; done

  # Exectute this loop multiple times until you observe errors.
  for c in c foo{1..50}; do lxc restart $c & done

  After this you can

  ps aux | grep apparmor

  and you should see output similar to:

  root 19774  0.0  0.0  12524  1116 pts/1S+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
  root 19775  0.0  0.0  12524  1208 pts/1S+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
  root 19776  0.0  0.0  13592  3224 pts/1D+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo30
  root 19778  0.0  0.0  13592  3384 pts/1D+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo26
  root 19780  0.0  0.0  12524  1208 pts/1S+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
  root 19782  0.0  0.0  12524  1208 pts/1S+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
  root 19783  0.0  0.0  13592  3388 pts/1D+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo43
  root 19784  0.0  0.0  13592  3252 pts/1D+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo34
  root 19794  0.0  0.0  12524  1208 pts/1S+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo25
  root 19795  0.0  0.0  13592  3256 pts/1D+   20:14   0:00 
apparmor_parser -RWL /var/lib/lxd/security/apparmor/cache 
/var/lib/lxd/security/apparmor/profiles/lxd-foo25

  apparmor_parser remains stuck even after all LXC/LXD commands have
  exited.

  dmesg output yields lines like:

  [41902.815174] audit: type=1400 audit(1480191089.678:43):
  apparmor="STATUS" operation="profile_load" profile="unconfined" name
  ="lxd-foo30_" pid=12545 comm="apparmor_parser"

  and cat /proc/12545/stack shows:

  [] aa_remove_profiles+0x88/0x270
  21:19   brauner  [] profile_remove+0x144/0x2e0
  21:19   brauner  [] __vfs_write+0x18/0x40
  21:19   brauner  [] vfs_write+0xb8/0x1b0
  21:19   brauner  [] SyS_write+0x55/0xc0
  21:19   brauner  [] entry_SYSCALL_64_fastpath+0x1e/0xa8
  21:19   brauner  [] 0x

  This looks like a potential kernel bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1645037/+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 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-06-01 Thread Stéphane Graber
Pinged in #ubuntu-kernel today for an update. It'd be good to have
groovy signed soon so we can then roll this out to focal users.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find image 

[Kernel-packages] [Bug 1648143] Re: tor in lxd: apparmor="DENIED" operation="change_onexec" namespace="root//CONTAINERNAME_" profile="unconfined" name="system_tor"

2020-06-01 Thread Stéphane Graber
** Changed in: apparmor (Ubuntu)
   Status: Confirmed => Invalid

** No longer affects: apparmor (Ubuntu Xenial)

** No longer affects: apparmor (Ubuntu Yakkety)

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

Title:
  tor in lxd: apparmor="DENIED" operation="change_onexec"
  namespace="root//CONTAINERNAME_" profile="unconfined"
  name="system_tor"

Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Fix Released
Status in tor package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  Fix Released
Status in tor source package in Xenial:
  Invalid
Status in linux source package in Yakkety:
  Fix Released
Status in tor source package in Yakkety:
  Invalid

Bug description:
  Environment:
  

  Distribution: ubuntu
  Distribution version: 16.10
  lxc info:
  apiextensions:

  storage_zfs_remove_snapshots
  container_host_shutdown_timeout
  container_syscall_filtering
  auth_pki
  container_last_used_at
  etag
  patch
  usb_devices
  https_allowed_credentials
  image_compression_algorithm
  directory_manipulation
  container_cpu_time
  storage_zfs_use_refquota
  storage_lvm_mount_options
  network
  profile_usedby
  container_push
  apistatus: stable
  apiversion: "1.0"
  auth: trusted
  environment:
  addresses:
  163.172.48.149:8443
  172.20.10.1:8443
  172.20.11.1:8443
  172.20.12.1:8443
  172.20.22.1:8443
  172.20.21.1:8443
  10.8.0.1:8443
  architectures:
  x86_64
  i686
  certificate: |
  -BEGIN CERTIFICATE-
  -END CERTIFICATE-
  certificatefingerprint: 
3048baa9f20d316f60a6c602452b58409a6d9e2c3218897e8de7c7c72af0179b
  driver: lxc
  driverversion: 2.0.5
  kernel: Linux
  kernelarchitecture: x86_64
  kernelversion: 4.8.0-27-generic
  server: lxd
  serverpid: 32694
  serverversion: 2.4.1
  storage: btrfs
  storageversion: 4.7.3
  config:
  core.https_address: '[::]:8443'
  core.trust_password: true

  Container: ubuntu 16.10

  
  Issue description
  --

  
  tor can't start in a non privileged container

  
  Logs from the container:
  -

  Dec 7 15:03:00 anonymous tor[302]: Configuration was valid
  Dec 7 15:03:00 anonymous systemd[303]: tor@default.service: Failed at step 
APPARMOR spawning /usr/bin/tor: No such file or directory
  Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Main process 
exited, code=exited, status=231/APPARMOR
  Dec 7 15:03:00 anonymous systemd[1]: Failed to start Anonymizing overlay 
network for TCP.
  Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Unit entered failed 
state.
  Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed with result 
'exit-code'.
  Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Service hold-off 
time over, scheduling restart.
  Dec 7 15:03:00 anonymous systemd[1]: Stopped Anonymizing overlay network for 
TCP.
  Dec 7 15:03:00 anonymous systemd[1]: tor@default.service: Failed to reset 
devices.list: Operation not permitted
  Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on 
/system.slice/system-tor.slice/tor@default.service: Operation not permitted
  Dec 7 15:03:00 anonymous systemd[1]: message repeated 6 times: [ Failed to 
set devices.allow on /system.slice/system-tor.slice/tor@default.service: 
Operation not permitted]
  Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device 
/run/systemd/inaccessible/chr
  Dec 7 15:03:00 anonymous systemd[1]: Couldn't stat device 
/run/systemd/inaccessible/blk
  Dec 7 15:03:00 anonymous systemd[1]: Failed to set devices.allow on 
/system.slice/system-tor.slice/tor@default.service: Operation not permitted


  Logs from the host
  

  audit: type=1400 audit(1481119378.856:6950): apparmor="DENIED" 
operation="change_onexec" info="label not found" error=-2 
namespace="root//lxd-anonymous_" profile="unconfined" name="system_tor" 
  pid=12164 comm="(tor)"

  
  Steps to reproduce
  -

  install ubuntu container 16.10 on a ubuntu 16.10 host
  install tor in the container
  Launch tor

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1648143/+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 1881346] Re: linux-kvm should support nftables

2020-05-29 Thread Stéphane Graber
Right, I've sent a tweak to LXD upstream to detect such kernel setup and
fallback to xtables, but that's obviously not a situation we'd like to
rely on.

nftables is the current supported way of doing firewalling and is what
Ubuntu uses by default (through shim packages) as of 20.04, so we need
to ensure that all our kernels support it.

Easy fix would be to align CONFIG_NFT* to what we have in generic. If
that increases size too much, then I guess we can look at trimming
things a bit to only include the usually bits we need (ipv4, ipv6, nat,
mangling, mac filtering, ...).

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

Title:
  linux-kvm should support nftables

Status in linux-kvm package in Ubuntu:
  New

Bug description:
  LXD can't use nftables on the latest linux-kvm kernels for eoan,
  focal, and groovy:

  - groovy: 5.4.0.1009.9
  - focal: 5.4.0-1011.11
  - eoan: 5.3.0.1017.19

  LXD detects that nft tools are available, and nft tables can be
  listed; however, trying to create a new table or rule fails.

  Because of this, LXD has to fall back on xtables, which is a legacy
  package.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux-kvm/+bug/1881346/+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 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-05-26 Thread Stéphane Graber
Re-opening as I'm not seeing any mention of this being signed now.

** Changed in: linux-kvm (Ubuntu)
   Status: Fix Released => Triaged

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find 

[Kernel-packages] [Bug 1879690] Re: Docker registry doesn't stay up and keeps restarting

2020-05-21 Thread Stéphane Graber
/var/log/audit.log on Suse logs the same:

type=AVC msg=audit(1590086639.489:8595): apparmor="DENIED"
operation="open" profile="snap.docker.dockerd" name="/entrypoint.sh"
pid=5656 comm="entrypoint.sh" requested_mask="r" denied_mask="r" fsuid=0
ouid=0

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

Title:
  Docker registry doesn't stay up and keeps restarting

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]
  The change applied for bug 1857257 and its followup fix bug 1876645, which 
were released on focal and eoan -updates, introduced a regression on overlayfs, 
breaking docker snap.

  [Test case]
  See original bug report.

  [Fix]
  While we don't have a final fix the solution for now is to revert the 
following commits:

  UBUNTU: SAUCE: overlayfs: fix shitfs special-casing
  UBUNTU: SAUCE: overlayfs: use shiftfs hacks only with shiftfs as underlay

  [Regression potential]
  Low. Reverting these two commits will introduce back the issue reported on 
bug 1857257, but will fix the other use cases which was broken by the latest 
release.

  
  Original bug report.
  ---
  Tested kernels:
  Focal 5.4.0-31.35
  Eoan 5.3.0-53.47

  To reproduce:
  1) Spin up a cloud image
  2) snap install docker
  3) auth_folder=/var/snap/docker/common/auth
  4) mkdir -p $auth_folder
  5) docker run --entrypoint htpasswd registry:2 -Bbn user passwd > 
$auth_folder/htpasswd
  6) docker run -d -p 5000:5000 --restart=always --name registry \
    -v $auth_folder:/auth \
    -e "REGISTRY_AUTH=htpasswd" \
    -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
    -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
     registry:2

  On a good kernel 'docker ps' shows something like:
  # docker ps
  CONTAINER IDIMAGE   COMMAND  CREATED  
   STATUS  PORTSNAMES
  a346b65b4509registry:2  "/entrypoint.sh /etc…"   14 seconds 
ago  Up 12 seconds   0.0.0.0:5000->5000/tcp   registry

  On a bad kernel:
   docker ps
  CONTAINER IDIMAGE   COMMAND  CREATED  
   STATUSPORTS   NAMES
  0322374f1b1dregistry:2  "/entrypoint.sh /etc…"   5 seconds 
ago   Restarting (2) 1 second ago   registry

  Note status 'Restarting' on the bad kernel.

  This seems to be introduce by any of the following commits:
  b3bdda24f1bc UBUNTU: SAUCE: overlayfs: fix shitfs special-casing
  6f18a8434050 UBUNTU: SAUCE: overlayfs: use shiftfs hacks only with shiftfs as 
underlay
  629edd70891c UBUNTU: SAUCE: shiftfs: record correct creator credentials
  cfaa482afb97 UBUNTU: SAUCE: shiftfs: fix dentry revalidation

  Kernels that don't have these commits seem fine.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1879690/+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 1879690] Re: Docker registry doesn't stay up and keeps restarting

2020-05-21 Thread Stéphane Graber
To confirm that this isn't shiftfs related and that we were just causing
the issue to be hidden, I've run the same test on OpenSuse tumbleweed.

I chose that distro because it's apparmor-enabled, has snapd and a 5.4
kernel.

```
localhost:~ # snap install docker
docker 18.09.9 from Canonical* installed
localhost:~ # auth_folder=/var/snap/docker/common/auth
localhost:~ # mkdir -p $auth_folder
localhost:~ # docker run --entrypoint htpasswd registry:2 -Bbn user passwd > 
$auth_folder/htpasswd
Unable to find image 'registry:2' locally
2: Pulling from library/registry
486039affc0a: Pulling fs layer
ba51a3b098e6: Pulling fs layer
8bb4c43d6c8e: Pulling fs layer
6f5f453e5f2d: Pulling fs layer
42bc10b72f42: Pulling fs layer
6f5f453e5f2d: Waiting
42bc10b72f42: Waiting
ba51a3b098e6: Download complete
486039affc0a: Verifying Checksum
486039affc0a: Download complete
8bb4c43d6c8e: Verifying Checksum
8bb4c43d6c8e: Download complete
6f5f453e5f2d: Verifying Checksum
6f5f453e5f2d: Download complete
42bc10b72f42: Verifying Checksum
42bc10b72f42: Download complete
486039affc0a: Pull complete
ba51a3b098e6: Pull complete
8bb4c43d6c8e: Pull complete
6f5f453e5f2d: Pull complete
42bc10b72f42: Pull complete
Digest: sha256:7d081088e4bfd632a88e3f3bcd9e007ef44a796fddfe3261407a3f9f04abe1e7
Status: Downloaded newer image for registry:2
localhost:~ # docker run -d -p 5000:5000 --restart=always --name registry \
>   -v $auth_folder:/auth \
>   -e "REGISTRY_AUTH=htpasswd" \
>   -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
>   -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
>registry:2
cba1ec94734a8a198fa0c474d9873233958fad6cdafe93d2ccf4d701ecab55ff
localhost:~ # docker ps
CONTAINER IDIMAGE   COMMAND  CREATED
 STATUS  PORTS   NAMES
cba1ec94734aregistry:2  "/entrypoint.sh /etc…"   5 seconds ago  
 Restarting (2) Less than a second ago   registry
localhost:~ # uname -a
Linux localhost 5.4.10-1-default #1 SMP Thu Jan 9 15:45:45 UTC 2020 (556a6fe) 
x86_64 x86_64 x86_64 GNU/Linux
localhost:~ # 
```

As you can see, the exact same thing happen there. So this is an
apparmor kernel bug or some issue  with the snapd or docker snap, this
isn't a shiftfs bug and reverting the change would just expose a
different bug rather than actually fix things.

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

Title:
  Docker registry doesn't stay up and keeps restarting

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Eoan:
  Fix Committed
Status in linux source package in Focal:
  Fix Committed

Bug description:
  [Impact]
  The change applied for bug 1857257 and its followup fix bug 1876645, which 
were released on focal and eoan -updates, introduced a regression on overlayfs, 
breaking docker snap.

  [Test case]
  See original bug report.

  [Fix]
  While we don't have a final fix the solution for now is to revert the 
following commits:

  UBUNTU: SAUCE: overlayfs: fix shitfs special-casing
  UBUNTU: SAUCE: overlayfs: use shiftfs hacks only with shiftfs as underlay

  [Regression potential]
  Low. Reverting these two commits will introduce back the issue reported on 
bug 1857257, but will fix the other use cases which was broken by the latest 
release.

  
  Original bug report.
  ---
  Tested kernels:
  Focal 5.4.0-31.35
  Eoan 5.3.0-53.47

  To reproduce:
  1) Spin up a cloud image
  2) snap install docker
  3) auth_folder=/var/snap/docker/common/auth
  4) mkdir -p $auth_folder
  5) docker run --entrypoint htpasswd registry:2 -Bbn user passwd > 
$auth_folder/htpasswd
  6) docker run -d -p 5000:5000 --restart=always --name registry \
    -v $auth_folder:/auth \
    -e "REGISTRY_AUTH=htpasswd" \
    -e "REGISTRY_AUTH_HTPASSWD_REALM=Registry Realm" \
    -e REGISTRY_AUTH_HTPASSWD_PATH=/auth/htpasswd \
     registry:2

  On a good kernel 'docker ps' shows something like:
  # docker ps
  CONTAINER IDIMAGE   COMMAND  CREATED  
   STATUS  PORTSNAMES
  a346b65b4509registry:2  "/entrypoint.sh /etc…"   14 seconds 
ago  Up 12 seconds   0.0.0.0:5000->5000/tcp   registry

  On a bad kernel:
   docker ps
  CONTAINER IDIMAGE   COMMAND  CREATED  
   STATUSPORTS   NAMES
  0322374f1b1dregistry:2  "/entrypoint.sh /etc…"   5 seconds 
ago   Restarting (2) 1 second ago   registry

  Note status 'Restarting' on the bad kernel.

  This seems to be introduce by any of the following commits:
  b3bdda24f1bc UBUNTU: SAUCE: overlayfs: fix shitfs special-casing
  6f18a8434050 UBUNTU: SAUCE: overlayfs: use shiftfs hacks only with shiftfs as 
underlay
  

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-05-05 Thread Stéphane Graber
@Khaled yes, it is and we have it now. What's still needed is for the
kernel to be signed so it can be used under secureboot.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find image based on 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-04-21 Thread Stéphane Graber
Ok, fixed the bug tasks and re-opened the bug as we still need this
kernel to get signed.

** Changed in: linux-kvm (Ubuntu)
   Status: Fix Released => Triaged

** Changed in: cloud-images
 Assignee: Roufique Hossain (roufique) => (unassigned)

** Changed in: linux-kvm (Ubuntu)
 Assignee: Roufique Hossain (roufique) => (unassigned)

** Changed in: cloud-bl-tutorials
   Status: Confirmed => Invalid

** Changed in: cloud-bl-tutorials
   Status: Invalid => New

** Changed in: cloud-bl-tutorials
 Remote watch: Email to roufique@rtat # => None

** Project changed: cloud-bl-tutorials => linux (Ubuntu)

** No longer affects: linux (Ubuntu)

** Changed in: cloud-images
   Status: Confirmed => Invalid

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  Triaged

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-04-21 Thread Stéphane Graber
Hmm, actually, CONFIG_EFI_STUB is the one we were missing and I'm not
seeing that in your VM either, which makes me wonder how it was booted
in the first place :)

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in Cloud-Bio-Linux Tutorials:
  Confirmed
Status in cloud-images:
  Confirmed
Status in linux-kvm package in Ubuntu:
  Fix Released

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-04-21 Thread Stéphane Graber
Thanks Louis, so our testing may in fact have been accurate and things
regressed afterwards :)

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in Cloud-Bio-Linux Tutorials:
  Confirmed
Status in cloud-images:
  Confirmed
Status in linux-kvm package in Ubuntu:
  Fix Released

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
  

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-04-20 Thread Stéphane Graber
Just tested it now, confirmed that this still boots fine and that this
time the LXD agent successfully starts too.

So this config seems suitable for us. That + enabling kernel signing
will get us working images.

Thanks!

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  New

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, currently completely fail to boot under UEFI.

  A workaround was put in place such that LXD instead will pull generic-
  based images until this is resolved, this however does come with a
  much longer boot time (as the kernel panics, reboots and then boots)
  and also reduced functionality from cloud-init, so we'd still like
  this fixed in the near future.

  To get things behaving, it looks like we need the following config
  options to be enable in linux-kvm:

   - CONFIG_EFI_STUB
   - CONFIG_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS
   - CONFIG_VIRTIO_VSOCKETS_COMMON

  == Rationale ==
  We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.

  We also need the LXD agent to work, which requires functional virtio
  vsock.

  == Test case ==
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
   - lxc launch bug1873809 v1
   - lxc console v1
   - 
   - 
   - lxc exec v1 bash

  To validate a new kernel, you'll need to manually repack the .img file
  and install the new kernel in there.

  == Regression potential ==
  I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.

  Also, this will be introducing virtio vsock support which again, could
  maybe confused some horribly broken systems?

  
  In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.

  
  -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 

[Kernel-packages] [Bug 1873809] Re: Make linux-kvm bootable in LXD VMs

2020-04-20 Thread Stéphane Graber
** Description changed:

  The `disk-kvm.img` images which are to be preferred when run under
- virtualization, completely fail to boot under UEFI.
+ virtualization, currently completely fail to boot under UEFI.
  
- This is a critical issue as those are the images that LXD is now pulling
- by default.
+ A workaround was put in place such that LXD instead will pull generic-
+ based images until this is resolved, this however does come with a much
+ longer boot time (as the kernel panics, reboots and then boots) and also
+ reduced functionality from cloud-init, so we'd still like this fixed in
+ the near future.
  
+ To get things behaving, it looks like we need the following config
+ options to be enable in linux-kvm:
+ 
+  - CONFIG_EFI_STUB
+  - CONFIG_VSOCKETS
+  - CONFIG_VIRTIO_VSOCKETS
+  - CONFIG_VIRTIO_VSOCKETS_COMMON
+ 
+ == Rationale ==
+ We'd like to be able to use the linux-kvm based images for LXD, those will 
directly boot without needing the panic+reboot behavior of generic images and 
will be much lighter in general.
+ 
+ We also need the LXD agent to work, which requires functional virtio
+ vsock.
+ 
+ == Test case ==
+  - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-lxd.tar.xz
+  - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
+  - lxc image import focal-server-cloudimg-amd64-lxd.tar.xz 
focal-server-cloudimg-amd64-disk-kvm.img --alias bug1873809
+  - lxc launch bug1873809 v1
+  - lxc console v1
+  - 
+  - 
+  - lxc exec v1 bash
+ 
+ To validate a new kernel, you'll need to manually repack the .img file
+ and install the new kernel in there.
+ 
+ == Regression potential ==
+ I don't know who else is using those kvm images right now, but those changes 
will cause a change to the kernel binary such that it contains the EFI stub 
bits + a signature. This could cause some (horribly broken) systems to no 
longer be able to boot that kernel. Though considering that such a setup is 
common to our other kernels, this seems unlikely.
+ 
+ Also, this will be introducing virtio vsock support which again, could
+ maybe confused some horribly broken systems?
+ 
+ 
+ In either case, the kernel conveniently is the only package which ships 
multiple versions concurently, so rebooting on the previous kernel is always an 
option, mitigating some of the risks.
+ 
+ 
+ -- Details from original report --
  User report on the LXD side: https://github.com/lxc/lxd/issues/7224
  
- Note that the non optimized images boot just fine (disk1.img).
- 
- 
  I've reproduced this issue with:
-  - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
-  - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G
- 
+  - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
+  - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G
  
  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.
  
  Switching to the text console view (serial0), you'll see the same issue
  as that LXD report:
  
  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 

[Kernel-packages] [Bug 1873809] Re: disk-kvm.img aren't UEFI bootable

2020-04-20 Thread Stéphane Graber
Marking cloud-images side of this as Invalid since the images themselves are 
built correctly.
Re-packing with an updated kernel boots just fine, so we only need to track 
this against linux-kvm.

** Changed in: cloud-images
   Status: New => Invalid

** Summary changed:

- disk-kvm.img aren't UEFI bootable
+ Make linux-kvm bootable in LXD VMs

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  New

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, completely fail to boot under UEFI.

  This is a critical issue as those are the images that LXD is now
  pulling by default.

  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  Note that the non optimized images boot just fine (disk1.img).

  
  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  
  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find image based on IP(0x3FF2DA12) 
/build/edk2-dQLD17/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
 (ImageBase=3FF1E000, EntryPoint=3FF30781) 


  If booting in a SecureBoot enabled environment, you instead get a
  `Access Denied` at kernel loading time, indicating that the kernel
  binary isn't a normal signed kernel. That has the same result (boot
  hangs) but without the crash message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1873809/+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 1873809] Re: disk-kvm.img aren't UEFI bootable

2020-04-20 Thread Stéphane Graber
I've tested a kernel with CONFIG_EFI_STUB added (thanks cking!).

This does boot with secureboot enabled, though the LXD agent fails to
start due to lack of vsock.

So in addition to CONFIG_EFI_STUB, it looks like we also need:
 - CONFIG_VSOCKETS
 - CONFIG_VIRTIO_VSOCKETS
 - CONFIG_VIRTIO_VSOCKETS_COMMON

Which should give us the bits needed for virtio vsock.

The rest all looked good, so we should be fine with those tweaks and the
kernel getting signed.

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

Title:
  Make linux-kvm bootable in LXD VMs

Status in cloud-images:
  Invalid
Status in linux-kvm package in Ubuntu:
  New

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, completely fail to boot under UEFI.

  This is a critical issue as those are the images that LXD is now
  pulling by default.

  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  Note that the non optimized images boot just fine (disk1.img).

  
  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  
  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find image based on IP(0x3FF2DA12) 
/build/edk2-dQLD17/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
 (ImageBase=3FF1E000, EntryPoint=3FF30781) 


  If booting in a SecureBoot enabled environment, you instead get a
  `Access Denied` at kernel loading time, indicating that the kernel
  binary isn't a normal signed kernel. That has the same result (boot
  hangs) but without the crash message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1873809/+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 1873809] Re: disk-kvm.img aren't UEFI bootable

2020-04-20 Thread Stéphane Graber
Ok, so the fact that we thought this worked is clearly the result from
bad testing on our part, probably because of our simplestreams parsing
code we fixed yesterday...

We obviously still need to move LXD onto this images as booting the non-
kvm images takes twice as long as it should (due to them panic + reboot
every time) AND also breaks cloud-init, at least in the way we'd like to
use it.


Now realistically this can't be fixed in time for 20.04, so what we've done is 
submitted a change to simplestreams to force all LXD users onto the non-kvm 
image:
  
https://code.launchpad.net/~stgraber/simplestreams/+git/simplestreams/+merge/382597

We'll also tell all users of `ubuntu:` and `ubuntu-daily:` that they need to do:
 - lxc config device add NAME config disk source=cloud-init:config

Which passes a stable config drive to cloud-init, avoiding the cloud-
init issue they'd be getting out of the box.


Moving forward, we'd like the -kvm kernel to be both EFI enabled AND signed. 
This will then allow those images to work properly inside LXD, at which point 
we can undo the simplestreams change and have those images used once again by 
our users.

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

Title:
  disk-kvm.img aren't UEFI bootable

Status in cloud-images:
  New
Status in linux-kvm package in Ubuntu:
  New

Bug description:
  The `disk-kvm.img` images which are to be preferred when run under
  virtualization, completely fail to boot under UEFI.

  This is a critical issue as those are the images that LXD is now
  pulling by default.

  User report on the LXD side: https://github.com/lxc/lxd/issues/7224

  Note that the non optimized images boot just fine (disk1.img).

  
  I've reproduced this issue with:
   - wget 
http://cloud-images.ubuntu.com/focal/current/focal-server-cloudimg-amd64-disk-kvm.img
   - qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -hda 
focal-server-cloudimg-amd64-disk-kvm.img -m 1G

  
  On the graphical console, you'll see EDK2 load (TianoCore) followed by basic 
boot messages and then a message from grub (error: can't find command 
`hwmatch`).
  Those also appear on successful boots of other images so I don't think 
there's anything concerning that. However it'll hang indefinitely and eat up 
all your CPU.

  Switching to the text console view (serial0), you'll see the same
  issue as that LXD report:

  BdsDxe: failed to load Boot0001 "UEFI QEMU DVD-ROM QM3 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Secondary,Master,0x0): Not Found
  BdsDxe: loading Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  BdsDxe: starting Boot0002 "UEFI QEMU HARDDISK QM1 " from 
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
  error: can't find command `hwmatch'.
  e X64 Exception Type - 0D(#GP - General Protection)  CPU Apic ID - 
 
  ExceptionData - 
  RIP  - 3FF2DA12, CS  - 0038, RFLAGS - 00200202
  RAX  - AFAFAFAFAFAFAFAF, RCX - 3E80F108, RDX - AFAFAFAFAFAFAFAF
  RBX  - 0398, RSP - 3FF1C638, RBP - 3FF34360
  RSI  - 3FF343B8, RDI - 1000
  R8   - 3E80F108, R9  - 3E815B98, R10 - 0065
  R11  - 2501, R12 - 0004, R13 - 3E80F100
  R14  - , R15 - 
  DS   - 0030, ES  - 0030, FS  - 0030
  GS   - 0030, SS  - 0030
  CR0  - 80010033, CR2 - , CR3 - 3FC01000
  CR4  - 0668, CR8 - 
  DR0  - , DR1 - , DR2 - 
  DR3  - , DR6 - 0FF0, DR7 - 0400
  GDTR - 3FBEEA98 0047, LDTR - 
  IDTR - 3F2D8018 0FFF,   TR - 
  FXSAVE_STATE - 3FF1C290
   Find image based on IP(0x3FF2DA12) 
/build/edk2-dQLD17/edk2-0~20191122.bd85bf54/Build/OvmfX64/RELEASE_GCC5/X64/MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll
 (ImageBase=3FF1E000, EntryPoint=3FF30781) 


  If booting in a SecureBoot enabled environment, you instead get a
  `Access Denied` at kernel loading time, indicating that the kernel
  binary isn't a normal signed kernel. That has the same result (boot
  hangs) but without the crash message.

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-images/+bug/1873809/+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 1684481] Re: KVM guest execution start apparmor blocks on /dev/ptmx now (regression?)

2020-03-25 Thread Stéphane Graber
** Changed in: lxc (Ubuntu)
   Status: Fix Committed => 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/1684481

Title:
  KVM guest execution start apparmor blocks on /dev/ptmx now
  (regression?)

Status in apparmor package in Ubuntu:
  Won't Fix
Status in linux package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released
Status in lxd package in Ubuntu:
  Invalid

Bug description:
  Setup:
  - Xenial host
  - lxd guests with Trusty, Xenial, ...
  - add a LXD profile to allow kvm [3] (inspired by stgraber)
  - spawn KVM guests in the LXD guests using the different distro release 
versions
  - guests are based on the uvtool default template which has a serial console 
[4]

  Issue:
  - guest starting with serial device gets blocked by apparmor and killed on 
creation
  - This affects at least ppc64el and x86 (s390x has no serial concept that 
would match)
  - This appeared in our usual checks on -proposed releases so maybe we 
can/should stop something?
Last good was "Apr 5, 2017 10:40:50 AM" first bad one "Apr 8, 2017 5:11:22 
AM"

  Background:
  We use this setup for a while and it was working without a change on our end.
  Also the fact that it still works in the Trusty LXD makes it somewhat 
suspicious.
  Therefore I'd assume an SRUed change in LXD/Kernel/Apparmor might be the 
reason and open this bug to get your opinion on it.

  You can look into [1] and search for uvt-kvm create in it.

  Deny in dmesg:
  [652759.606218] audit: type=1400 audit(1492671353.134:4520): 
apparmor="DENIED" operation="open" 
namespace="root//lxd-testkvm-xenial-from_" 
profile="libvirt-668e21f1-fa55-4a30-b325-0ed5cfd55e5b" name="/dev/pts/ptmx" 
pid=27162 comm="qemu-system-ppc" requested_mask="wr" denied_mask="wr" fsuid=0 
ouid=0

  Qemu-log:
  2017-04-20T06:55:53.139450Z qemu-system-ppc64: -chardev pty,id=charserial0: 
Failed to create PTY: No such file or directory

  There was a similar issue on qmeu namespacing (which we don't use on any of 
these releases) [2].
  While we surely don't have the "same" issue the debugging on the namespacing 
might be worth as it could be related.

  Workaround for now:
  - drop serial section from guest xml

  [1]: 
https://jenkins.ubuntu.com/server/view/Virt/job/virt-migration-cross-release-amd64/78/consoleFull
  [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1421036
  [3]: 
https://git.launchpad.net/~ubuntu-server/ubuntu/+source/qemu-migration-test/tree/kvm_profile.yaml
  [4]: https://libvirt.org/formatdomain.html#elementsCharPTY
  --- 
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: ppc64el
  DistroRelease: Ubuntu 16.04
  NonfreeKernelModules: zfs zunicode zcommon znvpair zavl
  Package: lxd
  PackageArchitecture: ppc64el
  ProcKernelCmdline: root=UUID=902eaad1-2164-4f9a-bec4-7ff3abc15804 ro 
console=hvc0
  ProcLoadAvg: 3.15 3.02 3.83 1/3056 79993
  ProcSwaps:
   Filename TypeSizeUsedPriority
   /swap.img   file 8388544 0   -1
  ProcVersion: Linux version 4.4.0-72-generic (buildd@bos01-ppc64el-022) (gcc 
version 5.4.0 20160609 (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.4) ) #93-Ubuntu SMP Fri 
Mar 31 14:05:15 UTC 2017
  ProcVersionSignature: Ubuntu 4.4.0-72.93-generic 4.4.49
  Syslog:
   
  Tags:  xenial uec-images
  Uname: Linux 4.4.0-72-generic ppc64le
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups: utah
  _MarkForUpload: True
  cpu_cores: Number of cores present = 20
  cpu_coreson: Number of cores online = 20
  cpu_smt: SMT is off
  --- 
  ApportVersion: 2.20.1-0ubuntu2.5
  Architecture: ppc64el
  DistroRelease: Ubuntu 16.04
  NonfreeKernelModules: cfg80211 ebtable_broute ebtable_nat binfmt_misc veth 
nbd openvswitch vhost_net vhost macvtap macvlan xt_conntrack ipt_REJECT 
nf_reject_ipv4 ebtable_filter ebtables ip6t_MASQUERADE nf_nat_masquerade_ipv6 
ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6 ip6table_filter 
ip6_tables xt_comment xt_CHECKSUM iptable_mangle ipt_MASQUERADE 
nf_nat_masquerade_ipv4 iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 
nf_nat nf_conntrack xt_tcpudp bridge stp llc iptable_filter ip_tables x_tables 
zfs zunicode zcommon znvpair spl zavl kvm_hv kvm ipmi_powernv ipmi_msghandler 
uio_pdrv_genirq vmx_crypto powernv_rng ibmpowernv leds_powernv uio ib_iser 
rdma_cm iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp 
libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456 async_raid6_recov 
async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c raid1 raid0 
multipath linear ses enclosure mlx4_en vxlan ip6_udp_tunnel udp_tunnel 
mlx4_core ipr
  Package: lxd
  PackageArchitecture: ppc64el
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   LANG=C.UTF-8
   SHELL=/bin/bash
  ProcKernelCmdline: root=UUID=902eaad1-2164-4f9a-bec4-7ff3abc15804 ro 
console=hvc0
  

[Kernel-packages] [Bug 1527374] Re: CVE-2015-8709

2020-03-25 Thread Stéphane Graber
** No longer affects: lxc (Ubuntu)

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

Title:
  CVE-2015-8709

Status in linux package in Ubuntu:
  Fix Released
Status in linux-armadaxp package in Ubuntu:
  Confirmed
Status in linux-flo package in Ubuntu:
  Confirmed
Status in linux-goldfish package in Ubuntu:
  Confirmed
Status in linux-lts-quantal package in Ubuntu:
  Won't Fix
Status in linux-lts-raring package in Ubuntu:
  Won't Fix
Status in linux-lts-saucy package in Ubuntu:
  Won't Fix
Status in linux-lts-utopic package in Ubuntu:
  Fix Released
Status in linux-lts-vivid package in Ubuntu:
  Fix Released
Status in linux-lts-wily package in Ubuntu:
  Fix Released
Status in linux-lts-xenial package in Ubuntu:
  New
Status in linux-mako package in Ubuntu:
  Confirmed
Status in linux-manta package in Ubuntu:
  Confirmed
Status in linux-raspi2 package in Ubuntu:
  Fix Released
Status in linux-snapdragon package in Ubuntu:
  New
Status in linux-ti-omap4 package in Ubuntu:
  Confirmed
Status in linux source package in Precise:
  Invalid
Status in linux-lts-trusty source package in Precise:
  Fix Released
Status in linux source package in Trusty:
  Fix Released
Status in linux source package in Vivid:
  Fix Released
Status in linux source package in Wily:
  Fix Released
Status in linux source package in Xenial:
  Fix Released

Bug description:
  ** DISPUTED ** kernel/ptrace.c in the Linux kernel through 4.4.1
  mishandles uid and gid mappings, which allows local users to gain
  privileges by establishing a user namespace, waiting for a root
  process to enter that namespace with an unsafe uid or gid, and then
  using the ptrace system call.  NOTE: the vendor states "there is no
  kernel bug here."

  Break-Fix: - local-2015-8709

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1527374/+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 1530617] Re: FUSE in wily image with upstart installed causes chaos

2020-03-25 Thread Stéphane Graber
** Changed in: lxc (Ubuntu)
   Status: Confirmed => Invalid

** Changed in: upstart (Ubuntu)
   Status: New => Won't Fix

** 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/1530617

Title:
  FUSE in wily image with upstart installed causes chaos

Status in linux package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Invalid
Status in upstart package in Ubuntu:
  Won't Fix

Bug description:
  Host:
  DISTRIB_ID=Ubuntu
  DISTRIB_RELEASE=15.10
  DISTRIB_CODENAME=wily
  DISTRIB_DESCRIPTION="Ubuntu 15.10"

  lxc version: 1.1.4-0ubuntu1

  In a LXC container running Ubuntu 15.10, install upstart-sysv to
  replace systemd. Using FUSE then causes almost all processes in the
  container to be killed.

  The following steps reproduce the problem using sshfs:

  # create a wily container and attach to it
  sudo lxc-create -t download -n wily -- -d ubuntu -r wily -a amd64
  sudo lxc-start -n wily
  sudo lxc-attach -n wily

  # inside the container, install upstart-sysv and reboot
  apt-get update && apt-get -y install upstart-sysv
  reboot

  # on the host, reattach to the container
  sudo lxc-attach -n wily

  # back in the container, install ssh and sshfs
  apt-get -y install openssh-server sshfs

  # create an ssh key pair in /root/.ssh
  ssh-keygen

  # set up passwordless ssh
  mkdir ~ubuntu/.ssh
  cat /root/.ssh/id_rsa.pub >> ~ubuntu/.ssh/authorized_keys
  eval $(ssh-agent)
  ssh-add /root/.ssh/id_rsa

  # take a note of the running processes and their PIDs
  ps axjf

  # run sshfs
  mkdir /fuse
  sshfs ubuntu@localhost:/ /fuse

  # we are kicked out of the container
  # run ps again in the container
  sudo lxc-attach -n wily -- ps axjf

  # a whole bunch of processes are now gone. the getty processes now
  have new PIDs, indicating they have been restarted.

  
  Other debugging performed:
  - On a 14.10 host with lxc version 1.1.0~alpha2-0ubuntu3.3, the problem does 
not occur. FUSE works fine.
  - On the same 14.10 host with lxc upgraded to 1.1.5-0ubuntu3~ubuntu14.04.1, 
the problem occurs.
  - On a 15.10 host, when running a wily container without upstart, the problem 
does not occur.
  - On a 15.10 host, when running a trusty container, the problem does not 
occur.
  - The problem can't be reproduced outside a container (15.10 host, install 
upstart-sysv, then use FUSE)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1530617/+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 1858389] Re: lxd won't restart a container

2020-03-21 Thread Stéphane Graber
Moved the bug over to the kernel.

Those log messages are caused by reference issues in a network namespace
preventing it from being flushed, in turn preventing the LXC monitor
from exiting, holding everything up.

** Package changed: lxd (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/1858389

Title:
  lxd won't restart a container

Status in linux package in Ubuntu:
  New

Bug description:
  During the upgrade of a container from xenial to bionic, the container
  stopped working after the reboot.

  In an manual attempt to start the container:
  # lxc start juju-3fae13-25-lxd-6 
  error: Monitor is hung

  There are no failures reported in lxd/lxc related log files

  The dmesg does give some possibly related lines:
  [24085329.749762] unregister_netdevice: waiting for eth2 to become free. 
Usage count = 1
  [24085339.874547] unregister_netdevice: waiting for eth2 to become free. 
Usage count = 1
  [24085349.931433] unregister_netdevice: waiting for eth2 to become free. 
Usage count = 1
  [24085360.136221] unregister_netdevice: waiting for eth2 to become free. 
Usage count = 1
  [24085370.329020] unregister_netdevice: waiting for eth2 to become free. 
Usage count = 1

  
  I could find that eth2 got renamed quite a few time:
  dmesg | grep eth2 | grep renamed
  [   10.974225] i40e :02:00.2 eno3: renamed from eth2
  [   38.168206] eth2: renamed from vethX6IXIX
  [   39.528396] eth1: renamed from veth2L8Q43
  [   39.544217] eth2: renamed from vethCL4RR8
  [   42.132600] eth0: renamed from veth27ILVJ
  [   42.184425] eth2: renamed from vethGV30Y9
  [   43.332523] eth2: renamed from veth38IOJO
  [   44.553249] eth2: renamed from vethYWPS85
  [   47.696816] eth2: renamed from vethRS5NIA
  [12244954.658741] eth0: renamed from veth23WYKR
  [12244954.712483] eth2: renamed from vethXKHJAY
  [21391530.547187] eth2: renamed from vethON24JW
  [21392047.344985] eth2: renamed from vethBHEXYH
  [21852338.859877] eth2: renamed from veth44669K

  
  Kernel running:
  uname -a
  Linux openstack-9 4.4.0-143-generic #169-Ubuntu SMP Thu Feb 7 07:56:38 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux

  lxd running:
  dpkg -l | grep lxd
  ii  lxd   2.0.11-0ubuntu1~16.04.4 
amd64Container hypervisor based on LXC - daemon
  ii  lxd-client2.0.11-0ubuntu1~16.04.4 
amd64Container hypervisor based on LXC - client

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1858389/+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 1864303] Re: Removing the e1000e module causes a crash

2020-02-22 Thread Stéphane Graber
** Changed in: linux-5.4 (Ubuntu)
   Status: New => Confirmed

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

Title:
  Removing the e1000e module causes a crash

Status in linux-5.4 package in Ubuntu:
  Confirmed

Bug description:
  I have a Lenovo x1 Carbon Gen5 and when it initially came out if you
  left the onboard NIC (e1000e) module loaded it would suck CPU/battery
  life so I have it removed in rc.local on boot.

  In 5.4 (also happens on 5.4.0.15.18 which I'm running from proposed
  right now), this is what happens when the module is unloaded:

  [  608.979789] e1000e :00:1f.6 enp0s31f6: removed PHC
  [  609.008352] [ cut here ]
  [  609.008353] kernel BUG at drivers/pci/msi.c:375!
  [  609.008358] invalid opcode:  [#1] SMP PTI
  [  609.008359] CPU: 0 PID: 6829 Comm: rmmod Tainted: P   O  
5.4.0-15-generic #18-Ubuntu
  [  609.008360] Hardware name: LENOVO 20HRCTO1WW/20HRCTO1WW, BIOS N1MET59W 
(1.44 ) 11/25/2019
  [  609.008364] RIP: 0010:free_msi_irqs+0x17d/0x1b0
  [  609.008365] Code: 84 df fe ff ff 45 31 f6 eb 11 41 83 c6 01 44 39 73 14 0f 
86 cc fe ff ff 8b 7b 10 44 01 f7 e8 ea c3 b6 ff 48 83 78 70 00 74 e0 <0f> 0b 49 
8d b5 b0 00 00 00 e8 b5 7d b7 ff e9 cd fe ff ff 49 8b 78
  [  609.008366] RSP: 0018:a7d2072f7d40 EFLAGS: 00010286
  [  609.008367] RAX: 8bc9bfb49e00 RBX: 8bc9ad69c720 RCX: 

  [  609.008368] RDX:  RSI: 0084 RDI: 
a9e65980
  [  609.008369] RBP: a7d2072f7d70 R08: 8bc9bb564db0 R09: 
8bc9bb564df8
  [  609.008369] R10:  R11: a9e65988 R12: 
8bc9cb5272c0
  [  609.008370] R13: 8bc9cb527000 R14:  R15: 
dead0100
  [  609.008371] FS:  7f188f1f9500() GS:8bc9ce20() 
knlGS:
  [  609.008372] CS:  0010 DS:  ES:  CR0: 80050033
  [  609.008373] CR2: 7f6d1a6af060 CR3: 00046d9f8006 CR4: 
003606f0
  [  609.008373] Call Trace:
  [  609.008376]  pci_disable_msi+0x100/0x130
  [  609.008385]  e1000e_reset_interrupt_capability+0x52/0x60 [e1000e]
  [  609.008389]  e1000_remove+0xc4/0x180 [e1000e]
  [  609.008391]  pci_device_remove+0x3e/0xb0
  [  609.008394]  device_release_driver_internal+0xf0/0x1d0
  [  609.008396]  driver_detach+0x4c/0x8f
  [  609.008397]  bus_remove_driver+0x5c/0xd0
  [  609.008399]  driver_unregister+0x31/0x50
  [  609.008400]  pci_unregister_driver+0x40/0x90
  [  609.008405]  e1000_exit_module+0x10/0x3c1 [e1000e]
  [  609.008407]  __x64_sys_delete_module+0x147/0x2b0
  [  609.008409]  ? exit_to_usermode_loop+0xea/0x160
  [  609.008411]  do_syscall_64+0x57/0x190
  [  609.008413]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
  [  609.008414] RIP: 0033:0x7f188f345c9b
  [  609.008416] Code: 73 01 c3 48 8b 0d f5 71 0c 00 f7 d8 64 89 01 48 83 c8 ff 
c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa b8 b0 00 00 00 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d c5 71 0c 00 f7 d8 64 89 01 48
  [  609.008416] RSP: 002b:7fffc8d32e68 EFLAGS: 0206 ORIG_RAX: 
00b0
  [  609.008418] RAX: ffda RBX: 561e1a391790 RCX: 
7f188f345c9b
  [  609.008419] RDX: 000a RSI: 0800 RDI: 
561e1a3917f8
  [  609.008420] RBP: 7fffc8d32ec8 R08:  R09: 

  [  609.008420] R10: 7f188f3c1ac0 R11: 0206 R12: 
7fffc8d33090
  [  609.008422] R13: 7fffc8d3474a R14: 561e1a3912a0 R15: 
561e1a391790
  [  609.008424] Modules linked in: thunderbolt rfcomm xfrm_user xfrm_algo 
l2tp_ppp l2tp_netlink l2tp_core ip6_udp_tunnel udp_tunnel pppox ccm xt_comment 
xt_CHECKSUM xt_MASQUERADE ip6table_mangle ip6table_nat dummy iptable_mangle 
iptable_nat nf_tables nfnetlink bridge stp llc cmac algif_hash algif_skcipher 
af_alg bnep zfs(PO) zunicode(PO) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) 
spl(O) zlua(PO) joydev intel_rapl_msr mei_hdcp nls_iso8859_1 snd_seq_midi 
snd_seq_midi_event snd_hda_codec_hdmi snd_hda_codec_conexant 
snd_hda_codec_generic intel_rapl_common x86_pkg_temp_thermal intel_powerclamp 
coretemp kvm_intel snd_hda_intel snd_rawmidi kvm snd_intel_nhlt snd_hda_codec 
intel_cstate rmi_smbus intel_rapl_perf snd_hda_core snd_hwdep iwlmvm rmi_core 
mac80211 uvcvideo input_leds videobuf2_vmalloc videobuf2_memops btusb btrtl 
snd_pcm libarc4 serio_raw snd_seq btbcm intel_wmi_thunderbolt videobuf2_v4l2 
btintel videobuf2_common wmi_bmof thinkpad_acpi bluetooth videodev nvram 
snd_seq_device ledtrig_audio
  [  609.008447]  iwlwifi mc snd_timer rtsx_pci_ms ecdh_generic ecc cfg80211 
memstick snd mei_me ucsi_acpi typec_ucsi intel_xhci_usb_role_switch mei roles 
intel_pch_thermal typec soundcore acpi_pad mac_hid nf_log_ipv6 ip6t_REJECT 
nf_reject_ipv6 xt_hl ip6t_rt nf_log_ipv4 nf_log_common ipt_REJECT 
nf_reject_ipv4 xt_LOG xt_limit xt_addrtype xt_tcpudp 

[Kernel-packages] [Bug 1837888] Re: lxc 3.0.3-0ubuntu1 ADT test failure with linux 5.3.0-0.1

2019-07-25 Thread Stéphane Graber
Moving this bug to the kernel as investigation discovered a kernel regression 
in overmounting protection behavior in 5.3 rc1.
So not a LXC bug but a kernel one.

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

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

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

Title:
  lxc 3.0.3-0ubuntu1 ADT test failure with linux 5.3.0-0.1

Status in linux package in Ubuntu:
  Triaged

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-bootstrap/eoan/amd64/l/lxc/20190724_132232_e90e9@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-bootstrap/eoan/arm64/l/lxc/20190724_134725_e90e9@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-bootstrap/eoan/ppc64el/l/lxc/20190724_130343_e90e9@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-eoan-canonical-kernel-team-bootstrap/eoan/s390x/l/lxc/20190724_131610_e90e9@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1837888/+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 1834475] Re: lxd 3.0.3-0ubuntu1~18.04.1 ADT test failure with linux 4.15.0-54.58

2019-06-28 Thread Stéphane Graber
We've changed some of those timings in 3.0.4 which will make it in
Ubuntu in the next month or so, but those tests can still be slightly
flaky even in our CI as we're testing cluster recovery during random
node losses, sometimes things take a bit longer than the 30s timeout to
recover, especially on busy systems like those adt test VMs.

It's not an actual problem that users will ever see, so if a retry gets
you through, don't worry about that particular failure.

** Changed in: lxd (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/1834475

Title:
  lxd 3.0.3-0ubuntu1~18.04.1 ADT test failure with linux 4.15.0-54.58

Status in linux package in Ubuntu:
  Incomplete
Status in lxd package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Incomplete
Status in lxd source package in Bionic:
  New

Bug description:
  Testing failed on:
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxd/20190626_154218_46720@/log.gz

  Some testcase have been flaky on arm64.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1834475/+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 1824812] Re: apparmor does not start in Disco LXD containers

2019-04-16 Thread Stéphane Graber
** Tags added: shiftfs

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

Title:
  apparmor does not start in Disco LXD containers

Status in AppArmor:
  Triaged
Status in apparmor package in Ubuntu:
  In Progress
Status in libvirt package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  In Progress

Bug description:
  In LXD apparmor now skips starting.

  Steps to reproduce:
  1. start LXD container
    $ lxc launch ubuntu-daily:d d-testapparmor
    (disco to trigger the issue, cosmic as reference)
  2. check the default profiles loaded
    $ aa-status

  => This will in cosmic and up to recently disco list plenty of profiles 
active even in the default install.
  Cosmic:
    25 profiles are loaded.
    25 profiles are in enforce mode.
  Disco:
    15 profiles are loaded.
    15 profiles are in enforce mode.

  All those 15 remaining are from snaps.
  The service of apparmor.service actually states that it refuses to start.

  $ systemctl status apparmor
  ...
  Apr 15 13:56:12 testkvm-disco-to apparmor.systemd[101]: Not starting AppArmor 
in container

  I can get those profiles (the default installed ones) loaded, for example:
    $ sudo apparmor_parser -r /etc/apparmor.d/sbin.dhclient
  makes it appear
    22 profiles are in enforce mode.
     /sbin/dhclient

  I was wondering as in my case I found my guest with no (=0) profiles loaded. 
But as shown above after "apparmor_parser -r" and package install profiles 
seemed fine. Then the puzzle was solved, on package install they
  will call apparmor_parser via the dh_apparmor snippet and it is fine.

  To fully disable all of them:
$ lxc stop 
$ lxc start 
$ lxc exec d-testapparmor aa-status
  apparmor module is loaded.
  0 profiles are loaded.
  0 profiles are in enforce mode.
  0 profiles are in complain mode.
  0 processes have profiles defined.
  0 processes are in enforce mode.
  0 processes are in complain mode.
  0 processes are unconfined but have a profile defined.

  That would match the service doing an early exit as shown in systemctl
  status output above. The package install or manual load works, but
  none are loaded by the service automatically e.g. on container
  restart.

  --- --- ---

  This bug started as:
  Migrations to Disco trigger "Unable to find security driver for model 
apparmor"

  This most likely is related to my KVM-in-LXD setup but it worked fine
  for years and I'd like to sort out what broke. I have migrated to
  Disco's qemu 3.1 already which makes me doubts generic issues in qemu
  3.1 in general.

  The virt tests that run cross release work fine starting from X/B/C but all 
those chains fail at mirgating to Disco now with:
    $ lxc exec testkvm-cosmic-from -- virsh migrate --unsafe --live 
kvmguest-bionic-normal
    qemu+ssh://10.21.151.207/system
    error: unsupported configuration: Unable to find security driver for model 
apparmor

  I need to analyze what changed

To manage notifications about this bug go to:
https://bugs.launchpad.net/apparmor/+bug/1824812/+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 1824719] Re: shiftfs: Allow stacking overlayfs on top

2019-04-16 Thread Stéphane Graber
** Changed in: linux (Ubuntu)
   Status: Incomplete => Triaged

** Tags added: shiftfs

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

Title:
  shiftfs: Allow stacking overlayfs on top

Status in linux package in Ubuntu:
  Triaged

Bug description:
  Shiftfs right now prevents stacking overlayfs on top of it which
  unfortunately means all users of Docker as well as some nested LXC
  users which aren't using btrfs are going to break when they get
  switched over to shiftfs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824719/+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 1824719] [NEW] [shiftfs] Allow stacking overlayfs on top

2019-04-14 Thread Stéphane Graber
Public bug reported:

Shiftfs right now prevents stacking overlayfs on top of it which
unfortunately means all users of Docker as well as some nested LXC users
which aren't using btrfs are going to break when they get switched over
to shiftfs.

** 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/1824719

Title:
  [shiftfs] Allow stacking overlayfs on top

Status in linux package in Ubuntu:
  Incomplete

Bug description:
  Shiftfs right now prevents stacking overlayfs on top of it which
  unfortunately means all users of Docker as well as some nested LXC
  users which aren't using btrfs are going to break when they get
  switched over to shiftfs.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1824719/+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 1789746] Re: getxattr: always handle namespaced attributes

2018-11-08 Thread Stéphane Graber
** Changed in: linux (Ubuntu Xenial)
   Status: Fix Committed => 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/1789746

Title:
  getxattr: always handle namespaced attributes

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Released
Status in linux source package in Bionic:
  Fix Released
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  
  == SRU Justification ==
  When running in a container with a user namespace, if you call getxattr
  with name = "system.posix_acl_access" and size % 8 != 4, then getxattr
  silently skips the user namespace fixup that it normally does resulting in
  un-fixed-up data being returned.
  This is caused by posix_acl_fix_xattr_to_user() being passed the total
  buffer size and not the actual size of the xattr as returned by
  vfs_getxattr().

  I have pushed a commit upstream that fixes this bug:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=82c9a927bc5df6e06b72d206d24a9d10cced4eb5

  This commit passes the actual length of the xattr as returned by
  vfs_getxattr() down.

  A reproducer for the issue is:

    touch acl_posix

    setfacl -m user:0:rwx acl_posix

  and the compile:

    #define _GNU_SOURCE
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 

    /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
    int main(int argc, void **argv)
    {
    ssize_t ret1, ret2;
    char buf1[128], buf2[132];
    int fret = EXIT_SUCCESS;
    char *file;

    if (argc < 2) {
    fprintf(stderr,
    "Please specify a file with "
    "\"system.posix_acl_access\" permissions set\n");
    _exit(EXIT_FAILURE);
    }
    file = argv[1];

    ret1 = getxattr(file, "system.posix_acl_access",
    buf1, sizeof(buf1));
    if (ret1 < 0) {
    fprintf(stderr, "%s - Failed to retrieve "
    "\"system.posix_acl_access\" "
    "from \"%s\"\n", strerror(errno), file);
    _exit(EXIT_FAILURE);
    }

    ret2 = getxattr(file, "system.posix_acl_access",
    buf2, sizeof(buf2));
    if (ret2 < 0) {
    fprintf(stderr, "%s - Failed to retrieve "
    "\"system.posix_acl_access\" "
    "from \"%s\"\n", strerror(errno), file);
    _exit(EXIT_FAILURE);
    }

    if (ret1 != ret2) {
    fprintf(stderr, "The value of \"system.posix_acl_"
    "access\" for file \"%s\" changed "
    "between two successive calls\n", file);
    _exit(EXIT_FAILURE);
    }

    for (ssize_t i = 0; i < ret2; i++) {
    if (buf1[i] == buf2[i])
    continue;

    fprintf(stderr,
    "Unexpected different in byte %zd: "
    "%02x != %02x\n", i, buf1[i], buf2[i]);
    fret = EXIT_FAILURE;
    }

    if (fret == EXIT_SUCCESS)
    fprintf(stderr, "Test passed\n");
    else
    fprintf(stderr, "Test failed\n");

    _exit(fret);
    }
  and run:

    ./tester acl_posix

  On a non-fixed up kernel this should return something like:

    root@c1:/# ./t
    Unexpected different in byte 16: ffa0 != 00
    Unexpected different in byte 17: ff86 != 00
    Unexpected different in byte 18: 01 != 00

  and on a fixed kernel:

    root@c1:~# ./t
    Test passed

  
  == Fix ==
  82c9a927bc5d ("getxattr: use correct xattr length")

  == Regression Potential ==
  Low.  One liner that passes the actual length of the xattr as returned by
  vfs_getxattr() down.

  == Test Case ==
  A test kernel was built with this patch and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789746/+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 1624540] Re: please have lxd recommend zfs

2018-11-06 Thread Stéphane Graber
Marking the LXD side of this fixed as we're now shipping as a snap by
default and the snap contains zfs.

** Changed in: lxd (Ubuntu)
   Status: Incomplete => Fix Released

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

Title:
  please have lxd recommend zfs

Status in lxd package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  In Progress

Bug description:
  Since ZFS is now in Main (Bug #1532198), LXD should recommend the ZFS
  userspace package, such that 'sudo lxd init' just works.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1624540/+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 1788314] Update Released

2018-11-05 Thread Stéphane Graber
The verification of the Stable Release Update for lxd has completed
successfully and the package has now been released to -updates.
Subsequently, the Ubuntu Stable Release Updates Team is being
unsubscribed and will not receive messages about this bug report.  In
the event that you encounter a regression using the package from
-updates please report a new bug using ubuntu-bug and tag the bug report
regression-update so we can easily find any regressions.

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

Title:
  Conflict between zfs-linux and s390-tools

Status in s390-tools package in Ubuntu:
  Fix Released
Status in zfs-linux package in Ubuntu:
  Invalid

Bug description:
  Not sure which of the two needs fixing, but there's a path conflict
  between zfs-linux and s390-tools which effectively prevents installing
  ZFS on s390x in cosmic.

  (Reading database ... 83042 files and directories currently installed.)
  Preparing to unpack .../zfsutils-linux_0.7.9-3ubuntu5_s390x.deb ...
  Unpacking zfsutils-linux (0.7.9-3ubuntu5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb (--unpack):
   trying to overwrite '/usr/share/initramfs-tools/hooks/zdev', which is also 
in package s390-tools 2.6.0-0ubuntu2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  Exit request sent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1788314/+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 1799497] Re: 4.15 kernel hard lockup about once a week

2018-11-01 Thread Stéphane Graber
Oh, I am also using zram-config on the affected machine.

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

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

-- 
Mailing list: 

[Kernel-packages] [Bug 1799497] Re: 4.15 kernel hard lockup about once a week

2018-10-31 Thread Stéphane Graber
Just happened again, though the machine wouldn't reboot at all
afterwards, leading to the hosting provider going for a motherboard
replacement, so I guess better luck next week with debugging this.

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage 

[Kernel-packages] [Bug 1799497] Re: 4.15 kernel hard lockup about once a week

2018-10-24 Thread Stéphane Graber
The server doesn't respond to pings when locked up.

I do have IPMI and console redirection going for my server and have
enabled all sysrq now though it's unclear whether I can send those
through the BMC yet (as just typing them would obviously send them to my
laptop...).

I've setup debug console both to screen and to IPMI, raised the kernel
log level to 9, setup NMI watchdog and enabled panic on oops and panic
on hardlock and disabled reboot on panic, so maybe I'll get lucky with
the next hang and get some output on console though that'd be a first...

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 

[Kernel-packages] [Bug 1799497] ProcInterrupts.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "ProcInterrupts.txt"
   
https://bugs.launchpad.net/bugs/1799497/+attachment/5204636/+files/ProcInterrupts.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] ProcModules.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "ProcModules.txt"
   
https://bugs.launchpad.net/bugs/1799497/+attachment/5204637/+files/ProcModules.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] Re: 4.15 kernel hard lockup about once a week

2018-10-23 Thread Stéphane Graber
Note that I've deleted the wifisyslog and currentdmesg as they're not
relevant (current boot) and included information that I'd rather not
have exposed publicly.

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] WifiSyslog.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "WifiSyslog.txt"
   
https://bugs.launchpad.net/bugs/1799497/+attachment/5204639/+files/WifiSyslog.txt

** Attachment removed: "CurrentDmesg.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1799497/+attachment/5204633/+files/CurrentDmesg.txt

** Attachment removed: "WifiSyslog.txt"
   
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1799497/+attachment/5204639/+files/WifiSyslog.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 

[Kernel-packages] [Bug 1799497] UdevDb.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "UdevDb.txt"
   https://bugs.launchpad.net/bugs/1799497/+attachment/5204638/+files/UdevDb.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] CRDA.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "CRDA.txt"
   https://bugs.launchpad.net/bugs/1799497/+attachment/5204632/+files/CRDA.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] ProcCpuinfoMinimal.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "ProcCpuinfoMinimal.txt"
   
https://bugs.launchpad.net/bugs/1799497/+attachment/5204635/+files/ProcCpuinfoMinimal.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] Lspci.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "Lspci.txt"
   https://bugs.launchpad.net/bugs/1799497/+attachment/5204634/+files/Lspci.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] Re: 4.15 kernel hard lockup about once a week

2018-10-23 Thread Stéphane Graber
Well, kinda, this is a production server running a lot of publicly
visible services, so I can run test kernels on it so long as they don't
regress system security.

There's also the unfortunate problem that it takes over a week for me to
see the problem in most cases and that my last known good kernel was the
latest 4.4 kernel from 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/1799497

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  

[Kernel-packages] [Bug 1799497] CurrentDmesg.txt

2018-10-23 Thread Stéphane Graber
apport information

** Attachment added: "CurrentDmesg.txt"
   
https://bugs.launchpad.net/bugs/1799497/+attachment/5204633/+files/CurrentDmesg.txt

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in Bionic:
  Incomplete

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
  --- 
  ProblemType: Bug
  AlsaDevices:
   total 0
   crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
   crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
  AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
  ApportVersion: 2.20.9-0ubuntu7.4
  Architecture: amd64
  ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
  AudioDevicesInUse:
   Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
   Cannot stat file /proc/22831/fd/10: Permission denied
  DistroRelease: Ubuntu 18.04
  HibernationDevice:
   RESUME=none
   CRYPTSETUP=n
  IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
  Lsusb:
   Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
   Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
   Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
  MachineType: Intel Corporation S1200SP
  NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
  Package: linux (not installed)
  PciMultimedia:
   
  ProcEnviron:
   TERM=xterm
   PATH=(custom, no user)
   XDG_RUNTIME_DIR=
   LANG=en_US.UTF-8
   SHELL=/bin/bash
  ProcFB: 0 mgadrmfb
  ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
  ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
  RelatedPackageVersions:
   linux-restricted-modules-4.15.0-38-generic N/A
   linux-backports-modules-4.15.0-38-generic  N/A
   linux-firmware 1.173.1
  RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
  Tags:  bionic
  Uname: Linux 4.15.0-38-generic x86_64
  UnreportableReason: This report is about a package that is not installed.
  UpgradeStatus: No upgrade log present (probably fresh install)
  UserGroups:
   
  _MarkForUpload: False
  dmi.bios.date: 01/25/2018
  dmi.bios.vendor: Intel Corporation
  dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
  dmi.board.asset.tag: Base Board Asset Tag
  dmi.board.name: S1200SP
  dmi.board.vendor: Intel Corporation
  dmi.board.version: H57532-271
  dmi.chassis.asset.tag: 
  dmi.chassis.type: 23
  dmi.chassis.vendor: ...
  dmi.chassis.version: ..
  dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
  dmi.product.family: Family
  dmi.product.name: S1200SP
  dmi.product.version: 
  dmi.sys.vendor: Intel Corporation

To manage notifications about this bug go to:

[Kernel-packages] [Bug 1799497] Re: 4.15 kernel hard lockup about once a week

2018-10-23 Thread Stéphane Graber
Oh and whatever kernel I boot needs to have support for ZFS 0.7 or I
won't be able to read my drives.

** Tags added: apport-collected

** Description changed:

  My main server has been running into hard lockups about once a week ever
  since I switched to the 4.15 Ubuntu 18.04 kernel.
  
  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on the
  cmdline but isn't rebooting so the kernel isn't even processing this as
  a kernel panic.
  
  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.
  
  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197
  
  
  My system doesn't have a lot of memory pressure with about 50% of free memory:
  
  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222
  
  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea of
  what happened but I'm not too hopeful given the complete silence on the
  console when this occurs.
  
  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux
  
- But I've seen this since the GA kernel on 4.15 so it's not a recent
- regression.
+ But I've seen this since the GA kernel on 4.15 so it's not a recent 
regression.
+ --- 
+ ProblemType: Bug
+ AlsaDevices:
+  total 0
+  crw-rw 1 root audio 116,  1 Oct 23 16:12 seq
+  crw-rw 1 root audio 116, 33 Oct 23 16:12 timer
+ AplayDevices: Error: [Errno 2] No such file or directory: 'aplay': 'aplay'
+ ApportVersion: 2.20.9-0ubuntu7.4
+ Architecture: amd64
+ ArecordDevices: Error: [Errno 2] No such file or directory: 'arecord': 
'arecord'
+ AudioDevicesInUse:
+  Error: command ['fuser', '-v', '/dev/snd/seq', '/dev/snd/timer'] failed with 
exit code 1: Cannot stat file /proc/22822/fd/10: Permission denied
+  Cannot stat file /proc/22831/fd/10: Permission denied
+ DistroRelease: Ubuntu 18.04
+ HibernationDevice:
+  RESUME=none
+  CRYPTSETUP=n
+ IwConfig: Error: [Errno 2] No such file or directory: 'iwconfig': 'iwconfig'
+ Lsusb:
+  Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
+  Bus 001 Device 002: ID 046b:ff10 American Megatrends, Inc. Virtual Keyboard 
and Mouse
+  Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
+ MachineType: Intel Corporation S1200SP
+ NonfreeKernelModules: zfs zunicode zavl icp zcommon znvpair
+ Package: linux (not installed)
+ PciMultimedia:
+  
+ ProcEnviron:
+  TERM=xterm
+  PATH=(custom, no user)
+  XDG_RUNTIME_DIR=
+  LANG=en_US.UTF-8
+  SHELL=/bin/bash
+ ProcFB: 0 mgadrmfb
+ ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-4.15.0-38-generic 
root=UUID=575c878a-0be6-4806-9c83-28f67aedea65 ro biosdevname=0 net.ifnames=0 
panic=1 verbose console=tty0 console=ttyS0,115200n8
+ ProcVersionSignature: Ubuntu 4.15.0-38.41-generic 4.15.18
+ RelatedPackageVersions:
+  linux-restricted-modules-4.15.0-38-generic N/A
+  linux-backports-modules-4.15.0-38-generic  N/A
+  linux-firmware 1.173.1
+ RfKill: Error: [Errno 2] No such file or directory: 'rfkill': 'rfkill'
+ Tags:  bionic
+ Uname: Linux 4.15.0-38-generic x86_64
+ UnreportableReason: This report is about a package that is not installed.
+ UpgradeStatus: No upgrade log present (probably fresh install)
+ UserGroups:
+  
+ _MarkForUpload: False
+ dmi.bios.date: 01/25/2018
+ dmi.bios.vendor: Intel Corporation
+ dmi.bios.version: S1200SP.86B.03.01.1029.012520180838
+ dmi.board.asset.tag: Base Board Asset Tag
+ dmi.board.name: S1200SP
+ dmi.board.vendor: Intel Corporation
+ dmi.board.version: H57532-271
+ dmi.chassis.asset.tag: 
+ dmi.chassis.type: 23
+ dmi.chassis.vendor: ...
+ dmi.chassis.version: ..
+ dmi.modalias: 
dmi:bvnIntelCorporation:bvrS1200SP.86B.03.01.1029.012520180838:bd01/25/2018:svnIntelCorporation:pnS1200SP:pvr:rvnIntelCorporation:rnS1200SP:rvrH57532-271:cvn...:ct23:cvr..:
+ dmi.product.family: Family
+ dmi.product.name: S1200SP
+ dmi.product.version: 
+ dmi.sys.vendor: Intel Corporation

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

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  Incomplete
Status in linux source package in 

[Kernel-packages] [Bug 1799497] [NEW] 4.15 kernel hard lockup about once a week

2018-10-23 Thread Stéphane Graber
Public bug reported:

My main server has been running into hard lockups about once a week ever
since I switched to the 4.15 Ubuntu 18.04 kernel.

When this happens, nothing is printed to the console, it's effectively
stuck showing a login prompt. The system is running with panic=1 on the
cmdline but isn't rebooting so the kernel isn't even processing this as
a kernel panic.


As this felt like a potential hardware issue, I had my hosting provider give me 
a completely different system, different motherboard, different CPU, different 
RAM and different storage, I installed that system on 18.04 and moved my data 
over, a week later, I hit the issue again.

We've since also had a LXD user reporting similar symptoms here also on varying 
hardware:
  https://github.com/lxc/lxd/issues/5197


My system doesn't have a lot of memory pressure with about 50% of free memory:

root@vorash:~# free -m
  totalusedfree  shared  buff/cache   available
Mem:  31819   17574 402 513   13842   13292
Swap: 159092687   13222

I will now try to increase console logging as much as possible on the
system in the hopes that next time it hangs we can get a better idea of
what happened but I'm not too hopeful given the complete silence on the
console when this occurs.

System is currently on:
  Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

But I've seen this since the GA kernel on 4.15 so it's not a recent
regression.

** Affects: 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/1799497

Title:
  4.15 kernel hard lockup about once a week

Status in linux package in Ubuntu:
  New

Bug description:
  My main server has been running into hard lockups about once a week
  ever since I switched to the 4.15 Ubuntu 18.04 kernel.

  When this happens, nothing is printed to the console, it's effectively
  stuck showing a login prompt. The system is running with panic=1 on
  the cmdline but isn't rebooting so the kernel isn't even processing
  this as a kernel panic.

  
  As this felt like a potential hardware issue, I had my hosting provider give 
me a completely different system, different motherboard, different CPU, 
different RAM and different storage, I installed that system on 18.04 and moved 
my data over, a week later, I hit the issue again.

  We've since also had a LXD user reporting similar symptoms here also on 
varying hardware:
https://github.com/lxc/lxd/issues/5197

  
  My system doesn't have a lot of memory pressure with about 50% of free memory:

  root@vorash:~# free -m
totalusedfree  shared  buff/cache   
available
  Mem:  31819   17574 402 513   13842   
13292
  Swap: 159092687   13222

  I will now try to increase console logging as much as possible on the
  system in the hopes that next time it hangs we can get a better idea
  of what happened but I'm not too hopeful given the complete silence on
  the console when this occurs.

  System is currently on:
Linux vorash 4.15.0-36-generic #39-Ubuntu SMP Mon Sep 24 16:19:09 UTC 2018 
x86_64 x86_64 x86_64 GNU/Linux

  But I've seen this since the GA kernel on 4.15 so it's not a recent
  regression.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1799497/+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 1789746] Re: getxattr: always handle namespaced attributes

2018-10-02 Thread Stéphane Graber
** Changed in: linux (Ubuntu Cosmic)
   Status: Fix Committed => 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/1789746

Title:
  getxattr: always handle namespaced attributes

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed
Status in linux source package in Bionic:
  Fix Committed
Status in linux source package in Cosmic:
  Fix Released

Bug description:
  
  == SRU Justification ==
  When running in a container with a user namespace, if you call getxattr
  with name = "system.posix_acl_access" and size % 8 != 4, then getxattr
  silently skips the user namespace fixup that it normally does resulting in
  un-fixed-up data being returned.
  This is caused by posix_acl_fix_xattr_to_user() being passed the total
  buffer size and not the actual size of the xattr as returned by
  vfs_getxattr().

  I have pushed a commit upstream that fixes this bug:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=82c9a927bc5df6e06b72d206d24a9d10cced4eb5

  This commit passes the actual length of the xattr as returned by
  vfs_getxattr() down.

  A reproducer for the issue is:

    touch acl_posix

    setfacl -m user:0:rwx acl_posix

  and the compile:

    #define _GNU_SOURCE
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 
    #include 

    /* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
    int main(int argc, void **argv)
    {
    ssize_t ret1, ret2;
    char buf1[128], buf2[132];
    int fret = EXIT_SUCCESS;
    char *file;

    if (argc < 2) {
    fprintf(stderr,
    "Please specify a file with "
    "\"system.posix_acl_access\" permissions set\n");
    _exit(EXIT_FAILURE);
    }
    file = argv[1];

    ret1 = getxattr(file, "system.posix_acl_access",
    buf1, sizeof(buf1));
    if (ret1 < 0) {
    fprintf(stderr, "%s - Failed to retrieve "
    "\"system.posix_acl_access\" "
    "from \"%s\"\n", strerror(errno), file);
    _exit(EXIT_FAILURE);
    }

    ret2 = getxattr(file, "system.posix_acl_access",
    buf2, sizeof(buf2));
    if (ret2 < 0) {
    fprintf(stderr, "%s - Failed to retrieve "
    "\"system.posix_acl_access\" "
    "from \"%s\"\n", strerror(errno), file);
    _exit(EXIT_FAILURE);
    }

    if (ret1 != ret2) {
    fprintf(stderr, "The value of \"system.posix_acl_"
    "access\" for file \"%s\" changed "
    "between two successive calls\n", file);
    _exit(EXIT_FAILURE);
    }

    for (ssize_t i = 0; i < ret2; i++) {
    if (buf1[i] == buf2[i])
    continue;

    fprintf(stderr,
    "Unexpected different in byte %zd: "
    "%02x != %02x\n", i, buf1[i], buf2[i]);
    fret = EXIT_FAILURE;
    }

    if (fret == EXIT_SUCCESS)
    fprintf(stderr, "Test passed\n");
    else
    fprintf(stderr, "Test failed\n");

    _exit(fret);
    }
  and run:

    ./tester acl_posix

  On a non-fixed up kernel this should return something like:

    root@c1:/# ./t
    Unexpected different in byte 16: ffa0 != 00
    Unexpected different in byte 17: ff86 != 00
    Unexpected different in byte 18: 01 != 00

  and on a fixed kernel:

    root@c1:~# ./t
    Test passed

  
  == Fix ==
  82c9a927bc5d ("getxattr: use correct xattr length")

  == Regression Potential ==
  Low.  One liner that passes the actual length of the xattr as returned by
  vfs_getxattr() down.

  == Test Case ==
  A test kernel was built with this patch and tested by the original bug 
reporter.
  The bug reporter states the test kernel resolved the bug.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789746/+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 1790521] Re: lxd 3.0.2-0ubuntu3 ADT test failure with linux 4.18.0-7.8

2018-09-04 Thread Stéphane Graber
The new liblxc has now migrated, so may be worth retrying.

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

Title:
  lxd 3.0.2-0ubuntu3 ADT test failure with linux 4.18.0-7.8

Status in linux package in Ubuntu:
  Incomplete
Status in lxd package in Ubuntu:
  Invalid
Status in linux source package in Cosmic:
  Incomplete
Status in lxd source package in Cosmic:
  Invalid

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/amd64/l/lxd/20180831_072844_6ea94@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/arm64/l/lxd/20180831_074034_6ea94@/log.gz
  i386: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/i386/l/lxd/20180831_073216_6ea94@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/ppc64el/l/lxd/20180831_072127_6ea94@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-cosmic/cosmic/s390x/l/lxd/20180831_072401_6ea94@/log.gz

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1790521/+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 1789746] Re: getxattr: always handle namespaced attributes

2018-08-29 Thread Stéphane Graber
** Changed in: linux (Ubuntu)
   Status: Confirmed => Triaged

** Also affects: linux (Ubuntu Cosmic)
   Importance: High
   Status: Triaged

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

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

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

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

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: linux (Ubuntu Bionic)
   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/1789746

Title:
  getxattr: always handle namespaced attributes

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

Bug description:
  Hey everyone,

  When running in a container with a user namespace, if you call getxattr
  with name = "system.posix_acl_access" and size % 8 != 4, then getxattr
  silently skips the user namespace fixup that it normally does resulting in
  un-fixed-up data being returned.
  This is caused by posix_acl_fix_xattr_to_user() being passed the total
  buffer size and not the actual size of the xattr as returned by
  vfs_getxattr().

  I have pushed a commit upstream that fixes this bug:

  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=82c9a927bc5df6e06b72d206d24a9d10cced4eb5

  
  This commit passes the actual length of the xattr as returned by
  vfs_getxattr() down.

  A reproducer for the issue is:

touch acl_posix

setfacl -m user:0:rwx acl_posix

  and the compile:

#define _GNU_SOURCE
#include 
#include 
#include 
#include 
#include 
#include 
#include 

/* Run in user namespace with nsuid 0 mapped to uid != 0 on the host. */
int main(int argc, void **argv)
{
ssize_t ret1, ret2;
char buf1[128], buf2[132];
int fret = EXIT_SUCCESS;
char *file;

if (argc < 2) {
fprintf(stderr,
"Please specify a file with "
"\"system.posix_acl_access\" permissions set\n");
_exit(EXIT_FAILURE);
}
file = argv[1];

ret1 = getxattr(file, "system.posix_acl_access",
buf1, sizeof(buf1));
if (ret1 < 0) {
fprintf(stderr, "%s - Failed to retrieve "
"\"system.posix_acl_access\" "
"from \"%s\"\n", strerror(errno), file);
_exit(EXIT_FAILURE);
}

ret2 = getxattr(file, "system.posix_acl_access",
buf2, sizeof(buf2));
if (ret2 < 0) {
fprintf(stderr, "%s - Failed to retrieve "
"\"system.posix_acl_access\" "
"from \"%s\"\n", strerror(errno), file);
_exit(EXIT_FAILURE);
}

if (ret1 != ret2) {
fprintf(stderr, "The value of \"system.posix_acl_"
"access\" for file \"%s\" changed "
"between two successive calls\n", file);
_exit(EXIT_FAILURE);
}

for (ssize_t i = 0; i < ret2; i++) {
if (buf1[i] == buf2[i])
continue;

fprintf(stderr,
"Unexpected different in byte %zd: "
"%02x != %02x\n", i, buf1[i], buf2[i]);
fret = EXIT_FAILURE;
}

if (fret == EXIT_SUCCESS)
fprintf(stderr, "Test passed\n");
else
fprintf(stderr, "Test failed\n");

_exit(fret);
}
  and run:

./tester acl_posix

  On a non-fixed up kernel this should return something like:

root@c1:/# ./t
Unexpected different in byte 16: ffa0 != 00
Unexpected different in byte 17: ff86 != 00
Unexpected different in byte 18: 01 != 00

  and on a fixed kernel:

root@c1:~# ./t
Test passed

  
  Please backport this to the 4.15 (bionic) and 4.4 (xenial) kernels. :)

  Thanks!
  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1789746/+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 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

2018-08-23 Thread Stéphane Graber
Were you maybe using a privileged container before? Those aren't
affected by the /sys ownership issue.

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

Title:
  libvirtd is unable to configure bridge devices inside of LXD
  containers

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Bionic:
  Triaged

Bug description:
  libvirtd cannot properly configure the default bridge device when
  installed inside of unprivileged LXD containers. 'systemctl status
  libvirtd' shows the following error:

error : virNetDevBridgeSet:140 : Unable to set bridge virbr0
  forward_delay: Permission denied

  This is caused due to the files under /sys/class/net/ being owned by
  init namespace root rather than container root even when the bridge
  device is created inside of the container. Here's an example from
  inside of an unprivileged container:

  # brctl addbr testbr0
  # ls -al /sys/class/net/testbr0/bridge/forward_delay 
  -rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 
/sys/class/net/testbr0/bridge/forward_delay

  libvirt cannot open this file for writing even though it created the
  device. Where safe, files under /sys/class/net/ should be owned by
  container root.

  The following upstream patches have been merged into linux-next which
  fix this bug:

  
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
  
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784501/+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 1788314] Re: Conflict between zfs-linux and s390-tools

2018-08-22 Thread Stéphane Graber
Closing the zfs task as this will be fixed in s390-tools.

** Changed in: zfs-linux (Ubuntu)
   Status: Triaged => Invalid

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

Title:
  Conflict between zfs-linux and s390-tools

Status in s390-tools package in Ubuntu:
  Confirmed
Status in zfs-linux package in Ubuntu:
  Invalid

Bug description:
  Not sure which of the two needs fixing, but there's a path conflict
  between zfs-linux and s390-tools which effectively prevents installing
  ZFS on s390x in cosmic.

  (Reading database ... 83042 files and directories currently installed.)
  Preparing to unpack .../zfsutils-linux_0.7.9-3ubuntu5_s390x.deb ...
  Unpacking zfsutils-linux (0.7.9-3ubuntu5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb (--unpack):
   trying to overwrite '/usr/share/initramfs-tools/hooks/zdev', which is also 
in package s390-tools 2.6.0-0ubuntu2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  Exit request sent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1788314/+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 1788314] [NEW] Conflict between zfs-linux and s390-tools

2018-08-21 Thread Stéphane Graber
Public bug reported:

Not sure which of the two needs fixing, but there's a path conflict
between zfs-linux and s390-tools which effectively prevents installing
ZFS on s390x in cosmic.

(Reading database ... 83042 files and directories currently installed.)
Preparing to unpack .../zfsutils-linux_0.7.9-3ubuntu5_s390x.deb ...
Unpacking zfsutils-linux (0.7.9-3ubuntu5) ...
dpkg: error processing archive 
/var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb (--unpack):
 trying to overwrite '/usr/share/initramfs-tools/hooks/zdev', which is also in 
package s390-tools 2.6.0-0ubuntu2
dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
Errors were encountered while processing:
 /var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
Exit request sent.

** Affects: s390-tools (Ubuntu)
 Importance: High
 Status: Triaged

** Affects: zfs-linux (Ubuntu)
 Importance: High
 Status: Triaged

** Also affects: s390-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: s390-tools (Ubuntu)
   Status: New => Triaged

** Changed in: zfs-linux (Ubuntu)
   Status: New => Triaged

** Changed in: s390-tools (Ubuntu)
   Importance: Undecided => High

** Changed in: zfs-linux (Ubuntu)
   Importance: Undecided => High

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

Title:
  Conflict between zfs-linux and s390-tools

Status in s390-tools package in Ubuntu:
  Triaged
Status in zfs-linux package in Ubuntu:
  Triaged

Bug description:
  Not sure which of the two needs fixing, but there's a path conflict
  between zfs-linux and s390-tools which effectively prevents installing
  ZFS on s390x in cosmic.

  (Reading database ... 83042 files and directories currently installed.)
  Preparing to unpack .../zfsutils-linux_0.7.9-3ubuntu5_s390x.deb ...
  Unpacking zfsutils-linux (0.7.9-3ubuntu5) ...
  dpkg: error processing archive 
/var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb (--unpack):
   trying to overwrite '/usr/share/initramfs-tools/hooks/zdev', which is also 
in package s390-tools 2.6.0-0ubuntu2
  dpkg-deb: error: paste subprocess was killed by signal (Broken pipe)
  Errors were encountered while processing:
   /var/cache/apt/archives/zfsutils-linux_0.7.9-3ubuntu5_s390x.deb
  E: Sub-process /usr/bin/dpkg returned an error code (1)
  Exit request sent.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/s390-tools/+bug/1788314/+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 1784501] Re: libvirtd is unable to configure bridge devices inside of LXD containers

2018-08-10 Thread Stéphane Graber
Adding a task for bionic as we'll want this fix to be available for our 18.04 
users.
No need to backport it to anything older than that though.

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

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

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Medium

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

Title:
  libvirtd is unable to configure bridge devices inside of LXD
  containers

Status in linux package in Ubuntu:
  Fix Committed
Status in linux source package in Bionic:
  Triaged

Bug description:
  libvirtd cannot properly configure the default bridge device when
  installed inside of unprivileged LXD containers. 'systemctl status
  libvirtd' shows the following error:

error : virNetDevBridgeSet:140 : Unable to set bridge virbr0
  forward_delay: Permission denied

  This is caused due to the files under /sys/class/net/ being owned by
  init namespace root rather than container root even when the bridge
  device is created inside of the container. Here's an example from
  inside of an unprivileged container:

  # brctl addbr testbr0
  # ls -al /sys/class/net/testbr0/bridge/forward_delay 
  -rw-r--r-- 1 nobody nogroup 4096 Jul 30 22:33 
/sys/class/net/testbr0/bridge/forward_delay

  libvirt cannot open this file for writing even though it created the
  device. Where safe, files under /sys/class/net/ should be owned by
  container root.

  The following upstream patches have been merged into linux-next which
  fix this bug:

  
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=c59e18b876da3e466abe5fa066aa69050f5be17c
  
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=d1753390274f7760e5b593cb657ea34f0617e559

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1784501/+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 1778286] Re: Backport namespaced fscaps to xenial 4.4

2018-08-05 Thread Stéphane Graber
** 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/1778286

Title:
  Backport namespaced fscaps to xenial 4.4

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification

  Impact: Support for using filesystem capabilities in unprivileged user
  namespaces was added upstream in Linux 4.14. This is a useful feature
  that allows unprivileged containers to set fscaps that are valid only
  in user namespaces where a specific kuid is mapped to root. This
  allows for e.g. support for Linux distros within lxd which make use of
  filesystem capabilities.

  Fix: Backport upstream commit 8db6c34f1dbc "Introduce v3 namespaced
  file capabilities" and any subsequent fixes to xenial 4.4.

  Test Case: Test use of fscaps within a lxd container.

  Regression Potential: This has been upstream since 4.14 (and thus is
  present in bionic), and the backport to xenial 4.4 was
  straightforward, so regression potential is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1778286/+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 1778286] Re: Backport namespaced fscaps to xenial 4.4

2018-08-05 Thread Stéphane Graber
Installing the LXD snap from edge channel (for fscaps support), on the
current 4.4 kernel:

root@djanet:~# lxc launch ubuntu-daily:cosmic c1
To start your first container, try: lxc launch ubuntu:18.04

Creating c1
Starting c1  
root@djanet:~# lxc exec c1 -- setcap cap_net_raw+ep /usr/bin/mtr-packet
Failed to set capabilities on file `/usr/bin/mtr-packet' (Operation not 
permitted)
The value of the capability argument is not permitted for a file. Or the file 
is not a regular (non-symlink) file

As expected on that kernel, the caps were lost when the container got
uid shifted and manually setting the caps from within the container
fails.


After switching to 4.4.0-132:

root@djanet:~# lxc exec c1 -- setcap cap_net_raw+ep /usr/bin/mtr-packet
root@djanet:~# lxc exec c1 -- getcap /usr/bin/mtr-packet
/usr/bin/mtr-packet = cap_net_raw+ep

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

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

Title:
  Backport namespaced fscaps to xenial 4.4

Status in linux package in Ubuntu:
  Fix Released
Status in linux source package in Xenial:
  Fix Committed

Bug description:
  SRU Justification

  Impact: Support for using filesystem capabilities in unprivileged user
  namespaces was added upstream in Linux 4.14. This is a useful feature
  that allows unprivileged containers to set fscaps that are valid only
  in user namespaces where a specific kuid is mapped to root. This
  allows for e.g. support for Linux distros within lxd which make use of
  filesystem capabilities.

  Fix: Backport upstream commit 8db6c34f1dbc "Introduce v3 namespaced
  file capabilities" and any subsequent fixes to xenial 4.4.

  Test Case: Test use of fscaps within a lxd container.

  Regression Potential: This has been upstream since 4.14 (and thus is
  present in bionic), and the backport to xenial 4.4 was
  straightforward, so regression potential is low.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1778286/+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 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches

2018-07-30 Thread Stéphane Graber
I tested on two systems, one clean xenial and one clean bionic, both
running the current stable LXD snap with latest ArchLinux and Debian
containers. On both of them, upgrading to the kernels provided by John
fixed the file_lock denials and made the containers boot again.

So as far as I'm concerned, we're good to start pushing this to Ubuntu
kernels.

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

Title:
  locking sockets broken due to missing AppArmor socket mediation
  patches

Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in apparmor source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  Triaged
Status in apparmor source package in Bionic:
  Invalid
Status in linux source package in Bionic:
  Triaged

Bug description:
  Hey,

  Newer systemd makes use of locks placed on AF_UNIX sockets created
  with the socketpair() syscall to synchronize various bits and pieces
  when isolating services. On kernels prior to 4.18 that do not have
  backported the AppArmor socket mediation patchset this will cause the
  locks to be denied with EACCESS. This causes systemd to be broken in
  LXC and LXD containers that do not run unconfined which is a pretty
  big deal. We have seen various bug reports related to this. See for
  example [1] and [2].

  If feasible it would be excellent if we could backport the socket
  mediation patchset to all LTS kernels. Afaict, this should be 4.4 and
  4.15. This will unbreak a whole range of use-cases.

  The socket mediation patchset is available here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4

  
  [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
  [2]: https://github.com/systemd/systemd/issues/9493

  Thanks!
  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+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 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches

2018-07-27 Thread Stéphane Graber
Ok, thanks for the update. I've now updated the bug once again to move
all the tasks over to the kernel. Can you attach the kernel patch here
when you can, I'm sure some of the subscribers may want to test this
ahead of the Ubuntu kernel fixes :)

** Changed in: linux (Ubuntu)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu Xenial)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu Bionic)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu)
   Status: Invalid => Triaged

** Changed in: linux (Ubuntu Xenial)
   Status: Invalid => Triaged

** Changed in: linux (Ubuntu Bionic)
   Status: Invalid => Triaged

** Changed in: apparmor (Ubuntu)
   Status: Triaged => Invalid

** Changed in: apparmor (Ubuntu Xenial)
   Status: Triaged => Invalid

** Changed in: apparmor (Ubuntu Bionic)
   Status: Triaged => Invalid

** Changed in: apparmor (Ubuntu)
 Assignee: John Johansen (jjohansen) => (unassigned)

** Changed in: apparmor (Ubuntu Xenial)
 Assignee: John Johansen (jjohansen) => (unassigned)

** Changed in: apparmor (Ubuntu Bionic)
 Assignee: John Johansen (jjohansen) => (unassigned)

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => John Johansen (jjohansen)

** Changed in: linux (Ubuntu Xenial)
 Assignee: (unassigned) => John Johansen (jjohansen)

** Changed in: linux (Ubuntu Bionic)
 Assignee: (unassigned) => John Johansen (jjohansen)

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

Title:
  locking sockets broken due to missing AppArmor socket mediation
  patches

Status in apparmor package in Ubuntu:
  Invalid
Status in linux package in Ubuntu:
  Triaged
Status in apparmor source package in Xenial:
  Invalid
Status in linux source package in Xenial:
  Triaged
Status in apparmor source package in Bionic:
  Invalid
Status in linux source package in Bionic:
  Triaged

Bug description:
  Hey,

  Newer systemd makes use of locks placed on AF_UNIX sockets created
  with the socketpair() syscall to synchronize various bits and pieces
  when isolating services. On kernels prior to 4.18 that do not have
  backported the AppArmor socket mediation patchset this will cause the
  locks to be denied with EACCESS. This causes systemd to be broken in
  LXC and LXD containers that do not run unconfined which is a pretty
  big deal. We have seen various bug reports related to this. See for
  example [1] and [2].

  If feasible it would be excellent if we could backport the socket
  mediation patchset to all LTS kernels. Afaict, this should be 4.4 and
  4.15. This will unbreak a whole range of use-cases.

  The socket mediation patchset is available here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4

  
  [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
  [2]: https://github.com/systemd/systemd/issues/9493

  Thanks!
  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+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 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches

2018-07-26 Thread Stéphane Graber
@John any update on the point releases?

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

Title:
  locking sockets broken due to missing AppArmor socket mediation
  patches

Status in apparmor package in Ubuntu:
  Triaged
Status in linux package in Ubuntu:
  Invalid
Status in apparmor source package in Xenial:
  Triaged
Status in linux source package in Xenial:
  Invalid
Status in apparmor source package in Bionic:
  Triaged
Status in linux source package in Bionic:
  Invalid

Bug description:
  Hey,

  Newer systemd makes use of locks placed on AF_UNIX sockets created
  with the socketpair() syscall to synchronize various bits and pieces
  when isolating services. On kernels prior to 4.18 that do not have
  backported the AppArmor socket mediation patchset this will cause the
  locks to be denied with EACCESS. This causes systemd to be broken in
  LXC and LXD containers that do not run unconfined which is a pretty
  big deal. We have seen various bug reports related to this. See for
  example [1] and [2].

  If feasible it would be excellent if we could backport the socket
  mediation patchset to all LTS kernels. Afaict, this should be 4.4 and
  4.15. This will unbreak a whole range of use-cases.

  The socket mediation patchset is available here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4

  
  [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
  [2]: https://github.com/systemd/systemd/issues/9493

  Thanks!
  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+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 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches

2018-07-24 Thread Stéphane Graber
Per discussion above:
 - Closing the kernel tasks
 - Raising priority on apparmor tasks to Critical (to match what kernel had)
 - Assigning to jjohansen as the AppArmor maintainer

As we care about xenial, bionic and cosmic, we need point releases (or 
cherry-pick) for:
 - AppArmor 2.10 (2.10.95 in xenial)
 - AppArmor 2.12 (2.12 in bionic and cosmic)

John: Any ETA for those two point releases or pointer to a commit which
we could SRU on its own?

For now our focus is obviously on getting this resolved in Ubuntu as
soon as possible, since it's breaking a number of systemd services that
are now (18.04) shipping with more confinement than in the past. The
same issue is also currently preventing us from starting newer Fedora
and Arch containers on Ubuntu.

Our standard response so far has been to tell users to turn off AppArmor
for those containers, but it's obviously not an answer we like to give
(I'm sure you'll agree).

** Changed in: linux (Ubuntu)
   Status: Triaged => Invalid

** Changed in: linux (Ubuntu Xenial)
   Status: Triaged => Invalid

** Changed in: linux (Ubuntu Bionic)
   Status: Triaged => Invalid

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

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

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

** Changed in: apparmor (Ubuntu)
   Importance: Undecided => Critical

** Changed in: apparmor (Ubuntu Xenial)
   Importance: Undecided => Critical

** Changed in: apparmor (Ubuntu Bionic)
   Importance: Undecided => Critical

** Changed in: linux (Ubuntu)
   Importance: Critical => Undecided

** Changed in: linux (Ubuntu Xenial)
   Importance: High => Undecided

** Changed in: linux (Ubuntu Bionic)
   Importance: High => Undecided

** Changed in: apparmor (Ubuntu)
 Assignee: (unassigned) => John Johansen (jjohansen)

** Changed in: apparmor (Ubuntu Xenial)
 Assignee: (unassigned) => John Johansen (jjohansen)

** Changed in: apparmor (Ubuntu Bionic)
 Assignee: (unassigned) => John Johansen (jjohansen)

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

Title:
  locking sockets broken due to missing AppArmor socket mediation
  patches

Status in apparmor package in Ubuntu:
  Triaged
Status in linux package in Ubuntu:
  Invalid
Status in apparmor source package in Xenial:
  Triaged
Status in linux source package in Xenial:
  Invalid
Status in apparmor source package in Bionic:
  Triaged
Status in linux source package in Bionic:
  Invalid

Bug description:
  Hey,

  Newer systemd makes use of locks placed on AF_UNIX sockets created
  with the socketpair() syscall to synchronize various bits and pieces
  when isolating services. On kernels prior to 4.18 that do not have
  backported the AppArmor socket mediation patchset this will cause the
  locks to be denied with EACCESS. This causes systemd to be broken in
  LXC and LXD containers that do not run unconfined which is a pretty
  big deal. We have seen various bug reports related to this. See for
  example [1] and [2].

  If feasible it would be excellent if we could backport the socket
  mediation patchset to all LTS kernels. Afaict, this should be 4.4 and
  4.15. This will unbreak a whole range of use-cases.

  The socket mediation patchset is available here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4

  
  [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
  [2]: https://github.com/systemd/systemd/issues/9493

  Thanks!
  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+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 1780227] Re: locking sockets broken due to missing AppArmor socket mediation patches

2018-07-24 Thread Stéphane Graber
In preparation for an SRU, here is a minimal C testcase provided by
Wolfgang Bumiller:

```
/*
# apparmor_parser -r /etc/apparmor.d/bug-profile
# (tested without the flags here as well btw.)
profile bug-profile flags=(attach_disconnected,mediate_deleted) {
   network,
   file,
   unix,
}

# gcc this.c
# ./a.out
lock = 2 (Success)
# aa-exec -p bug-profile ./a.out
lock = 2 (Permission denied)

kernel: audit: type=1400 audit(1530774919.510:93): apparmor="DENIED" 
operation="file_lock" profile="bug-profile" pid=21788 comm="a.out" 
family="unix" sock_type="dgram" protocol=0 addr=none
*/

#include 
#include 
#include 
#include 
#include 
#include 

int
main(int argc, char **argv)
{
 int sp[2];
 if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sp) != 0) {
  perror("socketpair");
  exit(1);
 }
 int rc = flock(sp[0], LOCK_EX);
 printf("lock = %i (%m)\n");

 close(sp[0]);
 close(sp[1]);
 return 0;
}
```

Another very easy way to reproduce the issue is to run "hostnamectl
status" inside a container which will hang as the systemd unit (socket
activated) will fail to trigger.

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

Title:
  locking sockets broken due to missing AppArmor socket mediation
  patches

Status in apparmor package in Ubuntu:
  Triaged
Status in linux package in Ubuntu:
  Invalid
Status in apparmor source package in Xenial:
  Triaged
Status in linux source package in Xenial:
  Invalid
Status in apparmor source package in Bionic:
  Triaged
Status in linux source package in Bionic:
  Invalid

Bug description:
  Hey,

  Newer systemd makes use of locks placed on AF_UNIX sockets created
  with the socketpair() syscall to synchronize various bits and pieces
  when isolating services. On kernels prior to 4.18 that do not have
  backported the AppArmor socket mediation patchset this will cause the
  locks to be denied with EACCESS. This causes systemd to be broken in
  LXC and LXD containers that do not run unconfined which is a pretty
  big deal. We have seen various bug reports related to this. See for
  example [1] and [2].

  If feasible it would be excellent if we could backport the socket
  mediation patchset to all LTS kernels. Afaict, this should be 4.4 and
  4.15. This will unbreak a whole range of use-cases.

  The socket mediation patchset is available here:
  
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=80a17a5f501ea048d86f81d629c94062b76610d4

  
  [1]: https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1575779
  [2]: https://github.com/systemd/systemd/issues/9493

  Thanks!
  Christian

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1780227/+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 1760173] Re: zfs, zpool commands hangs for 10 seconds without a /dev/zfs

2018-06-07 Thread Stéphane Graber
Not really, no. You can use systemd-detect-virt which is systemd
specific but should work as a regular user, otherwise you can try to add
some specialized checks like looking if /dev in the mount table is
devtmpfs or not.

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

Title:
  zfs, zpool commands hangs for 10 seconds without a /dev/zfs

Status in lxd package in Ubuntu:
  Invalid
Status in zfs-linux package in Ubuntu:
  Triaged
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Artful:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Committed
Status in zfs-linux source package in Cosmic:
  Triaged

Bug description:
  == SRU Justification, Xenial, Artful, Bionic ==

  When outside a lxd container with zfs storage, zfs list or zpool
  status either returns or reports what's going on.

  When inside a lxd container with zfs storage, zfs list or zpool status
  appears to hang, no output for 10 seconds.

  == Fix ==

  Inside a container we don't need the 10 seconds timeout, so check for
  this scenario and set the timeout to default to 0 seconds.

  == Regression Potential ==

  Minimal, this caters for a corner case inside a containerized
  environment, the fix will not alter the behaviour for other cases.

  -

  1. # lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  2. # apt-cache policy zfsutils-linux
  zfsutils-linux:
    Installed: 0.6.5.6-0ubuntu19
    Candidate: 0.6.5.6-0ubuntu19
    Version table:
   *** 0.6.5.6-0ubuntu19 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status

  3. When inside a lxd container with zfs storage, zfs list or zpool
  status either return or report what's going on.

  4. When inside a lxd container with zfs storage, zfs list or zpool
  status appears to hang, no output for 10 seconds.

  strace reveals that without a /dev/zfs the tools wait for it to appear
  for 10 seconds but do not provide a command line switch to disable or
  make it more verbose.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: zfsutils-linux 0.6.5.6-0ubuntu19
  ProcVersionSignature: Ubuntu 4.13.0-36.40~16.04.1-generic 4.13.13
  Uname: Linux 4.13.0-36-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Fri Mar 30 18:09:29 2018
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: zfs-linux
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1760173/+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 1760173] Re: zfs, zpool commands hangs for 10 seconds without a /dev/zfs

2018-06-07 Thread Stéphane Graber
That's because an attached process ("lxc-attach" or "lxc exec") isn't a
child of init, it's spawned directly by liblxc and so does have our env
variable set.

Any process which is a direct or indirect child of PID1 in the container
will be inheriting its environment through that path and as init systems
strip any inherited environment, the container env variable will not be
set for those.

So for example, sshing into your container will not have the env
variable set, same goes for any systemd unit.

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

Title:
  zfs, zpool commands hangs for 10 seconds without a /dev/zfs

Status in lxd package in Ubuntu:
  Invalid
Status in zfs-linux package in Ubuntu:
  Triaged
Status in zfs-linux source package in Xenial:
  Fix Committed
Status in zfs-linux source package in Artful:
  Fix Committed
Status in zfs-linux source package in Bionic:
  Fix Committed
Status in zfs-linux source package in Cosmic:
  Triaged

Bug description:
  == SRU Justification, Xenial, Artful, Bionic ==

  When outside a lxd container with zfs storage, zfs list or zpool
  status either returns or reports what's going on.

  When inside a lxd container with zfs storage, zfs list or zpool status
  appears to hang, no output for 10 seconds.

  == Fix ==

  Inside a container we don't need the 10 seconds timeout, so check for
  this scenario and set the timeout to default to 0 seconds.

  == Regression Potential ==

  Minimal, this caters for a corner case inside a containerized
  environment, the fix will not alter the behaviour for other cases.

  -

  1. # lsb_release -rd
  Description:  Ubuntu 16.04.4 LTS
  Release:  16.04

  2. # apt-cache policy zfsutils-linux
  zfsutils-linux:
    Installed: 0.6.5.6-0ubuntu19
    Candidate: 0.6.5.6-0ubuntu19
    Version table:
   *** 0.6.5.6-0ubuntu19 500
  500 http://archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status

  3. When inside a lxd container with zfs storage, zfs list or zpool
  status either return or report what's going on.

  4. When inside a lxd container with zfs storage, zfs list or zpool
  status appears to hang, no output for 10 seconds.

  strace reveals that without a /dev/zfs the tools wait for it to appear
  for 10 seconds but do not provide a command line switch to disable or
  make it more verbose.

  ProblemType: Bug
  DistroRelease: Ubuntu 16.04
  Package: zfsutils-linux 0.6.5.6-0ubuntu19
  ProcVersionSignature: Ubuntu 4.13.0-36.40~16.04.1-generic 4.13.13
  Uname: Linux 4.13.0-36-generic x86_64
  ApportVersion: 2.20.1-0ubuntu2.15
  Architecture: amd64
  Date: Fri Mar 30 18:09:29 2018
  ProcEnviron:
   TERM=xterm-256color
   PATH=(custom, no user)
   LANG=C.UTF-8
  SourcePackage: zfs-linux
  UpgradeStatus: No upgrade log present (probably fresh install)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/lxd/+bug/1760173/+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


  1   2   3   >