[Touch-packages] [Bug 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

[Guilherme G. Piccoli]

Observed in B/aws (kernel 4.15), cycle sru-20210621.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1783881

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  In Progress
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  Invalid

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

[Guilherme G. Piccoli]

Observed in B/aws (kernel 4.15), cycle sru-20210621.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1783881

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  In Progress
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  Invalid

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

[Guilherme G. Piccoli]

Observed this on B/oracle-5.4, cycle sru-20210621 .

** Tags added: oracle

** Also affects: ubuntu-kernel-tests
   Importance: Undecided
   Status: New

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1886790

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Confirmed

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1886790/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

[Guilherme G. Piccoli]

** Also affects: lxc
   Importance: Undecided
   Status: New

** No longer affects: lxc

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1886790

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Confirmed

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

[Guilherme G. Piccoli]

Observed on B/aws-5.4 , cycle 20210621.

** Tags added: 5.4 aws bionic sru-20210621

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1886790

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Confirmed

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

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


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

[Guilherme G. Piccoli]

Observed in B/aws-5.4, cycle sru-20210621.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1783881

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  In Progress
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Invalid
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  Won't Fix
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  Invalid

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+subscriptions


-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1886790] Re: lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels (device_add_remove_test)

[Guilherme G. Piccoli]

** Summary changed:

- lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic
+ lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels 
(device_add_remove_test)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1886790

Title:
  lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with B/5.4 kernels
  (device_add_remove_test)

Status in lxc package in Ubuntu:
  Fix Released
Status in lxc source package in Bionic:
  Confirmed

Bug description:
  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/amd64/l/lxc/20200706_183234_ca65f@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/arm64/l/lxc/20200706_172136_71b68@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/ppc64el/l/lxc/20200706_191938_cedac@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/s390x/l/lxc/20200706_163359_98d4d@/log.gz

  The failing test seems to be:

  FAIL: lxc-tests: lxc-test-device-add-remove (0s)
  ---
  Adding /dev/network_latency to the container (device_add_remove_test) 
failed...
  ---

  This is a regression from the 4.15/5.3 to 5.4 kernels in Bionic. Note
  that this testcase is successful on Focal with the same kernel
  version.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1884024] Re: lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4

[Guilherme G. Piccoli]

*** This bug is a duplicate of bug 1886790 ***
https://bugs.launchpad.net/bugs/1886790

** This bug has been marked a duplicate of bug 1886790
   lxc 3.0.3-0ubuntu1~18.04.1 ADT test failure with 5.4 kernels in Bionic

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1884024

Title:
  lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Committed

Bug description:
  Issue found on with 5.4.0-1016.16~18.04.1-oracle on both
  VM.Standard2.1 and VM.Standard2.16

  Test failed with:
   FAIL: lxc-tests: lxc-test-device-add-remove (1s)
   ---
   Adding /dev/network_latency to the container (device_add_remove_test) 
failed...

  This issue can be found on oracle : 5.4.0-1011.11~18.04.1 on
  VM.Standard2.16 but passed on VM.Standard2.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1884024/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1783881] Re: ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits number of processes

[Guilherme G. Piccoli]

Found on B-5.4/aws, cycle sru-20210531 .

** Tags added: sru-20210531

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1783881

Title:
  ltp-syscalls: msgstress03 / msgstress04 fails because systemd limits
  number of processes

Status in ubuntu-kernel-tests:
  Triaged
Status in linux package in Ubuntu:
  Incomplete
Status in linux-azure package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  Incomplete
Status in linux source package in Xenial:
  New
Status in linux-azure source package in Xenial:
  New
Status in systemd source package in Xenial:
  New
Status in linux source package in Bionic:
  New
Status in linux-azure source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  As systemd limits the number of processes, this test will fail because
  it can't fork enough processes. That is limited to when the test is
  run after logging as user 1000, then running sudo. I guess that
  logging as root may not cause this to happen.

  # ./testcases/bin/msgstress03 
  Fork failed (may be OK if under stress)
  Fork failed (may be OK if under stress)
  msgstress031  TFAIL  :  msgstress03.c:157:  Fork failed (may be OK if 
under stress)
  #

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1783881/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1884024] Re: lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4

[Guilherme G. Piccoli]

Observed with B-5.4/aws, cycle sru-20210531 .

** Tags added: sru-20210531

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1884024

Title:
  lxc-test-device-add-remove from ubuntu_lxc failed on B-5.4

Status in ubuntu-kernel-tests:
  New
Status in lxc package in Ubuntu:
  Fix Committed

Bug description:
  Issue found on with 5.4.0-1016.16~18.04.1-oracle on both
  VM.Standard2.1 and VM.Standard2.16

  Test failed with:
   FAIL: lxc-tests: lxc-test-device-add-remove (1s)
   ---
   Adding /dev/network_latency to the container (device_add_remove_test) 
failed...

  This issue can be found on oracle : 5.4.0-1011.11~18.04.1 on
  VM.Standard2.16 but passed on VM.Standard2.1

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/1884024/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

[Guilherme G. Piccoli]

Issue observed for a long time in 5.8 kernels, for example G/KVM.

** Tags added: 5.8 groovy kvm sru-20210531

** Tags added: sru-20210510

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1917601

Title:
  lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed

Bug description:
  We seem to get failed dep8 testing on lxc in Groovy for a while. What
  we are interested in is knowing whether this is known problems in the
  testing or something that waits on kernel fixes (who would be driving
  those if this is the case).

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1917601] Re: lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

[Guilherme G. Piccoli]

Marked https://bugs.launchpad.net/bugs/1900662 as duplicate of this one.
Same issue, and seems (per Christian) that is fixed on 4.0.6 .

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1917601

Title:
  lxc 1:4.0.4-0ubuntu3 ADT test failure with linux 5.8.0-45.51

Status in lxc package in Ubuntu:
  Confirmed
Status in lxc source package in Groovy:
  Confirmed

Bug description:
  We seem to get failed dep8 testing on lxc in Groovy for a while. What
  we are interested in is knowing whether this is known problems in the
  testing or something that waits on kernel fixes (who would be driving
  those if this is the case).

  Testing failed on:
  amd64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/amd64/l/lxc/20210224_161232_5c8ac@/log.gz
  arm64: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/arm64/l/lxc/20210224_202135_e7aed@/log.gz
  ppc64el: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/ppc64el/l/lxc/20210224_172418_73aab@/log.gz
  s390x: 
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-groovy/groovy/s390x/l/lxc/20210224_164056_06e00@/log.gz

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1900008] Re: Sessions of screen does not keep running in background

[Guilherme G. Piccoli]

That's interesting, I just performed your suggested test, and I couldn't
reproduce - it's a fresh Ubuntu 20.04 install, running MATE (not KDE!)
and GNU screen 4.8.0-1. After closing the terminal, I've opened another
one and "screen -x" worked fine, as expected.

Could you try to use MATE / Gnome to perform your test? So we can
isolate it to KDE (or not). Also, which version of screen is installed
in your system? Thanks!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/198

Title:
  Sessions of screen does not keep running in background

Status in screen package in Ubuntu:
  New
Status in systemd package in Ubuntu:
  New

Bug description:
  In a new fresh installed 20.04, when I use screen command and close
  the terminal (not closing screen sesion), then I can't recover it with
  screen -x, since does not exist. I can only recover screen sesion if
  the original terminal running screen is not being closed.

  For some reason, this is closing screen session of that user:

  Oct 15 13:32:45 pc-caja2 systemd[1]: session-66.scope: Succeeded.
  Oct 15 13:32:45 pc-caja2 systemd[1]: Stopped Session 66 of user usuario.

  This does not happen in an upgraded system from 18.04 to 20.04.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1573095] Re: Cloud images fail to boot when a serial port is not available

[Guilherme G. Piccoli]

Oh, so it's explained! Thanks Javier for the data. You're using an
outdated version of the package that doesn't contain this fix. You need
initramfs-tools version 0.122ubuntu8.17 - you can either try to get an
updated cloud image, or after the first boot you may be able to update
it (you could disable the console=ttySX entry in the cmdline as a
workaround in the 1st boot).

If possible, please try the new version and let us all know how it goes.
Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1573095

Title:
  Cloud images fail to boot when a serial port is not available

Status in cloud-images:
  Invalid
Status in cloud-init:
  Invalid
Status in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  I tried to launch a ubuntu 16.04 cloud image within KVM.
  The image is not booting up and hangs at

  "Btrfs loaded"

  Hypervisor env is Proxmox 4.1

  [racb: see comment 40 for minimal steps to reproduce using Ubuntu-
  provided tooling only]

  
  Related bugs:
   * bug 1016695: add console=tty1 to cloud-image kernel boot parameters
   * bug 1123220: cloud-image VM causes kernel panic if image is resized
   * bug 1061977: Machine fails to commission when console=ttyS0 is present on 
kernel opts
   * bug 1573095: Cloud images fail to boot when a serial port is not available 
   * bug 1122245: booting from a cloud image hangs until virsh console is used

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1573095] Re: Cloud images fail to boot when a serial port is not available

[Guilherme G. Piccoli]

Thanks for the report Javier! What version of initramfs-tools are you
using ?

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1573095

Title:
  Cloud images fail to boot when a serial port is not available

Status in cloud-images:
  Invalid
Status in cloud-init:
  Invalid
Status in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  I tried to launch a ubuntu 16.04 cloud image within KVM.
  The image is not booting up and hangs at

  "Btrfs loaded"

  Hypervisor env is Proxmox 4.1

  [racb: see comment 40 for minimal steps to reproduce using Ubuntu-
  provided tooling only]

  
  Related bugs:
   * bug 1016695: add console=tty1 to cloud-image kernel boot parameters
   * bug 1123220: cloud-image VM causes kernel panic if image is resized
   * bug 1061977: Machine fails to commission when console=ttyS0 is present on 
kernel opts
   * bug 1573095: Cloud images fail to boot when a serial port is not available 
   * bug 1122245: booting from a cloud image hangs until virsh console is used

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

John, thanks a lot for your report! Definitely we don't want to delay boots - 
although I'm happy to hear that eventually it boots. Can you send me logs so I 
can understand what's going on?
My suggestion is to follow the steps below (as root user):

(0) [optional] Force a log rotation, in order we only capture the 
relevant/latest data:
logrotate -f /etc/logrotate.conf ;

(1) Add "debug ignore_loglevel" to your kernel command-line (usually
done by editing /etc/default/grub or /etc/default/grub.d/[somefile]);
update grub after editing the conf file (through "update-grub" tool);

(2) Now that'll seem a bit counter-intuitive: reboot the machine, and
all initramfs-tools verbose output will go to a file, *including* the
password requests for LUKS (I'm not sure why this happens, I feel it's
bug but we can live with that for now, to collect your data). So your
system might seem hung - write the password and press ENTER how many
times it's usually asked (when system appears hung) - hopefully you
manage to boot your system, even if takes a while.

(3) Collect 2 files and attach them here please: "/var/log/syslog" and
"/run/initramfs/initramfs.debug".

Hopefully with that I can understand exactly what's causing this weird behavior 
in your setup.
Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  Fix Released
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  Fix Released
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  Fix Released
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes 

[Touch-packages] [Bug 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

[Guilherme G. Piccoli]

I was able to verify this bug with systemd from bionic-proposed (version
237-3ubuntu10.43) by following the procedure in the test case; it's
working as expected, I can see 64M in the memlock limit.

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1830746

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  Fix Committed
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 120375] Re: cannot boot raid1 with only one disk

[Guilherme G. Piccoli]

This is a very old LP bug, but for completeness it worth mentioning here
that recently some patches were merged on initramfs-tools and
cryptsetup, that allow a good experience booting with LUKS-encrypted
rootfs on top of a degraded RAID1 array; for details, please check:
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1879980

Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/120375

Title:
  cannot boot raid1 with only one disk

Status in initramfs-tools:
  Fix Released
Status in grub package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Fix Released
Status in grub source package in Hardy:
  Fix Released
Status in initramfs-tools source package in Hardy:
  Fix Released
Status in mdadm source package in Hardy:
  Fix Released

Bug description:
  The impact of the bug on users: Systems with root on a RAID array will
  not be able to boot if the array is degraded. Usrs affected by this
  will encounter an unusable system after a reboot (say, a kernel
  upgrade).

  Justification for backporting the fix to the stable release: Hardy is
  a LTS edition. It is expected that people will continue to use this
  version and not upgrade to Intrepid. People who have upgrade from
  Dapper LTS to Hardy LTS are affected too.

  TEST CASE
  Build a clean system with root on RAID, with Ubuntu 8.04 LTS. Degrade the 
