[Touch-packages] [Bug 1790963] Re: Unable to connect with openssh 7.8 client and certificates
This [1] appears to be the source of the problem, specifically "Add new RSA certificate types that that can be used in the above options and on the wire to require the use of RSA/SHA2 signatures." - unfortunately, those new certificate types don't exist/work in openssh <7.8, breaking backwards compatibility with 7.8 clients. Christian - Correct, it doesn't matter that no Ubuntu version is shipping with openssh 7.8 today. Bleeding edge distributions are, and non-Linux users are getting updates to 7.8, which breaks connectivity to any openssh server <7.8 under these circumstances when the client is 7.8. Etienne - Thank you for providing that - it is the current workaround aside from downgrading clients to 7.7. This is not a complete solution though, as it doesn't help for environments that sign RSA user certificates through an automated service (unless that service supports EC certs, which I'm going to guess may not work with really old versions of openssh). [1] http://bugzilla.mindrot.org/show_bug.cgi?id=2799 ** Bug watch added: OpenSSH Portable Bugzilla #2799 https://bugzilla.mindrot.org/show_bug.cgi?id=2799 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1790963 Title: Unable to connect with openssh 7.8 client and certificates Status in openssh package in Ubuntu: Confirmed Bug description: Users are unable to connect to Ubuntu when using openssh client 7.8 and certificates. We have seen this with both xenial and bionic, but this affects connecting to ANY host running openssh server <7.8. It appears to be specific to using certificate authentication. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm When comparing the list returned from a 7.6 server and a 7.8 server via "ssh -Q key", we find that 7.8 returns rsa- sha2-512-cert-...@openssh.com and rsa-sha2-256-cert-...@openssh.com which are not present (or valid) for the earlier version server. It appears that the change noted here in the release notes[1] for 7.8 is related: * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 [1] https://www.openssh.com/txt/release-7.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1790963] Re: Unable to connect with openssh 7.8 client and certificates
Updated the description - specifically, this appears to affect certificate authentication and be related to rsa- sha2-512-cert-...@openssh.com and rsa-sha2-256-cert-...@openssh.com which are present in 7.8 server, but not earlier versions (nor are valid to add to the configuration manually). ** Summary changed: - Unable to connect with openssh 7.8 client + Unable to connect with openssh 7.8 client and certificates ** Description changed: - Users are unable to connect to Ubuntu when using openssh client 7.8. We - have seen this with both xenial and bionic, but this affects connecting - to ANY host running openssh server <7.8. + Users are unable to connect to Ubuntu when using openssh client 7.8 and + certificates. We have seen this with both xenial and bionic, but this + affects connecting to ANY host running openssh server <7.8. + + It appears to be specific to using certificate authentication. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm + + When comparing the list returned from a 7.6 server and a 7.8 server via + "ssh -Q key", we find that 7.8 returns rsa-sha2-512-cert-...@openssh.com + and rsa-sha2-256-cert-...@openssh.com which are not present (or valid) + for the earlier version server. It appears that the change noted here in the release notes[1] for 7.8 is related: * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). + This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 [1] https://www.openssh.com/txt/release-7.8 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1790963 Title: Unable to connect with openssh 7.8 client and certificates Status in openssh package in Ubuntu: Confirmed Bug description: Users are unable to connect to Ubuntu when using openssh client 7.8 and certificates. We have seen this with both xenial and bionic, but this affects connecting to ANY host running openssh server <7.8. It appears to be specific to using certificate authentication. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm When comparing the list returned from a 7.6 server and a 7.8 server via "ssh -Q key", we find that 7.8 returns rsa- sha2-512-cert-...@openssh.com and rsa-sha2-256-cert-...@openssh.com which are not present (or valid) for the earlier version server. It appears that the change noted here in the release notes[1] for 7.8 is related: * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 [1] https://www.openssh.com/txt/release-7.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lis
[Touch-packages] [Bug 1790963] Re: Unable to connect with openssh 7.8 client
** Description changed: Users are unable to connect to Ubuntu when using openssh client 7.8. We have seen this with both xenial and bionic, but this affects connecting - to ANY host running openssh <7.8. + to ANY host running openssh server <7.8. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm It appears that the change noted here in the release notes[1] for 7.8 is related: - * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar -HostbasedAcceptedKeyTypes options have changed. These now specify -signature algorithms that are accepted for their respective -authentication mechanism, where previously they specified accepted -key types. This distinction matters when using the RSA/SHA2 -signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their -certificate counterparts. Configurations that override these -options but omit these algorithm names may cause unexpected -authentication failures (no action is required for configurations -that accept the default for these options). + * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar + HostbasedAcceptedKeyTypes options have changed. These now specify + signature algorithms that are accepted for their respective + authentication mechanism, where previously they specified accepted + key types. This distinction matters when using the RSA/SHA2 + signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their + certificate counterparts. Configurations that override these + options but omit these algorithm names may cause unexpected + authentication failures (no action is required for configurations + that accept the default for these options). This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 - [1] https://www.openssh.com/releasenotes.html + [1] https://www.openssh.com/txt/release-7.8 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1790963 Title: Unable to connect with openssh 7.8 client Status in openssh package in Ubuntu: Confirmed Bug description: Users are unable to connect to Ubuntu when using openssh client 7.8. We have seen this with both xenial and bionic, but this affects connecting to ANY host running openssh server <7.8. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm It appears that the change noted here in the release notes[1] for 7.8 is related: * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 [1] https://www.openssh.com/txt/release-7.8 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1790963] [NEW] Unable to connect with openssh 7.8 client
Public bug reported: Users are unable to connect to Ubuntu when using openssh client 7.8. We have seen this with both xenial and bionic, but this affects connecting to ANY host running openssh <7.8. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm It appears that the change noted here in the release notes[1] for 7.8 is related: * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 [1] https://www.openssh.com/releasenotes.html ** Affects: openssh (Ubuntu) Importance: Undecided Status: Confirmed -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to openssh in Ubuntu. https://bugs.launchpad.net/bugs/1790963 Title: Unable to connect with openssh 7.8 client Status in openssh package in Ubuntu: Confirmed Bug description: Users are unable to connect to Ubuntu when using openssh client 7.8. We have seen this with both xenial and bionic, but this affects connecting to ANY host running openssh <7.8. The only known recourse at this time is either downgrade clients to 7.7 or a previous version of openssh, or create new keys/certificates with a different alg that is acceptable for both the older server and newer client. The error message via ssh -vvv is: debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:REDACTED debug1: send_pubkey_test: no mutual signature algorithm It appears that the change noted here in the release notes[1] for 7.8 is related: * sshd(8): the semantics of PubkeyAcceptedKeyTypes and the similar HostbasedAcceptedKeyTypes options have changed. These now specify signature algorithms that are accepted for their respective authentication mechanism, where previously they specified accepted key types. This distinction matters when using the RSA/SHA2 signature algorithms "rsa-sha2-256", "rsa-sha2-512" and their certificate counterparts. Configurations that override these options but omit these algorithm names may cause unexpected authentication failures (no action is required for configurations that accept the default for these options). This is also affecting other Linux distributions as well: https://bugzilla.redhat.com/show_bug.cgi?id=1623929 https://bugs.archlinux.org/task/59838 [1] https://www.openssh.com/releasenotes.html To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1790963/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1651278] Re: systemd-sysv-generator does not fully translate facilities to targets
** Bug watch added: github.com/systemd/systemd/issues #4762 https://github.com/systemd/systemd/issues/4762 ** Also affects: systemd via https://github.com/systemd/systemd/issues/4762 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1651278 Title: systemd-sysv-generator does not fully translate facilities to targets Status in systemd: Unknown Status in systemd package in Ubuntu: Confirmed Bug description: See the bug raised here: https://github.com/systemd/systemd/issues/4762 and fixed upstream here: https://github.com/systemd/systemd/commit/e932f5407ef5ad05d25d7dfefa4cda0fe81cc346 In short, given a sysv-init script with valid LSB headers, one of which defines Required-Start: $foo and given that a foo.target target exists and is enabled, I would expect to see After=foo.target in the generated unit. In practice (on all versions of systemd prior to the unreleased v233) no other facilities beyond the pre-defined facilities ($network, $local_fs, etc) will be used in generating the systemd wrapper for the old sysv init script. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1651278/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1752722] Re: systemd 237 reports incorrect state when drop-in present
** Bug watch added: github.com/systemd/systemd/issues #8328 https://github.com/systemd/systemd/issues/8328 ** Also affects: systemd via https://github.com/systemd/systemd/issues/8328 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1752722 Title: systemd 237 reports incorrect state when drop-in present Status in systemd: Fix Released Status in systemd package in Ubuntu: Triaged Status in systemd source package in Bionic: Triaged Bug description: Raised this upstream: https://github.com/systemd/systemd/issues/8328 In short, in systemd 237 as it ships with Bionic, if a unit has a drop-in present but has been masked, systemctl is-enabled and systemctl list-unit-files report incorrect state, showing the units as enabled rather than masked. This works as-expected in systemd 229 under Xenial. I have not tested under systemd 234 in artful so I cannot say for sure exactly when this was introduced, but will spin up a quick test to see if this also exists under systemd 234. To manage notifications about this bug go to: https://bugs.launchpad.net/systemd/+bug/1752722/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1752722] Re: systemd 237 reports incorrect state when drop-in present
** Tags added: bionic -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to systemd in Ubuntu. https://bugs.launchpad.net/bugs/1752722 Title: systemd 237 reports incorrect state when drop-in present Status in systemd package in Ubuntu: Confirmed Bug description: Raised this upstream: https://github.com/systemd/systemd/issues/8328 In short, in systemd 237 as it ships with Bionic, if a unit has a drop-in present but has been masked, systemctl is-enabled and systemctl list-unit-files report incorrect state, showing the units as enabled rather than masked. This works as-expected in systemd 229 under Xenial. I have not tested under systemd 234 in artful so I cannot say for sure exactly when this was introduced, but will spin up a quick test to see if this also exists under systemd 234. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1752722/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1484083] Re: Don't work autologin after update lightdm
** Changed in: hundredpapercuts Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1484083 Title: Don't work autologin after update lightdm Status in One Hundred Papercuts: Fix Released Status in lightdm package in Ubuntu: Fix Released Status in user-setup package in Ubuntu: Fix Released Bug description: Don't work autologin after update lightdm ProblemType: Bug DistroRelease: Ubuntu 15.10 Package: lightdm 1.15.2-0ubuntu2 ProcVersionSignature: Ubuntu 4.1.0-3.3-lowlatency 4.1.3 Uname: Linux 4.1.0-3-lowlatency x86_64 ApportVersion: 2.18-0ubuntu6 Architecture: amd64 CurrentDesktop: Unity Date: Wed Aug 12 14:20:00 2015 InstallationDate: Installed on 2015-04-23 (110 days ago) InstallationMedia: SourcePackage: lightdm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1484083/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1714618] Re: No password necessary for login to admin account
Thank you for taking the time to report this issue and helping to make Ubuntu better. Examining the information you have given us, this does not appear to be a bug report so we are closing it and converting it to a question in the support tracker. We appreciate the difficulties you are facing, but it would make more sense to raise problems you are having in the support tracker at https://answers.launchpad.net/ubuntu if you are uncertain if they are bugs. For help on reporting bugs, see https://help.ubuntu.com/community/ReportingBugs. ** Changed in: lightdm (Ubuntu) Status: New => Invalid ** Converted to question: https://answers.launchpad.net/ubuntu/+source/lightdm/+question/657253 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to lightdm in Ubuntu. https://bugs.launchpad.net/bugs/1714618 Title: No password necessary for login to admin account Status in lightdm package in Ubuntu: Invalid Bug description: Having changed the language of Ubuntu from french to english, and have set the admin to login without a password, I have added a password to the admin account. However, at the login page, I am not prompted a password when logging in. I am prompted for one on other non admin accounts, and I am also prompted it when accessing root privileges or when the admin password is needed for other reasons on the whole of ubuntu. I have checked and I cannot find a light.dm file with any auto-login data. I cannot understand how I can disable auto-login. ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: lightdm 1.18.3-0ubuntu1.1 ProcVersionSignature: Ubuntu 4.4.0-93.116-generic 4.4.79 Uname: Linux 4.4.0-93-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.10 Architecture: amd64 CurrentDesktop: Unity Date: Sat Sep 2 01:19:46 2017 InstallationDate: Installed on 2016-10-07 (329 days ago) InstallationMedia: Ubuntu 16.04.1 LTS "Xenial Xerus" - Release amd64 (20160719) SourcePackage: lightdm UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/lightdm/+bug/1714618/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1540353] Re: xargs: invalid number for -s option
Xenial currently has python 3.5 (not python 3.4) and at a version where the upstream bug[1] should be fixed. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809079 ** Bug watch added: Debian Bug tracker #809079 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809079 ** Also affects: python3.5 (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=809079 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to python3.4 in Ubuntu. https://bugs.launchpad.net/bugs/1540353 Title: xargs: invalid number for -s option Status in One Hundred Papercuts: Confirmed Status in python3.4 package in Ubuntu: Confirmed Status in python3.5 package in Debian: Unknown Bug description: I ran "sudo apt-get autoremove" and when python3.4 and libpython3.4-minimal:amd64 were removed, the following error was shown on the screen: Removing python3.4-minimal (3.4.4-1) ... Unlinking and removing bytecode for runtime python3.4 Removing libpython3.4-minimal:amd64 (3.4.4-1) ... xargs: invalid number for -s option Usage: xargs [OPTION]... COMMAND [INITIAL-ARGS]... Run COMMAND with arguments INITIAL-ARGS and more arguments read from input. ...followed by instructions on how to use xargs properly. Probably some maintainer scripting errors? ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: libpython3.4-minimal (not installed) ProcVersionSignature: Ubuntu 4.3.0-7.18-generic 4.3.3 Uname: Linux 4.3.0-7-generic x86_64 ApportVersion: 2.19.4-0ubuntu1 Architecture: amd64 CurrentDesktop: Unity Date: Mon Feb 1 13:46:27 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2015-11-28 (65 days ago) InstallationMedia: Ubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20151127) SourcePackage: python3.4 UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1540353/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1515513] Re: /boot/initrd.img-*.old-dkms files left behind
The commit for this in upstream Debian (0.123 version of initramfs- tools) is here: https://anonscm.debian.org/cgit/kernel/initramfs- tools.git/commit/?id=ac6d31fc2c707b72ff8af9944c9b4f8af303a6a3 - I would be happy to make a patch for this commit to xenial (zesty and later has 0.125+, so should already include the fix). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1515513 Title: /boot/initrd.img-*.old-dkms files left behind Status in dkms package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in dkms package in Debian: New Bug description: One notices *.old-dkms files being left behind still sitting on the disk after purging the related kernel. This can cause /boot to become full, and when it gets really bad, even sudo apt-get autoremove won't fix the problem - only deleting the old-dkms files manually solves the problem. Note: Filling up the /boot partition causes updates to fail. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: dkms 2.2.0.3-2ubuntu3.3 ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5 Uname: Linux 3.19.0-28-generic x86_64 ApportVersion: 2.17.2-0ubuntu1.7 Architecture: amd64 CurrentDesktop: KDE Date: Thu Nov 12 08:17:10 2015 InstallationDate: Installed on 2015-05-05 (190 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) PackageArchitecture: all SourcePackage: dkms UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1515513] Re: /boot/initrd.img-*.old-dkms files left behind
Sorry, my previous comment was for another initramfs-tools related bug. Please disregard #18. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1515513 Title: /boot/initrd.img-*.old-dkms files left behind Status in dkms package in Ubuntu: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in dkms package in Debian: New Bug description: One notices *.old-dkms files being left behind still sitting on the disk after purging the related kernel. This can cause /boot to become full, and when it gets really bad, even sudo apt-get autoremove won't fix the problem - only deleting the old-dkms files manually solves the problem. Note: Filling up the /boot partition causes updates to fail. ProblemType: Bug DistroRelease: Ubuntu 15.04 Package: dkms 2.2.0.3-2ubuntu3.3 ProcVersionSignature: Ubuntu 3.19.0-28.30-generic 3.19.8-ckt5 Uname: Linux 3.19.0-28-generic x86_64 ApportVersion: 2.17.2-0ubuntu1.7 Architecture: amd64 CurrentDesktop: KDE Date: Thu Nov 12 08:17:10 2015 InstallationDate: Installed on 2015-05-05 (190 days ago) InstallationMedia: Ubuntu 15.04 "Vivid Vervet" - Release amd64 (20150422) PackageArchitecture: all SourcePackage: dkms UpgradeStatus: No upgrade log present (probably fresh install) To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/dkms/+bug/1515513/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1597661] Re: When /boot is full, repeated mkinitramfs runs can fill up /
The commit for this in upstream Debian (0.123 version of initramfs- tools) is here: https://anonscm.debian.org/cgit/kernel/initramfs- tools.git/commit/?id=ac6d31fc2c707b72ff8af9944c9b4f8af303a6a3 - I would be happy to make a patch for this commit to xenial (zesty and later has 0.125+, so should already include the fix). -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to initramfs-tools in Ubuntu. https://bugs.launchpad.net/bugs/1597661 Title: When /boot is full, repeated mkinitramfs runs can fill up / Status in One Hundred Papercuts: Confirmed Status in initramfs-tools: Confirmed Status in initramfs-tools package in Ubuntu: Confirmed Status in initramfs-tools package in Debian: Fix Released Bug description: My /boot partition filled up so when I (or unattended upgrades) next attempted to install a kernel, it failed. On failure, mkinitramfs leaves a temporary directory in /var/tmp. If you (or unattended upgrades) do this enough times, you can end up with substantial, non-obvious disk usage. (I believe that this is fixed in Debian: https://bugs.debian.org/cgi- bin/bugreport.cgi?bug=814345) ProblemType: Bug DistroRelease: Ubuntu 16.04 Package: initramfs-tools 0.122ubuntu8 ProcVersionSignature: Ubuntu 4.4.0-28.47-generic 4.4.13 Uname: Linux 4.4.0-28-generic x86_64 ApportVersion: 2.20.1-0ubuntu2.1 Architecture: amd64 Date: Thu Jun 30 09:12:45 2016 EcryptfsInUse: Yes InstallationDate: Installed on 2014-07-30 (700 days ago) InstallationMedia: Ubuntu-Server 14.04.1 LTS "Trusty Tahr" - Release amd64 (20140722.3) PackageArchitecture: all SourcePackage: initramfs-tools UpgradeStatus: Upgraded to xenial on 2016-03-07 (114 days ago) To manage notifications about this bug go to: https://bugs.launchpad.net/hundredpapercuts/+bug/1597661/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
