[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-04-21 Thread Mauricio Faria de Oliveira
Another ceph bugfix release (v14.2.20) has pushed this one release
further, thus at least v14.2.21.

** Description changed:

  [Impact]
  
  The radosgw beast frontend in ceph nautilus might hit coroutine stack
  corruption on startup and requests.
  
  This is usually observed right at the startup of the ceph-radosgw systemd 
unit; sometimes 1 minute later.
  But it might occur any time handling requests, depending on 
coroutine/request's function path/stack size.
  
  The symptoms are usually a crash with stack trace listing TCMalloc 
(de)allocate/release to central cache,
  but less rare signs are large allocs in the _terabytes_ range (pointer to 
stack used as allocation size)
  and stack traces showing function return addresses (RIP) that are actually 
pointers to an stack address.
  
  This is not widely hit in Ubuntu as most deployments use the ceph-radosgw 
charm that hardcodes 'civetweb'
  as rgw frontend, which is _not_ affected; custom/cephadm deployments that 
choose 'beast' might hit this.
  
    @ charm-ceph-radosgw/templates/ceph.conf
  rgw frontends = civetweb port={{ port }}
  
  Let's report this LP bug for documentation and tracking purposes until
  UCA gets the fixes.
  
  [Fix]
  
  This has been reported by an Ubuntu Advantage user, and another user in ceph 
tracker #47910 [1].
  This had been reported and fixed in Octopus [2] (confirmed by UA user; no 
longer affected.)
  
  The Nautilus backport has recently been merged [3, 4] and should be
- available in v14.2.20.
+ available in v14.2.21.
  
  [Test Case]
  
  The conditions to trigger the bug aren't clear, but apparently related to EC 
pools w/ very large buckets,
  and of course the radosgw frontend beast being enabled (civetweb is not 
affected.)
  
  [Where problems could occur]
  
  The fixes are restricted to the beast frontend, specifically to the 
coroutines used to handle requests.
  So problems would probably be seen in request handling only with the beast 
frontend.
  Workarounds thus include switching back to the civetweb frontend.
  
  This changes core/base parts of the RGW beast frontend code, but are in place 
from Octopus released.
  The other user/reporter in the ceph tracker has been using the patches for 
weeks with no regression;
  the ceph tests have passed and likely serious issues would be caught by ceph 
CI upstream.
  
  [1] https://tracker.ceph.com/issues/47910 report tracker (nautilus)
  [2] https://tracker.ceph.com/issues/43739 master tracker (octopus)
  [3] https://tracker.ceph.com/issues/43921 backport tracker (nautilus)
  [4] https://github.com/ceph/ceph/pull/39947 github PR

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749

Title:
  nautilus: ceph radosgw beast frontend coroutine stack corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1921749/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1922561] Re: osd shutdown may flood the cluster log with 'osd.X reported immediately failed by osd.Y'

2021-04-21 Thread Mauricio Faria de Oliveira
New ceph bugfix releases for Nautilus (v14.2.20) and Octopus (v15.2.11)
have pushed this another release further.

Also marking Hirsute as Fix Released (v16.2.0+.)

** Description changed:

  [Impact]
  
  The `osd_fast_shutdown` option (available in Nautilus and enabled
  by default) may cause the cluster log to receive too many entries
  of `osd.X reported immediately failed by osd.Y` on large clusters.
  
  This happens as the monitor no longer receives the OSD message to
  notify that the OSD is shutting down and now relies on other OSDs
  telling it about the failed OSD (not really 'failed' but shutdown.)
  
  This might be an issue for LMA stacks/tools that check ceph logs
  for failed lines, and then require additional logic to filter on
  an intended OSD (fast) shutdown; might not be an option/possible,
  and require an admin to analyze.
  
  [Fix]
  
  The `osd_fast_shutdown_notify_mon` option for OSDs (disabled by
  default) can tell the monitor it is shutting down (done in slow/
  non-fast shutdown) under `osd_fast_shutdown`.
  
  This introduces minimal delay (the ack from the mon is required
  to prevent the messages), and addresses the cluster log issue.
  PS: the `osd_mon_shutdown_timeout` option can be used to control
  the maximum amount of time waiting for the monitor ack to arrive.
  
  The new option should be available in the following Ceph releases:
  - Pacific 16.2.0 [1] [Hirsute+]
- - Octopus 15.2.11 [2] [Focal/Groovy; Ussuri+]
- - Nautilus TBD (at least 14.2.20) [3] [Eoan is EOL; Train]
+ - Octopus 15.2.12 [2] [Focal/Groovy; Ussuri+]
+ - Nautilus 14.2.21) [3] [Eoan is EOL; Train]
  
  This bug tracks the release of this patch in Ubuntu/Cloud Archive.
  
  [Test Case]
  
  - Stop an OSD and watch the OSD and MON logs.
  
  - Before / or with `osd_fast_shutdown_notify_mon = false`:
  
  ```
  osd log:
  
  2021-01-09T18:59:52.448+ 7f937fcdc700 -1 received  signal: Terminated 
from -bash  (PID: 408) UID: 1000
  2021-01-09T18:59:52.448+ 7f937fcdc700 -1 osd.2 22 *** Got signal 
Terminated ***
  2021-01-09T18:59:52.448+ 7f937fcdc700 -1 osd.2 22 *** Immediate shutdown 
(osd_fast_shutdown=true) ***
  
  mon log:
  
  $ cat out/mon.a.log | grep '^2021-01-09T18:59:' | grep 'osd.0 reported 
immediately failed by osd.' | rev | cut -d: -f1 | rev | sort | uniq -c
    4  osd.0 reported immediately failed by osd.1
    4  osd.0 reported immediately failed by osd.2
    4  osd.0 reported immediately failed by osd.3
    4  osd.0 reported immediately failed by osd.4
    4  osd.0 reported immediately failed by osd.5
    4  osd.0 reported immediately failed by osd.6
    4  osd.0 reported immediately failed by osd.7
    4  osd.0 reported immediately failed by osd.8
    4  osd.0 reported immediately failed by osd.9
  ```
  
  - After / with `osd_fast_shutdown_notify_mon = true`:
  
  ```
  osd log:
  
  2021-01-14T17:21:10.825+ 7feceded1700 -1 received  signal: Terminated 
from -bash  (PID: 1750) UID: 1000
  2021-01-14T17:21:10.825+ 7feceded1700 -1 osd.0 80 *** Got signal 
Terminated ***
  2021-01-14T17:21:10.825+ 7feceded1700 -1 osd.0 80 *** Immediate shutdown 
(osd_fast_shutdown=true) ***
  2021-01-14T17:21:10.825+ 7feceded1700  0 osd.0 80 prepare_to_stop telling 
mon we are shutting down
  ...
  2021-01-14T17:21:11.021+ 7fecdac0c700  0 osd.0 80 got_stop_ack starting 
shutdown
  2021-01-14T17:21:11.021+ 7feceded1700  0 osd.0 80 prepare_to_stop 
starting shutdown
  
  mon log:
  
  2021-01-14T17:21:10.829+ 7f62fce61700  0 log_channel(cluster) log [INF] : 
osd.0 marked itself down
  2021-01-14T17:21:10.885+ 7f62ff666700  1 mon.a@0(leader).osd e80 do_prune 
osdmap full prune enabled
  2021-01-14T17:21:10.889+ 7f62ff666700  0 log_channel(cluster) log [WRN] : 
Health check failed: 1 osds down (OSD_DOWN)
  2021-01-14T17:21:10.957+ 7f62fb65e700  1 mon.a@0(leader).osd e81 e81: 10 
total, 9 up, 10 in
  2021-01-14T17:21:11.013+ 7f62fb65e700  0 log_channel(cluster) log [DBG] : 
osdmap e81: 10 total, 9 up, 10 in
  ```
  
  [Where problems could occur]
  
  Any regression from this patch should manifest in OSD shutdown, but only
  when the option is enabled.
  
  The patch is quite small and contained to the OSD shutdown path.
  
  It is effectively a nop when the option is disabled (by default).
  
  It is a small change from the newly introduced default behavior,
  but it just re-introduces a message in the shutdown path, which
  is how it used to be done on previous releases and even earlier
  stable releases in Nautilus.
  
  [1] https://tracker.ceph.com/issues/49683
  [2] https://tracker.ceph.com/issues/49681
  [3] https://tracker.ceph.com/issues/49682

** Changed in: ceph (Ubuntu Hirsute)
   Status: Confirmed => Fix Released

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1922561

Title:
  osd shutdown may flood the 

[Bug 1922561] [NEW] osd shutdown may flood the cluster log with 'osd.X reported immediately failed by osd.Y'

2021-04-05 Thread Mauricio Faria de Oliveira
Public bug reported:

[Impact]

The `osd_fast_shutdown` option (available in Nautilus and enabled
by default) may cause the cluster log to receive too many entries
of `osd.X reported immediately failed by osd.Y` on large clusters.

This happens as the monitor no longer receives the OSD message to
notify that the OSD is shutting down and now relies on other OSDs
telling it about the failed OSD (not really 'failed' but shutdown.)

This might be an issue for LMA stacks/tools that check ceph logs
for failed lines, and then require additional logic to filter on
an intended OSD (fast) shutdown; might not be an option/possible,
and require an admin to analyze.

[Fix]

The `osd_fast_shutdown_notify_mon` option for OSDs (disabled by
default) can tell the monitor it is shutting down (done in slow/
non-fast shutdown) under `osd_fast_shutdown`.

This introduces minimal delay (the ack from the mon is required
to prevent the messages), and addresses the cluster log issue.
PS: the `osd_mon_shutdown_timeout` option can be used to control
the maximum amount of time waiting for the monitor ack to arrive.

The new option should be available in the following Ceph releases:
- Pacific 16.2.0 [1] [Hirsute+]
- Octopus 15.2.11 [2] [Focal/Groovy; Ussuri+]
- Nautilus TBD (at least 14.2.20) [3] [Eoan is EOL; Train]

This bug tracks the release of this patch in Ubuntu/Cloud Archive.

[Test Case]

- Stop an OSD and watch the OSD and MON logs.

- Before / or with `osd_fast_shutdown_notify_mon = false`:

```
osd log:

2021-01-09T18:59:52.448+ 7f937fcdc700 -1 received  signal: Terminated from 
-bash  (PID: 408) UID: 1000
2021-01-09T18:59:52.448+ 7f937fcdc700 -1 osd.2 22 *** Got signal Terminated 
***
2021-01-09T18:59:52.448+ 7f937fcdc700 -1 osd.2 22 *** Immediate shutdown 
(osd_fast_shutdown=true) ***

mon log:

$ cat out/mon.a.log | grep '^2021-01-09T18:59:' | grep 'osd.0 reported 
immediately failed by osd.' | rev | cut -d: -f1 | rev | sort | uniq -c
  4  osd.0 reported immediately failed by osd.1
  4  osd.0 reported immediately failed by osd.2
  4  osd.0 reported immediately failed by osd.3
  4  osd.0 reported immediately failed by osd.4
  4  osd.0 reported immediately failed by osd.5
  4  osd.0 reported immediately failed by osd.6
  4  osd.0 reported immediately failed by osd.7
  4  osd.0 reported immediately failed by osd.8
  4  osd.0 reported immediately failed by osd.9
```

- After / with `osd_fast_shutdown_notify_mon = true`:

```
osd log:

2021-01-14T17:21:10.825+ 7feceded1700 -1 received  signal: Terminated from 
-bash  (PID: 1750) UID: 1000
2021-01-14T17:21:10.825+ 7feceded1700 -1 osd.0 80 *** Got signal Terminated 
***
2021-01-14T17:21:10.825+ 7feceded1700 -1 osd.0 80 *** Immediate shutdown 
(osd_fast_shutdown=true) ***
2021-01-14T17:21:10.825+ 7feceded1700  0 osd.0 80 prepare_to_stop telling 
mon we are shutting down
...
2021-01-14T17:21:11.021+ 7fecdac0c700  0 osd.0 80 got_stop_ack starting 
shutdown
2021-01-14T17:21:11.021+ 7feceded1700  0 osd.0 80 prepare_to_stop starting 
shutdown

mon log:

2021-01-14T17:21:10.829+ 7f62fce61700  0 log_channel(cluster) log [INF] : 
osd.0 marked itself down
2021-01-14T17:21:10.885+ 7f62ff666700  1 mon.a@0(leader).osd e80 do_prune 
osdmap full prune enabled
2021-01-14T17:21:10.889+ 7f62ff666700  0 log_channel(cluster) log [WRN] : 
Health check failed: 1 osds down (OSD_DOWN)
2021-01-14T17:21:10.957+ 7f62fb65e700  1 mon.a@0(leader).osd e81 e81: 10 
total, 9 up, 10 in
2021-01-14T17:21:11.013+ 7f62fb65e700  0 log_channel(cluster) log [DBG] : 
osdmap e81: 10 total, 9 up, 10 in
```

[Where problems could occur]

Any regression from this patch should manifest in OSD shutdown, but only
when the option is enabled.

The patch is quite small and contained to the OSD shutdown path.

It is effectively a nop when the option is disabled (by default).

It is a small change from the newly introduced default behavior,
but it just re-introduces a message in the shutdown path, which
is how it used to be done on previous releases and even earlier
stable releases in Nautilus.

[1] https://tracker.ceph.com/issues/49683
[2] https://tracker.ceph.com/issues/49681
[3] https://tracker.ceph.com/issues/49682

** Affects: cloud-archive
 Importance: Undecided
 Status: Invalid

** Affects: cloud-archive/train
 Importance: Undecided
 Status: Confirmed

** Affects: cloud-archive/ussuri
 Importance: Undecided
 Status: Confirmed

** Affects: cloud-archive/victoria
 Importance: Undecided
 Status: Invalid

** Affects: cloud-archive/wallaby
 Importance: Undecided
 Status: Invalid

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

** Affects: ceph (Ubuntu Focal)
 Importance: Undecided
 Status: Confirmed

** Affects: ceph (Ubuntu Groovy)
 Importance: Undecided
 Status: Confirmed

** Affects: ceph (Ubuntu Hirsute)
 

[Bug 1922561] Re: osd shutdown may flood the cluster log with 'osd.X reported immediately failed by osd.Y'

2021-04-05 Thread Mauricio Faria de Oliveira
Adding target Ubuntu/Cloud Archive releases.

(note: Victoria and Wallaby have no ceph packages yet, thus marking as
Invalid.)

```
The new option should be available in the following Ceph releases:
- Pacific 16.2.0 [Hirsute+]
- Octopus 15.2.11 [Focal/Groovy; Ussuri+]
- Nautilus TBD (at least 14.2.20) [Eoan is EOL; Train]

This bug tracks the release of this patch in Ubuntu/Cloud Archive.
```

** Description changed:

  [Impact]
  
  The `osd_fast_shutdown` option (available in Nautilus and enabled
  by default) may cause the cluster log to receive too many entries
  of `osd.X reported immediately failed by osd.Y` on large clusters.
  
  This happens as the monitor no longer receives the OSD message to
  notify that the OSD is shutting down and now relies on other OSDs
  telling it about the failed OSD (not really 'failed' but shutdown.)
  
  This might be an issue for LMA stacks/tools that check ceph logs
  for failed lines, and then require additional logic to filter on
  an intended OSD (fast) shutdown; might not be an option/possible,
  and require an admin to analyze.
  
  [Fix]
  
  The `osd_fast_shutdown_notify_mon` option for OSDs (disabled by
  default) can tell the monitor it is shutting down (done in slow/
  non-fast shutdown) under `osd_fast_shutdown`.
  
  This introduces minimal delay (the ack from the mon is required
  to prevent the messages), and addresses the cluster log issue.
  PS: the `osd_mon_shutdown_timeout` option can be used to control
  the maximum amount of time waiting for the monitor ack to arrive.
  
  The new option should be available in the following Ceph releases:
  - Pacific 16.2.0 [1] [Hirsute+]
  - Octopus 15.2.11 [2] [Focal/Groovy; Ussuri+]
- - Nautilus TBD (at least 14.2.20) [Eoan is EOL; Train]
+ - Nautilus TBD (at least 14.2.20) [3] [Eoan is EOL; Train]
  
  This bug tracks the release of this patch in Ubuntu/Cloud Archive.
  
  [Test Case]
  
  - Stop an OSD and watch the OSD and MON logs.
  
  - Before / or with `osd_fast_shutdown_notify_mon = false`:
  
  ```
  osd log:
  
  2021-01-09T18:59:52.448+ 7f937fcdc700 -1 received  signal: Terminated 
from -bash  (PID: 408) UID: 1000
  2021-01-09T18:59:52.448+ 7f937fcdc700 -1 osd.2 22 *** Got signal 
Terminated ***
  2021-01-09T18:59:52.448+ 7f937fcdc700 -1 osd.2 22 *** Immediate shutdown 
(osd_fast_shutdown=true) ***
  
  mon log:
  
  $ cat out/mon.a.log | grep '^2021-01-09T18:59:' | grep 'osd.0 reported 
immediately failed by osd.' | rev | cut -d: -f1 | rev | sort | uniq -c
    4  osd.0 reported immediately failed by osd.1
    4  osd.0 reported immediately failed by osd.2
    4  osd.0 reported immediately failed by osd.3
    4  osd.0 reported immediately failed by osd.4
    4  osd.0 reported immediately failed by osd.5
    4  osd.0 reported immediately failed by osd.6
    4  osd.0 reported immediately failed by osd.7
    4  osd.0 reported immediately failed by osd.8
    4  osd.0 reported immediately failed by osd.9
  ```
  
  - After / with `osd_fast_shutdown_notify_mon = true`:
  
  ```
  osd log:
  
  2021-01-14T17:21:10.825+ 7feceded1700 -1 received  signal: Terminated 
from -bash  (PID: 1750) UID: 1000
  2021-01-14T17:21:10.825+ 7feceded1700 -1 osd.0 80 *** Got signal 
Terminated ***
  2021-01-14T17:21:10.825+ 7feceded1700 -1 osd.0 80 *** Immediate shutdown 
(osd_fast_shutdown=true) ***
  2021-01-14T17:21:10.825+ 7feceded1700  0 osd.0 80 prepare_to_stop telling 
mon we are shutting down
  ...
  2021-01-14T17:21:11.021+ 7fecdac0c700  0 osd.0 80 got_stop_ack starting 
shutdown
  2021-01-14T17:21:11.021+ 7feceded1700  0 osd.0 80 prepare_to_stop 
starting shutdown
  
  mon log:
  
  2021-01-14T17:21:10.829+ 7f62fce61700  0 log_channel(cluster) log [INF] : 
osd.0 marked itself down
  2021-01-14T17:21:10.885+ 7f62ff666700  1 mon.a@0(leader).osd e80 do_prune 
osdmap full prune enabled
  2021-01-14T17:21:10.889+ 7f62ff666700  0 log_channel(cluster) log [WRN] : 
Health check failed: 1 osds down (OSD_DOWN)
  2021-01-14T17:21:10.957+ 7f62fb65e700  1 mon.a@0(leader).osd e81 e81: 10 
total, 9 up, 10 in
  2021-01-14T17:21:11.013+ 7f62fb65e700  0 log_channel(cluster) log [DBG] : 
osdmap e81: 10 total, 9 up, 10 in
  ```
  
  [Where problems could occur]
  
  Any regression from this patch should manifest in OSD shutdown, but only
  when the option is enabled.
  
  The patch is quite small and contained to the OSD shutdown path.
  
  It is effectively a nop when the option is disabled (by default).
  
  It is a small change from the newly introduced default behavior,
  but it just re-introduces a message in the shutdown path, which
  is how it used to be done on previous releases and even earlier
  stable releases in Nautilus.
  
  [1] https://tracker.ceph.com/issues/49683
  [2] https://tracker.ceph.com/issues/49681
  [3] https://tracker.ceph.com/issues/49682