root array. Reboot and shiver.

  A discussion of the regression potential of the patch and how users could get 
inadvertently effected. 
  - the only users that could be affected, as fas as  know, are the ones that 
already made a workaround and altered their system files accordingly.

  
  Binary package hint: mdadm

  if i unplug one hd from raid1 i cannot successfully boot because raid
  starts only if all disks are available through

  : "${MD_DEGRADED_ARGS:= --no-degraded}" in /usr/share/initramfs-
  tools/scripts/local-top/mdadm

  my workaround is:

  /etc/initramfs-tools/hooks/startdegradedraid

  #!/bin/sh
  #
  # Copyright  2006 Martin F. Krafft 
  # based on the scripts in the initramfs-tools package.
  # released under the terms of the Artistic Licence.
  #
  # $Id: hook 281 2006-12-08 08:14:44Z madduck $
  #

  set -eu

  PREREQ="udev"

  prereqs()
  {
  echo "$PREREQ"
  }

  case ${1:-} in
prereqs)
  prereqs
  exit 0
  ;;
  esac

  MDADM=$(command -v mdadm 2>/dev/null) || :
  [ -x $MDADM ] || exit 0

  DESTCONFIG=$DESTDIR/conf/md.conf

  echo "MD_DEGRADED_ARGS=' '" >> $DESTCONFIG

  exit 0

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/120375/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Thanks for releasing the packages in -proposed Lukasz. I was able to
complete the validation for the Focal version, following the procedure
in the description. An user reported internally to me that the
verification of Bionic version was also successful, hence I'm hereby
marking this LP as verified for both releases.

Bionic version tested: 2:2.0.2-1ubuntu1.2
Focal version tested: 2:2.2.2-3ubuntu2.3

Cheers,


Guilherme

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  Fix Committed
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  Fix Committed
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  Fix Released
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, 

[Touch-packages] [Bug 1573095] Re: Cloud images fail to boot when a serial port is not available

[Guilherme G. Piccoli]

The specific issue (the bad return from printf) was worked in LP #1879987 - it 
was fixed recently on initramfs-tools versions:
0.122ubuntu8.17 (Ubuntu 16.04 - Xenial)
0.130ubuntu3.11 (Ubuntu 18.04 - Bionic)
0.136ubuntu6.3 (Ubuntu 20.04 - Focal)
0.137ubuntu12 (Ubuntu 20.10 - Groovy)

I'll nominate this LP for initramfs-tools and set as Fix Released. If that's 
still reproducible in any way, likely there's another correlated issue, please 
open another LP and mention it here.
Cheers,


Guilherme

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

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => Medium

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

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1573095

Title:
  Cloud images fail to boot when a serial port is not available

Status in cloud-images:
  Invalid
Status in cloud-init:
  Invalid
Status in Ubuntu:
  Invalid
Status in initramfs-tools package in Ubuntu:
  Fix Released

Bug description:
  I tried to launch a ubuntu 16.04 cloud image within KVM.
  The image is not booting up and hangs at

  "Btrfs loaded"

  Hypervisor env is Proxmox 4.1

  [racb: see comment 40 for minimal steps to reproduce using Ubuntu-
  provided tooling only]

  
  Related bugs:
   * bug 1016695: add console=tty1 to cloud-image kernel boot parameters
   * bug 1123220: cloud-image VM causes kernel panic if image is resized
   * bug 1061977: Machine fails to commission when console=ttyS0 is present on 
kernel opts
   * bug 1573095: Cloud images fail to boot when a serial port is not available 
   * bug 1122245: booting from a cloud image hangs until virsh console is used

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Thanks a lot Alex for your review from a security point-of-view. And thanks 
again Lukasz for dealing with this SRU!
Cheers,

Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  Fix Released
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  Fix Released
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Thanks a bunch mfo!!

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Hi Eric, all the changes are part of the same functionality - the local-bottom 
script for example is a clean-up for the files created in the local-top phase. 
I think it'd be unnecessary verbosity to explain file by file, and this bug is 
waiting for a long time to be fixed (especially due to the FTBFS we needed to 
investigate and fix), so unless you think it's strictly necessary, I'd rather 
move this one forward without changing the description.
Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:

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

[Guilherme G. Piccoli]

** Patch added: "bionic_cryptsetup_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5411486/+files/bionic_cryptsetup_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "focal_cryptsetup_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5411485/+files/focal_cryptsetup_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

