[Bug 1975799] Re: SRU for FastNetMon package

2022-05-26 Thread Vladimir Grevtsev
** Tags added: regression-release -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1975799 Title: SRU for FastNetMon package To manage notifications about this bug go to:

[Bug 1879012] Re: GRUB does not bring up networking when loaded over HTTP

2022-02-07 Thread Vladimir Grevtsev
Hi folks, It looks like the issue is still around - I just got hit by this with MAAS 3.1.0 on Focal. However, replacing grubx64.efi with the one from /usr/lib/grub/x86_64-efi-signed/grubx64.efi.signed made the trick and I was able to boot without any manual intervention. Can we consider

[Bug 1934849] Re: s3 backend takes time exponentially

2021-07-08 Thread Vladimir Grevtsev
I'm facing the same issue and can confirm the suggested fix improves the upload speed dramatically (without it, I had ~3.5min for 200mb image, now the same time is consumed for 10GB image upload). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed

[Bug 1901942] [NEW] Series upgrade (B>F) has failed with MAAS installed from PPA: package maas 2.8.2-8577-g.a3e674063-0ubuntu1~18.04.1 failed to install/upgrade: new maas package pre-installation scri

2020-10-28 Thread Vladimir Grevtsev
Public bug reported: Steps to reproduce: 1. Get a clean Bionic machine 2. sudo add-apt-repository ppa:maas/2.8; sudo apt update; sudo apt upgrade -y 3. Run a do-release-upgrade 4. Upgrade will fail: Could not install the upgrades The upgrade has aborted. Your system could be in an unusable

[Bug 1901942] Re: Series upgrade (B>F) has failed with MAAS installed from PPA: package maas 2.8.2-8577-g.a3e674063-0ubuntu1~18.04.1 failed to install/upgrade: new maas package pre-installation script

2020-10-28 Thread Vladimir Grevtsev
** Summary changed: - package maas 2.8.2-8577-g.a3e674063-0ubuntu1~18.04.1 failed to install/upgrade: new maas package pre-installation script subprocess returned error exit status 1 + Series upgrade (B>F) has failed with MAAS installed from PPA: package maas

[Bug 1896617] Re: [SRU] Creation of image (or live snapshot) from the existing VM fails if libvirt-image-backend is configured to qcow2 starting from Ussuri

2020-09-24 Thread Vladimir Grevtsev
However, the above has broken the new instance creation: $ os server show demo-http -f yaml OS-DCF:diskConfig: MANUAL OS-EXT-AZ:availability_zone: '' OS-EXT-SRV-ATTR:host: null OS-EXT-SRV-ATTR:hypervisor_hostname: null OS-EXT-SRV-ATTR:instance_name: instance-02d8 OS-EXT-STS:power_state:

[Bug 1896617] Re: [SRU] Creation of image (or live snapshot) from the existing VM fails if libvirt-image-backend is configured to qcow2 starting from Ussuri

2020-09-24 Thread Vladimir Grevtsev
Workaround that finally worked for me: juju run --application nova-compute-kvm 'sudo usermod -G kvm,libvirt- qemu libvirt-qemu; sudo service libvirt-guests restart' -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1896617] Re: [SRU] Creation of image (or live snapshot) from the existing VM fails if libvirt-image-backend is configured to qcow2 starting from Ussuri