-- 
You received this bug notification because you are a member of Ubuntu

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-04-05 Thread Mauricio Faria de Oliveira
** Description changed:

  [Impact]
  
  The radosgw beast frontend in ceph nautilus might hit coroutine stack
  corruption on startup and requests.
  
  This is usually observed right at the startup of the ceph-radosgw systemd 
unit; sometimes 1 minute later.
  But it might occur any time handling requests, depending on 
coroutine/request's function path/stack size.
  
  The symptoms are usually a crash with stack trace listing TCMalloc 
(de)allocate/release to central cache,
  but less rare signs are large allocs in the _terabytes_ range (pointer to 
stack used as allocation size)
  and stack traces showing function return addresses (RIP) that are actually 
pointers to an stack address.
  
  This is not widely hit in Ubuntu as most deployments use the ceph-radosgw 
charm that hardcodes 'civetweb'
  as rgw frontend, which is _not_ affected; custom/cephadm deployments that 
choose 'beast' might hit this.
  
-   @ charm-ceph-radosgw/templates/ceph.conf
- rgw frontends = civetweb port={{ port }}
+   @ charm-ceph-radosgw/templates/ceph.conf
+ rgw frontends = civetweb port={{ port }}
  
  Let's report this LP bug for documentation and tracking purposes until
  UCA gets the fixes.
  
  [Fix]
  
  This has been reported by an Ubuntu Advantage user, and another user in ceph 
tracker #47910 [1].
  This had been reported and fixed in Octopus [2] (confirmed by UA user; no 
longer affected.)
  
  The Nautilus backport has recently been merged [3, 4] and should be
- available in v14.2.19.
+ available in v14.2.20.
  
  [Test Case]
  
  The conditions to trigger the bug aren't clear, but apparently related to EC 
pools w/ very large buckets,
  and of course the radosgw frontend beast being enabled (civetweb is not 
affected.)
  
  [Where problems could occur]
  
  The fixes are restricted to the beast frontend, specifically to the 
coroutines used to handle requests.
  So problems would probably be seen in request handling only with the beast 
frontend.
  Workarounds thus include switching back to the civetweb frontend.
  
  This changes core/base parts of the RGW beast frontend code, but are in place 
from Octopus released.
  The other user/reporter in the ceph tracker has been using the patches for 
weeks with no regression;
  the ceph tests have passed and likely serious issues would be caught by ceph 
CI upstream.
  
  [1] https://tracker.ceph.com/issues/47910 report tracker (nautilus)
  [2] https://tracker.ceph.com/issues/43739 master tracker (octopus)
  [3] https://tracker.ceph.com/issues/43921 backport tracker (nautilus)
  [4] https://github.com/ceph/ceph/pull/39947 github PR

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749

Title:
  nautilus: ceph radosgw beast frontend coroutine stack corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1921749/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
Comments #1- #6: example stack traces and GDB debug snippets of the
issue.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749

Title:
  nautilus: ceph radosgw beast frontend coroutine stack corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1921749/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
coredump #6

RIP address in stack is actually not an instruction address, but a stack 
address (corrupted stack).
GDB searched hard for stack unwinding, and got a very long trace, that might 
not be correct.

Oct 23 16:41:27 HOSTNAME radosgw[3572]: *** Caught signal (Segmentation 
fault) **
Oct 23 16:41:27 HOSTNAME radosgw[3572]:  in thread 7f826a190700 
thread_name:radosgw
Oct 23 16:41:27 HOSTNAME radosgw[3572]:  ceph version 14.2.11 
(f7fdb2f52131f54b891a2ec99d8205561242cdaf) nautilus (stable)
Oct 23 16:41:27 HOSTNAME radosgw[3572]:  1: (()+0x128a0) 
[0x7f82987d68a0]
Oct 23 16:41:27 HOSTNAME radosgw[3572]:  2: [0x56275c77ac20]
Oct 23 16:41:27 HOSTNAME radosgw[3572]: 2020-10-23 16:41:27.433 
7f826a190700 -1 *** Caught signal (Segmentation fault) **

The RIP is in the stack address range from the previous frame:

(gdb) frame 5
#5  0x7f829a26e83d in AsyncConnection::send_message 
(this=0x56275c71ad00, m=0x56275c76f600) at 
./src/msg/async/AsyncConnection.cc:548
(gdb) info reg $rbp
rbp0x56275c76f600  0x56275c76f600
(gdb) info reg $rsp
rsp0x56275c782480  0x56275c782480

#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x562758ea16b0 in reraise_fatal (signum=11) at 
./src/global/signal_handler.cc:81
#2  handle_fatal_signal (signum=11) at 
./src/global/signal_handler.cc:326
#3  
#4  0x56275c77ac20 in ?? ()
#5  0x7f829a26e83d in AsyncConnection::send_message 
(this=0x56275c71ad00, m=0x56275c76f600) at 
./src/msg/async/AsyncConnection.cc:548
#6  0x7f82a32ee135 in Objecter::_send_op 
(this=this@entry=0x56275bc35080, op=op@entry=0x56275c76f000) at 
./src/osdc/Objecter.cc:3274
#7  0x7f82a32f0433 in Objecter::_op_submit 
(this=this@entry=0x56275bc35080, op=op@entry=0x56275c76f000, sul=..., 
ptid=ptid@entry=0x56275c7827e8) at ./src/osdc/Objecter.cc:2456
#8  0x7f82a32fb43d in Objecter::_op_submit_with_budget 
(this=this@entry=0x56275bc35080, op=op@entry=0x56275c76f000, sul=..., 
ptid=ptid@entry=0x56275c7827e8, ctx_budget=ctx_budget@entry=0x0) at 
./src/osdc/Objecter.cc:2284
#9  0x7f82a32fb680 in Objecter::op_submit (this=0x56275bc35080, 
op=0x56275c76f000, ptid=0x56275c7827e8, ctx_budget=0x0) at 
./src/osdc/Objecter.cc:2251
#10 0x7f82a32c2e3a in librados::IoCtxImpl::operate_read 
(this=0x56275bd83ee0, oid=..., o=0x56275bdaa180, pbl=pbl@entry=0x0, 
flags=flags@entry=0) at ./src/librados/IoCtxImpl.cc:725
#11 0x7f82a32987ec in librados::v14_2_0::IoCtx::operate 
(this=this@entry=0x56275c782c98, oid=..., o=o@entry=0x56275c782b80, 
pbl=pbl@entry=0x0) at ./src/librados/librados_cxx.cc:1423
#12 0x562759244dbc in rgw_rados_operate (ioctx=..., oid=..., 
op=op@entry=0x56275c782b80, pbl=pbl@entry=0x0, y=...) at 
./src/rgw/rgw_tools.cc:218
#13 0x5627592b7fbf in RGWSI_RADOS::Obj::operate 
(this=this@entry=0x56275c782c10, op=op@entry=0x56275c782b80, pbl=pbl@entry=0x0, 
y=...) at ./src/rgw/services/svc_rados.cc:96
#14 0x562758f33a22 in RGWSI_SysObj_Core::read 
(this=this@entry=0x56275afe7540, obj_ctx=..., read_state=..., 
objv_tracker=objv_tracker@entry=0x56275c783948, obj=..., 
bl=bl@entry=0x56275c783460, ofs=0, end=-1, attrs=0x56275c782dc0, 
raw_attrs=true, cache_info=0x56275c783680) at 
./src/rgw/services/svc_sys_obj_core.cc:222
#15 0x5627592bbe7d in RGWSI_SysObj_Cache::read 
(this=this@entry=0x56275afe7540, obj_ctx=..., read_state=..., 
objv_tracker=0x56275c783948, obj=..., obl=obl@entry=0x56275c783460, ofs=0, 
end=-1, attrs=0x56275c783b90, raw_attrs=false, cache_info=0x56275c783680, 
refresh_version=...) at ./src/rgw/services/svc_sys_obj_cache.cc:147
#16 0x562758f2fbcb in RGWSI_SysObj::Obj::ROp::read 
(this=this@entry=0x56275c783260, ofs=ofs@entry=0, end=end@entry=-1, 
bl=bl@entry=0x56275c783460) at ./src/rgw/services/svc_sys_obj.cc:47
#17 0x5627592426c3 in RGWSI_SysObj::Obj::ROp::read 
(pbl=0x56275c783460, this=0x56275c783260) at ./src/rgw/services/svc_sys_obj.h:99
#18 rgw_get_system_obj (rgwstore=rgwstore@entry=0x56275b073800, 
obj_ctx=..., pool=..., key=..., bl=..., 
objv_tracker=objv_tracker@entry=0x56275c783948, pmtime=0x56275c783b88, 
pattrs=0x56275c783b90, cache_info=0x56275c783680, refresh_version=...) at 
./src/rgw/rgw_tools.cc:156
#19 0x562759198257 in RGWRados::get_bucket_instance_from_oid 
(this=this@entry=0x56275b073800, obj_ctx=..., oid=..., info=..., 
pmtime=pmtime@entry=0x56275c783b88, pattrs=pattrs@entry=0x56275c783b90, 
cache_info=0x56275c783680, refresh_version=...) at ./src/rgw/rgw_rados.cc:8250
#20 0x56275919b5ad in RGWRados::_get_bucket_info 
(this=0x56275b073800, obj_ctx=..., tenant=..., bucket_name=..., info=..., 
pmtime=pmtime@entry=0x0, pattrs=0x56275c785fb8, refresh_version=...) at 
./src/rgw/rgw_rados.cc:8405
   

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
coredump #5

Oct 23 16:41:01 HOSTNAME radosgw[1616]: tcmalloc: large alloc 
94195528343552 bytes == (nil) @  0x7f97ec494887 0x7f97ec1cb1b2 0x7f97ec1ff948 
0x7f97ec1d08be 0x7f97ec1db01e 0x7f97ec1dd433 0x7f97ec1e843d 0x7f97ec1e8680 
0x7f97ec1afe3a 0x7f97ec1857ec 0x55ab96ae9dbc 0x55ab967d8a22 0x55ab96b60e7d 
0x55ab967d4bcb 0x55ab96ae76c3 0x55ab96af598a 0x55ab967c5a1a 0x55ab9667e1cf 
0x55ab96801118 0x55ab96801c87 0x55ab96766a0b 0x55ab966bd660 0x55ab966be86d 
0x55ab96bfad5f
Oct 23 16:41:01 HOSTNAME radosgw[1616]: terminate called without an 
active exception
Oct 23 16:41:01 HOSTNAME radosgw[1616]: *** Caught signal (Aborted) **

#0  raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x55ab967466b0 in reraise_fatal (signum=6) at 
./src/global/signal_handler.cc:81
#2  handle_fatal_signal (signum=6) at ./src/global/signal_handler.cc:326
#3  
#4  __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:51
#5  0x7f97e09c18b1 in __GI_abort () at abort.c:79
#6  0x7f97e13b4957 in __gnu_cxx::__verbose_terminate_handler () at 
../../../../src/libstdc++-v3/libsupc++/vterminate.cc:95
#7  0x7f97e13baae6 in __cxxabiv1::__terminate (handler=) at ../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:47
#8  0x7f97e13bab21 in std::terminate () at 
../../../../src/libstdc++-v3/libsupc++/eh_terminate.cc:57
#9  0x55ab96801eb0 in rgw::auth::Strategy::apply 
(dpp=0x55ab9a627000, auth_strategy=..., s=) at 
./src/rgw/rgw_auth.cc:273
#10 0x55ab96766a0b in process_request (store=0x55ab99917800, 
rest=0x7fff342285a0, req=0x55ab9b020930, frontend_prefix=..., 
auth_registry=..., client_io=client_io@entry=0x55ab9b0209c0, olog=0x0, 
yield=..., scheduler=0x55ab9ac1f928, http_ret=0x0) at 
./src/rgw/rgw_process.cc:251
#11 0x55ab966bd660 in (anonymous 
namespace)::handle_connection
 > (context=..., env=..., stream=..., buffer=..., pause_mutex=..., 
scheduler=, ec=..., yield=..., is_ssl=false) at 
./src/rgw/rgw_asio_frontend.cc:167
#12 0x55ab966be86d in (anonymous 
namespace)::AsioFrontendoperator() 
(yield=..., __closure=0x55ab9a8aa1e8) at ./src/rgw/rgw_asio_frontend.cc:638
#13 
boost::asio::detail::coro_entry_point >, (anonymous 
namespace)::AsioFrontend::accept((anonymous 
namespace)::AsioFrontend::Listener&, 
boost::system::error_code):: >::operator() 
(ca=..., this=) at 
./obj-x86_64-linux-gnu/boost/include/boost/asio/impl/spawn.hpp:337
#14 
boost::coroutines::detail::push_coroutine_object,
 void, boost::asio::detail::coro_entry_point >, 
(anonymous namespace)::AsioFrontend::accept((anonymous 
namespace)::AsioFrontend::Listener&, 
boost::system::error_code):: >&, 
boost::coroutines::basic_standard_stack_allocator
 >::run (this=0x55ab9b021f60) at 
./obj-x86_64-linux-gnu/boost/include/boost/coroutine/detail/push_coroutine_object.hpp:302
#15 
boost::coroutines::detail::trampoline_push_void,
 void, boost::asio::detail::coro_entry_point >, 
(anonymous namespace)::AsioFrontend::accept((anonymous 
namespace)::AsioFrontend::Listener&, 
boost::system::error_code):: >&, 
boost::coroutines::basic_standard_stack_allocator
 > >(boost::context::detail::transfer_t) (t=...) at 
./obj-x86_64-linux-gnu/boost/include/boost/coroutine/detail/trampoline_push.hpp:70
#16 0x55ab96bfad5f in make_fcontext ()
#17 0x55ab9703fcd0 in vtable for 
boost::coroutines::detail::push_coroutine_object,
 void, boost::asio::detail::coro_entry_point >, 
