[Bug 1570472] Re: Set systemd as default service provider

2017-02-27 Thread Ivan Suzdal
@nacc, hello. It's great news! I've tested package from "-proposed" and can confirm it works. But as an always, it would be nice if someone else could confirm. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1570472] Re: Set systemd as default service provider

2016-07-21 Thread Ivan Suzdal
@Nish, after a superficial RCA I can say here is probably some mistake from my side. Perhaps, in previous release (sadly I can't find particular ISO where I faced with issue) were some parts of upstart ('/sbin/start' for example) which causes issue like in comment #8. For now I can't reproduce

[Bug 1570472] Re: Set systemd as default service provider

2016-07-20 Thread Ivan Suzdal
@Nish, from my point of view it's absolutely expected behavior. In this request, we trying to change default puppet service provider from 'upstart' to 'systemd'. So when you change your init system from 'systemd' to 'upstart' - puppet shall fall. Probably we can add another init system checks, but

[Bug 1582328] Re: e1000 Tx Unit Hang

2016-06-16 Thread Ivan Suzdal
Tested on dpkg-query -W -f='${binary:Package}\t${Architecture}\t${Version}\n' linux-image-4.4.0-25-generic linux-image-generic linux-image-4.4.0-25-genericamd64 4.4.0-25.44 linux-image-generic amd64 4.4.0.25.26 Seems to be working fine. I couldn't get any e1000 related errors. **

[Bug 1582328] Re: e1000 Tx Unit Hang

2016-06-01 Thread Ivan Suzdal
Hi all! Is here any ETA for landing this changes into Xenial? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1582328 Title: e1000 Tx Unit Hang To manage notifications about this bug go to:

[Bug 1582328] Re: e1000 Tx Unit Hang

2016-05-16 Thread Ivan Suzdal
e1000 debbiff against Ubuntu xenial release kernel ** Patch added: "e1000-Ubuntu.diff" https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1582328/+attachment/4663956/+files/e1000-Ubuntu.diff -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

[Bug 1582328] [NEW] e1000 Tx Unit Hang

2016-05-16 Thread Ivan Suzdal
Public bug reported: e1000 NIC sporadically hangs, which causes temporary network unavailable. I saw this issue on virtual environment and on real hardware. This issue is already fixed in upstream kernel [0] [1]. I made patches against the current Ubuntu kernel (xenial release). Could you

[Bug 1570472] Re: Set systemd as default service provider

2016-05-11 Thread Ivan Suzdal
@Nish, is any ETA here? Could I help somehow yet? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1570472 Title: Set systemd as default service provider To manage notifications about this bug go to:

[Bug 1570472] Re: Set systemd as default service provider

2016-04-18 Thread Ivan Suzdal
I've tested simple manifest which includes 'ensure service running' on 15.04 and 15.10 and have no faced with any issues. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1570472 Title: Set systemd as

[Bug 1570472] Re: Set systemd as default service provider

2016-04-15 Thread Ivan Suzdal
In my case these changes were enough. Not sure what other changes weren't necessary - I checked on the 16.04 and unfortunately I've no opportunity to check on an early releases. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1570472] [NEW] Set systemd as default service provider

2016-04-14 Thread Ivan Suzdal
Public bug reported: AFAIK, Ubuntu has systemd as default init system since 15.04 release. Although, puppet thinks it's still upstart. This behavior is already fixed in upstream puppet code. Please, add this patch to Xenial puppet package. ** Affects: puppet (Ubuntu) Importance: Undecided

[Bug 1551828] Re: kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-19 Thread Ivan Suzdal
Hi all! Any ETA with series file? Can I help you somehow? -- You received this bug notification because you are a member of Ubuntu Server Team, which is subscribed to multipath-tools in Ubuntu. https://bugs.launchpad.net/bugs/1551828 Title: kpartx causes kernel oops when NVMe devices is not

[Bug 1551828] Re: kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-18 Thread Ivan Suzdal
Hi all! Any ETA with series file? Can I help you somehow? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1551828 Title: kpartx causes kernel oops when NVMe devices is not in blacklist To manage

[Bug 1551828] Re: kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-09 Thread Ivan Suzdal
Looks like you forgot to add nvme patch to debian/patches/series # ls debian/patches/ | grep nvme dm-multipath-backlist-nvme-5c412e47.patch # grep nvme debian/patches/series # ** Tags removed: verification-needed ** Tags added: verification-failed -- You received this bug notification because

[Bug 1551828] Re: kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-09 Thread Ivan Suzdal
Looks like you forgot to add nvme patch to debian/patches/series # ls debian/patches/ | grep nvme dm-multipath-backlist-nvme-5c412e47.patch # grep nvme debian/patches/series # ** Tags removed: verification-needed ** Tags added: verification-failed -- You received this bug notification because

[Bug 1551828] Re: kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-01 Thread Ivan Suzdal
** Description changed: - When on bare metal uses NVMe devices - kpartx cause kernel oops. Also any tools which works with disks (e.g. fdisk, lsblk) hangs in D state (uninterruptible sleep) while trying to to read /dev/dm-X. + When on bare metal uses NVMe devices - kpartx cause kernel oops. +

[Bug 1551828] Re: kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-01 Thread Ivan Suzdal
** Description changed: - When on bare metal uses NVMe devices - kpartx cause kernel oops. Also any tools which works with disks (e.g. fdisk, lsblk) hangs in D state (uninterruptible sleep) while trying to to read /dev/dm-X. + When on bare metal uses NVMe devices - kpartx cause kernel oops. +

[Bug 1551828] Re: kpartx cause kernel oops when NVMe devices is not in blacklist

2016-03-01 Thread Ivan Suzdal
** Patch added: "xenial nvme blacklist" https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551828/+attachment/4585637/+files/xenial-blacklist-nvme-devices.patch ** Summary changed: - kpartx cause kernel oops when NVMe devices is not in blacklist + kpartx causes kernel oops when

[Bug 1551828] Re: kpartx cause kernel oops when NVMe devices is not in blacklist

2016-03-01 Thread Ivan Suzdal
** Patch added: "xenial nvme blacklist" https://bugs.launchpad.net/ubuntu/+source/multipath-tools/+bug/1551828/+attachment/4585637/+files/xenial-blacklist-nvme-devices.patch ** Summary changed: - kpartx cause kernel oops when NVMe devices is not in blacklist + kpartx causes kernel oops when

[Bug 1551828] [NEW] kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-01 Thread Ivan Suzdal
Public bug reported: When on bare metal uses NVMe devices - kpartx cause kernel oops. Also any tools which works with disks (e.g. fdisk, lsblk) hangs in D state (uninterruptible sleep) while trying to to read /dev/dm-X. This bug is already described and fixed in upstream

[Bug 1551828] [NEW] kpartx causes kernel oops when NVMe devices is not in blacklist

2016-03-01 Thread Ivan Suzdal
Public bug reported: When on bare metal uses NVMe devices - kpartx cause kernel oops. Also any tools which works with disks (e.g. fdisk, lsblk) hangs in D state (uninterruptible sleep) while trying to to read /dev/dm-X. This bug is already described and fixed in upstream