After the cryptsetup FTBFS investigation (on LP #1891473), coincidentally a 
security fix was released for such package, that included a fix for the FTBFS. 
So, this is a "rebase" on top of the latest version for Focal/Groovy - Bionic 
wasn't affected, but I'm re-uploading its debdiff nevertheless.
Thanks,


Guilherme

** Patch added: "groovy_cryptsetup_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5411484/+files/groovy_cryptsetup_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Released
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go to:

[Touch-packages] [Bug 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

[Guilherme G. Piccoli]

** Patch added: "This is the (tested) debdiff with the proposed SRU, for Bionic 
only."
   
https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1830746/+attachment/5409870/+files/bionic_systemd_lp1830746.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1830746

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  releases, like Focal and subsequent ones, already include this patch
  so effectively we're putting Bionic on-par with newer releases.

  * A discussion about this topic (leading to this SRU) is present in
  ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
  devel/2020-September/041159.html.

  [Test Case]
  * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).

  * A more interesting test is to run a Focal container in a current
  Bionic system and try to build the cryptsetup package - it'll fail in
  some tests. After updating the host (Bionic) systemd to include the
  mlock bump patch, the build succeeds in the Focal container.

  [Regression Potential]
  * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.

  
  [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

[Guilherme G. Piccoli]

** Description changed:

- See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock-
- cannot-exceed-16777216/4856/5
+ [Impact]
+ * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
+ * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.
  
- In containers, the limits.kernel.memlock cannot exceed 16777216 when the
- container is bionic. The memlock setting is set to 16M in systemd and
- cannot be bumped up in an unprivileged container.
+ * It's especially harmful in containers to have such "small" limit, so
+ we are hereby SRUing a more recent bump from upstream systemd, in the
+ form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
+ [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
+ releases, like Focal and subsequent ones, already include this patch so
+ effectively we're putting Bionic on-par with newer releases.
  
- This is fixed in upstream systemd.
+ * A discussion about this topic (leading to this SRU) is present in
+ ubuntu-devel ML: https://lists.ubuntu.com/archives/ubuntu-
+ devel/2020-September/041159.html.
  
- Container ubuntu version:
- Distributor ID:   Ubuntu
- Description:  Ubuntu 18.04.2 LTS
- Release:  18.04
- Codename: bionic
+ [Test Case]
+ * The straightforward test is to just look "ulimit -l" and "ulimit -Hl" in a 
current Bionic system, and then install an updated version with the hereby 
proposed SRU to see such limit bump from 16M to 64M (after a reboot) - a 
version containing this fix is available at my PPA as of 2020-09-10 [0] (likely 
to be deleted in next month or so).
  
- systemd package version: 237-3ubuntu10.21
+ * A more interesting test is to run a Focal container in a current
+ Bionic system and try to build the cryptsetup package - it'll fail in
+ some tests. After updating the host (Bionic) systemd to include the
+ mlock bump patch, the build succeeds in the Focal container.
+ 
+ [Regression Potential]
+ * Since it's a simple bump and it makes Bionic behave like Focal, I don't 
foresee regressions. One potential issue would be if some users rely on the 
lower default limit (16M) and this value is bumped by a package update, but 
that could be circumvented by setting a lower limit in limits.conf. The 
benefits for such bump are likely much bigger than any "regression" caused for 
users relying on such default limit.
+ 
+ 
+ [0] https://launchpad.net/~gpiccoli/+archive/ubuntu/test1830746

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

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

** Changed in: systemd (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Tags removed: patch rls-dd-incoming
** Tags added: seg

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1830746

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released
Status in systemd source package in Focal:
  Fix Released

Bug description:
  [Impact]
  * Since systemd commit fb3ae275cb ("main: bump RLIMIT_NOFILE for the root 
user substantially") [https://github.com/systemd/systemd/commit/fb3ae275cb], 
which is present in Bionic, the memlock ulimit value was bumped to 16M. It's an 
adjustable limit, but the default (in previous Ubuntu releases/systemd 
versions) was really small.
  * Although bumping this value was a good thing, 16M is not enough and we can 
see failures on mlock'ed allocations on Bionic, like the one hereby reported by 
Kees or the recent introduced cryptsetup build failures (due to PPA builder 
updates to Bionic) - see https://bugs.launchpad.net/bugs//1891473.

  * It's especially harmful in containers to have such "small" limit, so
  we are hereby SRUing a more recent bump from upstream systemd, in the
  form of commit 91cfdd8d29 ("core: bump mlock ulimit to 64Mb")
  [https://github.com/systemd/systemd/commit/91cfdd8d29]. Latest Ubuntu
  

[Touch-packages] [Bug 1830746] Re: memlock setting in systemd (pid 1) too low for containers (bionic)

[Guilherme G. Piccoli]

Hi Sebastian, thanks for offering help. And thanks of course Kees for reporting 
the issue!
Recently we faced a build breakage of cryptsetup package narrowed to this 
issue: https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1891473

I intend to bump this limit to 64M to match recent releases; I'm using
the upstream systemd commit for this:
https://github.com/systemd/systemd/commit/91cfdd8d29

Cheers,


Guilherme

** Changed in: systemd (Ubuntu Cosmic)
   Status: Confirmed => Won't Fix

** Changed in: systemd (Ubuntu)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Cosmic)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: systemd (Ubuntu Disco)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Eoan)
   Importance: Undecided => High

** Changed in: systemd (Ubuntu Bionic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: systemd (Ubuntu Cosmic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: systemd (Ubuntu Disco)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: systemd (Ubuntu Eoan)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: systemd (Ubuntu Bionic)
   Status: Confirmed => In Progress

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1830746

Title:
  memlock setting in systemd (pid 1) too low for containers (bionic)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Bionic:
  In Progress
Status in systemd source package in Cosmic:
  Won't Fix
Status in systemd source package in Disco:
  Won't Fix
Status in systemd source package in Eoan:
  Fix Released

Bug description:
  See also https://discuss.linuxcontainers.org/t/limits-kernel-memlock-
  cannot-exceed-16777216/4856/5

  In containers, the limits.kernel.memlock cannot exceed 16777216 when
  the container is bionic. The memlock setting is set to 16M in systemd
  and cannot be bumped up in an unprivileged container.

  This is fixed in upstream systemd.

  Container ubuntu version:
  Distributor ID:   Ubuntu
  Description:  Ubuntu 18.04.2 LTS
  Release:  18.04
  Codename: bionic

  systemd package version: 237-3ubuntu10.21

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

I've managed to verify the initramfs-tools Focal-proposed package
(version 0.136ubuntu6.3) by following 2 approaches, given that we don't
have its cryptsetup counter-part released yet:

(a) The verification by "negation" aims to check if we don't have
regression, by testing if the new package changed the old behavior. And
it passed: with the proposed initramfs-tools, if we have a degraded
RAID1 holding the encrypted rootfs, Ubuntu fails to boot exactly like
using the regular/released initramfs-tools package, so no regressions
/behavior-change introduced.

(b) I've tested with a modified cryptsetup package [0] that included the
fix counter-part, and in this case, we are able to boot as expected,
proving that the initramfs-tools proposed package is working as it
should.

Also, the armhf autopkgtest regression mentioned in the above comment is no 
longer an issue, it's fixed (test was re-executed and succeeded - likely a 
flaky network case).
Hence, marking this bug as verified for Focal.
Cheers,


Guilherme


[0] https://launchpad.net/~gpiccoli/+archive/ubuntu/lp1879980

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  Fix Committed
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  Fix Released
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification 

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

I've tested the Focal-proposed initramfs-tools (version 0.136ubuntu6.3 ) 
according to the "Test Case" section in the description, and it's working as 
expected. Also, the armhf autopkgtest failure is no longer an issue (test was 
re-executed with success), so marking as verified!
Cheers,


Guilherme

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  Fix Committed
Status in initramfs-tools source package in Groovy:
  Fix Released

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

The ARMHF testing was retried (thanks mfo!) and passed, likely flaky
network issues during the test. Also, since Focal was successful to
build and no issues on autopkgtest were reported (i.e., no test fails
detected), I'm hereby marking this as verified.

Cheers,


Guilherme

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Focal:
  Fix Committed
Status in initramfs-tools source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Run the autopkgtest suite in the initramfs-tools package and observe the 
failure aforementioned.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that. [See the
  Rectification below]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

After discussing with Eric, seems initramfs-tools was "released" in
Groovy (even with autopkgtest), so I'm hereby attaching an updated
debdiff only with the autopkgtest fix.

** Patch added: "groovy_initramfs_lp1879980_lp1893675_V3.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+attachment/5406587/+files/groovy_initramfs_lp1879980_lp1893675_V3.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Run the autopkgtest suite in the initramfs-tools package and observe the 
failure aforementioned.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that. [See the
  Rectification below]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** Patch added: "focal_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5406228/+files/focal_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

An issue on initramfs-tools autopkgtest was found in Groovy and Focal (see LP 
#1893675) - it's non-related with the fixes proposed here, but we need to make 
autopkgtest happy or we cannot get the package released, so here goes the V2 of 
the initramfs-tools debdiffs.
Notice the SRU is mainly driven in this LP and/or LP #1879987.

** Patch added: "groovy_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5406229/+files/groovy_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

To manage notifications about this bug go 

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

[Guilherme G. Piccoli]

Worth to notice that the cryptsetup release is blocked on LP #1891473 -
there's a failure on building this package from source introduced by a
recent PPA builder upgrade (from Xenial to Bionic).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "focal_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5406230/+files/focal_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

An issue on initramfs-tools autopkgtest was found in Groovy and Focal (see LP 
#1893675) - it's non-related with the fixes proposed here, but we need to make 
autopkgtest happy or we cannot get the package released, so here goes the V2 of 
the initramfs-tools debdiffs.
Notice the SRU is mainly driven in this LP and/or LP #1879980.

** Patch added: "groovy_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5406227/+files/groovy_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

Although the debdiffs are being hereby attached, the SRU track is
ongoing in LPs #1879987 and #1879980.

** Patch added: "groovy_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+attachment/5406203/+files/groovy_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Run the autopkgtest suite in the initramfs-tools package and observe the 
failure aforementioned.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that. [See the
  Rectification below]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

** Patch added: "focal_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+attachment/5406204/+files/focal_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Run the autopkgtest suite in the initramfs-tools package and observe the 
failure aforementioned.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that. [See the
  Rectification below]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

** Description changed:

  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."
  
  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.
  
  * The fix proposed here is just to manually run "partprobe" before using
  the new to-be-discovered loop partition in the net autopkgtest.
  
  [Test Case]
- * Build initramfs-tools in PPA and observe the failure in AMD64 - the 
signature of the failure is as discussed in the Impact section above.
+ * Run the autopkgtest suite in the initramfs-tools package and observe the 
failure aforementioned.
  
  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.
  
  * Notice that this test is not executed in Debian CI given that CI has
- no support for VMs, and this test requires that.
+ no support for VMs, and this test requires that. [See the Rectification
+ below]

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Run the autopkgtest suite in the initramfs-tools package and observe the 
failure aforementioned.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that. [See the
  Rectification below]

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] Re: Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

Rectification of my statement in the description: the net test is not
present in Debian, only in Ubuntu (Focal and subsequent releases), added
in order to perform network parsing test, especially for netplan.

** Also affects: initramfs-tools (Ubuntu Groovy)
   Importance: Undecided
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: In Progress

** Also affects: initramfs-tools (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu Focal)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Groovy)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Build initramfs-tools in PPA and observe the failure in AMD64 - the 
signature of the failure is as discussed in the Impact section above.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1893675] [NEW] Autopkgtest failure on latest version of initramfs-tools - lack of partprobe

[Guilherme G. Piccoli]

Public bug reported:

[Impact]
* Currently the initramfs-tools autopkgtest fails for at least AMD64, with the 
following signature:
"mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device /dev/loop0p1 
does not exist."

* The reason for that is the test trying immediately to use that
partition on the loop device, but kernel may not have a partition re-
read ioctl issued, so the test may fail as observing a nonexistent
partition.

* The fix proposed here is just to manually run "partprobe" before using
the new to-be-discovered loop partition in the net autopkgtest.

[Test Case]
* Build initramfs-tools in PPA and observe the failure in AMD64 - the signature 
of the failure is as discussed in the Impact section above.

[Regression Potential]
* Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
* The only potential issue I see with that is if for some reason we don't have 
partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

* Notice that this test is not executed in Debian CI given that CI has
no support for VMs, and this test requires that.

** Affects: initramfs-tools (Ubuntu)
 Importance: Undecided
 Assignee: Guilherme G. Piccoli (gpiccoli)
 Status: In Progress


** Tags: seg

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1893675

Title:
  Autopkgtest failure on latest version of initramfs-tools - lack of
  partprobe

Status in initramfs-tools package in Ubuntu:
  In Progress

Bug description:
  [Impact]
  * Currently the initramfs-tools autopkgtest fails for at least AMD64, with 
the following signature:
  "mount: /tmp/autopkgtest.K1r92h/build.zdS/src/mnt: special device 
/dev/loop0p1 does not exist."

  * The reason for that is the test trying immediately to use that
  partition on the loop device, but kernel may not have a partition re-
  read ioctl issued, so the test may fail as observing a nonexistent
  partition.

  * The fix proposed here is just to manually run "partprobe" before
  using the new to-be-discovered loop partition in the net autopkgtest.

  [Test Case]
  * Build initramfs-tools in PPA and observe the failure in AMD64 - the 
signature of the failure is as discussed in the Impact section above.

  [Regression Potential]
  * Extremely low potential, we are just introducing a partition re-read/probe 
operation during autopkgtest phase, in order to keep the partition table of 
loop devices consistent before the test uses it.
  * The only potential issue I see with that is if for some reason we don't 
have partprobe in the autopkgtest environment, but that shouldn't happen since 
parted package is on ubuntu-standard.

  * Notice that this test is not executed in Debian CI given that CI has
  no support for VMs, and this test requires that.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1893675/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

After about 10 weeks, finally my patch was merged by the Debian
maintainer: https://salsa.debian.org/kernel-team/initramfs-
tools/-/commit/c3cbf355

Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Attaching a new Bionic debdiff, which now includes a fix for a third bug
(LP #1820929).

** Patch added: "bionic_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5401090/+files/bionic_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

Attaching a new Bionic debdiff, which now includes a fix for a third bug
(LP #1820929).

** Patch added: "bionic_initramfs_lp1879980_V2.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5401089/+files/bionic_initramfs_lp1879980_V2.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Although the debdiff is hereby attached, 3 bugs have fixes carried on
such patch - the main work is done on LP ##1879980 (and the other LP
handled in this SRU is #1879987) .

** Tags added: sts

** Description changed:

- This bug is a follow-up to
+ [Impact]
  
- https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268
+ * At present, virtual machines utilizing net_failover network interface
+ configurations are incorrectly configured due to the reliance on the MAC
+ address to identify specific network interfaces.  When net_failover is
+ utilized, multiple interfaces will bear the same MAC address (the
+ net_failover master itself, as well as the interfaces subordinate to
+ it), rendering the MAC address ineffective for unique identification of
+ the interface.  This results in incorrect naming of network interfaces
+ from the "set-name" directive in the netplan configuration.
  
- after applying the 0001-net_failover-delay-taking-over-primary-device-
- to-acc.patch attached in that bug, the VF interface "eth0" is renamed to
- "rename4" instead of "ens4". Log is showing that attempt to rename
- "eth0" to "ens3" failed because of conflict with existing name, so
- that's why it ends up with rename4.
+ * The solution here is to use the interface name instead of the MAC
+ address when the interface is a net_failover master device.  Logic is
+ added on initramfs-tools to check the device type and virtio flags to
+ apply this change only to net_failover master devices.
  
- vsbalakr@ubuntu-18:~$ uname -a
- Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
- vsbalakr@ubuntu-18:~$ ip l 
- 1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
- 2: ens3:  mtu 1500 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff 
- 3: ens3nsby:  mtu 1500 qdisc pfifo_fast 
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether 
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff 
- 4: rename4:  mtu 1500 qdisc mq master ens3 
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff
+ [Test Case]
  
- vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
- ...
- Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): carrier: link connected
- Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): enslaved to non-master-type device ens3; ignoring
- Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface 
name 'eth0' to 'ens3': Device or resource busy
- Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4' 
from 'eth0' to 'ens3': Device or resource busy
+ * The change can be tested by configuring a virtual machine with a
+ virtio_net network device with the "failover=on" option to the "-device"
+ option to qemu, e.g.,
  
- Within VM there's netplan config as below:
+ -device virtio-net-
+ 
pci,netdev=hostnet0,id=net0,bus=pci.0,addr=0x3,mac=00:00:17:00:18:04,failover=on
  
- vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
- # This file describes the network interfaces available on your system
- # For more information, see netplan(5).
- network:
-   version: 2
-   renderer: networkd
-   ethernets:
- ens3:
-   dhcp4: yes
-   gateway4: 10.211.8.1
-   nameservers:
-   addresses: [10.211.11.1,10.209.76.197]
+ * This will set the virtio device "standby" feature bit (bit 62,
+ counting from 0).  This requires a version of qemu with support for this
+ feature.
  
- By running udevadm test, we can see the conflicting ens3 name comes from
- netplan's /run/udev/rules.d/99-netplan-ens3.rules
+ * When so configured, the netplan configuration generated by initramfs
+ will not contain a "macaddress:" match directive for the network
+ interface in question.
  
- vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
- SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"
+ [Regression Potential]
  
- vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add" 
/sys/class/net/eth0
- calling: test
- version 237
- This program is for debugging only, it does not run any program
- specified by a RUN key. It may show incorrect results, because
- some values may be different, or not available at a simulation run.
- 
- Load module index
- Parsed configuration file /lib/systemd/network/99-default.link
- Parsed configuration file /run/systemd/network/10-netplan-ens3.link
- Created link configuration context.
- Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
- ..
- Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
- rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
- 25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie 
nodes 

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

[Guilherme G. Piccoli]

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: systemd (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: netplan.io (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Bionic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Bionic)
 Assignee: Guilherme G. Piccoli (gpiccoli) => Jay Vosburgh (jvosburgh)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1820929

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

Status in netplan:
  Triaged
Status in initramfs-tools package in Ubuntu:
  New
Status in netplan.io package in Ubuntu:
  Triaged
Status in systemd package in Ubuntu:
  Incomplete
Status in initramfs-tools source package in Bionic:
  In Progress
Status in netplan.io source package in Bionic:
  New
Status in systemd source package in Bionic:
  New

Bug description:
  This bug is a follow-up to

  https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1815268

  after applying the 0001-net_failover-delay-taking-over-primary-device-
  to-acc.patch attached in that bug, the VF interface "eth0" is renamed
  to "rename4" instead of "ens4". Log is showing that attempt to rename
  "eth0" to "ens3" failed because of conflict with existing name, so
  that's why it ends up with rename4.

  vsbalakr@ubuntu-18:~$ uname -a
  Linux ubuntu-18 4.15.0-1009-oracle #11+lp1815268 SMP Tue Mar 12 15:20:15 UTC 
2019 x86_64 x86_64 x86_64 GNU/Linux
  vsbalakr@ubuntu-18:~$ ip l 
  1: lo:  mtu 65536 qdisc noqueue state UNKNOWN mode 
DEFAULT group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 
00:00:00:00:00:00 
  2: ens3:  mtu 1500 qdisc noqueue state UP 
mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff 
  3: ens3nsby:  mtu 1500 qdisc pfifo_fast 
master ens3 state UP mode DEFAULT group default qlen 1000 link/ether 
ba:fb:9f:12:2f:02 brd ff:ff:ff:ff:ff:ff 
  4: rename4:  mtu 1500 qdisc mq master ens3 
state UP mode DEFAULT group default qlen 1000 link/ether ba:fb:9f:12:2f:02 brd 
ff:ff:ff:ff:ff:ff

  vsbalakr@ubuntu-18:~$ egrep -i '(rename4|busy)' /var/log/syslog
  ...
  Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): carrier: link connected
  Mar 18 11:01:52 ubuntu-18 NetworkManager[1294]:  [1552932112.9591] 
device (rename4): enslaved to non-master-type device ens3; ignoring
  Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: error changing net interface 
name 'eth0' to 'ens3': Device or resource busy
  Mar 18 11:01:53 ubuntu-18 systemd-udevd[2463]: could not rename interface '4' 
from 'eth0' to 'ens3': Device or resource busy

  Within VM there's netplan config as below:

  vsbalakr@ubuntu-18:~$ cat /etc/netplan/01-netcfg.yaml
  # This file describes the network interfaces available on your system
  # For more information, see netplan(5).
  network:
version: 2
renderer: networkd
ethernets:
  ens3:
dhcp4: yes
gateway4: 10.211.8.1
nameservers:
addresses: [10.211.11.1,10.209.76.197]

  By running udevadm test, we can see the conflicting ens3 name comes
  from netplan's /run/udev/rules.d/99-netplan-ens3.rules

  vsbalakr@ubuntu-18:~$ cat /run/udev/rules.d/99-netplan-ens3.rules
  SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", 
ATTR{address}=="ba:fb:9f:12:2f:02", NAME="ens3"

  vsbalakr@ubuntu-18:/lib/udev/rules.d$ udevadm test --action="add" 
/sys/class/net/eth0
  calling: test
  version 237
  This program is for debugging only, it does not run any program
  specified by a RUN key. It may show incorrect results, because
  some values may be different, or not available at a simulation run.

  Load module index
  Parsed configuration file /lib/systemd/network/99-default.link
  Parsed configuration file /run/systemd/network/10-netplan-ens3.link
  Created link configuration context.
  Reading rules file: /lib/udev/rules.d/01-md-raid-creating.rules
  ..
  Reading rules file: /lib/udev/rules.d/99-vmware-scsi-udev.rules
  rules contain 393216 bytes tokens (32768 * 12 bytes), 38638 bytes strings
  25317 strings (216160 bytes), 21957 de-duplicated (180883 bytes), 3361 trie 
nodes used
  RUN '/lib/open-iscsi/net-interface-handler start' 
/lib/udev/rules.d/70-iscsi-network-interface.rules:2
  IMPORT builtin 'net_id' /lib/udev/rules.d/75-net-description.r

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

[Guilherme G. Piccoli]

Just got a test result from an user that reported the issue - the packages with 
the proposed patches [0] fixed the issue to him.
cheers,


Guilherme


[0] https://launchpad.net/~gpiccoli/+archive/ubuntu/lp1879980

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** Patch added: "focal_initramfs_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5398703/+files/focal_initramfs_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** Patch added: "xenial_initramfs_lp1879987.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5398705/+files/xenial_initramfs_lp1879987.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

Worth to notice that the debdiffs (except Xenial's) include a fix for LP
#1879980 - we are doing a single SRU for 2 bugs.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** Patch added: "groovy_initramfs_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5398702/+files/groovy_initramfs_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** Patch added: "bionic_initramfs_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+attachment/5398704/+files/bionic_initramfs_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "focal_initramfs_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5398699/+files/focal_initramfs_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "groovy_cryptsetup_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5398696/+files/groovy_cryptsetup_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "bionic_initramfs_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5398701/+files/bionic_initramfs_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "groovy_initramfs_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5398697/+files/groovy_initramfs_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "focal_cryptsetup_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5398698/+files/focal_cryptsetup_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Worth to notice that the initramfs-tools debdiffs include a fix for LP
#1879987 - we are doing a single SRU for 2 bugs.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

One relevant discussion would be why we decided to not change mdadm code
anymore. What happens here is that we have an inter-dependency between
mdadm and cryptroot - we first changed the mdadm max counter to
"untangle" that relation, in a way cryptroot would run more times than
mdadm.

But studying better the initramfs-tools, we notice that we could use the
same "hack" currently in code to execute mdadm on local-block for
cryptroot, and add an extra cryptroot run if mdadm was executed. This
way, we make things work as expected (ab-)using the same code already
present on initramfs-tools, without requiring modifying yet another boot
component.

I've set mdadm as "Opinion" in this LP because *it is affected*, in
fact, it is part of the problem. But...not changing mdadm is a cheaper
option in my opinion. At least for now..I plan to try a refactor on
initramfs-tools to cope with inter-relations of components on local-
block, regardless of their number (and this will require changing
mdadm).

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once 

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

[Guilherme G. Piccoli]

** Patch added: "bionic_cryptsetup_lp1879980.debdiff"
   
https://bugs.launchpad.net/ubuntu/focal/+source/mdadm/+bug/1879980/+attachment/5398700/+files/bionic_cryptsetup_lp1879980.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Oh, I forgot to mention - Xenial won't be fixed. It's a release pretty stable 
with less then a year remaining of regular support, and with older code. So, in 
my opinion (again) it's safer to keep it as is, and consider that degraded 
RAID1 + encrypted rootfs is fully supported on Bionic and so on.
Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress
Status in mdadm source package in Groovy:
  Opinion
Status in cryptsetup package in Debian:
  New

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  * The hereby proposed solution has 2 components: first, cryptsetup
  script is modified to allow a gentle failure on local-top stage, then
  it retries for a while (according to a heuristic based on ROOTDELAY
  with minimum of 30 executions) in a later stage (local-block). This
  gives time to other initramfs scripts to run, like mdadm in local-
  block stage. And this is meant to work this way according to
  initramfs-tools documentation (although Ubuntu changed it a bit with
  wait-for-root, hence we stopped looping on local-block, see next
  bullet).

  * Second, initramfs-tools was adjusted - currently, it runs for a
  while the mdadm local-block script, in order to assemble the arrays in
  a non-degraded mode. We extended this approach to also execute
  cryptsetup, in a way that after mdadm ends its execution, we execute
  at least once more time cryptsetup. In an ideal world we should loop
  on local-block as Debian's initramfs (in a way to remove hardcoded
  mdadm/cryptsetup mentions from initramfs-tools code), but this would
  be really a big change, non-SRUable probably. I plan to work that for
  future Ubuntu releases.

  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  * If using the initramfs-toos/cryptsetup patches hereby proposed, the
  rootfs can be mounted normally.

  [Regression potential]

  * There are potential for regressions, since this is a change in 2
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A modification in the behavior of cryptsetup was introduced: right
  now, if we fail the password 3 times (the default maximum attempts),
  the script doesn't "panic" and drop to a shell immediately; instead it
  runs once more (or twice, if mdadm is installed) before failing. This
  is a minor change given the benefit of the being able to mount rootfs
  in a degraded RAID1 scenario.

  * Other potential regressions could show-up as boot problems, but the
  change in initramfs-tools specifically is not invasive, it just may
  delay boot time a bit, given we now run cryptsetup multiple times on
  local-block, with 1 sec delays between executions.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : 

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

[Guilherme G. Piccoli]

** Description changed:

  [Impact]
- * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array members gets removed.
+ * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array's members gets removed.
  
  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).
  
  * Second, mdadm initramfs script that assembles degraded arrays executes
  later on boot, in the local-block stage. So, in a stacked setup of
  encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails
  early in the boot, preventing mdadm to assemble the degraded array.
  
- [Proposed solution]
- * The solution hereby proposed has 3 components: first, cryptsetup script is 
modified to allow a gentle failure on local-top stage, then it retries for a 
while in a later stage (local-block). This gives time to other initramfs 
scripts to run, like mdadm in local-block stage.
+ * The hereby proposed solution has 2 components: first, cryptsetup
+ script is modified to allow a gentle failure on local-top stage, then it
+ retries for a while (according to a heuristic based on ROOTDELAY with
+ minimum of 30 executions) in a later stage (local-block). This gives
+ time to other initramfs scripts to run, like mdadm in local-block stage.
+ And this is meant to work this way according to initramfs-tools
+ documentation (although Ubuntu changed it a bit with wait-for-root,
+ hence we stopped looping on local-block, see next bullet).
  
- * Second, mdadm script was adjusted - currently, it retries for a while
- to assemble the arrays in a non-degraded mode, by waiting for udev to
- discover the missing devices. After some time, it gives-up and assembles
- all arrays as degraded. The adjust we made was only to reduce this
- number of attempts and fallback a bit faster to degraded array assembly.
- 
- * Third, there's a difference in Ubuntu initramfs-tools compared to
- Debian's : in Ubuntu, we rely on wait-for-root, a binary meant to speed-
- up the boot process. Problem is that currently this approach prevents
- local-block scripts to run more than once (thus retrying mechanisms will
- fail). Our proposed solution changes initramfs-tools to allow some
- looping in local-block stage (as Debian), but still relying on wait-for-
- root. Also, we increased a bit the default rootdelay from 30 seconds to
- 60 seconds.
- 
+ * Second, initramfs-tools was adjusted - currently, it runs for a while
+ the mdadm local-block script, in order to assemble the arrays in a non-
+ degraded mode. We extended this approach to also execute cryptsetup, in
+ a way that after mdadm ends its execution, we execute at least once more
+ time cryptsetup. In an ideal world we should loop on local-block as
+ Debian's initramfs (in a way to remove hardcoded mdadm/cryptsetup
+ mentions from initramfs-tools code), but this would be really a big
+ change, non-SRUable probably. I plan to work that for future Ubuntu
+ releases.
  
  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.
  
  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.
  
+ * If using the initramfs-toos/cryptsetup patches hereby proposed, the
+ rootfs can be mounted normally.
  
  [Regression potential]
  
- * There are potential for regressions, since this is a change in 3 boot
+ * There are potential for regressions, since this is a change in 2 boot
  components. The patches were designed in a way to keep the regular case
  working, it changes the failure case which is not currently working
  anyway.
  
- * A potential issue in the initramfs-tools change is a bad script in
- local-block, lacking a good "halt" mechanism, to induce a boot loop
- condition. This problem would be exposed by the hereby proposed
- modification.
+ * A modification in the behavior of cryptsetup was introduced: right
+ now, if we fail the password 3 times (the default maximum attempts), the
+ script doesn't "panic" and drop to a shell immediately; instead it runs
+ once more (or twice, if mdadm is installed) before failing. This is a
+ minor change given the benefit of the being able to mount rootfs in a
+ degraded RAID1 scenario.
+ 
+ * Other potential regressions could show-up as boot problems, but the
+ change in initramfs-tools specifically is not invasive, it just may
+ delay boot time a bit, given we now run cryptsetup multiple times on
+ local-block, with 1 sec delays between executions.

-- 
You received this 

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

[Guilherme G. Piccoli]

** Changed in: mdadm (Ubuntu)
   Status: Confirmed => Opinion

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => In Progress

** Also affects: mdadm (Ubuntu Groovy)
   Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: Opinion

** Also affects: cryptsetup (Ubuntu Groovy)
   Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: In Progress

** Also affects: initramfs-tools (Ubuntu Groovy)
   Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: In Progress

** Also affects: mdadm (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: cryptsetup (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

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

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

** Also affects: initramfs-tools (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: mdadm (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: cryptsetup (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Changed in: mdadm (Ubuntu Xenial)
   Status: New => Opinion

** Changed in: mdadm (Ubuntu Bionic)
   Status: New => Opinion

** Changed in: cryptsetup (Ubuntu Xenial)
   Status: New => Opinion

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

** Changed in: cryptsetup (Ubuntu Bionic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

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

** Changed in: cryptsetup (Ubuntu Xenial)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

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

** Changed in: cryptsetup (Ubuntu Xenial)
   Status: Opinion => Won't Fix

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

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

** Changed in: cryptsetup (Ubuntu Focal)
     Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Xenial)
   Status: New => Won't Fix

** Changed in: initramfs-tools (Ubuntu Xenial)
     Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Bionic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Focal)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Focal)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

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

** Changed in: mdadm (Ubuntu Xenial)
   Status: Opinion => Won't Fix

** Changed in: mdadm (Ubuntu Xenial)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

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

** Changed in: mdadm (Ubuntu Bionic)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

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

** Changed in: mdadm (Ubuntu Focal)
   Status: New => Opinion

** Changed in: mdadm (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in mdadm package in Ubuntu:
  Opinion
Status in cryptsetup source package in Xenial:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  Won't Fix
Status in mdadm source package in Xenial:
  Won't Fix
Status in cryptsetup source package in Bionic:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in mdadm source package in Bionic:
  Opinion
Status in cryptsetup source package in Focal:
  In Progress
Status in initramfs-tools source package in Focal:
  In Progress
Status in mdadm source package in Focal:
  Opinion
Status in cryptsetup source package in Groovy:
  In Progress
Status in initramfs-tools source package in G

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** Description changed:

- kernel get stucks at boot if console=ttyS* is specified in the kernel
- cmdline and that serial HW isn't available on the system.
+ [Impact]
  
- Reproduced with:
- 4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)
+ * Currently, if users provide the wrong console in kernel command-line
+ (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
+ parameter is not provided, we may face an infinite loop on initramfs-
+ tools, effectively blocking the boot.
  
- Removing the non-existent 'console=ttyS*' parameter fixes the situation.
+ * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
+  
+ * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.
  
- I tested it using KVM/qemu, but it has been brought to my attention that
- it was reproducible in VMware as well.
+ * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
+ should definitely not brake the boot due to error log functions.
  
- I think it is safe to say that it is unlikely to be specifics to a
- certain virtualization technology type.
  
- Didn't test on baremetal yet.
+ [Test Case]
+ 
+ * To reproduce this, one must boot a system (virtual machine is good)
+ with the wrong console set on kernel command-line through the "console="
+ parameter *and* not pass the "quiet" parameter.
+ 
+ * Also, e2fsck tool shouldn't be present in the initrd - for that, the
+ 6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
+ recreated after that. This is the default in Ubuntu, though.
+ 
+ 
+ [Regression Potential]
+ 
+ * The regression potential is small, we're just returning 0 after a
+ printf that is executed in error paths, so I don't expect any issues
+ from that. But in case something bad happens after this change, I expect
+ a more friendly" breakage, like an initramfs panic (drop to a shell),
+ not a silent failure or boot-loop.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  [Impact]

  * Currently, if users provide the wrong console in kernel command-line
  (like console=ttyS1, when the right one is ttyS0) *and* "quiet"
  parameter is not provided, we may face an infinite loop on initramfs-
  tools, effectively blocking the boot.

  * Details are: the _log_msg() functions is "void" typed, which means it 
returns whatever its last command returns; this function is the basic building 
block for all error/warning messages in initramfs-tools. In case a bad console 
was provided to kernel on command-line, printf (and apparently all 
write()-related functions) returns error, and so this error is carried over in 
_log_msg().
   
  * Happens that checkfs() function has a loop that runs forever in this 
scenario (*if* fsck is not present in initramfs, and obviously if "quiet" is 
not provided in the command-line). The situation is easily reproducible.

  * This SRU proposes a pretty simple fix: return zero on _log_msg(). We
  should definitely not brake the boot due to error log functions.

  
  [Test Case]

  * To reproduce this, one must boot a system (virtual machine is good)
  with the wrong console set on kernel command-line through the
  "console=" parameter *and* not pass the "quiet" parameter.

  * Also, e2fsck tool shouldn't be present in the initrd - for that, the
  6th field of /etc/fstab (fs_passno) should be 0 and initrd must be
  recreated after that. This is the default in Ubuntu, though.

  
  [Regression Potential]

  * The regression potential is small, we're just returning 0 after a
  printf that is executed in error paths, so I don't expect any issues
  from that. But in case something bad happens after this change, I
  expect a more friendly" breakage, like an initramfs panic (drop to a
  shell), not a silent failure or boot-loop.

To manage notifications about this 

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

Let me clarify why I'm un-marking this as duplicate of #1573095. This LP
bug is indeed a duplicate of #1573095, but we have a lot of noise there,
and potentially multiple different issues reported. The main one is the
wrong ttySX causing the infinite loop in initramfs-tools due to error on
write.

Hence, I'll use this LP to do the SRU for Ubuntu initramfs-tools. Also,
worth notice that we have Debian bugs reported [0] and a Merge Request
in Debian Salsa [1], both ignored by the Debian maintainer for 6 weeks.
So, we'll go with Ubuntu fix for now, and hopefully Debian will merge
that in the future.

Cheers,


Guilherme


[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962545 and 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=960355

[1] https://salsa.debian.org/kernel-team/initramfs-
tools/-/merge_requests/30

** Bug watch added: Debian Bug tracker #962545
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962545

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

** This bug is no longer a duplicate of bug 1573095
   Cloud images fail to boot when a serial port is not available

** No longer affects: linux (Ubuntu)

** Changed in: initramfs-tools (Ubuntu)
   Status: Confirmed => In Progress

** Also affects: initramfs-tools (Ubuntu Eoan)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Focal)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Trusty)
   Importance: Undecided
   Status: New

** Also affects: initramfs-tools (Ubuntu Groovy)
   Importance: High
 Assignee: Guilherme G. Piccoli (gpiccoli)
   Status: In Progress

** Changed in: initramfs-tools (Ubuntu Eoan)
   Status: New => Won't Fix

** Changed in: initramfs-tools (Ubuntu Trusty)
   Status: New => Won't Fix

** Changed in: initramfs-tools (Ubuntu Xenial)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Bionic)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Focal)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided => High

** Changed in: initramfs-tools (Ubuntu Trusty)
   Importance: High => Low

** Changed in: initramfs-tools (Ubuntu Bionic)
   Importance: Undecided => High

** Changed in: initramfs-tools (Ubuntu Focal)
   Importance: Undecided => High

** Changed in: initramfs-tools (Ubuntu Eoan)
   Importance: Undecided => Low

** Changed in: initramfs-tools (Ubuntu Focal)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Eoan)
     Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Bionic)
     Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Xenial)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Trusty)
     Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  Won't Fix