(anonymous namespace)::AsioFrontend::accept((anonymous 
namespace)::AsioFrontend::Listener&, 
boost::system::error_code)::{lambda(boost::asio::basic_yield_context >)#4}>&, 
boost::coroutines::basic_standard_stack_allocator
 > ()
#18 0x0026 in ?? ()
#19 0x in ?? ()


The ceph error message provides some more stack frames than GDB.

(gdb) info symbol 

0x7f97ec494887 tc_newarray + 455 in section google_malloc of 
/usr/lib/x86_64-linux-gnu/libtcmalloc.so.4
0x7f97ec1cb1b2 void std::__cxx11::basic_string, std::allocator >::_M_construct(char*, 
char*, std::forward_iterator_tag)
0x7f97ec1ff948 std::vector 
>::operator=(std::vector > const&)
0x7f97ec1d08be Objecter::_prepare_osd_op
0x7f97ec1db01e Objecter::_send_op
0x7f97ec1dd433 Objecter::_op_submit
0x7f97ec1e843d Objecter::_op_submit_with_budget
0x7f97ec1e8680 Objecter::op_submit
0x7f97ec1afe3a librados::IoCtxImpl::operate_read
0x7f97ec1857ec librados::v14_2_0::IoCtx::operate
0x55ab96ae9dbc rgw_rados_operate
0x55ab967d8a22 RGWSI_SysObj_Core::read
0x55ab96b60e7d RGWSI_SysObj_Cache::read
0x55ab967d4bcb RGWSI_SysObj::Obj::ROp::read
0x55ab96ae76c3 rgw_get_system_obj
0x55ab96af598a rgw_get_user_info_from_index
0x55ab967c5a1a 

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
coredump #4

Shorter stack trace reported in ceph logs than in GDB.

Oct 23 16:41:28 HOSTNAME radosgw[4319]: *** Caught signal (Segmentation 
fault) **
Oct 23 16:41:28 HOSTNAME radosgw[4319]:  in thread 7fb79e999700 
thread_name:msgr-worker-2
Oct 23 16:41:28 HOSTNAME radosgw[4319]:  ceph version 14.2.11 
(f7fdb2f52131f54b891a2ec99d8205561242cdaf) nautilus (stable)
Oct 23 16:41:28 HOSTNAME radosgw[4319]:  1: (()+0x128a0) 
[0x7fb7a747d8a0]
Oct 23 16:41:28 HOSTNAME radosgw[4319]:  2: 
(tcmalloc::ThreadCache::ReleaseToCentralCache(tcmalloc::ThreadCache::FreeList*, 
unsigned long, int)+0xdb) [0x7fb7b223dbcb]
Oct 23 16:41:28 HOSTNAME radosgw[4319]:  3: 
(tcmalloc::ThreadCache::ListTooLong(tcmalloc::ThreadCache::FreeList*, unsigned 
long)+0x1b) [0x7fb7b223dc9b]
Oct 23 16:41:28 HOSTNAME radosgw[4319]:  4: (cfree()+0x2d5) 
[0x7fb7b224c6f5]


#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x5565a2ff16b0 in reraise_fatal (signum=11) at 
./src/global/signal_handler.cc:81
#2  handle_fatal_signal (signum=11) at 
./src/global/signal_handler.cc:326
#3  
#4  tcmalloc::SLL_Next (t=0x0) at src/linked_list.h:45
#5  tcmalloc::SLL_PopRange (end=, start=, N=158, head=0x5565a3cd8bf0) at src/linked_list.h:76
#6  tcmalloc::ThreadCache::FreeList::PopRange (end=, 
start=, N=158, this=0x5565a3cd8bf0) at src/thread_cache.h:225
#7  tcmalloc::ThreadCache::ReleaseToCentralCache 
(this=this@entry=0x5565a3cd8a40, src=src@entry=0x5565a3cd8bf0, cl=, N=158, N@entry=273) at src/thread_cache.cc:195
#8  0x7fb7b223dc9b in tcmalloc::ThreadCache::ListTooLong 
(this=this@entry=0x5565a3cd8a40, list=0x5565a3cd8bf0, cl=) at 
src/thread_cache.cc:157
#9  0x7fb7b224c6f5 in tcmalloc::ThreadCache::Deallocate 
(cl=, ptr=0x5565a57f5c00, this=0x5565a3cd8a40) at 
src/thread_cache.h:387
#10 (anonymous namespace)::do_free_helper 
(invalid_free_fn=0x7fb7b222cce0 <(anonymous namespace)::InvalidFree(void*)>, 
size_hint=0, use_hint=false, heap_must_be_valid=true, heap=0x5565a3cd8a40, 
ptr=0x5565a57f5c00) at src/tcmalloc.cc:1305
#11 (anonymous namespace)::do_free_with_callback 
(invalid_free_fn=0x7fb7b222cce0 <(anonymous namespace)::InvalidFree(void*)>, 
size_hint=0, use_hint=false, ptr=0x5565a57f5c00) at src/tcmalloc.cc:1337
#12 (anonymous namespace)::do_free (ptr=0x5565a57f5c00) at 
src/tcmalloc.cc:1345
#13 tc_free (ptr=0x5565a57f5c00) at src/tcmalloc.cc:1610
#14 0x7fb7b1fca164 in __gnu_cxx::new_allocator::deallocate 
(this=0x5565a5bf0880, __p=) at 
/usr/include/c++/7/ext/new_allocator.h:125
#15 std::allocator_traits >::deallocate (__a=..., 
__n=, __p=) at 
/usr/include/c++/7/bits/alloc_traits.h:462
#16 std::_Vector_base >::_M_deallocate 
(this=0x5565a5bf0880, __n=, __p=) at 
/usr/include/c++/7/bits/stl_vector.h:180
#17 std::_Vector_base >::~_Vector_base 
(this=0x5565a5bf0880, __in_chrg=) at 
/usr/include/c++/7/bits/stl_vector.h:162
#18 std::vector >::~vector 
(this=0x5565a5bf0880, __in_chrg=) at 
/usr/include/c++/7/bits/stl_vector.h:435
#19 MOSDOp::~MOSDOp (this=0x5565a5bf0600, __in_chrg=) at 
./src/messages/MOSDOp.h:195
#20 MOSDOp::~MOSDOp (this=0x5565a5bf0600, __in_chrg=) at 
./src/messages/MOSDOp.h:195
#21 0x7fb7a8ca6db7 in RefCountedObject::put (this=0x5565a5bf0600) 
at ./src/common/RefCountedObj.h:64
#22 0x7fb7a8f42d30 in ProtocolV2::write_message 
(this=this@entry=0x5565a5776000, m=m@entry=0x5565a5bf0600, 
more=more@entry=false) at ./src/msg/async/ProtocolV2.cc:571
#23 0x7fb7a8f56f0b in ProtocolV2::write_event (this=0x5565a5776000) 
at ./src/msg/async/ProtocolV2.cc:658
#24 0x7fb7a8f16263 in AsyncConnection::handle_write 
(this=0x5565a5763b00) at ./src/msg/async/AsyncConnection.cc:692
#25 0x7fb7a8f6a757 in EventCenter::process_events 
(this=this@entry=0x5565a43f2e00, timeout_microseconds=, 
timeout_microseconds@entry=3000, 
working_dur=working_dur@entry=0x7fb79e996be8) at ./src/msg/async/Event.cc:441
#26 0x7fb7a8f6ee48 in NetworkStackoperator() 
(__closure=0x5565a44c3958) at ./src/msg/async/Stack.cc:53
#27 std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at 
/usr/include/c++/7/bits/std_function.h:316
#28 0x7fb7a719f6df in ?? () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#29 0x7fb7a74726db in start_thread (arg=0x7fb79e999700) at 
pthread_create.c:463
#30 0x7fb7a685ca3f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95


Again, interaction between SLL_Pop(Range) and SLL_Next.

#4  tcmalloc::SLL_Next (t=0x0) at src/linked_list.h:45
#5  tcmalloc::SLL_PopRange (end=, start=, N=158, head=0x5565a3cd8bf0) at src/linked_list.h:76

Same as previous 2 cases, same function/instruction/register/pointer:

(gdb) f 4


[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
coredump #3

(gdb) bt
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x55bd9a04f6b0 in reraise_fatal (signum=11) at 
./src/global/signal_handler.cc:81
#2  handle_fatal_signal (signum=11) at 
./src/global/signal_handler.cc:326
#3  
#4  tcmalloc::SLL_Next (t=0x0) at src/linked_list.h:45
#5  tcmalloc::SLL_PopRange (end=, start=, N=176, head=0x55bd9c1d2bf0) at src/linked_list.h:76
#6  tcmalloc::ThreadCache::FreeList::PopRange (end=, 
start=, N=176, this=0x55bd9c1d2bf0) at src/thread_cache.h:225
#7  tcmalloc::ThreadCache::ReleaseToCentralCache 
(this=this@entry=0x55bd9c1d2a40, src=src@entry=0x55bd9c1d2bf0, cl=, N=176, N@entry=273) at src/thread_cache.cc:195
#8  0x7f036eed4c9b in tcmalloc::ThreadCache::ListTooLong 
(this=this@entry=0x55bd9c1d2a40, list=0x55bd9c1d2bf0, cl=) at 
src/thread_cache.cc:157
#9  0x7f036eee36f5 in tcmalloc::ThreadCache::Deallocate 
(cl=, ptr=0x55bd9e12e0f0, this=0x55bd9c1d2a40) at 
src/thread_cache.h:387
#10 (anonymous namespace)::do_free_helper 
(invalid_free_fn=0x7f036eec3ce0 <(anonymous namespace)::InvalidFree(void*)>, 
size_hint=0, use_hint=false, heap_must_be_valid=true, heap=0x55bd9c1d2a40, 
ptr=0x55bd9e12e0f0) at src/tcmalloc.cc:1305
#11 (anonymous namespace)::do_free_with_callback 
(invalid_free_fn=0x7f036eec3ce0 <(anonymous namespace)::InvalidFree(void*)>, 
size_hint=0, use_hint=false, ptr=0x55bd9e12e0f0) at src/tcmalloc.cc:1337
#12 (anonymous namespace)::do_free (ptr=0x55bd9e12e0f0) at 
src/tcmalloc.cc:1345
#13 tc_free (ptr=0x55bd9e12e0f0) at src/tcmalloc.cc:1610
#14 0x7f036ec61164 in __gnu_cxx::new_allocator::deallocate 
(this=0x55bd9c982c80, __p=) at 
/usr/include/c++/7/ext/new_allocator.h:125
#15 std::allocator_traits >::deallocate (__a=..., 
__n=, __p=) at 
/usr/include/c++/7/bits/alloc_traits.h:462
#16 std::_Vector_base >::_M_deallocate 
(this=0x55bd9c982c80, __n=, __p=) at 
/usr/include/c++/7/bits/stl_vector.h:180
#17 std::_Vector_base >::~_Vector_base 
(this=0x55bd9c982c80, __in_chrg=) at 
/usr/include/c++/7/bits/stl_vector.h:162
#18 std::vector >::~vector 
(this=0x55bd9c982c80, __in_chrg=) at 
/usr/include/c++/7/bits/stl_vector.h:435
#19 MOSDOp::~MOSDOp (this=0x55bd9c982a00, __in_chrg=) at 
./src/messages/MOSDOp.h:195
#20 MOSDOp::~MOSDOp (this=0x55bd9c982a00, __in_chrg=) at 
./src/messages/MOSDOp.h:195
#21 0x7f036593ddb7 in RefCountedObject::put (this=0x55bd9c982a00) 
at ./src/common/RefCountedObj.h:64
#22 0x7f0365bd9d30 in ProtocolV2::write_message 
(this=this@entry=0x55bd9dc68000, m=m@entry=0x55bd9c982a00, 
more=more@entry=false) at ./src/msg/async/ProtocolV2.cc:571
#23 0x7f0365bedf0b in ProtocolV2::write_event (this=0x55bd9dc68000) 
at ./src/msg/async/ProtocolV2.cc:658
#24 0x7f0365bad263 in AsyncConnection::handle_write 
(this=0x55bd9dc58900) at ./src/msg/async/AsyncConnection.cc:692
#25 0x7f0365c01757 in EventCenter::process_events 
(this=this@entry=0x55bd9c8ece00, timeout_microseconds=, 
timeout_microseconds@entry=3000, 
working_dur=working_dur@entry=0x7f035b62dbe8) at ./src/msg/async/Event.cc:441
#26 0x7f0365c05e48 in NetworkStackoperator() 
(__closure=0x55bd9c9bd958) at ./src/msg/async/Stack.cc:53
#27 std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at 
/usr/include/c++/7/bits/std_function.h:316
#28 0x7f0363e366df in ?? () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#29 0x7f03641096db in start_thread (arg=0x7f035b630700) at 
pthread_create.c:463
#30 0x7f03634f3a3f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Again, interaction between SLL_Pop(Range) and SLL_Next.

#4  tcmalloc::SLL_Next (t=0x0) at src/linked_list.h:45
#5  tcmalloc::SLL_PopRange (end=, start=, N=176, head=0x55bd9c1d2bf0) at src/linked_list.h:76

Same as previous case, same function/instruction/register/pointer:

(gdb) f 4

(gdb) x/i $rip
=> 0x7f036eed4bcb 
: mov(%rdx),%rdx

(gdb) x $rdx
   0x0: Cannot access memory at address 0x0

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749

Title:
  nautilus: ceph radosgw beast frontend coroutine stack corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1921749/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
coredump #1

(gdb) bt
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x555f023cf6b0 in reraise_fatal (signum=11) at 
./src/global/signal_handler.cc:81
#2  handle_fatal_signal (signum=11) at 
./src/global/signal_handler.cc:326
#3  
#4  tcmalloc::SLL_Next (t=0x6ee6555f) at src/linked_list.h:45
#5  tcmalloc::SLL_Pop (list=0x555f03530628) at src/linked_list.h:59
#6  tcmalloc::ThreadCache::FreeList::Pop (this=) at 
src/thread_cache.h:212
#7  tcmalloc::ThreadCache::Allocate (cl=, 
size=, this=) at src/thread_cache.h:365
#8  (anonymous namespace)::do_memalign (align=align@entry=8, 
size=, size@entry=4096) at src/tcmalloc.cc:1462
#9  0x7f1d87d08379 in (anonymous 
namespace)::do_memalign_or_cpp_memalign (size=4096, align=8) at 
src/tcmalloc.cc:1131
#10 tc_posix_memalign (result_ptr=result_ptr@entry=0x7f1d74c51310, 
align=align@entry=8, size=size@entry=4096) at src/tcmalloc.cc:1781
#11 0x7f1d7ea60a86 in ceph::buffer::v14_2_0::raw_combined::create 
(mempool=10, align=8, len=4000) at ./src/common/buffer.cc:121
#12 ceph::buffer::v14_2_0::list::refill_append_space 
(this=this@entry=0x7f1d74c51480, len=len@entry=1) at ./src/common/buffer.cc:1442
#13 0x7f1d7ea6197a in ceph::buffer::v14_2_0::list::append 
(this=0x7f1d74c51480, data=0x7f1d74c513e0 "\b\024\305t\035\177", 
len=) at ./src/common/buffer.cc:1470
#14 0x7f1d7ea02f2c in ceph::encode_raw (bl=..., 
t=@0x7f1d74c513e0: 8 '\b') at ./src/include/encoding.h:73
#15 ceph::encode (features=720575940647714820, bl=..., 
v=@0x7f1d74c513e0: 8 '\b') at ./src/include/encoding.h:85
#16 ceph::msgr::v2::ControlFrame::_encode_payload_each (
t=@0x7f1d74c513e0: 8 '\b', this=0x7f1d74c51480) at 
./src/msg/async/frames_v2.h:426
#17 ceph::msgr::v2::ControlFrame::_encode (args#1=..., 
args#0=@0x7f1d74c513e0: 8 '\b', this=0x7f1d74c51480) at 
./src/msg/async/frames_v2.h:460
#18 ceph::msgr::v2::ControlFrame::Encode (args#1=..., 
args#0=@0x7f1d74c513e0: 8 '\b', this=) at 
./src/msg/async/frames_v2.h:471
#19 ProtocolV2::_handle_peer_banner_payload (this=0x555f054c, 
buffer=..., r=) at ./src/msg/async/ProtocolV2.cc:942
#20 0x7f1d7ea011a4 in ProtocolV2::run_continuation 
(this=0x555f054c, continuation=...) at ./src/msg/async/ProtocolV2.cc:47
#21 0x7f1d7e9ce0e6 in std::function::operator()(char*, long) const (__args#1=, 
__args#0=, this=0x555f054b8410) at 
/usr/include/c++/7/bits/std_function.h:706
#22 AsyncConnection::process (this=0x555f054b8000) at 
./src/msg/async/AsyncConnection.cc:450
#23 0x7f1d7ea241cd in EventCenter::process_events 
(this=this@entry=0x555f03c4a980, timeout_microseconds=, 
timeout_microseconds@entry=3000, 
working_dur=working_dur@entry=0x7f1d74c51be8) at ./src/msg/async/Event.cc:415
#24 0x7f1d7ea28e48 in NetworkStackoperator() 
(__closure=0x555f03d1b988) at ./src/msg/async/Stack.cc:53
#25 std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...)
at /usr/include/c++/7/bits/std_function.h:316
#26 0x7f1d7cc596df in ?? () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#27 0x7f1d7cf2c6db in start_thread (arg=0x7f1d74c54700) at 
pthread_create.c:463
#28 0x7f1d7c316a3f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

See 
#4  tcmalloc::SLL_Next (t=0x6ee6555f) at src/linked_list.h:45
#5  tcmalloc::SLL_Pop (list=0x555f03530628) at src/linked_list.h:59

The pointer in frame 4 is bogus,

(gdb) x 0x555f03530628
0x555f03530628: 0x555f

(gdb) x 0x6ee6555f
0x6ee6555f: Cannot access memory at address 
0x6ee6555f

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749

Title:
  nautilus: ceph radosgw beast frontend coroutine stack corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1921749/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1921749] Re: nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
coredump #2

