[Bug 1925010] Re: shim-signed 15.4 does not boot on EFI 1.10 systems
Yes, and why can't we use the old binaries that worked before? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1925010 Title: shim-signed 15.4 does not boot on EFI 1.10 systems To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/shim/+bug/1925010/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1880409] [NEW] Prompting for change to sshd_config might cause lock-out from upgrade process
Public bug reported: Upgrading to a new release is often done with do-release-upgrade. If you do this via SSH, this probably runs in a dedicated "screen" session. At some point you might be asked to replace your current "sshd_config" with the package maintainer's one. While sitting at this prompt, you can't open a new SSH connection to your machine. If you let the upgrade run in the background from a remote pc, you might lose connection in the meantime. If the upgrade reaches this prompt, you will not be able to log in and resume your upgrade with SSH, as sshd won't accept connections. The port is opened and you can connect, but sshd will immediately close the connection, without even prompting for credentials. If you have no other means but SSH to access your server (e.g. headless vps), you won't be able to login again and might be forced to a reinstallation (or some other form of recovery operation). ** Affects: ubuntu-release-upgrader (Ubuntu) Importance: Undecided Status: New ** Tags: do-release-upgrade ssh sshd upgrade -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1880409 Title: Prompting for change to sshd_config might cause lock-out from upgrade process To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/1880409/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1861472] Re: upgrade from fresh bionic to focal needlessly prompts user
Another problem is that while showing this prompt, you can't log in via SSH. If you leave your upgrade unattended and lose the connection to your server, you won't be able to log in via SSH again to complete/continue the upgrade. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1861472 Title: upgrade from fresh bionic to focal needlessly prompts user To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1861472/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1743592] Re: NGINX fails to start/install/upgrade if IPv6 is completely disabled.
Will it log as :::10.1.2.3 if IPv6 is disabled on the system? I could imagine this notation could confuse some tools for automatic analyses of logfiles. I fear that this would break something in the background without people even realizing it until it is too late. Imo failing hard should be the preferred option. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743592 Title: NGINX fails to start/install/upgrade if IPv6 is completely disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1743592] Re: NGINX fails to start/install/upgrade if IPv6 is completely disabled.
Addition: Actually I think the best solution would be to test for IPv6 at runtime and produce just a warning instead of failing. Same for systems where IPv4 is disabled but the config still contains the IPv4 directive. Any objections? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743592 Title: NGINX fails to start/install/upgrade if IPv6 is completely disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1743592] Re: NGINX fails to start/install/upgrade if IPv6 is completely disabled.
Thomas Ward: Which part are you referring to exactly? I agree automating the detection of everything seems a bit over the top. But for something so fundamental as the different IP-stacks, I think it is well worth considering it, though I am also not really happy as I still believe whoever disables IPv6 system-wide should consider the consequences. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743592 Title: NGINX fails to start/install/upgrade if IPv6 is completely disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1743592] Re: NGINX fails to start/install/upgrade if IPv6 is completely disabled.
Opting for #1 is a stupid idea. Yes, personally I hate it because many times I have been wondering why it's not listening on IPv6 only to find out that the configuration line "listen 80 default_server;" doesn't in fact mean to just listen on port 80, but to listen only on port 80 for IPv4. In my opinion this configuration line doesn't make it clear, and if it stays like this, then "#listen [::]:80 default_server;" needs to be included in this way at the very least (note the hash symbol)! What is another problem is hosting providers that are dual-stacked, and where maybe -records already exist. In those cases the client would first try to connect to the IPv6 address which has no nginx listening on port 80. Happy eyeballs should take care of this and fallback to IPv4, but that doesn't always seem to work properly. On another note this is another step towards cannibalizing the deployment of IPv6 by making it opt-in instead of opt-out. Either implement option #2 or return to the way it was before and leave it up to the admin to figure out why his config doesn't work on the system he fiddled with. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1743592 Title: NGINX fails to start/install/upgrade if IPv6 is completely disabled. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1743592/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
