[Group.of.nepali.translators] [Bug 1930286] Re: Defensics' synopsys fuzzer testing tool cause openssh to segfault
** Changed in: openssh (Ubuntu Xenial) Status: New => In Progress ** Description changed: + [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one (if possible) in order to better understand what the failing test scenario is doing. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) + + [Test plan] + + ** NOT REPRODUCIBLE ON MY SIDE ** + + This seems to be a corner case generated by the Defensics fuzzer test + suite (proprietary software from synopsys). + + That's the only way this could have been reproduced so far. + + [Where problem could occur] + + [Other information] + + Upstream fix: + https://github.com/openssh/openssh-portable/commit/2adbe1e63bc313d03e8e84e652cc623af8ebb163 + + Only Xenial requires the fix: + + # git describe --contains 2adbe1e + V_7_5_P1~7 + + # rmadison openssh + => openssh | 1:7.2p2-4ubuntu2.10 | xenial-updates | source + openssh | 1:7.6p1-4 | bionic | source + openssh | 1:7.6p1-4ubuntu0.3 | bionic-security | source + openssh | 1:7.6p1-4ubuntu0.3 | bionic-updates | source + openssh | 1:7.6p1-4ubuntu0.4 | bionic-proposed | source + openssh | 1:8.2p1-4 | focal| source + openssh | 1:8.2p1-4ubuntu0.2 | focal-security | source + openssh | 1:8.2p1-4ubuntu0.2 | focal-updates| source + openssh | 1:8.3p1-1 | groovy | source + openssh | 1:8.3p1-1ubuntu0.1 | groovy-security | source + openssh | 1:8.3p1-1ubuntu0.1 | groovy-updates | source + openssh | 1:8.4p1-5ubuntu1| hirsute | source + openssh | 1:8.4p1-5ubuntu1| impish | source ** Changed in: openssh (Ubuntu) Status: New => Fix Released ** Changed in: openssh (Ubuntu Xenial) Importance: Undecided => Medium ** Description changed: - [Impact] + [Impact] Here's what has been brought to my attention by a UA customer: * Release: Xenial/16.04LTS * Openssh version: 7.2p2-4ubuntu2.10 * Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) - As of today, I have no access to a reproducer. Still working on getting - access to one (if possible) in order to better understand what the - failing test scenario is doing. + As of today, I have no access to a reproducer. * coredump: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_
[Group.of.nepali.translators] [Bug 1930286] [NEW] Defensics fuzzer testing tool cause openssh to segfault
Public bug reported: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) As of today, I have no access to a reproducer. Still working on getting access to one and better understand what the failing test scenario is doing. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Affects: openssh (Ubuntu) Importance: Undecided Status: New ** Affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: openssh (Ubuntu Xenial) Importance: Undecided Status: New ** Description changed: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 - Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html + Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) + + As of today, I have no access to a reproducer. gdb backtrace: $ gdb $(which sshd) core.cic-1.domain.tld.1612566260.sshd.20731 ... Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `sshd: [net] '. Program terminated with signal SIGSEGV, Segmentation fault. #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 136 ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S: No such file or directory. (gdb) bt #0 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:136 #1 0x7fec25b241db in memcpy (__len=, __src=0x0, __dest=) at /usr/include/x86_64-linux-gnu/bits/string3.h:53 #2 aes_gcm_ctrl (c=0x558a7ae19758, type=, arg=, ptr=0x0) at e_aes.c:1189 #3 0x7fec25b20897 in EVP_CIPHER_CTX_ctrl (ctx=ctx@entry=0x558a7ae19758, type=type@entry=18, arg=arg@entry=-1, ptr=ptr@entry=0x0) at evp_enc.c:619 #4 0x558a7953f54c in cipher_init (cc=cc@entry=0x558a7ae19750, cipher=0x558a797b3ef0 , key=0x0, keylen=32, iv=0x0, ivlen=, do_encrypt=0) at ../cipher.c:336 #5 0x558a7954521a in ssh_set_newkeys (ssh=ssh@entry=0x558a7ae18ef0, mode=mode@entry=0)at ../packet.c:919 #6 0x558a7955ae92 in kex_input_newkeys (type=, seq=, ctxt=0x558a7ae18ef0)at ../kex.c:434 #7 0x558a7954d269 in ssh_dispatch_run (ssh=ssh@entry=0x558a7ae18ef0, mode=0, done=0x558a7ae18278, ctxt=0x558a7ae18ef0) at ../dispatch.c:119 #8 0x558a7954d2b9 in ssh_dispatch_run_fatal (ssh=0x558a7ae18ef0, mode=, done=, ctxt=) at ../dispatch.c:140 #9 0x558a79502770 in do_ssh2_kex () at ../sshd.c:2744 #10 main (ac=, av=) at ../sshd.c:2301 (gdb) ** Description changed: I'm reporting this bug to keep track of it, as of today I'm still collecting informations. Here's what I have gathered so far: Release: Xenial/16.04LTS Openssh version :7.2p2-4ubuntu2.10 Fuzzer tool used: https://www.synopsys.com/software-integrity/security-testing/fuzz-testing.html (proprietary software) - As of today, I have no access to a reproducer. + As of today, I have no access to a reproducer. Still working on getting + access to one and better understand what the failing test
[Group.of.nepali.translators] [Bug 1925351] Re: [sos39][networking] dpdk port flapping observed during sosreport execution
** Description changed: [IMPACT] sosreport networking plugin unconditionally exercise 'ethtool -e'. EEPROM dump collection might hang on specific types of devices, ETHTOOL(8) -e --eeprom-dump Retrieves and prints an EEPROM dump for the specified network device. When raw is enabled, then it dumps the raw EEPROM data to stdout. The length and offset parameters allow dumping certain portions of the EEPROM. Default is to dump the entire EEPROM. [TEST PLAN] * On a xenial system ## Should not execute 'ethtool -e' (New default behaviour) * sosreport -o networking ## Should execute 'ethtool -e'. (Only if sosreport is instructed to do so (AKA former default behaviour)) * sosreport -o networking --plugin-option networking.eepromdump ## Should not execute 'ethtool -e' with -a (if with appropriate tunables in /etc/sos.conf) --- [tunables] networking.eepromdump = off --- ## Should execute 'ethtool -e' with -a (if without appropriate tunables in /etc/sos.conf) [WHERE PROBLEM OCCURS] No problem expected. networking plugin will be gated to prevent 'ethtool -e' to be run by default, so that 'sosreport -o networking' will now no longer execute 'ethtool -e' command. On the other end, if one really want to eepromdump, one can use the 'eepromdump' plugin option as follows: sosreport -o networking --plugin-option networking.eepromdump Yes, we are changing the default behaviour for good reasons as it may produce more harm than good the way it is at the moment, BUT the former behaviour is still available if *REALLY* needed, and after knowing the risk that this could occur. Note: sosreport -a ## Will still execute 'ethtool -e' as it turns all options to 'True'. -a, --alloptions Set all boolean options to True for all enabled plug-ins. Unless one specify the following in /etc/sos.conf: --- [tunables] networking.eepromdump = off --- so 'sosreport -a' with a combination of adding the right tunables in /etc/sos.conf will prevent 'ethtool_e' to be executed. [OTHER INFORMATION] Upstream fix: - https://github.com/sosreport/sos/commit/bc3b7eefa093af150286ad6c345cef6afe282756 + https://github.com/sosreport/sos/commit/a74ef444a72691fab9c65fa679687cc2d6e0fc8c + + $ git describe --contains aca8bd83 + 4.1~44 + + $ rmadison sosreport + => sosreport | 3.9.1-1ubuntu0.16.04.1| xenial-updates + sosreport | 4.1-1ubuntu0.18.04.1 | bionic-updates + sosreport | 4.1-1ubuntu0.20.04.1 | focal-updates + sosreport | 4.1-1ubuntu0.20.10.1 | groovy-updates + sosreport | 4.1-1ubuntu1 | hirsute ** Also affects: sosreport (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Hirsute) Importance: Undecided Status: Fix Released ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Bionic) Status: New => Fix Released ** Changed in: sosreport (Ubuntu Focal) Status: New => Fix Released ** Changed in: sosreport (Ubuntu Groovy) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1925351 Title: [sos39][networking] dpdk port flapping observed during sosreport execution Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Focal: Fix Released Status in sosreport source package in Groovy: Fix Released Status in sosreport source package in Hirsute: Fix Released Bug description: [IMPACT] sosreport networking plugin unconditionally exercise 'ethtool -e'. EEPROM dump collection might hang on specific types of devices, ETHTOOL(8) -e --eeprom-dump Retrieves and prints an EEPROM dump for the specified network device. When raw is enabled, then it dumps the raw EEPROM data to stdout. The length and offset parameters allow dumping certain portions of the EEPROM. Default is to dump the entire EEPROM. [TEST PLAN] * On a xenial system ## Should not execute 'ethtool -e' (New default behaviour) * sosreport -o networking ## Should execute 'ethtool -e'. (Only if sosreport is instructed to do so (AKA former default behaviour)) * sosreport -o networking --plugin-option networking.eepromdump ## Should not execute 'ethtool -e' with -a (if with appropriate tunables in /etc/sos.conf) --- [tunables] networking.eepromdump = off --- ## Should execute 'ethtool -e' with -a (if without appr
[Group.of.nepali.translators] [Bug 1925351] [NEW] [networking] dpdk port flapping observed during sosreport execution
Public bug reported: [IMPACT] sosreport networking plugin unconditionally exercise 'ethtool -e. EEPROM dump collection might hang on specific types of devices, ETHTOOL(8) -e --eeprom-dump Retrieves and prints an EEPROM dump for the specified network device. When raw is enabled, then it dumps the raw EEPROM data to stdout. The length and offset parameters allow dumping certain portions of the EEPROM. Default is to dump the entire EEPROM. [TEST PLAN] * On a xenial system ## Should not execute 'ethtool -e' (Default behaviour) * sosreport -o networking ## Should execute 'ethtool -e'. (Only if sosreport is instructed to do so) * sosreport -o networking --plugin-option networking.eepromdump [WHERE PROBLEM OCCURS] No problem expected. networking plugin will be gated to prevent 'ethtool -e' to be run by default, so that sosreport -o networking will not execute 'ethtool -e' command. On the other end, if one really want to eepromdump, one can use the 'eepromdump' plugin option as follows: sosreport -o networking --plugin-option networking.eepromdump So we are changing the default behaviour, but the former one is still available if *REALLY* needed, and knowing the risk that this can occur. [OTHER INFORMATION] Upstream fix: https://github.com/sosreport/sos/commit/bc3b7eefa093af150286ad6c345cef6afe282756 ** Affects: sosreport (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: sosreport (Ubuntu Xenial) Importance: High Assignee: Eric Desrochers (slashd) Status: In Progress ** Changed in: sosreport (Ubuntu) Status: New => Fix Released ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Xenial) Status: New => In Progress ** Changed in: sosreport (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Xenial) Importance: Undecided => High ** Description changed: [IMPACT] sosreport networking plugin unconditionally exercise 'ethtool -e. EEPROM dump collection might hang on specific types of devices, - ETHTOOL(8) --e --eeprom-dump - Retrieves and prints an EEPROM dump for the specified network device. When raw is enabled, then it dumps the raw EEPROM data to stdout. The length and offset parameters allow dumping certain portions of the EEPROM. Default is to dump the entire EEPROM. - + -e --eeprom-dump + Retrieves and prints an EEPROM dump for the specified network device. When raw is enabled, then it dumps the raw EEPROM data to stdout. The length and offset parameters allow dumping certain portions of the EEPROM. Default is to dump the entire EEPROM. [TEST CASE] * On a xenial system - * sosreport -o networking + * sosreport -o networking ## Should not execute 'ethtool -e' + * sosreport -o networking --plugin-option networking.eepromdump ## Should execute 'ethtool -e'. [WHERE PROBLEM OCCURS] No problem expected. networking plugin will be gated to prevent 'ethtool -e' to be run by default, so that sosreport -o networking will not execute 'ethtool -e' command. On the other end, if one really want to eepromdump, one can use the 'eepromdump' plugin option as follows: sosreport -o networking --plugin-option networking.eepromdump - - So we are changing the default behaviour, but the former one is still available if *REALLY* needed, and knowing the risk that this can occurs. + So we are changing the default behaviour, but the former one is still + available if *REALLY* needed, and knowing the risk that this can occur. [OTHER INFORMATION] - Upstream fix: https://github.com/sosreport/sos/commit/bc3b7eefa093af150286ad6c345cef6afe282756 ** Description changed: [IMPACT] sosreport networking plugin unconditionally exercise 'ethtool -e. EEPROM dump collection might hang on specific types of devices, ETHTOOL(8) -e --eeprom-dump Retrieves and prints an EEPROM dump for the specified network device. When raw is enabled, then it dumps the raw EEPROM data to stdout. The length and offset parameters allow dumping certain portions of the EEPROM. Default is to dump the entire EEPROM. - [TEST CASE] + [TEST PLAN] * On a xenial system - * sosreport -o networking ## Should not execute 'ethtool -e' - * sosreport -o networking --plugin-option networking.eepromdump ## Should execute 'ethtool -e'. + + ## Should not execute 'ethtool -e' (Default behaviour) + * sosreport -o networking + + ## Should execute 'ethtool -e'. (Only if sosreport is instructed to do so) + * sosreport -o networking --plugin-option networking.eepromdump + * sosreport -a --plugin-option n
[Group.of.nepali.translators] [Bug 1892275] Re: [sync][sru] sos upstream 4.0
** Changed in: sosreport (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: sosreport (Ubuntu Bionic) Assignee: Eric Desrochers (slashd) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1892275 Title: [sync][sru] sos upstream 4.0 Status in sosreport: Unknown Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: Won't Fix Status in sosreport source package in Focal: Fix Released Bug description: [Impact] The sos team is pleased to announce the release of sos-4.0. This is a major version release that represents a significant change to the sos project, new features, and bug fixes. https://github.com/sosreport/sos/releases/tag/4.0 [Test Case] * Install sosreport 4.0-1* package ** Test new main binary 'sos' and it's former binary still present 'sosreport' (e.g. sosreport -a --all-logs & sos report -a --all-logs) ** Test new features: *** sos-collect (Collect sosreport from multiple node simultaneously) *** sos-clean || sos-mask (It's aim is to scrub potentially sensitive information from sosreports in a consistent manner, beyond the obfuscation done by plugins already.) Replacement of the former project called 'soscleaner' which no longer deliver development. [Regression Potential] Main binary formerly known as 'sosreport' has been officially renamed to 'sos' but 'sosreport' still exist and has been carried over for now to help to transition for package maintainer. No impact nor behavioural change for existing user. They are welcome to use the new binary or the former one as they wish. -rwxr-xr-x 1 root root 1057 Aug 25 16:24 /usr/bin/sosreport -rwxr-xr-x 1 root root 596 Aug 25 16:24 /usr/bin/sos New functionalities has been added which could lead to possible bugs ,since they are fairly new addition, if not already caught by the travis/autopkg tests but if a problem arise it will be limited to the components itself and won't affect the main behaviour (which by the way remain the same, which is to collect a tarball using 'sosreport' or/and now 'sos report' subcommand. To resume, main known existing behaviour remain the same but some new features which are limited/independent to each other has been added to offer new features such as : * sos collect is a new sub command in this release, and is an integration of the standalone sos-collector project, with the aim being to collect sosreports from multiple systems simultaneously. Note that this sub-command requires python3-pexpect to be available. If the module is not available, sos collect will abort with an appropriate error message * sos clean, also available as sos mask, is a newly added sub-command in this release and is an implementation of the standalone soscleaner project. Its aim is to scrub potentially sensitive information from sosreports in a consistent manner, beyond the obfuscation done by plugins already. https://wiki.ubuntu.com/SosreportUpdates sos4.0 now enforces archives to be stored in /var/tmp. A debian patch has been made to continue to store in /tmp (current behaviour) to stay align with current behaviour but also because debian's systemd implementation doesn't provide a tmpfiles.d cleaner for /var/tmp. So /tmp remains the default "tmp-dir" location. During the testing, I found a py38 incompatibility related to dictionnary order, that I fixed upstream and cherry-pick for Ubuntu release having py38 found in : d/p/0002-fix-dict-order- py38-incompatibility.patch. Upstream commit: https://github.com/sosreport/sos/pull/2207/commits/86dfd99931ac0199895cf5e41711fc9b1ab6feaf The old config (/etc/sos.conf) contents will not be carried over after update. Users will have to modify the new file (/etc/sos/sos.conf) instead (if needed). [Other Information] https://github.com/sosreport/sos/releases/tag/4.0 [Original Description] https://github.com/sosreport/sos/releases/tag/4.0 Major changes Sos has been redesigned to provide functionality beyond the well known report data collection usage. It has been updated to provide more functionality via sub-commands. A new sos binary has replaced the former sosreport binary as the main entry point for the utility. sos report is now used to generate sosreport tarballs. A sosreport binary is maintained as a redirection point and will now invoke sos report. sos collect formally brings sos-collector into the main sos project, and is used to collect sosreports from multiple nodes simultaneously. A sos-collector
[Group.of.nepali.translators] [Bug 1892275] Re: [sync][sru] sos upstream 4.0
** Changed in: sosreport (Ubuntu Xenial) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1892275 Title: [sync][sru] sos upstream 4.0 Status in sosreport: Unknown Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Focal: Fix Released Bug description: [Impact] The sos team is pleased to announce the release of sos-4.0. This is a major version release that represents a significant change to the sos project, new features, and bug fixes. https://github.com/sosreport/sos/releases/tag/4.0 [Test Case] * Install sosreport 4.0-1* package ** Test new main binary 'sos' and it's former binary still present 'sosreport' (e.g. sosreport -a --all-logs & sos report -a --all-logs) ** Test new features: *** sos-collect (Collect sosreport from multiple node simultaneously) *** sos-clean || sos-mask (It's aim is to scrub potentially sensitive information from sosreports in a consistent manner, beyond the obfuscation done by plugins already.) Replacement of the former project called 'soscleaner' which no longer deliver development. [Regression Potential] Main binary formerly known as 'sosreport' has been officially renamed to 'sos' but 'sosreport' still exist and has been carried over for now to help to transition for package maintainer. No impact nor behavioural change for existing user. They are welcome to use the new binary or the former one as they wish. -rwxr-xr-x 1 root root 1057 Aug 25 16:24 /usr/bin/sosreport -rwxr-xr-x 1 root root 596 Aug 25 16:24 /usr/bin/sos New functionalities has been added which could lead to possible bugs ,since they are fairly new addition, if not already caught by the travis/autopkg tests but if a problem arise it will be limited to the components itself and won't affect the main behaviour (which by the way remain the same, which is to collect a tarball using 'sosreport' or/and now 'sos report' subcommand. To resume, main known existing behaviour remain the same but some new features which are limited/independent to each other has been added to offer new features such as : * sos collect is a new sub command in this release, and is an integration of the standalone sos-collector project, with the aim being to collect sosreports from multiple systems simultaneously. Note that this sub-command requires python3-pexpect to be available. If the module is not available, sos collect will abort with an appropriate error message * sos clean, also available as sos mask, is a newly added sub-command in this release and is an implementation of the standalone soscleaner project. Its aim is to scrub potentially sensitive information from sosreports in a consistent manner, beyond the obfuscation done by plugins already. https://wiki.ubuntu.com/SosreportUpdates sos4.0 now enforces archives to be stored in /var/tmp. A debian patch has been made to continue to store in /tmp (current behaviour) to stay align with current behaviour but also because debian's systemd implementation doesn't provide a tmpfiles.d cleaner for /var/tmp. So /tmp remains the default "tmp-dir" location. During the testing, I found a py38 incompatibility related to dictionnary order, that I fixed upstream and cherry-pick for Ubuntu release having py38 found in : d/p/0002-fix-dict-order- py38-incompatibility.patch. Upstream commit: https://github.com/sosreport/sos/pull/2207/commits/86dfd99931ac0199895cf5e41711fc9b1ab6feaf The old config (/etc/sos.conf) contents will not be carried over after update. Users will have to modify the new file (/etc/sos/sos.conf) instead (if needed). [Other Information] https://github.com/sosreport/sos/releases/tag/4.0 [Original Description] https://github.com/sosreport/sos/releases/tag/4.0 Major changes Sos has been redesigned to provide functionality beyond the well known report data collection usage. It has been updated to provide more functionality via sub-commands. A new sos binary has replaced the former sosreport binary as the main entry point for the utility. sos report is now used to generate sosreport tarballs. A sosreport binary is maintained as a redirection point and will now invoke sos report. sos collect formally brings sos-collector into the main sos project, and is used to collect sosreports from multiple nodes simultaneously. A sos-collector binary is maintained as a redirection point and will invoke sos collect. This means the standalone sos-collector utility will no longer be independently developed. sos clean formally brings soscleaner-like functionality into the main sos p
[Group.of.nepali.translators] [Bug 1906302] Re: [plugin][apt] Move unattended-upgrades log collection
** Description changed: - This commit move the collection of unattended-upgrades from 'logs' plugin to 'apt' plugin: + [Impact] + + Having u-u logs collection inside the apt plugin make more sense + (instead of logs plugin) as it is using apt functionalities and python + modules such as apt, apt_inst, apt_pkg. + + u-u is a mechanism to automatically install security upgrades on + Debian/Ubuntu. It is enabled by default at installation. + + 'sos' philosophy is that each plugin should be taken care of its own + logs. + + [Test case] + + * Deploy Ubuntu (A container will do) + * Run sosreport and make sure the systemd plugin is executed + ** sosreport -o apt + * Look the content of the generated tarball under 'path_to_sosreport/var/log/unattended-upgrades/' + + and under 'path_to_sosreport/sos_logs/sos.log' for the execution log of the 'apt' plugin: + sos.log:2021-02-06 11:23:55,257 INFO: [plugin:apt] collecting path '/var/log/unattended-upgrades/. + + + [Where problem could occur] + + If a problem have to occur, it will only be impacting the apt plugin + itself, not the core functionalities of 'sos' nor its other plugins. + + A third party vendor might have to break the habit to assume that the + 'logs' plugin will take care of the 'u-u' logs, and that 'apt' is the + way to move forward now. + + [Other information] https://github.com/sosreport/sos/commit/9f057fb43a949cabb496d06506a59e411ef17812 ** Description changed: [Impact] Having u-u logs collection inside the apt plugin make more sense (instead of logs plugin) as it is using apt functionalities and python modules such as apt, apt_inst, apt_pkg. u-u is a mechanism to automatically install security upgrades on Debian/Ubuntu. It is enabled by default at installation. 'sos' philosophy is that each plugin should be taken care of its own logs. [Test case] * Deploy Ubuntu (A container will do) * Run sosreport and make sure the systemd plugin is executed - ** sosreport -o apt + ** sosreport -o apt * Look the content of the generated tarball under 'path_to_sosreport/var/log/unattended-upgrades/' - and under 'path_to_sosreport/sos_logs/sos.log' for the execution log of the 'apt' plugin: - sos.log:2021-02-06 11:23:55,257 INFO: [plugin:apt] collecting path '/var/log/unattended-upgrades/. + * And under 'path_to_sosreport/sos_logs/sos.log' for the execution log + of the 'apt' plugin: + sos.log:2021-02-06 11:23:55,257 INFO: [plugin:apt] collecting path + '/var/log/unattended-upgrades/. [Where problem could occur] If a problem have to occur, it will only be impacting the apt plugin itself, not the core functionalities of 'sos' nor its other plugins. A third party vendor might have to break the habit to assume that the 'logs' plugin will take care of the 'u-u' logs, and that 'apt' is the way to move forward now. [Other information] https://github.com/sosreport/sos/commit/9f057fb43a949cabb496d06506a59e411ef17812 ** Changed in: sosreport (Ubuntu Groovy) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Groovy) Status: New => In Progress ** Changed in: sosreport (Ubuntu Focal) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Focal) Status: New => In Progress ** Changed in: sosreport (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: sosreport (Ubuntu Bionic) Status: New => In Progress ** Changed in: sosreport (Ubuntu Bionic) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1906302 Title: [plugin][apt] Move unattended-upgrades log collection Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Focal: In Progress Status in sosreport source package in Groovy: In Progress Status in sosreport source package in Hirsute: Fix Released Bug description: [Impact] Having u-u logs collection inside the apt plugin make more sense (instead of logs plugin) as it is using apt functionalities and python modules such as apt, apt_inst, apt_pkg. u-u is a mechanism to automatically install security upgrades on Debian/Ubuntu. It is enabled by default at installation. 'sos' philosophy is that each plugin should be taken care of its own logs. [Test case] * Deploy Ubuntu (A container will do) * Run sosreport an
[Group.of.nepali.translators] [Bug 1914372] Re: Ubuntu packages affected by CVE-2020-24553
** Description changed: [Impact] Go before 1.14.8 and 1.15.x before 1.15.1 allows XSS because text/html is the default for CGI/FCGI handlers that lack a Content-Type header. [Test Case] Described as POC at https://www.redteam-pentesting.de/en/advisories/rt- sa-2020-004/-inconsistent-behavior-of-gos-cgi-and-fastcgi-transport-may- lead-to-cross-site-scripting: 1. Use the snippet of CGI go code provided and run it: go run poc.go 2. Run nginx with the config provided to forward the FastCGI calls to the go program. 3. curl -i -o - http://localhost:8000 4. Observe the output. In an affected golang build the output will say: Content-Type: text/html (...) while in the fixed version it should recognize the content type correctly as: Content-Type: image/png [Where problems could occur] * It may affect deployments where go apps are used as CGI scripts - if the setup was incorrectly relying on hard-coded content type it may require fixing it. [Other Info] + * It has been specifically backported upstream in release 1.14 series: + https://go.googlesource.com/go/+/8fcee8abbea1bb959c63a6944f9ddf490a97f802 + + $ git tag --contains 8fcee8abbe + go1.14.10 + go1.14.11 + go1.14.12 + go1.14.13 + go1.14.14 + go1.14.15 + go1.14.8 + go1.14.9 + + * The fix is present in golang-1.15 for hirsute and groovy. ** Also affects: golang-1.15 (Ubuntu) Importance: Undecided Status: New ** Changed in: golang-1.15 (Ubuntu) Status: New => Fix Released ** Changed in: golang-1.14 (Ubuntu Hirsute) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: golang-1.14 (Ubuntu Groovy) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: golang-1.14 (Ubuntu Focal) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: golang-1.10 (Ubuntu Bionic) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: golang-1.10 (Ubuntu Xenial) Assignee: (unassigned) => Dariusz Gadomski (dgadomski) ** Changed in: golang-1.14 (Ubuntu Hirsute) Status: New => In Progress ** Changed in: golang-1.14 (Ubuntu Groovy) Status: New => In Progress ** Changed in: golang-1.14 (Ubuntu Focal) Status: New => In Progress ** Changed in: golang-1.10 (Ubuntu Xenial) Status: New => In Progress ** Changed in: golang-1.10 (Ubuntu Bionic) Status: New => In Progress ** Description changed: [Impact] Go before 1.14.8 and 1.15.x before 1.15.1 allows XSS because text/html is the default for CGI/FCGI handlers that lack a Content-Type header. [Test Case] Described as POC at https://www.redteam-pentesting.de/en/advisories/rt- sa-2020-004/-inconsistent-behavior-of-gos-cgi-and-fastcgi-transport-may- lead-to-cross-site-scripting: 1. Use the snippet of CGI go code provided and run it: go run poc.go 2. Run nginx with the config provided to forward the FastCGI calls to the go program. 3. curl -i -o - http://localhost:8000 4. Observe the output. In an affected golang build the output will say: Content-Type: text/html (...) while in the fixed version it should recognize the content type correctly as: Content-Type: image/png [Where problems could occur] * It may affect deployments where go apps are used as CGI scripts - if the setup was incorrectly relying on hard-coded content type it may require fixing it. [Other Info] - * It has been specifically backported upstream in release 1.14 series: + * It has been specifically backported upstream in release 1.14 series (Starting w/ 1.14.8) as follows: https://go.googlesource.com/go/+/8fcee8abbea1bb959c63a6944f9ddf490a97f802 $ git tag --contains 8fcee8abbe go1.14.10 go1.14.11 go1.14.12 go1.14.13 go1.14.14 go1.14.15 go1.14.8 go1.14.9 - * The fix is present in golang-1.15 for hirsute and groovy. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1914372 Title: Ubuntu packages affected by CVE-2020-24553 Status in golang-1.14 package in Ubuntu: In Progress Status in golang-1.15 package in Ubuntu: Fix Released Status in golang-1.10 source package in Xenial: In Progress Status in golang-1.10 source package in Bionic: In Progress Status in golang-1.14 source package in Focal: In Progress Status in golang-1.14 source package in Groovy: In Progress Status in golang-1.14 source package in Hirsute: In Progress Bug description: [Impact] Go before 1.14.8 and 1.15.x before 1.15.1 allows XSS because text/html is the default for CGI/FCGI handlers that lack a Content- Type header. [Test Case] Described as POC at https://www.redteam-pentesting.de/en/advisories /rt-sa-2020-004/-inconsistent-behavior-of-gos-cgi-and-fastcgi- transport-may-lead-to-cross-site-scrip
[Group.of.nepali.translators] [Bug 1907676] Re: segmentation fault when opening fd
@julian, thanks for the quick reply. Will do. ** Changed in: python-apt (Ubuntu) Status: New => Fix Released ** Description changed: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. - [Where problem could occurs] + # dak scenario: + dak crashes with a segmentation fault in python3-apt when processing + uploads or processing the NEW queue on ftp-master; and also on my + playground server (used to generate the backtrace). + + [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1907676 Title: segmentation fault when opening fd Status in python-apt package in Ubuntu: Fix Released Status in python-apt source package in Xenial: New Status in python-apt source package in Bionic: New Status in python-apt source package in Focal: New Status in python-apt source package in Groovy: New Status in python-apt package in Debian: Unknown Bug description: [Impact] USN-4668-1 introduced a regression in python-apt when using certain APIs with a file handle. [Test case] # Landscape scenario: 1) On the Landscape server, create a package profile that installs a single package, 'hello' is enough. 2) On the Landscape server, apply the package profile to a client 3) On the Landscape client, verify that there is no segfault message on '/var/log/kern.log' 4) On the Landscape server, verify that the activity to apply the package profile ends with success. Step 3) would show a segfault and step 4), the activity would stay 'In Progress' forever. # dak scenario: dak crashes with a segmentation fault in python3-apt when processing uploads or processing the NEW queue on ftp-master; and also on my playground server (used to generate the backtrace). [Where problems could occurs] [Other info] See Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=977000 Fix: https://salsa.debian.org/apt-team/python-apt/-/commit/3d9af5f196ad6a6c6973ac699a15888d21a9bb52 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/python-apt/+bug/1907676/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1907262] Re: raid10: discard leads to corrupted file system
@voidlily, I would assume you are running a HWE kernel (v4.15) on Xenial. If it's the case, fixing the Bionic kernel will generate a new HWE (4.15) kernel for Xenial. ** Changed in: linux (Ubuntu Xenial) Status: New => Invalid ** Changed in: linux (Ubuntu Trusty) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system Status in linux package in Ubuntu: Confirmed Status in linux source package in Trusty: Invalid Status in linux source package in Xenial: Invalid Status in linux source package in Bionic: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: Fix Committed Bug description: Seems to be closely related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578 After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126 the fstrim command triggered by fstrim.timer causes a severe number of mismatches between two RAID10 component devices. This bug affects several machines in our company with different HW configurations (All using ECC RAM). Both, NVMe and SATA SSDs are affected. How to reproduce: - Create a RAID10 LVM and filesystem on two SSDs mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2 pvcreate -ff -y /dev/md0 vgcreate -f -y VolGroup /dev/md0 lvcreate -n root-L 100G -ay -y VolGroup mkfs.ext4 /dev/VolGroup/root mount /dev/VolGroup/root /mnt - Write some data, sync and delete it dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M sync rm /mnt/data.raw - Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0): cat /sys/block/md0/md/mismatch_cnt - Trigger the bug fstrim /mnt - Re-Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*1): cat /sys/block/md0/md/mismatch_cnt After investigating this issue on several machines it *seems* that the first drive does the trim correctly while the second one goes wild. At least the number and severity of errors found by a USB stick live session fsck.ext4 suggests this. To perform the single drive evaluation the RAID10 was started using a single drive at once: mdadm --assemble /dev/md127 /dev/nvme0n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root vgchange -a n /dev/VolGroup mdadm --stop /dev/md127 mdadm --assemble /dev/md127 /dev/nvme1n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root When starting these fscks without -n, on the first device it seems the directory structure is OK while on the second device there is only the lost+found folder left. Side-note: Another machine using HWE kernel 5.4.0-56 (after using -53 before) seems to have a quite similar issue. Unfortunately the risk/regression assessment in the aforementioned bug is not complete: the workaround only mitigates the issues during FS creation. This bug on the other hand is triggered by a weekly service (fstrim) causing severe file system corruption. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1907262] Re: raid10: discard leads to corrupted file system
** Also affects: linux (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: linux (Ubuntu Trusty) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1907262 Title: raid10: discard leads to corrupted file system Status in linux package in Ubuntu: Confirmed Status in linux source package in Trusty: New Status in linux source package in Xenial: New Status in linux source package in Bionic: Fix Committed Status in linux source package in Focal: Fix Committed Status in linux source package in Groovy: Fix Committed Bug description: Seems to be closely related to https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1896578 After updating the Ubuntu 18.04 kernel from 4.15.0-124 to 4.15.0-126 the fstrim command triggered by fstrim.timer causes a severe number of mismatches between two RAID10 component devices. This bug affects several machines in our company with different HW configurations (All using ECC RAM). Both, NVMe and SATA SSDs are affected. How to reproduce: - Create a RAID10 LVM and filesystem on two SSDs mdadm -C -v -l10 -n2 -N "lv-raid" -R /dev/md0 /dev/nvme0n1p2 /dev/nvme1n1p2 pvcreate -ff -y /dev/md0 vgcreate -f -y VolGroup /dev/md0 lvcreate -n root-L 100G -ay -y VolGroup mkfs.ext4 /dev/VolGroup/root mount /dev/VolGroup/root /mnt - Write some data, sync and delete it dd if=/dev/zero of=/mnt/data.raw bs=4K count=1M sync rm /mnt/data.raw - Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (should be 0): cat /sys/block/md0/md/mismatch_cnt - Trigger the bug fstrim /mnt - Re-Check the RAID device echo check >/sys/block/md0/md/sync_action - After finishing (see /proc/mdstat), check the mismatch_cnt (probably in the range of N*1): cat /sys/block/md0/md/mismatch_cnt After investigating this issue on several machines it *seems* that the first drive does the trim correctly while the second one goes wild. At least the number and severity of errors found by a USB stick live session fsck.ext4 suggests this. To perform the single drive evaluation the RAID10 was started using a single drive at once: mdadm --assemble /dev/md127 /dev/nvme0n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root vgchange -a n /dev/VolGroup mdadm --stop /dev/md127 mdadm --assemble /dev/md127 /dev/nvme1n1p2 mdadm --run /dev/md127 fsck.ext4 -n -f /dev/VolGroup/root When starting these fscks without -n, on the first device it seems the directory structure is OK while on the second device there is only the lost+found folder left. Side-note: Another machine using HWE kernel 5.4.0-56 (after using -53 before) seems to have a quite similar issue. Unfortunately the risk/regression assessment in the aforementioned bug is not complete: the workaround only mitigates the issues during FS creation. This bug on the other hand is triggered by a weekly service (fstrim) causing severe file system corruption. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1907262/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1905579] Re: parted crashes with invalid pointer on resizepart on focal
Xenial and Bionic doesn't have such end_input pointer in do_resizepart(). ** Changed in: parted (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: parted (Ubuntu Xenial) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1905579 Title: parted crashes with invalid pointer on resizepart on focal Status in parted package in Ubuntu: Fix Released Status in parted source package in Xenial: Won't Fix Status in parted source package in Bionic: Won't Fix Status in parted source package in Focal: In Progress Status in parted source package in Groovy: In Progress Status in parted source package in Hirsute: Fix Released Bug description: [Impact] Parted is crashing (core dumping) during resize operation, while changing the end position of a partition. [Test Case] root@ubuntu-focal:~# parted /dev/sda resizepart 1 100% Warning: Partition /dev/sda1 is being used. Are you sure you want to continue? Yes/No? yes End? [42.9GB]? free(): invalid pointer Aborted (core dumped) [Where problems could occur] As per resize documentation: "Note that this does not modify any filesystem present in the partition." "When growing a partition you will want to grow the filesystem afterwards" FS-wise the resize operation won't try to take action on the FS itself. It would need to be done by the admin as a separate step. If any problem arise, it will be limited to the resize functionality of parted. In this case, the impact would be ~ similar to the actual parted state (before this SRU), and one won't be able to resize as requested. [Other Info] https://git.savannah.gnu.org/cgit/parted.git/commit/?id=ca845aeeddb17343c9289816833ca352f7c0d87b # Upstream repo: git describe --tags ca845ae v3.3-5-gca845ae # Ubuntu $ rmadison parted parted | 3.2-15ubuntu0.1 | xenial-updates parted | 3.2-20ubuntu0.2 | bionic-updates parted | 3.3-4 | focal parted | 3.3-4 | groovy parted | 3.3-4 | hirsute [Original Description] parted crashes with invalid pointer on resizepart on focal root@ubuntu-focal:~# parted /dev/sda resizepart 1 100% Warning: Partition /dev/sda1 is being used. Are you sure you want to continue? Yes/No? yes End? [42.9GB]? free(): invalid pointer Aborted (core dumped) Discussion: https://www.mail-archive.com/bug- par...@gnu.org/msg04962.html Fix: https://github.com/bcl/parted/commit/883813c365482d06d05a1998e066792c48156f23 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/parted/+bug/1905579/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1903733] Re: Out of memory issue for websocket client
** Description changed: + [Impact] + + + [Test Case] + + + [Where problems could occur] + + + [Other Info] + + $ git remote -v + originhttps://github.com/tornadoweb/tornado.git (fetch) + originhttps://github.com/tornadoweb/tornado.git (push) + + $ git describe --contains 20becca3 + v5.1.0b1~28^2~1 + + $ rmadison python3-tornardo + => python3-tornado | 4.2.1-1ubuntu3 | xenial + python3-tornado | 4.5.3-1 | bionic/universe + => python3-tornado | 4.5.3-1ubuntu0.1| bionic-updates/universe + python3-tornado | 6.0.3+really5.1.1-3 | focal/universe + python3-tornado | 6.0.4-2 | groovy/universe + python3-tornado | 6.0.4-3 | hirsute/universe + python3-tornado | 6.1.0-1 | hirsute-proposed/universe + + + [Original Description] + Tornado has no 'flow control' for websockets. A websocket will receive data as fast as it can, and store the data in a deque. If that data is not consumed as fast as it is written, then that deque will grow in size indefinitely, ultimately leading to a memory error and killing the process. Fix is to use a Queue. Read and get messages from the queue on the client side. Patch file [0] Commit history [1] GitHub [2] Issue [3] [0] https://patch-diff.githubusercontent.com/raw/tornadoweb/tornado/pull/2351.patch [1] https://github.com/tornadoweb/tornado/pull/2351/commits [2] https://github.com/tornadoweb/tornado [3] https://github.com/tornadoweb/tornado/issues/2341 Will provide test setup at a later point ** Also affects: python-tornado (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: python-tornado (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: python-tornado (Ubuntu Hirsute) Importance: Undecided Assignee: Heather Lemon (hypothetical-lemon) Status: New ** Also affects: python-tornado (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: python-tornado (Ubuntu Focal) Importance: Undecided Status: New ** Changed in: python-tornado (Ubuntu Hirsute) Status: New => Fix Released ** Changed in: python-tornado (Ubuntu Groovy) Status: New => Fix Released ** Changed in: python-tornado (Ubuntu Focal) Status: New => Fix Released ** Changed in: python-tornado (Ubuntu Hirsute) Assignee: Heather Lemon (hypothetical-lemon) => (unassigned) ** Changed in: python-tornado (Ubuntu Bionic) Assignee: (unassigned) => Heather Lemon (hypothetical-lemon) ** Changed in: python-tornado (Ubuntu Xenial) Assignee: (unassigned) => Heather Lemon (hypothetical-lemon) ** Description changed: [Impact] - [Test Case] - [Where problems could occur] + [Other Info] - [Other Info] + Upstream commit(s): + https://github.com/tornadoweb/tornado/pull/2351/commits/20becca336caae61cd24f7afba0e177c0a210c70 $ git remote -v originhttps://github.com/tornadoweb/tornado.git (fetch) originhttps://github.com/tornadoweb/tornado.git (push) $ git describe --contains 20becca3 v5.1.0b1~28^2~1 $ rmadison python3-tornardo - => python3-tornado | 4.2.1-1ubuntu3 | xenial - python3-tornado | 4.5.3-1 | bionic/universe - => python3-tornado | 4.5.3-1ubuntu0.1| bionic-updates/universe - python3-tornado | 6.0.3+really5.1.1-3 | focal/universe - python3-tornado | 6.0.4-2 | groovy/universe - python3-tornado | 6.0.4-3 | hirsute/universe - python3-tornado | 6.1.0-1 | hirsute-proposed/universe - + => python3-tornado | 4.2.1-1ubuntu3 | xenial + python3-tornado | 4.5.3-1 | bionic/universe + => python3-tornado | 4.5.3-1ubuntu0.1| bionic-updates/universe + python3-tornado | 6.0.3+really5.1.1-3 | focal/universe + python3-tornado | 6.0.4-2 | groovy/universe + python3-tornado | 6.0.4-3 | hirsute/universe + python3-tornado | 6.1.0-1 | hirsute-proposed/universe [Original Description] Tornado has no 'flow control' for websockets. A websocket will receive data as fast as it can, and store the data in a deque. If that data is not consumed as fast as it is written, then that deque will grow in size indefinitely, ultimately leading to a memory error and killing the process. Fix is to use a Queue. Read and get messages from the queue on the client side. Patch file [0] Commit history [1] GitHub [2] Issue [3] [0] https://patch-diff.githubusercontent.com/raw/tornadoweb/tornado/pull/2351.patch [1] https://github.com/tornadoweb/tornado/pull/2351/commits [2] https://github.com/tornadoweb/tornado [3] https://github.com/tornadoweb/tornado/issues/2341 Will provide test setup at a later point -- You received this bug notification because you are a member of नेपाली
[Group.of.nepali.translators] [Bug 1893109] Re: Backport - collect ceph balancer and pr-autoscale status
@CJ, Could you produce a debdiff ? I'll sponsor it. ** Tags added: seg sts ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Groovy) Status: New => In Progress ** Changed in: sosreport (Ubuntu Groovy) Assignee: (unassigned) => Chris Johnston (cjohnston) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1893109 Title: Backport - collect ceph balancer and pr-autoscale status Status in sosreport: Fix Released Status in sosreport package in Ubuntu: In Progress Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: New Status in sosreport source package in Groovy: In Progress Bug description: It would be nice to collect: ceph osd pool autoscale-status ceph balancer status Upstream report: https://github.com/sosreport/sos/issues/2211 Upstream commit: https://github.com/sosreport/sos/commit/52f4661e2b594134b98e2967b02cc860d7963fef To manage notifications about this bug go to: https://bugs.launchpad.net/sosreport/+bug/1893109/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1888854] Re: update ovs plugin
*** This bug is a duplicate of bug 1892275 *** https://bugs.launchpad.net/bugs/1892275 sosreport 4.0-1~ubuntu0.20.04.1 (currently found in focal-proposed) will contain the above plugin update and more. https://launchpad.net/ubuntu/+source/sosreport/4.0-1~ubuntu0.20.04.1 - Eric ** This bug has been marked a duplicate of bug 1892275 [sync][sru] sos upstream 4.0 -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/154 Title: update ovs plugin Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: In Progress Bug description: [Impact] The Openvswitch plugin is a little outdated. sosreport is in constant development, and since 3.9.1 got released a few plugin updates, adds, ... has been merged upstream (Some changes has been reported and/or submitted by Canonical employees). Some changes will be beneficial for the Canonical support team in order to help troubleshooting UA customer and may also serve for other 3rd party vendor. [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection (which is part of the autopkgtest (d/test/simple.sh) now. * https://wiki.ubuntu.com/SosreportUpdates [Regression Potential] Sosreport, as of today, has ~300 plugins that are all configured differently and configured to run under certain conditions. We can't test all possible scenarios. All we can do is identify the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...). With that being said, it is definitely possible that certain plugins may not work as expected, but the risk will be very low (e.g. not collecting the desired information) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionalities of sosreport. [Other Information] [Original description] Backport OVS changes into sosreport (ubuntu) c2bf52d7 [openvswitch] poll dpdk status from ifaces and ports 96c69385 [openvswitch] pull cfm, qos, and bond info 4703cbaa [openvswitch] Add LACP stats 27ef2569 [openvswitch] List important dpdk related directories bc0c0245 [openvswitch] ensure -t 5 for ovs-vsctl where needed eb145d94 [openvswitch] capture all datapath data 798fc4a5 [openvswitch] pull additional bridge information e1b474af [openvswitch] add support for OpenFlow 1.4 and 1.5 ac1ebcc8 [openvswitch] only check mempool information for dpdk-init=true To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/154/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1888403] Re: sosreport plugins updates
*** This bug is a duplicate of bug 1892275 *** https://bugs.launchpad.net/bugs/1892275 sosreport 4.0-1~ubuntu0.20.04.1 (currently found in focal-proposed) will contain the above plugin update and more. https://launchpad.net/ubuntu/+source/sosreport/4.0-1~ubuntu0.20.04.1 - Eric ** This bug has been marked a duplicate of bug 1892275 [sync][sru] sos upstream 4.0 -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1888403 Title: sosreport plugins updates Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: In Progress Status in sosreport source package in Groovy: Fix Released Bug description: [Impact] sosreport is in constant development, and since 3.9.1 got released a few plugin updates, adds, ... has been merged upstream (Some of the changes has been reported and/or submitted by Canonical employees). Some changes will be beneficial for the Canonical support team in order to help troubleshooting UA customer and may also serve for other 3rd party vendor. [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection (which is part of the autopkgtest (d/test/simple.sh) now. * https://wiki.ubuntu.com/SosreportUpdates [Regression Potential] Sosreport, as of today, has ~300 plugins that are all configured differently and configured to run under certain conditions. We can't test all possible scenarios. All we can do is identify the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...). With that being said, it is definitely possible that certain plugins may not work as expected, but the risk will be very low (e.g. not collecting the desired information) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionalities of sosreport. [Other Information] [Original description] List of plugins update under evaluation (so far) for next sosreport SRU: (The list is susceptible to change as it is still an evaluation as we speak) 4be4e4ea [drbd] Add new plugin for DRBD 43b4a9ab [maas] use maas-region instead of deprecated maas-region-admin 31e04678 [networking] collect iptables when proper kernel modules loaded 591cd4cf [networking] Small change to produce more-useful, numbered ufw rule status e8b38048 [systemd] update trigger with better generic file check e9d71c78 [ubuntu] support status command update 3a50987a [sar] Extend command sadf to get more data out of sar 9d572eb4 [kubernetes] Adding support for alternate Ubuntu deployments b34edec3 [pacemaker] Fix scrubbing when password contains an equal sign To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1888403/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1888403] [NEW] sosreport plugins updates
Public bug reported: List of plugins update under evaluation (so far) for next sosreport SRU: (The list is susceptible to change as it is still an evaluation as we speak) 4be4e4ea [drbd] Add new plugin for DRBD 43b4a9ab [maas] use maas-region instead of deprecated maas-region-admin c2bf52d7 [openvswitch] poll dpdk status from ifaces and ports 96c69385 [openvswitch] pull cfm, qos, and bond info 4703cbaa [openvswitch] Add LACP stats 27ef2569 [openvswitch] List important dpdk related directories bc0c0245 [openvswitch] ensure -t 5 for ovs-vsctl where needed eb145d94 [openvswitch] capture all datapath data 798fc4a5 [openvswitch] pull additional bridge information e1b474af [openvswitch] add support for OpenFlow 1.4 and 1.5 ac1ebcc8 [openvswitch] only check mempool information for dpdk-init=true 31e04678 [networking] collect iptables when proper kernel modules loaded 591cd4cf [networking] Small change to produce more-useful, numbered ufw rule status e8b38048 [systemd] update trigger with better generic file check e9d71c78 [ubuntu] support status command update 3a50987a [sar] Extend command sadf to get more data out of sar 9d572eb4 [kubernetes] Adding support for alternate Ubuntu deployments b34edec3 [pacemaker] Fix scrubbing when password contains an equal sign ** Affects: sosreport (Ubuntu) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Focal) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Groovy) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Tags: seg sts ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Groovy) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Focal) Importance: Undecided Status: New ** Tags added: seg sts ** Description changed: List of plugins update under evaluation (so far) for next sosreport SRU: 4be4e4ea [drbd] Add new plugin for DRBD 43b4a9ab [maas] use maas-region instead of deprecated maas-region-admin c2bf52d7 [openvswitch] poll dpdk status from ifaces and ports 96c69385 [openvswitch] pull cfm, qos, and bond info 4703cbaa [openvswitch] Add LACP stats 27ef2569 [openvswitch] List important dpdk related directories bc0c0245 [openvswitch] ensure -t 5 for ovs-vsctl where needed eb145d94 [openvswitch] capture all datapath data 798fc4a5 [openvswitch] pull additional bridge information e1b474af [openvswitch] add support for OpenFlow 1.4 and 1.5 ac1ebcc8 [openvswitch] only check mempool information for dpdk-init=true 31e04678 [networking] collect iptables when proper kernel modules loaded 591cd4cf [networking] Small change to produce more-useful, numbered ufw rule status - 1417827a [maas] Add snap support to maas plugin ** Changed in: sosreport (Ubuntu Groovy) Status: New => In Progress ** Changed in: sosreport (Ubuntu Groovy) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Groovy) Importance: Undecided => Medium ** Description changed: List of plugins update under evaluation (so far) for next sosreport SRU: + + (The list is susceptible to change as it is still an evaluation as we + speak) 4be4e4ea [drbd] Add new plugin for DRBD 43b4a9ab [maas] use maas-region instead of deprecated maas-region-admin c2bf52d7 [openvswitch] poll dpdk status from ifaces and ports 96c69385 [openvswitch] pull cfm, qos, and bond info 4703cbaa [openvswitch] Add LACP stats 27ef2569 [openvswitch] List important dpdk related directories bc0c0245 [openvswitch] ensure -t 5 for ovs-vsctl where needed eb145d94 [openvswitch] capture all datapath data 798fc4a5 [openvswitch] pull additional bridge information e1b474af [openvswitch] add support for OpenFlow 1.4 and 1.5 ac1ebcc8 [openvswitch] only check mempool information for dpdk-init=true 31e04678 [networking] collect iptables when proper kernel modules loaded 591cd4cf [networking] Small change to produce more-useful, numbered ufw rule status ** Description changed: List of plugins update under evaluation (so far) for next sosreport SRU: (The list is susceptible to change as it is still an evaluation as we speak) 4be4e4ea [drbd] Add new plugin for DRBD 43b4a9ab [maas] use maas-region instead of deprecated maas-region-admin c2bf52d7 [openvswitch] poll dpdk status from ifaces and ports 96c69385 [openvswitch] pull cfm, qos, and bond info 4703cbaa [openvswitch] Add LACP stats 27ef2569 [openvswitch] List important dpdk related directories bc0c0245 [openvswitch] ensure -t 5 for ovs-vs
[Group.of.nepali.translators] [Bug 1865212] Re: simple.sh to be run as part of the autopkgtests
** Changed in: sosreport (Ubuntu Xenial) Status: Won't Fix => In Progress ** Changed in: sosreport (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1865212 Title: simple.sh to be run as part of the autopkgtests Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Eoan: Fix Released Bug description: [Impact] I'd like to provide more testing/regression detection to the actual autopkgtest for sosreport. [Test Case] The acceptance criteria: * The autopkgtest infra picks the simple.sh * Executes/runs it * and that the script passes all verifications. [Regression potential] simple.sh is generating sosreport(s) archive using various parameters/arguments and look for its success. That will enhance the detection of potential regression inside sosreport to them early. One regression I can think of is simple.sh providing false positive and/or that the script always fails, but it is unlikely to happen because I've been using it manually for quite some time now and it has been proven to work well. If pending sru doesn't reveal any regression then we are all good. autopkgtest log can also be use as a proof that simple.sh did run as expected. [Original Description] Reporting this bug as a reminder for me to start working at eventually include simple.sh[0] to be run as part of the sosreport's autopkgtest. Autopkgtest restriction definitions requirement: needs-root [0] - A quick port of the travis tests to bash, requires root https://github.com/sosreport/sos/blob/master/tests/simple.sh To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1865212/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1884293] Re: Update to maintenance release v3.9.1
** Changed in: sosreport (Ubuntu Xenial) Status: Won't Fix => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1884293 Title: Update to maintenance release v3.9.1 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Eoan: Fix Released Status in sosreport source package in Focal: Fix Released Bug description: [Impact] sosreport 3.9.1 is now released. It would be great to find sosreport v3.9.1 in supported stable releases, and active development release considering the fact that the releases (especially LTSes) are going to be supported for a couple of years. Sosreport is widely used by Canonical support team (and mission critical) to troubleshoot UA (Ubuntu Advantage) customer, partners, community users, and so on. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) - v3.9 (LP: #1862830) [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection (which is part of the autopkgtest (d/test/simple.sh) now. * Perform some dog fooding test routines (--all-logs, --upload, looking sosreport archive content, ... and so on) * https://wiki.ubuntu.com/SosreportUpdates [Regression Potential] Sosreport, as of today, has 300 plugins that are all configured differently and configured to run under certain conditions. We can't test all possible scenarios. All we can do is identify the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...). With that being said, it is definitely possible that certain plugins may not work as expected, but the risk will be very low (e.g. not collecting the desired information) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionalities of sosreport. [Other Information] * Release note: https://github.com/sosreport/sos/releases/tag/3.9.1 [Original Description] 3.9.1 is now found in Debian unstable and Groovy (Current Active Devel Release) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1884293/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1886494] Re: sosreport does not correctly enable the maas plugin for a snap install
** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Xenial) Importance: Undecided => Low ** Changed in: sosreport (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Xenial) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1886494 Title: sosreport does not correctly enable the maas plugin for a snap install Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: Fix Committed Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Released Bug description: [Impact] sosreport doesn't exercise the MAAS plugin if it is installed as a SNAP. Only work if installed as a DEB package. [Test Case] * snap install maas * sosreport -a * Looking the sosreport archive content and validate that MAAS information haven't been collected (e.g. /path_to_sosreport/sos_commands/maas) [Regression Potential] No regression expected. If a regression happens it will only be isolated to the plugin itself. It won't affect/impact other plugin nor sosreport core functionalities. Worst case scenario, the MAAS plugin won't be exercised as expected, and one would need to request MAAS information manually. https://wiki.ubuntu.com/SosreportUpdates [Other Info] Upstream commit: - [maas] Add snap support to maas plugin - https://github.com/sosreport/sos/commit/1417827a [Original Description] Installing maas via snap on a focal machine (in my case lxd container) following: sudo snap install maas-test-db sudo snap install maas sudo maas init region --database-uri maas-test-db:/// Then running sosreport, sosreport does not correctly enable the maas plugin. I tested with version 3.9.1-1ubuntu0.20.04.1 of sosreport and also the upstream package from source. Here are the results: root@testing:/sos# dpkg -l | grep sosreport ii sosreport 3.9.1-1ubuntu0.20.04.1 amd64 Set of tools to gather troubleshooting data from a system root@testing:/sos# sosreport -l | grep maas maas inactive Ubuntu Metal-As-A-Service root@testing:/sos# ./bin/sosreport -l | grep maas maas Ubuntu Metal-As-A-Service maas.profile-name The name with which you will later refer to this remote maas.url The URL of the remote API maas.credentials The credentials, also known as the API key As you can see the version of sosreport from the package lists the maas plugin as inactive but from source it is enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1886494/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1884293] Re: Update to maintenance release v3.9.1
** Tags removed: verification-needed verification-needed-bionic verification-needed-focal ** Tags added: verification-done verification-done-bionic verification-done-focal ** Changed in: sosreport (Ubuntu Xenial) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1884293 Title: Update to maintenance release v3.9.1 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: Fix Committed Status in sosreport source package in Eoan: Fix Committed Status in sosreport source package in Focal: Fix Committed Bug description: [Impact] sosreport 3.9.1 is now released. It would be great to find sosreport v3.9.1 in supported stable releases, and active development release considering the fact that the releases (especially LTSes) are going to be supported for a couple of years. Sosreport is widely used by Canonical support team (and mission critical) to troubleshoot UA (Ubuntu Advantage) customer, partners, community users, and so on. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) - v3.9 (LP: #1862830) [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection (which is part of the autopkgtest (d/test/simple.sh) now. * Perform some dog fooding test routines (--all-logs, --upload, looking sosreport archive content, ... and so on) * https://wiki.ubuntu.com/SosreportUpdates [Regression Potential] Sosreport, as of today, has 300 plugins that are all configured differently and configured to run under certain conditions. We can't test all possible scenarios. All we can do is identify the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...). With that being said, it is definitely possible that certain plugins may not work as expected, but the risk will be very low (e.g. not collecting the desired information) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionalities of sosreport. [Other Information] * Release note: https://github.com/sosreport/sos/releases/tag/3.9.1 [Original Description] 3.9.1 is now found in Debian unstable and Groovy (Current Active Devel Release) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1884293/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1883320] Re: [kvm] change check_enabled to /dev/kvm
** Changed in: sosreport (Ubuntu Bionic) Status: New => In Progress ** Also affects: sosreport (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Eoan) Status: New => In Progress ** Changed in: sosreport (Ubuntu Eoan) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Bionic) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Eoan) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Bionic) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1883320 Title: [kvm] change check_enabled to /dev/kvm Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: In Progress Status in sosreport source package in Groovy: Fix Released Bug description: [Impact] The KVM plugin get triggered in a container (e.g lxd) because of "/sys/module/kvm" inheritance from the kernel host. Not only it's a waste of sosreport time, but running it inside a container may unintentionally reveal details from its host. Which is a undesired behaviour. Switching to /dev/kvm, is more appropriate and follow current standard as used by tool such as cpu-checker (kvm-ok) for instance. And taking benefit of this change to get rid of the check_enabled() overwrite in favour of using "files=" trigger. [Test Case] * Run sosreport inside a LXD container * The container will contain KVM information from its host (Iff its host as KVM installed) [Regression Potential] We only change the way the plugin gets triggered to use a most conventional way. If /dev/kvm exist, then exercise the kvm plugin. No regression expected, but worse case scenario, it will only be isolated and impact the KVM plugin to collect data properly as expected. It won't cause any harm to others plugins nor sosreport core functionalities itself. The commit went through some upstream Travis testing which used a shell script called "simple.sh" to verify sosreport collection. BTW, this same exact script is part of the sosreport autopkgtest, and will be run as part of the SRU to push this change. [Other Information] * Upstream bug: https://github.com/sosreport/sos/issues/2062 * Upstream commit: https://github.com/sosreport/sos/pull/2063/commits/dc58a038c18ff3e838d883d4b31aad5dac7ea9e1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1883320/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1884293] Re: Update to maintenance release v3.9.1
** Changed in: sosreport (Ubuntu Bionic) Status: Confirmed => In Progress ** Also affects: sosreport (Ubuntu Eoan) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Eoan) Status: New => In Progress ** Changed in: sosreport (Ubuntu Eoan) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Eoan) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1884293 Title: Update to maintenance release v3.9.1 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Confirmed Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: In Progress Bug description: [Impact] sosreport 3.9.1 is now released. It would be great to find sosreport v3.9.1 in supported stable releases, and active development release considering the fact that the releases (especially LTSes) are going to be supported for a couple of years. Sosreport is widely used by Canonical support team (and mission critical) to troubleshoot UA (Ubuntu Advantage) customer, partners, community users, and so on. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) - v3.9 (LP: #1862830) [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection (which is part of the autopkgtest (d/test/simple.sh) now. * Perform some dog fooding test routines (--all-logs, --upload, looking sosreport archive content, ... and so on) [Regression Potential] Sosreport, as of today, has 300 plugins that are all configured differently and configured to run under certain conditions. We can't test all possible scenarios. All we can do is identify the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...). With that being said, it is definitely possible that certain plugins may not work as expected, but the risk will be very low (e.g. not collecting the desired information) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionalities of sosreport. [Other Information] * Release note: https://github.com/sosreport/sos/releases/tag/3.9.1 [Original Description] 3.9.1 is now found in Debian unstable and Groovy (Current Active Devel Release) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1884293/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1883320] Re: [kvm] change check_enabled to /dev/kvm
Fixed in Groovy's sosreport (3.9.1-1ubuntu1) uploaded earlier today. * New 3.9.1 upstream release. (LP: #1884293) This maintenance release includes: - New plugins: sos_extras, ovirt_engine_backup, console, validation_framework. - lxd plugin collections have been overhauled. - Fixed handling of the namespace pattern for the networking plugin. - A basic path is now defined in Policy for all subclasses. Plugin API Enhancements: - Enablement checks have been extended to include architecture constraints. - SoSPredicate has been extended to include architecture constraints, as well as negative constraints for all elements. - Plugins will now capture service status information for all services defined in the services class attr. Further release information and tarballs are available at: - https://github.com/sosreport/sos/releases/tag/3.9.1 * Former patches now fixed upstream: - d/p/0001-unittest-py3-fix.patch - d/p/0002-lxd-drop-db-collection-and-introduce-lxd-buginfo.patch * Other specific modifications: - d/p/0001-lshw-command.patch - d/p/0002-lds-substitute-oidc-conf.patch ==> - d/p/0003-kvm-change-trigger-to-dev-kvm.patch <== ** Changed in: sosreport (Ubuntu Groovy) Status: In Progress => Fix Released ** Changed in: sosreport (Ubuntu Focal) Status: New => In Progress ** Changed in: sosreport (Ubuntu Focal) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Focal) Importance: Undecided => Medium -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1883320 Title: [kvm] change check_enabled to /dev/kvm Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Focal: In Progress Status in sosreport source package in Groovy: Fix Released Bug description: [Impact] The KVM plugin get triggered in a container (e.g lxd) because of "/sys/module/kvm" inheritance from the kernel host. Not only it's a waste of sosreport time, but running it inside a container may unintentionally reveal details from its host. Which is a undesired behaviour. Switching to /dev/kvm, is more appropriate and follow current standard as used by tool such as cpu-checker (kvm-ok) for instance. And taking benefit of this change to get rid of the check_enabled() overwrite in favour of using "files=" trigger. [Test Case] * Run sosreport inside a LXD container * The container will contain KVM information from its host (Iff its host as KVM installed) [Regression Potential] We only change the way the plugin gets triggered to use a most conventional way. If /dev/kvm exist, then exercise the kvm plugin. No regression expected, but worse case scenario, it will only be isolated and impact the KVM plugin to collect data properly as expected. It won't cause any harm to others plugins nor sosreport core functionalities itself. The commit went through some upstream Travis testing which used a shell script called "simple.sh" to verify sosreport collection. BTW, this same exact script is part of the sosreport autopkgtest, and will be run as part of the SRU to push this change. [Other Information] * Upstream bug: https://github.com/sosreport/sos/issues/2062 * Upstream commit: https://github.com/sosreport/sos/pull/2063/commits/dc58a038c18ff3e838d883d4b31aad5dac7ea9e1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1883320/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1884293] [NEW] Update to maintenance release v3.9.1
Public bug reported: [Impact] sosreport 3.9.1 is now released. It would be great to find sosreport v3.9.1 in supported stable releases, and active development release considering the fact that the releases (especially LTSes) are going to be supported for a couple of years. Sosreport is widely used by Canonical support team to troubleshoot UA (Ubuntu Advantage) customer, other vendors and community users. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) - v3.9 (LP: #1862830) [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection (which is part of the autopkgtest (d/test/simple.sh) now. * Perform some dog fooding test routines (--all-logs, --upload, lookg sosreport archive content, ... and so on) [Regression Potential] Sosreport, as of today, has 300 plugins that are all configured differently and configured to run under certain conditions. We can't test all possible scenarios. All we can do is identify the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...). With that being said, it is definitely possible that certain plugins may not work as expected, but the risk will be very low (e.g. not collecting the desired information) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionalities of sosreport. [Other Information] * Release note: https://github.com/sosreport/sos/releases/tag/3.9.1 [Original Description] 3.9.1 is now found in Debian unstable and Groovy (Current Active Devel Release) ** Affects: sosreport (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: sosreport (Ubuntu Xenial) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: sosreport (Ubuntu Bionic) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: sosreport (Ubuntu Focal) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Tags: seg sts ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Focal) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu) Status: New => Fix Released ** Changed in: sosreport (Ubuntu Xenial) Status: New => In Progress ** Changed in: sosreport (Ubuntu Bionic) Status: New => In Progress ** Changed in: sosreport (Ubuntu Focal) Status: New => In Progress ** Changed in: sosreport (Ubuntu Focal) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Bionic) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Focal) Importance: Undecided => Medium ** Description changed: [Impact] - sosreport 3.9 is now released. + sosreport 3.9.1 is now released. - It would be great to find sosreport v3.9 in supported stable releases, - and active development release considering the fact that the releasea - (especially LTSes) are going to be supported for a couple of years - still. + It would be great to find sosreport v3.9.1 in supported stable releases, + and active development release considering the fact that the releases + (especially LTSes) are going to be supported for a couple of years. - Sosreport is widely use by Canonical support team to troubleshoot UA + Sosreport is widely used by Canonical support team to troubleshoot UA (Ubuntu Advantage) customer, other vendors and community users. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) - v3.9 (LP: #1862830) [Test Case] * Install sosreport * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. - $ grep -v "INFO:" sos_logs/sos.log + $ grep -v "
[Group.of.nepali.translators] [Bug 1869465] Re: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp'
** Also affects: makedumpfile (Ubuntu) Importance: Undecided Status: New ** Changed in: makedumpfile (Ubuntu Groovy) Importance: Undecided => Medium ** Changed in: makedumpfile (Ubuntu Groovy) Status: New => In Progress ** Changed in: makedumpfile (Ubuntu Groovy) Assignee: (unassigned) => Ioanna Alifieraki (joalif) ** Tags removed: sts-sponsor-mfo-and-slashd ** Tags added: sts-sponsor-mfo -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1869465 Title: Kdump-Tools: Makedumpfile Failed, Falling Back To 'Cp' Status in linux package in Ubuntu: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in linux source package in Xenial: In Progress Status in makedumpfile source package in Xenial: New Status in linux source package in Bionic: In Progress Status in makedumpfile source package in Bionic: New Status in linux source package in Eoan: In Progress Status in makedumpfile source package in Eoan: New Status in linux source package in Focal: In Progress Status in makedumpfile source package in Focal: New Status in linux source package in Groovy: In Progress Status in makedumpfile source package in Groovy: In Progress Status in linux package in Debian: New Bug description: [Impact] On some arm systems makedumpfile fails to translate virtual to physical addresses properly. This may result in makedumpfile looping forever exhausting all memory, or translating a virtual address to an invalid physical address and then failing and falling back to cp. The reason it cannot resolve some addresses is because the PMD mask is wrong. When physical address mask allows up to 48bits pmd mask should allow the same, currently pmd mask is set to 40bits (see commit [1]). Commit [1] fixes this bug. [Test Case] To hit this bug you need a system that needs physical addresses over 1TB. This may be either because you have a lot of memory or because the firmware mapped some memory above 1TB for some reason [1]. A user hit this bug because firmware mapped memory above 1TB and provided a dump so I could reproduce the bug when running makedumpfile on the dump. [Regression Potential] This commit changes the PMD_SECTION_MASK for arm64. So any regression potential would only affect arm64 systems. In addition PMD_SECTION_MASK is used in translation from virtual to physical addresses and therefore any regression would happen during this process. [Other] [1] https://github.com/makedumpfile/makedumpfile/commit/7242ae4cb5288df626f464ced0a8b60fd669100b When testing kdump on Ubuntu 18.04.4 (arm64) GA kernel, makedumpfile fails. The test steps are as follows: # echo 1> / proc / sys / kernel / sysrq # echo c> / proc / sysrq-trigger The logs are as follows: kdump-tools[646]: starting kdump-tools: * running makedumpfile -c -d 31 /proc/vmcore /var/crash/202003251128/dump-incomplete kdump-tools[646]: readpage_elf: Attempt to read non-existent page at 0x0 kdump-tools[646]: readmem: type_addr: 1, addr:ff0, size:8 kdump-tools[646]: vaddr_to_paddr_arm64: Can't read pud kdump-tools[646]: readmem: Can't convert a virtual address(9e653690) to physical address. kdump-tools[646]: readmem: type_addr: 0, addr:9e653690, size:1032 kdump-tools[646]: validate_mem_section: Can't read mem_section array. kdump-tools[646]: get_mem_section: Could not validate mem_section. kdump-tools[646]: get_mm_sparsemem: Can't get the address of mem_section. kdump-tools[646]: makedumpfile Failed. kdump-tools[646]: * kdump-tools: makedumpfile failed, falling back to 'cp' But when I use the HWE kernel, I find that there is no such problem. The HEW kernel version: 5.3.0-42-generic To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1869465/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1875927] Re: add support for phys_port_name attribute in Xenial/16.04LTS
** Changed in: systemd (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: systemd (Ubuntu Xenial) Assignee: Eric Desrochers (slashd) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1875927 Title: add support for phys_port_name attribute in Xenial/16.04LTS Status in systemd package in Ubuntu: Fix Released Status in systemd source package in Xenial: Won't Fix Bug description: [Impact] In Xenial/16.04LTS, one can't generate network interface name from "phys_port_name" attribute. "phys_port_name" indicates the interface physical port name within the NIC. [Test Case] Check that udev (systemd-udevd) provides the phys_port_name property Tests should be done on kernel versions: v4.15 (HWE) # cat /sys/class/net//phys_port_name yyy Look if interface name contains the 'phys_port_name': $ ip link show 3: ens3nyyy: ... [Regression Potential] * This piece of code is already in place in Bionic (systemd) and late. AFAICT, nothing has been reported since then with regards to this feature. * phys_port_name kernel support has been introduced in v4.1, but none of the current v4.4 Xenial kernel drivers uses it (minus rocker which is a test bed software switch for devel work on switchdev, it has no real function) # Xenial - kernel v4.4 config-4.4.0-142-generic:# CONFIG_NET_SWITCHDEV is not set No drivers uses the phys_port_name method at all + NET_SWITCHDEV is not even turned on. # Xenial HWE - kernel v4.15 config-4.15.0-99-generic:CONFIG_NET_SWITCHDEV=y Meaning if a regression arise, it will be limited to the HWE kernel (v4.15) and to the "Ethernet switch device driver model (switchdev)": mlx5 mlxsw bnxt sfc (solarflar) -- drivers/net/ethernet: -- broadcom/bnxt/bnxt_vfr.c: .ndo_get_phys_port_name = bnxt_vf_rep_get_phys_port_name broadcom/bnxt/bnxt.c: .ndo_get_phys_port_name = bnxt_get_phys_port_name cavium/liquidio/lio_vf_rep.c: .ndo_get_phys_port_name = lio_vf_rep_phys_port_name, mellanox/mlx5/core/en_rep.c: .ndo_get_phys_port_name = mlx5e_rep_get_phys_port_name, mellanox/mlxsw/switchx2.c:.ndo_get_phys_port_name = mlxsw_sx_port_get_phys_port_name, mellanox/mlxsw/spectrum.c:.ndo_get_phys_port_name = mlxsw_sp_port_get_phys_port_name, netronome/nfp/nfp_net_repr.c: .ndo_get_phys_port_name = nfp_port_get_phys_port_name, netronome/nfp/nfp_net_common.c: .ndo_get_phys_port_name = nfp_port_get_phys_port_name, rocker/rocker_main.c: .ndo_get_phys_port_name = rocker_port_get_phys_port_name, sfc/efx.c:.ndo_get_phys_port_name = efx_get_phys_port_name, -- # On other more specific kernels the regression potential can be expanded to virtio-net driver as well. # cloud-init may taint the result as it renames switchdev(s) after systemd at first initialization (even without the phys_port_name support) as follows: (Testing on a sfc card / server deployed by MAAS) syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 36.199674] sfc :08:00.1 ens1f1: renamed from eth1 ## systemd syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 37.128236] sfc :08:00.0 ens1f0: renamed from eth0 ## systemd syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.653460] sfc :08:00.0 ens1f0np0: renamed from ens1f0 ## cloud-init syslog:May 20 22:12:43 OBFUSCATED_HOST kernel: [ 84.697177] sfc :08:00.1 ens1f1np1: renamed from ens1f1 ## cloud-init cloud-init.log:2020-05-20 22:04:53,980 - util.py[DEBUG]: Running command ['ip', 'link', 'set', 'ens1f0', 'name', 'ens1f0np0'] with allowed return codes [0] (shell=False, capture=True) cloud-init.log:2020-05-20 22:04:54,016 - util.py[DEBUG]: Running command ['ip', 'link', 'set', 'ens1f1', 'name', 'ens1f1np1'] with allowed return codes [0] (shell=False, capture=True) systemd: ... OBFUSCATED_HOST systemd[1]: sys-subsystem-net-devices-ens1f1.device: Dev sys-subsystem-net-devices-ens1f1.device appeared twice with different sysfs paths /sys/devices/pci:00/:00:03.0/:08:00.1/net/ens1f1 and /sys/devices/pci:00/:00:03.0/:08:00.1/net/ens1f1np1 # 1 concern was raise here by ddstreet: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/1 Here's the result of the test I have performed: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1875927/comments/5 This change indeed rename existing switchdev interfaces to add the 'phys_port_name' (if any) into it. I'm afraid this will be a non- acceptable behaviour change in stable release and won't be SRU'able. M
[Group.of.nepali.translators] [Bug 1874526] Re: [landscape] Substitute oidc conf in service file
After talking to simpoir (lds maintainer) lds 19.10 is not available in Xenial so no OIDC available. ** Changed in: sosreport (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: sosreport (Ubuntu Xenial) Assignee: Eric Desrochers (slashd) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1874526 Title: [landscape] Substitute oidc conf in service file Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: Fix Committed Status in sosreport source package in Eoan: Fix Committed Status in sosreport source package in Focal: Fix Committed Status in sosreport source package in Groovy: Fix Released Bug description: [Impact] Landscape has added the ability to connect to OIDC. The plugin should be updated to obfuscate the sensitive information. https://docs.ubuntu.com/landscape/en/onprem-auth#openid-connect- support [Test Case] * Install sosreport * Install landscape-client and/or landscape-server (to make sure sosreport's landscape plugin will be triggered) from the Landscape PPA -> https://launchpad.net/~landscape * Manually append or create files: "/etc/landscape/service.conf" & "/etc/landscape/service.conf.old" (No need to have a fully functionnal landscape setup, just the package installed (for triggering purposes) and then you can create and add the parameter by hand) * Add the following in both "/etc/landscape/service.conf" & "/etc/landscape/service.conf.old": oidc-client-secret = secret-test oidc-client-id = id-test * Execute sosreport "sosreport -a" * Make sure landscape plugin was exercise. * Extract archive and make sure both "oidc-client-id" & "oidc-client-secret" are subsituted in files "/etc/landscape/service.conf" & "/etc/landscape/service.conf.old" as it should (if present). Expected result (path_to_sosreport/etc/landscape/service.conf*) oidc-client-secret = [] oidc-client-id = [] Extra testing (sanity check): * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection. https://raw.githubusercontent.com/sosreport/sos/master [Regression] No regression expected, we don't change/impact core functionnalities nor affect other plugins. If something happens it will be isolate to the landscape plugin itself only. Worse case the OID substitution won't work as expected (corner case) and will reveal OID sensible information, but it is very unlikely to happen as it will be intensively tested during the testing phase, and the substitute mechanism in place has been proven to work for the same configuration files in the landscape plugin already. [Other Informations] Upstream bug: https://github.com/sosreport/sos/issues/2023 Upstream PR: https://github.com/sosreport/sos/pull/2025 Upstream commit: https://github.com/sosreport/sos/pull/2025/commits/0c4d821e26e1206a0b99f427b572931ba2fd9bb5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1874526/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1875927] [NEW] add support for phys_port_name attribute in Xenial/16.04LTS
Public bug reported: It has been brought to my attention that systemd in Xenial/16.04LTS doesn't have support for phys_port_name[0] attribute. The support has been first introduced in systemd version "232" via: https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184 https://github.com/systemd/systemd/pull/4506 Bionic and late have the necessary bits ( systemd >232), but not Xenial (229)[1] Support for "phys_port_name" has been first introduced in the kernel with v4.1[2] [0] - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net - https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html - https://www.kernel.org/doc/Documentation/networking/switchdev.txt [1] # git systemd/systemd git describe --contains 4887b656c22af059d4e833de7b56544f24951184 v232~15 # rmadison => systemd | 229-4ubuntu21.27 | xenial-updates systemd | 237-3ubuntu10.39 | bionic-updates systemd | 240-6ubuntu5.8 | disco-updates systemd | 242-7ubuntu3.7 | eoan-updates systemd | 245.4-4ubuntu3 | focal systemd | 245.4-4ubuntu3 | groovy [2] https://github.com/torvalds/linux/commit/db24a9044ee1 $ git describe --contains db24a9044ee1 v4.1-rc1 ** Affects: systemd (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: systemd (Ubuntu Xenial) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Tags: sts ** Also affects: systemd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: systemd (Ubuntu) Status: New => Fix Released ** Tags added: sts ** Changed in: systemd (Ubuntu Xenial) Status: New => Confirmed ** Changed in: systemd (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: systemd (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: systemd (Ubuntu Xenial) Status: Confirmed => In Progress ** Description changed: It has been brought to my attention that systemd in Xenial/16.04LTS doesn't have support for phys_port_name[0] attribute. The support has been first introduced in systemd version "232" via: https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184 + https://github.com/systemd/systemd/pull/4506 Bionic and late have the necessary bits ( systemd >232), but not Xenial (229). - [0] + [0] - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net - https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html ** Description changed: It has been brought to my attention that systemd in Xenial/16.04LTS doesn't have support for phys_port_name[0] attribute. The support has been first introduced in systemd version "232" via: https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184 https://github.com/systemd/systemd/pull/4506 Bionic and late have the necessary bits ( systemd >232), but not Xenial - (229). + (229)[1] [0] - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net - https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html + + [1] + # git systemd/systemd + git describe --contains 4887b656c22af059d4e833de7b56544f24951184 + v232~15 + + # rmadison + => systemd | 229-4ubuntu21.27 | xenial-updates + systemd | 237-3ubuntu10.39 | bionic-updates + systemd | 240-6ubuntu5.8 | disco-updates + systemd | 242-7ubuntu3.7 | eoan-updates + systemd | 245.4-4ubuntu3 | focal + systemd | 245.4-4ubuntu3 | groovy ** Description changed: It has been brought to my attention that systemd in Xenial/16.04LTS doesn't have support for phys_port_name[0] attribute. The support has been first introduced in systemd version "232" via: https://github.com/systemd/systemd/commit/4887b656c22af059d4e833de7b56544f24951184 https://github.com/systemd/systemd/pull/4506 Bionic and late have the necessary bits ( systemd >232), but not Xenial (229)[1] [0] - https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-net - https://www.freedesktop.org/software/systemd/man/systemd.net-naming-scheme.html + - https://www.kernel.org/doc/Documentation/networking/switchdev.txt [1] # git systemd/systemd git describe --contains 4887b656c22af059d4e833de7b56544f24951184 v232~15 # rmadison - => systemd | 229-4ubuntu21.27 | xenial-updates - systemd | 237-3ubuntu10.39 | bionic-updates - systemd | 240-6ubuntu5.8 | disco-updates - systemd | 242-7ubuntu3.7 | eoan-updates - systemd | 245.4-4ubuntu3 | focal - systemd | 245.4-4ubuntu3 | groovy + => systemd | 229-4ubuntu21.27 | xenial-updates + systemd | 237-3ubuntu10.39 | bionic-updates + systemd | 240-6ubuntu5.8 | disco-updates + systemd | 242-7ubuntu3.7 | eoan-updates + systemd | 245.4-
[Group.of.nepali.translators] [Bug 1865212] Re: simple.sh to be run as part of the autopkgtests
** Changed in: sosreport (Ubuntu Bionic) Assignee: (unassigned) => Heather Lemon (hypothetical-lemon) ** Changed in: sosreport (Ubuntu Bionic) Status: New => In Progress ** Changed in: sosreport (Ubuntu Xenial) Status: New => Won't Fix ** Changed in: sosreport (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: sosreport (Ubuntu Xenial) Importance: Undecided => Low -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1865212 Title: simple.sh to be run as part of the autopkgtests Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Eoan: In Progress Bug description: [Wishlist] Reporting this bug as a reminder for me to start working at eventually include simple.sh[0] to be run as part of the sosreport's autopkgtest. Autopkgtest restriction definitions requirement: needs-root [0] - A quick port of the travis tests to bash, requires root https://github.com/sosreport/sos/blob/master/tests/simple.sh To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1865212/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1874526] Re: [landscape] Substitute oidc conf in service file
** Also affects: sosreport (Ubuntu Groovy) Importance: High Assignee: Eric Desrochers (slashd) Status: In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1874526 Title: [landscape] Substitute oidc conf in service file Status in sosreport package in Ubuntu: In Progress Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: In Progress Status in sosreport source package in Groovy: In Progress Bug description: [Impact] Landscape has added the ability to connect to OIDC. The plugin should be updated to obfuscate the sensitive information. https://docs.ubuntu.com/landscape/en/onprem-auth#openid-connect- support [Test Case] * Install sosreport * Run sosreport in a Landscape environment (client and server) * Extract archive and look at the content of sos_commands/landscape and most importantly make sure both "oidc-client-id" & "oidc-client-secret" are subsitute in files "/etc/landscape/service.conf" & "/etc/landscape/service.conf.old" as it should (if present). Extra testing: * Look under "sos_reports" for full report. * Look under "sos_logs" for warnings/errors. $ grep -v "INFO:" sos_logs/sos.log * Run "simple.sh": A quick port of the travis tests to bash. Generating various type of sosreports collection. https://raw.githubusercontent.com/sosreport/sos/master [Regression] No regression expected, we don't change/impact core functionnalities nor affect other plugins. If something happens it will be isolate to the landscape plugin itself only. Worse case the OID substitution won't work as expected (corner case) and will reveal OID sensible information, but it is very unlikely to happen as it will be intensively tested during the testing phase, and the substitute mechanism in place has been proven to work for the same configuration files in the landscape plugin already. [Other Informations] Upstream bug: https://github.com/sosreport/sos/issues/2023 Upstream PR: https://github.com/sosreport/sos/pull/2025 Upstream commit: https://github.com/sosreport/sos/pull/2025/commits/0c4d821e26e1206a0b99f427b572931ba2fd9bb5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1874526/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd
Nicolas, can you please produce a 'groovy' 20.10 debdiff ? Thanks ** Also affects: rabbitmq-server (Ubuntu Groovy) Importance: Low Assignee: Nicolas Bock (nicolasbock) Status: In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1874075 Title: rabbitmq-server startup timeouts differ between SysV and systemd Status in rabbitmq-server package in Ubuntu: In Progress Status in rabbitmq-server source package in Xenial: In Progress Status in rabbitmq-server source package in Bionic: In Progress Status in rabbitmq-server source package in Eoan: Won't Fix Status in rabbitmq-server source package in Focal: In Progress Status in rabbitmq-server source package in Groovy: In Progress Bug description: The startup timeouts were recently adjusted and synchronized between the SysV and systemd startup files. https://github.com/rabbitmq/rabbitmq-server-release/pull/129 The new startup files should be included in this package. [Impact] After starting the RabbitMQ server process, the startup script will wait for the server to start by calling `rabbitmqctl wait` and will time out after 10 s. The startup time of the server depends on how quickly the Mnesia database becomes available and the server will time out after `mnesia_table_loading_retry_timeout` ms times `mnesia_table_loading_retry_limit` retries. By default this wait is 30,000 ms times 10 retries, i.e. 300 s. The mismatch between these two timeout values might lead to the startup script failing prematurely while the server is still waiting for the Mnesia tables. This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the `--timeout` option into the startup script. The default value for this timeout is set to 10 minutes (600 seconds). This change also updates the systemd service file to match the timeout values between the two service management methods. [Test Case] In a clustered setup with two nodes, A and B. 1. create queue on A 2. shut down B 3. shut down A 4. boot B The broker on B will wait for A. The systemd service will wait for 10 seconds and then fail. Boot A and the rabbitmq-server process on B will complete startup. [Regression Potential] This change alters the behavior of the startup scripts when the Mnesia database takes long to become available. This might lead to failures further down the service dependency chain. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1871494] Re: add lshw cmd into sosreport's hardware plugin
Heather, can you please produce a 'groovy' 20.10 debdiff ? Thanks ** Also affects: sosreport (Ubuntu Groovy) Importance: Wishlist Assignee: Heather Lemon (hypothetical-lemon) Status: In Progress ** Changed in: sosreport (Ubuntu Groovy) Importance: Wishlist => Low -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1871494 Title: add lshw cmd into sosreport's hardware plugin Status in sosreport package in Ubuntu: In Progress Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: In Progress Status in sosreport source package in Groovy: In Progress Bug description: [Impact] lshw(1) https://linux.die.net/man/1/lshw * lshw is a small tool to extract detailed information on the hardware configuration of the machine. It can report exact memory configuration, firmware version, mainboard configuration, CPU version and speed, cache configuration, bus speed, etc. on DMI-capable x86 or IA-64 systems and on some PowerPC machines (PowerMac G4 is known to work). * Adding 'lshw' will help Canonical or third-party vendor using the sosreport package to not having to ask 'lshw' in addition to sosreport. This is a frequent command to run to troubleshoot/debug things * Including hardware information is a helpful debug step to determine issues found [Test Case] * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, since this is specifically listing hardware informations. * For all distros: - install sosreport from the proposed pocket - run sosreport with default settings `sudo sosreport -a --config sos.conf` Or to just test hardware plugin `sosreport -o hardware --config sos.conf` * Extract archive and look at contents - untar report file in /tmp/ - cd /sos_commands/hardware/ - less lshw -- the ouput is information about the system's hardware - look under "sos_logs" for warnings/errors. - look under "sos_reports" for full report. * Run `simple.sh`: A quick port of the travis unit tests to bash. Generates various types of sosreports collection. * Ensure simple.sh test passes - wget https://raw.githubusercontent.com/sosreport/sos/master /test/simple.sh - execute command `sudo tests/simple.sh` [Regression Potential] * Command implicitly slows down python script * Unit test failures * Only affects the hardware plugin and won't affect core functionalities nor other plugins * Lshw that is commonly used on system, the command cannot create any harm on the system (read only) * If the command doesn't exist sosreport will continue and move on * Lshw must be run as super user or it will only report partial information [Other Info] * Upstream commit: https://github.com/sosreport/sos/pull/1994/commits/2dd5cd45a8381fa36ea99c85b526f9d79e526d91 [Original description] * This is a wishlist to add the cmd 'lshw' into the hardware's sosreport plugin To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1871494/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1874075] Re: rabbitmq-server startup timeouts differ between SysV and systemd
Eoan FTBFS as follows: ==> rabbitmqctl ** (Mix) You're trying to run :rabbitmqctl on Elixir v1.9.1 but it has declared in its mix.exs file it supports only Elixir >= 1.6.6 and < 1.8.0 make[4]: *** [Makefile:93: escript/rabbitmqctl] Error 1 make[4]: Leaving directory '/<>/deps/rabbitmq_cli' make[3]: *** [erlang.mk:4322: deps] Error 2 make[3]: Leaving directory '/<>/deps/rabbit' make[2]: *** [erlang.mk:4322: deps] Error 2 make[2]: Leaving directory '/<>' make[1]: *** [debian/rules:18: override_dh_auto_build] Error 2 make[1]: Leaving directory '/<>' make: *** [debian/rules:11: build] Error 2 dpkg-buildpackage: error: debian/rules build subprocess returned exit status 2 Bug reference: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1773324 - Eric ** Changed in: rabbitmq-server (Ubuntu Eoan) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1874075 Title: rabbitmq-server startup timeouts differ between SysV and systemd Status in rabbitmq-server package in Ubuntu: In Progress Status in rabbitmq-server source package in Xenial: In Progress Status in rabbitmq-server source package in Bionic: In Progress Status in rabbitmq-server source package in Eoan: Won't Fix Status in rabbitmq-server source package in Focal: In Progress Bug description: The startup timeouts were recently adjusted and synchronized between the SysV and systemd startup files. https://github.com/rabbitmq/rabbitmq-server-release/pull/129 The new startup files should be included in this package. [Impact] After starting the RabbitMQ server process, the startup script will wait for the server to start by calling `rabbitmqctl wait` and will time out after 10 s. The startup time of the server depends on how quickly the Mnesia database becomes available and the server will time out after `mnesia_table_loading_retry_timeout` ms times `mnesia_table_loading_retry_limit` retries. By default this wait is 30,000 ms times 10 retries, i.e. 300 s. The mismatch between these two timeout values might lead to the startup script failing prematurely while the server is still waiting for the Mnesia tables. This change introduces variable `RABBITMQ_STARTUP_TIMEOUT` and the `--timeout` option into the startup script. The default value for this timeout is set to 10 minutes (600 seconds). This change also updates the systemd service file to match the timeout values between the two service management methods. [Test Case] In a clustered setup with two nodes, A and B. 1. create queue on A 2. shut down B 3. shut down A 4. boot B The broker on B will wait for A. The systemd service will wait for 10 seconds and then fail. Boot A and the rabbitmq-server process on B will complete startup. [Regression Potential] This change alters the behavior of the startup scripts when the Mnesia database takes long to become available. This might lead to failures further down the service dependency chain. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rabbitmq-server/+bug/1874075/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1860813] Re: LXC container reports spike in swap occasionally
** Also affects: lxcfs (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: lxcfs (Ubuntu Eoan) Importance: Undecided Status: New ** Also affects: lxcfs (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: lxcfs (Ubuntu Bionic) Assignee: (unassigned) => Kellen Renshaw (krenshaw) ** Changed in: lxcfs (Ubuntu Bionic) Importance: Undecided => Medium ** Changed in: lxcfs (Ubuntu Bionic) Status: New => In Progress ** Tags added: sts-sponsor-slashd -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1860813 Title: LXC container reports spike in swap occasionally Status in lxcfs package in Ubuntu: Fix Released Status in lxcfs source package in Xenial: New Status in lxcfs source package in Bionic: In Progress Status in lxcfs source package in Eoan: New Bug description: [Impact] * lxcfs provides a container-specific view of /proc/meminfo. Occasionally, with near zero or zero swap usage *and* swap accounting turned on (kernel parameter swapaccount=1), the container will report 100% swap utilization. * This issue has been encountered and could result in unecessary alerts or potential automated attempts at remediating a non-existent "full swap" issue. * This fix changed the logic used for SwapFree when swap accounting is enabled to better handle situations where memswusage is less than memusage, caused by the fuzziness of the usage_in_bytes counters used as the source. Specifically, it added a check for memusage being larger than memswusage and if so, sets 0 as the value of swapusage. Otherwise the calculation (memswusage - memusage) remains the same. [Test Case] * Requires a Bionic (18.04) or Eoan (19.10) host with swap space. * Enable swap accounting with the "swapaccount=1" kernel parameter on the kernel command line. Edit /etc/default/grub, add "swapaccount=1" to the GRUB_CMDLINE_LINUX_DEFAULT="other parameters" line, then run "update-grub" and reboot to make the change active. * Ensure lxd is installed, "sudo apt install lxd" * Create a lxd/lxc container with "lxc launch ubuntu:X container_name" with X being either b[ionic] or e[oan]. * Open two shells to the container with "lxc shell container_name" * In one of the shells, run: watch -n 0.1 "grep Swap /proc/meminfo" * In the other, run: while true; do free; done * You should see SwapFree intermittently drop to zero in the first terminal. * The fix results in small non-zero swap "usage" intermittently instead of intermittent SwapFree = 0. [Regression Potential] * Low, as swap accounting must be enabled to encounter the bug and the fix. * Potential for unanticipated edge cases in the values of memusage and memswusage to cause incorrect swap reporting within the container, with swap accounting turned on. * Any tooling that expected, compensated, or relied on the behavior may no longer work as expected. [Other Info] * Cherrypick of a one line fix to address this specific situation. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lxcfs/+bug/1860813/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1862830] Re: Update sosreport to 3.9
This bug was fixed in the package sosreport - 3.9-1 Sponsored for Eric Desrochers (slashd) --- sosreport (3.9-1) unstable; urgency=medium * New 3.9 upstream release. - Improved human-readable archive naming and support for archive labels - Improved reporting of archive output and properties - Support for automatic uploading of report archives via FTP and HTTPS - Automatic PATH support on Ubuntu distributions - Improved policy performance - Improved service status collection API - 9 new plugins: cloud_init, convert2rhel, ebpf, fwupd, login, nginx, nvidia, openstack_tripleo - 6 obsolete plugins removed or merged into other plugins: katello, last, mrggrid, mrgmessg, satellite - Significant updates to 14 plugins: dlm, dnf, ceph, foreman, gluster, gnocchi, juju, kubernetes, logs, maas, networking, openvswitch, python, plugins - The openswan plugin was renamed to libreswan to reflect the active upstream project name - Updated Red Hat presets and new Cloud Forms preset - Updates to networking plugin namespace handling - Updates to the OVN plugins (ovn_central, ovn_host) - Kernel eBPF data consolidated in a single plugin Further release information and tarballs are available at: https://github.com/sosreport/sos/releases/tag/3.9 * Other specific modifications: - d/p/0001-unittest-py3-fix.patch -- Eric Desrochers Sun, 16 Feb 2020 01:35:52 + ** Changed in: sosreport (Ubuntu) Status: In Progress => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1862830 Title: Update sosreport to 3.9 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Eoan: New Status in sosreport source package in Focal: Fix Released Status in sosreport package in Debian: New Bug description: [Impact] sosreport 3.9 is now released. It would be great to find sosreport v3.9 in supported stable releases, and active development release considering the fact that the releasea (especially LTSes) are going to be supported for a couple of years still. Sosreport is widely use by Canonical support team to troubleshoot UA (Ubuntu Advantage) customer, other vendors and community users. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Test the new upload functionality (--upload) * Test new --all-logs behaviour * Make sure the new naming pattern doesn't break any current Canonical mechanism (Brickftp scripts, ...). If yes evaluate if easy fixable before considering reverting back to 'legacy' pattern. * Run sosreport in different customer scenarios: server, desktop, cloud, hypervisor, instance (container, vm), physical server, ... * Extract archive and look at the content, look for 0 size file (and use common sense if legit or not) * Look under "sos_reports" and "sos_logs" for warnings/errors [Regression Potential] Sosreport has 292 plugins that are all configured differently and configured to run under certains conditions. We can't test all possible scenarios. All we can do is idenfity the most common, important and Ubuntu/Canonical related one and test them (e.g. Openstack*, juju, MAAS, kernel, ...) . With that being said, it is definitely possible that certains plugins may not work as expected, but the risk will be very low (e.g not collecting the desired informations) and isolated to this specific plugin. It shouldn't affect the other plugins nor core functionnalities of sosreport. [Other Informations] * Release note: https://github.com/sosreport/sos/releases/tag/3.9 [Original Description] A new version of sosreport upstream (v3.9) will be released soon. This bug is to track activities to update sosreport in Ubuntu stable + Active Devel release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1862830/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828901] Re: add PTY support for runuser
The sosreport juju plugin refactoring has been simplified. For now, we don't expect the juju plugin to drop privileges any time soon. Thanks ! ** Changed in: util-linux (Ubuntu Xenial) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828901 Title: add PTY support for runuser Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: Won't Fix Status in util-linux package in Debian: Fix Released Bug description: [IMPACT] [TEST CASE] [REGRESSION POTENTIAL] [OTHER INFORMATION] Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 This is fixing a CVE vulnerability: https://security-tracker.debian.org/tracker/CVE-2016-2779 Restricting ioctl on the kernel side seems the better approach, patches have been posted to kernel-hardening list http://www.openwall.com/lists/oss-security/2016/02/27/1 https://marc.info/?l=util-linux-ng&m=145694736107128&w=2 2.31 introduces a new --pty option to separate privileged and unprivileged shells (not enabled by default and the cli switch is necessary). [ORIGINAL DESCRIPTION] After a discussion with security team on what would be their recommended way to run command as 'juju-user' inside the sosreport juju plugin which is run as root, in order to avoid using 'sudo' or 'su' command. The recommendation was to use 'runuser -P' runuser PTY support is present in Bionic and late, but not in Xenial. I'm opening this bug in the effort to update util-linux/runuser code in Xenial to add the PTY support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1828901/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1862830] Re: Update sosreport to 3.9
** Bug watch added: Debian Bug tracker #951392 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951392 ** Also affects: sosreport (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=951392 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1862830 Title: Update sosreport to 3.9 Status in sosreport package in Ubuntu: In Progress Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Eoan: New Status in sosreport source package in Focal: In Progress Status in sosreport package in Debian: Unknown Bug description: [Impact] sosreport 3.9 is now released. It would be great to find sosreport v3.9 in supported stable releases, and active development release considering the fact that the releasea (especially LTSes) are going to be supported for a couple of years still. Sosreport is widely use by Canonical support team to troubleshoot UA (Ubuntu Advantage) customer, other vendors and community users. Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] [Regression Potential] [Other Informations] * Release note: https://github.com/sosreport/sos/releases/tag/3.9 [Original Description] A new version of sosreport upstream (v3.9) will be released soon. This bug is to track activities to update sosreport in Ubuntu stable + Active Devel release. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1862830/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1860217] Re: dpkg-reconfigure clamav-daemon in infinite loop
@cash.williams no worries I revert it back to "Fix Committed" ** Changed in: clamav (Ubuntu Xenial) Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1860217 Title: dpkg-reconfigure clamav-daemon in infinite loop Status in clamav package in Ubuntu: Fix Released Status in clamav source package in Xenial: Fix Committed Status in clamav source package in Bionic: Fix Committed Status in clamav source package in Eoan: Fix Committed Status in clamav source package in Focal: Fix Released Bug description: [Impact] There appears to be another issue with > dpkg-reconfigure clamav-daemon Like in #1792051, the command ends up in an infinite loop, just that this time it happens between 'Log file for clamav-daemon' and 'Do you want to enable log rotation?', with one more step between also included in the loop. Purged and reinstalled the package with no effect. Effected package: clamav-daemon 0.102.1+dfsg-0ubuntu0.19.10.2 (arm64) EDIT: I was able to reproduce the error on a different system (also 0.102.1+dfsg-0ubuntu0.19.10.2, just amd64 instead) [Test Case] (1) Here's how to reproduce: * Deploy Bionic * Install clamav clamav-daemon (As a debug exercise and confirmation of the infinite loop in action, with the use of "export DEBCONF_DEBUG='.*'" one can confirm it.) * Perform: DEBIAN_FRONTEND=noninteractive DEBCONF_NONINTERACTIVE_SEEN=true dpkg-reconfigure clamav-daemon Make sure it completes fine and doesn't enter an infinite loop. --- (2) Run "dpkg-reconfigure clamav-daemon", make sure all of the debconf prompts that are supposed to be there are actually reachable, including the one modified by this SRU "LogTime"[0] and "LogRotate"[1]. [0]- Do you want to log time information with each message? [1]- Do you want to enable log rotation? Here's a test where I intentionally reconfigure the package and set both LogTime and LogRotate from 'yes' (true) to 'No' (False). # egrep "LogRotate|LogTime" /etc/clamav/clamd.conf LogRotate true LogTime true # dpkg-reconfigure clamav-daemon Replacing config file /etc/clamav/clamd.conf with new version Disabling old logrotate script for clamav-daemon # egrep "LogRotate|LogTime" /etc/clamav/clamd.conf LogRotate false LogTime false [Regression Potential] Right now, the impact is limited to the reconfiguration of the package. This is a consequence of the removal of ScanOnAcces (701f0e8e Remove ScanOnAccess). It's been proven to be working well pre-SRU. If a regression is found, it will likely remain limited to the package reconfiguration. I added another verification to address vorlon's concern found in comment #16. See section (2) in [Test Case]. [Other infos] * Debian upstream bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=950296 * Debian upstream (salsa): https://salsa.debian.org/clamav-team/clamav/commit/089b6136e95dd34b3ac8a4d0753bffb48c48ebdb To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/clamav/+bug/1860217/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1819437] Re: transient mon<->osd connectivity HEALTH_WARN events don't self clear in 13.2.4
** Changed in: ceph (Ubuntu Focal)
Status: New => Fix Released
** Changed in: ceph (Ubuntu Xenial)
Status: New => Invalid
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1819437
Title:
transient mon<->osd connectivity HEALTH_WARN events don't self clear
in 13.2.4
Status in ceph package in Ubuntu:
Fix Released
Status in ceph source package in Xenial:
Invalid
Status in ceph source package in Bionic:
New
Status in ceph source package in Eoan:
New
Status in ceph source package in Focal:
Fix Released
Bug description:
In a recently juju deployed 13.2.4 ceph cluster (as part of an
OpenStack Rocky deploy) we experienced a none clearing HEALTH_WARN
event that appeared to be associated with a short planned network
outage, but did not clear without human intervention:
health: HEALTH_WARN
6 slow ops, oldest one blocked for 112899 sec, daemons
[mon.shinx,mon.sliggoo] have slow ops.
We can correlate this back to a known network event, but all OSDs are
up and the cluster otherwise looks healthy:
ubuntu@juju-df624b-4-lxd-14:~$ sudo ceph osd tree
ID CLASS WEIGHT TYPE NAMESTATUS REWEIGHT PRI-AFF
-1 7.64076 root default
-13 0.90970 host happiny
8 hdd 0.90970 osd.8up 1.0 1.0
-5 0.90970 host jynx
9 hdd 0.90970 osd.9up 1.0 1.0
-3 1.63739 host piplup
0 hdd 0.81870 osd.0up 1.0 1.0
3 hdd 0.81870 osd.3up 1.0 1.0
-9 1.63739 host raichu
5 hdd 0.81870 osd.5up 1.0 1.0
6 hdd 0.81870 osd.6up 1.0 1.0
-11 0.90919 host shinx
7 hdd 0.90919 osd.7up 1.0 1.0
-7 1.63739 host sliggoo
1 hdd 0.81870 osd.1up 1.0 1.0
4 hdd 0.81870 osd.4up 1.0 1.0
ubuntu@shinx:~$ sudo ceph daemon mon.shinx ops
{
"ops": [
{
"description": "osd_failure(failed timeout osd.0
10.48.2.158:6804/211414 for 31sec e911 v911)",
"initiated_at": "2019-03-07 00:40:43.282823",
"age": 113953.696205,
"duration": 113953.696225,
"type_data": {
"events": [
{
"time": "2019-03-07 00:40:43.282823",
"event": "initiated"
},
{
"time": "2019-03-07 00:40:43.282823",
"event": "header_read"
},
{
"time": "0.00",
"event": "throttled"
},
{
"time": "0.00",
"event": "all_read"
},
{
"time": "0.00",
"event": "dispatched"
},
{
"time": "2019-03-07 00:40:43.283360",
"event": "mon:_ms_dispatch"
},
{
"time": "2019-03-07 00:40:43.283360",
"event": "mon:dispatch_op"
},
{
"time": "2019-03-07 00:40:43.283360",
"event": "psvc:dispatch"
},
{
"time": "2019-03-07 00:40:43.283370",
"event": "osdmap:preprocess_query"
},
{
"time": "2019-03-07 00:40:43.283371",
"event": "osdmap:preprocess_failure"
},
{
"time": "2019-03-07 00:40:43.283386",
"event": "osdmap:prepare_update"
},
{
"time": "2019-03-07 00:40:43.283386",
"event": "osdmap:prepare_failure"
}
],
"info": {
"seq": 48576937,
"src_is_mon": false,
"source": "osd.8 10.48.2.206:6800/1226277",
"forwarded_to_leader": false
}
}
},
{
"description": "osd_
[Group.of.nepali.translators] [Bug 1825010] Re: [sru] Update sosreport to 3.8
** Summary changed: - [sru] Update sosreport to 3.9 + [sru] Update sosreport to 3.8 ** Tags removed: sosreport37 ** Changed in: sosreport (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: sosreport (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: sosreport (Ubuntu Eoan) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825010 Title: [sru] Update sosreport to 3.8 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: Won't Fix Status in sosreport source package in Bionic: Won't Fix Status in sosreport source package in Cosmic: Won't Fix Status in sosreport source package in Disco: Won't Fix Status in sosreport source package in Eoan: Won't Fix Status in sosreport source package in Focal: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.8 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.8 It would be great to find sosreport v3.8 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.8 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos38X-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos38X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos38X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.8 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825010] Re: [sru] Update sosreport to 3.8
** Changed in: sosreport (Ubuntu Disco) Status: Confirmed => Won't Fix ** Changed in: sosreport (Ubuntu Xenial) Status: Confirmed => Won't Fix ** Changed in: sosreport (Ubuntu Bionic) Status: Confirmed => In Progress ** Changed in: sosreport (Ubuntu Xenial) Status: Won't Fix => In Progress ** Changed in: sosreport (Ubuntu Xenial) Importance: Undecided => Low -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825010 Title: [sru] Update sosreport to 3.8 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Cosmic: Won't Fix Status in sosreport source package in Disco: Won't Fix Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.8 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.8 It would be great to find sosreport v3.8 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.8 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos38X-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos38X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos38X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.8 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1842495] Re: Grafana support on Ubuntu
Disco is near EOL, no need to patch it. ** Also affects: sosreport (Ubuntu Eoan) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1842495 Title: Grafana support on Ubuntu Status in sosreport: Fix Released Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Disco: Won't Fix Status in sosreport source package in Eoan: New Bug description: Please expand the Grafana plugin to support Ubuntu. This should work with both snaps or debs. To manage notifications about this bug go to: https://bugs.launchpad.net/sosreport/+bug/1842495/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1842495] Re: Grafana support on Ubuntu
@cjohnston Do you need this in stable release as well ? Feel free to generate debdiff(s) and I'll gladly sponsor them. - Eric ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Disco) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1842495 Title: Grafana support on Ubuntu Status in sosreport: Fix Released Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Disco: Won't Fix Status in sosreport source package in Eoan: New Bug description: Please expand the Grafana plugin to support Ubuntu. This should work with both snaps or debs. To manage notifications about this bug go to: https://bugs.launchpad.net/sosreport/+bug/1842495/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Changed in: lvm2 (Ubuntu Xenial)
Status: New => Won't Fix
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1854981
Title:
system doesn't properly boot as expected if /usr is on its own LV
Status in initramfs-tools package in Ubuntu:
Won't Fix
Status in lvm2 package in Ubuntu:
Fix Released
Status in initramfs-tools source package in Xenial:
Won't Fix
Status in lvm2 source package in Xenial:
Won't Fix
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Confirmed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Confirmed
Bug description:
Only the lv for root volume get activated, because of the grub
parameter that specifies/enforce it "root=/dev/mapper/ubuntu-vg-ubuntu
--lv"
http://man7.org/linux/man-pages/man7/bootparam.7.html
'root=...'
This argument tells the kernel what device is to be used as
the root filesystem while booting.
If one add a separate LV for /usr, the system will go straight to
initramfs prompt failling to mount /usr.
At initramfs prompt, we notice that 'lv-usr' status is 'NOT
available'.
Performing 'lvm vgchange -ay' at initramfs prompt workaround the
problem and allow one to successfully boot.
Adding 'debug' parameter, we clearly we see /root being detected and mounted:
initramfs.debug:
=> + mount -r -t ext4 /dev/mapper/ubuntu--vg-ubuntu--lv /root
=> + mountroot_status=0
+ [ ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ read_fstab_entry /usr
+ found=1
+ [ -f /root/etc/fstab ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
+ [ / = /usr ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
+ [ /usr = /usr ]
+ [ -n ]
+ found=0
+ break 2
+ return 0
+ log_begin_msg Mounting /usr file system
+ _log_msg Begin: Mounting /usr file system ...
then the code read /etc/fstab and specifically search for /usr (most
likely because of the /usr binary merged) and try to mount if if
found.
initramfs-tools:init
271 maybe_break mount
272 log_begin_msg "Mounting root file system"
273 # Always load local and nfs (since these might be needed for /etc or
274 # /usr, irrespective of the boot script used to mount the rootfs).
275 . /scripts/local
276 . /scripts/nfs
277 . /scripts/${BOOT}
278 parse_numeric "${ROOT}"
279 maybe_break mountroot
280 mount_top
281 mount_premount
282 mountroot
283 log_end_msg
284
=> 285 if read_fstab_entry /usr; then
=> 286 log_begin_msg "Mounting /usr file system"
=> 287 mountfs /usr
=> 288 log_end_msg
=> 289 fi
In this case, /usr is present in /etc/fstab but the logical volume is
not available, so it is mounting a filesystem without his backend
device, thus goes straight to the initramfs prompt because /usr
couldn't be mounted.
It clearly seems to be an 'auto-activation' issue at boot.
For other such as /home, /var, it's not a big deal cause they can be
activated later on in the process and they are (I haven't check but I
guess systemd or systemd unit/generator is taking care of it at some
point), but /usr is a important piece to have mounted before the pivot
since it contains most of the crucial binary, especially that nowadays
/sbin, /bin, and /lib are pointing to /usr:
lrwxrwxrwx 1 root root 10 Aug 26 13:51 libx32 -> usr/libx32
lrwxrwxrwx 1 root root 9 Aug 26 13:51 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 9 Aug 26 13:51 lib32 -> usr/lib32
lrwxrwxrwx 1 root root 7 Aug 26 13:51 lib -> usr/lib
lrwxrwxrwx 1 root root 7 Aug 26 13:51 bin -> usr/bin
lrwxrwxrwx 1 root root 8 Aug 26 13:51 sbin -> usr/sbin
NOTE:
* That doesn't affect /usr found in /etc/fstab on its separate
partition when no LVM involve (e.g. /dev/vdb /usr ext4 ). It only
cause issue when /usr is in a LVM context.
* I was able to reproduce on Bionic and Disco so far.
Eoan doesn't seem to exhibit the situation so far in my testing.
* While certain release such as Bionic, Xenial doesn't come implicitly
with the /usr merge approach. One can install package 'usrmerge' and
convert their system /usr merged. I don't think removing the
read_fstable_entry for /usr is an option here, as some user could
potentially decide to convert their system with 'usrmerge' pkg.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1854981/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/
[Group.of.nepali.translators] [Bug 1854981] Re: system doesn't properly boot as expected if /usr is on its own LV
** Also affects: lvm2 (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: lvm2 (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Disco)
Importance: Undecided
Status: New
** Also affects: lvm2 (Ubuntu Xenial)
Importance: Undecided
Status: New
** Also affects: initramfs-tools (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: initramfs-tools (Ubuntu Disco)
Status: New => Won't Fix
** Changed in: initramfs-tools (Ubuntu Bionic)
Status: New => Won't Fix
** Changed in: initramfs-tools (Ubuntu Xenial)
Status: New => Won't Fix
** Changed in: initramfs-tools (Ubuntu)
Status: New => Won't Fix
** Changed in: lvm2 (Ubuntu)
Status: New => Fix Released
** Changed in: lvm2 (Ubuntu Disco)
Status: New => Confirmed
** Changed in: lvm2 (Ubuntu Bionic)
Status: New => Confirmed
** Changed in: lvm2 (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: lvm2 (Ubuntu Disco)
Importance: Undecided => Medium
** Changed in: lvm2 (Ubuntu)
Importance: High => Undecided
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1854981
Title:
system doesn't properly boot as expected if /usr is on its own LV
Status in initramfs-tools package in Ubuntu:
Won't Fix
Status in lvm2 package in Ubuntu:
Fix Released
Status in initramfs-tools source package in Xenial:
Won't Fix
Status in lvm2 source package in Xenial:
Won't Fix
Status in initramfs-tools source package in Bionic:
Won't Fix
Status in lvm2 source package in Bionic:
Confirmed
Status in initramfs-tools source package in Disco:
Won't Fix
Status in lvm2 source package in Disco:
Confirmed
Bug description:
Only the lv for root volume get activated, because of the grub
parameter that specifies/enforce it "root=/dev/mapper/ubuntu-vg-ubuntu
--lv"
http://man7.org/linux/man-pages/man7/bootparam.7.html
'root=...'
This argument tells the kernel what device is to be used as
the root filesystem while booting.
If one add a separate LV for /usr, the system will go straight to
initramfs prompt failling to mount /usr.
At initramfs prompt, we notice that 'lv-usr' status is 'NOT
available'.
Performing 'lvm vgchange -ay' at initramfs prompt workaround the
problem and allow one to successfully boot.
Adding 'debug' parameter, we clearly we see /root being detected and mounted:
initramfs.debug:
=> + mount -r -t ext4 /dev/mapper/ubuntu--vg-ubuntu--lv /root
=> + mountroot_status=0
+ [ ]
+ log_end_msg
+ _log_msg done.\n
+ [ n = y ]
+ printf done.\n
done.
+ read_fstab_entry /usr
+ found=1
+ [ -f /root/etc/fstab ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
+ [ / = /usr ]
+ read MNT_FSNAME MNT_DIR MNT_TYPE MNT_OPTS MNT_FREQ MNT_PASS MNT_JUNK
+ [ /usr = /usr ]
+ [ -n ]
+ found=0
+ break 2
+ return 0
+ log_begin_msg Mounting /usr file system
+ _log_msg Begin: Mounting /usr file system ...
then the code read /etc/fstab and specifically search for /usr (most
likely because of the /usr binary merged) and try to mount if if
found.
initramfs-tools:init
271 maybe_break mount
272 log_begin_msg "Mounting root file system"
273 # Always load local and nfs (since these might be needed for /etc or
274 # /usr, irrespective of the boot script used to mount the rootfs).
275 . /scripts/local
276 . /scripts/nfs
277 . /scripts/${BOOT}
278 parse_numeric "${ROOT}"
279 maybe_break mountroot
280 mount_top
281 mount_premount
282 mountroot
283 log_end_msg
284
=> 285 if read_fstab_entry /usr; then
=> 286 log_begin_msg "Mounting /usr file system"
=> 287 mountfs /usr
=> 288 log_end_msg
=> 289 fi
In this case, /usr is present in /etc/fstab but the logical volume is
not available, so it is mounting a filesystem without his backend
device, thus goes straight to the initramfs prompt because /usr
couldn't be mounted.
It clearly seems to be an 'auto-activation' issue at boot.
For other such as /home, /var, it's not a big deal cause they can be
activated later on in the process and they are (I haven't check but I
guess systemd or systemd unit/generator is taking care of it at some
point), but /usr is a important piece to have mounted before the pivot
since it contains most of the crucial binary, especially that nowadays
/sbin, /bin, and /lib are pointing to /usr:
lrwxrwxrwx 1 root root 10 Aug 26 13:51 libx32 -> usr/libx32
lrwxrwxrwx 1 root root 9 Aug 26 13:51 lib64 -> usr/lib64
lrwxrwxrwx 1 root root 9 Aug 26 13:51 lib32 -> usr/lib32
lrwxrwxrwx 1 root r
[Group.of.nepali.translators] [Bug 1825010] Re: [sru] Update sosreport to 3.8
** Changed in: sosreport (Ubuntu Cosmic) Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825010 Title: [sru] Update sosreport to 3.8 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: Confirmed Status in sosreport source package in Bionic: Confirmed Status in sosreport source package in Cosmic: Won't Fix Status in sosreport source package in Disco: Confirmed Status in sosreport source package in Eoan: In Progress Status in sosreport source package in Focal: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.8 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.8 It would be great to find sosreport v3.8 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.8 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos38X-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos38X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos38X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.8 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828467] Re: [sru] remove juju-db stop/start service interactions
** Changed in: sosreport (Ubuntu) Assignee: Dan Hill (hillpd) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu) Status: In Progress => Fix Released ** Changed in: sosreport (Ubuntu Cosmic) Status: New => Won't Fix ** Changed in: sosreport (Ubuntu Eoan) Assignee: Dan Hill (hillpd) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Disco) Assignee: Dan Hill (hillpd) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Cosmic) Assignee: Dan Hill (hillpd) => (unassigned) ** Changed in: sosreport (Ubuntu Bionic) Assignee: Dan Hill (hillpd) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Xenial) Assignee: Dan Hill (hillpd) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Disco) Status: New => In Progress ** Changed in: sosreport (Ubuntu Bionic) Status: New => In Progress ** Changed in: sosreport (Ubuntu Xenial) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828467 Title: [sru] remove juju-db stop/start service interactions Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: In Progress Status in sosreport source package in Bionic: In Progress Status in sosreport source package in Cosmic: Won't Fix Status in sosreport source package in Disco: In Progress Status in sosreport source package in Eoan: In Progress Bug description: [Impact] The juju plugin will stop and start the juju-db service during data collection. sosreport should not impact running services, or attempt to recover them. This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1] This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases. [0] - https://github.com/sosreport/sos/issues/1653 [1] - https://github.com/sosreport/sos/pull/1670 [Test Case] * Make sure you are in the juju controller. * Install sosreport * Look mongod PID before ** $ pidof mongod * Run sosreport, ensuring that the juju plugin is exercised * Confirm the juju-db service was not restarted, and mongoexport data captured. * Look mongod PID after ** $ pidof mongod Check for errors while running, or in /tmp/sosreport-*/sos_logs/ The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides. [Regression Potential] * Risk is low. * Change is limited in scope to the juju plugin. * Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins. [Other information] We will temporary divert from the juju plugin found upstream and debian, while the refactoring is completed to avoid any situation where sosreport is run on a controller since it may have production impact on Ubuntu juju environment. Once the refactoring of the juju plugin is completed upstream, we will make sure to update debian and put the juju plugin align with what found upstream and debian. Actually, sosreport 3.7 micro-release is blocked waiting for this refactoring to be completed (LP: #1825010). To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1828467/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT
Uploaded grub2-signed "Rebuild against grub2 2.02~beta2-36ubuntu3.23.
(LP: #1840686)"
** Changed in: grub2-signed (Ubuntu)
Status: In Progress => Fix Released
** Changed in: grub2-signed (Ubuntu)
Assignee: Eric Desrochers (slashd) => (unassigned)
** Changed in: grub2-signed (Ubuntu)
Importance: High => Undecided
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1840686
Title:
Xenial images won't reboot if disk size is > 2TB when using GPT
Status in cloud-init:
Won't Fix
Status in grub package in Ubuntu:
Fix Released
Status in grub2-signed package in Ubuntu:
Fix Released
Status in grub source package in Xenial:
In Progress
Bug description:
[Impact]
On Xenial images which use GPT instead of MBR to enable efi based
booting, there is an issue where after booting an instance that has a
disk size of 2049 GB or higher, we hang on the next subsequent boot
(Logs indicate it hanging on "Booting Hard Disk 0").
This is a problem in grub2 where the system would become unbootable
after ext* online resize if no resize_inode was created at ext* format
time.
[Test Case]
To reproduce:
1) Create an image with a disk size of 3072 GB using a serial that has
GPT:
gcloud compute instances create test-3072-xenial --image daily-
ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel
--boot-disk-size 3072
2) Reboot the instance
The instance will hang on reboot and you cannot connect. If you go to
GCP console and select Logs > Serial port 1 (console), you will see
the boot process has stopped at "Booting Hard Disk 0".
I have built a test package, which is available here:
https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test
If you do step 1) but do not reboot, and instead add the PPA, install
the new grub like so:
1) gcloud compute instances create test-3072-xenial --image
daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel
--boot-disk-size 3072
2) sudo add-apt-repository ppa:mruffell/lp1840686-test
3) sudo apt-get update
4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin
grub-efi-amd64-signed grub-pc-bin grub2-common
5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin
grub2-common
6) sudo grub-install /dev/sda
7) sudo reboot
The instance will boot successfully and you will be able to connect.
Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image,
as it is enabled for GPT and efi. GCP was reverted back to MBR and
bios booting because of this bug, so the latest images will not
reproduce the problem.
[Regression Potential]
Grub is a core package and every care must be taken in order to not
introduce any regressions.
The commit is present in B, D, E and F, and is considered well tested
and widely adopted by the community.
The commit comes with its own testcase, to test the ext4_metabg fix.
The changes are localised to ext* based filesystems, although since
they are the most popular family of filesystems used by the community,
this does not reduce risk of breakage by much.
If a regression were to happen, a regression would have a large
impact, and in the worst case, can lead to unbootable systems and data
loss for users who are not technical enough to reinstall grub from a
working package inside the broken system chroot.
[Other Info]
In comment #4, Sultan identifies the fix as:
commit e20aa39ea4298011ba716087713cff26c6c52006
Author: Vladimir Serbinenko
Date: Mon Feb 16 20:53:26 2015 +0100
Subject: ext2: Support META_BG.
This commit is from upstream grub2, and can be found here:
https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006
Looking at when this was merged:
$ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006
2.02-beta3~429
This commit is present in B, D, E and F, leaving X as the only version
needing an SRU.
The commit cleanly cherry picks to X, because the delta from
2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small.
To manage notifications about this bug go to:
https://bugs.launchpad.net/cloud-init/+bug/1840686/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840686] Re: Xenial images won't reboot if disk size is > 2TB when using GPT
** Also affects: grub2-signed (Ubuntu) Importance: Undecided Status: New ** Changed in: grub2-signed (Ubuntu) Status: New => In Progress ** Changed in: grub2-signed (Ubuntu) Importance: Undecided => High ** Changed in: grub2-signed (Ubuntu) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840686 Title: Xenial images won't reboot if disk size is > 2TB when using GPT Status in cloud-init: Won't Fix Status in grub package in Ubuntu: Fix Released Status in grub2-signed package in Ubuntu: Fix Released Status in grub source package in Xenial: In Progress Bug description: [Impact] On Xenial images which use GPT instead of MBR to enable efi based booting, there is an issue where after booting an instance that has a disk size of 2049 GB or higher, we hang on the next subsequent boot (Logs indicate it hanging on "Booting Hard Disk 0"). This is a problem in grub2 where the system would become unbootable after ext* online resize if no resize_inode was created at ext* format time. [Test Case] To reproduce: 1) Create an image with a disk size of 3072 GB using a serial that has GPT: gcloud compute instances create test-3072-xenial --image daily- ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 2) Reboot the instance The instance will hang on reboot and you cannot connect. If you go to GCP console and select Logs > Serial port 1 (console), you will see the boot process has stopped at "Booting Hard Disk 0". I have built a test package, which is available here: https://launchpad.net/~mruffell/+archive/ubuntu/lp1840686-test If you do step 1) but do not reboot, and instead add the PPA, install the new grub like so: 1) gcloud compute instances create test-3072-xenial --image daily-ubuntu-1604-xenial-v20190731 --image-project ubuntu-os-cloud-devel --boot-disk-size 3072 2) sudo add-apt-repository ppa:mruffell/lp1840686-test 3) sudo apt-get update 4) sudo apt remove grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub-pc-bin grub2-common 5) sudo apt install grub-common grub-efi-amd64 grub-efi-amd64-bin grub-pc-bin grub2-common 6) sudo grub-install /dev/sda 7) sudo reboot The instance will boot successfully and you will be able to connect. Note, we must use "daily-ubuntu-1604-xenial-v20190731" as the image, as it is enabled for GPT and efi. GCP was reverted back to MBR and bios booting because of this bug, so the latest images will not reproduce the problem. [Regression Potential] Grub is a core package and every care must be taken in order to not introduce any regressions. The commit is present in B, D, E and F, and is considered well tested and widely adopted by the community. The commit comes with its own testcase, to test the ext4_metabg fix. The changes are localised to ext* based filesystems, although since they are the most popular family of filesystems used by the community, this does not reduce risk of breakage by much. If a regression were to happen, a regression would have a large impact, and in the worst case, can lead to unbootable systems and data loss for users who are not technical enough to reinstall grub from a working package inside the broken system chroot. [Other Info] In comment #4, Sultan identifies the fix as: commit e20aa39ea4298011ba716087713cff26c6c52006 Author: Vladimir Serbinenko Date: Mon Feb 16 20:53:26 2015 +0100 Subject: ext2: Support META_BG. This commit is from upstream grub2, and can be found here: https://git.savannah.gnu.org/cgit/grub.git/commit/?id=e20aa39ea4298011ba716087713cff26c6c52006 Looking at when this was merged: $ git describe --contains e20aa39ea4298011ba716087713cff26c6c52006 2.02-beta3~429 This commit is present in B, D, E and F, leaving X as the only version needing an SRU. The commit cleanly cherry picks to X, because the delta from 2.02~beta2-36ubuntu3.22 to 2.02-beta3~429 is small. To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1840686/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1743592] Re: NGINX fails to start/install/upgrade if IPv6 is completely disabled.
** Changed in: nginx (Ubuntu Eoan)
Status: In Progress => Won't Fix
** Changed in: nginx (Ubuntu Disco)
Status: In Progress => Won't Fix
** Changed in: nginx (Ubuntu Bionic)
Status: In Progress => Won't Fix
** Changed in: nginx (Ubuntu Xenial)
Status: New => Won't Fix
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1743592
Title:
NGINX fails to start/install/upgrade if IPv6 is completely disabled.
Status in nginx package in Ubuntu:
Triaged
Status in nginx source package in Xenial:
Won't Fix
Status in nginx source package in Bionic:
Won't Fix
Status in nginx source package in Disco:
Won't Fix
Status in nginx source package in Eoan:
Won't Fix
Status in nginx package in Debian:
New
Bug description:
[IMPACT]
With current default vhost listening on IPV6, nginx won't start on
fully IPV6 disabled system, expecting to connect to a IPV6 socket on
port 80.
# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
==> nginx: [emerg] socket() [::]:80 failed (97: Address family not supported
by protocol)
nginx: configuration file /etc/nginx/nginx.conf test failed
# cat /etc/nginx/sites-enabled/default
..
server {
listen 80 default_server;
==> listen [::]:80 default_server;
..
[TEST CASE]
* Disable ipv6
# cat /proc/cmdline
ipv6.disable=1
* Reboot for the kernel parameter to be taken into account.
* Fresh install of nginx:
# apt-get install nginx -y
Output:
# apt-get install nginx -y
...
Setting up nginx-core (1.14.0-0ubuntu1.6) ...
Job for nginx.service failed because the control process exited with error
code.
See "systemctl status nginx.service" and "journalctl -xe" for details.
invoke-rc.d: initscript nginx, action "start" failed.
● nginx.service - A high performance web server and a reverse proxy server
Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset:
enabled)
Active: failed (Result: exit-code) since Wed 2019-10-23 14:01:26 UTC; 6ms
ago
Docs: man:nginx(8)
Process: 1005 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on;
master_process on; (code=exited, status=1/FAILURE)
Oct 23 14:01:26 nginxbionictest1 systemd[1]: Starting A high performance web
server and a reverse proxy server...
Oct 23 14:01:26 nginxbionictest1 nginx[1005]: nginx: [emerg] socket() [::]:80
failed (97: Address family not supported by protocol)
Oct 23 14:01:26 nginxbionictest1 nginx[1005]: nginx: configuration file
/etc/nginx/nginx.conf test failed
Oct 23 14:01:26 nginxbionictest1 systemd[1]: nginx.service: Control process
exited, code=exited status=1
Oct 23 14:01:26 nginxbionictest1 systemd[1]: nginx.service: Failed with
result 'exit-code'.
Oct 23 14:01:26 nginxbionictest1 systemd[1]: Failed to start A high
performance web server and a reverse proxy server.
dpkg: error processing package nginx-core (--configure):
installed nginx-core package post-installation script subprocess returned
error exit status 1
dpkg: dependency problems prevent configuration of nginx:
nginx depends on nginx-core (<< 1.14.0-0ubuntu1.6.1~) | nginx-full (<<
1.14.0-0ubuntu1.6.1~) | nginx-light (<< 1.14.0-0ubuntu1.6.1~) | nginx-extras
(<< 1.14.0-0ubuntu1.6.1~); however:
Package nginx-core is not configured yet.
Package nginx-full is not installed.
Package nginx-light is not installed.
Package nginx-extras is not installed.
nginx depends on nginx-core (>= 1.14.0-0ubuntu1.6) | nginx-full (>=
1.14.0-0ubuntu1.6) | nginx-light (>= 1.14.0-0ubuntu1.6) | nginx-extras (>=
1.14.0-0ubuntu1.6); however:
Package nginx-core is not configured yet.
Package nginx-full is not installed.
Package nginx-light is not installed.
Package nginx-extras is not installed.
dpkg: error processing package nginx (--configure):
dependency problems - leaving unconfigured
Processing triggers for systemd (237-3ubuntu10.31) ...
No apport report written because the error message indicates its a followup
error from a previous failure.
Processing triggers for man-db (2.8.3-2ubuntu0.1)
...
Processing triggers for ufw (0.36-0ubuntu0.18.04.1) ...
Processing triggers for ureadahead (0.100.0-21) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Errors were encountered while processing:
nginx-core
nginx
E: Sub-process /usr/bin/dpkg returned an error code (1)
# dpkg -l | grep -i nginx
iU nginx 1.14.0-0ubuntu1.6 all
small, powerful, scalable web/proxy server
ii nginx-common 1.14.0-0ubuntu1.6 all
small, powerful, scalable web/p
[Group.of.nepali.translators] [Bug 1831448] Re: adcli: not adding an additional service-name
Current active devel release (Future next LTS), now introduced a newer version of adcli: adcli | 0.9.0-1 | focal/universe | source, amd64, arm64, armhf, i386, ppc64el, s390x ** Also affects: adcli (Ubuntu Focal) Importance: Undecided Status: Won't Fix ** Changed in: adcli (Ubuntu Focal) Status: Won't Fix => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1831448 Title: adcli: not adding an additional service-name Status in adcli package in Ubuntu: Won't Fix Status in adcli source package in Xenial: Won't Fix Status in adcli source package in Bionic: Won't Fix Status in adcli source package in Disco: Won't Fix Status in adcli source package in Eoan: Won't Fix Status in adcli source package in Focal: Fix Released Status in adcli package in CentOS: Unknown Status in adcli package in Debian: Fix Released Bug description: I'm trying to add service principals to my computer in an Active Directory environment. The command runs without errors but the computer account attribute "servicePrincipalName" in AD is not changed. The man page says - --service-name=service Additional service name for a Kerberos principal to be created on the computer account. This option may be specified multiple times. -- I've tried this by adcli -v update --service-name=nfs -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details and got * Found realm in keytab: DOMAIN * Found service principal in keytab: host/m15015-lin.DOMAIN * Found host qualified name in keytab: host/m15015-lin.DOMAIN * Found service principal in keytab: host/M15015-LIN * Found computer name in keytab: M15015-LIN * Found service principal in keytab: host/m15015-lin * Using domain name: DOMAIN * Calculated computer account name from fqdn: M15015-LIN * Using domain realm: DOMAIN * Discovering domain controllers: _ldap._tcp.DOMAIN * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.x.X * Received NetLogon info from: WinDC3.DOMAIN * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Q9bim6/krb5.d/adcli-krb5-conf-ZzF3Xh * Looked up short domain name: DOMAIN * Using fully qualified name: m15015-lin * Using domain name: DOMAIN * Using computer account name: M15015-LIN * Using domain realm: DOMAIN * Using fully qualified name: m15015-lin.DOMAIN * Enrolling computer name: M15015-LIN * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for M15015-LIN$ at: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Retrieved kvno '2' for computer account in directory: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Password not too old, no change needed * Modifying computer account: userAccountControl * Modifying computer account: operatingSystem * Modifying computer account: userPrincipalName The errorcode is 0. The cmd line --service-name is not working or do I use the wrong argument? --service-name="nfs/HOSTNAME" is not working too. However, my AD and kerberos configuration is working and so other updates to the computer account in AD are working like: adcli -v update --os-version=19.04 -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details This updates the attribute "operatingSystemVersion" for the computer account in AD. --- Ubuntu 19.04 adcli 0.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1831448/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1848210] Re: ghostscript: ensure update of cups-filter
I will be more favourable to do the other way around by adding a "Depends:" in cups-filters package for ghostscript version "X" ? Especially if cups-filters always needs ghostscript ? It will force ghostscript to get updated instead of making the package install to fails/breaks. At least it's worth testing IMHO that avenue before considering the current "Breaks:" approach. - Eric ** Also affects: cups-filters (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1848210 Title: ghostscript: ensure update of cups-filter Status in cups-filters package in Ubuntu: New Status in ghostscript package in Ubuntu: Invalid Status in cups-filters source package in Xenial: New Status in ghostscript source package in Xenial: In Progress Status in cups-filters source package in Bionic: New Status in ghostscript source package in Bionic: In Progress Bug description: [Impact] * After an update of ghostscript but not cups-filters (which is possible; eg unattended-upgrade/landscape) users may hit errors printing PDF files (LP#1828401). * Landscape and unattended-upgrade allows packages updates to security updates / USN-only, thus ghostscript is updated for CVE-2019-3839-1 and -2 (version 9.26~dfsg+0-0ubuntu0.18.04.9 and 16.04.9) which may break printing PDF files on cups-filters. * So, to ensure that ghostscript and cups-filters are both updated, add a versioned 'Breaks:' relationship to ghostscript for older cups-filters versions which are not yet fixed. Per Debian Policy [1]: """ Normally a Breaks entry will have an “earlier than” version clause; such a Breaks is introduced in the version ... [that] reveals a bug in earlier versions of the broken package ... This use of Breaks will inform higher-level package management tools that the broken package must be upgraded before the new one. """ * A versioned 'Depends:' relationship is not possible as ghostscript doesn't depend on cups-filters, thus it's possible to have ghostscript installed without cups-filters at all. [Test Case] * Install cups-filters version without fix for LP#1828401: 1.20.2-0ubuntu3 in Bionic, and 1.8.3-2ubuntu3.4 in Xenial. * Update ghostscript to/later than fix for CVE-2019-3839-1/-2 9.26~dfsg+0-0ubuntu0.18.04.9 in Bionic / .16.04.9 in Xenial. * Notice it does _not_ update cups-filters to version with fix: 1.20.2-0ubuntu3.1 in Bionic, and 1.8.3-2ubuntu3.5 in Xenial. * $ wget -O ppd-with-pdf-support.ppd \ 'http://www.openprinting.org/ppd-o-matic.php?driver=hl7x0&printer=Brother-HL-1020&show=1' * $ wget -O dummy.pdf \ https://www.w3.org/WAI/ER/tests/xhtml/testfiles/resources/pdf/dummy.pdf * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf ... Filetype: PDF GPL Ghostscript 9.26: Unrecoverable error, exit code 1 Process is dying with "Unable to determine number of pages, page count: -1 ", exit stat 3 ... * Note it's broken. * Install ghostscript (test) packages with the relationships 'Breaks: cups-filters (<< 1.20.2-0ubuntu3.1)' in Bionic or 'Breaks: ..., cups-filters (<< 1.8.3-2ubuntu3.5)' in Xenial. * Note it _does_ update cups-filters to version with fix. * $ foomatic-rip -v --ppd ppd-with-pdf-support.ppd dummy.pdf ... Filetype: PDF File contains 1 pages Starting renderer with command: <...> ... * Note it's now working. [Regression Potential] * Low. This only causes an update to cups-filters to a version that fixes an already identified/resolved problem (LP#1828401), which is available in bionic- & xenial-updates since May 2019. [Other Info] * This is only required in Xenial and Bionic. * Trusty doesn't have the ghostscript update that causes the problem. * Disco/Eoan have the cups-filters fix that it requires (1.22.5+). [1] https://www.debian.org/doc/debian-policy/ch-relationships.html #packages-which-break-other-packages-breaks To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/cups-filters/+bug/1848210/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1846138] Re: backport mod_reqtimeout with handshake support
** Changed in: apache2 (Ubuntu Disco) Status: New => Fix Released ** Changed in: apache2 (Ubuntu Bionic) Status: New => Confirmed ** Changed in: apache2 (Ubuntu Bionic) Status: Confirmed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1846138 Title: backport mod_reqtimeout with handshake support Status in apache2 package in Ubuntu: Fix Released Status in apache2 source package in Xenial: Confirmed Status in apache2 source package in Bionic: Fix Released Status in apache2 source package in Disco: Fix Released Bug description: ## DRAFT ## [Impact] [Test Case] [Regression Potential] [Other Info] [Original description] Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18. Lack of this feature was exhausting free connections when sent corrupted packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1846138] Re: backport mod_reqtimeout with handshake support
** Changed in: apache2 (Ubuntu) Status: New => Fix Released ** Changed in: apache2 (Ubuntu) Assignee: Jesse Williamson (chardan) => (unassigned) ** Changed in: apache2 (Ubuntu Xenial) Assignee: (unassigned) => Jesse Williamson (chardan) ** Description changed: - Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to - Apache 2.4.18. + ## DRAFT ## + [Impact] + + [Test Case] + + [Regression Potential] + + + [Other Info] + + [Original description] + Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18. Lack of this feature was exhausting free connections when sent corrupted packets. ** Changed in: apache2 (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: apache2 (Ubuntu Xenial) Status: New => Confirmed ** Also affects: apache2 (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: apache2 (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1846138 Title: backport mod_reqtimeout with handshake support Status in apache2 package in Ubuntu: Fix Released Status in apache2 source package in Xenial: Confirmed Status in apache2 source package in Bionic: Fix Released Status in apache2 source package in Disco: Fix Released Bug description: ## DRAFT ## [Impact] [Test Case] [Regression Potential] [Other Info] [Original description] Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18. Lack of this feature was exhausting free connections when sent corrupted packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1846138] Re: backport mod_reqtimeout with handshake support
** Also affects: apache2 (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1846138 Title: backport mod_reqtimeout with handshake support Status in apache2 package in Ubuntu: New Status in apache2 source package in Xenial: New Bug description: Backport the handshake feature in mod_reqtimeout (in Apache 2.4.39) to Apache 2.4.18. Lack of this feature was exhausting free connections when sent corrupted packets. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apache2/+bug/1846138/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1831448] Re: adcli: not adding an additional service-name
A bionic-backports request has been made via LP: #1846516 ** Changed in: adcli (Ubuntu Eoan) Status: New => Won't Fix ** Changed in: adcli (Ubuntu Disco) Status: New => Won't Fix ** Changed in: adcli (Ubuntu Bionic) Status: New => Won't Fix ** Changed in: adcli (Ubuntu Xenial) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1831448 Title: adcli: not adding an additional service-name Status in adcli package in Ubuntu: New Status in adcli source package in Xenial: Won't Fix Status in adcli source package in Bionic: Won't Fix Status in adcli source package in Disco: Won't Fix Status in adcli source package in Eoan: Won't Fix Status in adcli package in CentOS: Unknown Status in adcli package in Debian: Fix Released Bug description: I'm trying to add service principals to my computer in an Active Directory environment. The command runs without errors but the computer account attribute "servicePrincipalName" in AD is not changed. The man page says - --service-name=service Additional service name for a Kerberos principal to be created on the computer account. This option may be specified multiple times. -- I've tried this by adcli -v update --service-name=nfs -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details and got * Found realm in keytab: DOMAIN * Found service principal in keytab: host/m15015-lin.DOMAIN * Found host qualified name in keytab: host/m15015-lin.DOMAIN * Found service principal in keytab: host/M15015-LIN * Found computer name in keytab: M15015-LIN * Found service principal in keytab: host/m15015-lin * Using domain name: DOMAIN * Calculated computer account name from fqdn: M15015-LIN * Using domain realm: DOMAIN * Discovering domain controllers: _ldap._tcp.DOMAIN * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.x.X * Received NetLogon info from: WinDC3.DOMAIN * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Q9bim6/krb5.d/adcli-krb5-conf-ZzF3Xh * Looked up short domain name: DOMAIN * Using fully qualified name: m15015-lin * Using domain name: DOMAIN * Using computer account name: M15015-LIN * Using domain realm: DOMAIN * Using fully qualified name: m15015-lin.DOMAIN * Enrolling computer name: M15015-LIN * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for M15015-LIN$ at: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Retrieved kvno '2' for computer account in directory: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Password not too old, no change needed * Modifying computer account: userAccountControl * Modifying computer account: operatingSystem * Modifying computer account: userPrincipalName The errorcode is 0. The cmd line --service-name is not working or do I use the wrong argument? --service-name="nfs/HOSTNAME" is not working too. However, my AD and kerberos configuration is working and so other updates to the computer account in AD are working like: adcli -v update --os-version=19.04 -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details This updates the attribute "operatingSystemVersion" for the computer account in AD. --- Ubuntu 19.04 adcli 0.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1831448/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1831448] Re: adcli: not adding an additional service-name
@bigon, I made the request more "official" by reporting a bug in Debian against adcli: # adcli new release 0.9.0 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941583 Regards, Eric ** Bug watch added: Debian Bug tracker #941583 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941583 ** Also affects: adcli (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=941583 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1831448 Title: adcli: not adding an additional service-name Status in adcli package in Ubuntu: New Status in adcli source package in Xenial: New Status in adcli source package in Bionic: New Status in adcli source package in Disco: New Status in adcli source package in Eoan: New Status in adcli package in CentOS: Unknown Status in adcli package in Debian: Unknown Bug description: I'm trying to add service principals to my computer in an Active Directory environment. The command runs without errors but the computer account attribute "servicePrincipalName" in AD is not changed. The man page says - --service-name=service Additional service name for a Kerberos principal to be created on the computer account. This option may be specified multiple times. -- I've tried this by adcli -v update --service-name=nfs -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details and got * Found realm in keytab: DOMAIN * Found service principal in keytab: host/m15015-lin.DOMAIN * Found host qualified name in keytab: host/m15015-lin.DOMAIN * Found service principal in keytab: host/M15015-LIN * Found computer name in keytab: M15015-LIN * Found service principal in keytab: host/m15015-lin * Using domain name: DOMAIN * Calculated computer account name from fqdn: M15015-LIN * Using domain realm: DOMAIN * Discovering domain controllers: _ldap._tcp.DOMAIN * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.X.X * Sending netlogon pings to domain controller: cldap://X.X.x.X * Received NetLogon info from: WinDC3.DOMAIN * Wrote out krb5.conf snippet to /tmp/adcli-krb5-Q9bim6/krb5.d/adcli-krb5-conf-ZzF3Xh * Looked up short domain name: DOMAIN * Using fully qualified name: m15015-lin * Using domain name: DOMAIN * Using computer account name: M15015-LIN * Using domain realm: DOMAIN * Using fully qualified name: m15015-lin.DOMAIN * Enrolling computer name: M15015-LIN * Generated 120 character computer password * Using keytab: FILE:/etc/krb5.keytab * Found computer account for M15015-LIN$ at: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Retrieved kvno '2' for computer account in directory: CN=M15015-LIN,OU=Linux-Clients,OU=Client Computer,DC=DOMAIN * Password not too old, no change needed * Modifying computer account: userAccountControl * Modifying computer account: operatingSystem * Modifying computer account: userPrincipalName The errorcode is 0. The cmd line --service-name is not working or do I use the wrong argument? --service-name="nfs/HOSTNAME" is not working too. However, my AD and kerberos configuration is working and so other updates to the computer account in AD are working like: adcli -v update --os-version=19.04 -D DOMAIN -C /tmp/krb5cc_11872_nXpkOu --show-details This updates the attribute "operatingSystemVersion" for the computer account in AD. --- Ubuntu 19.04 adcli 0.8.2-1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/adcli/+bug/1831448/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825010] Re: [sru] Update sosreport to 3.8
sosreport 3.8 have been accepted into debian unstable. As a first step, I'll upload sosreport 3.8 in the next active development release (F-series) when the cycle will start, and then will wait as mentioned earlier for the juju plugin(s) refactoring to be merged before updating any stable releases. ** Also affects: sosreport (Ubuntu Ff-series) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Ff-series) Status: New => In Progress ** Changed in: sosreport (Ubuntu Ff-series) Importance: Undecided => Medium ** Changed in: sosreport (Ubuntu Ff-series) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825010 Title: [sru] Update sosreport to 3.8 Status in sosreport package in Ubuntu: New Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Cosmic: New Status in sosreport source package in Disco: New Status in sosreport source package in Eoan: In Progress Status in sosreport source package in FF-Series: In Progress Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.8 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.8 It would be great to find sosreport v3.8 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.8 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos37xenial-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos37X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos37X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.8 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1843036] Re: [regression] SNMP missing disks in hrStorageTable
** Changed in: net-snmp (Ubuntu Bionic) Status: Fix Released => Fix Committed -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1843036 Title: [regression] SNMP missing disks in hrStorageTable Status in net-snmp package in Ubuntu: Fix Released Status in net-snmp source package in Xenial: Fix Committed Status in net-snmp source package in Bionic: Fix Committed Status in net-snmp source package in Disco: Fix Committed Status in net-snmp source package in Eoan: Fix Released Bug description: [IMPACT] It has been brought to me the following: Some hosts have started to cause UNKNOWN return values in Nagios for checks on their disks. This is because these hosts are no longer reporting their disks as part of the SNMP table hrStorageTable (1.3.6.1.2.1.25.2.3.1 ) - only memory devices are being reported. The affected hosts that I have investigated received updates for SNMP: Upgrade package libsnmp-base 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2 Upgrade package libsnmp30 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2 Upgrade package snmpd 5.7.3+dfsg-1.8ubuntu3.1 to 5.7.3+dfsg-1.8ubuntu3.2 It seems likely that this package update is the cause. As debug info, you can see the difference between 2 nearly identical servers, one of which received the SNMP updates, and one which did not. You can see that the one without the update is returning disks in the SNMP output: # snmpwalk -v2c -cpublic arcprsmt01 1.3.6.1.2.1.25.2.3.1.3 iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory" iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory" iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers" iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory" iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory" iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space" iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/" iso.3.6.1.2.1.25.2.3.1.3.37 = STRING: "/run" iso.3.6.1.2.1.25.2.3.1.3.39 = STRING: "/dev/shm" iso.3.6.1.2.1.25.2.3.1.3.40 = STRING: "/run/lock" iso.3.6.1.2.1.25.2.3.1.3.41 = STRING: "/sys/fs/cgroup" iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run/snapd/ns" iso.3.6.1.2.1.25.2.3.1.3.70 = STRING: "/var/lib/docker/containers/3cad3d36991b677c37b08b374a7bfeceddf36a6b6754edaa1ff687b00111a6b8/mounts/shm" iso.3.6.1.2.1.25.2.3.1.3.73 = STRING: "/var/lib/docker/containers/c605c4b76dea65d562ba024212a38e24fb710186c499187b6604478b7ff678e9/mounts/shm" iso.3.6.1.2.1.25.2.3.1.3.82 = STRING: "/run/user/2002" iso.3.6.1.2.1.25.2.3.1.3.253 = STRING: "/var/lib/docker/containers/dc74a157fbaaa284e0e5b8ca4afc88769bf625eb796d89a5d26f98a540cabf35/mounts/shm" iso.3.6.1.2.1.25.2.3.1.3.256 = STRING: "/var/lib/docker/containers/6ce6193433f9c1c95cccbfbbe08a3f3385bdbc4f2e3f0baa02d11baf3866dfd2/mounts/shm" iso.3.6.1.2.1.25.2.3.1.3.258 = STRING: "/run/user/1000" The other, which received SNMP updates, is returning only memory devices, such as swap and shmem: # snmpwalk -v2c -cpublic arcprsmt02 1.3.6.1.2.1.25.2.3.1.3 iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory" iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory" iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers" iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory" iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory" iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space" [Test Case] * Install snmp snmpd * Configure /etc/snmp/snmpd.conf by adding the following: view systemonly included .1.3.6.1.2.1.25.2.3.1.3 * Restart snmpd * Use snmpwalk: ** snmpwalk -v2c -cpublic localhost 1.3.6.1.2.1.25.2.3.1.3 Expected behavior is to see the disk as follow: " iso.3.6.1.2.1.25.2.3.1.3.1 = STRING: "Physical memory" iso.3.6.1.2.1.25.2.3.1.3.3 = STRING: "Virtual memory" iso.3.6.1.2.1.25.2.3.1.3.6 = STRING: "Memory buffers" iso.3.6.1.2.1.25.2.3.1.3.7 = STRING: "Cached memory" iso.3.6.1.2.1.25.2.3.1.3.8 = STRING: "Shared memory" iso.3.6.1.2.1.25.2.3.1.3.10 = STRING: "Swap space" iso.3.6.1.2.1.25.2.3.1.3.31 = STRING: "/" iso.3.6.1.2.1.25.2.3.1.3.33 = STRING: "/dev" iso.3.6.1.2.1.25.2.3.1.3.45 = STRING: "/dev/lxd" iso.3.6.1.2.1.25.2.3.1.3.46 = STRING: "/dev/.lxd-mounts" iso.3.6.1.2.1.25.2.3.1.3.63 = STRING: "/proc/sys/kernel/random/boot_id" iso.3.6.1.2.1.25.2.3.1.3.66 = STRING: "/dev/shm" iso.3.6.1.2.1.25.2.3.1.3.67 = STRING: "/run" iso.3.6.1.2.1.25.2.3.1.3.68 = STRING: "/run/lock" iso.3.6.1.2.1.25.2.3.1.3.69 = STRING: "/sys/fs/cgroup" " [Potential Regression] The fix has been tested by various impacted users (+/- 10 different impacted users), and feedback were all positives (see comments below). Note that this fix a regression introduced by: https://bugs.launchpad.net/bugs/1835818 [Other information] # Upstream commit: https://github.com/net-snmp/net-snmp/commit/71e487212bd65839e7454d
[Group.of.nepali.translators] [Bug 1825010] Re: [sru] Update sosreport to 3.8
** No longer affects: sosreport (Debian) ** Bug watch added: Debian Bug tracker #939900 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939900 ** Also affects: sosreport (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939900 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825010 Title: [sru] Update sosreport to 3.8 Status in sosreport package in Ubuntu: New Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Cosmic: New Status in sosreport source package in Disco: New Status in sosreport source package in Eoan: In Progress Status in sosreport package in Debian: Unknown Bug description: [Impact] sosreport 3.8 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.8 It would be great to find sosreport v3.8 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.8 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos37xenial-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos37X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos37X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.8 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1842426] [NEW] xenial's chromium-browser test failure
Public bug reported: As requested by SRU verification team: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1589289/comments/33 As for xenial's chromium-browser test failures - could you please file a bug about the failing architectures? I would then include the bug number in the hint. This way we won't forget about the test issues. # pending SRU report: Regression in autopkgtest for chromium-browser (arm64): test log http://autopkgtest.ubuntu.com/packages/c/chromium-browser/xenial/arm64 Regression in autopkgtest for chromium-browser (i386): test log http://autopkgtest.ubuntu.com/packages/c/chromium-browser/xenial/i386 Regression in autopkgtest for chromium-browser (amd64): test log http://autopkgtest.ubuntu.com/packages/c/chromium-browser/xenial/amd64 The above are recurrent pattern of autopkgtest failures. ** Affects: chromium-browser (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: chromium-browser (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: chromium-browser (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: chromium-browser (Ubuntu) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1842426 Title: xenial's chromium-browser test failure Status in chromium-browser package in Ubuntu: Fix Released Status in chromium-browser source package in Xenial: New Bug description: As requested by SRU verification team: https://bugs.launchpad.net/ubuntu/+source/util- linux/+bug/1589289/comments/33 As for xenial's chromium-browser test failures - could you please file a bug about the failing architectures? I would then include the bug number in the hint. This way we won't forget about the test issues. # pending SRU report: Regression in autopkgtest for chromium-browser (arm64): test log http://autopkgtest.ubuntu.com/packages/c/chromium-browser/xenial/arm64 Regression in autopkgtest for chromium-browser (i386): test log http://autopkgtest.ubuntu.com/packages/c/chromium-browser/xenial/i386 Regression in autopkgtest for chromium-browser (amd64): test log http://autopkgtest.ubuntu.com/packages/c/chromium-browser/xenial/amd64 The above are recurrent pattern of autopkgtest failures. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1842426/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840091] Re: ubuntu-advantage enable-esm should ensure correct package requirements are met
Base on the discussion with vorlon, I'll mark X/B/E as 'Won't Fix' for now. [12:27:52] rbasak: there's a complete rewrite of the client that is going to be landed in trusty-updates, definitely before xenial goes ESM. It's been delayed for polish but is definitely happening [12:28:07] because the ESM service implementation is changing and the old client will not work with ESM for xenial [12:28:19] so I'm confident in this case :) [12:31:15] rbasak, vorlon, so it's safe to say that we can postpone the fix until the new client is released ? and re-evaluate by then ? [12:31:24] for x and late [12:31:36] yes ** Changed in: ubuntu-advantage-tools (Ubuntu Bionic) Status: In Progress => Won't Fix ** Changed in: ubuntu-advantage-tools (Ubuntu Eoan) Status: In Progress => Won't Fix ** Changed in: ubuntu-advantage-tools (Ubuntu Xenial) Status: In Progress => Won't Fix ** Changed in: ubuntu-advantage-tools (Ubuntu Eoan) Assignee: Erlon R. Cruz (sombrafam) => (unassigned) ** Changed in: ubuntu-advantage-tools (Ubuntu Bionic) Assignee: Erlon R. Cruz (sombrafam) => (unassigned) ** Changed in: ubuntu-advantage-tools (Ubuntu Xenial) Assignee: Erlon R. Cruz (sombrafam) => (unassigned) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840091 Title: ubuntu-advantage enable-esm should ensure correct package requirements are met Status in ubuntu-advantage-tools package in Ubuntu: Won't Fix Status in ubuntu-advantage-tools source package in Trusty: Fix Committed Status in ubuntu-advantage-tools source package in Xenial: Won't Fix Status in ubuntu-advantage-tools source package in Bionic: Won't Fix Status in ubuntu-advantage-tools source package in Eoan: Won't Fix Bug description: [Impact] To use ESM for 14.04 you must install 1.0.1ubuntu2.23 of apt apt- transport-https apt-utils libapt-inst1.5 libapt-pkg4.12 These should be checked and warn/error/install the correct packages when running enable-esm [Test Case] * Deploy trusty container with a "apt" package version lower than version: "1.0.1ubuntu2.23" ** lxc launch ubuntu:d57cf522816f For instance image iD "d57cf522816f" contains apt : 1.0.1ubuntu2.17 * lxc exec bash * Install ubuntu-advantage-tools * ubuntu-advantage enable-esm * sudo apt-get update * sudo apt-get upgrade Err https://esm.ubuntu.com/ubuntu/ trusty-security/main bash amd64 4.3-7ubuntu1.8+esm1 HttpError401 Err https://esm.ubuntu.com/ubuntu/ trusty-security/main bzip2 amd64 1.0.6-5ubuntu0.1~esm2 ... E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/a/apport/apport_2.14.1-0ubuntu3.29+esm1_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/g/glib2.0/libglib2.0-data_2.40.2-0ubuntu1.1+esm3_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/p/python-urllib3/python-urllib3_1.7.1-1ubuntu4.1+esm1_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/s/screen/screen_4.1.0~20120320gitdb59704-9ubuntu0.1~esm1_amd64.deb HttpError401 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Expected behaviour: Get:3 https://esm.ubuntu.com/ubuntu/ trusty-security/main bash amd64 4.3-7ubuntu1.8+esm1 [575 kB] Get:6 https://esm.ubuntu.com/ubuntu/ trusty-security/main bzip2 amd64 1.0.6-5ubuntu0.1~esm2 [34.6 kB] .. If user installs u-a-tools and do not upgrade apt, then complains are that it does not work all the time as expected (see above ^) Would be better to add some Depends: (as describe by juliank) to avoid users updating the tool but keeping an older version of apt that may introduce esm upgrade problem/failure. [Potential Regression] * One situation that Andreas brought up that is worth mentioning here, is that apparently some customer may have intentionally disabled "trusty-updates". If it's the case, then one would need to enable "trusty-updates" back temporary in order to upgrade the "ubuntu- advantage-tools" package and it's Dependencies (apt derived binary packages) * We simply instruct u-a-tools to update apt (and its derived binary pkg) to a more recent version to avoid problems. * apt in Trusty is unlikely to change now. There may be other ESM uploads here and there in the future, but Trusty itself is frozen now. [Other Info] * Fix has been proposed and agreed by foundation team. * rmadison: apt | 1.0.1ubuntu2| trusty apt | 1.0.1ubuntu2.19 | trusty-security apt | 1.0.1ubuntu2.23 | trusty-updates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1840091/+subscriptions ___ Mailing list: https:
[Group.of.nepali.translators] [Bug 1840091] Re: ubuntu-advantage enable-esm should ensure correct package requirements are met
** Changed in: ubuntu-advantage-tools (Ubuntu Eoan) Status: Won't Fix => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840091 Title: ubuntu-advantage enable-esm should ensure correct package requirements are met Status in ubuntu-advantage-tools package in Ubuntu: Won't Fix Status in ubuntu-advantage-tools source package in Trusty: Fix Committed Status in ubuntu-advantage-tools source package in Xenial: In Progress Status in ubuntu-advantage-tools source package in Bionic: In Progress Status in ubuntu-advantage-tools source package in Eoan: In Progress Bug description: [Impact] To use ESM for 14.04 you must install 1.0.1ubuntu2.23 of apt apt- transport-https apt-utils libapt-inst1.5 libapt-pkg4.12 These should be checked and warn/error/install the correct packages when running enable-esm [Test Case] * Deploy trusty container with a "apt" package version lower than version: "1.0.1ubuntu2.23" ** lxc launch ubuntu:d57cf522816f For instance image iD "d57cf522816f" contains apt : 1.0.1ubuntu2.17 * lxc exec bash * Install ubuntu-advantage-tools * ubuntu-advantage enable-esm * sudo apt-get update * sudo apt-get upgrade Err https://esm.ubuntu.com/ubuntu/ trusty-security/main bash amd64 4.3-7ubuntu1.8+esm1 HttpError401 Err https://esm.ubuntu.com/ubuntu/ trusty-security/main bzip2 amd64 1.0.6-5ubuntu0.1~esm2 ... E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/a/apport/apport_2.14.1-0ubuntu3.29+esm1_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/g/glib2.0/libglib2.0-data_2.40.2-0ubuntu1.1+esm3_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/p/python-urllib3/python-urllib3_1.7.1-1ubuntu4.1+esm1_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/s/screen/screen_4.1.0~20120320gitdb59704-9ubuntu0.1~esm1_amd64.deb HttpError401 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Expected behaviour: Get:3 https://esm.ubuntu.com/ubuntu/ trusty-security/main bash amd64 4.3-7ubuntu1.8+esm1 [575 kB] Get:6 https://esm.ubuntu.com/ubuntu/ trusty-security/main bzip2 amd64 1.0.6-5ubuntu0.1~esm2 [34.6 kB] .. If user installs u-a-tools and do not upgrade apt, then complains are that it does not work all the time as expected (see above ^) Would be better to add some Depends: (as describe by juliank) to avoid users updating the tool but keeping an older version of apt that may introduce esm upgrade problem/failure. [Potential Regression] * One situation that Andreas brought up that is worth mentioning here, is that apparently some customer may have intentionally disabled "trusty-updates". If it's the case, then one would need to enable "trusty-updates" back temporary in order to upgrade the "ubuntu- advantage-tools" package and it's Dependencies (apt derived binary packages) * We simply instruct u-a-tools to update apt (and its derived binary pkg) to a more recent version to avoid problems. * apt in Trusty is unlikely to change now. There may be other ESM uploads here and there in the future, but Trusty itself is frozen now. [Other Info] * Fix has been proposed and agreed by foundation team. * rmadison: apt | 1.0.1ubuntu2| trusty apt | 1.0.1ubuntu2.19 | trusty-security apt | 1.0.1ubuntu2.23 | trusty-updates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1840091/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1840091] Re: ubuntu-advantage enable-esm should ensure correct package requirements are met
Might be a MUST to have it also in future release before their ESM period start. For that reason, I'm targeting the other LTS version. ** Also affects: ubuntu-advantage-tools (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: ubuntu-advantage-tools (Ubuntu Eoan) Importance: High Status: Won't Fix ** Also affects: ubuntu-advantage-tools (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1840091 Title: ubuntu-advantage enable-esm should ensure correct package requirements are met Status in ubuntu-advantage-tools package in Ubuntu: Won't Fix Status in ubuntu-advantage-tools source package in Trusty: Fix Committed Status in ubuntu-advantage-tools source package in Xenial: In Progress Status in ubuntu-advantage-tools source package in Bionic: In Progress Status in ubuntu-advantage-tools source package in Eoan: In Progress Bug description: [Impact] To use ESM for 14.04 you must install 1.0.1ubuntu2.23 of apt apt- transport-https apt-utils libapt-inst1.5 libapt-pkg4.12 These should be checked and warn/error/install the correct packages when running enable-esm [Test Case] * Deploy trusty container with a "apt" package version lower than version: "1.0.1ubuntu2.23" ** lxc launch ubuntu:d57cf522816f For instance image iD "d57cf522816f" contains apt : 1.0.1ubuntu2.17 * lxc exec bash * Install ubuntu-advantage-tools * ubuntu-advantage enable-esm * sudo apt-get update * sudo apt-get upgrade Err https://esm.ubuntu.com/ubuntu/ trusty-security/main bash amd64 4.3-7ubuntu1.8+esm1 HttpError401 Err https://esm.ubuntu.com/ubuntu/ trusty-security/main bzip2 amd64 1.0.6-5ubuntu0.1~esm2 ... E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/a/apport/apport_2.14.1-0ubuntu3.29+esm1_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/g/glib2.0/libglib2.0-data_2.40.2-0ubuntu1.1+esm3_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/p/python-urllib3/python-urllib3_1.7.1-1ubuntu4.1+esm1_all.deb HttpError401 E: Failed to fetch https://esm.ubuntu.com/ubuntu/pool/main/s/screen/screen_4.1.0~20120320gitdb59704-9ubuntu0.1~esm1_amd64.deb HttpError401 E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing? Expected behaviour: Get:3 https://esm.ubuntu.com/ubuntu/ trusty-security/main bash amd64 4.3-7ubuntu1.8+esm1 [575 kB] Get:6 https://esm.ubuntu.com/ubuntu/ trusty-security/main bzip2 amd64 1.0.6-5ubuntu0.1~esm2 [34.6 kB] .. If user installs u-a-tools and do not upgrade apt, then complains are that it does not work all the time as expected (see above ^) Would be better to add some Depends: (as describe by juliank) to avoid users updating the tool but keeping an older version of apt that may introduce esm upgrade problem/failure. [Potential Regression] * One situation that Andreas brought up that is worth mentioning here, is that apparently some customer may have intentionally disabled "trusty-updates". If it's the case, then one would need to enable "trusty-updates" back temporary in order to upgrade the "ubuntu- advantage-tools" package and it's Dependencies (apt derived binary packages) * We simply instruct u-a-tools to update apt (and its derived binary pkg) to a more recent version to avoid problems. * apt in Trusty is unlikely to change now. There may be other ESM uploads here and there in the future, but Trusty itself is frozen now. [Other Info] * Fix has been proposed and agreed by foundation team. * rmadison: apt | 1.0.1ubuntu2| trusty apt | 1.0.1ubuntu2.19 | trusty-security apt | 1.0.1ubuntu2.23 | trusty-updates To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-advantage-tools/+bug/1840091/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828596] Re: kdump fails when crash is triggered after DLPAR cpu add operation
** Changed in: makedumpfile (Ubuntu Disco) Status: New => In Progress ** Changed in: makedumpfile (Ubuntu Disco) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) ** Changed in: makedumpfile (Ubuntu Bionic) Status: New => In Progress ** Changed in: makedumpfile (Ubuntu Bionic) Assignee: (unassigned) => Thadeu Lima de Souza Cascardo (cascardo) ** Changed in: makedumpfile (Ubuntu Cosmic) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828596 Title: kdump fails when crash is triggered after DLPAR cpu add operation Status in The Ubuntu-power-systems project: Triaged Status in kexec-tools package in Ubuntu: Invalid Status in makedumpfile package in Ubuntu: Fix Released Status in kexec-tools source package in Xenial: New Status in makedumpfile source package in Xenial: New Status in kexec-tools source package in Bionic: New Status in makedumpfile source package in Bionic: In Progress Status in kexec-tools source package in Cosmic: New Status in makedumpfile source package in Cosmic: Won't Fix Status in kexec-tools source package in Disco: New Status in makedumpfile source package in Disco: In Progress Status in kexec-tools source package in Eoan: Invalid Status in makedumpfile source package in Eoan: Fix Released Bug description: [Impact] After a CPU add/hotplug operation on Power systems, kdump will fail after a crash. The kdump kernel needs to be reloaded after a CPU add/hotplug. [Test case] Do CPU add/hotplug, trigger a crash, and check for a successful kdump. [Regression potential] Multiple reloads caused by multiple sequential CPU adds may cause spurious log results, and systemd may fail to properly reload the kdump kernel. This has been handled by resetting the failure counter when doing such reloads. == Comment: #0 - Hari Krishna Bathini - 2019-05-10 05:55:40 == ---Problem Description--- kdump fails when crash is triggered after CPU add operation. Machine Type = na ---System Hang--- Crashed in early boot process of kdump kernel after crash Had to issue system reset from HMC to reclaim ---Steps to Reproduce--- 1. Configure kdump. 2. Add cpu from HMC. 3. Trigger crash. 4. Machine hangs after crash as below: --- [169250.213166] IPI complete [169250.234331] kexec: Starting switchover sequence. I'm in purgatory --- STRUCK HERE --- ---uname output--- na ---Debugger--- A debugger is not configured == Comment: #1 - Hari Krishna Bathini - 2019-05-10 05:56:46 == The problem is, kexec udev rule to restart kdump-tools service - when a core is added, is not being triggered. The old DT created by kexec (before the core is added) is being used by KDump Kernel. So, when system crashes on a thread from the added core(s), KDump kernel is failing to get the 'boot_cpuid' and eventually failing to boot.. == Comment: #2 - Hari Krishna Bathini - 2019-05-10 06:02:27 == The udev rule when CPU is added is not triggered because ppc64 does not eject add/remove event when a CPU is hot added/removed. It only ejects online/offline event to user space when CPU is hot added/removed. So, the below udev rules are never triggered when needed: SUBSYSTEM=="cpu", ACTION=="add", PROGRAM="/bin/systemctl try-restart kdump-tools.service" SUBSYSTEM=="cpu", ACTION=="remove", PROGRAM="/bin/systemctl try-restart kdump-tools.service" Also, with how CPU hot add & remove are handled in ppc64, a udev trigger to reload kdump after CPU is hot removed is NOT necessary. So, fix the CPU hot add case by updating the udev rule and drop the udev rule meant for CPU hot remove in the kdump udev rules file: SUBSYSTEM=="cpu", ACTION=="online", PROGRAM="/bin/systemctl try- restart kdump-tools.service" To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1828596/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1589289] Re: fstrim: cannot open /dev/.lxd-mounts: Permission denied
** Bug watch added: Debian Bug tracker #935326 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935326 ** Also affects: util-linux (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=935326 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1589289 Title: fstrim: cannot open /dev/.lxd-mounts: Permission denied Status in util-linux package in Ubuntu: In Progress Status in util-linux source package in Xenial: In Progress Status in util-linux source package in Bionic: In Progress Status in util-linux source package in Disco: In Progress Status in util-linux package in Debian: Unknown Bug description: [Impact] fstrim weekly cronjob output in an unprivileged LXD container: /etc/cron.weekly/fstrim: fstrim: cannot open /dev/.lxd-mounts: Permission denied fstrim: /dev/fuse: not a directory fstrim: /dev/lxd: FITRIM ioctl failed: Operation not permitted There is a github issue: https://github.com/lxc/lxd/issues/2030 The outcome is that it's purely an fstrim misbehaviour, it could be smarter. Stephane Graber comment: As all of this is handled by the kernel, there isn't anything we can do about it in LXD. I think fstrim should be made slightly more clever: * Don't run on bind-mounts (you can detect bind-mounts by parsing /proc/self/mountinfo instead of /proc/mounts) * Maybe not be as noisy on expected errors like EACCES, EPERM and ENOENT, only log actual failures which would likely be EINVAL or memory related errors. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: util-linux 2.27.1-6ubuntu3 ProcVersionSignature: Ubuntu 4.4.0-21.37-generic 4.4.6 Uname: Linux 4.4.0-21-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Sun Jun 5 19:49:04 2016 ProcEnviron: LANGUAGE=en_US:en TERM=xterm PATH=(custom, no user) LANG=en_US.UTF-8 SHELL=/bin/bash SourcePackage: util-linux UpgradeStatus: No upgrade log present (probably fresh install) [Test Case] * Ubuntu lxd container * Wait for the scheduled fstrim run (X: cronjob, B and late: systemd timer) * fstrim will run and report errors "Operation not permitted" "Permission denied", ... Container shouldn't run fstrim, it should only be run at host level. [Potential Regression] None, the change will only block fstrim to be automatically run at scheduled time. One can still run fstrim on a container manually, even if there is no purpose of doing that. Xenial uses the cronjob approach /etc/cron.weekly/fstrim Bionic and late switched to a systemd timer. 2 differents fixes (one for X, and one for B and late) will be needed, but they'll do same thing, which prevent fstrim to automatically run if inside a container both fixes using systemd-virt-detect. [Other Informations] * The systemd timer change upstream PR: https://github.com/karelzak/util-linux/pull/841 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1589289/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1839366] Re: LVM: fix missing dash
** Changed in: resource-agents (Ubuntu Xenial)
Status: In Progress => Invalid
** Description changed:
[Impact]
lvm-tag.sh line 150 is missing a dash in front of 'aly' flags. This is
causing lvm resource to fail during start.
heartbeat/lvm-tag.sh
vgchange_activate_options="aly --config
activation{volume_list=[\"@${OUR_TAG}\"]}"
is missing a - in front of aly. The - can be seen in the deactivate
line:
vgchange_deactivate_options="-aln"
Upstream fix:
https://github.com/ClusterLabs/resource-agents/pull/1190/files
Version: 1:4.1.0~rc1-1ubuntu1.1
[Test Case]
It's the ocf:heartbeat:LVM resource that fails here (because the flags
it passes to vgchange to activate the VG are incorrect). It manages an
Linux Volume Manager volume (LVM) as an HA resource.
[Potential Regression]
I don't expect regression, the missing "-" need to be there to properly
perform the activation. Once the activation will work using the "-",
it's not impossible that one finds other corner situation due to the
fact that the activation now working, but IMHO they'll be consider bugs,
not regression to this SRU.
[Other Infos]
* Redhat Bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1612828
* Upstream fix:
https://github.com/ClusterLabs/resource-agents/commit/5a664525a20d3d5094912322be4faac668e4920e
$ git describe --contains 5a664525a20d3d5094912322be4faac668e4920e
v4.2.0rc1~42^2
$ rmadison resource-agents
- => resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates
+ resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates # lvm-tag.sh
doesn't exist yet.
=> resource-agents | 1:4.1.0~rc1-1ubuntu1.1 | bionic-updates
resource-agents | 1:4.2.0-1ubuntu1.1 | disco-updates
resource-agents | 1:4.2.0-1ubuntu2 | eoan
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1839366
Title:
LVM: fix missing dash
Status in resource-agents package in Ubuntu:
Fix Released
Status in resource-agents source package in Xenial:
Invalid
Status in resource-agents source package in Bionic:
In Progress
Bug description:
[Impact]
lvm-tag.sh line 150 is missing a dash in front of 'aly' flags. This is
causing lvm resource to fail during start.
heartbeat/lvm-tag.sh
vgchange_activate_options="aly --config
activation{volume_list=[\"@${OUR_TAG}\"]}"
is missing a - in front of aly. The - can be seen in the deactivate
line:
vgchange_deactivate_options="-aln"
Upstream fix:
https://github.com/ClusterLabs/resource-agents/pull/1190/files
Version: 1:4.1.0~rc1-1ubuntu1.1
[Test Case]
It's the ocf:heartbeat:LVM resource that fails here (because the flags
it passes to vgchange to activate the VG are incorrect). It manages an
Linux Volume Manager volume (LVM) as an HA resource.
[Potential Regression]
I don't expect regression, the missing "-" need to be there to
properly perform the activation. Once the activation will work using
the "-", it's not impossible that one finds other corner situation due
to the fact that the activation now working, but IMHO they'll be
consider bugs, not regression to this SRU.
[Other Infos]
* Redhat Bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1612828
* Upstream fix:
https://github.com/ClusterLabs/resource-agents/commit/5a664525a20d3d5094912322be4faac668e4920e
$ git describe --contains 5a664525a20d3d5094912322be4faac668e4920e
v4.2.0rc1~42^2
$ rmadison resource-agents
resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates # lvm-tag.sh
doesn't exist yet.
=> resource-agents | 1:4.1.0~rc1-1ubuntu1.1 | bionic-updates
resource-agents | 1:4.2.0-1ubuntu1.1 | disco-updates
resource-agents | 1:4.2.0-1ubuntu2 | eoan
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug/1839366/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1839366] Re: LVM: fix missing dash
** Tags added: sts
** Description changed:
heartbeat/lvm-tag.sh
vgchange_activate_options="aly --config
activation{volume_list=[\"@${OUR_TAG}\"]}"
is missing a - in front of aly. The - can be seen in the deactivate
line:
vgchange_deactivate_options="-aln"
Upstream fix:
https://github.com/ClusterLabs/resource-agents/pull/1190/files
Version: 1:4.1.0~rc1-1ubuntu1.1
+
+ [Other Infos]
+
+ * Upstream fix: https://github.com/ClusterLabs/resource-
+ agents/commit/5a664525a20d3d5094912322be4faac668e4920e
+
+ $ git describe --contains 5a664525a20d3d5094912322be4faac668e4920e
+ v4.2.0rc1~42^2
+
+ $ rmadison resource-agents
+ => resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates
+ => resource-agents | 1:4.1.0~rc1-1ubuntu1.1 | bionic-updates
+ resource-agents | 1:4.2.0-1ubuntu1.1 | disco-updates
+ resource-agents | 1:4.2.0-1ubuntu2 | eoan
** Also affects: resource-agents (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: resource-agents (Ubuntu Xenial)
Importance: Undecided
Status: New
** Changed in: resource-agents (Ubuntu)
Status: New => Fix Released
** Changed in: resource-agents (Ubuntu Bionic)
Status: New => In Progress
** Changed in: resource-agents (Ubuntu Bionic)
Importance: Undecided => Medium
** Changed in: resource-agents (Ubuntu Bionic)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: resource-agents (Ubuntu Xenial)
Assignee: (unassigned) => Eric Desrochers (slashd)
** Changed in: resource-agents (Ubuntu Xenial)
Importance: Undecided => Medium
** Changed in: resource-agents (Ubuntu Xenial)
Status: New => In Progress
** Description changed:
heartbeat/lvm-tag.sh
vgchange_activate_options="aly --config
activation{volume_list=[\"@${OUR_TAG}\"]}"
is missing a - in front of aly. The - can be seen in the deactivate
line:
vgchange_deactivate_options="-aln"
Upstream fix:
https://github.com/ClusterLabs/resource-agents/pull/1190/files
Version: 1:4.1.0~rc1-1ubuntu1.1
[Other Infos]
- * Upstream fix: https://github.com/ClusterLabs/resource-
- agents/commit/5a664525a20d3d5094912322be4faac668e4920e
+ * Redhat Bug:
+ https://bugzilla.redhat.com/show_bug.cgi?id=1612828
+
+ * Upstream fix:
+
https://github.com/ClusterLabs/resource-agents/commit/5a664525a20d3d5094912322be4faac668e4920e
$ git describe --contains 5a664525a20d3d5094912322be4faac668e4920e
v4.2.0rc1~42^2
- $ rmadison resource-agents
- => resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates
- => resource-agents | 1:4.1.0~rc1-1ubuntu1.1 | bionic-updates
- resource-agents | 1:4.2.0-1ubuntu1.1 | disco-updates
- resource-agents | 1:4.2.0-1ubuntu2 | eoan
+ $ rmadison resource-agents
+ => resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates
+ => resource-agents | 1:4.1.0~rc1-1ubuntu1.1 | bionic-updates
+ resource-agents | 1:4.2.0-1ubuntu1.1 | disco-updates
+ resource-agents | 1:4.2.0-1ubuntu2 | eoan
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1839366
Title:
LVM: fix missing dash
Status in resource-agents package in Ubuntu:
Fix Released
Status in resource-agents source package in Xenial:
In Progress
Status in resource-agents source package in Bionic:
In Progress
Bug description:
[Impact]
lvm-tag.sh line 150 is missing a dash in front of 'aly' flags. This is
causing lvm resource to fail during start:
heartbeat/lvm-tag.sh
vgchange_activate_options="aly --config
activation{volume_list=[\"@${OUR_TAG}\"]}"
is missing a - in front of aly. The - can be seen in the deactivate
line:
vgchange_deactivate_options="-aln"
Upstream fix:
https://github.com/ClusterLabs/resource-agents/pull/1190/files
Version: 1:4.1.0~rc1-1ubuntu1.1
[Test Case]
[Potential Regression]
[Other Infos]
* Redhat Bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1612828
* Upstream fix:
https://github.com/ClusterLabs/resource-agents/commit/5a664525a20d3d5094912322be4faac668e4920e
$ git describe --contains 5a664525a20d3d5094912322be4faac668e4920e
v4.2.0rc1~42^2
$ rmadison resource-agents
=> resource-agents | 1:3.9.7-1ubuntu1.1 | xenial-updates
=> resource-agents | 1:4.1.0~rc1-1ubuntu1.1 | bionic-updates
resource-agents | 1:4.2.0-1ubuntu1.1 | disco-updates
resource-agents | 1:4.2.0-1ubuntu2 | eoan
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/resource-agents/+bug
[Group.of.nepali.translators] [Bug 1835818] Re: snmpd causes autofs mount points to be mounted on service start/restart
** Changed in: net-snmp (Ubuntu Cosmic) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1835818 Title: snmpd causes autofs mount points to be mounted on service start/restart Status in net-snmp package in Ubuntu: In Progress Status in net-snmp source package in Xenial: In Progress Status in net-snmp source package in Bionic: In Progress Status in net-snmp source package in Cosmic: Won't Fix Status in net-snmp source package in Disco: In Progress Status in net-snmp source package in Eoan: In Progress Bug description: [Impact] Autofs direct map triggers are visible in /etc/mtab. On boot, when snmpd starts, it iterates over the entries in /etc/mtab and performs statfs() on them. This trigger automount to mount autofs mounts even if the user does not explicitly access them. However this happens only if autofs service is started before snmpd. If snmpd stars first /etc/mtab is not yet populated with autofs mounts and therefore are not mounted. When there a few autofs mount points the impact is insignificant. However when there are thousands of them, this causes unnecessary overhead on operations such as df. This also delays the system shutdown time since everything needs to be unmounted. [Test Case] *** Test Case 1 - During boot: The user that brought this issue to our attention would observe all autofs mounts be mounted at boot, because in their environment autofs would start first. In my environment snmpd starts first so to reproduce I had to add a small delay in snmpd init script. In /etc/init.d/snmp : @@ -36,6 +36,8 @@ cd / case "$1" in start) +# Delay snmp start +sleep 2 log_daemon_msg "Starting SNMP services:" # remove old symlink with previous version if [ -L /var/run/agentx ]; then $cat /etc/auto.master /- /etc/auto.nfs --timeout=30 $cat /etc/auto.nfs /home/test1 -fstype=nfs,hard,intr,nosuid,no-subtree-check,tcp :/srv/export/test1 /home/test2 -fstype=nfs,hard,intr,nosuid,no-subtree-check,tcp :/srv/export/test2 Reboot vm, syslog entries : # Autofs starts Jul 11 11:04:16 xenial-vm3 autofs[1295]: * Starting automount... Jul 11 11:04:16 xenial-vm3 automount[1357]: Starting automounter version 5.1.1, master map /etc/auto.master Jul 11 11:04:16 xenial-vm3 automount[1357]: using kernel protocol version 5.02 # Mount triggers, now visible in mtab Jul 11 11:04:16 xenial-vm3 automount[1357]: mounted direct on /home/test1 with timeout 300, freq 75 seconds Jul 11 11:04:16 xenial-vm3 automount[1357]: mounted direct on /home/test2 with timeout 300, freq 75 seconds Jul 11 11:04:16 xenial-vm3 autofs[1295]:...done. ... # SNMP starts Jul 11 11:04:18 xenial-vm3 snmpd[1294]: * Starting SNMP services: Jul 11 11:04:18 xenial-vm3 systemd[1]: proc-sys-fs-binfmt_misc.automount: Got automount request for /proc/sys/fs/binfmt_misc, triggered by 1394 (snmpd) Jul 11 11:04:18 xenial-vm3 systemd[1]: Mounting Arbitrary Executable File Formats File System... Jul 11 11:04:18 xenial-vm3 systemd[1]: Mounted Arbitrary Executable File Formats File System. Jul 11 11:04:18 xenial-vm3 automount[1357]: attempting to mount entry /home/test1 <== Jul 11 11:04:18 xenial-vm3 kernel: [8.880685] FS-Cache: Loaded Jul 11 11:04:18 xenial-vm3 kernel: [8.889318] FS-Cache: Netfs 'nfs' registered for caching Jul 11 11:04:18 xenial-vm3 kernel: [8.902672] NFS: Registering the id_resolver key type Jul 11 11:04:18 xenial-vm3 kernel: [8.902680] Key type id_resolver registered Jul 11 11:04:18 xenial-vm3 kernel: [8.902682] Key type id_legacy registered Jul 11 11:04:18 xenial-vm3 automount[1357]: mounted /home/test1 <== Jul 11 11:04:18 xenial-vm3 automount[1357]: attempting to mount entry /home/test2 <== Jul 11 11:04:18 xenial-vm3 kernel: [9.163011] random: nonblocking pool is initialized Jul 11 11:04:18 xenial-vm3 automount[1357]: mounted /home/test2 <=== *** Test Case 2 - Restart snmpd : To reproduce this case, autofs mounts should not be mounted to begin with. (restart autofs or let it expire) #systemctl restart snmpd.service Syslog entries : Jul 11 11:15:40 xenial-vm3 systemd[1]: Stopping LSB: SNMP agents... Jul 11 11:15:40 xenial-vm3 snmpd[1668]: * Stopping SNMP services: Jul 11 11:15:40 xenial-vm3 snmpd[1434]: Received TERM or STOP signal... shutting down... Jul 11 11:15:40 xenial-vm3 systemd[1]: Stopped LSB: SNMP agents. Jul 11 11:15:40 xenial-vm3 systemd[1]: Starting LSB: SNMP agents... Jul 11 11:15:42 xenial-vm3 snmpd[1677]: * Starting SNMP services: Jul 11 11:15:42 xenial-vm3 automount[1357]: attempting to mount entry /home/test1 <=== Jul 11 11:15:42 xenial-vm3 auto
[Group.of.nepali.translators] [Bug 1681909] Re: kdump is not captured in remote host when kdump over ssh is configured
Marking Cosmic as 'Won't fix'. Ubuntu 18.10 (Cosmic Cuttlefish) End Of Life reached on July 18 2019. ** Changed in: makedumpfile (Ubuntu Cosmic) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1681909 Title: kdump is not captured in remote host when kdump over ssh is configured Status in The Ubuntu-power-systems project: In Progress Status in makedumpfile package in Ubuntu: In Progress Status in makedumpfile source package in Xenial: In Progress Status in makedumpfile source package in Bionic: In Progress Status in makedumpfile source package in Cosmic: Won't Fix Status in makedumpfile source package in Disco: In Progress Status in makedumpfile source package in Eoan: In Progress Bug description: [Impact] * Kdump over network (like NFS mount or SSH dump) relies on network- online target from systemd. Even so, there are some NICs that report "Link Up" state but aren't ready to transmit packets. This is a generally bad behavior that is credited probably to NIC firmware delays, usually not fixable from drivers. Some adapters known to act like this are bnx2x, tg3 and ixgbe. * Kdump is a mechanism that may be a last resort to debug complex/hard to reproduce issues, so it's interesting to increase its reliability / resilience. We then propose here a solution/quirk to this issue on network dump by adding a retry/delay mechanism; if it's a network dump, kdump will retry some times and sleep between the attempts in order to exclude the case of NICs that aren't ready yet but will soon be able to transmit packets. * Although first reported by IBM in PowerPC arch, the scope for this issue is the NIC, and it was later reported in x86 arch too. [Test case] Usually it's difficult to naturally reproduce this issue in a deterministic way, but we have an artificial test case on comment #24 of this LP. Also, we have a report from this bug in which the user managed to reproduce the problem consistently - it's fixed after testing our solution. [Regression potential] There's not a clear regression potential here since it's just a retry/delay mechanism. Some potential problems may come from bad coding in the script. The delay between attempts is only 3 sec per iteration, so it shouldn't block the kdump progress for a high amount of time at once. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu-power-systems/+bug/1681909/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1832223] Re: glusterfs in bionic is EOL
** Description changed: According to glusterfs release schedule[0], the glusterfs version[1] found in bionic 'universe' reached EOL at upstream level. + + 3.13 was a short term maintenance release, it reached end of life (EOL) + with the release of 4.0.0.[2] As I create this bug, only 4.1 and late are still 'maintained' [0]- https://www.gluster.org/release-schedule/ [1]- rmadison: glusterfs-server | 3.13.2-1build1 | bionic/universe glusterfs-server | 3.13.2-1ubuntu1 | bionic-proposed/universe + + [2]- https://docs.gluster.org/en/latest/release-notes/4.0.0/ ** Summary changed: - glusterfs in bionic is EOL + glusterfs in bionic/xenial is EOL ** Description changed: According to glusterfs release schedule[0], the glusterfs version[1] - found in bionic 'universe' reached EOL at upstream level. + found in Bionic and Xenial 'universe' reached EOL at upstream level. 3.13 was a short term maintenance release, it reached end of life (EOL) with the release of 4.0.0.[2] As I create this bug, only 4.1 and late are still 'maintained' [0]- https://www.gluster.org/release-schedule/ [1]- rmadison: - glusterfs-server | 3.13.2-1build1 | bionic/universe - glusterfs-server | 3.13.2-1ubuntu1 | bionic-proposed/universe + glusterfs | 3.7.6-1ubuntu1 | xenial/universe | source + glusterfs | 3.13.2-1build1 | bionic/universe | source + glusterfs | 3.13.2-1ubuntu1 | bionic-proposed/universe | source + glusterfs | 3.13.2-1ubuntu1 | bionic-updates/universe | source [2]- https://docs.gluster.org/en/latest/release-notes/4.0.0/ ** Also affects: glusterfs (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: glusterfs (Ubuntu Xenial) Importance: Undecided => Low ** Description changed: According to glusterfs release schedule[0], the glusterfs version[1] found in Bionic and Xenial 'universe' reached EOL at upstream level. - 3.13 was a short term maintenance release, it reached end of life (EOL) - with the release of 4.0.0.[2] + 3.7 has been released in November 2015. + 3.13 has been released in January 2018. + + Note: 3.13 was a short term maintenance release, it reached end of life + (EOL) with the release of 4.0.0.[2] As I create this bug, only 4.1 and late are still 'maintained' [0]- https://www.gluster.org/release-schedule/ [1]- rmadison: - glusterfs | 3.7.6-1ubuntu1 | xenial/universe | source - glusterfs | 3.13.2-1build1 | bionic/universe | source - glusterfs | 3.13.2-1ubuntu1 | bionic-proposed/universe | source - glusterfs | 3.13.2-1ubuntu1 | bionic-updates/universe | source + glusterfs | 3.7.6-1ubuntu1 | xenial/universe | source + glusterfs | 3.13.2-1build1 | bionic/universe | source + glusterfs | 3.13.2-1ubuntu1 | bionic-proposed/universe | source + glusterfs | 3.13.2-1ubuntu1 | bionic-updates/universe | source [2]- https://docs.gluster.org/en/latest/release-notes/4.0.0/ -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1832223 Title: glusterfs in bionic/xenial is EOL Status in glusterfs package in Ubuntu: Fix Released Status in glusterfs source package in Xenial: New Status in glusterfs source package in Bionic: New Bug description: According to glusterfs release schedule[0], the glusterfs version[1] found in Bionic and Xenial 'universe' reached EOL at upstream level. 3.7 has been released in November 2015. 3.13 has been released in January 2018. Note: 3.13 was a short term maintenance release, it reached end of life (EOL) with the release of 4.0.0.[2] As I create this bug, only 4.1 and late are still 'maintained' [0]- https://www.gluster.org/release-schedule/ [1]- rmadison: glusterfs | 3.7.6-1ubuntu1 | xenial/universe | source glusterfs | 3.13.2-1build1 | bionic/universe | source glusterfs | 3.13.2-1ubuntu1 | bionic-proposed/universe | source glusterfs | 3.13.2-1ubuntu1 | bionic-updates/universe | source [2]- https://docs.gluster.org/en/latest/release-notes/4.0.0/ To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/glusterfs/+bug/1832223/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1668639] Re: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d
It is fixed in Ubuntu Bionic and late but this LP bug have never been mentioned in the changelog, which explains why the status didn't change until now (after a manual status change from my part) Xenial hasn't been fix, I did some quick verification and base on the fix, which add a Depends as follow: debian/control: init-system-helpers (>= 1.47~) and considering rmadison: init-system-helpers | 1.29ubuntu1 | xenial | source, all init-system-helpers | 1.29ubuntu4 | xenial-updates | source, all I'm afraid the fix won't work for Xenial. With that being said, I will set Xenial to "Won't fix". Please feel free to re-open it if you judge Xenial need the fix by providing good justification/rational. - Eric ** Changed in: rsyslog (Ubuntu Zesty) Status: Won't Fix => Fix Released ** Changed in: rsyslog (Ubuntu Xenial) Status: In Progress => Fix Released ** Changed in: rsyslog (Ubuntu Xenial) Status: Fix Released => Won't Fix ** Changed in: rsyslog (Ubuntu Trusty) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1668639 Title: Add a trigger to reload rsyslog when a new configuration file is dropped in /etc/rsyslog.d Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Trusty: Won't Fix Status in rsyslog source package in Xenial: Won't Fix Status in rsyslog source package in Zesty: Fix Released Status in rsyslog source package in Artful: Fix Released Status in rsyslog package in Debian: Fix Released Bug description: [Impact] Servers or cloud instances will not log important messages after initial deployment. Manual reboot or restart of services is necessary to get expected behaviour. [Test Case] 1) Install, enable and start haproxy 2) Observe that /etc/rsyslog.d/49-haproxy.conf is installed 3) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log is NOT created 4) Restart rsyslog service 5) Observe that /var/lib/haproxy/dev/log and /var/log/haproxy.log IS created 6) Restart haproxy service and observe that log now is filled with entries With the patched deb steps 3,4 and 6 becomes irrelevant and everything works out of the box. [Regression Potential] Minimal. This patch merges a patch from Debian where a trigger is added to the rsyslog package that fires when other debs drop files into /etc/rsyslog.d. [Original Bug Description] rsyslog should reload its configuration when other packages drop configuration in /etc/rsyslog.d https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791337 https://anonscm.debian.org/cgit/collab- maint/rsyslog.git/commit/?id=8d4074003f8fb19dae07c59dd19f0540a639210f To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/rsyslog/+bug/1668639/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828901] Re: add PTY support for runuser
** Changed in: util-linux (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: util-linux (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) ** Bug watch added: Debian Bug tracker #815922 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 ** Also affects: util-linux (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 Importance: Unknown Status: Unknown ** Changed in: util-linux (Ubuntu Xenial) Status: New => In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828901 Title: add PTY support for runuser Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: In Progress Status in util-linux package in Debian: Unknown Bug description: [IMPACT] [TEST CASE] [REGRESSION POTENTIAL] [OTHER INFORMATION] Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 This is fixing a CVE vulnerability: https://security-tracker.debian.org/tracker/CVE-2016-2779 Restricting ioctl on the kernel side seems the better approach, patches have been posted to kernel-hardening list http://www.openwall.com/lists/oss-security/2016/02/27/1 https://marc.info/?l=util-linux-ng&m=145694736107128&w=2 2.31 introduces a new --pty option to separate privileged and unprivileged shells (not enabled by default and the cli switch is necessary). [ORIGINAL DESCRIPTION] After a discussion with security team on what would be their recommended way to run command as 'juju-user' inside the sosreport juju plugin which is run as root, in order to avoid using 'sudo' or 'su' command. The recommendation was to use 'runuser -P' runuser PTY support is present in Bionic and late, but not in Xenial. I'm opening this bug in the effort to update util-linux/runuser code in Xenial to add the PTY support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1828901/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828901] [NEW] add PTY support for runuser
Public bug reported: [IMPACT] [TEST CASE] [REGRESSION POTENTIAL] [OTHER INFORMATION] Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 This is fixing a CVE vulnerability: https://security-tracker.debian.org/tracker/CVE-2016-2779 Restricting ioctl on the kernel side seems the better approach, patches have been posted to kernel-hardening list http://www.openwall.com/lists/oss-security/2016/02/27/1 https://marc.info/?l=util-linux-ng&m=145694736107128&w=2 2.31 introduces a new --pty option to separate privileged and unprivileged shells (not enabled by default and the cli switch is necessary). [ORIGINAL DESCRIPTION] After a discussion with security team on what would be their recommended way to run command as 'juju-user' inside the sosreport juju plugin which is run as root, in order to avoid using 'sudo' or 'su' command. The recommendation was to use 'runuser -P' runuser PTY support is present in Bionic and late, but not in Xenial. I'm opening this bug in the effort to update util-linux/runuser code in Xenial to add the PTY support. ** Affects: util-linux (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: util-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Tags: sts ** Tags added: sts ** Also affects: util-linux (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: util-linux (Ubuntu) Status: New => Fix Released ** Description changed: - After a discussion with security team on what would be their recommended - way to run command as 'juju-user' inside the sosreport juju plugin which - is run as root, in order to avoid using 'sudo' or 'su' command. + [IMPACT] + + [TEST CASE] + + [REGRESSION POTENTIAL] + + [OTHER INFORMATION] + + Debbug: + https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 + + This is fixing a CVE vulnerability: + https://security-tracker.debian.org/tracker/CVE-2016-2779 + + Restricting ioctl on the kernel side seems the better approach, patches have been posted to kernel-hardening list + http://www.openwall.com/lists/oss-security/2016/02/27/1 + https://marc.info/?l=util-linux-ng&m=145694736107128&w=2 + 2.31 introduces a new --pty option to separate privileged and unprivileged + shells (not enabled by default and the cli switch is necessary). + + [ORIGINAL DESCRIPTION] + After a discussion with security team on what would be their recommended way to run command as 'juju-user' inside the sosreport juju plugin which is run as root, in order to avoid using 'sudo' or 'su' command. The recommendation was to use 'runuser -P' runuser PTY support is present in Bionic and late, but not in Xenial. I'm opening this bug in the effort to update util-linux/runuser code in Xenial to add the PTY support. -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828901 Title: add PTY support for runuser Status in util-linux package in Ubuntu: Fix Released Status in util-linux source package in Xenial: New Bug description: [IMPACT] [TEST CASE] [REGRESSION POTENTIAL] [OTHER INFORMATION] Debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815922 This is fixing a CVE vulnerability: https://security-tracker.debian.org/tracker/CVE-2016-2779 Restricting ioctl on the kernel side seems the better approach, patches have been posted to kernel-hardening list http://www.openwall.com/lists/oss-security/2016/02/27/1 https://marc.info/?l=util-linux-ng&m=145694736107128&w=2 2.31 introduces a new --pty option to separate privileged and unprivileged shells (not enabled by default and the cli switch is necessary). [ORIGINAL DESCRIPTION] After a discussion with security team on what would be their recommended way to run command as 'juju-user' inside the sosreport juju plugin which is run as root, in order to avoid using 'sudo' or 'su' command. The recommendation was to use 'runuser -P' runuser PTY support is present in Bionic and late, but not in Xenial. I'm opening this bug in the effort to update util-linux/runuser code in Xenial to add the PTY support. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/util-linux/+bug/1828901/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1775195] Re: [sync][sru] Backport of sosreport v3.6
** Changed in: sosreport (Ubuntu Trusty) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1775195 Title: [sync][sru] Backport of sosreport v3.6 Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: Fix Released Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Cosmic: Fix Released Status in sosreport package in Debian: Fix Released Bug description: [Impact] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1 | testing sosreport | 3.6-1 | unstable and I have synced sosreport (Debian->Ubuntu Disco). It would be great to have sosreport v3.6 SRU'd in supported stable releases once official release upstream, considering the fact that the release (especially LTSes) will be supported for a couple of years still: [https://www.ubuntu.com/about/release-cycle] Ubuntu 16.04 | support until 2023 Ubuntu 18.04 | support until 2024 sosreport is widely use by Canonical support team to troubleshoot UA customer and other vendors and community users. These improvement will benefit all of them. sosreport 3.6 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for v3.5 (LP: #1734983) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub,zfs, ipsec, ...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. [Things identified during our testing] * [minor] juju plugin detection doesn't work if installed as a snap: https://github.com/sosreport/sos/issues/1475 Fix already submitted upstream. This is not a new thing, juju in sosreport have always been made for .deb so far. It's not a regression introduce in 3.6, and IMHO not a blocker for the current SRU. It could be patch later on when the upstream discussion/approval will be done. * [major] Certain plugins may or may not substitute sensible information such as password. Upstream fix found and applied : https://github.com/sosreport/sos/commit/b96bdab - d/p/fix-string-substitution-method.patch * [minor] kernel plugin dont collect some tracing instance files https://github.com/sosreport/sos/commit/d6379b5 LP: #1803735 - d/p/dont-collect-some-tracing-instance-files.patch [Regression Potential] * Regression risk is low, as long as the core functionnality works (Package manager, ...) * autopkgtest reveal no regressions. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would be impossible but we have tested the ones we considered important and Ubuntu related (canonical-livepatch, MAAS, juju, openstack, ...). Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't collect system logs, debug information or anything this plugin was instructed to do, usually won't affect other plugin to perform as expected and/or sosreport to complete. [Other Info] [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 [Original Description] sosreport 3.6 has been released in June 2018 with further enhancements in core sosreport functionality. A sync can be done since all Ubuntu patches has been integrated in 3.6 I already did the request for debian : https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=900818 and 3.6 has been uploaded in Debian since then (Thanks to caribou): sosreport | 3.6-1| testing sosreport | 3.6-1| unstable Now, it would be great to have sosreport v3.6 in Development Release & SRU'd in all supported stable release once official release upstream, considering the fact that the release will contain a number of enhancements, new features, and bug fixes and that sosreport is widely use by Canonical support team to troubleshoot UA customer. Just like we did for v3.5. [v3.6 Release notes] # https://github.com/sosreport/sos/releases/tag/3.6 The sos team is pleased to announce the release of sos-3.6. This is a significant release containing a number of enhancements, new features, and
[Group.of.nepali.translators] [Bug 1803735] Re: [kernel] dont collect some tracing instance files
** Changed in: sosreport (Ubuntu Trusty) Status: In Progress => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1803735 Title: [kernel] dont collect some tracing instance files Status in sosreport package in Ubuntu: Fix Released Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: Fix Released Status in sosreport source package in Bionic: Fix Released Status in sosreport source package in Cosmic: Fix Released Status in sosreport source package in Disco: Fix Released Bug description: ** Minor bug found in the current SRU for LP: #1775195 ** [Impact] * When kernel tracing event is in used, sosreport hang at the kernel plugin. [Test Case] * Install rasdaemon $ apt-get install rasdaemon -y * Run sosreport from -proposed (See Bug #1775195) sosreport | 3.6-1ubuntu0.16.04.1 | xenial-proposed sosreport | 3.6-1ubuntu0.18.04.1 | bionic-proposed sosreport | 3.6-1ubuntu0.18.10.1 | cosmic-proposed Only kernel plugin is needed to trigger the hang : $ sosreport -o kernel [Regression Potential] * Regression low. The fix is simply appending files to the the kernel plugin into an existing list of files to be ignored in order to stop hanging when trying to collect them when tracing event is in used. [Other Info] * Upstream fix: https://github.com/sosreport/sos/pull/1445/commits/d6379b5ba0f381ea8ec2403b9985100a946a5866 * Origin : https://github.com/sosreport/sos/pull/1445 [Git bisect log] git bisect start '--term-old' 'broken' '--term-new' 'fixed' # fixed: [848b110f83697814c72ac93b36e786ff9dafc0fc] [powerpc] Add support to collect DLPAR and LPM related logs git bisect fixed 848b110f83697814c72ac93b36e786ff9dafc0fc # broken: [967c015518c1aa135aa6007329972f031ffe12fc] [plugins] Remove unnecessary sizelimits git bisect broken 967c015518c1aa135aa6007329972f031ffe12fc # broken: [e89c7f7744ac4b39956ef3122cdb1489d2676664] [multipath] use -ll for path checker and prio inclusion git bisect broken e89c7f7744ac4b39956ef3122cdb1489d2676664 # broken: [0ea62d1ea57f41c1b75ccb83e69fdda386a7d280] [Plugin] fix exception raise in Plugin._copy_dir() git bisect broken 0ea62d1ea57f41c1b75ccb83e69fdda386a7d280 # broken: [2e3e1479df19aca58d8bd9f80ef3d6e7a9641211] [utilities] use correct comparison-to-None style git bisect broken 2e3e1479df19aca58d8bd9f80ef3d6e7a9641211 # broken: [e108d7c03834446f8dac66ad69f5eade4f2c5fce] [archive] fix and simplify directory destination rewriting git bisect broken e108d7c03834446f8dac66ad69f5eade4f2c5fce # broken: [f8ee9c4b87c6c3b8aa2bda3425f0e53499515363] [openstack_*] relax enabling of OSP RedHat plugins git bisect broken f8ee9c4b87c6c3b8aa2bda3425f0e53499515363 # fixed: [d6379b5ba0f381ea8ec2403b9985100a946a5866] [kernel] dont collect some tracing instance files git bisect fixed d6379b5ba0f381ea8ec2403b9985100a946a5866 # first fixed commit: [d6379b5ba0f381ea8ec2403b9985100a946a5866] [kernel] dont collect some tracing instance files To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1803735/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1828467] Re: [sru] remove juju-db stop/start service interactions
** Changed in: sosreport (Ubuntu Trusty) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1828467 Title: [sru] remove juju-db stop/start service interactions Status in sosreport package in Ubuntu: In Progress Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Cosmic: New Status in sosreport source package in Disco: New Status in sosreport source package in Eoan: In Progress Bug description: [Impact] The juju plugin will stop and start the juju-db service during data collection. sosreport should not impact running services, or attempt to recover them. This has been reported upstream[0] and will be fixed by the juju 2.x refactor[1] This is a stop-gap tracking the removal of the juju-db service restart code in existing sosreport releases. [0] - https://github.com/sosreport/sos/issues/1653 [1] - https://github.com/sosreport/sos/pull/1670 [Test Case] * Make sure you are in the juju controller. * Install sosreport * Look mongod PID before ** $ pidof mongod * Run sosreport, ensuring that the juju plugin is exercised * Confirm the juju-db service was not restarted, and mongoexport data captured. * Look mongod PID after ** $ pidof mongod Check for errors while running, or in /tmp/sosreport-*/sos_logs/ The offending function ensure_service_is_running() in theory doesn't create any harm unless juju plugin is exercised during a sosreport run from a juju controller where mongod and/or juju-db resides. [Regression Potential] * Risk is low. * Change is limited in scope to the juju plugin. * Worst-case scenario is that the mongoexport command will fail to collect any data, which won't affect core functionality of sosreport itself nor impact other sosreport plugins. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1828467/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1777131] Re: Wrong RAM size shown for server
Upstream bug : https://ezix.org/project/ticket/662 Upstream commit : https://ezix.org/src/pkg/lshw/commit/640615983fbf976e66931164a9ae1bd64da9668b I'm working on a backport fix for Xenial. # git describe --contains 6406159 B.02.17~26 # rmadison => lshw | 02.17-1.1ubuntu3.5 | xenial-updates lshw | 02.18-0.1ubuntu6 | bionic lshw | 02.18-0.1ubuntu6.18.04.1 | bionic-updates lshw | 02.18-0.1ubuntu7 | cosmic lshw | 02.18-0.1ubuntu7 | disco lshw | 02.18.85-0.1ubuntu1 | eoan ** Bug watch added: Ezix Trac #662 http://ezix.org/project/ticket/662 ** Also affects: lshw (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: lshw (Ubuntu) Status: Confirmed => Fix Released ** Changed in: lshw (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: lshw (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: lshw (Ubuntu Xenial) Status: New => In Progress ** Tags added: sts -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1777131 Title: Wrong RAM size shown for server Status in MAAS: Invalid Status in lshw package in Ubuntu: Fix Released Status in lshw source package in Xenial: In Progress Bug description: Currently MAAS relies on DMI for the info about RAM size. DMI seems not to be always correct, this results in wrong RAM amount shown in the MAAS UI. In my case : .. handle: DMI:0017 - lshw:description: DIMM Synchronous 2666 MHz (0.4 ns) - lshw:product: M386A8K40BM2-CTD - lshw:vendor: Samsung - lshw:physid: 0 - lshw:serial: 375610DE - lshw:slot: P1-DIMMA1 - lshw:size: units: bytes 34358689792 .. full machine yaml : https://pastebin.canonical.com/p/TqpvzXj2sx/ However product M386A8K40BM2-CTD is actually 64GB: https://memory.net/product/m386a8k40bm2-ctd-samsung-1x-64gb-ddr4-2666-lrdimm-pc4-21300v-l-quad-rank-x4-module/ I have 12 of those, and on boot it shows me the correct amount 12 * 64GB: ubuntu:~$ dmesg | grep Memory [0.00] Memory: 791161372K/803909324K available (8541K kernel code, 1313K rwdata, 4000K rodata, 1512K init, 1316K bss, 12747952K reserved, 0K cma-reserved) ubuntu:~$ free -m totalusedfree shared buff/cache available Mem: 7726583828 768156 18 672 766751 Swap: 8191 08191 /var/log/maas : https://private- fileshare.canonical.com/~dima/varlogmaas-15062018.tar ubuntu$ dpkg -l '*maas*'|cat Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ NameVersion Architecture Description +++-===---= un maas (no description available) ii maas-cli2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all MAAS client and command-line interface un maas-cluster-controller (no description available) ii maas-common 2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all MAAS server common files ii maas-dhcp 2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all MAAS DHCP server ii maas-dns2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all MAAS DNS server ii maas-proxy 2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all MAAS Caching Proxy ii maas-rack-controller2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all Rack Controller for MAAS ii maas-region-api 2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all Region controller API service for MAAS ii maas-region-controller 2.3.3-6498-ge4db91d-0ubuntu1~16.04.1 all Region Controller for MAAS un maas-region-controller-min (no description available) un python-django-maas (no description available) un python-maas-client (no description available) un python-maas-provisioningserver
[Group.of.nepali.translators] [Bug 1825010] Re: [sru] Backport of sosreport v3.7
debbug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928049 ** Bug watch added: Debian Bug tracker #928049 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928049 ** Also affects: sosreport (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=928049 Importance: Unknown Status: Unknown ** Changed in: sosreport (Ubuntu Trusty) Status: New => Won't Fix ** Summary changed: - [sru] Backport of sosreport v3.7 + [sru] new sosreport v3.7 -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1825010 Title: [sru] new sosreport v3.7 Status in sosreport package in Ubuntu: New Status in sosreport source package in Trusty: Won't Fix Status in sosreport source package in Xenial: New Status in sosreport source package in Bionic: New Status in sosreport source package in Cosmic: New Status in sosreport source package in Disco: New Status in sosreport source package in Eoan: In Progress Status in sosreport package in Debian: Unknown Bug description: [Impact] sosreport 3.7 has been released including further enhancements in core sosreport functionality: https://github.com/sosreport/sos/releases/tag/3.7 It would be great to find sosreport v3.7 in supported stable releases, considering the fact that the release (especially LTSes) will be supported for a couple of years still: sosreport is widely use by Canonical support team to troubleshoot UA customer, other vendors and community users. These improvement will benefit all of them. sosreport 3.7 contains a number of enhancements, new features, and bug fixes. (See "Release Note" below) Just like we did for : - v3.5 (LP: #1734983) - v3.6 (LP: #1775195) [Test Case] * Install sosreport * Run sosreport - sosreport plugins are separated by subject (juju, MAAS, grub, zfs,...) and allow the capability to detect (based on file and package) if it exist and/or installed and then only run the necessary plugins based on the detection made. It creates a files under /tmp in the form of : /tmp/sosreport-sos37xenial-20190416160152.tar.xz # Actual sosreport /tmp/sosreport-sos37X-20190416160152.tar.xz.md5 # MD5 checksum Only accessible by root user: -rw--- 1 root root 1619000 Apr 16 16:07 /tmp/sosreport-sos37X-20190416160152.tar.xz Ideally, since we can't test all plugins, it would be good to have a few testers using different HW, kernel, installation with a focus on juju, MAAS, LXD, canonical-livepatch, Looking for any error on the terminal while sosreport is running or post-sosreport run in /tmp/sosreport-*/sos_logs/ [Regression Potential] * Risk is low. * We did some dogfooding on sosreport, but we can't test each individual plugins and scenarios one by one, that would just be impossible but we have tested the ones we considered important and Ubuntu/Canonical related (canonical-livepatch, MAAS, juju, snappy), Openstack, mandatory file (logs, dmidecode, installed-debs and so on) * Plugin bug is an eventuality, but they are usually easy to fix and the impact will be isolated to the plugin itself or section of the plugin. If a plugin has a bug the worst that could happen is that this particular plugin won't (or partially) collect information. [Other information] * Release note: https://github.com/sosreport/sos/releases/tag/3.7 * Plugins: sosreport contains in total: 284 plugins - 185 plugins that used UbuntuPlugin and/or DebianPlugin that might been triggered at sosreport run. - 97 plugins not using UbuntuPlugin and/or DebianPlugin. Basically useless in a Ubuntu context. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/sosreport/+bug/1825010/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1825010] [NEW] v3.7 is now the latest release
Public bug reported: https://github.com/sosreport/sos/releases/tag/3.7 --- The sos team is pleased to announce the release of sos-3.7. This is a significant release containing a large number of enhancements, new features, and bug fixes, including: New distribution policies for CentOS and Amazon Linux 19 new plugins: candlepin, cifs, cockpit, composer, crio, gssproxy, katello, openstack_novajoin, ovirt_node, peripety, podman, pulp, rasdaemon, rhcos, rhv_analyzer, rpmostree, ruby, stratis, sudo Obsolete IPSec plugin removed (in favour of OpenSwan) Support for passphrase and key based encryption of the report archive Ability to encrypt the archive using GPG, with either a key or passphrase New --encrypt-key and --encrypt-pass arguments to sosreport Improved handling of paths containing directory symbolic links (for e.g. /sys) Previous versions of sos would replace intermediate path components that contain a symbolic link to a directory in the host file system with an actual directory in the report archive. The host file system structure is now reflected properly in the report directory structure. New InitSystem abstraction Allows plugin and collection enablement based on the presence of a service, and methods to test whether a given service is currently running LVM2 plugin enhancements Locking fixes for LVM2 metadata and reporting output capture Additional LVM2 logical volume manager report data Append plugin exceptions to sos_logs/*-plugin-exception.txt Previous versions of sos would overwrite earlier exceptions if more than one exception occurred while running a plugin (for example, when an exception occurs in both setup() and postproc() phases). Dry run mode (--dry-run) Allows sos to run without collecting data, or executing commands, and proving a log of actions that would have been taken by a normal run on the current system configuration. Plugin API enhancements SoSPredicates for gating collection on service and kernel module presence, and during dry-run mode Significant enhancements to core features and existing plugins Fixes to threaded exception handling, and interactive debugging with --debug Support for OpenShift 3.10 deployments Improved multipath data collection Fixed RHEL Atomic default command line preset Support for PowerPC DLPAR and LPM logs Additional FIPS and crypto-policies data collection Test suite and CI support for Python-3.7 final Additional systemd listings and statuses Support for user-controlled per-plugin timeouts Do not leave report artefacts in TMP when executing list commands Improvements to command termination in the event of plugin timeouts Policy support for Red Hat Enterprise Linux 8.0 Improved STONITH and watchdog data collection for Pacemaker clusters Support for Debian journald logging in the logs plugin New built-in 'cantboot' preset for collecting information relevant to failed boots Ability to disable default presets on the command line (--preset=none) Support for setting all sosreport command line options (including global and plugin options) in the sos.conf configuration file The deprecated XML reporting module has been removed Continuous integration with the LGTM static analyser (rated 'A') Apache plugin fixed to support --log-size global option Native support for collecting foreman-debug equivalent data in sos --- ** Affects: sosreport (Ubuntu) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Cosmic) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Disco) Importance: Undecided Status: New ** Affects: sosreport (Ubuntu Ee-series) Importance: Low Assignee: Eric Desrochers (slashd) Status: In Progress ** Also affects: sosreport (Ubuntu Ee-series) Importance: Undecided Status: New ** Changed in: sosreport (Ubuntu Ee-series) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: sosreport (Ubuntu Ee-series) Importance: Undecided => Low ** Changed in: sosreport (Ubuntu Ee-series) Status: New => In Progress ** Also affects: sosreport (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Disco) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: sosreport (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bu
[Group.of.nepali.translators] [Bug 1822129] Re: [SRU] leave device name empty so that nova can determine it instead
** Also affects: horizon (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: horizon (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: horizon (Ubuntu Xenial) Status: New => In Progress ** Changed in: horizon (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1822129 Title: [SRU] leave device name empty so that nova can determine it instead Status in Ubuntu Cloud Archive: Confirmed Status in Ubuntu Cloud Archive pike series: Confirmed Status in Ubuntu Cloud Archive queens series: Confirmed Status in Ubuntu Cloud Archive rocky series: Confirmed Status in Ubuntu Cloud Archive stein series: Confirmed Status in horizon package in Ubuntu: Fix Released Status in horizon source package in Xenial: In Progress Status in horizon source package in Bionic: In Progress Status in horizon source package in Cosmic: In Progress Status in horizon source package in Disco: Fix Released Bug description: [IMPACT] Horizon hardcoded 'vda' no matter what (legacy code) for boot volume scenarios. Meaning that if for instance we use an image with scsi decoration[1] horizon will name the device_name as 'vda' when it should be 'sda'. Inside the instance, it will be 'sda' but horizon will show 'vda', if you then attach a second volume the volume will be seen as 'sda' in horizon, but 'sdb' in the instance and so on ... creating a inconsistency, and can also cause in certain circumstance VM to have issue to successfully reboot, hanging with "No bootable device". There is 2 functions (thus fixes) separated as follow: * setFinalSpecBootImageToVolume() which already uses BDMv2, in this case it was just a matter to remove the 'device_name' attribute as suggested per documentation[2]. This function take care of boot image from volume scenario. -> https://review.openstack.org/#/c/644982/ * setFinalSpecBootFromVolumeDevice() which currently uses BDMv1 (legacy), in this case an upgrade to BDMv2 without setting up a 'device_name' attribute is sufficient to fix the issue. This function take care of booting from existing volume and snapshot. -> https://review.openstack.org/648328/ Basically, with theses 2 fixes, it is no longer relying on "vol_device_name= 'vda'" as it was before as it is no longer needed since Liberty (again as per documentation) An instance with scsi decoration will properly show 'sda' and without will show 'vda'.'vda' will still be taken when it's the right thing to do, but not because it is hardcorded like it used to before these fixes. [1] - scsi meta decoration: hw_disk_bus='scsi' hw_scsi_model='virtio-scsi' [2]- https://docs.openstack.org/nova/stein/user/block-device-mapping [TEST CASE] Here's some use case I can think of With fix 1 in setFinalSpecBootImageToVolume(): * Test #1: Use scsi meta data image decoration: hw_disk_bus='scsi' hw_scsi_model='virtio-scsi' 1. Go to the Horizon dashboard and launch an instance 2. Select "Boot from image (creates a new volume)" as Instance Boot Source Expected result: Instance should starts with /dev/sda as root device, instead of 'dev/vda' * Test #2: Use no scsi meta data image decoration 1. Go to the Horizon dashboard and launch an instance 2. Select "Boot from image (creates a new volume)" as Instance Boot Source Expected result: Instance will remain with /dev/vda as root device. No behaviour change here. With fix 2 in setFinalSpecBootFromVolumeDevice(): * Test #1: Creating a server using an existing volume or volume snapshot. [POTENTIAL REGRESSION] * none expected, we basically leave nova to determine the device_name instead of having it force for Horizon by removing the 'device_name' attribute, and we also take benefit of it to upgrade some part of the code from legacy BDMv1 in flavor of BDMv2. * Note: This will not fix device name inconsistency already created instance, but will fix newly created instance after having applied the package from where these fixes have been first introduced. * Both fixes aren't dependant and can be SRU'd separately. [OTHER INFORMATION] * Upstream bug: https://bugs.launchpad.net/nova/+bug/1560965 * Upstream git-review: # Taking care of bootimagefromvolume https://review.openstack.org/644982/ https://github.com/openstack/horizon/commit/4788c4d2f59b8aa08e5f599a6d2c327b6004dc0c # Taking care of existing volume and snapshot
[Group.of.nepali.translators] [Bug 1774032] Re: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous)
To avoid any potential confusion, I have marked Xenial as 'Won't Fix' with the following rationale: It is true that Xenial offers Jewel and Luminous support, but since the 'Add support for ceph version luminous' commit is not backward compatible with previous Ceph version. We can't backport that change in Xenial/16.04 LTS. >From 647ac31bf9db60b1685d6d8d25be65375ba85891 Mon Sep 17 00:00:00 2001 From: Aleksei Zakharov Date: Wed, 4 Oct 2017 11:12:23 +0300 Subject: [PATCH] Add support for ceph version luminous This patch is not backward compatible with previous ceph versions. Regards, Eric ** Also affects: collectd (Ubuntu Xenial) Importance: Undecided Status: New ** Changed in: collectd (Ubuntu Xenial) Status: New => Won't Fix -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1774032 Title: Bionic: CollectD ceph plugin is incompatible with Ceph 12+ (Luminous) Status in collectd package in Ubuntu: Fix Released Status in collectd source package in Xenial: Won't Fix Status in collectd source package in Bionic: In Progress Bug description: ## DRAFT ## [IMPACT] The version of collectd shipped with Ubuntu 18.04 (Bionic) provides a ceph plugin that is incompatible with the version of Ceph shipped in the same distribution. The version of collectd is 5.7.2-2ubuntu1 The version of ceph is 12.2.4-0ubuntu1.1 This patch for collectd is required for correct interoperation with Ceph 12+: https://github.com/collectd/collectd/pull/2464 The first version of collectd to contain this patch is 5.8.0. Without this patch, errors of the following form will be logged by collectd, and many ceph-specific metrics will not be collected: May 28 09:31:56 stor-a collectd[2141]: ceph plugin: cconn_handle_event(name=osd.2,i=0,st=4): error 1 May 28 09:31:56 stor-a collectd[2141]: ceph plugin: ds Bluestore.kvFlushLat.avgtime was not properly initialized. May 28 09:31:56 stor-a collectd[2141]: ceph plugin: JSON handler failed with status -1. [TEST CASE] [POTENTIAL REGRESSION] * Low, Bionic oldest Ceph version support is Luminous, so the backward incompatibility with previous ceph versions is not a problem here. * Upstream faced a segfault situation in the Ceph plugin with Mimic version via issue: https://github.com/collectd/collectd/issues/2572, this problem is also addressed in the current SRU (d/p/ceph-plugin- Fix-2572.patch) * The new Ceph support is already part of debian and Ubuntu Cosmic and Disco. [OTHER INFORMATION] # Upstream commits: 647ac31b Add support for ceph version luminous: https://github.com/collectd/collectd/commit/647ac31bf9db60b1685d6d8d25be65375ba85891 de05fb53 ceph plugin: Fix #2572: https://github.com/collectd/collectd/commit/de05fb53fad6bc998f585b704ca0caeadc14a035 $ git describe --contains 647ac31b collectd-5.8.0~29^2~9 $ git describe --contains de05fb53 collectd-5.8.1~38 # rmadison ==> collectd | 5.7.2-2ubuntu1| bionic/universe collectd | 5.8.0-5.2 | cosmic/universe collectd | 5.8.1-1.2 | disco/universe [ORIGINAL DESCRIPTION] The version of collectd shipped with Ubuntu 18.04 (Bionic) provides a ceph plugin that is incompatible with the version of Ceph shipped in the same distribution. The version of collectd is 5.7.2-2ubuntu1 The version of ceph is 12.2.4-0ubuntu1.1 This patch for collectd is required for correct interoperation with Ceph 12+: https://github.com/collectd/collectd/pull/2464 The first version of collectd to contain this patch is 5.8.0. Without this patch, errors of the following form will be logged by collectd, and many ceph-specific metrics will not be collected: May 28 09:31:56 stor-a collectd[2141]: ceph plugin: cconn_handle_event(name=osd.2,i=0,st=4): error 1 May 28 09:31:56 stor-a collectd[2141]: ceph plugin: ds Bluestore.kvFlushLat.avgtime was not properly initialized. May 28 09:31:56 stor-a collectd[2141]: ceph plugin: JSON handler failed with status -1. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/collectd/+bug/1774032/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1815237] Re: stop shipping "update-pciids" in /usr/sbin
** Changed in: pciutils (Ubuntu Cosmic) Assignee: Eric Desrochers (slashd) => (unassigned) ** Changed in: pciutils (Ubuntu Cosmic) Assignee: (unassigned) => Mark Thomas (markthomas) ** Changed in: pciutils (Ubuntu) Assignee: Eric Desrochers (slashd) => (unassigned) ** Changed in: pciutils (Ubuntu) Assignee: (unassigned) => Mark Thomas (markthomas) ** Changed in: pciutils (Ubuntu Cosmic) Assignee: Mark Thomas (markthomas) => (unassigned) ** Also affects: pciutils (Ubuntu Disco) Importance: Low Assignee: Mark Thomas (markthomas) Status: In Progress -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1815237 Title: stop shipping "update-pciids" in /usr/sbin Status in pciutils package in Ubuntu: In Progress Status in pciutils source package in Precise: Invalid Status in pciutils source package in Trusty: In Progress Status in pciutils source package in Xenial: In Progress Status in pciutils source package in Bionic: In Progress Status in pciutils source package in Cosmic: In Progress Status in pciutils source package in Disco: In Progress Bug description: [IMPACT] pciutils contains a script called 'update-pciids' which offer to user the possibilty to download new version of the PCI ID list from 'http:pciids.sourceforge.net/v2.2/pci.ids' and update the file '/usr/share/misc/pci.ids' accordingly. After a discussion with foundation/security about what would be the best practice between (a) simply use update-pciids script or (b) do an sru to update the list. Option (b) was unanimously judge more viable. (see the irc discussion in the [ORIG DESCRIPTION] section. That brought up another aspect, should Ubuntu keep that script available for user. Foundation/Security team ACK on moving the script to '/usr/share/doc/pciutils/examples/' The motivation behind this is the following : - Injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it. - It alters a dpkg-managed file in /usr/share - Uncheck download over http - [TEST CASE] 1) Install pciutils (if not installed already) # apt-get install pciutils The package come with a pre-define pci.ids vendor list, freeze at the end time it was last SRU'd, merge, sync from Debian. If you perform a 'dmidecode' on a system with recent HW, dmidecode may not know about this new HW since the pci.ids list can have been updated before the HW exist, or got added to the upstream pci vendor list. 2) Check pci.ids (pre-update) # stat /usr/share/misc/pci.ids File: /usr/share/misc/pci.ids Size: 1062022 Blocks: 2080 IO Block: 4096 regular file Device: 10302h/66306d Inode: 8916914 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) ==> Access: 2019-03-13 16:46:34.208000193 -0400 ==> Modify: 2017-04-24 14:35:32.0 -0400 ==> Change: 2019-03-04 15:19:41.001315621 -0500 Birth: - 3) Update pci.ids # update-pciids Downloaded daily snapshot dated 2019-03-14 03:15:02 4) Check pci.ids (pre-update) # stat /usr/share/misc/pci.ids File: /usr/share/misc/pci.ids Size: 1169201 Blocks: 2288 IO Block: 4096 regular file Device: 10302h/66306d Inode: 8916466 Links: 1 Access: (0644/-rw-r--r--) Uid: (0/root) Gid: (0/root) ==> Access: 2019-03-14 03:15:02.0 -0400 ==> Modify: 2019-03-14 03:15:02.0 -0400 ==> Change: 2019-03-15 12:32:25.489581638 -0400 Birth: - At this point the pci.ids is updated. After this SRU, the above step won't be available ^. [REGRESSION POTENTIAL] User used to update their PCI vendor list using 'update-pciids' won't have it available anymore out of the box as it was before this SRU. (Unless they do the necessary manual intervention by taking the script from 'pciutils/examples' set the executable bit and run it, as user could still use that way but they have to be aware of the potential risk that may or may not come with it.) At this point, it will be at user discretion to use it or not and judge/evaluate the risk, but the package itself will no longer offer the option out of the box. We need to file a debian bug about it, but I don't know if Debian will be willing to follow our chain of thought. If not we will divert from pciutils debian package at that aspect. [OTHER INFORMATION] For more information : # man update-pciids [ORIG DESCRIPTION] [Freenode #ubuntu-release discussion] [13:51:02] vorlon, I also puzzle what would be the good practice, SRU an update of pci.ids or leave the user the decision to use update-pc
[Group.of.nepali.translators] [Bug 1821582] [NEW] Don't rely on SysV init script in logrotate config
Public bug reported: [IMPACT] Xenial uses systemd as default now, debian salsa 4a49edf26d405726041bee12a42d6f064145c87e, introduce a shell script, taking advantage of systemctl directly if systemd is active by still keeping Sysv init script as fallback only. While there is no 'real' impact, I think it make total sense for a systemd Xenial system, to use the systemctl approach for logrotation [TEST CASE] * On a Xenial active systemd system: Determine the script pick the right decision approach. # bash -vx /usr/lib/rsyslog/rsyslog-rotate Run logrotate which contains 'include /etc/logrotate.d', thus will use the rsyslog log rotation information, now using '/usr/lib/rsyslog/rsyslog-rotate' helper. # logrotate -vdf /etc/logrotate.conf Check if logs rotation happeneded in /var/log. # ls -altr /var/log * On a Xenial active upstart system: Determine the script pick the right decision approach. # bash -vx /usr/lib/rsyslog/rsyslog-rotate Run logrotate which contains 'include /etc/logrotate.d', thus will use the rsyslog log rotation information, now using '/usr/lib/rsyslog/rsyslog-rotate' helper. # logrotate -vdf /etc/logrotate.conf Check if logs rotation happeneded in /var/log. # ls -altr /var/log [POTENTIAL REGRESSION * None, this commit introduced a new shell script (rsyslog-rotate) which uses systemctl directly if systemd is active (default in Xenial) but keeps the original Sysv init script as fallback only. Meaning no behaviour change for users who decided not to use systemd on their Xenial system. /usr/lib/rsyslog/rsyslog-rotate: 1) Check if existence of systemd, if yes; systemctl kill -s HUP rsyslog.service 2) Check if existence of systemd, if no ; invoke-rc.d rsyslog rotate > /dev/null [OTHER INFO] * Salsa rsyslog repository: https://salsa.debian.org/debian/rsyslog/commit/4a49edf26d405726041bee12a42d6f064145c87e * First introduced: git describe --contains 4a49edf26d405726041bee12a42d6f064145c87e debian/8.27.0-4~1 * rmadison: => rsyslog | 8.16.0-1ubuntu3 | xenial rsyslog | 8.32.0-1ubuntu4 | bionic rsyslog | 8.32.0-1ubuntu5 | cosmic rsyslog | 8.32.0-1ubuntu7 | disco ** Affects: rsyslog (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: rsyslog (Ubuntu Xenial) Importance: Medium Assignee: Eric Desrochers (slashd) Status: In Progress ** Tags: sts ** Changed in: rsyslog (Ubuntu) Status: New => Fix Released ** Also affects: rsyslog (Ubuntu Xenial) Importance: Undecided Status: New ** Tags added: sts ** Changed in: rsyslog (Ubuntu Xenial) Status: New => In Progress ** Changed in: rsyslog (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: rsyslog (Ubuntu Xenial) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1821582 Title: Don't rely on SysV init script in logrotate config Status in rsyslog package in Ubuntu: Fix Released Status in rsyslog source package in Xenial: In Progress Bug description: [IMPACT] Xenial uses systemd as default now, debian salsa 4a49edf26d405726041bee12a42d6f064145c87e, introduce a shell script, taking advantage of systemctl directly if systemd is active by still keeping Sysv init script as fallback only. While there is no 'real' impact, I think it make total sense for a systemd Xenial system, to use the systemctl approach for logrotation [TEST CASE] * On a Xenial active systemd system: Determine the script pick the right decision approach. # bash -vx /usr/lib/rsyslog/rsyslog-rotate Run logrotate which contains 'include /etc/logrotate.d', thus will use the rsyslog log rotation information, now using '/usr/lib/rsyslog/rsyslog-rotate' helper. # logrotate -vdf /etc/logrotate.conf Check if logs rotation happeneded in /var/log. # ls -altr /var/log * On a Xenial active upstart system: Determine the script pick the right decision approach. # bash -vx /usr/lib/rsyslog/rsyslog-rotate Run logrotate which contains 'include /etc/logrotate.d', thus will use the rsyslog log rotation information, now using '/usr/lib/rsyslog/rsyslog-rotate' helper. # logrotate -vdf /etc/logrotate.conf Check if logs rotation happeneded in /var/log. # ls -altr /var/log [POTENTIAL REGRESSION * None, this commit introduced a new shell script (rsyslog-rotate) which uses systemctl directly if systemd is active (default in Xenial) but keeps the original Sysv init script as fallback only. Meaning no behaviour change for users who decided not to use systemd on their Xenial system. /usr/lib/rsyslog/rsyslog-rotate: 1) Check if exi
[Group.of.nepali.translators] [Bug 1746598] Re: [MIR] libnfs
@cyphermox, It was "Fix Released" for disco only[1], can we complete it for stable releases ? [1] - rmadison libnfs | 1.2.0-3| precise/universe | source libnfs | 1.3.0-2ubuntu1 | trusty/universe | source libnfs | 1.9.8-1| xenial/universe | source libnfs | 2.0.0-1~exp1 | bionic/universe | source libnfs | 2.0.0-1~exp1 | cosmic/universe | source => libnfs | 3.0.0-2| disco| source ** Also affects: libnfs (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: libnfs (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: libnfs (Ubuntu Bionic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1746598 Title: [MIR] libnfs Status in libnfs package in Ubuntu: Fix Released Status in libnfs source package in Xenial: New Status in libnfs source package in Bionic: New Status in libnfs source package in Cosmic: New Bug description: Availability Built for all supported architectures. In sync with Debian. Rationale = gvfs 1.24 added an NFS backend 3 years ago. It was enabled in Debian a year ago, but we can't enable it in Ubuntu until libnfs is promoted to main. The Ubuntu bug for this feature to be enabled in gvfs is LP: #1637988 qemu-block-extra could also enable libnfs support. Security No known CVEs. https://security-tracker.debian.org/tracker/source-package/libnfs https://launchpad.net/ubuntu/+source/libnfs/+cve Quality assurance = - Desktop Packages team is subscribed. - dh_auto_test runs but the tests shipped by upstream cant'b be run at build time since they modify the system. - Autopkgtests are added in 3.0.0-1, running upstream's test suite which includes running tests with valgrind, too. https://bugs.launchpad.net/ubuntu/+source/libnfs https://bugs.debian.org/cgi-bin/pkgreport.cgi?src=libnfs https://github.com/sahlberg/libnfs/issues https://autopkgtest.ubuntu.com/packages/libn/libnfs (failing, never passed: see https://bugs.debian.org/921578 ) https://ci.debian.net/packages/libn/libnfs/ (tests aren't run in Debian because they request machine isolation which isn't implemented there yet) Dependencies No universe binary dependencies Standards compliance 3.9.8, debhelper compat 9, dh7 simple rules Maintenance === Actively maintained: https://github.com/sahlberg/libnfs Not team maintained in Debian. https://tracker.debian.org/pkg/libnfs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libnfs/+bug/1746598/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1817903] Re: systemd-resolve appends "options edns0" to resolv.conf
** Also affects: resolvconf (Ubuntu) Importance: Undecided Status: New ** Changed in: resolvconf (Ubuntu Disco) Importance: Undecided => High ** Changed in: resolvconf (Ubuntu Disco) Status: New => In Progress ** Changed in: resolvconf (Ubuntu Disco) Assignee: (unassigned) => Dan Streetman (ddstreet) ** Changed in: resolvconf (Ubuntu Disco) Importance: High => Critical -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1817903 Title: systemd-resolve appends "options edns0" to resolv.conf Status in resolvconf package in Ubuntu: In Progress Status in systemd package in Ubuntu: In Progress Status in resolvconf source package in Trusty: New Status in systemd source package in Trusty: Invalid Status in resolvconf source package in Xenial: New Status in systemd source package in Xenial: Invalid Status in resolvconf source package in Bionic: New Status in systemd source package in Bionic: In Progress Status in resolvconf source package in Cosmic: New Status in systemd source package in Cosmic: In Progress Status in resolvconf source package in Disco: In Progress Status in systemd source package in Disco: In Progress Bug description: [impact] systems upgraded from pre-Bionic releases to Bionic or later will continue to use ifupdown/resolvconf for network conf and management, but resolvconf has a new systemd service in Bionic and later that pulls systemd-resolved stub-resolv.conf into its local configuration. With the recent addition of edns0 option to the stub resolver conf in systemd to fix bug 1811471, this means resolvconf now sets up the /etc/resolv.conf file to include upstream servers but also use edns. For any systems where the upstream resolver(s) don't support edns, dns lookups will break. [test case] create a xenial system with ifupdown/resolvconf, then upgrade to bionic (alternately it should be possible to install bionic, then remove netplan and install/configure ifupdown and resolvconf). The system ifupdown config should include an upstream name server. After upgrade, the /etc/resolv.conf will contain both the upstream name server as well as options edns0. [regression potential] this changes how resolvconf handles system dns on bionic and later: 1) networking is managed by ifupdown resolvconf is currently adding the local stub resolver to /etc/resolv.conf, even though in this case it doesn't know about any upstream name servers. This change will remove the local stub resolver from /etc/resolv.conf; it should not be there. 2) networking is managed by systemd-networkd resolvconf is currently setting up /etc/resolv.conf to direct all local dns queries to the local stub resolver, similar to how systemd- resolved itself configures /etc/resolv.conf. This change will instead set up /etc/resolv.conf to bypass the local stub resolver, and send all dns queries to the upstream name server(s). In case #1, this change has little chance for regression; in case #2 however, this change will bypass the local stub resolver and thus create more network dns traffic (since dns queries will not be cached locally). However, this is how pre-Bionic releases worked, and simply removing resolvconf will restore systemd-resolved control of /etc/resolv.conf, causing the system to again use the local stub resolver. Additional regressions due to this change would likely be seen in dns query failures with other system configurations. [other info] This affects only Bionic and later; in Xenial and earlier, resolvconf does not include the 'resolvconf-pull-resolved' service to pull in the systemd-resolved stub config, which is what causes this problem. This also does not affect Debian, as it does not include the 'resolvconf-pull-resolved' service either. original description: -- Mint 19 (Ubuntu 18.04) Following latest mint update done on 24/02/2019, DNS is broken nslookup and dig of certain domain names work as expected, ping does not (ip works but not domain name) After a day of trial and error, testing I found that the problem lies with the presence of "options edns0" in /run/resolvconf/resolv.conf (link to by /etc/resolv.conf) With option present many dns lookups fail with both FF and chrome browswers and thunderbird... This is on a home network, with router set as dns proxy for external wan, not using NetworkManager Deleting the option on live system results in the issue immediately disappearing, but on reboot it is added back in (by systemd-resolve ?) I cannot find any option to prevent this being added, so presumably it is hard-coded in systemd following the update? systemd: Installed: 237-3ubuntu10.13 To manage notifications about this bug go to: https://bug
[Group.of.nepali.translators] [Bug 1666203] Re: pam_tty_audit failed in pam_open_session
** Description changed: + [Impact] + + * Kernel keystroke auditing via pam_tty_audit.so not working + + * When Using the pam_tty_audit with other pam modules(ex, pam_ldap), it failed in pam_open_session. +It was triggared by use uninitialized variable in pam_tty_audit.c::pam_open_session. + + [Test Case] + + 1. Install libpam-ldap + 2. Add the following to the end of /etc/pam.d/common-sessions + + session required pam_tty_audit.so enable=* open_only + + 3. When logging in with ssh etc., pam_tty_audit will fail and login fails + + [Regression Potential] + + * Low, we are simply including the missing header files and copy the old status as initialization of new. +It's already part of Debian and Disco. + + [Other Info] + + # Upstream fix: + https://github.com/linux-pam/linux-pam/commit/c5f829931a22c65feffee16570efdae036524bee + + # git describe --contains c5f829931a22c65feffee16570efdae036524bee + Linux-PAM-1_2_0~75 + + # rmadision pam + => pam | 1.1.8-1ubuntu2.2 | trusty-updates | source + => pam | 1.1.8-3.2ubuntu2 | xenial | source + => pam | 1.1.8-3.2ubuntu2.1 | xenial-updates | source + => pam | 1.1.8-3.6ubuntu2 | bionic | source + => pam | 1.1.8-3.6ubuntu2 | cosmic | source + pam | 1.3.1-5ubuntu1 | disco| source + + [Original Description] + Dear Maintainer. I found a bug in pam_tty_audit. When Using the pam_tty_audit with other pam modules(ex, pam_ldap), it failed in pam_open_session. It was triggared by use uninitialized variable in pam_tty_audit.c::pam_open_session. * Enviroments Ubuntu 14.04.4 LTS linux-image-3.16.0-71-generic3.16.0-71.92~14.04.1 libpam-ldap:amd64184-8.5ubuntu3 libpam-modules:amd641.1.8-1ubuntu2.2 Ubuntu 16.04.2 TLS linux-image-4.4.0-62-generic4.4.0-62.83 libpam-ldap:amd64184-8.7ubuntu1 libpam-modules:amd641.1.8-3.2ubuntu2 * Reproduction method 1. Install libpam-ldap. 2. Add the following to the end of /etc/pam.d/common-sessions session required pam_tty_audit.so enable=* open_only 3. When logging in with ssh etc., pam_tty_audit will fail and login fails * Solution (== 2018/04/16 Link updated ==) apply upstream patch https://github.com/linux-pam/linux-pam/commit/c5f829931a22c65feffee16570efdae036524bee * Logs (on Ubuntu14.04) -- auth.log -- May 18 14:47:03 vm sshd[2272]: Accepted publickey for test from 10.99.0.1 port 51398 ssh2: RSA 8f:39:1c:3a:f4:9d:ca:99:67:fc:e3:fd:1e:0c:5b:a8 May 18 14:47:03 vm sshd[2272]: pam_unix(sshd:session): session opened for user test by (uid=0) May 18 14:47:03 vm sshd[2272]: pam_tty_audit(sshd:session): error setting current audit status: Invalid argument May 18 14:47:03 vm sshd[2272]: error: PAM: pam_open_session(): Cannot make/remove an entry for the specified session May 18 14:47:03 vm sshd[2297]: Received disconnect from 10.99.0.1: 11: disconnected by user -- syslog -- May 18 14:47:03 vm audispd: node=vm type=USER_ACCT msg=audit(1463550423.399:58): pid=2272 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:accounting acct="test" exe="/usr/sbin/sshd" hostname=10.99.0.1 addr=10.99.0.1 terminal=ssh res=success' May 18 14:47:03 vm audispd: node=vm type=CRED_ACQ msg=audit(1463550423.403:59): pid=2272 uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred acct="test" exe="/usr/sbin/sshd" hostname=10.99.0.1 addr=10.99.0.1 terminal=ssh res=success' May 18 14:47:03 vm audispd: node=vm type=LOGIN msg=audit(1463550423.403:60): pid=2272 uid=0 old-auid=4294967295 auid=20299 old-ses=4294967295 ses=3 res=1 May 18 14:47:03 vm audispd: node=vm type=CONFIG_CHANGE msg=audit(1463550423.403:61): pid=2272 uid=0 auid=20299 ses=3 op=tty_set old-enabled=0 new-enabled=1 old-log_passwd=0 new-log_passwd=32743 res=0 May 18 14:47:03 vm audispd: node=vm type=USER_START msg=audit(1463550423.447:62): pid=2272 uid=0 auid=20299 ses=3 msg='op=PAM:session_open acct="test" exe="/usr/sbin/sshd" hostname=10.99.0.1 addr=10.99.0.1 terminal=ssh res=failed' May 18 14:47:03 vm audispd: node=vm type=CRED_ACQ msg=audit(1463550423.447:63): pid=2297 uid=0 auid=20299 ses=3 msg='op=PAM:setcred acct="test" exe="/usr/sbin/sshd" hostname=10.99.0.1 addr=10.99.0.1 terminal=ssh res=success' May 18 14:47:03 vm audispd: node=vm type=CRED_DISP msg=audit(1463550423.451:64): pid=2272 uid=0 auid=20299 ses=3 msg='op=PAM:setcred acct="test" exe="/usr/sbin/sshd" hostname=10.99.0.1 addr=10.99.0.1 terminal=ssh res=success' Thanks regards. ** Also affects: pam (Ubuntu Cosmic) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1666203 Title: pam_tty_audit failed in pam_open_session Status in pam package in Ubuntu: Fix Released Status in pam
[Group.of.nepali.translators] [Bug 1815237] Re: stop shipping "update-pciids" in /usr/sbin
** Changed in: pciutils (Ubuntu Precise) Status: New => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1815237 Title: stop shipping "update-pciids" in /usr/sbin Status in pciutils package in Ubuntu: In Progress Status in pciutils source package in Precise: Invalid Status in pciutils source package in Trusty: In Progress Status in pciutils source package in Xenial: In Progress Status in pciutils source package in Bionic: In Progress Status in pciutils source package in Cosmic: In Progress Bug description: [Freenode #ubuntu-release discussion] [13:51:02] vorlon, I also puzzle what would be the good practice, SRU an update of pci.ids or leave the user the decision to use update-pciids which does it automatically [13:52:13] slashd: That second option isn't a great one, for many reasons. [13:52:21] slashd: ^^ I concur [13:52:55] slashd: The two that come to mind is (a) it alters a dpkg-managed file in /usr/share and (b) it's an entirely unchecked random download over http. [13:53:17] In fact, I'm a bit shocked we even ship that script at all, or haven't at least neutered it in some way. [13:54:40] That's just begging for an injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it. [13:55:00] infinity, good point [13:56:05] If we were to give that as an option, we'd need to alter the script (and things that read that data) to use a second user-writable location in /var, and we'd need upstream to provide a signed/verifiable source we can pull from. [13:56:23] But I think "stop shipping the script on the PATH" is a saner plan. [13:58:26] slashd: Maybe get some input from someone like mdeslaur or sarnold to see if they think I'm being overly paranoid, but I think having a script on path that downloads random junk over http and slams it in a file in /usr/share that gets read by dozens of other binaries is pretty sketchy. [13:58:40] slashd: So I'd be +1 on just nuking it. [13:59:08] infinity, ack will try to have a ACK for security team as well, but sound like a good plan [13:59:14] slashd: Or moving it to /use/share/doc/pciutils/examples [14:00:23] infinity, vorlon ok thanks a lot for your help [14:00:28] oh ew ew ew ew [14:01:01] yeah, moving it to examples would be a good idea [14:01:21] mdeslaur, ack tks SRU team: +1 Security team: +1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/pciutils/+bug/1815237/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1816388] [NEW] FTBFS on s390x on xenial
Public bug reported: [Impact] libguestfs doesn't build on s390x architecture * Pending SRU (xenial) libguestfs s390x: Failed to build https://launchpad.net/ubuntu/+source/libguestfs/1:1.32.2-4ubuntu2.1/+build/16379018 * Build log ... checking for qemu-system-s390x... no configure: error: qemu must be installed ... [Test Case] * Build libguestfs for s390x in Launchpad (PPA) [Regression Potential] None, the package doesn't build. The fix is already in other releases. The package will no longer relies on qemu-system-misc in favor of qemu-system-s390x now. [Other informations] * git-ubuntu (libguestfs) commit 3928bd5f1458d199cd93e415c9a8081d28048500) * debdiff The following should help the build for that particular FTBFS situation (if no other build problem found after) diff -Nru libguestfs-1.32.2/debian/control libguestfs-1.32.2/debian/control --- libguestfs-1.32.2/debian/control2016-03-13 16:04:12.0 + +++ libguestfs-1.32.2/debian/control2019-02-15 14:24:56.0 + @@ -18,7 +18,7 @@ gperf, libxml2-utils, qemu-system-arm [armel armhf arm64], qemu-system-mips [mips mipsel mips64 mips64el], - qemu-system-misc [s390x], + qemu-system-s390x [s390x], qemu-system-ppc [powerpc ppc64 ppc64el], qemu-system-aarch64 [arm64], qemu-system-sparc [sparc], @@ -154,7 +154,7 @@ supermin (>= 5), qemu-system-arm [armel armhf arm64], qemu-system-mips [mips mipsel mips64 mips64el], - qemu-system-misc [s390x], + qemu-system-s390x [s390x], qemu-system-aarch64 [arm64], qemu-system-ppc [powerpc pc64 ppc64el], qemu-system-sparc [sparc], ** Affects: libguestfs (Ubuntu) Importance: Undecided Status: Fix Released ** Affects: libguestfs (Ubuntu Xenial) Importance: Medium Assignee: Ioanna Alifieraki (joalif) Status: In Progress ** Tags: sts ** Also affects: libguestfs (Ubuntu Xenial) Importance: Undecided Status: New ** Summary changed: - FTBFS on s390x + FTBFS on s390x on xenial ** Changed in: libguestfs (Ubuntu) Status: New => Fix Released ** Changed in: libguestfs (Ubuntu Xenial) Status: New => In Progress ** Changed in: libguestfs (Ubuntu Xenial) Importance: Undecided => Medium ** Changed in: libguestfs (Ubuntu Xenial) Assignee: (unassigned) => Ioanna Alifieraki (joalif) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1816388 Title: FTBFS on s390x on xenial Status in libguestfs package in Ubuntu: Fix Released Status in libguestfs source package in Xenial: In Progress Bug description: [Impact] libguestfs doesn't build on s390x architecture * Pending SRU (xenial) libguestfs s390x: Failed to build https://launchpad.net/ubuntu/+source/libguestfs/1:1.32.2-4ubuntu2.1/+build/16379018 * Build log ... checking for qemu-system-s390x... no configure: error: qemu must be installed ... [Test Case] * Build libguestfs for s390x in Launchpad (PPA) [Regression Potential] None, the package doesn't build. The fix is already in other releases. The package will no longer relies on qemu-system-misc in favor of qemu-system-s390x now. [Other informations] * git-ubuntu (libguestfs) commit 3928bd5f1458d199cd93e415c9a8081d28048500) * debdiff The following should help the build for that particular FTBFS situation (if no other build problem found after) diff -Nru libguestfs-1.32.2/debian/control libguestfs-1.32.2/debian/control --- libguestfs-1.32.2/debian/control 2016-03-13 16:04:12.0 + +++ libguestfs-1.32.2/debian/control 2019-02-15 14:24:56.0 + @@ -18,7 +18,7 @@ gperf, libxml2-utils, qemu-system-arm [armel armhf arm64], qemu-system-mips [mips mipsel mips64 mips64el], - qemu-system-misc [s390x], + qemu-system-s390x [s390x], qemu-system-ppc [powerpc ppc64 ppc64el], qemu-system-aarch64 [arm64], qemu-system-sparc [sparc], @@ -154,7 +154,7 @@ supermin (>= 5), qemu-system-arm [armel armhf arm64], qemu-system-mips [mips mipsel mips64 mips64el], - qemu-system-misc [s390x], + qemu-system-s390x [s390x], qemu-system-aarch64 [arm64], qemu-system-ppc [powerpc pc64 ppc64el], qemu-system-sparc [sparc], To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1816388/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1815212] Re: [Xenial][SRU] Update pci.ids for pciutils
** Description changed: [Impact] pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated. Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet. - User or troubleshooter may get a wrong impression that the correct raid - controller is not present, if the user doesn't read the PCI bus address. + User or troubleshooter may get a wrong impression that, for instance, + the correct raid controller is not present, if the user doesn't read the + PCI bus address. + + While we are here, I will update Xenial and Bionic to be at the same + version level (Version: 2018.07.21) of current devel release (Disco) + which isn't too far behind current upstream (github) one in master + branch. + + x/pciutils-3.3.1/pci.ids:#Version: 2016.01.02 + b/pciutils-3.5.2/pci.ids:#Version: 2017.03.16 + c/pciutils-3.5.2/pci.ids:#Version: 2018.07.21 + d/pciutils-3.5.2/pci.ids:#Version: 2018.07.21 + upstream/pciutils/pci.ids:# Version: 2018.08.12 + [Test case] Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table: Xenial: 60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01) Bionic: 60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01) [Regression Potential] - Low, no core functionality change. The intention is to only update - pci.ids table list. + Low, no core functionality change. + The intention is to only update pci.ids table list to recognize new pci vendor list/hw. The only thing I can think of ... In some cases there is some device id renaming, which I guess can "possibly" impact some user script or HW inventory solution expecting a certain type of device id output. Example: - 67df Ellesmere [Polaris10] + 67df Ellesmere [Radeon RX 470/480] [Other information] - - An update of pci.ids has been made on October 3rd 2016. - This update include the device id 0014 (took from the example in "Test Case".) - - Upstream repository: - https://github.com/pciutils/pciutils.git - - Upstream commits: - # git log --oneline v3.3.1..v3.5.2 pci.ids ## Update done between Xenial and Bionic - 701fdd1 Updated pci.ids to today's snapshot - 8c2d87f Updated pci.ids to today's snapshot - 07a250f pci.ids updated to today's snapshot - 73debb0 Updated pci.ids to today's snapshot - - # From the example in the [Test Case]: - # git show 701fdd1 - .. - + 0014 MegaRAID Tri-Mode SAS3516 - .. - - # git describe --contains 701fdd1 - v3.5.2~1 - - # rmadison pciutils - ==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates - pciutils | 1:3.5.2-1ubuntu1 | bionic - pciutils | 1:3.5.2-1ubuntu2 | cosmic - pciutils | 1:3.5.2-1ubuntu2 | disco - -- ** Also affects: pciutils (Ubuntu Bionic) Importance: Undecided Status: New ** Changed in: pciutils (Ubuntu Bionic) Status: New => In Progress ** Changed in: pciutils (Ubuntu Bionic) Importance: Undecided => Low ** Changed in: pciutils (Ubuntu Bionic) Assignee: (unassigned) => Eric Desrochers (slashd) -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1815212 Title: [Xenial][SRU] Update pci.ids for pciutils Status in pciutils package in Ubuntu: Fix Released Status in pciutils source package in Xenial: In Progress Status in pciutils source package in Bionic: In Progress Bug description: [Impact] pci.ids table in Xenial seems a little bit behind in term of new device id added since last time it was updated. Some user are observing that their new device doesn't show up because they don't exist in the pci.ids file yet. User or troubleshooter may get a wrong impression that, for instance, the correct raid controller is not present, if the user doesn't read the PCI bus address. While we are here, I will update Xenial and Bionic to be at the same version level (Version: 2018.07.21) of current devel release (Disco) which isn't too far behind current upstream (github) one in master branch. x/pciutils-3.3.1/pci.ids:#Version: 2016.01.02 b/pciutils-3.5.2/pci.ids:#Version: 2017.03.16 c/pciutils-3.5.2/pci.ids:#Version: 2018.07.21 d/pciutils-3.5.2/pci.ids:#Version: 2018.07.21 upstream/pciutils/pci.ids:# Version: 2018.08.12 [Test case] Here's an example took by a user using a device id (0014) not in the Xenial pci.ids table: Xenial: 60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01) Bionic: 60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode SAS3516 (rev 01) [Regression Potential] Low, no core functionality chan
[Group.of.nepali.translators] [Bug 1815237] [NEW] stop shipping "update-pciids"
Public bug reported: [Freenode #ubuntu-release discussion] [13:51:02] vorlon, I also puzzle what would be the good practice, SRU an update of pci.ids or leave the user the decision to use update-pciids which does it automatically [13:52:13] slashd: That second option isn't a great one, for many reasons. [13:52:21] slashd: ^^ I concur [13:52:55] slashd: The two that come to mind is (a) it alters a dpkg-managed file in /usr/share and (b) it's an entirely unchecked random download over http. [13:53:17] In fact, I'm a bit shocked we even ship that script at all, or haven't at least neutered it in some way. [13:54:40] That's just begging for an injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it. [13:55:00] infinity, good point [13:56:05] If we were to give that as an option, we'd need to alter the script (and things that read that data) to use a second user-writable location in /var, and we'd need upstream to provide a signed/verifiable source we can pull from. [13:56:23] But I think "stop shipping the script on the PATH" is a saner plan. [13:58:26] slashd: Maybe get some input from someone like mdeslaur or sarnold to see if they think I'm being overly paranoid, but I think having a script on path that downloads random junk over http and slams it in a file in /usr/share that gets read by dozens of other binaries is pretty sketchy. [13:58:40] slashd: So I'd be +1 on just nuking it. [13:59:08] infinity, ack will try to have a ACK for security team as well, but sound like a good plan [13:59:14] slashd: Or moving it to /use/share/doc/pciutils/examples [14:00:23] infinity, vorlon ok thanks a lot for your help [14:00:28] oh ew ew ew ew [14:01:01] yeah, moving it to examples would be a good idea [14:01:21] mdeslaur, ack tks SRU team: +1 Security team: +1 ** Affects: pciutils (Ubuntu) Importance: Low Assignee: Eric Desrochers (slashd) Status: In Progress ** Affects: pciutils (Ubuntu Trusty) Importance: Undecided Status: New ** Affects: pciutils (Ubuntu Xenial) Importance: Undecided Status: New ** Affects: pciutils (Ubuntu Bionic) Importance: Undecided Status: New ** Affects: pciutils (Ubuntu Cosmic) Importance: Undecided Status: New ** Changed in: pciutils (Ubuntu) Assignee: (unassigned) => Eric Desrochers (slashd) ** Changed in: pciutils (Ubuntu) Importance: Undecided => Low ** Changed in: pciutils (Ubuntu) Status: New => In Progress ** Also affects: pciutils (Ubuntu Xenial) Importance: Undecided Status: New ** Also affects: pciutils (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: pciutils (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: pciutils (Ubuntu Bionic) Importance: Undecided Status: New ** Summary changed: - drop "update-pciids" for security reasons + stop shipping "update-pciids" -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1815237 Title: stop shipping "update-pciids" Status in pciutils package in Ubuntu: In Progress Status in pciutils source package in Trusty: New Status in pciutils source package in Xenial: New Status in pciutils source package in Bionic: New Status in pciutils source package in Cosmic: New Bug description: [Freenode #ubuntu-release discussion] [13:51:02] vorlon, I also puzzle what would be the good practice, SRU an update of pci.ids or leave the user the decision to use update-pciids which does it automatically [13:52:13] slashd: That second option isn't a great one, for many reasons. [13:52:21] slashd: ^^ I concur [13:52:55] slashd: The two that come to mind is (a) it alters a dpkg-managed file in /usr/share and (b) it's an entirely unchecked random download over http. [13:53:17] In fact, I'm a bit shocked we even ship that script at all, or haven't at least neutered it in some way. [13:54:40] That's just begging for an injection attack where intentionally-corrupted pci.ids data exploits something goofy in a library that reads it. [13:55:00] infinity, good point [13:56:05] If we were to give that as an option, we'd need to alter the script (and things that read that data) to use a second user-writable location in /var, and we'd need upstream to provide a signed/verifiable source we can pull from. [13:56:23] But I think "stop shipping the script on the PATH" is a saner plan. [13:58:26] slashd: Maybe get some input from someone like mdeslaur or sarnold to see if they think I'm being overly paranoid, but I think having a script on path that downloads random
[Group.of.nepali.translators] [Bug 1815212] [NEW] [Xenial][SRU] Update pci.ids for pciutils
Public bug reported:
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device
id added since last time it was updated.
Some user are observing that their new device doesn't show up because
they don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to represent
what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the
Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository:
https://github.com/pciutils/pciutils.git
Upstream commit:
https://github.com/pciutils/pciutils/commit/701fdd1e
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates
pciutils | 1:3.5.2-1ubuntu1 | bionic
pciutils | 1:3.5.2-1ubuntu2 | cosmic
pciutils | 1:3.5.2-1ubuntu2 | disco
--
** Affects: pciutils (Ubuntu)
Importance: Undecided
Status: Fix Released
** Affects: pciutils (Ubuntu Xenial)
Importance: Undecided
Assignee: Eric Desrochers (slashd)
Status: In Progress
** Tags: sts
** Also affects: pciutils (Ubuntu Xenial)
Importance: Undecided
Status: New
** Description changed:
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device
- id added since last time he was updated.
+ id added since last time it was updated.
Some user are observe that their new device doesn't show up because they
don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or
less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the
Xenial pci.ids table:
Xenial:
- 60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
+ 60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
SAS3516 (rev 01)
[Regression Potential]
[Other information]
- An update of pci.ids has been made on October 3rd 2016.
+ An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64,
armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386,
ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386,
ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | disco | source, amd64, arm64, armhf, i386,
ppc64el, s390x
--
** Changed in: pciutils (Ubuntu)
Status: New => Fix Released
** Tags added: sts
** Description changed:
[Impact]
pci.ids table in Xenial seems a little bit behind in term of new device
id added since last time it was updated.
Some user are observe that their new device doesn't show up because they
don't exist in the pci.ids file yet.
IMHO, it would be a good idea to update the Xenial pci.ids to more or
less represent what Bionic has as of today.
[Test case]
Here's an example took by a user using a device id (0014) not in the
Xenial pci.ids table:
Xenial:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic Device 0014 (rev 01)
Bionic:
60:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID Tri-Mode
SAS3516 (rev 01)
[Regression Potential]
[Other information]
An update of pci.ids has been made on October 3rd 2016.
This update include the device id 0014 (took from the example in "Test Case".)
upstream repository : https://github.com/pciutils/pciutils.git
+ Upstream commit:
+ https://github.com/pciutils/pciutils/commit/701fdd1e
+
# git show 701fdd1e | grep SAS3516
..
+ 0014 MegaRAID Tri-Mode SAS3516
..
# git describe --contains 701fdd1e
v3.5.2~1
# rmadison pciutils
==> pciutils | 1:3.3.1-1.1ubuntu1.2 | xenial-updates | source, amd64, arm64,
armhf, i386, powerpc, ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu1 | bionic | source, amd64, arm64, armhf, i386,
ppc64el, s390x
pciutils | 1:3.5.2-1ubuntu2 | cosmic | source, amd64, arm64, armhf, i386,
p
[Group.of.nepali.translators] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Changed in: libmemcached (Ubuntu Trusty) Status: Fix Committed => Invalid -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached package in Ubuntu: Fix Released Status in libmemcached source package in Trusty: Invalid Status in libmemcached source package in Xenial: Fix Released Status in libmemcached source package in Bionic: Fix Released Status in libmemcached source package in Cosmic: Fix Released Status in libmemcached source package in Disco: Fix Released Status in libmemcached package in Debian: New Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] This bug is difficult to reproduce since it depends on the contents of the stack. However, here is a test case using the fix on Bionic that shows that this fix does not cause any problems. For testing you need 1) A memcached server. You can setup one by following the instructions in [1], or (what I did) create one in the cloud [2]. 2) A client test program to connect to the memcached server. One can be found in [3]. This simple test connects to a memcache server and test basic get/set operations. Copy paste the C code into a file (sals_test.c) and compile with : gcc -o sasl_test -O2 sasl_test.c -lmemcached -pthread 3) On a machine with the updated version of libmemcached in which the fix is applied : jo@bionic-vm:~$ dpkg -l | grep libmemcached ii libhashkit-dev:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms (development files) ii libhashkit2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64libmemcached hashing functions and algorithms ii libmemcached-dbg:amd641.0.18-4.2ubuntu0.18.04.1 amd64Debug Symbols for libmemcached ii libmemcached-dev:amd641.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server (development files) ii libmemcached-tools1.0.18-4.2ubuntu0.18.04.1 amd64Commandline tools for talking to memcached via libmemcached ii libmemcached11:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64C and C++ client library to the memcached server ii libmemcachedutil2:amd64 1.0.18-4.2ubuntu0.18.04.1 amd64library implementing connection pooling for libmemcached Run the sals_test binary : #./sasl_test [username] [password] [server] In my case using the credentials and the server created in step 1 : jo@bionic-vm:~$ ./sasl_test 88BAB0 1A99094B77C8935ED9F1461C767DB1F9 mc2.dev.eu.ec2.memcachier.com Get/Set success! [1] https://blog.couchbase.com/sasl-memcached-now-available/ [2] https://www.memcachier.com/ [3] https://blog.memcachier.com/2014/11/05/ubuntu-libmemcached-and-sasl-support/ [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. * When running autopkgtest for xenial/armhf it fails on gearmand : http://autopkgtest.ubuntu.com/packages/g/gearmand/xenial/armhf . However this is a long standing issue with gearmand and it is not related with the current SRU. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstre
[Group.of.nepali.translators] [Bug 1814939] Re: libguestfs fails to build on Xenial - dh_install --fail-missing
** Also affects: libguestfs (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1814939 Title: libguestfs fails to build on Xenial - dh_install --fail-missing Status in libguestfs package in Ubuntu: New Status in libguestfs source package in Xenial: In Progress Bug description: Ubuntu Version : $ lsb_release -rd Description: Ubuntu 16.04.5 LTS Release: 16.04 libguestfs version : 1:1.32.2-4ubuntu2 When trying to build libguestfs on Ubuntu 16.04 - Xenial, it fails at : dh_install -X.la -X.so.owner -Xbindtests -X/usr/lib/go/ -Xpackages.orig \ --fail-missing dh_install: usr/lib/go-1.6/pkg/linux_amd64/libguestfs.org/guestfs/guestfs.a exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_040_create_multiple_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_100_launch_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_070_optargs_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_060_explicit_close_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_010_load_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_900_rstringlist_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_030_create_flags_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_020_create_test.go exists in debian/tmp but is not installed to anywhere dh_install: usr/lib/go-1.6/src/pkg/libguestfs.org/guestfs/guestfs_050_handle_properties_test.go exists in debian/tmp but is not installed to anywhere dh_install: missing files, aborting debian/rules:118: recipe for target 'override_dh_install' failed This happens because the dh_install excludes the /usr/lib/go files (-X/usr/lib/go) but does not exclude the /usr/lib/go- for the specific version of go. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1814939/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1812696] Re: APT doc and manpage uses wrong ubuntu-codename
juliank will include the ubuntu-codename variable change in his next SRU later this week. Thanks Juliank ! ** Tags added: sts ** Changed in: apt (Ubuntu Trusty) Status: New => Invalid ** Description changed: From APT src code : - --- - * trusty: - apt-1.0.1ubuntu2.18/doc/apt-verbatim.ent: + --- + [GOOD ubuntu-codename] + * trusty: + apt-1.0.1ubuntu2.18/doc/apt-verbatim.ent: - * xenial: - apt-1.2.29/doc/apt-verbatim.ent: + [WRONG ubuntu-codename] + * xenial: + apt-1.2.29/doc/apt-verbatim.ent: - * bionic: - apt-1.6.7/doc/apt-verbatim.ent: + * bionic: + apt-1.6.7/doc/apt-verbatim.ent: - * disco: - apt-1.8.0~alpha3/doc/apt-verbatim.ent: - --- + * disco: + apt-1.8.0~alpha3/doc/apt-verbatim.ent: + --- - * vendor/ubuntu/sources.list.in - --- - # See sources.list(5) manpage for more information - # Remember that CD-ROMs, DVDs and such are managed through the apt-cdrom tool. - deb http://us.archive.ubuntu.com/ubuntu &ubuntu-codename; main restricted - deb-src http://us.archive.ubuntu.com/ubuntu &ubuntu-codename; main restricted + * vendor/ubuntu/sources.list.in + --- + # See sources.list(5) manpage for more information + # Remember that CD-ROMs, DVDs and such are managed through the apt-cdrom tool. + deb http://us.archive.ubuntu.com/ubuntu &ubuntu-codename; main restricted + deb-src http://us.archive.ubuntu.com/ubuntu &ubuntu-codename; main restricted - deb http://security.ubuntu.com/ubuntu &ubuntu-codename;-security main restricted - deb-src http://security.ubuntu.com/ubuntu &ubuntu-codename;-security main restricted + deb http://security.ubuntu.com/ubuntu &ubuntu-codename;-security main restricted + deb-src http://security.ubuntu.com/ubuntu &ubuntu-codename;-security main restricted - deb http://us.archive.ubuntu.com/ubuntu &ubuntu-codename;-updates main restricted - deb-src http://us.archive.ubuntu.com/ubuntu &ubuntu-codename;-updates main restricted - --- + deb http://us.archive.ubuntu.com/ubuntu &ubuntu-codename;-updates main restricted + deb-src http://us.archive.ubuntu.com/ubuntu &ubuntu-codename;-updates main restricted + --- The ubuntu-codename variable for Bionic and late in APT points to Xenial which generate the doc example with Xenial instead of the actual codename. - * ./doc/sources.list.5.xml | grep -i verbatim - --- - %aptverbatiment; - --- + * ./doc/sources.list.5.xml | grep -i verbatim + --- + %aptverbatiment; + --- It also seems to affect the man page by mentionning 'xenial' for Bionic: - http://manpages.ubuntu.com/manpages/bionic/man5/sources.list.5.html + http://manpages.ubuntu.com/manpages/bionic/man5/sources.list.5.html http://manpages.ubuntu.com/manpages/bionic/man5/apt_preferences.5.html -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1812696 Title: APT doc and manpage uses wrong ubuntu-codename Status in apt package in Ubuntu: New Status in apt source package in Trusty: Invalid Status in apt source package in Xenial: New Status in apt source package in Bionic: New Status in apt source package in Cosmic: New Status in apt source package in Disco: New Bug description: From APT src code : --- [GOOD ubuntu-codename] * trusty: apt-1.0.1ubuntu2.18/doc/apt-verbatim.ent: [WRONG ubuntu-codename] * xenial: apt-1.2.29/doc/apt-verbatim.ent: * bionic: apt-1.6.7/doc/apt-verbatim.ent: * disco: apt-1.8.0~alpha3/doc/apt-verbatim.ent: --- * vendor/ubuntu/sources.list.in --- # See sources.list(5) manpage for more information # Remember that CD-ROMs, DVDs and such are managed through the apt-cdrom tool. deb http://us.archive.ubuntu.com/ubuntu &ubuntu-codename; main restricted deb-src http://us.archive.ubuntu.com/ubuntu &ubuntu-codename; main restricted deb http://security.ubuntu.com/ubuntu &ubuntu-codename;-security main restricted deb-src http://security.ubuntu.com/ubuntu &ubuntu-codename;-security main restricted deb http://us.archive.ubuntu.com/ubuntu &ubuntu-codename;-updates main restricted deb-src http://us.archive.ubuntu.com/ubuntu &ubuntu-codename;-updates main restricted --- The ubuntu-codename variable for Bionic and late in APT points to Xenial which generate the doc example with Xenial instead of the actual codename. * ./doc/sources.list.5.xml | grep -i verbatim --- %aptverbatiment; --- It also seems to affect the man page by mentionning 'xenial'. Example took from Bionic: http://manpages.ubuntu.com/manpages/bionic/man5/sources.list.5.html http://manpages.ubuntu.com/manpages/bionic/man5/apt_preferences.5.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt/+bug/1812696/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to :
[Group.of.nepali.translators] [Bug 1573594] Re: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling
** Bug watch added: Debian Bug tracker #919696 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 ** Also affects: libmemcached (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1573594 Title: Missing null termination in PROTOCOL_BINARY_CMD_SASL_LIST_MECHS response handling Status in libmemcached: New Status in libmemcached package in Ubuntu: In Progress Status in libmemcached source package in Trusty: In Progress Status in libmemcached source package in Xenial: In Progress Status in libmemcached source package in Bionic: In Progress Status in libmemcached source package in Cosmic: In Progress Status in libmemcached source package in Disco: In Progress Status in libmemcached package in Debian: Unknown Bug description: [Impact] When connecting to a server using SASL, memcached_sasl_authenticate_connection() reads the list of supported mechanisms [1] from the server via the command PROTOCOL_BINARY_CMD_SASL_LIST_MECHS. The server's response is a string containing supported authentication mechanisms, which gets stored into the (uninitialized) destination buffer without null termination [2]. The buffer then gets passed to sasl_client_start [3] which treats it as a null-terminated string [4], reading uninitialised bytes in the buffer. As the buffer lives on the stack, an attacker that can put strings on the stack before the connection gets made, might be able to tamper with the authentication. [1] libmemcached/sasl.cc:174 [2] libmemcached/response.cc:619 [1] libmemcached/sasl.cc:231 [3] http://linux.die.net/man/3/sasl_client_start [Test Case] There is no known reliable reproducer. [Regression Potential] This fix initialises the buffer to 0. Any potential regression may include failure of the authentication when using SASL. [Other Info] This bug affects trusty and later. * rmadison: libmemcached | 1.0.8-1ubuntu2 | trusty | source libmemcached | 1.0.18-4.1 | xenial | source libmemcached | 1.0.18-4.2 | bionic | source libmemcached | 1.0.18-4.2 | cosmic | source libmemcached | 1.0.18-4.2 | disco | source * Debian bug: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=919696 * Upstream seems pretty quiet since 2014 Unfortunately, because the project seems more or less dead ... it seems like we won't be able submit anything upstream and go straight to fixing Debian and Ubuntu. - Repo: bzr branch lp:libmemcached - Last commit: revno: 1113 [merge] committer: Continuous Integration branch nick: workspace timestamp: Sun 2014-02-16 03:31:37 -0800 message: Merge bzr://soup.haus/ Build: jenkins-Libmemcached-473 To manage notifications about this bug go to: https://bugs.launchpad.net/libmemcached/+bug/1573594/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1800566] Re: Make the reset_devices parameter default for kdump kernels
** Also affects: makedumpfile (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Disco) Importance: High Assignee: Mauricio Faria de Oliveira (mfo) Status: Confirmed ** Also affects: makedumpfile (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1800566 Title: Make the reset_devices parameter default for kdump kernels Status in makedumpfile package in Ubuntu: Confirmed Status in makedumpfile source package in Trusty: New Status in makedumpfile source package in Xenial: New Status in makedumpfile source package in Bionic: New Status in makedumpfile source package in Cosmic: New Status in makedumpfile source package in Disco: Confirmed Bug description: Kernel has the "reset_devices" parameter that drivers can opt-in, and perform special activity in case this parameter is parsed from command-line. For example, in kdump kernels it hints the drivers that they (maybe) are booting from a non-healthy condition and needs to issue some reset to the adapter. Users currently (kernel v4.19) are: hpsa, ipr, megaraid_sas, mpt3sas, smartpqi, xenbus. This should be enabled by default in the kdump config file to be added in the kdump kernel command-line for all versions. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800566/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1800562] Re: Replace "nousb" option in kdump command-line for the newer "usbcore.nousb"
** Also affects: makedumpfile (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: makedumpfile (Ubuntu Cosmic)
Importance: Undecided
Status: New
** Also affects: makedumpfile (Ubuntu Disco)
Importance: High
Assignee: Guilherme G. Piccoli (gpiccoli)
Status: Confirmed
** Also affects: makedumpfile (Ubuntu Xenial)
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1800562
Title:
Replace "nousb" option in kdump command-line for the newer
"usbcore.nousb"
Status in makedumpfile package in Ubuntu:
Confirmed
Status in makedumpfile source package in Xenial:
New
Status in makedumpfile source package in Bionic:
New
Status in makedumpfile source package in Cosmic:
New
Status in makedumpfile source package in Disco:
Confirmed
Bug description:
Since kernel v4.5, the correct parameter to disable USB subsystem
initialization is "usbcore.nousb" always (instead of "nousb" in case
the subsystem is built-in). This was changed by commit 097a9ea0e48
("usb: make "nousb" a clear module parameter").
We need to take this into account in kdump-tools, or else we may boot
with USB in kdump even the command-line saying the opposite.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800562/+subscriptions
___
Mailing list: https://launchpad.net/~group.of.nepali.translators
Post to : group.of.nepali.translators@lists.launchpad.net
Unsubscribe : https://launchpad.net/~group.of.nepali.translators
More help : https://help.launchpad.net/ListHelp
[Group.of.nepali.translators] [Bug 1800873] Re: Add KDUMP_CMDLINE_REMOVE option to remove portions of kernel command-line
** Also affects: makedumpfile (Ubuntu Bionic) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Cosmic) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Disco) Importance: Low Assignee: Guilherme G. Piccoli (gpiccoli) Status: Confirmed ** Also affects: makedumpfile (Ubuntu Trusty) Importance: Undecided Status: New ** Also affects: makedumpfile (Ubuntu Xenial) Importance: Undecided Status: New -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1800873 Title: Add KDUMP_CMDLINE_REMOVE option to remove portions of kernel command- line Status in makedumpfile package in Ubuntu: Confirmed Status in makedumpfile source package in Trusty: New Status in makedumpfile source package in Xenial: New Status in makedumpfile source package in Bionic: New Status in makedumpfile source package in Cosmic: New Status in makedumpfile source package in Disco: Confirmed Bug description: Currently kdump has an useful option to append parameters to the kdump kernel command-line, "KDUMP_CMDLINE_APPEND". Would be useful to have a reciprocal option which users could use to remove parameters without needing to rewrite the whole line. The option name proposed here is KDUMP_CMDLINE_REMOVE, which would tentatively "sed"-out the options from the kernel command-line before appending the new ones from KDUMP_CMDLINE_APPEND. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/makedumpfile/+bug/1800873/+subscriptions ___ Mailing list: https://launchpad.net/~group.of.nepali.translators Post to : group.of.nepali.translators@lists.launchpad.net Unsubscribe : https://launchpad.net/~group.of.nepali.translators More help : https://help.launchpad.net/ListHelp