(gdb) bt
#0  raise (sig=sig@entry=11) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x557c23db26b0 in reraise_fatal (signum=11) at 
./src/global/signal_handler.cc:81
#2  handle_fatal_signal (signum=11) at 
./src/global/signal_handler.cc:326
#3  
#4  tcmalloc::SLL_Next (t=0x0) at src/linked_list.h:45
#5  tcmalloc::SLL_PopRange (end=, start=, N=27, head=0x557c26146d28) at src/linked_list.h:76
#6  tcmalloc::ThreadCache::FreeList::PopRange (end=, 
start=, N=27, this=0x557c26146d28) at src/thread_cache.h:225
#7  tcmalloc::ThreadCache::ReleaseToCentralCache 
(this=this@entry=0x557c26146a40, src=src@entry=0x557c26146d28, cl=, N=27, N@entry=85) at src/thread_cache.cc:195
#8  0x7feb0741dc9b in tcmalloc::ThreadCache::ListTooLong 
(this=this@entry=0x557c26146a40, list=0x557c26146d28, cl=) at 
src/thread_cache.cc:157
#9  0x7feb0742c6f5 in tcmalloc::ThreadCache::Deallocate 
(cl=, ptr=0x557c280c7800, this=0x557c26146a40) at 
src/thread_cache.h:387
#10 (anonymous namespace)::do_free_helper 
(invalid_free_fn=0x7feb0740cce0 <(anonymous namespace)::InvalidFree(void*)>, 
size_hint=0, use_hint=false, heap_must_be_valid=true, heap=0x557c26146a40, 
ptr=0x557c280c7800) at src/tcmalloc.cc:1305
#11 (anonymous namespace)::do_free_with_callback 
(invalid_free_fn=0x7feb0740cce0 <(anonymous namespace)::InvalidFree(void*)>, 
size_hint=0, use_hint=false, ptr=0x557c280c7800) at src/tcmalloc.cc:1337
#12 (anonymous namespace)::do_free (ptr=0x557c280c7800) at 
src/tcmalloc.cc:1345
#13 tc_free (ptr=0x557c280c7800) at src/tcmalloc.cc:1610
#14 0x7feb07151027 in RefCountedObject::put (this=0x557c280c7800) 
at ./src/common/RefCountedObj.h:64
#15 0x7feb07185a7a in Objecter::_finish_op 
(this=this@entry=0x557c2754f080, op=op@entry=0x557c280c7800, r=r@entry=0) at 
./src/osdc/Objecter.cc:3147
#16 0x7feb0718e50f in Objecter::handle_osd_op_reply 
(this=this@entry=0x557c2754f080, m=m@entry=0x557c280ae580) at 
./src/osdc/Objecter.cc:3528
#17 0x7feb0718f733 in Objecter::ms_dispatch (this=0x557c2754f080, 
m=0x557c280ae580) at ./src/osdc/Objecter.cc:966
#18 0x7feb071aa322 in non-virtual thunk to 
Objecter::ms_fast_dispatch(Message*) () at ./src/osdc/Objecter.h:2110
#19 0x7feafe03aa7a in Messenger::ms_fast_dispatch (m=..., 
this=) at ./src/msg/Messenger.h:665
#20 DispatchQueue::fast_dispatch (this=0x557c26970c58, m=...) at 
./src/msg/DispatchQueue.cc:72
#21 0x7feafe12b432 in DispatchQueue::fast_dispatch 
(m=0x557c280ae580, this=) at ./src/msg/DispatchQueue.h:204
#22 ProtocolV2::handle_message (this=this@entry=0x557c27bf5100) at 
./src/msg/async/ProtocolV2.cc:1462
#23 0x7feafe13d1f0 in ProtocolV2::handle_read_frame_dispatch 
(this=this@entry=0x557c27bf5100) at ./src/msg/async/ProtocolV2.cc:1128
#24 0x7feafe13d349 in ProtocolV2::_handle_read_frame_epilogue_main 
(this=this@entry=0x557c27bf5100) at ./src/msg/async/ProtocolV2.cc:1316
#25 0x7feafe13ec29 in ProtocolV2::handle_read_frame_epilogue_main 
(this=0x557c27bf5100, buffer=..., r=) at 
./src/msg/async/ProtocolV2.cc:1291
#26 0x7feafe1271a4 in ProtocolV2::run_continuation 
(this=0x557c27bf5100, continuation=...) at ./src/msg/async/ProtocolV2.cc:47
#27 0x7feafe0f40e6 in std::function::operator()(char*, long) const (__args#1=, 
__args#0=, this=0x557c27be1e90) at 
/usr/include/c++/7/bits/std_function.h:706
#28 AsyncConnection::process (this=0x557c27be1a80) at 
./src/msg/async/AsyncConnection.cc:450
#29 0x7feafe14a1cd in EventCenter::process_events 
(this=this@entry=0x557c26860e00, timeout_microseconds=, 
timeout_microseconds@entry=3000, 
working_dur=working_dur@entry=0x7feaf3b76be8) at ./src/msg/async/Event.cc:415
#30 0x7feafe14ee48 in NetworkStackoperator() 
(__closure=0x557c26931958) at ./src/msg/async/Stack.cc:53
#31 std::_Function_handler >::_M_invoke(const std::_Any_data &) (__functor=...) at 
/usr/include/c++/7/bits/std_function.h:316
#32 0x7feafc37f6df in ?? () from 
/usr/lib/x86_64-linux-gnu/libstdc++.so.6
#33 0x7feafc6526db in start_thread (arg=0x7feaf3b79700) at 
pthread_create.c:463
#34 0x7feafba3ca3f in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:95

Similar interaction between SLL_Pop(Range) and SLL_Next.

#4  tcmalloc::SLL_Next (t=0x0) at src/linked_list.h:45
#5  tcmalloc::SLL_PopRange (end=, start=, N=27, head=0x557c26146d28) at 

The instructions reads memory pointed by register RDX (into RDX itself)

(gdb) f 4

(gdb) x/i $rip
=> 0x7feb0741dbcb 
: mov(%rdx),%rdx

But RDX is NULL, invalid pointer to begin with.

(gdb) x $rdx
   0x0: Cannot access memory at address 0x0

-- 
You received this bug notification because you are a member of Ubuntu

[Bug 1921749] [NEW] nautilus: ceph radosgw beast frontend coroutine stack corruption

2021-03-29 Thread Mauricio Faria de Oliveira
Public bug reported:

[Impact]

The radosgw beast frontend in ceph nautilus might hit coroutine stack
corruption on startup and requests.

This is usually observed right at the startup of the ceph-radosgw systemd unit; 
sometimes 1 minute later.
But it might occur any time handling requests, depending on coroutine/request's 
function path/stack size.

The symptoms are usually a crash with stack trace listing TCMalloc 
(de)allocate/release to central cache,
but less rare signs are large allocs in the _terabytes_ range (pointer to stack 
used as allocation size)
and stack traces showing function return addresses (RIP) that are actually 
pointers to an stack address.

This is not widely hit in Ubuntu as most deployments use the ceph-radosgw charm 
that hardcodes 'civetweb'
as rgw frontend, which is _not_ affected; custom/cephadm deployments that 
choose 'beast' might hit this.

  @ charm-ceph-radosgw/templates/ceph.conf
rgw frontends = civetweb port={{ port }}

Let's report this LP bug for documentation and tracking purposes until
UCA gets the fixes.

[Fix]

This has been reported by an Ubuntu Advantage user, and another user in ceph 
tracker #47910 [1].
This had been reported and fixed in Octopus [2] (confirmed by UA user; no 
longer affected.)

The Nautilus backport has recently been merged [3, 4] and should be
available in v14.2.19.

[Test Case]

The conditions to trigger the bug aren't clear, but apparently related to EC 
pools w/ very large buckets,
and of course the radosgw frontend beast being enabled (civetweb is not 
affected.)

[Where problems could occur]

The fixes are restricted to the beast frontend, specifically to the coroutines 
used to handle requests.
So problems would probably be seen in request handling only with the beast 
frontend.
Workarounds thus include switching back to the civetweb frontend.

This changes core/base parts of the RGW beast frontend code, but are in place 
from Octopus released.
The other user/reporter in the ceph tracker has been using the patches for 
weeks with no regression;
the ceph tests have passed and likely serious issues would be caught by ceph CI 
upstream.

[1] https://tracker.ceph.com/issues/47910 report tracker (nautilus)
[2] https://tracker.ceph.com/issues/43739 master tracker (octopus)
[3] https://tracker.ceph.com/issues/43921 backport tracker (nautilus)
[4] https://github.com/ceph/ceph/pull/39947 github PR

** Affects: cloud-archive
 Importance: Undecided
 Status: Fix Released

** Affects: cloud-archive/train
 Importance: Undecided
 Status: Confirmed

** Affects: ceph (Ubuntu)
 Importance: Undecided
 Status: Fix Released

** Changed in: ceph (Ubuntu)
   Status: New => Fix Released

** Also affects: cloud-archive
   Importance: Undecided
   Status: New

** Also affects: cloud-archive/train
   Importance: Undecided
   Status: New

** Changed in: cloud-archive
   Status: New => Fix Released

** Changed in: cloud-archive/train
   Status: New => Confirmed

** Summary changed:

- nautilus: ceph radosgw beast frontend might hit coroutine stack corruption
+ nautilus: ceph radosgw beast frontend coroutine stack corruption

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1921749

Title:
  nautilus: ceph radosgw beast frontend coroutine stack corruption

To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-archive/+bug/1921749/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1909950] Re: named: TCP connections sometimes never close due to race in socket teardown

2021-03-01 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950

Title:
  named: TCP connections sometimes never close due to race in socket
  teardown

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1856871] Re: i/o error if next unused loop device is queried

2021-02-22 Thread Mauricio Faria de Oliveira
** Changed in: linux (Ubuntu)
   Status: Incomplete => In Progress

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

** Changed in: linux (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

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

** Changed in: linux (Ubuntu)
     Assignee: Mauricio Faria de Oliveira (mfo) => Eric Desrochers (slashd)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1856871

Title:
  i/o error if next unused loop device is queried

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1909950] Re: named: TCP connections sometimes never close due to race in socket teardown

2021-02-18 Thread Mauricio Faria de Oliveira
Ack; will do. Thanks for the notice!

** Changed in: bind9 (Ubuntu Focal)
   Status: Fix Committed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950

Title:
  named: TCP connections sometimes never close due to race in socket
  teardown

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1909950] Re: named: TCP connections sometimes never close due to race in socket teardown

2021-02-11 Thread Mauricio Faria de Oliveira
For doc purposes, I've had an interesting time
debugging why the bind9 forwarding didn't work
to a host running dnsmasq/libvirt (DNS server).

After some tcpdump comparisons against a local
dig client that worked fine, it turns out that
dnssec-validation must be changed from 'auto'
to 'yes', and then bind9 forwarding worked OK!

bind forwarder / default (see percent symbol): FAIL / NotImp
---

$ sudo tcpdump -i vnet9 'port 53'
...
22:59:07.461914 IP 192.168.122.11.48475 > rotom.domain: 36180+% [1au] A? 
ubuntu.com. (51)
22:59:07.462424 IP rotom.domain > 192.168.122.11.48475: 36180 NotImp 0/0/1 (62)
...


local client (no percent symbol): PASS
---

$ sudo tcpdump -i lo 'port 53'
...
22:58:24.444288 IP rotom.47673 > rotom.domain: 30984+ [1au] A? ubuntu.com. (51)
22:58:24.444915 IP rotom.domain > rotom.47673: 30984 4/0/1 A 91.189.88.181, A 
91.189.91.44, A 91.189.91.45, A 91.189.88.180 (103)
...


bind forwarder / dnssec-validation yes (NO percent symbol): PASS
---

$ sudo tcpdump -i vnet9 'port 53'
...
23:04:28.551700 IP 192.168.122.11.47530 > rotom.domain: 36699+ [1au] A? 
ubuntu.com. (51)
23:04:28.648898 IP rotom.domain > 192.168.122.11.47530: 36699 4/0/1 A 
91.189.91.45, A 91.189.88.181, A 91.189.88.180, A 91.189.91.44 (126)
...


Reference: 
https://serverfault.com/questions/399911/tcpdump-dns-output-codes#400044

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950

Title:
  named: TCP connections sometimes never close due to race in socket
  teardown

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1909950] Re: named: TCP connections sometimes never close due to race in socket teardown

2021-02-11 Thread Mauricio Faria de Oliveira
Matthew,

Thanks for the great work on this bug. Sponsored to focal.

I've reviewed the debdiff and had only two minor changes:
1) the Description: field to conform with DEP3/deb822 [1,2]
on multiline field (first line and paragraph separators), 
2) trimmed 'and-' of the patch name to keep its line under
80 chars in the changelog (we could break it, but it's weird.)

The package built fine on all archs w/ focal-proposed enabled.

The test-case consistently broke bind9 within ~30 seconds
with a powerful client VM (32 CPUs, 5 tmux tabs w/ the loop)
for the version in focal-updates.
The test package consistently survived the test-case.

cheers,
Mauricio

[1] https://dep-team.pages.debian.net/deps/dep3/
[2] https://manpages.debian.org/unstable/dpkg-dev/deb822.5.en.html

** Description changed:

  [Impact]
  
  We are seeing busy Bind9 servers stop accepting TCP connections after a
  period of time. Looking at netstat, named is still listening to port 53
  on all interfaces, but if you send a dig, the connection will just time
  out:
  
  $ dig +tcp ubuntu.com @192.168.122.2
  ;; Connection to 192.168.122.2#53(192.168.122.2) for ubuntu.com failed: timed 
out.
  
  Symptoms are the number of tcp connections slowly increase, as well as
  the tcp high water mark increases, if you run the "rndc status" command.
  Eventually, the number of tcp connections will reach the tcp connection
  limit, and named will "break" and no longer accept any new tcp
  connections.
  
  There will also be a number of connections in the conntrack table stuck
  in the ESTABLISHED state, even through they are idle and ready to close,
  and there will be a number of connections in the SYN_SENT state, due to
  these connections getting stuck since the tcp connection limit has been
  reached.
  
  This appears to be caused by a race between deactivating a netmgr handle
  and processing a asynchronous callback for the socket close code, which
  can get triggered when a client sends a broken packet to the server and
  then doesn't close the connection properly.
  
  [Testcase]
  
  You will need two VMs to reproduce this issue.
  
  On the first, install bind9:
  
  $ sudo apt install bind9
  
  Set up a caching resolver by editing /etc/bind/named.conf.options and
  uncommenting the forwarding block, and adding a DNS provider:
  
  forwarders {
  8.8.8.8;
  };
+ 
+ If the DNS provider runs on dnsmasq/libvirt, also set:
+ 
+ dnssec-validation yes;
  
  Next, restart the named service:
  
  $ sudo systemctl restart named.service
  
  Edit /etc/resolv.conf and change the resolver to 127.0.0.1.
  
  Disable the systemd-resolved service:
  
  $ sudo systemctl stop systemd-resolved.service
  
  Test to make sure resolving ubuntu.com works, using the IP of the NIC:
  
  $ dig +tcp @192.168.122.21 ubuntu.com
  https://paste.ubuntu.com/p/7NQJ6RRJHN/
  
  Now, go to the second VM:
  
  Test to make sure that you can dig the other VM with:
  
  $ dig +tcp @192.168.122.21 ubuntu.com
  
  After that, use tc to intentionally drop some packets, so we can
  simulate bad clients dropping connections and not closing them properly,
  so we can see if we can trigger the race.
  
  My NIC is enp1s0, and 30% drop should do the trick.
  
  $ sudo tc qdisc add dev enp1s0 root netem loss 30%
  
  Next, open gnome-terminal and paste and run the below command in 10-15
  tabs, the more the better:
  
  $ for run in {1..1}; do dig +tcp @192.168.122.21 ubuntu.com & done
  
  This parallelizes the connections to the bind9 server, to try and get
  above the 150 connection limit.
  
  Back on the server, watch the tcp high water mark in:
  
  $ sudo rndc status
  ..
  tcp clients: 0/150
  TCP high-water: 10
  ..
  
  $ sudo rndc status
  ..
  tcp clients: 31/150
  TCP high-water: 58
  ..
  
  $ sudo rndc status
  ..
  tcp clients: 56/150
  TCP high-water: 141
  ..
  
  $ sudo rndc status
  ..
  tcp clients: 142/150
  TCP high-water: 150
  ..
  
  If you can't hit the 150 mark on tcp high water, add more tabs to the
  other VM and keep hitting the DNS server. This will likely make the
  other VM unstable as well, FYI.
  
  Eventually, you will hit the 150 mark. After hitting it a bit longer,
  your bind9 server will be broken.
  
  $ dig +tcp @192.168.122.21 ubuntu.com
  ;; Connection to 192.168.122.21#53(192.168.122.21) for ubuntu.com failed: 
timed out.
  ;; Connection to 192.168.122.21#53(192.168.122.21) for ubuntu.com failed: 
timed out.
  
  ; <<>> DiG 9.16.1-Ubuntu <<>> +tcp @192.168.122.21 ubuntu.com
  ; (1 server found)
  ;; global options: +cmd
  ;; connection timed out; no servers could be reached
  
  ;; Connection to 192.168.122.21#53(192.168.122.21) for ubuntu.com
  failed: timed out.
  
  Do this from the bind9 server, so you don't get confused with the 30%
  packet drop of the other VM.
  
  If you install the test package from the below ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/lp1909950-test
  
  You can hit this bind9 as much as 

[Bug 1906720] Re: Fix the disable_ssl_certificate_validation option

2021-02-11 Thread Mauricio Faria de Oliveira
and apport/amd64 played tricks on us, but it does pass now.

it passed on bionic-updates, which suggests a regression on bionic-proposed;
but another rereun with bionic-proposed now passed.. well. it's good now! :)

from [1]:

2.20.9-0ubuntu7.23  python-httplib2/0.9.2+dfsg-1ubuntu0.3   2021-02-10 
23:43:24 UTC 0h 12m 27s  mfo passlog   artifacts  
2.20.9-0ubuntu7.23  python-httplib2/0.9.2+dfsg-1ubuntu0.2   2021-02-10 
23:01:31 UTC 0h 10m 15s  mfo passlog   artifacts  
2.20.9-0ubuntu7.23  python-httplib2/0.9.2+dfsg-1ubuntu0.3   2021-02-10 
13:34:34 UTC 0h 13m 01s  mfo faillog   artifacts  
2.20.9-0ubuntu7.23  python-httplib2/0.9.2+dfsg-1ubuntu0.3   2021-02-09 
22:41:05 UTC 0h 11m 19s  -   faillog   artifacts   

[1] https://autopkgtest.ubuntu.com/packages/apport/bionic/amd64

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906720

Title:
  Fix the disable_ssl_certificate_validation option

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-httplib2/+bug/1906720/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1906720] Re: Fix the disable_ssl_certificate_validation option

2021-02-10 Thread Mauricio Faria de Oliveira
Heather and I discussed the autopkgtests failures today.

She's taking a look at fixing python-oslo.vmware, which
seems to be a missing Build-Depends: on python module(s)
nowadays, because the last time it passed was 2019-03.
It was reproducible with autopkgtests-virt-lxd locally.

For apport, it seems an interesting one, as it fails on
other archs except i386 for a long time, including amd64
but it has recently passed on amd64; thus reported as a
regression; but previous errors on other archs sometimes
include the failing test.  And it's been ~2 months since
it last passed, so maybe things changed.

Thus I'm rerunning it against python-httplib2 in -updates,
to hopefully confirm the failure is not a regression from
this upload.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906720

Title:
  Fix the disable_ssl_certificate_validation option

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/python-httplib2/+bug/1906720/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1909950] Re: named: TCP connections sometimes never close due to race in socket teardown

2021-02-10 Thread Mauricio Faria de Oliveira
** Tags added: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1909950

