[Kernel-packages] [Bug 1815844] Change abandoned on charm-nova-compute (master)
Change abandoned by "Alex Kavanagh " on branch: master Review: https://review.opendev.org/c/openstack/charm-nova-compute/+/639719 Reason: Abandoning as submitter put a hold on it but hasn't revisited in 4 years. Please feel free to re-open it if it is still valid. -- 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/1815844 Title: iscsi multipath dm-N device only used on first volume attachment Status in OpenStack Nova Compute Charm: Invalid Status in OpenStack Compute (nova): Invalid Status in os-brick: Invalid Status in linux package in Ubuntu: Expired Bug description: With nova-compute from cloud:xenial-queens and use-multipath=true iscsi multipath is configured and the dm-N devices used on the first attachment but subsequent attachments only use a single path. The back-end storage is a Purestorage array. The multipath.conf is attached The issue is easily reproduced as shown below: jog@pnjostkinfr01:~⟫ openstack volume create pure2 --size 10 --type pure +-+--+ | Field | Value| +-+--+ | attachments | [] | | availability_zone | nova | | bootable| false| | consistencygroup_id | None | | created_at | 2019-02-13T23:07:40.00 | | description | None | | encrypted | False| | id | e286161b-e8e8-47b0-abe3-4df411993265 | | migration_status| None | | multiattach | False| | name| pure2| | properties | | | replication_status | None | | size| 10 | | snapshot_id | None | | source_volid| None | | status | creating | | type| pure | | updated_at | None | | user_id | c1fa4ae9a0b446f2ba64eebf92705d53 | +-+--+ jog@pnjostkinfr01:~⟫ openstack volume show pure2 ++--+ | Field | Value| ++--+ | attachments| [] | | availability_zone | nova | | bootable | false| | consistencygroup_id| None | | created_at | 2019-02-13T23:07:40.00 | | description| None | | encrypted | False| | id | e286161b-e8e8-47b0-abe3-4df411993265 | | migration_status | None | | multiattach| False| | name | pure2| | os-vol-host-attr:host | cinder@cinder-pure#cinder-pure | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 9be499fd1eee48dfb4dc6faf3cc0a1d7 | | properties | | | replication_status | None | | size | 10 | | snapshot_id| None | | source_volid | None | | status | available| | type | pure | | updated_at | 2019-02-13T23:07:41.00 | | user_id| c1fa4ae9a0b446f2ba64eebf92705d53 | ++--+ Add the volume to an instance: jog@pnjostkinfr01:~⟫ openstack server add volume T1 pure2 jog@pnjostkinfr01:~⟫ openstack server show T1
[Kernel-packages] [Bug 1834213] Fix included in openstack/neutron 22.0.0.0rc1
This issue was fixed in the openstack/neutron 22.0.0.0rc1 release candidate. -- 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/1834213 Title: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances Status in OpenStack Neutron Open vSwitch Charm: Fix Released Status in neutron: Fix Released Status in linux package in Ubuntu: Confirmed Bug description: With an environment running Xenial-Queens, and having just upgraded the linux-image-generic kernel for MDS patching, a few of our hypervisor hosts that were rebooted (3 out of 100) ended up dropping IP (tcp/udp) ingress traffic. It turns out that nf_conntrack module was loaded, but nf_conntrack_ipv4 was not loading, and the traffic was being dropped by this rule: table=72, n_packets=214989, priority=50,ct_state=+inv+trk actions=resubmit(,93) The ct_state "inv" means invalid conntrack state, which the manpage describes as: The state is invalid, meaning that the connection tracker couldn’t identify the connection. This flag is a catch- all for problems in the connection or the connection tracker, such as: • L3/L4 protocol handler is not loaded/unavailable. With the Linux kernel datapath, this may mean that the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules are not loaded. • L3/L4 protocol handler determines that the packet is malformed. • Packets are unexpected length for protocol. It appears that there may be an issue when patching the OS of a hypervisor not running instances may fail to update initrd to load nf_conntrack_ipv4 (and/or _ipv6). I couldn't find anywhere in the charm code that this would be loaded unless the charm's "harden" option is used on nova-compute charm (see charmhelpers contrib/host templates). It is unset in our environment, so we are not using any special module probing. Did nf_conntrack_ipv4 get split out from nf_conntrack in recent kernel upgrades or is it possible that the charm should define a modprobe file if we have the OVS firewall driver configured? To manage notifications about this bug go to: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1834213/+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 1834213] Re: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances
Reviewed: https://review.opendev.org/c/openstack/neutron/+/871659 Committed: https://opendev.org/openstack/neutron/commit/c609084b59c68f003153a58c2063f99b52f169e0 Submitter: "Zuul (22348)" Branch:master commit c609084b59c68f003153a58c2063f99b52f169e0 Author: Brian Haley Date: Tue Jan 24 15:16:47 2023 -0500 Add doc note on nf_conntrack module requirement The OVS firewall driver requires nf_conntrack module(s) to be loaded to function properly. While they are typically loaded automatically, add a note to the admin guide about the requirement to make it explicit. Closes-bug: #1834213 Change-Id: I55871eff1e37d4155b8d2b5ae8c182d160c4af9f ** Changed in: neutron 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/1834213 Title: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances Status in OpenStack Neutron Open vSwitch Charm: Fix Released Status in neutron: Fix Released Status in linux package in Ubuntu: Confirmed Bug description: With an environment running Xenial-Queens, and having just upgraded the linux-image-generic kernel for MDS patching, a few of our hypervisor hosts that were rebooted (3 out of 100) ended up dropping IP (tcp/udp) ingress traffic. It turns out that nf_conntrack module was loaded, but nf_conntrack_ipv4 was not loading, and the traffic was being dropped by this rule: table=72, n_packets=214989, priority=50,ct_state=+inv+trk actions=resubmit(,93) The ct_state "inv" means invalid conntrack state, which the manpage describes as: The state is invalid, meaning that the connection tracker couldn’t identify the connection. This flag is a catch- all for problems in the connection or the connection tracker, such as: • L3/L4 protocol handler is not loaded/unavailable. With the Linux kernel datapath, this may mean that the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules are not loaded. • L3/L4 protocol handler determines that the packet is malformed. • Packets are unexpected length for protocol. It appears that there may be an issue when patching the OS of a hypervisor not running instances may fail to update initrd to load nf_conntrack_ipv4 (and/or _ipv6). I couldn't find anywhere in the charm code that this would be loaded unless the charm's "harden" option is used on nova-compute charm (see charmhelpers contrib/host templates). It is unset in our environment, so we are not using any special module probing. Did nf_conntrack_ipv4 get split out from nf_conntrack in recent kernel upgrades or is it possible that the charm should define a modprobe file if we have the OVS firewall driver configured? To manage notifications about this bug go to: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1834213/+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 1834213] Re: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances
Fix proposed to branch: master Review: https://review.opendev.org/c/openstack/neutron/+/871659 ** Changed in: neutron Status: New => In Progress -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1834213 Title: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances Status in OpenStack Neutron Open vSwitch Charm: Fix Released Status in neutron: In Progress Status in linux package in Ubuntu: Confirmed Bug description: With an environment running Xenial-Queens, and having just upgraded the linux-image-generic kernel for MDS patching, a few of our hypervisor hosts that were rebooted (3 out of 100) ended up dropping IP (tcp/udp) ingress traffic. It turns out that nf_conntrack module was loaded, but nf_conntrack_ipv4 was not loading, and the traffic was being dropped by this rule: table=72, n_packets=214989, priority=50,ct_state=+inv+trk actions=resubmit(,93) The ct_state "inv" means invalid conntrack state, which the manpage describes as: The state is invalid, meaning that the connection tracker couldn’t identify the connection. This flag is a catch- all for problems in the connection or the connection tracker, such as: • L3/L4 protocol handler is not loaded/unavailable. With the Linux kernel datapath, this may mean that the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules are not loaded. • L3/L4 protocol handler determines that the packet is malformed. • Packets are unexpected length for protocol. It appears that there may be an issue when patching the OS of a hypervisor not running instances may fail to update initrd to load nf_conntrack_ipv4 (and/or _ipv6). I couldn't find anywhere in the charm code that this would be loaded unless the charm's "harden" option is used on nova-compute charm (see charmhelpers contrib/host templates). It is unset in our environment, so we are not using any special module probing. Did nf_conntrack_ipv4 get split out from nf_conntrack in recent kernel upgrades or is it possible that the charm should define a modprobe file if we have the OVS firewall driver configured? To manage notifications about this bug go to: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1834213/+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 1815844] Change abandoned on os-brick (master)
Change abandoned by Sean McGinnis (sean.mcgin...@gmail.com) on branch: master Review: https://review.opendev.org/638639 Reason: After reading the bug report, I'm going to abandon this. Feel free to restore and update if there is anything else to be 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/1815844 Title: iscsi multipath dm-N device only used on first volume attachment Status in OpenStack nova-compute charm: Invalid Status in OpenStack Compute (nova): Invalid Status in os-brick: Invalid Status in linux package in Ubuntu: Expired Bug description: With nova-compute from cloud:xenial-queens and use-multipath=true iscsi multipath is configured and the dm-N devices used on the first attachment but subsequent attachments only use a single path. The back-end storage is a Purestorage array. The multipath.conf is attached The issue is easily reproduced as shown below: jog@pnjostkinfr01:~⟫ openstack volume create pure2 --size 10 --type pure +-+--+ | Field | Value| +-+--+ | attachments | [] | | availability_zone | nova | | bootable| false| | consistencygroup_id | None | | created_at | 2019-02-13T23:07:40.00 | | description | None | | encrypted | False| | id | e286161b-e8e8-47b0-abe3-4df411993265 | | migration_status| None | | multiattach | False| | name| pure2| | properties | | | replication_status | None | | size| 10 | | snapshot_id | None | | source_volid| None | | status | creating | | type| pure | | updated_at | None | | user_id | c1fa4ae9a0b446f2ba64eebf92705d53 | +-+--+ jog@pnjostkinfr01:~⟫ openstack volume show pure2 ++--+ | Field | Value| ++--+ | attachments| [] | | availability_zone | nova | | bootable | false| | consistencygroup_id| None | | created_at | 2019-02-13T23:07:40.00 | | description| None | | encrypted | False| | id | e286161b-e8e8-47b0-abe3-4df411993265 | | migration_status | None | | multiattach| False| | name | pure2| | os-vol-host-attr:host | cinder@cinder-pure#cinder-pure | | os-vol-mig-status-attr:migstat | None | | os-vol-mig-status-attr:name_id | None | | os-vol-tenant-attr:tenant_id | 9be499fd1eee48dfb4dc6faf3cc0a1d7 | | properties | | | replication_status | None | | size | 10 | | snapshot_id| None | | source_volid | None | | status | available| | type | pure | | updated_at | 2019-02-13T23:07:41.00 | | user_id| c1fa4ae9a0b446f2ba64eebf92705d53 | ++--+ Add the volume to an instance: jog@pnjostkinfr01:~⟫ openstack server add volume T1 pure2 jog@pnjostkinfr01:~⟫ openstack server show T1
[Kernel-packages] [Bug 1834213] Re: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances
Reviewed: https://review.opendev.org/678956 Committed: https://git.openstack.org/cgit/openstack/charm-neutron-openvswitch/commit/?id=b76a59299794700fae1878af513c90ca5182a9f6 Submitter: Zuul Branch:master commit b76a59299794700fae1878af513c90ca5182a9f6 Author: tpsilva Date: Tue Aug 27 17:41:24 2019 -0300 Explicitly load nf_conntrack_ipv4 module When neutron-openvswitch-agent is using the openvswitch firewall, it needs the nf_conntrack_ipv4 module to be loaded. Usually, this module gets loaded by some other external tool, but in case this does not happen, neither the charm nor neutron will load it, so all traffic to the instances in this host will fail. This patch fixes that by explicitly loading the module. Change-Id: Ia788e870c124de7da17961c02259cfe80938e5d2 Closes-bug: #1834213 ** Changed in: charm-neutron-openvswitch Status: In Progress => Fix Committed -- 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/1834213 Title: After kernel upgrade, nf_conntrack_ipv4 module unloaded, no IP traffic to instances Status in OpenStack neutron-openvswitch charm: Fix Committed Status in linux package in Ubuntu: Confirmed Bug description: With an environment running Xenial-Queens, and having just upgraded the linux-image-generic kernel for MDS patching, a few of our hypervisor hosts that were rebooted (3 out of 100) ended up dropping IP (tcp/udp) ingress traffic. It turns out that nf_conntrack module was loaded, but nf_conntrack_ipv4 was not loading, and the traffic was being dropped by this rule: table=72, n_packets=214989, priority=50,ct_state=+inv+trk actions=resubmit(,93) The ct_state "inv" means invalid conntrack state, which the manpage describes as: The state is invalid, meaning that the connection tracker couldn’t identify the connection. This flag is a catch- all for problems in the connection or the connection tracker, such as: • L3/L4 protocol handler is not loaded/unavailable. With the Linux kernel datapath, this may mean that the nf_conntrack_ipv4 or nf_conntrack_ipv6 modules are not loaded. • L3/L4 protocol handler determines that the packet is malformed. • Packets are unexpected length for protocol. It appears that there may be an issue when patching the OS of a hypervisor not running instances may fail to update initrd to load nf_conntrack_ipv4 (and/or _ipv6). I couldn't find anywhere in the charm code that this would be loaded unless the charm's "harden" option is used on nova-compute charm (see charmhelpers contrib/host templates). It is unset in our environment, so we are not using any special module probing. Did nf_conntrack_ipv4 get split out from nf_conntrack in recent kernel upgrades or is it possible that the charm should define a modprobe file if we have the OVS firewall driver configured? To manage notifications about this bug go to: https://bugs.launchpad.net/charm-neutron-openvswitch/+bug/1834213/+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 1801349] Related fix merged to charm-lxd (master)
Reviewed: https://review.openstack.org/609024
Committed:
https://git.openstack.org/cgit/openstack/charm-lxd/commit/?id=ff0ee580b808102be534c3f6035bcc157799c325
Submitter: Zuul
Branch:master
commit ff0ee580b808102be534c3f6035bcc157799c325
Author: Ryan Beisner
Date: Tue Oct 9 09:46:54 2018 -0500
Update func tests and sync charm-helpers
dev-basic-cosmic-rocky stays due to:
https://bugs.launchpad.net/charm-lxd/+bug/1801349
Change-Id: I4d00957e8092b1fefc71e337237aefb38b292914
Related-Bug: #1801349
--
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/1801349
Title:
zpool create -f lxd /dev/vdb fails on cosmic (18.10) -- func27
Status in OpenStack LXD Charm:
New
Status in linux package in Ubuntu:
In Progress
Bug description:
Test: tests/gate-basic-cosmic-rocky
As part of the config, the lxd charm creates a pool device depending
on the config. The test config is:
lxd_config = {
'block-devices': '/dev/vdb',
'ephemeral-unmount': '/mnt',
'storage-type': 'zfs',
'overwrite': True
}
The config drive is normally mounted on /mnt, and the lxd charm
umounts it as part of the start up. The /etc/fstab on the unit is:
# cat /etc/fstab
LABEL=cloudimg-rootfs /ext4 defaults0 0
LABEL=UEFI /boot/efi vfatdefaults0 0
/dev/vdb/mntauto
defaults,nofail,x-systemd.requires=cloud-init.service,comment=cloudconfig
0 2
/dev/vdcnoneswapsw,comment=cloudconfig 0 0
However, even after umount-ing the /mnt off of /dev/vdb, the zpool create
command still fails:
# zpool create -f lxd /dev/vdb
/dev/vdb is in use and contains a unknown filesystem.
If the /etc/fstab is edited so that /dev/vdb is *never* mounted and then
rebooted, then the zpool create command succeeds:
# zpool list
NAME SIZE ALLOC FREE EXPANDSZ FRAGCAP DEDUP HEALTH ALTROOT
lxd 14.9G 106K 14.9G - 0% 0% 1.00x ONLINE -
# zpool status lxd
pool: lxd
state: ONLINE
scan: none requested
config:
NAMESTATE READ WRITE CKSUM
lxd ONLINE 0 0 0
vdb ONLINE 0 0 0
errors: No known data errors
Something odd is going on with cosmic (18.10) and the combination of
lxd, zfs and the kernel
lxd version: 3.6
zfsutils-linux/cosmic,now 0.7.9-3ubuntu6
Linux: 4.18.0-10-generic
To manage notifications about this bug go to:
https://bugs.launchpad.net/charm-lxd/+bug/1801349/+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 1672361] Fix included in openstack/tripleo-puppet-elements 5.3.2
This issue was fixed in the openstack/tripleo-puppet-elements 5.3.2 release. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to crash in Ubuntu. https://bugs.launchpad.net/bugs/1672361 Title: Ubuntu 17.04: Crash tool fails with error "crash: invalid structure size: tnt". Status in crash package in Ubuntu: Fix Released Bug description: Please cherry pick Upstream commit 651c824ffe2fd7eb8e416dbf4ff5c9a1da6ef7c6 commit 24a696228c56fd4354d29abe05b206373e0c8bfb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1672361/+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 1672361] Fix included in openstack/tripleo-puppet-elements 7.0.0.0rc1
This issue was fixed in the openstack/tripleo-puppet-elements 7.0.0.0rc1 release candidate. -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to crash in Ubuntu. https://bugs.launchpad.net/bugs/1672361 Title: Ubuntu 17.04: Crash tool fails with error "crash: invalid structure size: tnt". Status in crash package in Ubuntu: Fix Released Bug description: Please cherry pick Upstream commit 651c824ffe2fd7eb8e416dbf4ff5c9a1da6ef7c6 commit 24a696228c56fd4354d29abe05b206373e0c8bfb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/crash/+bug/1672361/+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 1311987] Re: deploy-ironic ramdisks do not boot: Failed to execute /init (error -28)
Reviewed: https://review.openstack.org/100698 Committed: https://git.openstack.org/cgit/openstack-dev/devstack/commit/?id=cd1cf1b41753a0d05a814f2a7817522b7f7e7b91 Submitter: Jenkins Branch:stable/icehouse commit cd1cf1b41753a0d05a814f2a7817522b7f7e7b91 Author: Adam Gandelman ad...@ubuntu.com Date: Mon Apr 28 14:06:42 2014 -0700 Bump minimum default RAM for Ironic nodes to 1GB Set the default RAM for Ironic BM VMs to 1GB to ensure DIB produced deployment ramdisks function correctly across older and newer kernels, regardless of rootfstype. Change-Id: Ifc15a4430aa63c3599e7fd76f5116dc7b728ead0 Closes-bug: #1311987 (cherry picked from commit 74eafa4b49dcf2f76b7627739d26e457fa1775db) ** Tags added: in-stable-icehouse -- 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/1311987 Title: deploy-ironic ramdisks do not boot: Failed to execute /init (error -28) Status in devstack - openstack dev environments: Fix Released Status in Openstack disk image builder: Triaged Status in “linux” package in Ubuntu: Invalid Bug description: The default ubuntu release for ramdisks was bumped to Trusty https://review.openstack.org/#/c/88384/ Ironic + devstack deployments stopped functioning. The ramdisk fails to run init, crashing with the following error: [ 23.154016] Failed to execute /init (error -28) [ 23.154909] Starting init: /sbin/init exists but couldn't execute it (error -28) [ 23.156388] Starting init: /bin/init exists but couldn't execute it (error -28) [ 23.157490] Starting init: /bin/sh exists but couldn't execute it (error -28) [ 23.160313] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. [ 23.164146] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-24-generic #46-Ubuntu [ 23.164146] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 23.164146] 88001a3a9ec0 81715a64 81a39f38 [ 23.164146] 88001a3a9f38 8170ec65 0008 88001a3a9f48 [ 23.164146] 88001a3a9ee8 81a39a38 13981396 1396 [ 23.164146] Call Trace: [ 23.164146] [81715a64] dump_stack+0x45/0x56 [ 23.164146] [8170ec65] panic+0xc8/0x1d7 [ 23.164146] [81703f40] ? rest_init+0x80/0x80 [ 23.164146] [81704062] kernel_init+0x122/0x130 [ 23.164146] [8172637c] ret_from_fork+0x7c/0xb0 [ 23.164146] [81703f40] ? rest_init+0x80/0x80 [ 23.164146] general protection fault: fff2 [#1] SMP [ 23.164146] Modules linked in: [ 23.164146] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-24-generic #46-Ubuntu [ 23.164146] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 23.164146] task: 88001a3a ti: 88001a3a8000 task.ti: 88001a3a8000 [ 23.164146] RIP: 0010:[8170ed30] [8170ed30] panic+0x193/0x1d7 [ 23.164146] RSP: :88001a3a9ed0 EFLAGS: 0246 [ 23.164146] RAX: 14a814a8 RBX: 81a39f38 RCX: 0854 [ 23.164146] RDX: 14a8 RSI: RDI: 0046 #define ENOSPC 28 /* No space left on device */ Setting DIB_RELEASE=saucy fixes the issue.A saucy ramdisk is 83M compressed, 238M decompressed. trusty ramdisk is 87M compressed, 245M decompressed. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1311987/+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 1311987] Fix proposed to devstack (stable/icehouse)
Fix proposed to branch: stable/icehouse Review: https://review.openstack.org/100698 -- 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/1311987 Title: deploy-ironic ramdisks do not boot: Failed to execute /init (error -28) Status in devstack - openstack dev environments: Fix Released Status in Openstack disk image builder: Triaged Status in “linux” package in Ubuntu: Invalid Bug description: The default ubuntu release for ramdisks was bumped to Trusty https://review.openstack.org/#/c/88384/ Ironic + devstack deployments stopped functioning. The ramdisk fails to run init, crashing with the following error: [ 23.154016] Failed to execute /init (error -28) [ 23.154909] Starting init: /sbin/init exists but couldn't execute it (error -28) [ 23.156388] Starting init: /bin/init exists but couldn't execute it (error -28) [ 23.157490] Starting init: /bin/sh exists but couldn't execute it (error -28) [ 23.160313] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/init.txt for guidance. [ 23.164146] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-24-generic #46-Ubuntu [ 23.164146] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 23.164146] 88001a3a9ec0 81715a64 81a39f38 [ 23.164146] 88001a3a9f38 8170ec65 0008 88001a3a9f48 [ 23.164146] 88001a3a9ee8 81a39a38 13981396 1396 [ 23.164146] Call Trace: [ 23.164146] [81715a64] dump_stack+0x45/0x56 [ 23.164146] [8170ec65] panic+0xc8/0x1d7 [ 23.164146] [81703f40] ? rest_init+0x80/0x80 [ 23.164146] [81704062] kernel_init+0x122/0x130 [ 23.164146] [8172637c] ret_from_fork+0x7c/0xb0 [ 23.164146] [81703f40] ? rest_init+0x80/0x80 [ 23.164146] general protection fault: fff2 [#1] SMP [ 23.164146] Modules linked in: [ 23.164146] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 3.13.0-24-generic #46-Ubuntu [ 23.164146] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [ 23.164146] task: 88001a3a ti: 88001a3a8000 task.ti: 88001a3a8000 [ 23.164146] RIP: 0010:[8170ed30] [8170ed30] panic+0x193/0x1d7 [ 23.164146] RSP: :88001a3a9ed0 EFLAGS: 0246 [ 23.164146] RAX: 14a814a8 RBX: 81a39f38 RCX: 0854 [ 23.164146] RDX: 14a8 RSI: RDI: 0046 #define ENOSPC 28 /* No space left on device */ Setting DIB_RELEASE=saucy fixes the issue.A saucy ramdisk is 83M compressed, 238M decompressed. trusty ramdisk is 87M compressed, 245M decompressed. To manage notifications about this bug go to: https://bugs.launchpad.net/devstack/+bug/1311987/+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 1273386] Related fix proposed to neutron (master)
Related fix proposed to branch: master Review: https://review.openstack.org/69653 -- 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/1273386 Title: Neutron namespace metadata proxy triggers kernel crash on Ubuntu 12.04/3.2 kernel Status in OpenStack Neutron (virtual network service): New Status in OpenStack Compute (Nova): New Status in “linux” package in Ubuntu: Incomplete Bug description: In the past 9 days we have been seeing very frequent occurences of this kernel crash: http://paste.openstack.org/show/61869/ Even if the particular crash pasted here is triggered by dnsmasq, in almost all cases the crash is actually triggered by the neutron metada proxy. This also affects nova badly since this issue, which appears namespace related, results in a hang while mounting the ndb device for key injection. logstash query: http://logstash.openstack.org/#eyJzZWFyY2giOiJcImtlcm5lbCBCVUcgYXQgL2J1aWxkL2J1aWxkZC9saW51eC0zLjIuMC9mcy9idWZmZXIuYzoyOTE3XCIgYW5kIGZpbGVuYW1lOnN5c2xvZy50eHQiLCJmaWVsZHMiOltdLCJvZmZzZXQiOjAsInRpbWVmcmFtZSI6ImN1c3RvbSIsImdyYXBobW9kZSI6ImNvdW50IiwidGltZSI6eyJmcm9tIjoiMjAxNC0wMS0xNlQxODo1MDo0OCswMDowMCIsInRvIjoiMjAxNC0wMS0yN1QxOToxNjoxMSswMDowMCIsInVzZXJfaW50ZXJ2YWwiOiIwIn0sInN0YW1wIjoxMzkwODUwMzI2ODY0fQ== We have seen about 398 hits since the bug started to manifest. Decreased hit rate in the past few days is due to less neutron patches being pushed. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1273386/+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
