[Bug 1851465] Re: apt-offline install fails
Affects at least bionic and disco - both share the same 1.8.1 version of apt-offline, which has this bug. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1851465 Title: apt-offline install fails To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/apt-offline/+bug/1851465/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
@racb I'm not sure that I would consider it normal or expected, though, for system services to suddenly stop working due to regular updates, and for a server to suddenly become unreachable and unresponsive just because it was updated. On the other hand, it's certainly not desirable for a system to silently operate with poor entropy and poor encryption quality. In my case, this is easily resolved due to the hardware RNG on the TI AM335X chip. However, AFAIK a Raspberry PI does not have a hardware RNG, nor do many embedded processors / systems - meaning they would have low entropy at boot, and rng-tools most likely won't help. Without looking at any code, here are a few observations. Does nginx really need to make this blocking call to openssl when the service starts? or only when the first https request is made to the service? That is, if no https request comes in for 2 min, or 10 min, maybe there would be sufficient entropy by then due to system activity. Does openssl really need to block on initialization until sufficient entropy exists? Or could it defer that until some subsequent call that does actually need adequate entropy? In other words, would moving this blocking behavior to a different function satisfy the security need that led to its implementation, without potentially blocking systemd services at boot time? Finally, I have a couple of the same devices that do not exhibit this blocking behavior. I'm not sure exactly why, but the difference appears somehow related to the way updates are applied. I've noticed a file '/.rnd' (from memory) which is used and/or generated by openssl. Looks like this file is used as an entropy seed. Once deleted (and the hardware RNG is not used), the nginx systemd service will start blocking and timing out. Attempts to create this file manually using openssl do not allow the nginx service to start successfully at boot. Maybe the simple fix is to find the right way to create and manage the /.rnd file on devices with low entropy? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835464 Title: nginx service fails after libssl update due to low entropy at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1835464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
@teward No, I'm not sure whether it's an nginx bug. openssl packages were updated; nginx package is at the same version. Basically, it looks like an openssl call that previously succeeded (and probably gave questionable responses) now has become a blocking call that doesn't return until sufficient entropy is available to ensure a reasonably secure random result. Where before nginx completed in a timely manner, it appears to be now blocking, and failing to start within the systemd timeout period, If that's the case (which looks likely), then other services which depend on openssl may time out as well. (tomcat with APR comes to mind as one possibility.) -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835464 Title: nginx service fails after libssl update due to low entropy at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1835464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
@xnox In my case, this is on a TI AM3352 processor. The key config item is: CONFIG_HW_RANDOM_OMAP=m TI's docs indicate that the following is important: CONFIG_CRYPTO_DEV_OMAP_SHAM=y And these may be related: CONFIG_CRYPTO_DEV_OMAP_AES=y CONFIG_CRYPTO_SHA256_ARM=y CONFIG_CRYPTO_SHA512_ARM=y In general, for devices having a hardware random number generator, I believe the following are needed: CONFIG_HW_RANDOM=m CONFIG_HW_RANDOM_TPM=m I started by building an ubuntu kernel for this ARM processor; but after some backported kernel patches broke the ubuntu kernel for my device, I switched to the kernel.org stock 4.9 LTS kernel. Incidentally, that's made it easier to get support from driver developers. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835464 Title: nginx service fails after libssl update due to low entropy at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/nginx/+bug/1835464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1835464] [NEW] nginx service fails after libssl update due to low entropy at boot
Public bug reported: After updating libssl and related packages, nginx will no longer autostart at system boot. Immediately after boot, nginx.service is in a failed state. # service nginx status ● 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: timeout) since Fri 2018-08-24 21:27:51 UTC; 32min ago Docs: man:nginx(8) systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Start-pre operation timed out. Terminating. systemd[1]: nginx.service: Failed with result 'timeout'. systemd[1]: Failed to start A high performance web server and a reverse proxy server. The service can be manually started after boot. # service nginx start # service nginx status ● nginx.service - A high performance web server and a reverse proxy server Loaded: loaded (/lib/systemd/system/nginx.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2018-08-24 22:02:06 UTC; 2s ago Docs: man:nginx(8) Process: 2704 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Process: 2703 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS) Main PID: 2705 (nginx) CGroup: /system.slice/nginx.service ├─2705 nginx: master process /usr/sbin/nginx -g daemon on; master_process on; └─2706 nginx: worker process systemd[1]: Starting A high performance web server and a reverse proxy server... systemd[1]: nginx.service: Failed to parse PID from file /run/nginx.pid: Invalid argument systemd[1]: Started A high performance web server and a reverse proxy server. This happens on an ARMHF based microcontroller running ubuntu 18.04.2 raspi server distribution with a stock kernel.org 4.9-181 kernel. Ubuntu repositories are not accessible from the device, so packages are copied to the device, and apt install is used to upgrade them: apt install --no-install-recommends $dir/updates/system/*.deb | logger 2>&1 The following is a list of packages that, when upgraded, cause the nginx systemd service to fail to autostart at boot. 201,205c201,205 < ii libpython2.7:armhf 2.7.15-4ubuntu4~18.04 armhf Shared Python runtime library (version 2.7) < ii libpython2.7-minimal:armhf 2.7.15-4ubuntu4~18.04 armhf Minimal subset of the Python language (version 2.7) < ii libpython2.7-stdlib:armhf 2.7.15-4ubuntu4~18.04 armhf Interactive high-level object-oriented language (standard library, version 2.7) < ii libpython3.6-minimal:armhf 3.6.8-1~18.04.1 armhf Minimal subset of the Python language (version 3.6) < ii libpython3.6-stdlib:armhf 3.6.8-1~18.04.1 armhf Interactive high-level object-oriented language (standard library, version 3.6) --- > ii libpython2.7:armhf 2.7.15~rc1-1ubuntu0.1 armhf > Shared Python runtime library (version 2.7) > ii libpython2.7-minimal:armhf 2.7.15~rc1-1ubuntu0.1 armhf > Minimal subset of the Python language (version 2.7) > ii libpython2.7-stdlib:armhf 2.7.15~rc1-1ubuntu0.1 armhf > Interactive high-level object-oriented language (standard library, > version 2.7) > ii libpython3.6-minimal:armhf 3.6.7-1~18.04 armhf > Minimal subset of the Python language (version 3.6) > ii libpython3.6-stdlib:armhf 3.6.7-1~18.04 armhf > Interactive high-level object-oriented language (standard library, > version 3.6) 225c225 < ii libssl1.1:armhf 1.1.1-1ubuntu2.1~18.04.2 armhf Secure Sockets Layer toolkit - shared libraries --- > ii libssl1.1:armhf 1.1.0g-2ubuntu4.3 armhf > Secure Sockets Layer toolkit - shared libraries 272c272 < ii openssl 1.1.1-1ubuntu2.1~18.04.2 armhf Secure Sockets Layer toolkit - cryptographic utility --- > ii openssl 1.1.0g-2ubuntu4.3 armhf > Secure Sockets Layer toolkit - cryptographic utility 282,283c282,283 < ii python3.6 3.6.8-1~18.04.1 armhf Interactive high-level object-oriented language (version 3.6) < ii python3.6-minimal 3.6.8-1~18.04.1 armhf Minimal subset of the Python language (version 3.6) --- > ii python3.6 3.6.7-1~18.04 armhf > Interactive high-level object-oriented language (version 3.6) > ii python3.6-minimal 3.6.7-1~18.04 armhf > Minimal subset of the Python language (version 3.6) nginx is used primarily as an https front-end for
[Bug 1835464] Re: nginx service fails after libssl update due to low entropy at boot
This appears to be due to openssl requests blocking or failing until sufficient entropy is available for random number generation. The target device is based on the TI AM335X (Sitara) ARM Cortex A8 SOC. The SOC (system on a chip) has a hardware random number generator, which requires a kernel driver to be built. Though the kernel driver was being loaded, that's not enough for the hardware RNG to be used by the OS. After installing the rng-tools package, which connects the hardware RNG / kernel driver to the OS layer, entropy at boot went up 100-fold; and nginx started normally at boot. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1835464 Title: nginx service fails after libssl update due to low entropy at boot To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+bug/1835464/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1753518] Re: package grub-efi-amd64-signed 1.93+2.02-2ubuntu8 failed to install/upgrade: installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1
This has completely bricked an AMD E-350-based mini PC. I recently installed ubuntu 18.04 server; and 3 updates later, I can't boot the device at all. Not even POST video output. Pulling the CMOS battery didn't help. The system ran fine for 4+ years running CentOS 7 server. Here's the apt update output: # apt update ... 10 packages can be upgraded. Run 'apt list --upgradable' to see them. # apt upgrade Reading package lists... Done Building dependency tree Reading state information... Done Calculating upgrade... Done The following packages will be upgraded: grub-common grub-efi-amd64 grub-efi-amd64-bin grub-efi-amd64-signed grub2-common libidn11 libunistring2 python3-httplib2 ufw unattended-upgrades 10 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. ... Setting up grub-efi-amd64-bin (2.02-2ubuntu8.13) ... Setting up grub2-common (2.02-2ubuntu8.13) ... Processing triggers for systemd (237-3ubuntu10.19) ... Setting up grub-efi-amd64 (2.02-2ubuntu8.13) ... Installing for x86_64-efi platform. Could not delete variable: No space left on device grub-install: error: efibootmgr failed to register the boot entry: Block device required. Failed: grub-install --target=x86_64-efi WARNING: Bootloader is not properly installed, system may not be bootable Sourcing file `/etc/default/grub' Generating grub configuration file ... Found linux image: /boot/vmlinuz-4.15.0-47-generic Found initrd image: /boot/initrd.img-4.15.0-47-generic Found linux image: /boot/vmlinuz-4.15.0-46-generic Found initrd image: /boot/initrd.img-4.15.0-46-generic done Setting up grub-efi-amd64-signed (1.93.14+2.02-2ubuntu8.13) ... Installing for x86_64-efi platform. Could not prepare Boot variable: No space left on device grub-install: error: efibootmgr failed to register the boot entry: Input/output error. dpkg: error processing package grub-efi-amd64-signed (--configure): installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1 Processing triggers for libc-bin (2.27-3ubuntu1) ... Errors were encountered while processing: grub-efi-amd64-signed E: Sub-process /usr/bin/dpkg returned an error code (1) During the failed update, I was prompted for a new grub config file. I chose to keep my existing file (the default, believe). Next, I tried: # dpkg-reconfigure grub-efi-amd64-signed /usr/sbin/dpkg-reconfigure: grub-efi-amd64-signed is broken or not fully installed root@giraffe:/home/dietmar# apt install grub-efi-amd64-signed Reading package lists... Done Building dependency tree Reading state information... Done grub-efi-amd64-signed is already the newest version (1.93.14+2.02-2ubuntu8.13). 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 1 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Do you want to continue? [Y/n] y Setting up grub-efi-amd64-signed (1.93.14+2.02-2ubuntu8.13) ... Installing for x86_64-efi platform. Could not prepare Boot variable: No space left on device grub-install: error: efibootmgr failed to register the boot entry: Input/output error. dpkg: error processing package grub-efi-amd64-signed (--configure): installed grub-efi-amd64-signed package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent processing triggers for shim-signed: shim-signed depends on grub-efi-amd64-signed; however: Package grub-efi-amd64-signed is not configured yet. df showed plenty of free space on all partitions: Filesystem 1K-blocksUsed Available Use% Mounted on udev 4035776 0 4035776 0% /dev tmpfs 8131842336810848 1% /run /dev/sda2 45876068 4616084 38899872 11% / tmpfs4065908 0 4065908 0% /dev/shm tmpfs 5120 0 5120 0% /run/lock tmpfs4065908 0 4065908 0% /sys/fs/cgroup /dev/sda1 5232486152517096 2% /boot/efi /dev/sda4 106674880 65120 101147952 1% /home tmpfs 813180 0813180 0% /run/user/1000 I tried the workaround from Ronan Mooney. https://bugs.launchpad.net/ubuntu/+source/grub2-signed/+bug/1753518/comments/11 That allowed apt to complete without an error; however, it left the system in an unbootable state. # mv ubuntu/ ubuntu.bak # apt install -f Reading package lists... Done Building dependency tree Reading state information... Done 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. 2 not fully installed or removed. After this operation, 0 B of additional disk space will be used. Setting up grub-efi-amd64-signed (1.93.14+2.02-2ubuntu8.13) ... Setting up shim-signed (1.37~18.04.3+15+1533136590.3beb971-0ubuntu1) ... W: APT had planned for dpkg to do more than it reported back (3 vs 7). Affected packages: grub-efi-amd64-signed:amd64 # apt install --reinstall grub-common grub-efi-amd64 grub-efi-amd64-bin grub2-common Reading package
[Bug 1577049] Re: The switch user feature has disappeared from indicator applet since upgrade from 15.10 to 16.04
Affects me too. Switching users is still possible, it's just missing from the indicator applet. A couple of possible workarounds in http://ubuntuforums.org/showthread.php?t=2326209=13505357#post13505357 Comment #7. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1577049 Title: The switch user feature has disappeared from indicator applet since upgrade from 15.10 to 16.04 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/gnome-shell/+bug/1577049/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1568604] Re: Mouse cursor lost when unlocking with Intel graphics
I'm running Ubuntu Gnome 16.04, with gdm3. I do not have light-locker or xscreensaver installed. This happens almost every time that I fast switch to a different user. Pushing the mouse to the upper left corner (which shows the Activities Overview) and pressing Ctrl makes the cursor show up - every time. Pressing Super (which shows the Activities Overview) and nudging the mouse makes the cursor show up - every time. Nudging the mouse and then pressing Super makes the cursor show up. This combination - in just about any order - seems to reliably make the mouse reappear: * Move the mouse * Press a key * Show the activities overview -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1568604 Title: Mouse cursor lost when unlocking with Intel graphics To manage notifications about this bug go to: https://bugs.launchpad.net/xorg-server/+bug/1568604/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