Title:
  named: TCP connections sometimes never close due to race in socket
  teardown

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-08 Thread Mauricio Faria de Oliveira
Some armhf autopkgtests finally ran, and unblocked mpd and samba.
Now re-running some systemd tests that have (again) been flaky, on amd64 and 
ppc64el, to unblock qemu; the last piece missing.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-04 Thread Mauricio Faria de Oliveira
That seemed to be correct; update_excuses is now updated,
and autopkgtests for mpd/samba/qemu are now running.

There were 3 regressions reported, each on a single arch,
which seemed to be unrelated to liburing; so just sent a
rerun request for them.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-04 Thread Mauricio Faria de Oliveira
TL;DR: giving it some time (tomorrow AM) for update_excuses to possibly 
realize that mpd/samba/qemu deps are satisfiable (or for me to realize
i might be missing something; details below.)

---

liburing migrated after some autopkgtests/triggers tweaks.
plocate migrated.

mpd, samba, qemu are blocked due to unsatisfiable deps (and one
uninstallable).

I could not reproduce any of those w/ selective upgrading from -proposed;
installing the mentioned package names just work, and when some deps are
needed from -proposed as well, they're fromt the same source package.

So I'll wait a bit more for perhaps update_excuses.html to update, in case
it's out of date;  i've looked at update_output.txt but these packages are
not listed in it.

---

mpd (0.22.3-1 to 0.22.4-1build1)
...
mpd/amd64 has unsatisfiable dependency 

$ sudo apt install --dry-run mpd/hirsute-proposed >/dev/null 2>&1; echo 
$?
0

$ sudo apt install --dry-run -t hirsute-proposed mpd >/dev/null 2>&1; 
echo $?
0
...
migrating mpd/0.22.4-1build1/amd64 to testing makes 
libtest-corpus-audio-mpd-perl/1.120990-2.1/amd64 uninstallable 

$ sudo apt install --dry-run libtest-corpus-audio-mpd-perl 
mpd/hirsute-proposed >/dev/null 2>&1; echo $?
0


samba (2:4.13.3+dfsg-1ubuntu1 to 2:4.13.3+dfsg-1ubuntu2)
...
samba-vfs-modules/amd64 has unsatisfiable dependency 
...

$ sudo apt-get install --dry-run samba-vfs-modules/hirsute-proposed 
>/dev/null 2>&1; echo $?
100

$ sudo apt-get install --dry-run -t hirsute-proposed samba-vfs-modules 
>/dev/null 2>&1; echo $?
0

$ sudo apt-get install --dry-run 
{samba-vfs-modules,samba-libs,libwbclient0}/hirsute-proposed >/dev/null 2>&1; 
echo $?
0


qemu (1:5.2+dfsg-3ubuntu1 to 1:5.2+dfsg-3ubuntu2)
...
qemu-guest-agent/amd64 has unsatisfiable dependency 

$ sudo apt install --dry-run qemu-guest-agent/hirsute-proposed 
>/dev/null 2>&1; echo $?
0

$ sudo apt install --dry-run -t hirsute-proposed qemu-guest-agent 
>/dev/null 2>&1; echo $?
0

qemu-system-x86/amd64 has unsatisfiable dependency

$ sudo apt-get install --dry-run qemu-system-x86/hirsute-proposed 
>/dev/null 2>&1; echo $?
100

$ sudo apt-get install --dry-run -t hirsute-proposed qemu-system-x86 
>/dev/null 2>&1; echo $?
0

$ sudo apt-get install --dry-run 
{qemu-system-x86,qemu-system-common,qemu-system-data,qemu-block-extra}/hirsute-proposed
 >/dev/null 2>&1; echo $?
0

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-04 Thread Mauricio Faria de Oliveira
Thanks for the info and the uploads.

That's good to know!

I didn't know it, and just added the bug reference in case it'd
be useful to find out why the no change rebuild was needed.

But I guess that can go in the changelog entry itself, right?

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
** Patch added: "lp1914145_qemu.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/liburing/+bug/1914145/+attachment/5459531/+files/lp1914145_qemu.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
** Patch added: "lp1914145_plocate.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/liburing/+bug/1914145/+attachment/5459530/+files/lp1914145_plocate.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
** Patch added: "lp1914145_mpd.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/liburing/+bug/1914145/+attachment/5459529/+files/lp1914145_mpd.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
** Patch added: "lp1914145_samba.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/liburing/+bug/1914145/+attachment/5459528/+files/lp1914145_samba.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
Hi Christian,

Attaching the debdiffs with no change rebuilds.

- samba is the most important, since it also fixes an autopkgtest
failure to unblock liburing in hirsute-proposed.

- mpd also has autopkgtests, but there's still a version in -proposed as
of now, so maybe it needs to wait (but since it's a no change rebuild,
maybe it can be overriden if needed?)

- plocate has no autopkgtests, lower priority.

- qemu neither, and is up to you depending on your qemu upload, per our
discussion.

Thanks!
Mauricio

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
liburing built successfully on all archs in hirsute-proposed.

autopkgtests look green (!) on amd64/arm64/ppc64el/s390x and
fail on armhf as seen previously (not a regression.)

autopkgtests for the reverse dependencies, in update_excuses:

- samba: fail consistently in all archs -- this is known and is fixed
with the no-change rebuild.

  current: [1]
smbclient-share-access-uring FAIL non-zero exit status 1

  no-change rebuild: [2]
smbclient-share-access-uring PASS

- mpd: fail in s390x, even w/ a few retries, i'll take a look.

  however, this is not the version in hirsute-proposed.
  it was blocked on build failure on ppc64el [3], no logs,
  i just retried it, and it finished successfully.

  we'll need the no-change rebuild anyway, on top of -proposed.

[1] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-mfo-lp1914145/hirsute/amd64/s/samba/20210202_233735_bb529@/log.gz
[2] 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-hirsute-mfo-lp1914145/hirsute/amd64/s/samba/20210203_220550_7e02e@/log.gz

[3]

update_excuses:

mpd (0.22.3-1 to 0.22.4-1)
...
Issues preventing migration:
missing build on ppc64el: mpd (from 0.22.3-1)
arch:ppc64el not built yet, autopkgtest delayed there
...

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
** Description changed:

  New version (0.7-3) available without our delta (already forwarded
  upstream), needs merge.
  
  Reverse dependencies [2] need No-Change-Rebuilds to pick up the new ABI,
  which unfortunately has been broken between 0.6-3 and 0.7-3 [3]:
  - mpd, samba, plocate, qemu
  
  Autopkgtests PASS on amd64/arm64/ppc64el/s390x, not run on riscv64, and fail 
on armhf (but not a regression); see the latest per-arch log.gz in
  [4] for runs against a PPA.
  
  Autopkgtests for the reverse dependencies:
- - mpd: PASS
- - samba: FAIL on cifs-share-access-uring (regression, probably due to the
-   ABI breakage; now re-rerunning w/ samba no-change-rebuild to confirm.)
+ - mpd: PASS (although failing consistently on s390x; will take a look)
+ - samba: FAIL on cifs-share-access-uring (regression due to ABI breakage;
+   passes with no-change-rebuilt samba and new liburing)
  - plocate: no tests.
  - qemu: no tests.
  
  Merge request: [1]
  
  [1]
  
https://code.launchpad.net/~mfo/ubuntu/+source/liburing/+git/liburing/+merge/397393
  
  [2] Reverse Dependencies:
  
  $ apt-cache rdepends liburing1 | awk '/^  / { print $1 }' | while read rdep; 
do apt-cache show $rdep | awk '/^Package:/ || /^Source:/ { print $2 }' | tail 
-n1; done | sort -u
  liburing
  mpd
  plocate
  qemu
  samba
  
  [3] Debian Bug #972758
  https://bugs.debian.org/972758
  
  [4]
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-hirsute-mfo-lp1914145?format=plain

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-03 Thread Mauricio Faria de Oliveira
** Description changed:

  New version (0.7-3) available without our delta (already forwarded
  upstream), needs merge.
  
  Reverse dependencies [2] need No-Change-Rebuilds to pick up the new ABI,
- which unfortunately has been broken between 0.6-3 and 0.7-3 [3].
+ which unfortunately has been broken between 0.6-3 and 0.7-3 [3]:
+ - mpd, samba, plocate, qemu
  
  Autopkgtests PASS on amd64/arm64/ppc64el/s390x, not run on riscv64, and fail 
on armhf (but not a regression); see the latest per-arch log.gz in
  [4] for runs against a PPA.
  
- (autopkgtests for the reverse dependencies with the new package are now
- running; except for qemu, which doesn't have tests. only for amd64 arch.)
- 
+ Autopkgtests for the reverse dependencies:
+ - mpd: PASS
+ - samba: FAIL on cifs-share-access-uring (regression, probably due to the
+   ABI breakage; now re-rerunning w/ samba no-change-rebuild to confirm.)
+ - plocate: no tests.
+ - qemu: no tests.
  
  Merge request: [1]
  
  [1]
  
https://code.launchpad.net/~mfo/ubuntu/+source/liburing/+git/liburing/+merge/397393
  
  [2] Reverse Dependencies:
  
  $ apt-cache rdepends liburing1 | awk '/^  / { print $1 }' | while read rdep; 
do apt-cache show $rdep | awk '/^Package:/ || /^Source:/ { print $2 }' | tail 
-n1; done | sort -u
  liburing
  mpd
  plocate
  qemu
  samba
  
  [3] Debian Bug #972758
  https://bugs.debian.org/972758
  
  [4]
  
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
  /autopkgtest-hirsute-mfo-lp1914145?format=plain

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1914145] Re: Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-02 Thread Mauricio Faria de Oliveira
** Description changed:

- New version available without our delta (already forwarded upstream),
- needs merge.
+ New version (0.7-3) available without our delta (already forwarded
+ upstream), needs merge.
+ 
+ Reverse dependencies need No-Change-Rebuilds to pick up the new ABI,
+ which unfortunately has been broken between 0.6-3 and 0.7-3 [2].
+ 
+ Merge request: [1]
+ 
+ [1]
+ 
https://code.launchpad.net/~mfo/ubuntu/+source/liburing/+git/liburing/+merge/397393
+ 
+ Reverse Dependencies: [2]
+ 
+ $ apt-cache rdepends liburing1 | awk '/^  / { print $1 }' | while read rdep; 
do apt-cache show $rdep | awk '/^Package:/ || /^Source:/ { print $2 }' | tail 
-n1; done | sort -u
+ liburing
+ mpd
+ plocate
+ qemu
+ samba