Status in initramfs-tools source package in Xenial:
  In Progress
Status in initramfs-tools source package in Bionic:
  In Progress
Status in initramfs-tools source package in Eoan:
  Won't Fix
Status in initramfs-tools source package in Focal:
  In Progress
Status in initramfs-tools source package in Groovy:
  In Progress

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1392317] Re: Incorrect order of messages with RepeatedMsgReduction on

[Guilherme G. Piccoli]

Thanks Roger and Kobus for your report! Do you know if the problem persists on 
Xenial (16.04) or later Ubuntu releases? We don't support fixes for Trusty 
anymore except for security ones, so I've marked as "won't fix". In case you 
can reproduce with newer versions, let us know.
Cheers,


Guilherme

** Also affects: rsyslog (Ubuntu Trusty)
   Importance: Undecided
   Status: New

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

** Changed in: rsyslog (Ubuntu)
   Status: Confirmed => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
https://bugs.launchpad.net/bugs/1392317

Title:
  Incorrect order of messages with RepeatedMsgReduction on

Status in rsyslog package in Ubuntu:
  Invalid
Status in rsyslog source package in Trusty:
  Won't Fix

Bug description:
  In rsyslog Version 7.4.4-1ubuntu2.3 there is a bug which mixes up the order 
of some messages when $RepeatedMsgReduction is enabled.
  This can sometimes result in a message missing in the current syslog and 