2020-09-24 Thread Vladimir Grevtsev
Can confirm that 'service libvirt-guests restart' did the trick (I was restarting the libvirtd itself). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1896617 Title: [SRU] Creation of image (or live

[Bug 1896617] Re: [SRU] Creation of image (or live snapshot) from the existing VM fails if libvirt-image-backend is configured to qcow2 starting from Ussuri

2020-09-24 Thread Vladimir Grevtsev
Can confirm that > Dropping libvirt-qemu from nova in /etc/group fixes this as a work- around. AND restarting the compute node helped. Without the reboot the fix didn't get applied (probably, I had to restart something else rather than libvirtd and nova-compute services). -- You received this

[Bug 1896617] Re: Creation of image (or live snapshot) from the existing VM fails if libvirt-image-backend is configured to qcow2 starting from Ussuri

2020-09-23 Thread Vladimir Grevtsev
@Corey, you're mentioning that it works on instance with id 049f but it was in SHUTOFF state (thus it was working), but if you'd start the instance: $ os server list | 049f76c6-3f6d-4299-b332-bf4c264b8741 | ubuntu-tests2 | SHUTOFF | internal=10.0.0.30 |

[Bug 1649397] Re: maas-dhcpd.service won't start

2020-06-05 Thread Vladimir Grevtsev
Got the same today with MAAS 2.6.2 $ sudo service maas-dhcpd status ● maas-dhcpd.service - MAAS instance of ISC DHCP server for IPv4 Loaded: loaded (/lib/systemd/system/maas-dhcpd.service; enabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-06-05 14:54:44

[Bug 1861789] Re: [SRU] ceph 14.2.8

2020-04-07 Thread Vladimir Grevtsev
Any chance to get this SRU into the Bionic? bionic-proposed still contains 14.2.4 which fails (LP: #1871362) $ sudo apt-cache policy ceph-osd ceph-osd: Installed: 14.2.4-0ubuntu0.19.10.1~cloud0 Candidate: 14.2.4-0ubuntu0.19.10.1~cloud0 Version table: *** 14.2.4-0ubuntu0.19.10.1~cloud0 500

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-02-13 Thread Vladimir Grevtsev
For information: I have redeployed the same bundle [with only difference - removed Livepatch references] on similar hardware and no reproducer here - all symlinks are in-place. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu.

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-01-24 Thread Vladimir Grevtsev
Just have run an 'udevadm trigger' before Vault unlocking and looks like it's getting that links back: $ juju run --application ceph-osd 'sudo udevadm trigger -ubuntu@ln-sv-infr01:~$ juju run --application ceph-osd 'sudo udevadm trigger --subsystem-match=block --action=add' - Stdout: ""

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-01-24 Thread Vladimir Grevtsev
Third redeployment: $ juju status | pastebinit http://paste.ubuntu.com/p/Y2Sdv4QJFm/ $ juju run --application ceph-osd 'ls -lah /dev/disk/by-dname | wc -l' | pastebinit http://paste.ubuntu.com/p/7CxBPzrqhY/ -- You received this bug notification because you are a member of Ubuntu Bugs, which

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-01-24 Thread Vladimir Grevtsev
It's failing somewhere in between: https://pastebin.canonical.com/p/bBSkf7mh9f/ (take a look at ln-sv- ostk05, it's already missing some bcaches); however they were there (see previous comment). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-01-24 Thread Vladimir Grevtsev
I just captured this once more after starting an openstack bundle deployment: https://pastebin.canonical.com/p/dhc8tBqt8Q/ So, workaround with inserting udevadm settle/trigger to cloudinit- userdata will not help there as it's being executed on node initial deployment, but nodes already have all

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-01-24 Thread Vladimir Grevtsev
Just did two deployments of simple single charm in a row to exclude some openstack charm influence: Pass 1: https://paste.ubuntu.com/p/qCt7WhHbzv/, http://paste.ubuntu.com/p/cxQ9qgY7gZ/ Pass 2: http://paste.ubuntu.com/p/Yn7ZYVSNzH/ http://paste.ubuntu.com/p/Hp5zcdGZKH/,

[Bug 1812925] Re: No OSDs has been initialized in random unit with "No block devices detected using current configuration"

2019-01-24 Thread Vladimir Grevtsev
After systems being idle for ~2h currently it looks like they have all the symlinks in-place: $ juju run --application ceph-osd 'ls -lah /dev/disk/by-dname | wc -l' | pastebinit http://paste.ubuntu.com/p/rDH57vGjKP/ $ ls -l /dev/disk/by-dname/ total 0 lrwxrwxrwx 1 root root 13 Jan 24 15:16

[Bug 1793901] Re: kernel oops in bcache module

2019-01-10 Thread Vladimir Grevtsev
We have a reproducer now: $ uname -a Linux ln-sv-infr01 4.15.0-42-generic #45-Ubuntu SMP Thu Nov 15 19:32:57 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux $ lsblk NAMEMAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:00 3.7T 0 disk ├─sda1

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

2018-12-14 Thread Vladimir Grevtsev
Subscribing field-medium as workaround (e.g not to use 2048mb ram VMs) exists, but solution still need to be found. Also, before yesterday (e.g on libvirt 1:2.11+dfsg-1ubuntu7.8 + maas 2.5rc2) worked fine. -- You received this bug notification because you are a member of Ubuntu Bugs, which is

[Bug 1797581] Re: Composing a VM in MAAS with exactly 2048 MB RAM causes the VM to kernel panic

2018-12-14 Thread Vladimir Grevtsev
Reproduced today on MAAS 2.5 / latest Bionic. qemu/maas versions: https://paste.ubuntu.com/p/kDk3c9tVFX/ good vm dump: http://paste.ubuntu.com/p/zTW2p6JGQJ/ good vm log: http://paste.ubuntu.com/p/V7GP9KgP8S/ good vm serial output: http://paste.ubuntu.com/p/FDymQcH8qD/ bad vm dump:

[Bug 1795424] Re: [SRU] queens stable releases

2018-10-09 Thread Vladimir Grevtsev
Just FYI to whom it may concern: https://bugs.launchpad.net/neutron/+bug/1782576 is included into 12.0.4 SRU and I can confirm that it will resolve issue above (and unblock further movement of https://bugs.launchpad.net/charm-neutron- api/+bug/178739). -- You received this bug notification