** Also affects: mpd (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: plocate (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: qemu (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: samba (Ubuntu)
   Importance: Undecided
   Status: New

** Description changed:

  New version (0.7-3) available without our delta (already forwarded
  upstream), needs merge.
  
- Reverse dependencies need No-Change-Rebuilds to pick up the new ABI,
- which unfortunately has been broken between 0.6-3 and 0.7-3 [2].
+ Reverse dependencies [2] need No-Change-Rebuilds to pick up the new ABI,
+ which unfortunately has been broken between 0.6-3 and 0.7-3 [3].
  
  Merge request: [1]
  
  [1]
  
https://code.launchpad.net/~mfo/ubuntu/+source/liburing/+git/liburing/+merge/397393
  
- Reverse Dependencies: [2]
+ [2] Reverse Dependencies:
  
  $ apt-cache rdepends liburing1 | awk '/^  / { print $1 }' | while read rdep; 
do apt-cache show $rdep | awk '/^Package:/ || /^Source:/ { print $2 }' | tail 
-n1; done | sort -u
  liburing
  mpd
  plocate
  qemu
  samba
+ 
+ [3] Debian Bug #972758 
+ https://bugs.debian.org/972758

** Changed in: mpd (Ubuntu)
   Status: New => In Progress

** Changed in: plocate (Ubuntu)
   Status: New => In Progress

** Changed in: qemu (Ubuntu)
   Status: New => In Progress

** Changed in: samba (Ubuntu)
   Status: New => In Progress

** Changed in: mpd (Ubuntu)
   Importance: Undecided => Wishlist

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

** Changed in: plocate (Ubuntu)
   Importance: Critical => Wishlist

** Changed in: qemu (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: samba (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: mpd (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: plocate (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: qemu (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: samba (Ubuntu)
     Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Description changed:

  New version (0.7-3) available without our delta (already forwarded
  upstream), needs merge.
  
  Reverse dependencies [2] need No-Change-Rebuilds to pick up the new ABI,
  which unfortunately has been broken between 0.6-3 and 0.7-3 [3].
+ 
+ Autopkgtests PASS on amd64/arm64/ppc64el/s390x, not run on riscv64, and fail 
on armhf (but not a regression); see the latest per-arch log.gz in
+ [4] for runs against a PPA.
  
  Merge request: [1]
  
  [1]
  
https://code.launchpad.net/~mfo/ubuntu/+source/liburing/+git/liburing/+merge/397393
  
  [2] Reverse Dependencies:
  
  $ apt-cache rdepends liburing1 | awk '/^  / { print $1 }' | while read rdep; 
do apt-cache show $rdep | awk '/^Package:/ || /^Source:/ { print $2 }' | tail 
-n1; done | sort -u
  liburing
  mpd
  plocate
  qemu
  samba
  
- [3] Debian Bug #972758 
+ [3] Debian Bug #972758
  https://bugs.debian.org/972758
+ 
+ [4]
+ 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac
+ /autopkgtest-hirsute-mfo-lp1914145?format=plain

** Description changed:

  New version (0.7-3) available without our delta (already forwarded
  upstream), needs merge.
  
  Reverse dependencies [2] need No-Change-Rebuilds to pick up the new ABI,
  which unfortunately has been broken between 0.6-3 and 0.7-3 [3].
  
  Autopkgtests PASS on amd64/arm64/ppc64el/s390x, not run on riscv64, and fail 
on armhf (but not a regression); see the latest per-arch log.gz in
  [4] for runs against a PPA.
+ 
+ (autopkgtests for the reverse dependencies with the new package are now
+ running; except for qemu, which doesn't have tests. only for amd64 arch.)
+ 
  
  Merge request: [1]
  
  [1]
  
https://code.launchpad.net/~mfo/ubuntu/+source/liburing/+git/liburing/+merge/397393
  
  [2] Reverse Dependencies:
  
  $ apt-cache rdepends liburing1 | awk '/^  / { print $1 }' | while read rdep; 
do apt-cache show $rdep | awk '/^Package:/ || /^Source:/ { print $2 }' | tail 
-n1; done | sort -u
  liburing
  mpd
  plocate
  qemu
  samba
  
  [3] Debian Bug #972758
  https://b

[Bug 1914145] [NEW] Please merge liburing 0.7-3 (main) from Debian unstable (main)

2021-02-01 Thread Mauricio Faria de Oliveira
Public bug reported:

New version available without our delta (already forwarded upstream),
needs merge.

** Affects: liburing (Ubuntu)
 Importance: Wishlist
 Assignee: Mauricio Faria de Oliveira (mfo)
 Status: In Progress

** Changed in: liburing (Ubuntu)
   Status: New => In Progress

** Changed in: liburing (Ubuntu)
   Importance: Undecided => Wishlist

** Changed in: liburing (Ubuntu)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1914145

Title:
  Please merge liburing 0.7-3 (main) from Debian unstable (main)

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1838152] Re: gnome-shell freezes on notification arrival (fixed upstream)

2021-01-28 Thread Mauricio Faria de Oliveira
Hi Luka/@zapduke,

Can you test/verify bionic-proposed?

Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1838152

Title:
  gnome-shell freezes on notification arrival (fixed upstream)

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-shell/+bug/1838152/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1912969] Re: librelp is FTBFS on riscv64 on Focal

2021-01-25 Thread Mauricio Faria de Oliveira
** Changed in: librelp (Ubuntu Hirsute)
 Assignee: (unassigned) => Matthew Ruffell (mruffell)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912969

Title:
  librelp is FTBFS on riscv64 on Focal

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-25 Thread Mauricio Faria de Oliveira
Thanks again, Matthew.

I've reviewed and sponsored the new debdiff for Focal, with the existing
changes (so we have .20.04.1 and .2 in the same upload, going in focal-
proposed again.)

Further details added in bug 1912969.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1912969] Re: librelp is FTBFS on riscv64 on Focal

2021-01-25 Thread Mauricio Faria de Oliveira
Hi Matthew,

Can you please upload a debdiff for Hirsute as well?

I'll ask one of our core devs to handle it.

Thank you!

** Description changed:

  [Impact]
  
  During the recent SRU for bug 1908473, we found that librelp is FTBFS on
  riscv64 on Focal, due to the test cases basic-realistic.sh and tls-
  basic-realistic.sh failing during dh_auto_test during package build.
  
  dh_auto_test --no-parallel
   make -j1 check VERBOSE=1
  ...
  make  check-TESTS
  make[4]: Entering directory '/<>/tests'
  ...
  FAIL: basic-realistic.sh
  FAIL: tls-basic-realistic.sh
  ...
  
  Relevant log: https://paste.ubuntu.com/p/hwYXSbKPPV/
  
  These tests attempt to send 50,000 messages between a server and client,
  and riscv64 is just too slow to complete sending all of these messages
  before the watchdog thinks the process gets stuck and kills it.
  
  Recent runs see "00046000 msgs sent" for basic-realistic.sh and
  "00029000 msgs sent" for tls-basic-realistic.sh, which misses the 50,000
  mark by a long shot.
  
  To fix, we will follow a similar pattern to an existing patch we carry
  already and trim down the number of messages sent to 10,000 which should
  reliably be possible on riscv64.
  
  [Testcase]
  
  Attempt to build librelp on on all architectures, and currently, riscv64
  will fail on Focal.
  
  If you apply the below patch to reduce messages for basic-realistic.sh
  and tls-basic-realistic.sh to 10,000 the build passes on riscv64, which
  you can see in the below ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/lp1912969-test
  
  [Where problems could occur]
  
  Since we are reducing the number of packets being sent in a testcase in
  an attempt to not time out the build, there should be little risk in
  this SRU.
  
  The tests are still continuing to run on all architectures, and are
  still at a meaningful high number of 10,000 packets, which should find
  any problems during subsequent builds in the future, but not slow down
  the build for riscv64.
+ 
+ [Other Info]
+ 
+ * Upload to Focal before Hirsute has been authorized by SRU team (#3).
+   Hirsute is being followed up on soon.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912969

Title:
  librelp is FTBFS on riscv64 on Focal

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1912969] Re: librelp is FTBFS on riscv64 on Focal

2021-01-25 Thread Mauricio Faria de Oliveira
Reviewed and sponsored to Focal.

Per chat with Lukasz/sil2100 is is OK to have this only in Focal first,
but we'd like to see this in Hirsute, so that when we eventually (maybe
after Hirsute) re-enable the tests in riscv64, this is covered.

Thus marking Hirsute as In Progress, but this can be followed up on
after the upload to Focal by a core developer.

(Groovy is not needed, as riscv64 tests won't be re-enabled for Groovy.)

** Also affects: librelp (Ubuntu Hirsute)
   Importance: Undecided
   Status: Fix Released

** Also affects: librelp (Ubuntu Groovy)
   Importance: Undecided
   Status: New

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

** Changed in: librelp (Ubuntu Hirsute)
   Status: Fix Released => In Progress

** Tags added: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1912969

Title:
  librelp is FTBFS on riscv64 on Focal

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces

2021-01-25 Thread Mauricio Faria de Oliveira
Marking all other packages/dev release as Invalid.

Per previous discussion with Jay, iirc, those are
leftovers from a previously considered solution(s)
which was not the final one (in initramfs-tools.)

And just Bionic had to be patched as later releases
were not affected.

Please feel free to fix-up if that's not accurate.

** Changed in: netplan
   Status: Triaged => Invalid

** Changed in: initramfs-tools (Ubuntu)
   Status: New => Invalid

** Changed in: netplan.io (Ubuntu)
   Status: Triaged => Invalid

** Changed in: netplan.io (Ubuntu Bionic)
   Status: New => Invalid

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1820929

Title:
  netplan should consider adding more udev attribute for exact matching
  of failover 3-netdev interfaces

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895351] Re: prepare plugin does not run in automatic mode

2021-01-25 Thread Mauricio Faria de Oliveira
@jibel done! sorry, I missed adding it earlier.

** Description changed:

+ [Impact]
+ 
+  * Currently ubiquity's prepare plugin, which installs the
+3rd party drivers, is not run at all in automatic mode.
+
+  * This prevents automatic installation of such drivers
+(e.g., nvidia drivers) which are shipped / available
+in the ISOs now; and thus could actually be installed.
+ 
+  * That causes additional network bandwidth consumption
+or additional steps to install them in offline cases.
+
+ [Fix]
+ 
+  * The MR allows the prepare plugin to run in automatic
+mode unconditionally in Hirsute and later, and Focal
+gets the 'ubiquity/prepare_automatic' preseed option
+to enable it (so not to change the default behavior.)
+ 
+  * Now users can use the existing 'ubiquity/use_nonfree'
+preseed option to install 3rd party drivers while in
+automatic mode (i.e., with the 'automatic-ubiquity'
+option, or running 'ubiquity --automatic'.)
+ 
+ [Test Case]
+ 
+  * Boot the live installer with the 'automatic-ubiquity'
+option, or run 'ubiquity --automatic' in the shell.
+
+  * Check whether the 'Updates and other software' page
+is listed or not.
+- Before: it is not.
+- After: 
+  - Hirsute: it is.
+  - Focal: according to 'ubiquity/prepare_automatic'.
+  
+  * The page can be automatically configured via preseed
+options, and be skipped with the key preseed option
+'ubiquity/use_nonfree'.
+ 
+  * Then 3rd party drivers should be installer or not
+according to the option value and system hardware.
+ 
+ [Where problems could occur]
+ 
+  * Automatic installations that didn't configure the
+'ubiquity/use_nonfree' option configured will now
+block in the 'Updates and other software' page,
+waiting for input (in Hirsute and later) and thus
+need to have their preseed file/options updated.
+
+  * In Focal that behavior doesn't change by default,
+and the users have to opt-in with the new option
+'ubiquity/prepare_automatic', so they are already
+updating the preseed file/options.
+ 
+  * If there are any existing problems in the prepare
+plugin, they may now be exposed in automatic mode.
+However, since it runs by default in manual Desktop
+installs it's not expected to have any known issues.
+ 
+  * If issues happen with the option enabled in Focal,
+users can opt-out with the new preseed option; and
+in Groovy (where it's not available), bug reports
+on it before release may be reported and addressed.
+ 
+ [Other Info]
+  
+  * Hirsute and Focal are patched; Groovy is not because
+there are no more Desktop ISO spins planned (standard
+release) thus this patch is not effectively used on G.
+ 
+ [Original Description]
+ 
  Currently the prepare plugin is just not run at all in automatic mode.
  
  But some users could benefit from it now that the ISOs ship with
  e.g., nvidia drivers, to install 3rd party drivers automatically
  during install, and not consume network bandwidth to download it.
  
  The MR introduces the 'ubiquity/prepare_automatic' preseed option
  to allow the prepare plugin to run in automatic mode (i.e. with
  the 'automatic-ubiquity' option / ubiquity --automatic)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895351

Title:
  prepare plugin does not run in automatic mode

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-22 Thread Mauricio Faria de Oliveira
Hi Matthew,

Thanks for the analysis.

We'll need such changes on top of what's in -proposed (ie, in an
incremental version), re-uploaded.

Please see `dpkg-buildpackage -v` to generate a package build including
the version in -proposed plus the new version with the workaround for
the test-case.

And as always, feel free to reach out if there's anything I can help
with!

cheers,
Mauricio

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-21 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-21 Thread Mauricio Faria de Oliveira
Hi Matthew,

I've kicked one or two rebuilds today, and still see the (same) one or
two tests failing.

I'm out this week so can't look much more into it (althogh I'm
admittedly curious about it :)

If you can take a look at these FTBFS test case failures, that would be
awesome; all archs must pass for the SRU to be released. Maybe you can
get access to a riscv64 instance, or the issue perhaps reproduces in
QEMU?

Otherwise I can try and take a look on Monday.

cheers,
Mauricio

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-21 Thread Mauricio Faria de Oliveira
The functionality is present in the desktop ISO daily build of
2021-01-21 [1] , per the ISO manifest file [2]:

ubiquity 20.04.15.3

It has been verified to work correctly on testing of that ISO, with the
following in a preseed file:

ubiquity partman-crypto/luksformat_options string \
--type luks1

cheers,
Mauricio

[1] https://cdimage.ubuntu.com/focal/daily-live/20210121/
[2] 
https://cdimage.ubuntu.com/focal/daily-live/20210121/focal-desktop-amd64.manifest

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895351] Re: prepare plugin does not run in automatic mode

2021-01-21 Thread Mauricio Faria de Oliveira
Added Groovy as Won't Fix, since there are no more installer spins.

Added Focal as In Progress, the backport MR has been submitted [1].

[1] https://code.launchpad.net/~mfo/ubiquity/+git/ubiquity/+merge/396500


** Also affects: ubiquity (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: ubiquity (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: ubiquity (Ubuntu Hirsute)
   Importance: Medium
 Assignee: Mauricio Faria de Oliveira (mfo)
   Status: Fix Committed

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

** Changed in: ubiquity (Ubuntu Focal)
   Status: New => In Progress

** Changed in: ubiquity (Ubuntu Focal)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895351

Title:
  prepare plugin does not run in automatic mode

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-19 Thread Mauricio Faria de Oliveira
Now the two tests failed again.

I have to EOD, and this might benefit from some delay, in case the transient 
condition just goes away.
Also, let's not overload the riscv64 builder with this so other builds can move 
on.

We have 7 days in -proposed to look at this in more detail (or the bad
condition to go away), and get it built.

** Attachment added: 
"buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.4"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5454592/+files/buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.4

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-19 Thread Mauricio Faria de Oliveira
Same one failure, re-building again.

** Attachment added: 
"buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.3"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5454591/+files/buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.3

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-19 Thread Mauricio Faria de Oliveira
and now it had only 1 failure in the test suite,
thus indeed a transient/arch-specific flakiness.

re-building once again.

$ zgrep '^FAIL: .*sh$' 
buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.*
buildlog_ubuntu-focal-

riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.1:FAIL: 
basic-realistic.sh
buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.1:FAIL:
 tls-basic-realistic.sh
buildlog_ubuntu-focal-

riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.2:FAIL: tls-
basic-realistic.sh

** Attachment added: 
"buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.2"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5454590/+files/buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz.2

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-19 Thread Mauricio Faria de Oliveira
focal/riscv64 had 2 failures in the test suite.

i've requested a re-build so it runs again, as
it seems more related to the arch or something
transient than the patchset, as only this arch
and release hit it.
(groovy: all archs ok, focal: other archs ok)

attaching build log for ref (it's lost on retry)

** Attachment added: 
"buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5454568/+files/buildlog_ubuntu-focal-riscv64.librelp_1.5.0-1ubuntu2.20.04.1_BUILDING.txt.gz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-14 Thread Mauricio Faria de Oliveira
** Patch added: "lp1908473_librelp_groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5453105/+files/lp1908473_librelp_groovy.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-14 Thread Mauricio Faria de Oliveira
** Patch added: "lp1908473_librelp_focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1908473/+attachment/5453106/+files/lp1908473_librelp_focal.debdiff

** Description changed:

  [Impact]
  
  In recent versions of rsyslog and librelp, the imrelp module leaks file
  descriptors due to a bug where it does not correctly close sockets, and
  instead, leaves them in the CLOSE_WAIT state.
  
  This causes rsyslogd on busy servers to eventually hit the limit of
  maximum open files allowed, which locks rsyslogd up until it is
  restarted.
  
  A workaround is to restart rsyslogd every month or so to manually close
  all of the open sockets.
  
  Only users of the imrelp module are affected, and not rsyslog users in
  general.
  
  [Testcase]
  
  Install the rsyslog-relp module like so:
  
  $ sudo apt install rsyslog rsyslog-relp
  
  Next, generate a working directory, and make a config file that loads
  the relp module.
  
  $ sudo mkdir /workdir
  $ cat << EOF >> ./spool.conf
  \$LocalHostName spool
  \$AbortOnUncleanConfig on
  \$PreserveFQDN on
  
  global(
  workDirectory="/workdir"
  maxMessageSize="256k"
  )
  
  main_queue(queue.type="Direct")
  module(load="imrelp")
  input(
  type="imrelp"
  name="imrelp"
  port="601"
  ruleset="spool"
  MaxDataSize="256k"
  )
  
  ruleset(name="spool" queue.type="direct") {
  }
  
  # Just so rsyslog doesn't whine that we do not have outputs
  ruleset(name="noop" queue.type="direct") {
  action(
  type="omfile"
  name="omfile"
  file="/workdir/spool.log"
  )
  }
  EOF
  
  Verify that the config is valid, then start a rsyslog server.
  
  $ sudo rsyslogd -f ./spool.conf -N9
  $ sudo rsyslogd -f ./spool.conf -i /workdir/rsyslogd.pid
  
  Fetch the rsyslogd PID and check for open files.
  
  $ RLOGPID=$(cat /workdir/rsyslogd.pid)
  $ sudo ls -l /proc/$RLOGPID/fd
  total 0
  lr-x-- 1 root root 64 Dec 17 01:22 0 -> /dev/urandom
  lrwx-- 1 root root 64 Dec 17 01:22 1 -> 'socket:[41228]'
  lrwx-- 1 root root 64 Dec 17 01:22 3 -> 'socket:[41222]'
  lrwx-- 1 root root 64 Dec 17 01:22 4 -> 'socket:[41223]'
  lrwx-- 1 root root 64 Dec 17 01:22 7 -> 'anon_inode:[eventpoll]'
  
  We have 3 sockets open by default. Next, use netcat to open 100
  connections:
  
  $ for i in {1..100} ; do nc -z 127.0.0.1 601 ; done
  
  Now check for open file descriptors, and there will be an extra 100 sockets
  in the list:
  
  $ sudo ls -l /proc/$RLOGPID/fd
  
  https://paste.ubuntu.com/p/f6NQVNbZcR/
  
  We can check the state of these sockets with:
  
  $ ss -t
  
  https://paste.ubuntu.com/p/7Ts2FbxJrg/
  
  The listening sockets will be in CLOSE-WAIT, and the netcat sockets will
  be in FIN-WAIT-2.
  
  $ ss -t | grep CLOSE-WAIT | wc -l
  100
  
  If you install the test package available in the following ppa:
  
  https://launchpad.net/~mruffell/+archive/ubuntu/sf299578-test
  
  When you open connections with netcat, these will be closed properly,
  and the file descriptor leak will be fixed.
  
  [Where problems could occur]
  
  If a regression were to occur, it would be limited to users of the
  imrelp module, which is a part of the rsyslogd-relp package, and depends
  on librelp.
  
  rsyslog-relp is not part of a default installation of rsyslog, and is
  opt in by changing a configuration file to enable imrelp.
  
- The changes to rsyslog implement a testcase which exercises the
- problematic code to ensure things are working as expected, and should
- run during autopkgtest time.
+ The changes to rsyslog implement a testcase which exercises the problematic 
code to ensure things are working as expected; this
+ can be enabled manually on build, and has been verified to pass (#7).
  
  [Other]
  
  Upstream bug list:
  
  https://github.com/rsyslog/rsyslog/issues/4350
  https://github.com/rsyslog/rsyslog/issues/4005
  https://github.com/rsyslog/librelp/issues/188
  https://github.com/rsyslog/librelp/pull/193
  
  The following commits fix the problem:
  
  rsyslogd
  
  
  commit baee0bd5420649329793746f0daf87c4f59fe6a6
  Author: Andre lorbach 
  Date:   Thu Apr 9 13:00:35 2020 +0200
  Subject: testbench: Add test for imrelp to check broken session handling.
  Link: 
https://github.com/rsyslog/rsyslog/commit/baee0bd5420649329793746f0daf87c4f59fe6a6
  
  librelp
  ===
  
  commit 7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
  Author: Andre lorbach 
  Date:   Mon May 11 14:59:55 2020 +0200
  Subject: fix memory leak on session break.
  Link: 
https://github.com/rsyslog/librelp/commit/7907c9c57f6ed94c8ce5a4e63c3c4e019f71cff0
  
  commit 4a6ad8637c244fd3a1caeb9a93950826f58e956a
  Author: Andre lorbach 
  Date:   Wed Apr 8 15:55:32 2020 +0200
  Subject: replsess: fix double free of sendbuf in some cases.
  Link: 
https://github.com/rsyslog/librelp/commit/4a6ad8637c244fd3a1caeb9a93950826f58e956a
  
  commit 3797944fb62273fa1164acd3104f0894b337c4d0
  Author: Ognyan Kulev 
  

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-14 Thread Mauricio Faria de Oliveira
Matthew, thanks for the great work in this bug and patches.

Uploaded to Groovy and Focal w/ trivial changes; attached.

cheers,
Mauricio

...

debdiffs:

I've modified the patch files slightly, as we discussed;
- keep the commit messages;
- use its/patch headers for DEP3, adding Origin: / Bug-Ubuntu:
- added prefix keywords upstream/backport to Origin;, 
  and documented changes done to backport patches 2,3.

upstream:

- no additional changes upstream that further change/fix these patches.

downstream:

- changelog looks good.
- version numbers and upgrade path look good.
- no other current uploads/versions in -proposed
- no block-proposed[-] tag

build:

The packages built successfully on all architectures on
a PPA with -proposed enabled (as on build environments.)

tests:

I've done testing with your steps (thanks!) and the new test introduced in 
patch 2, manually.
Unfortunately it doesn't run at build time as the package --disable-valgrind in 
debian/rules.

> PASS: basic-sessionbreak-vg.sh # --enable-valgrind in d/rules; install
valgrind/libtool; chmod +x

And also we don't have autopkgtests on librelp [1] nor rsyslog [2]
(single reverse dep for librelp0).

So the two tests above seem to be really the only tests for this. 
All good as both have positive results!

...

$ grep Package: debian/control
Package: librelp0
Package: librelp-dev

$ apt rdepends librelp0
librelp0
Reverse Depends:
  Depends: librelp-dev (= 1.5.0-1ubuntu2)
  Depends: rsyslog-relp (>= 1.5.0)
  Depends: rsyslog-relp (>= 1.4.0)

ubuntu@librelp-f:~/librelp-1.5.0$ apt rdepends librelp-dev
librelp-dev
Reverse Depends:

$ apt-cache show rsyslog-relp | grep Source:
Source: rsyslog
Source: rsyslog

[1] https://autopkgtest.ubuntu.com/packages/librelp
[1] https://autopkgtest.ubuntu.com/packages/rsyslog

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-14 Thread Mauricio Faria de Oliveira
Verification done for focal-proposed
---

All good, the package from -proposed works correctly in both scenarios
-- without the option (ie, default behavior) and with the option (ie,
opt-in behavior.)

Note: tested on VM with UEFI OVMF firmware with secure boot enabled 
(OVMF_CODE_4M.ms.fd), as shim-signed is also updated in the upload.
All good -- both scenarios install/boot to login screen w/ secboot.


Steps:
=

On install, select Try Ubuntu, and launch Terminal.

$ sudo add-apt-repository 'deb http://archive.ubuntu.com/ubuntu focal-proposed 
main' && sudo apt install -y ubiquity && apt policy ubiquity
...
ubiquity:
  Installed: 20.04.15.3
  Candidate: 20.04.15.3
  Version table:
 *** 20.04.15.3 500
500 http://archive.ubuntu.com/ubuntu focal-proposed/main amd64 Packages
100 /var/lib/dpkg/status
...

$ grep -c luksopts /lib/partman/lib/crypto-base.sh 
4

$ dmesg | grep -i secure
[0.00] secureboot: Secure boot enabled
[0.00] Kernel is locked down from EFI Secure Boot mode; see man 
kernel_lockdown.7
[0.008398] secureboot: Secure boot enabled

Move on with installer, select install to LVM/Encrypt.

Check on Terminal:

$ lsblk --ascii | grep -B1 crypt
`-vda3252:30   8.8G  0 part  
  `-vda3_crypt253:00   8.8G  0 crypt


Without option (default)
---

$ sudo debconf-get partman-crypto/luksformat_options

$

$ sudo cryptsetup luksDump /dev/vda3 | head -n2
LUKS header information
Version:2


With option (opt-in)
---

$ sudo debconf-get partman-crypto/luksformat_options
--type luks1
$

$ sudo cryptsetup luksDump /dev/vda3 | head -n3
LUKS header information for /dev/vda3

Version:1

$ grep luks /var/log/partman 
/usr/bin/autopartition-crypto: Additional options for luksFormat: '--type luks1'


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

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-13 Thread Mauricio Faria de Oliveira
** Patch added: "lp1898129_focal_ubiquity.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1898129/+attachment/5452745/+files/lp1898129_focal_ubiquity.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-13 Thread Mauricio Faria de Oliveira
Verification done for focal-proposed (partman-crypto)
---

1) Booted the Ubuntu 20.04.1 Desktop ISO.
2) Launched a terminal, extracted the .udeb and copied over the crypto-base.sh 
file.
3) Performed installation to encrypted disk without the preseed option 
(default).
4) Performed installation to encrypted disk with the preseed option (testing).

On both cases, the installation finishes successfully, and the system can boot.
The LUKS header version is used as expected (LUKS2 by default, LUKS1 w/ option)

Details:
---

Launch terminal:

$ wget 
https://launchpad.net/ubuntu/+archive/primary/+files/partman-crypto_101ubuntu4.1_amd64.udeb
$ dpkg-deb -x partman-crypto_101ubuntu4.1_amd64.udeb udeb
$ sudo cp udeb/lib/partman/lib/crypto-base.sh /lib/partman/lib/crypto-base.sh

$ grep luksopts /lib/partman/lib/crypto-base.sh
local mapping device cipher iv size pass luksopts
luksopts="$RET"
log "Additional options for luksFormat: '$luksopts'"
log-output -t partman-crypto /sbin/cryptsetup -c $cipher-$iv -h 
$hash -s $size $luksopts luksFormat $device $pass

Launch ubiquity / Install Ubuntu 20.04.1 Desktop to Encrypted LVM device.
(In 'Installation type', select 'Erase disk and install Ubuntu', click in 
'Advanced features', select 'Use LVM ...', select 'Encrypt ...', and move on to 
'Install Now')

Launch terminal:

Without the option:

$ sudo debconf-get partman-crypto/luksformat_options
$ 


$ lsblk --ascii | grep -B1 crypt
`-vda6252:60   8.8G  0 part  
  `-vda6_crypt253:00   8.8G  0 crypt

$ sudo cryptsetup luksDump /dev/vda6 | head -n2
LUKS header information
Version:2

With the option:

$ sudo debconf-get partman-crypto/luksformat_options
--type luks1

$ lsblk --ascii | grep -B1 crypt
`-vda6252:60   8.8G  0 part  
  `-vda6_crypt253:00   8.8G  0 crypt
  
$ sudo cryptsetup luksDump /dev/vda6 | head -n3
LUKS header information for /dev/vda6

Version:1

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-13 Thread Mauricio Faria de Oliveira
Uploaded ubiquity to focal.

Two notes:

1) The 'debian/rules update' process picked up the new partman-crypto from 
focal-proposed, and also shim-signed.
Discussed this with Laney and it shouldn't be an issue, as the ISO .list file 
already shows the new version, so it's being used for a while now.
Nonetheless, I'll test a secure boot scenario w/ a VM and OVMF/UEFI.

2) There's new pyflakes in focal-proposed that cause ubiquity to FTBFS.
This is a simple change already in Groovy, so just picking that up too.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-13 Thread Mauricio Faria de Oliveira
Based on good test results with partman-crypto (comment #19)
now moving on with ubiquity (to include the updated sources).

Tests with the patched packaged built from a PPA are positive.
The results are identical to the reported for partman-crypto
(LUKS2/LUKS1 by default/as requested; installed system boots.)


Testing ubiquity from PPA:
-

Booted the Ubuntu 20.04.1 Desktop ISO.
Launch terminal:

$ sudo add-apt-repository ppa:mfo/lp1898129prop2
$ sudo apt install -y ubiquity

$ dpkg -s ubiquity | grep Version:
Version: 20.04.15.3

$ grep luksopts /lib/partman/lib/crypto-base.sh
local mapping device cipher iv size pass luksopts
luksopts="$RET"
log "Additional options for luksFormat: '$luksopts'"
log-output -t partman-crypto /sbin/cryptsetup -c $cipher-$iv -h 
$hash -s $size $luksopts luksFormat $device $pass

Without the option:

$ sudo debconf-get partman-crypto/luksformat_options

$

$ lsblk --ascii | grep -B1 crypt
`-vda6252:60   8.8G  0 part  
  `-vda6_crypt253:00   8.8G  0 crypt 

$ sudo cryptsetup luksDump /dev/vda6 | head -n2
LUKS header information
Version:2

With the option:

$ sudo debconf-get partman-crypto/luksformat_options
--type luks1

$ lsblk --ascii | grep -B1 crypt
`-vda6252:60   8.8G  0 part  
  `-vda6_crypt253:00   8.8G  0 crypt
  
$ sudo cryptsetup luksDump /dev/vda6 | head -n3
LUKS header information for /dev/vda6

Version:1

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1908473] Re: rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which leads to file descriptor leak

2021-01-13 Thread Mauricio Faria de Oliveira
** Tags added: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1908473

Title:
  rsyslog-relp: imrelp module leaves sockets in CLOSE_WAIT state which
  leads to file descriptor leak

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-07 Thread Mauricio Faria de Oliveira
Uploaded partman-crypto to focal.

After it makes it to focal-proposed,
updated ubiquity upload will follow.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-07 Thread Mauricio Faria de Oliveira
** Patch added: "lp1898129_focal_partman-crypto.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1898129/+attachment/5450385/+files/lp1898129_focal_partman-crypto.debdiff

** Tags added: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2021-01-07 Thread Mauricio Faria de Oliveira
In order to fix this for Focal / 20.04.2 point release:

Groovy is a no-op, because:

1) it has no partman-crypto as stand-alone src pkg anymore.
2) its ubiquity (w/ bundled partman-crypto) doesn't need a
   patch as there won't be new ISOs/Desktop install for it.
[thus, partman-crypto: Invalid / ubiquity: Won't Fix.]

Focal needs the fix in both, in two steps:

1) patch partman-crypto (stills exists as stand-alone src pkg.)
2) update ubiquity w/ the patched partman-crypto (in proposed.)
[thus, partman-crypto: In Progress / ubiquity: In Progress.]