being printed even days later.
  Using Ubuntu 14.04.1 LTS.
  […]
  Nov 12 16:32:01 ws-api3 CRON[5572]: pam_unix(cron:session): session closed 
for user www-data
  Nov 12 16:33:01 ws-api3 CRON[5582]: pam_unix(cron:session): session opened 
for user www-data by (uid=0)
  Nov 10 11:56:01 ws-api3 CRON[5583]: (www-data) CMD (nice -n10 php 
/var/www/api/scripts/import/php/import.php all^I>> $CL/import.log 2>> 
$PL/api_cli_er
  rlog)
  Nov 12 16:33:01 ws-api3 CRON[5583]: (www-data) CMD (nice -n10 php 
/var/www/api/scripts/import/php/import.php all^I>> $CL/dev_import.log 2>> 
$PL/dev_ap
  i_cli_errlog)
  Nov 12 16:33:01 ws-api3 CRON[5582]: pam_unix(cron:session): session closed 
for user www-data
  […]

  
  To reproduce this error, turn on $RepeatedMsgReduction in the rsyslog.conf 
and generate a whole bunch of syslog message, e.g. with the following php 
script:
   $k'");
   }
  }

  Result will be (after a short while):
  Nov 12 11:17:08 syslogTest vm[21410]: log > 0
  Nov 12 11:18:05 syslogTest vm[21410]: log > 1
  Nov 12 11:17:08 syslogTest vm[21412]: log > 0
  Nov 12 11:18:05 syslogTest vm[21412]: log > 1
  Nov 12 11:17:08 syslogTest vm[21414]: log > 0
  Nov 12 11:18:05 syslogTest vm[21414]: log > 1

  What's pretty suspicious is that after the pool of process IDs is exhausted 
and resettet, old messages are from the same process ID but from the previous 
iteration.
  Is RepeatedMsgReduction somehow grouping by process ID? In the first example 
is a cron process using the same process ID like one before, therefore printing 
the old message from Nov, 10. The old message was not at the position inside 
the syslog where it should have been.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Changed in: cryptsetup (Ubuntu)
   Status: Confirmed => In Progress

** Bug watch added: Debian Bug tracker #933059
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933059

** Also affects: cryptsetup (Debian) via
   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=933059
   Importance: Unknown
   Status: Unknown

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  In Progress
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed
Status in cryptsetup package in Debian:
  Unknown

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  [Proposed solution]
  * The solution hereby proposed has 3 components: first, cryptsetup script is 
modified to allow a gentle failure on local-top stage, then it retries for a 
while in a later stage (local-block). This gives time to other initramfs 
scripts to run, like mdadm in local-block stage.

  * Second, mdadm script was adjusted - currently, it retries for a
  while to assemble the arrays in a non-degraded mode, by waiting for
  udev to discover the missing devices. After some time, it gives-up and
  assembles all arrays as degraded. The adjust we made was only to
  reduce this number of attempts and fallback a bit faster to degraded
  array assembly.

  * Third, there's a difference in Ubuntu initramfs-tools compared to
  Debian's : in Ubuntu, we rely on wait-for-root, a binary meant to
  speed-up the boot process. Problem is that currently this approach
  prevents local-block scripts to run more than once (thus retrying
  mechanisms will fail). Our proposed solution changes initramfs-tools
  to allow some looping in local-block stage (as Debian), but still
  relying on wait-for-root. Also, we increased a bit the default
  rootdelay from 30 seconds to 60 seconds.

  
  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  
  [Regression potential]

  * There are potential for regressions, since this is a change in 3
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A potential issue in the initramfs-tools change is a bad script in
  local-block, lacking a good "halt" mechanism, to induce a boot loop
  condition. This problem would be exposed by the hereby proposed
  modification.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Debian merge request for the cryptsetup patch was just submitted:
https://salsa.debian.org/cryptsetup-team/cryptsetup/-/merge_requests/18

Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  [Proposed solution]
  * The solution hereby proposed has 3 components: first, cryptsetup script is 
modified to allow a gentle failure on local-top stage, then it retries for a 
while in a later stage (local-block). This gives time to other initramfs 
scripts to run, like mdadm in local-block stage.

  * Second, mdadm script was adjusted - currently, it retries for a
  while to assemble the arrays in a non-degraded mode, by waiting for
  udev to discover the missing devices. After some time, it gives-up and
  assembles all arrays as degraded. The adjust we made was only to
  reduce this number of attempts and fallback a bit faster to degraded
  array assembly.

  * Third, there's a difference in Ubuntu initramfs-tools compared to
  Debian's : in Ubuntu, we rely on wait-for-root, a binary meant to
  speed-up the boot process. Problem is that currently this approach
  prevents local-block scripts to run more than once (thus retrying
  mechanisms will fail). Our proposed solution changes initramfs-tools
  to allow some looping in local-block stage (as Debian), but still
  relying on wait-for-root. Also, we increased a bit the default
  rootdelay from 30 seconds to 60 seconds.

  
  [Test case]
  * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.

  * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
  from one of the RAID members. Reboot and it will fail to mount rootfs
  and continue boot process.

  
  [Regression potential]

  * There are potential for regressions, since this is a change in 3
  boot components. The patches were designed in a way to keep the
  regular case working, it changes the failure case which is not
  currently working anyway.

  * A potential issue in the initramfs-tools change is a bad script in
  local-block, lacking a good "halt" mechanism, to induce a boot loop
  condition. This problem would be exposed by the hereby proposed
  modification.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Description changed:

