[Bug 1954481] [NEW] package linux-image-5.13.0-1007-aws 5.13.0-1007.8 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1
Public bug reported: Upgrade from 21.04 to 21.10 using do-release-upgrade ProblemType: Package DistroRelease: Ubuntu 21.10 Package: linux-image-5.13.0-1007-aws 5.13.0-1007.8 ProcVersionSignature: Ubuntu 5.11.0-1022.23-aws 5.11.22 Uname: Linux 5.11.0-1022-aws aarch64 ApportVersion: 2.20.11-0ubuntu71 Architecture: arm64 CasperMD5CheckResult: unknown Date: Fri Dec 10 19:15:53 2021 Ec2AMI: ami-05147d015de80c44e Ec2AMIManifest: (unknown) Ec2AvailabilityZone: us-east-1c Ec2InstanceType: t4g.nano Ec2Kernel: unavailable Ec2Ramdisk: unavailable ErrorMessage: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 Python3Details: /usr/bin/python3.9, Python 3.9.7, python3-minimal, 3.9.4-1build1 PythonDetails: N/A RebootRequiredPkgs: Error: path contained symlinks. RelatedPackageVersions: dpkg 1.20.9ubuntu2 apt 2.3.9 SourcePackage: initramfs-tools Title: package linux-image-5.13.0-1007-aws 5.13.0-1007.8 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 UpgradeStatus: Upgraded to impish on 2021-12-10 (0 days ago) ** Affects: initramfs-tools (Ubuntu) Importance: Undecided Status: New ** Tags: apport-package arm64 ec2-images impish need-duplicate-check -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1954481 Title: package linux-image-5.13.0-1007-aws 5.13.0-1007.8 failed to install/upgrade: run-parts: /etc/kernel/postinst.d/initramfs-tools exited with return code 1 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/initramfs-tools/+bug/1954481/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849156] Re: systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed
I realize that the title makes it sound as though this is intended behavior. To be clear, in this scenario, neither systemd- timesyncd.service nor ntp.service start. It's not just systemd- timesyncd.service that doesn't start, as that would be intended behavior. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849156 Title: systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849156/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1849156] [NEW] systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed
Public bug reported: Ubuntu 19.10's systemd package introduced /lib/systemd/system/systemd- timesyncd.service.d/disable-with-time-daemon.conf. This prevents systemd-timesyncd.service from starting if the ntp package has been installed. However, ntp.service has a Conflicts directive for systemd- timesyncd.service. If both services are enabled, neither will start on boot. This breaks upgrades from < 19.10 to 19.10 for systems that have both ntp and systemd installed. Possible workarounds: - Uninstall ntp - Disable systemd-timesyncd.service % lsb_release -rd Description:Ubuntu 19.10 Release:19.10 % apt-cache policy systemd systemd: Installed: 242-7ubuntu3 Candidate: 242-7ubuntu3 Version table: *** 242-7ubuntu3 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu eoan/main amd64 Packages 100 /var/lib/dpkg/status % apt-cache policy ntp ntp: Installed: 1:4.2.8p12+dfsg-3ubuntu2 Candidate: 1:4.2.8p12+dfsg-3ubuntu2 Version table: *** 1:4.2.8p12+dfsg-3ubuntu2 500 500 http://us-east-1.ec2.archive.ubuntu.com/ubuntu eoan/universe amd64 Packages 100 /var/lib/dpkg/status % dpkg -S /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf systemd: /lib/systemd/system/systemd-timesyncd.service.d/disable-with-time-daemon.conf % sudo systemctl status ntp ● ntp.service - Network Time Service Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled) Active: inactive (dead) Docs: man:ntpd(8) % sudo systemctl status systemd-timesyncd.service ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Drop-In: /lib/systemd/system/systemd-timesyncd.service.d └─disable-with-time-daemon.conf Active: inactive (dead) Condition: start condition failed at Mon 2019-10-21 12:05:38 EDT; 29s ago Docs: man:systemd-timesyncd.service(8) Oct 21 12:05:38 ubuntu systemd[1]: Condition check resulted in Network Time Synchronization being skipped. ** Affects: systemd (Ubuntu) Importance: Undecided Status: New -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1849156 Title: systemd-timesyncd.service broken on upgrade to 19.10 if ntp was installed To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1849156/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1718948] Re: Traceback when running `s3cmd --configure`
Subscribing maintainer, as this is a serious bug that's been fixed upstream for quite a while. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1718948 Title: Traceback when running `s3cmd --configure` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/s3cmd/+bug/1718948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1718948] Re: Traceback when running `s3cmd --configure`
Why did artful ship with this version of s3cmd? It was known to be broken at the time of artful's release. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1718948 Title: Traceback when running `s3cmd --configure` To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/s3cmd/+bug/1718948/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1518457] Re: kswapd0 100% CPU usage
>From man 7 udev: The udev rules are read from the files located in the system rules directory /lib/udev/rules.d, the volatile runtime directory /run/udev/rules.d and the local administration directory /etc/udev/rules.d. All rules files are collectively sorted and processed in lexical order, regardless of the directories in which they live. However, files with identical filenames replace each other. Files in /etc have the highest priority, files in /run take precedence over files with the same name in /lib. This can be used to override a system- supplied rules file with a local file if needed; a symlink in /etc with the same name as a rules file in /lib, pointing to /dev/null, disables the rules file entirely. Rule files must have the extension .rules; other extensions are ignored. As such, the best way to work around this is: sudo ln -s /dev/null /etc/udev/rules.d/40-vm-hotadd.rules Unlike deleting or modifying the original file, this will persist across upgrades without requiring manual conflict resolution. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1518457 Title: kswapd0 100% CPU usage To manage notifications about this bug go to: https://bugs.launchpad.net/linux/+bug/1518457/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1525015] Re: Regression of #1510345: [SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules
** Description changed:
+ Tested with ami-305d115a and equivalent nightly builds from 2015-12-08
+ and 2015-12-10. It's possible to work around the issue by copying the
+ image's snapshot and changing eth0 to ens3 in
+ /etc/network/interfaces.d/eth0.cfg prior to first boot, but most users
+ probably won't think to do that since it's not actually possible to get
+ access to the file system over SSH before applying the workaround.
+
Copied from https://bugs.launchpad.net/ubuntu/+source/livecd-
rootfs/+bug/1510345:
SRU Justification
[IMPACT] Cloud images produced by livecd-rootfs are not accessable when
presented with certain NICS such as ixgbevf used on HVM instances for
AWS.
[CAUSE] Changes in default device naming in 15.10 causes some devices to
be named at boot time and are not predicatable, i.e. instead of "eth0"
being the first NIC, "ens3" might be used.
[FIX] Boot instances with "net.ifnames=0". This change reverts to the
old device naming conventions. As a fix, this is the most appropriate
since the cloud images configure the first NIC for DHCP.
[TEST CASE1]:
- Build image from -proposed
- Boot image in KVM, i.e:
$ qemu-system-x86_64 \
-smp 2 -m 1024 -machine accel=kvm \
-drive file=build.img,if=virtio,bus=0,cache=unsafe,unit=0,snapshot=on \
-net nic,model=rtl8139
- Confirm that image has "eth0"
[TEST CASE2]:
- Build image from -proposed
- Publish image to AWS as HVM w/ SRIOV enabled
- Confirm that instance boots and is accessable via SSH
[ORIGINAL REPORT]
I've made several attempts to launch a c4.xlarge and c4.8xlarge
instances using Ubuntu 15.10 Wily but am unable to ping the instance
after it has started running. The console shows that the instance
reachability check failed.
I am able to successfully launch c4.xlarge instances using Ubuntu 14.04
and t2.large instances using Ubuntu 15.10.
I've tried with both of these instance AMIs:
ubuntu/images/hvm-ssd/ubuntu-wily-15.10-amd64-server-20151021 - ami-225ebd11
ubuntu/images-testing/hvm-ssd/ubuntu-wily-daily-amd64-server-20151026 -
ami-ea20cdd9
Might there be a problem with the Ubuntu Kernel in 15.10 for the c4
instances?
Looking at the system log it seems that the network never comes up:
[ 140.699509] cloud-init[1469]: 2015-10-26 20:45:49,887 -
url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-
data/instance-id' failed [0/120s]: request error [('Connection
aborted.', OSError(101, 'Network is unreachable'))]
Thread at AWS forums:
https://forums.aws.amazon.com/thread.jspa?threadID=218656
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1525015
Title:
Regression of #1510345: [SRU] Cloud Images do not bring up networking
w/ certain virtual NICs due to device naming rules
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1525015/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1525015] Re: Regression of #1510345: [SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules
** Description changed:
- Copied from #1510345:
+ Copied from https://bugs.launchpad.net/ubuntu/+source/livecd-
+ rootfs/+bug/1510345:
SRU Justification
[IMPACT] Cloud images produced by livecd-rootfs are not accessable when
presented with certain NICS such as ixgbevf used on HVM instances for
AWS.
[CAUSE] Changes in default device naming in 15.10 causes some devices to
be named at boot time and are not predicatable, i.e. instead of "eth0"
being the first NIC, "ens3" might be used.
[FIX] Boot instances with "net.ifnames=0". This change reverts to the
old device naming conventions. As a fix, this is the most appropriate
since the cloud images configure the first NIC for DHCP.
[TEST CASE1]:
- Build image from -proposed
- Boot image in KVM, i.e:
- $ qemu-system-x86_64 \
--smp 2 -m 1024 -machine accel=kvm \
--drive file=build.img,if=virtio,bus=0,cache=unsafe,unit=0,snapshot=on \
--net nic,model=rtl8139
+ $ qemu-system-x86_64 \
+ -smp 2 -m 1024 -machine accel=kvm \
+ -drive file=build.img,if=virtio,bus=0,cache=unsafe,unit=0,snapshot=on \
+ -net nic,model=rtl8139
- Confirm that image has "eth0"
[TEST CASE2]:
- Build image from -proposed
- Publish image to AWS as HVM w/ SRIOV enabled
- Confirm that instance boots and is accessable via SSH
[ORIGINAL REPORT]
I've made several attempts to launch a c4.xlarge and c4.8xlarge
instances using Ubuntu 15.10 Wily but am unable to ping the instance
after it has started running. The console shows that the instance
reachability check failed.
I am able to successfully launch c4.xlarge instances using Ubuntu 14.04
and t2.large instances using Ubuntu 15.10.
I've tried with both of these instance AMIs:
ubuntu/images/hvm-ssd/ubuntu-wily-15.10-amd64-server-20151021 - ami-225ebd11
ubuntu/images-testing/hvm-ssd/ubuntu-wily-daily-amd64-server-20151026 -
ami-ea20cdd9
Might there be a problem with the Ubuntu Kernel in 15.10 for the c4
instances?
Looking at the system log it seems that the network never comes up:
[ 140.699509] cloud-init[1469]: 2015-10-26 20:45:49,887 -
url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-
data/instance-id' failed [0/120s]: request error [('Connection
aborted.', OSError(101, 'Network is unreachable'))]
Thread at AWS forums:
https://forums.aws.amazon.com/thread.jspa?threadID=218656
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1525015
Title:
Regression of #1510345: [SRU] Cloud Images do not bring up networking
w/ certain virtual NICs due to device naming rules
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1525015/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1525015] [NEW] Regression of #1510345: [SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules
Public bug reported:
Copied from #1510345:
SRU Justification
[IMPACT] Cloud images produced by livecd-rootfs are not accessable when
presented with certain NICS such as ixgbevf used on HVM instances for
AWS.
[CAUSE] Changes in default device naming in 15.10 causes some devices to
be named at boot time and are not predicatable, i.e. instead of "eth0"
being the first NIC, "ens3" might be used.
[FIX] Boot instances with "net.ifnames=0". This change reverts to the
old device naming conventions. As a fix, this is the most appropriate
since the cloud images configure the first NIC for DHCP.
[TEST CASE1]:
- Build image from -proposed
- Boot image in KVM, i.e:
$ qemu-system-x86_64 \
-smp 2 -m 1024 -machine accel=kvm \
-drive file=build.img,if=virtio,bus=0,cache=unsafe,unit=0,snapshot=on \
-net nic,model=rtl8139
- Confirm that image has "eth0"
[TEST CASE2]:
- Build image from -proposed
- Publish image to AWS as HVM w/ SRIOV enabled
- Confirm that instance boots and is accessable via SSH
[ORIGINAL REPORT]
I've made several attempts to launch a c4.xlarge and c4.8xlarge
instances using Ubuntu 15.10 Wily but am unable to ping the instance
after it has started running. The console shows that the instance
reachability check failed.
I am able to successfully launch c4.xlarge instances using Ubuntu 14.04
and t2.large instances using Ubuntu 15.10.
I've tried with both of these instance AMIs:
ubuntu/images/hvm-ssd/ubuntu-wily-15.10-amd64-server-20151021 - ami-225ebd11
ubuntu/images-testing/hvm-ssd/ubuntu-wily-daily-amd64-server-20151026 -
ami-ea20cdd9
Might there be a problem with the Ubuntu Kernel in 15.10 for the c4
instances?
Looking at the system log it seems that the network never comes up:
[ 140.699509] cloud-init[1469]: 2015-10-26 20:45:49,887 -
url_helper.py[WARNING]: Calling 'http://169.254.169.254/2009-04-04/meta-
data/instance-id' failed [0/120s]: request error [('Connection
aborted.', OSError(101, 'Network is unreachable'))]
Thread at AWS forums:
https://forums.aws.amazon.com/thread.jspa?threadID=218656
** Affects: livecd-rootfs (Ubuntu)
Importance: Undecided
Status: New
** Tags: cloud-images ec2 regression-update wily
** Attachment added: "Boot logs from EC2 console"
https://bugs.launchpad.net/bugs/1525015/+attachment/4532875/+files/ec2-console.log
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1525015
Title:
Regression of #1510345: [SRU] Cloud Images do not bring up networking
w/ certain virtual NICs due to device naming rules
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/livecd-rootfs/+bug/1525015/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 1510345] Re: [SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules
Regressed; reported at https://bugs.launchpad.net/ubuntu/+source/livecd- rootfs/+bug/1525015 -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1510345 Title: [SRU] Cloud Images do not bring up networking w/ certain virtual NICs due to device naming rules To manage notifications about this bug go to: https://bugs.launchpad.net/cloud-init/+bug/1510345/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 363695] Re: update-apt-xapian-index uses too much CPU and memory
Encountered this on a fresh instance of raring immediately after installing and updating apt-file. sudo apt-file purge immediately fixed the issue. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/363695 Title: update-apt-xapian-index uses too much CPU and memory To manage notifications about this bug go to: https://bugs.launchpad.net/apt/+bug/363695/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 445863] Re: Spell checking doesn't allow US English words when using "English" language
As of Ubuntu 12.10, the relevant dconf path is /org/gnome/empathy/conversation/spell-checker-languages. Change the value to whatever language you want (e.g., "en-US"). -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/445863 Title: Spell checking doesn't allow US English words when using "English" language To manage notifications about this bug go to: https://bugs.launchpad.net/empathy/+bug/445863/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