** Description changed:

+ [Impact]
+ 
+  * Users cannot specify options for 'cryptsetup luksFormat'
+that is used by the installer.
+ 
+  * Some deployments need the installed disks in LUKS1 format
+for backward compatibility with older releases that don't
+support LUKS2, for backup/audit/management purposes.
+ 
+  * However, on Focal and later, cryptsetup defaults to LUKS2,
+which broke that functionality.
+
+  * Currently it's not possible to request the LUKS format in
+the installer, so this patch allows for that w/ a preseed
+option ('partman-crypto/luksformat_options') for the user.
+ 
+ [Test Case]
+ 
+  * Default behavior: LUKS2
+  
+- Install Ubuntu (Focal/later); check LUKS header version:
+
+  $ sudo cryptsetup luksDump /dev/vda4
+  LUKS header information
+  Version: 2
+  ...
+  
+  * Opt-in behavior: LUKS1 (for example; can use other options)
+  
+- Install Ubuntu (Focal/later) with preseed file/option:
+ 
+  ubiquity partman-crypto/luksformat_options string \
+--type luks1
+ 
+- Check LUKS header version:
+
+  $ sudo cryptsetup luksDump /dev/vda4
+  LUKS header information for /dev/vda4
+  Version: 1
+  ...
+ 
+- Check install logs for confirmation:
+
+  $ grep luksFormat /var/log/partman
+  /usr/bin/autopartition-crypto: Additional options for luksFormat: 
'--type luks1'
+
+ [Where problems could occur]
+ 
+  * The changes are contained within the partman-crypto functionality,
+so only install with encrypted disks should be affected by issues.
+ 
+  * Any additional options specified to 'cryptsetup luksFormat' are
+opt-in _and_ specified by the user via the preseed option, thus
+errors are probably tied to particular options (mis) used.
+ 
+  * If the preseed option is not specified, original behavior remains.
+ 
+ [Other Info]
+  
+  * This patch is applied in Hirsute.
+  * This patch is not needed in Groovy (rationale in comment #15.)
+  * This patch is targeted at Focal (cryptsetup defaulted to LUKS2.)
+  * This patch is not needed in Bionic/earlier (^defaults to LUKS1.)
+ 
+ [Original Description]
  Most users should be fine with the options to
  'cryptsetup luksFormat' used by the installer.
  
  However, some users may have reasons to use
  other options, and that is not possible now.
  
  Let's provide a new preseed option for that:
  'partman-crypto/luksformat_options'

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2021-01-06 Thread Mauricio Faria de Oliveira
Verification done for bionic-proposed.

The conntrack default ns and per-ns files for 'conntrack -L' and
'conntrack -S' are now present.

$ echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs)-proposed main 
universe" \
| sudo tee /etc/apt/sources.list.d/proposed.list \
&& sudo apt update \
&& sudo apt install -y sosreport conntrack conntrackd

$ sudo ip netns add ns1 && sudo ip netns add ns2 && sudo ip netns add
ns3

$ sudo ip netns
ns3
ns2
ns1

$ lsb_release -cs
bionic

$ dpkg -s sosreport | grep Version:
Version: 3.9.1-1ubuntu0.18.04.3

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack | sort
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrack_-L_-o_extended
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrack_-S
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_cache
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_ct
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_expect
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_link
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_network
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_queue
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_rsqueue
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/conntrackd_-s_runtime
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-L_-o_extended
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-S
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-L_-o_extended
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-S
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-L_-o_extended
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-S

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

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2021-01-06 Thread Mauricio Faria de Oliveira
Verification done for groovy-proposed.

The conntrack default ns and per-ns files for 'conntrack -L' and
'conntrack -S' are now present.

$ echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs)-proposed main 
universe" \
| sudo tee /etc/apt/sources.list.d/proposed.list \
&& sudo apt update \
&& sudo apt install -y sosreport conntrack conntrackd

$ sudo ip netns add ns1 && sudo ip netns add ns2 && sudo ip netns add
ns3

$ sudo ip netns
ns3
ns2
ns1


$ lsb_release -cs
groovy

$ dpkg -s sosreport | grep Version:
Version: 4.0-1ubuntu2.1

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack | sort
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrack_-L_-o_extended
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrack_-S
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_cache
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_ct
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_expect
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_link
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_network
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_queue
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_rsqueue
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/conntrackd_-s_runtime
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-L_-o_extended
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-S
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-L_-o_extended
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-S
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-L_-o_extended
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-S

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2021-01-06 Thread Mauricio Faria de Oliveira
Verification done for focal-proposed.

The conntrack default ns and per-ns files for 'conntrack -L' and
'conntrack -S' are now present.

$ echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs)-proposed main 
universe" \
| sudo tee /etc/apt/sources.list.d/proposed.list \
&& sudo apt update \
&& sudo apt install -y sosreport conntrack conntrackd

$ sudo ip netns add ns1 && sudo ip netns add ns2 && sudo ip netns add
ns3

$ sudo ip netns
ns3
ns2
ns1

$ lsb_release -cs
focal

$ dpkg -s sosreport | grep Version:
Version: 4.0-1~ubuntu0.20.04.3

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack | sort
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrack_-L_-o_extended
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrack_-S
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_cache
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_ct
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_expect
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_link
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_network
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_queue
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_rsqueue
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/conntrackd_-s_runtime
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-L_-o_extended
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-S
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-L_-o_extended
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-S
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-L_-o_extended
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-S

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2021-01-06 Thread Mauricio Faria de Oliveira
Verification done for bionic-proposed.

The per-ns files for 'ip neigh' and 'ip rule' are now present.

$ echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs)-proposed main 
universe" \
| sudo tee /etc/apt/sources.list.d/proposed.list \
&& sudo apt update \
&& sudo apt install -y sosreport conntrack conntrackd

$ sudo ip netns add ns1 && sudo ip netns add ns2 && sudo ip netns add
ns3

$ sudo ip netns
ns3
ns2
ns1

$ lsb_release -cs
bionic

$ dpkg -s sosreport | grep Version:
Version: 3.9.1-1ubuntu0.18.04.3

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule | sort
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_-4_rule
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_-6_rule
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_neigh_show_nud_noarp
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_netns_exec_ns1_ip_-s_-s_neigh_show
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_netns_exec_ns1_ip_rule_list
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_netns_exec_ns2_ip_-s_-s_neigh_show
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_netns_exec_ns2_ip_rule_list
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_netns_exec_ns3_ip_-s_-s_neigh_show
sosreport-mfo-sos-b-2021-01-06-kyiprqo/sos_commands/networking/ip_netns_exec_ns3_ip_rule_list


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

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2021-01-06 Thread Mauricio Faria de Oliveira
Verification done for focal-proposed.

The per-ns files for 'ip neigh' and 'ip rule' are now present.

$ echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs)-proposed main 
universe" \
| sudo tee /etc/apt/sources.list.d/proposed.list \
&& sudo apt update \
&& sudo apt install -y sosreport conntrack conntrackd

$ sudo ip netns add ns1 && sudo ip netns add ns2 && sudo ip netns add
ns3

$ sudo ip netns
ns3
ns2
ns1

$ lsb_release -cs
focal

$ dpkg -s sosreport | grep Version:
Version: 4.0-1~ubuntu0.20.04.3

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule | sort
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_-4_rule
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_-6_rule
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_neigh_show_nud_noarp
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_netns_exec_ns1_ip_-s_-s_neigh_show
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_netns_exec_ns1_ip_rule_list
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_netns_exec_ns2_ip_-s_-s_neigh_show
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_netns_exec_ns2_ip_rule_list
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_netns_exec_ns3_ip_-s_-s_neigh_show
sosreport-mfo-sos-f-2021-01-06-imeiaft/sos_commands/networking/ip_netns_exec_ns3_ip_rule_list


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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2021-01-06 Thread Mauricio Faria de Oliveira
Verification done for groovy-proposed.

The per-ns files for 'ip neigh' and 'ip rule' are now present.

$ echo "deb http://archive.ubuntu.com/ubuntu $(lsb_release -cs)-proposed main 
universe" \
| sudo tee /etc/apt/sources.list.d/proposed.list \
&& sudo apt update \
&& sudo apt install -y sosreport conntrack conntrackd

$ sudo ip netns add ns1 && sudo ip netns add ns2 && sudo ip netns add
ns3

$ sudo ip netns
ns3
ns2
ns1

$ lsb_release -cs
groovy

$ dpkg -s sosreport | grep Version:
Version: 4.0-1ubuntu2.1

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule | sort
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_-4_rule
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_-6_rule
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_neigh_show_nud_noarp
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_netns_exec_ns1_ip_-s_-s_neigh_show
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_netns_exec_ns1_ip_rule_list
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_netns_exec_ns2_ip_-s_-s_neigh_show
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_netns_exec_ns2_ip_rule_list
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_netns_exec_ns3_ip_-s_-s_neigh_show
sosreport-mfo-sos-g-2021-01-06-wkdqtsk/sos_commands/networking/ip_netns_exec_ns3_ip_rule_list

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2021-01-06 Thread Mauricio Faria de Oliveira
>> +# Collect info from conntrackd
>
> This change seems to have disappeared in the backport to Bionic, but it 
> doesn't matter so I left it.

Nice catch; I missed that one, sorry.
Thanks for the flexibility with that.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-31 Thread Mauricio Faria de Oliveira
** Description changed:

+ [Impact]
+ 
+  * sosreport currently does not collect commands
+'ip neigh' and 'ip rule' for network namespaces,
+which are used with e.g., openstack neutron.
+ 
+ [Test Case]
+ 
+  * Create network namespace(s) (eg, ns1, ns2, ns3)
+$ sudo ip netns add ns1
+$ sudo ip netns add ns2
+$ sudo ip netns add ns3
+ 
+  * Run the sosreport networking plugin
+$ sudo sos report -o networking --batch
+ 
+  * Check the sosreport tarball for per-netns files
+('ip_netns_exec__') for the commands
+'ip -s -s neigh show' and 'ip rule list'
+ 
+  * See comments 4, 5, 6 for examples.
+ 
+ [Regression Potential]
+ 
+  * The patch adds commands to the networking plugin,
+thus any issue should be contained within/happen
+on it.
+ 
+  * Errors in running such commands aren't a problem,
+and should be logged by sosreport anyway.
+ 
+ [Other Info]
+ 
  Closes:
  https://github.com/sosreport/sos/issues/2281
  
  PR:
  
https://github.com/sosreport/sos/pull/2282/commits/41182ac9bde87b29499489a112ab24dcc9a374b0

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-31 Thread Mauricio Faria de Oliveira
** Description changed:

  [Impact]
  
  * The plugin conntrackd is renamed to conntrack.
+   (enabled automatically per installed packages.)
  
- * Added the following
- conntrack commands to the plugin.
- conntrack -L -o extended
- conntrack -S
+ * Added the following conntrack commands to the plugin,
+   which run on default and other network namespaces:
+ 
+   conntrack -L -o extended
+   conntrack -S
  
  [Test Case]
  
  * Install sosreport