- Description will be saved for further SRU template, the details of the
- issue will be exposed in comments
+ [Impact]
+ * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array members gets removed.
+ 
+ * The problem has 2 main aspects: first, cryptsetup initramfs script
+ attempts to decrypt the array only in the local-top boot stage, and in
+ case it fails, it gives-up and show user a shell (boot is aborted).
+ 
+ * Second, mdadm initramfs script that assembles degraded arrays executes
+ later on boot, in the local-block stage. So, in a stacked setup of
+ encrypted root on top of RAID, if the RAID is degraded, cryptsetup fails
+ early in the boot, preventing mdadm to assemble the degraded array.
+ 
+ [Proposed solution]
+ * The solution hereby proposed has 3 components: first, cryptsetup script is 
modified to allow a gentle failure on local-top stage, then it retries for a 
while in a later stage (local-block). This gives time to other initramfs 
scripts to run, like mdadm in local-block stage.
+ 
+ * Second, mdadm script was adjusted - currently, it retries for a while
+ to assemble the arrays in a non-degraded mode, by waiting for udev to
+ discover the missing devices. After some time, it gives-up and assembles
+ all arrays as degraded. The adjust we made was only to reduce this
+ number of attempts and fallback a bit faster to degraded array assembly.
+ 
+ * Third, there's a difference in Ubuntu initramfs-tools compared to
+ Debian's : in Ubuntu, we rely on wait-for-root, a binary meant to speed-
+ up the boot process. Problem is that currently this approach prevents
+ local-block scripts to run more than once (thus retrying mechanisms will
+ fail). Our proposed solution changes initramfs-tools to allow some
+ looping in local-block stage (as Debian), but still relying on wait-for-
+ root. Also, we increased a bit the default rootdelay from 30 seconds to
+ 60 seconds.
+ 
+ 
+ [Test case]
+ * Install Ubuntu in a Virtual Machine with 2 disks. Use the installer to 
create a RAID1 volume and an encrypted root on top of it.
+ 
+ * Boot the VM, and use "sgdisk"/"wipefs" to erase the partition table
+ from one of the RAID members. Reboot and it will fail to mount rootfs
+ and continue boot process.
+ 
+ 
+ [Regression potential]
+ 
+ * There are potential for regressions, since this is a change in 3 boot
+ components. The patches were designed in a way to keep the regular case
+ working, it changes the failure case which is not currently working
+ anyway.
+ 
+ * A potential issue in the initramfs-tools change is a bad script in
+ local-block, lacking a good "halt" mechanism, to induce a boot loop
+ condition. This problem would be exposed by the hereby proposed
+ modification.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  [Impact]
  * Considering a setup of a encrypted rootfs on top of md RAID1 device, Ubuntu 
is currently unable to decrypt the rootfs if the array gets degraded, like for 
example if one of the array members gets removed.

  * The problem has 2 main aspects: first, cryptsetup initramfs script
  attempts to decrypt the array only in the local-top boot stage, and in
  case it fails, it gives-up and show user a shell (boot is aborted).

  * Second, mdadm initramfs script that assembles degraded arrays
  executes later on boot, in the local-block stage. So, in a stacked
  setup of encrypted root on top of RAID, if the RAID is degraded,
  cryptsetup fails early in the boot, preventing mdadm to assemble the
  degraded array.

  [Proposed solution]
  * The solution hereby proposed has 3 components: first, cryptsetup script is 
modified to allow a gentle failure on local-top stage, then it retries for a 
while in a later stage (local-block). This gives time to other initramfs 
scripts to run, like mdadm in local-block stage.

  * Second, mdadm script was adjusted - currently, it retries for a
  while to assemble the arrays in a non-degraded mode, by waiting for
  udev to discover the missing devices. After some time, it gives-up and
  assembles all arrays as degraded. The adjust we made was only to
  reduce this number of attempts and fallback a bit faster to degraded
  array assembly.

  * Third, there's a difference in Ubuntu initramfs-tools compared to
  Debian's : in Ubuntu, we rely on wait-for-root, a binary meant to
  speed-up the boot process. Problem is that currently this approach
  prevents local-block scripts to run more than once (thus 

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

[Guilherme G. Piccoli]

I have a report of a Bionic user that tested the packages on my PPA with 
success.
I changed a small bit though, from the first proposal (just for consistency): 
moved the cryptsetup clean-up script to local-bottom instead of init-bottom.

Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

*** This bug is a duplicate of bug 1573095 ***
https://bugs.launchpad.net/bugs/1573095

Although this is closed as dup, I thought would be good to clarify why
Debian Buster doesn't reproduce (at first). What happens is that Debian
includes the fsck on initrd by default, and in Ubuntu that doesn't
happen - the reason behind it is that rootfs is marked as always-verify
in the 6th field of fstab (fs_passno) in the Debian cloud image I got,
whereas Ubuntu cloud image use the default value, 0.

Once I changed Debian to not include fsck on initrd, it reproduced the
issue. And once I set Ubuntu rootfs to have value 1 on fstab's 6th
field, it stopped to reproduce. When fsck is on initrd, we don't
log_warn "fsck not present, so skipping $NAME file system", so we don't
fail in _checkfs_once(), hence there's no infinite loop on checkfs().

Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

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

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

List of somewhat duplicate bugs:
https://bugs.launchpad.net/ubuntu/+source/mdadm/+bug/120375
(after comment #74)

https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/251164
(propose some alternative solutions we can think about, like failure hooks)

https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/659899

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1003309
(partially related)

blog post: feeding.cloud.geek.nz/posts/the-perils-of-raid-and-full-disk-
encryption-on-ubuntu

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

Not a debdiff - I found easier to just add the patches as in my local
git repository of the packages.

** Patch added: "cryptroot patch"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879980/+attachment/5375734/+files/0001-d-initramfs-cryptroot-script-Allow-some-retries-on-l.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "mdadm patch"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879980/+attachment/5375736/+files/0001-script.local-block-Improve-last-resort-mechanism.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

** Patch added: "initramfs-tools patch"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879980/+attachment/5375735/+files/0001-scripts-local-Allow-local-block-looping-as-Debian.patch

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

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

[Guilherme G. Piccoli]

The issue basically is about a failure in mounting root if we have a
stacked setup of LUKS on top of RAID1, when RAID1 is degraded (like a
member missing). What happens in detail is a conjuncture of factors
leading to this problem:

(a) The initramfs script for cryptroot currently is present in two
initram stages: local-top and local-block. Problem is that if the script
fails on local-top phase, it panics and opens a console, not allowing
the boot process to continue. In this case, subsequent scripts are not
executed automatically.

(b) The mdadm initramfs script to mount degraded arrays runs on local-
block stage. It provides a heuristic that tries a regular array assemble
for (2/3*ROOTDELAY) times, and then it assembles the array as degraded,
in which is called the "poor man last resort" mechanism.

So, the first and far more serious issue is cryptroot early fail at
local-top phase. So an idea I've implemented to fix this was to allow
some retries on local-block stage, given local-block should loop for a
while running its scripts (at least according to documentation and
Debian's initramfs code). But guess what ?

(c) In Ubuntu, we have wait-on-root, which aims to speed-up the boot, in
my shallow understanding. Basically, we have wait-for-root consuming
almost all the ROOTDELAY time (30s as default, if not specified), and
local-block scripts run only once. Except...mdadm, which has the
previously mentioned heuristic of running 2/3*ROOTDELAY times. And for
that, we have a hack on initramfs-tools to cope with mdadm (!), as per
commit: salsa.debian.org/kernel-team/initramfs-tools/-/commit/033c948bb0
.

So, to fix the cryptroot inability to mount root device on top a
degraded RAID1 is a matter of coordinate mdadm and cryptroot, and (if my
approach is taken), loop on local-block. Below are the steps I took to
circumvent this long-term issue:

1) Allows cryptsetup to retry on local-block stage, relying in a
heuristic based on ROOTDELAY (we try 1/4*ROOTDELAY times) and on
initramfs looping at local-block phase.

2) Reduce the heuristic frequency on mdadm, in order it doesn't "beat"
the cryptroot attempts, i.e., cryptroot must execute more times. for
this, we reduced the heuristic for 1/5*ROOTDELAY.

3) Make local-block on Ubuntu loop again, but still rely on wait-for-
root in a first step; also, I removed that mdadm heinous hack from
initramfs-tools, it works without...that...if local-block loops.

Below I'll submit groovy debdiffs to gather reviews on my approach. Also, a PPA 
with packages built, in case somebody else wanna give them a try: 
https://launchpad.net/~gpiccoli/+archive/ubuntu/lp1879980
Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

*** This bug is a duplicate of bug 1573095 ***
https://bugs.launchpad.net/bugs/1573095

Sorry, dup of LP #1573095.

** This bug has been marked a duplicate of bug 1573095
   Cloud images fail to boot when a serial port is not available

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

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

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

*** This bug is a duplicate of bug 1573095 ***
https://bugs.launchpad.net/bugs/1573095

Eric, I'll close this LP as dup of #1879987 - seems it's the same issue.
I'll try also the Debian release top see what's different there...we can
comment in the other bug about Debian status and what are the
differences.

Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

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

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879987] Re: machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

[Guilherme G. Piccoli]

This was greatly debugged by LP user WGH in https://bugs.launchpad.net
/cloud-images/+bug/1573095/comments/46 - it's really a flaw on
initramfs, I managed to workaround the issue with "quiet" parameter
(system boots normally ,even with the wrong serial console).

Investigation continues... I guess this LP may end-up being a duplicate of 
1573095.
Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879987

Title:
  machine get stuck at boot if specified 'console=ttyS* ' doesn't exist.

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

Bug description:
  kernel get stucks at boot if console=ttyS* is specified in the kernel
  cmdline and that serial HW isn't available on the system.

  Reproduced with:
  4.4 (from Xenial), 4.15 (from Bionic), 5.4 (native, Focal) and 5.7-next 
(mainline)

  Removing the non-existent 'console=ttyS*' parameter fixes the
  situation.

  I tested it using KVM/qemu, but it has been brought to my attention
  that it was reproducible in VMware as well.

  I think it is safe to say that it is unlikely to be specifics to a
  certain virtualization technology type.

  Didn't test on baremetal yet.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1879987/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1879980] [NEW] Fail to boot with LUKS on top of RAID1 if the array is broken/degraded

[Guilherme G. Piccoli]

Public bug reported:

Description will be saved for further SRU template, the details of the
issue will be exposed in comments

** Affects: cryptsetup (Ubuntu)
 Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
 Status: Confirmed

** Affects: initramfs-tools (Ubuntu)
 Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
 Status: Confirmed

** Affects: mdadm (Ubuntu)
 Importance: Medium
 Assignee: Guilherme G. Piccoli (gpiccoli)
 Status: Confirmed


** Tags: sts

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

** Changed in: mdadm (Ubuntu)
   Status: New => Confirmed

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

** Changed in: mdadm (Ubuntu)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Also affects: initramfs-tools (Ubuntu)
   Importance: Undecided
   Status: New

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

** Changed in: initramfs-tools (Ubuntu)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1879980

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

Status in cryptsetup package in Ubuntu:
  Confirmed
Status in initramfs-tools package in Ubuntu:
  Confirmed
Status in mdadm package in Ubuntu:
  Confirmed

Bug description:
  Description will be saved for further SRU template, the details of the
  issue will be exposed in comments

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1771557] Re: NVMe boot drives not supported - failing in generating initramfs

[Guilherme G. Piccoli]

Thanks a lot Eric and Brian for handling the SRU process.
I just tested the packages initramfs-tools and initramfs-tools-bin version 
0.103ubuntu4.11, from trusty-proposed, following the test procedure of this 
LP's description.

Everything is working fine, so I'll mark this as verification-done.

Cheers,


Guilherme

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

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1771557

Title:
  NVMe boot drives not supported - failing in generating initramfs

Status in initramfs-tools:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  Fix Committed
Status in initramfs-tools source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  When creating the initramfs image, mkinitramfs has multiple options on
  how to include modules. The default (and most common) one is the
  "MODULES=most", which includes the majority of filesystem modules and
  all the block device drivers. One other option is "MODULES=dep", which
  tries to descend in the sysfs hierarchy and guess modules to add, with
  the goal of reduce the size of initramfs.

  For the MODULES=dep case, the initramfs-tools hook-functions script
  cannot translate nvmeXnYpZ to nvmeXnY block device, so it's failing in
  the sysfs lookup, so it does not build the initram disk.

  Upstream solution is composed of at least 2 patches (it's a series,
  but the 2 below are really the needed ones):

  commit 3cb744c9
  Author: Ben Hutchings 
  hook-functions: Rewrite block device sysfs lookup to be generic

  commit 8ac52dc0
  Author: Ben Hutchings 
  hook-functions: Include modules for all components of a multi-disk device

  Instead of doing the huge backport, we added another sed substitution: 
currently the script has substitutions for sdX and hdX, in order to convert 
sda1 to sda, for example. The new substitution converts nvmeXnYpZ to nvmeXnY.
  It's less intrusive than the full backport, since this is a minimal SRU to 
Trusty only.

  [Test Case]
  1. Install Trusty with rootfs in a multi-disk(md) array composed of two nvme 
partitions - in my tests, I've used a RAID1.

  (lsblk output of my test env:

  nvme0n1 259:0010G  0 disk
  └─nvme0n1p1 259:1010G  0 part
    └─md0   9:0010G  0 raid1 /
  nvme1n1 259:2010G  0 disk
  └─nvme1n1p1 259:3010G  0 part
    └─md0   9:0010G  0 raid1 /
  )

  2. Once system is booted, modify the "/etc/initramfs-
  tools/initramfs.conf", replacing "MODULES=most" to "MODULES=dep".

  3. Update your initramfs by running something like:
  "update-initramfs -u -k "

  The initramfs creating procedure will fail, unless the patch from this
  LP is present.

  [Regression Potential]
  If the sed expression was somewhat broken, we could have an issue generating 
initiramfs when MODULES is set to "dep", even for generic block devices (like 
regular HDDs).

  [Other Info]
  * This issue is based on Debian bug #785147: 
  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147

  * Only Trusty is affected, Xenial and late contains the full fix as
  mentioned above :

  $ git describe --contains  8ac52dc0
  v0.121_rc1~11

  $ git describe --contains 3cb744c9
  v0.121_rc1~11

  $ rmadison initramfs-tools

   initramfs-tools | 0.103ubuntu4| trusty   | source, all
   ==> initramfs-tools | 0.103ubuntu4.10 | trusty-updates   | source, all
   initramfs-tools | 0.122ubuntu8| xenial   | source, all
   initramfs-tools | 0.122ubuntu8.11 | xenial-updates   | source, all
   initramfs-tools | 0.125ubuntu12   | artful   | source, all
   initramfs-tools | 0.125ubuntu12.1 | artful-updates   | source, all
   initramfs-tools | 0.130ubuntu3| bionic   | source, all
   initramfs-tools | 0.130ubuntu6| cosmic   | source, all

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/1771557/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1771557] Re: NVMe boot drives not supported - failing in generating initramfs

[Guilherme G. Piccoli]

This solution was suggested by Szilard Cserey and further improved by
Dan Streetman - thanks both!

** Patch added: "lp1771557_v1.debdiff"
   
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1771557/+attachment/5140444/+files/lp1771557_v1.debdiff

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1771557

Title:
  NVMe boot drives not supported - failing in generating initramfs

Status in initramfs-tools:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  In Progress
Status in initramfs-tools source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  When creating the initramfs image, mkinitramfs has multiple options on
  how to include modules. The default (and most common) one is the
  "MODULES=most", which includes the majority of filesystem modules and
  all the block device drivers. One other option is "MODULES=dep", which
  tries to descend in the sysfs hierarchy and guess modules to add, with
  the goal of reduce the size of initramfs.

  For the MODULES=dep case, the initramfs-tools hook-functions script
  cannot translate nvmeXnYpZ to nvmeXnY block device, so it's failing in
  the sysfs lookup, so it does not build the initram disk.

  Upstream solution is composed of at least 2 patches (it's a series,
  but the 2 below are really the needed ones):

  commit 3cb744c9
  Author: Ben Hutchings 
  hook-functions: Rewrite block device sysfs lookup to be generic

  commit 8ac52dc0
  Author: Ben Hutchings 
  hook-functions: Include modules for all components of a multi-disk device

  Instead of doing the huge backport, we added another sed substitution: 
currently the script has substitutions for sdX and hdX, in order to convert 
sda1 to sda, for example. The new substitution converts nvmeXnYpZ to nvmeXnY.
  It's less intrusive than the full backport, since this is a minimal SRU to 
Trusty only.


  [Test Case]
  1. Install Trusty with rootfs in a multi-disk(md) array composed of two nvme 
partitions - in my tests, I've used a RAID1.

  (lsblk output of my test env:

  nvme0n1 259:0010G  0 disk  
  └─nvme0n1p1 259:1010G  0 part  
└─md0   9:0010G  0 raid1 /
  nvme1n1 259:2010G  0 disk  
  └─nvme1n1p1 259:3010G  0 part  
└─md0   9:0010G  0 raid1 /
  )

  
  2. Once system is booted, modify the "/etc/initramfs-tools/initramfs.conf", 
replacing "MODULES=most" to "MODULES=dep".

  3. Update your initramfs by running something like:
  "update-initramfs -u -k "

  The initramfs creating procedure will fail, unless the patch from this
  LP is present.


  [Regression Potential]
  If the sed expression was somewhat broken, we could have an issue generating 
initiramfs when MODULES is set to "dep", even for generic block devices (like 
regular HDDs).


  [Other Info]
  This issue is based on Debian bug #785147: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/1771557/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1771557] Re: NVMe boot drives not supported - failing in generating initramfs

[Guilherme G. Piccoli]

** Description changed:

- [Impact] 
- The initramfs-tools hook-functions script cannot translate nvmeXnYpZ to 
nvmeXnY block device, so it's failing and not building the initram disk.
+ [Impact]
  
- Upstream solution is composed for at least 2 patches (it's a series, but
+ When creating the initramfs image, mkinitramfs has multiple options on
+ how to include modules. The default (and most common) one is the
+ "MODULES=most", which includes the majority of filesystem modules and
+ all the block device drivers. One other option is "MODULES=dep", which
+ tries to descend in the sysfs hierarchy and guess modules to add, with
+ the goal of reduce the size of initramfs.
+ 
+ For the MODULES=dep case, the initramfs-tools hook-functions script
+ cannot translate nvmeXnYpZ to nvmeXnY block device, so it's failing in
+ the sysfs lookup, so it does not build the initram disk.
+ 
+ Upstream solution is composed of at least 2 patches (it's a series, but
  the 2 below are really the needed ones):
  
  commit 3cb744c9
  Author: Ben Hutchings 
  hook-functions: Rewrite block device sysfs lookup to be generic
  
  commit 8ac52dc0
  Author: Ben Hutchings 
  hook-functions: Include modules for all components of a multi-disk device
  
- Instead of doing the backport, which is huge, we added another sed 
substitution: currently the script has substitutions for sdX and hdX, in order 
to convert sda1 to sda, for example. The new substitution converts nvmeXnYpZ to 
nvmeXnY.
- It's less intrusive than the full backport, since this is a SRU to Trusty 
only.
+ Instead of doing the huge backport, we added another sed substitution: 
currently the script has substitutions for sdX and hdX, in order to convert 
sda1 to sda, for example. The new substitution converts nvmeXnYpZ to nvmeXnY.
+ It's less intrusive than the full backport, since this is a minimal SRU to 
Trusty only.
  
  
  [Test Case]
- To be added.
+ 1. Install Trusty with rootfs in a multi-disk(md) array composed of two nvme 
partitions - in my tests, I've used a RAID1.
+ 
+ (lsblk output of my test env:
+ 
+ nvme0n1 259:0010G  0 disk  
+ └─nvme0n1p1 259:1010G  0 part  
+   └─md0   9:0010G  0 raid1 /
+ nvme1n1 259:2010G  0 disk  
+ └─nvme1n1p1 259:3010G  0 part  
+   └─md0   9:0010G  0 raid1 /
+ )
  
  
- [Regression Potential] 
- If the sed expression was somewhat broken, we could have an issue generating 
initiramfs for generic block devices, like regular HDDs.
+ 2. Once system is booted, modify the "/etc/initramfs-tools/initramfs.conf", 
replacing "MODULES=most" to "MODULES=dep".
+ 
+ 3. Update your initramfs by running something like:
+ "update-initramfs -u -k "
+ 
+ The initramfs creating procedure will fail, unless the patch from this
+ LP is present.
+ 
+ 
+ [Regression Potential]
+ If the sed expression was somewhat broken, we could have an issue generating 
initiramfs when MODULES is set to "dep", even for generic block devices (like 
regular HDDs).
  
  
  [Other Info]
  This issue is based on Debian bug #785147: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1771557

Title:
  NVMe boot drives not supported - failing in generating initramfs

Status in initramfs-tools:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  In Progress
Status in initramfs-tools source package in Xenial:
  Fix Released

Bug description:
  [Impact]

  When creating the initramfs image, mkinitramfs has multiple options on
  how to include modules. The default (and most common) one is the
  "MODULES=most", which includes the majority of filesystem modules and
  all the block device drivers. One other option is "MODULES=dep", which
  tries to descend in the sysfs hierarchy and guess modules to add, with
  the goal of reduce the size of initramfs.

  For the MODULES=dep case, the initramfs-tools hook-functions script
  cannot translate nvmeXnYpZ to nvmeXnY block device, so it's failing in
  the sysfs lookup, so it does not build the initram disk.

  Upstream solution is composed of at least 2 patches (it's a series,
  but the 2 below are really the needed ones):

  commit 3cb744c9
  Author: Ben Hutchings 
  hook-functions: Rewrite block device sysfs lookup to be generic

  commit 8ac52dc0
  Author: Ben Hutchings 
  hook-functions: Include modules for all components of a multi-disk device

  Instead of doing the huge backport, we added another sed substitution: 
currently the script has substitutions for sdX and hdX, in order to convert 
sda1 to sda, for example. The new substitution converts nvmeXnYpZ to nvmeXnY.
  It's less intrusive than the full backport, since this is a 

[Touch-packages] [Bug 1771557] Re: NVMe boot drives not supported - failing in generating initramfs

[Guilherme G. Piccoli]

** Changed in: initramfs-tools (Ubuntu)
   Status: In Progress => Fix Released

** Changed in: initramfs-tools (Ubuntu)
   Importance: High => Medium

** Changed in: initramfs-tools (Ubuntu)
Milestone: trusty-updates => None

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1771557

Title:
  NVMe boot drives not supported - failing in generating initramfs

Status in initramfs-tools:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  Fix Released
Status in initramfs-tools source package in Trusty:
  In Progress
Status in initramfs-tools source package in Xenial:
  Fix Released

Bug description:
  [Impact] 
  The initramfs-tools hook-functions script cannot translate nvmeXnYpZ to 
nvmeXnY block device, so it's failing and not building the initram disk.

  Upstream solution is composed for at least 2 patches (it's a series,
  but the 2 below are really the needed ones):

  commit 3cb744c9
  Author: Ben Hutchings 
  hook-functions: Rewrite block device sysfs lookup to be generic

  commit 8ac52dc0
  Author: Ben Hutchings 
  hook-functions: Include modules for all components of a multi-disk device

  Instead of doing the backport, which is huge, we added another sed 
substitution: currently the script has substitutions for sdX and hdX, in order 
to convert sda1 to sda, for example. The new substitution converts nvmeXnYpZ to 
nvmeXnY.
  It's less intrusive than the full backport, since this is a SRU to Trusty 
only.

  
  [Test Case]
  To be added.

  
  [Regression Potential] 
  If the sed expression was somewhat broken, we could have an issue generating 
initiramfs for generic block devices, like regular HDDs.

  
  [Other Info]
  This issue is based on Debian bug #785147: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/1771557/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1771557] Re: NVMe boot drives not supported - failing in generating initramfs

[Guilherme G. Piccoli]

** Package changed: linux (Ubuntu) => initramfs-tools (Ubuntu)

** Changed in: initramfs-tools (Ubuntu Xenial)
   Importance: Undecided => Medium

** Changed in: initramfs-tools (Ubuntu Xenial)
   Status: New => Fix Released

** Changed in: initramfs-tools (Ubuntu Trusty)
   Importance: Undecided => High

** Changed in: initramfs-tools (Ubuntu Trusty)
   Status: New => In Progress

** Changed in: initramfs-tools (Ubuntu Trusty)
 Assignee: (unassigned) => Guilherme G. Piccoli (gpiccoli)

** Changed in: initramfs-tools (Ubuntu Trusty)
Milestone: None => trusty-updates

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu.
https://bugs.launchpad.net/bugs/1771557

Title:
  NVMe boot drives not supported - failing in generating initramfs

Status in initramfs-tools:
  Fix Released
Status in initramfs-tools package in Ubuntu:
  In Progress
Status in initramfs-tools source package in Trusty:
  In Progress
Status in initramfs-tools source package in Xenial:
  Fix Released

Bug description:
  [Impact] 
  The initramfs-tools hook-functions script cannot translate nvmeXnYpZ to 
nvmeXnY block device, so it's failing and not building the initram disk.

  Upstream solution is composed for at least 2 patches (it's a series,
  but the 2 below are really the needed ones):

  commit 3cb744c9
  Author: Ben Hutchings <b...@decadent.org.uk>
  hook-functions: Rewrite block device sysfs lookup to be generic

  commit 8ac52dc0
  Author: Ben Hutchings <b...@decadent.org.uk>
  hook-functions: Include modules for all components of a multi-disk device

  Instead of doing the backport, which is huge, we added another sed 
substitution: currently the script has substitutions for sdX and hdX, in order 
to convert sda1 to sda, for example. The new substitution converts nvmeXnYpZ to 
nvmeXnY.
  It's less intrusive than the full backport, since this is a SRU to Trusty 
only.

  
  [Test Case]
  To be added.

  
  [Regression Potential] 
  If the sed expression was somewhat broken, we could have an issue generating 
initiramfs for generic block devices, like regular HDDs.

  
  [Other Info]
  This issue is based on Debian bug #785147: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=785147

To manage notifications about this bug go to:
https://bugs.launchpad.net/initramfs-tools/+bug/1771557/+subscriptions

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

As mentioned by Dan in the above comments, some failures in autopkgtest
like:

autopkgtest [14:44:48]: test ubuntu-regression-suite: [---
Source Package Version: 4.4.0-1017.17
Running Kernel Version: 3.13.0-145.194
ERROR: running version does not match source package

Are "expected" due to LP #1723223.

Other than that, the proposed package passed in all other tests.
Thanks,

Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1303649] Re: systemd-logind spins in cgmanager_ping_sync()

[Guilherme G. Piccoli]

Thanks a lot for your feedback Marcelo; I'm glad everything seems fine now.
Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1303649

Title:
  systemd-logind spins in cgmanager_ping_sync()

Status in cgmanager package in Ubuntu:
  Invalid
Status in libnih package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd-logind is consuming a high level of cpu on a continual basis:

PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND   
 
676 root  20   0   43644   2144   1568 R 100.0  0.0  74:43.77 
systemd-logind

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: systemd-services 204-5ubuntu17
  ProcVersionSignature: Ubuntu 3.13.0-22.44-generic 3.13.8
  Uname: Linux 3.13.0-22-generic x86_64
  ApportVersion: 2.14.1-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Apr  7 09:09:37 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-04-23 (348 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423)
  SourcePackage: systemd
  UpgradeStatus: Upgraded to trusty on 2013-11-11 (146 days ago)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1303649] Re: systemd-logind spins in cgmanager_ping_sync()