- * sosreport -a will exercise 'conntrack' plugin if one of the following 
packages installation is met: ('conntrack-tools', 'conntrack', 'conntrackd'),
+ 
+ * sosreport -a will exercise 'conntrack' plugin if one of the following
+ packages installation is met: ('conntrack-tools', 'conntrack',
+ 'conntrackd'),
  
  * Alternative way to exercise the plugin :
    ** 'sosreport -o conntrack'
    ** 'sos report -o conntrack'
  
  * Then a sosreport tarball will be generated under /tmp
- * Extract that said tarball, and look under 
/path_to_sosreport/sos_commands/conntrack/
+ 
+ * Extract that said tarball, and look under
+ /path_to_sosreport/sos_commands/conntrack/
  
  And one should see 2 new files, one for each new commands added by this
- command.
+ command, for the default and other network namespaces.
  
  [Regression Potential]
  
  * The plugin is renamed from 'conntrackd' to 'conntrack'.
  If one has a plugin_options in /etc/sos/sos.conf specific to former name 
'conntrackd' (e.g skip the plugin, enable the plugin, ...) well it won't be 
effective anymore, and one would need to update their config file to reflect 
new reality of the plugin name change. But it's very uncommon to see users 
using such plugin options. Very unlikely to happen.
  
  * conntrack -L -o extended
  Show the connection tracking table in /proc/net/nf_conntrack format
  
  * conntrack -S
     -S, --stats
    Show the in-kernel connection tracking system statistics.
  
  The new commands addition are harmless, and if a problem arise it will
  be isolated to the 'conntrack' plugin and won't affect other plugins nor
  sosreport core functionalities.
  
  [Other Info]
  
  Closes: https://github.com/sosreport/sos/issues/2049
  Origin: 
https://github.com/sosreport/sos/commit/e6af5287b6bde901690c58090f958960a536660a
  Resolves: https://github.com/sosreport/sos/pull/2251

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1820929] Re: netplan should consider adding more udev attribute for exact matching of failover 3-netdev interfaces

2020-12-31 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1820929

Title:
  netplan should consider adding more udev attribute for exact matching
  of failover 3-netdev interfaces

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1879980] Re: Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

2020-12-31 Thread Mauricio Faria de Oliveira
** Tags removed: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1879980

Title:
  Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-31 Thread Mauricio Faria de Oliveira
Sponsored to F/G/B.

** Tags added: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-31 Thread Mauricio Faria de Oliveira
Sponsored to G/F/B.

** Tags removed: sts-sponsor-volunteer
** Tags added: sts-sponsor-mfo

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
Verification for test packages on Bionic.
===


$ sudo ip netns add ns1
$ sudo ip netns add ns2
$ sudo ip netns add ns3

$ ip netns
ns3
ns2
ns1

$ sudo apt install conntrack conntrackd

$ lsb_release -cs
bionic


Before: (no conntrack files; only conntrackd)
---

$ dpkg -s sosreport | grep -i version:
Version: 3.9.1-1ubuntu0.18.04.2

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_rsqueue
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_runtime
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_cache
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_link
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_network
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_expect
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_ct
sosreport-bionic-2020-12-29-csevyci/sos_commands/conntrackd/conntrackd_-s_queue

$ sudo rm /tmp/sosreport-*.xz

After: (new conntrack files!)
---

$ dpkg -s sosreport | grep -i version:
Version: 3.9.1-1ubuntu0.18.04.3

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack | sort
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrack_-L_-o_extended
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrack_-S
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_cache
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_ct
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_expect
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_link
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_network
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_queue
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_rsqueue
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/conntrackd_-s_runtime
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-L_-o_extended
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-S
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-L_-o_extended
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-S
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-L_-o_extended
sosreport-bionic-2020-12-29-maeovkn/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-S

$ sudo rm /tmp/sosreport-*.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
Verification for test packages on Focal.
===

$ sudo ip netns add ns1
$ sudo ip netns add ns2
$ sudo ip netns add ns3

$ ip netns
ns3
ns2
ns1

$ sudo apt install conntrack conntrackd

$ lsb_release -cs
focal

Before:  (no conntrack files; only conntrackd)
---

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1~ubuntu0.20.04.2

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_cache
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_ct
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_expect
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_link
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_network
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_queue
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_rsqueue
sosreport-focal-2020-12-29-ngoohaj/sos_commands/conntrackd/conntrackd_-s_runtime

$ sudo rm /tmp/sosreport-*.xz

After: (new conntrack files!)
---

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1~ubuntu0.20.04.3

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrack_-L_-o_extended
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrack_-S
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_cache
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_ct
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_expect
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_link
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_network
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_queue
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_rsqueue
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/conntrackd_-s_runtime
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-L_-o_extended
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-S
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-L_-o_extended
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-S
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-L_-o_extended
sosreport-focal-2020-12-29-vybyhjy/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-S

$ sudo rm /tmp/sosreport-*.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
Verification for test packages on Groovy.
===

$ sudo ip netns add ns1
$ sudo ip netns add ns2
$ sudo ip netns add ns3

$ ip netns
ns3
ns2
ns1

$ sudo apt install conntrack conntrackd

$ lsb_release -cs
groovy

Before: (no conntrack files; only conntrackd)
--

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1ubuntu2
 
$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_cache
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_ct
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_expect
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_link
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_network
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_queue
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_rsqueue
sosreport-groovy-2020-12-29-tpjjhqx/sos_commands/conntrackd/conntrackd_-s_runtime

$ sudo rm /tmp/sosreport-*.xz

After: (new conntrack files!)
-

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1ubuntu2.1

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/conntrack
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrack_-L_-o_extended
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrack_-S
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_cache
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_ct
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_expect
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_link
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_network
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_queue
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_rsqueue
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/conntrackd_-s_runtime
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-L_-o_extended
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/ip_netns_exec_ns1_conntrack_-S
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-L_-o_extended
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/ip_netns_exec_ns2_conntrack_-S
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-L_-o_extended
sosreport-groovy-2020-12-29-stewcwc/sos_commands/conntrack/ip_netns_exec_ns3_conntrack_-S

$ sudo rm /tmp/sosreport-*.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
Packages built successfully for all architectures on
ppa:mfo/lp1898077-lp1901555.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-29 Thread Mauricio Faria de Oliveira
Verification for test packages on Bionic.
===


$ sudo ip netns add ns1
$ sudo ip netns add ns2
$ sudo ip netns add ns3

$ ip netns
ns3
ns2
ns1

$ lsb_release -cs
bionic

Before: (no files for ip neigh/rule per network namespace)
---

$ dpkg -s sosreport | grep -i version:
Version: 3.9.1-1ubuntu0.18.04.2

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule
sosreport-bionic-2020-12-29-csevyci/sos_commands/networking/ip_-4_rule
sosreport-bionic-2020-12-29-csevyci/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-bionic-2020-12-29-csevyci/sos_commands/networking/ip_-6_rule
sosreport-bionic-2020-12-29-csevyci/sos_commands/networking/ip_neigh_show_nud_noarp

$ sudo rm /tmp/sosreport-*.xz

After: (new files!)
---

$ dpkg -s sosreport | grep -i version:
Version: 3.9.1-1ubuntu0.18.04.3

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule | sort
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_-4_rule
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_-6_rule
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_neigh_show_nud_noarp
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_netns_exec_ns1_ip_-s_-s_neigh_show
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_netns_exec_ns1_ip_rule_list
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_netns_exec_ns2_ip_-s_-s_neigh_show
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_netns_exec_ns2_ip_rule_list
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_netns_exec_ns3_ip_-s_-s_neigh_show
sosreport-bionic-2020-12-29-maeovkn/sos_commands/networking/ip_netns_exec_ns3_ip_rule_list

$ sudo rm /tmp/sosreport-*.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-29 Thread Mauricio Faria de Oliveira
Verification for test packages on Groovy.
===

$ sudo ip netns add ns1
$ sudo ip netns add ns2
$ sudo ip netns add ns3

$ ip netns
ns3
ns2
ns1

$ lsb_release -cs
groovy

Before: (no files for ip neigh/rule per network namespace)
--

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1ubuntu2
 
$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule
sosreport-groovy-2020-12-29-tsvvcpx/sos_commands/networking/ip_-4_rule
sosreport-groovy-2020-12-29-tsvvcpx/sos_commands/networking/ip_-6_rule
sosreport-groovy-2020-12-29-tsvvcpx/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-groovy-2020-12-29-tsvvcpx/sos_commands/networking/ip_neigh_show_nud_noarp

$ sudo rm /tmp/sosreport-*.xz

After: (new files!)
-

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1ubuntu2.1

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_-4_rule
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_-6_rule
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_neigh_show_nud_noarp
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_netns_exec_ns1_ip_-s_-s_neigh_show
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_netns_exec_ns1_ip_rule_list
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_netns_exec_ns2_ip_-s_-s_neigh_show
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_netns_exec_ns2_ip_rule_list
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_netns_exec_ns3_ip_-s_-s_neigh_show
sosreport-groovy-2020-12-29-stewcwc/sos_commands/networking/ip_netns_exec_ns3_ip_rule_list

$ sudo rm /tmp/sosreport-*.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-29 Thread Mauricio Faria de Oliveira
Verification for test packages on Focal.
===

$ sudo ip netns add ns1
$ sudo ip netns add ns2
$ sudo ip netns add ns3

$ ip netns
ns3
ns2
ns1

$ lsb_release -cs
focal

Before: (no files for ip neigh/rule per network namespace)
---

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1~ubuntu0.20.04.2

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule
sosreport-focal-2020-12-29-ngoohaj/sos_commands/networking/ip_-4_rule
sosreport-focal-2020-12-29-ngoohaj/sos_commands/networking/ip_-6_rule
sosreport-focal-2020-12-29-ngoohaj/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-focal-2020-12-29-ngoohaj/sos_commands/networking/ip_neigh_show_nud_noarp

$ sudo rm /tmp/sosreport-*.xz

After: (new files!)
---

$ dpkg -s sosreport | grep -i version:
Version: 4.0-1~ubuntu0.20.04.3

$ sudo sosreport --batch

$ sudo tar tf /tmp/sosreport-*.xz | grep sos_commands/networking | grep -e 
neigh -e rule
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_-4_rule
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_-6_rule
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_-s_-s_neigh_show
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_neigh_show_nud_noarp
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_netns_exec_ns1_ip_-s_-s_neigh_show
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_netns_exec_ns1_ip_rule_list
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_netns_exec_ns2_ip_-s_-s_neigh_show
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_netns_exec_ns2_ip_rule_list
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_netns_exec_ns3_ip_-s_-s_neigh_show
sosreport-focal-2020-12-29-vybyhjy/sos_commands/networking/ip_netns_exec_ns3_ip_rule_list

$ sudo rm /tmp/sosreport-*.xz

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-29 Thread Mauricio Faria de Oliveira
This patch is being sponsored/uploaded for stable releases via bug
1898077.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
** Changed in: sosreport (Ubuntu Groovy)
 Assignee: Hemanth Nakkina (hemanth-n) => Mauricio Faria de Oliveira (mfo)

** Changed in: sosreport (Ubuntu Focal)
 Assignee: Hemanth Nakkina (hemanth-n) => Mauricio Faria de Oliveira (mfo)

** Changed in: sosreport (Ubuntu Bionic)
 Assignee: Hemanth Nakkina (hemanth-n) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1901555] Re: [plugin][networking] Include ns ip neigh and ip rule info

2020-12-29 Thread Mauricio Faria de Oliveira
** Changed in: sosreport (Ubuntu Groovy)
   Importance: Undecided => Medium

** Changed in: sosreport (Ubuntu Groovy)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: sosreport (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: sosreport (Ubuntu Focal)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

** Changed in: sosreport (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: sosreport (Ubuntu Bionic)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1901555

Title:
  [plugin][networking] Include ns ip neigh and ip rule info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
** Patch added: "lp1898077_lp1901555_sosreport_bionic.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1898077/+attachment/5447752/+files/lp1898077_lp1901555_sosreport_bionic.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
** Patch added: "lp1898077_lp1901555_sosreport_focal.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1898077/+attachment/5447751/+files/lp1898077_lp1901555_sosreport_focal.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
** Patch added: "lp1898077_lp1901555_sosreport_groovy.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1898077/+attachment/5447750/+files/lp1898077_lp1901555_sosreport_groovy.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898077] Re: [conntrackd][plugin] add conntrack info

2020-12-29 Thread Mauricio Faria de Oliveira
Attaching updated debdiffs that include bug 1901555.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898077

Title:
  [conntrackd][plugin] add conntrack info

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1895458] Re: Computer freezes on kernel 5, works on kernel 4

2020-12-22 Thread Mauricio Faria de Oliveira
Hi Petar,

Thanks for letting us know, and sorry it wasn't possible to get back to
this bug.

I'll mark it as Invalid as the root cause isn't know; but glad it's
working now.

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

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1895458

Title:
  Computer freezes on kernel 5, works on kernel 4

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-11 Thread Mauricio Faria de Oliveira
Next Steps:

1) Upload partman-crypto to focal.
2) Wait for it to be available in focal-proposed.
3) Upload ubiquity to focal (gets focal-proposed.)

We could upload both and coordinate the time that
they are accepted and published (ubiquity must be
after partman-crypto), but plans might go wrong :)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-11 Thread Mauricio Faria de Oliveira
All looks good with the PPA build.

After patch/build partman-crypto, and updating its sources
in ubiquity (adding an apt source to the PPA, of course),
the ubiquitu .deb package includes the partman-crypto changes
in '/lib/partman/lib/crypto-base.sh' as expected.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-10 Thread Mauricio Faria de Oliveira
Actually, step 2) is not a no-change-rebuild, but running 'debian/rules
update', which adds to the changelog properly.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-10 Thread Mauricio Faria de Oliveira
Actually in Focal partman-crypto is present in ubiquity
(in d-i/source/partman-crypto) so we'll change it again.

However, ubiquity in Focal doesn't yet use git subtrees;
it just `apt-get source` the d-i components, so we need:

1) patch partman-crypto/focal.
2) no-change-rebuild ubiquity/focal, so to pick it up.

I'll try that in a PPA.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-10 Thread Mauricio Faria de Oliveira
** Changed in: ubiquity (Ubuntu Focal)
   Status: Invalid => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1906496] Re: mgr can be very slow in a large ceph cluster

2020-12-09 Thread Mauricio Faria de Oliveira
Hi Pon,

Thanks for clarifying offline that the Openstack/Ceph team is okay with
more than one commit per patch file.

So, on the debdiff 'noise', I've previously seen and usually removed
that stuff; this seems to be due to the packaging not cleaning up files
generated at build time, I guess.

You can use the handy `filterdiff` tool to keep only the files required,
and get a cleaner debdiff:

$ cat debdiff-ceph-13.2.9 | filterdiff -i 'ceph-13.2.9/debian/changelog'
-i 'ceph-13.2.9/debian/patches/*'

This gives us just the required changed files for the usual pattern of
adding a .patch file. :)

Hope this helps,
Mauricio

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906496

Title:
  mgr can be very slow in a large ceph cluster

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-08 Thread Mauricio Faria de Oliveira
In order to fix this in Focal for the 20.04.3 point release:

Groovy is a no-op, since it has no partman-crypto, and its
ubiquity doesn't need the patch as there won't be new ISOs.
[thus: partman-crypto / Invalid; ubiquity / Won't Fix.]

Focal needs the patch on partman-crypto only (as it is not
yet shipped via ubiquity), then ubiquity installs it later.
[thus: partman-crypto / In Progress; ubiquity / Invalid.]

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1898129] Re: Cannot configure 'cryptsetup luksFormat' at install time

2020-12-08 Thread Mauricio Faria de Oliveira
This has been fixed on Hirsute; changing to Fix Released.

"""
ubiquity (21.04.3) hirsute; urgency=medium

  [ Mauricio Faria de Oliveira ]
  * Introduce preseed option partman-crypto/luksformat_options

  [ Łukasz 'sil2100' Zemczak ]
  * Automatic update of included source packages: partman-crypto
101ubuntu5.

 -- Łukasz 'sil2100' Zemczak   Thu, 03 Dec 2020 
15:21:45 +0100
"""

** Changed in: ubiquity (Ubuntu)
   Status: Fix Committed => Fix Released

** Also affects: partman-crypto (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: ubiquity (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: partman-crypto (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: ubiquity (Ubuntu Hirsute)
   Importance: Medium
 Assignee: Mauricio Faria de Oliveira (mfo)
   Status: Fix Released

** Also affects: partman-crypto (Ubuntu Hirsute)
   Importance: Undecided
   Status: New

** Also affects: ubiquity (Ubuntu Groovy)
   Importance: Undecided
   Status: New

** Also affects: partman-crypto (Ubuntu Groovy)
   Importance: Undecided
   Status: New

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

** Changed in: ubiquity (Ubuntu Focal)
   Status: New => In Progress

** Changed in: ubiquity (Ubuntu Focal)
   Status: In Progress => Invalid

** Changed in: partman-crypto (Ubuntu Hirsute)
   Status: New => Invalid

** Changed in: partman-crypto (Ubuntu Groovy)
   Status: New => Invalid

** Changed in: partman-crypto (Ubuntu Focal)
   Status: New => In Progress

** Changed in: partman-crypto (Ubuntu Focal)
 Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1898129

Title:
  Cannot configure 'cryptsetup luksFormat' at install time

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/partman-crypto/+bug/1898129/+subscriptions

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

[Bug 1906496] Re: mgr can be very slow in a large ceph cluster

2020-12-08 Thread Mauricio Faria de Oliveira
Hi Pon,

Thanks for the backport!

Not sure this is a requirement from the Openstack/Ceph team,
but I imagine that individual commits (3) should go each in
their own .patch files, as usually done with non-cloud SRUs.

I guess this only takes some light changes to your backport.
Happy to help if needed!

cheers,
Mauricio

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1906496

Title:
  mgr can be very slow in a large ceph cluster

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

-- 
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

  1   2   3   4   5   6   7   8   9   10   >