[Guilherme G. Piccoli]

For the folks that observed the recent cgmanager issue with logind:
there's a new systemd version in -proposed; it's version
"204-5ubuntu20.28". I've just tested it with and without cgmanager, in
kernels 4.4.0-119 and 3.13.0-145 (according to LP #1750013), and didn't
observe any constant CPU utilization increase.

Important to notice this new version of systemd ("204-5ubuntu20.28")
_does not depend_ on cgmanager, so it's not mandatory to have cgmanager
installed.

Tests with the new version are welcome, with and without cgmanager. I'd
like to ask, if possible, that anyone that observes the issue again to
test with and without cgmanager, and if possible, in kernels 4.4.0 and
3.13.0, so we have a better idea of the environments reproducing the
issue.

Thanks in advance,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1303649

Title:
  systemd-logind spins in cgmanager_ping_sync()

Status in cgmanager package in Ubuntu:
  Invalid
Status in libnih package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd-logind is consuming a high level of cpu on a continual basis:

PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND   
 
676 root  20   0   43644   2144   1568 R 100.0  0.0  74:43.77 
systemd-logind

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: systemd-services 204-5ubuntu17
  ProcVersionSignature: Ubuntu 3.13.0-22.44-generic 3.13.8
  Uname: Linux 3.13.0-22-generic x86_64
  ApportVersion: 2.14.1-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Apr  7 09:09:37 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-04-23 (348 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423)
  SourcePackage: systemd
  UpgradeStatus: Upgraded to trusty on 2013-11-11 (146 days ago)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

Hi Łukasz, thanks for the heads-up.

I just tested systemd from -proposed, version 204-5ubuntu20.28 and it
fixes the issue reported in this LP.

The test consists in doing multiple SSHs in a loop (better explained in
the description). I've run the test with and without cgmanager
installed, in kernels 4.4.0-119 and 3.13.0-145, no memory leaks
observed.

Important to notice, I wasn't able to observe any constant increase in
CPU utilization from both binaries (logind and cgm); I kept monitoring
and didn't notice anything abnormal.

I'll mark this as verified.
Cheers,


Guilherme

** Tags removed: sts-sru-needed verification-needed verification-needed-trusty
** Tags added: verification-done verification-done-trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

Dan, this is the v3 of the patch. I bumped the version to 20.28 since my
proposed 20.27 caused the regression aforementioned.

For this version, I removed the dependency of cgmanager, along with the
code that added closing sessions to garbage collector. Happens that a
similar code is present on systemd-logind already, and for some reason
(which is still a mystery for me) I was seeing a session leak in the
tool. My hypothesis is that I built one version of the tool without the
bunch of debian patches, and so that portion of code wasn't present.
Then, I started working in a fix, but in the end, the fix is useless
since a similar one is already there.

Anyway, the patch now just avoid some small memory leaks in both
session's free path and cgmanager glue code. It was tested in both
kernels 3.13 and 4.14 (with and without cgmanager), I didn't observe
leaks anymore nor high CPU utilization.

Thanks,


Guilherme

** Patch added: "lp1750013-trusty_v3.debdiff"
   
https://bugs.launchpad.net/ubuntu/artful/+source/systemd/+bug/1750013/+attachment/5100204/+files/lp1750013-trusty_v3.debdiff

** Tags removed: regression-proposed verification-done verification-done-trusty
** Tags added: sts-sru-needed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1303649] Re: systemd-logind spins in cgmanager_ping_sync()

[Guilherme G. Piccoli]

Folks that are experiencing this issue: the best way to circumvent it
for now I guess it's downgrade systemd package to version
204-5ubuntu20.26 and remove cgmanager.

To remove cgmanager: "sudo apt-get remove cgmanager"

To downgrade systemd version: "sudo apt-get install systemd-
services=204-5ubuntu20.26 libsystemd-login0=204-5ubuntu20.26 libsystemd-
daemon0=204-5ubuntu20.26  libpam-systemd=204-5ubuntu20.26
libudev1=204-5ubuntu20.26 udev=204-5ubuntu20.26"

The version 204-5ubuntu20.26 is in the official repos, so no need to
download manually deb packages and whatnot; the proposed 20.27 version
should be removed for now.

Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1303649

Title:
  systemd-logind spins in cgmanager_ping_sync()

Status in cgmanager package in Ubuntu:
  Invalid
Status in libnih package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd-logind is consuming a high level of cpu on a continual basis:

PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND   
 
676 root  20   0   43644   2144   1568 R 100.0  0.0  74:43.77 
systemd-logind

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: systemd-services 204-5ubuntu17
  ProcVersionSignature: Ubuntu 3.13.0-22.44-generic 3.13.8
  Uname: Linux 3.13.0-22-generic x86_64
  ApportVersion: 2.14.1-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Apr  7 09:09:37 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-04-23 (348 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423)
  SourcePackage: systemd
  UpgradeStatus: Upgraded to trusty on 2013-11-11 (146 days ago)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

Thank you Mauro! One thing that worth to take a look is that you're
using kernel 3.13, and this could be related to the high CPU utilization
issue you're observing.

We're changing the approach of this fix to not rely on cgmanager
anymore. The CPU utilization issue is however another bug that needs
investigation - I'll use the LP #1303649 for that.

Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1303649] Re: systemd-logind spins in cgmanager_ping_sync()

[Guilherme G. Piccoli]

Thanks Dale and Marcelo for your quick report - this is really useful.
The problem seem to be caused due to cgmanager being added as dependency
of systemd in -proposed - this request was clearly explained in LP
#1750013 (not a dup for this, it's another issue with systemd-logind).

During my test I didn't observe such bad behavior of high CPU
utilization - might be some interaction I didn't explore/reproduce. Can
you check please if you're using -backports repo ? If so, then the
cgmanager version installed in your system was 0.39 (the default
version, without -backports repo, is 0.24).

Anyway, the systemd package with cgmanager as dependency was _removed_
from -proposed, so as next step I'll focus in fixing the other LP
without adding cgmanager, and eventually investigate what bad
interaction happened in your case to address it.

Thanks,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to lxc in Ubuntu.
https://bugs.launchpad.net/bugs/1303649

Title:
  systemd-logind spins in cgmanager_ping_sync()

Status in cgmanager package in Ubuntu:
  Invalid
Status in libnih package in Ubuntu:
  Invalid
Status in lxc package in Ubuntu:
  Fix Released
Status in systemd package in Ubuntu:
  Fix Released

Bug description:
  systemd-logind is consuming a high level of cpu on a continual basis:

PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+ COMMAND   
 
676 root  20   0   43644   2144   1568 R 100.0  0.0  74:43.77 
systemd-logind

  ProblemType: Bug
  DistroRelease: Ubuntu 14.04
  Package: systemd-services 204-5ubuntu17
  ProcVersionSignature: Ubuntu 3.13.0-22.44-generic 3.13.8
  Uname: Linux 3.13.0-22-generic x86_64
  ApportVersion: 2.14.1-0ubuntu1
  Architecture: amd64
  CurrentDesktop: Unity
  Date: Mon Apr  7 09:09:37 2014
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2013-04-23 (348 days ago)
  InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130423)
  SourcePackage: systemd
  UpgradeStatus: Upgraded to trusty on 2013-11-11 (146 days ago)

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

Thanks Stéphane, the 2nd point is a reasonable consideration.
Regardless if I could provide a fix to cgmanager for the regression,
certainly it won't be added again as a dependency.

Cheers,


Guilherme

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

We had a potential regression reported after some users installed this package 
from -proposed.
The reports starts on comment #17 in LP: #1303649 .

Summary: users are reporting high CPU loads from both systemd-logind and
cgmanager processes, as well as delays in logins. I'm investigating to
reproduce and understand the issue.

** Tags added: regression-proposed

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

Thanks Dan and Brian.

Just tested: after 1h and more than 5500 SSH sessions, no leaks at all were 
observed.
(As a comparison, testing the "old" version 20.26 I got 1.8 MB of leak in half 
an hour!)

Cheers,


Guilherme

** Tags removed: sts-sru-needed verification-needed verification-needed-trusty
** Tags added: verification-done verification-done-trusty

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  Fix Committed
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp

[Touch-packages] [Bug 1750013] Re: systemd-logind: memory leaks on session's connections (trusty-only)

[Guilherme G. Piccoli]

Thanks Dan.

About cgmanager: if we don't have it installed, it does not affect
memory of systemd-logind tool per se. What happens, IMHO, is even more
severe: we don't free/de-allocate sysfs cgroup paths for sessions. So,
in my tests _without_ cgmanager, after 8000 SSH sessions to my target
machine, I found 8000 folders with some files each at
/sys/fs/cgroup/systemd/user// .

Although it doesn't directly affects systemd-logind memory footprint, it
certainly affects system memory overall. So, in my consideration (given
cgmanager has even code glue added to systemd on Trusty), I'd suggest to
make it a dependency, not sure why it isn't anyway - for me, this cgroup
folders' leak is clearly a bug.

-- 
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1750013

Title:
  systemd-logind: memory leaks on session's connections (trusty-only)

Status in systemd package in Ubuntu:
  Fix Released
Status in systemd source package in Trusty:
  In Progress
Status in systemd source package in Xenial:
  Fix Released
Status in systemd source package in Artful:
  Fix Released
Status in systemd source package in Bionic:
  Fix Released

Bug description:
  Below the SRU request form. Please refer to the Original Description
  to a more comprehensive explanation of the problem observed.

  
  [Impact] 

   * systemd-logind tool is leaking memory at each session connected. The 
   issues happens in systemd from Trusty (14.04) only.

   * Three issues observed:
- systemd-logind is leaking entire sessions, i.e, the sessions are not 
  feeed after they're closed. In order to fix that, we proactively add 
  the sessions to systemd garbage collector (gc) when they are closed. 
  Also, part of the fix is to make cgmanager package a dependency. Refer 
  to comment #1 to a more thorough explanation of the issue and the fix.

- a small memory leak was observed in the session creation logic of 
  systemd-logind. The fix for that is the addition of an appropriate 
  free() call. Refer to comment #2 to more details on the issue and fix.

- another small memory leak was observed in the cgmanager glue code of 
  systemd-logind - this code is only present in this specific Ubuntu 
  release of the package, due to necessary compatibility layer with 
  upstart init system. The fix is to properly call free() in 2 
  functions. Refer to comment #3 to a deep exposition of the issue and 
  the fix.

  
  [Test Case]

   * The basic test-case is to run the following loop from a remote machine:
 while true; do ssh  "whoami"; done

   * It's possible to watch the increase in memory consumption from 
 "systemd-logind" process in the target machine. One can use the
 "ps uax" command to verify the RSS of the process, or count its 
 anonymous pages from /proc//smaps.

  
  [Regression Potential] 

   * Since the fixes are small and not intrusive, the potential for 
 regressions are low. More regression considerations on comments #1, #2 
 and #3 for each fix.

   * A potential small regressson is performance-wise, since now we add 
 sessions to garbage collector proactively.

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

-- 
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help   : https://help.launchpad.net/ListHelp