Bug#996804: Acknowledgement (NetworkManager reverts to EUI-64 addresses after Bullseye upgrade)

Workaround/ solution: Commented out the `inet6 auto` stanza for the interface in /etc/network/interfaces and now it keeps a stable private address as expected. NetworkManager always seemed to yield to ifup/down (or perhaps the reverse) in prior versions of Debian, so I hadn't thought to check

Bug#996804: NetworkManager reverts to EUI-64 addresses after Bullseye upgrade

Package: network-manager Version: 1.30.0-2 tags: ipv6 I'm running a Debian system on a LAN segment configured to assign IPv6 addresses via SLAAC. After upgrading from Buster to Bullseye, NetworkManager starts the system with an IPv6 stable-privacy address as usual. However, after some time

Bug#931644: Buster kernel entropy pool too low on VM boot

I've upgraded my VMs to the 10.3 point release and can confirm that cryptographic services (SSH and others) start quite rapidly now on system boot. Thanks, all! -Michael

Bug#931644: Buster kernel entropy pool too low on VM boot

Apologies for the late reply. I can certainly test on some of my VMs if you're willing to provide packages. Reading over Linus' explanation of deriving jitter from the CPU's cycle counter, while I'm no cryptographer, I might have some concerns about the quality of the entropy that will be

Bug#931644: Buster kernel entropy pool too low on VM boot

> The release notes for buster do mention this issue and provide a > link to: > > https://wiki.debian.org/BoottimeEntropyStarvation > > which has your Haveged solution as one of its suggestions. > D'oh! Serves me right for just skimming the release notes, then. After doing some in-depth

Bug#931644: Buster kernel entropy pool too low on VM boot

Package: linux-image-4.19.0-5-amd64 Version: 4.19.0-5 Issue: == After upgrading to Debian Buster, Xen PV guests' entropy pool is too low to start cryptographic services in a timely manner. This results in 30+ second delays in the startup of services such as SSH. If I connect to the VM's

Bug#903821: 4.9.110-1 Xen PV boot workaround

I've tested the workaround successfully. Added `pti=off` to my kernel's boot arguments, updated GRUB, and it started as intended. Benoît, Just to be sure, since you're loading your guests' kernels directly like that, you're passing pti=off via the `extra` config line in your domU config files,

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

This also apparently affects at least PV guests. Upgrading a PV domU to kernel 4.9.110-1 and rebooting yields the following output via xl's console: Loading Linux 4.9.0-6-amd64 ... Loading Linux 4.9.0-7-amd64 ... Loading initial ramdisk ...   [ vmlinuz-4.9.0-7- amd6  2.69MiB  66%  1.67MiB/s ] [ 

Bug#903767: Stretch kernel 4.9.110-1 boot-loops with Xen Hypervisor 4.8

Package: linux-image-4.9.0-7-amd64 Version: 4.9.110-1 Description: After installing the latest Stretch kernel, 4.9.110-1, on a server running Xen Hypervisor 4.8, bootstrapping the kernel fails. GRUB loads the hypervisor as normal, which then attempts to load the Dom0 kernel. Once

Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

On further investigation, Arne's absolutely right. I upgraded the kernel back to 4.9.88-1 from Debian Security and installed 'haveged' (another random number generator). Everything started quickly and normally after a reboot. Turns out I hadn't noticed this on any of my other virtual servers

Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

Interesting! I'd also noticed 'random: init done' being piped to console well after the server had booted, but I didn't mention it because I didn't think it was related. What you've said makes a lot of sense. On Sat, 5 May 2018 11:54:54 +0200 Arne Nordmark wrote: > I have

Bug#897917: Stretch kernel 4.9.88-1 breaks startup of RPC, KDC services

Package: linux-image-4.9.0-6-amd64 Version: 4.9.88-1 Issue: == Kernel "linux-image-4.9.0-6-amd64," version 4.9.88-1, breaks systemd startup of RPC, Kerberos KDC services.  Description: After upgrading to the latest Stretch kernel (4.9.88-1), RPC and KDC services time out

Bug#887676: Stretch kernel 4.9.0-5-amd64 breaks Xen PVH support

Aha! Okay, that certainly explains some things. I didn't realize PVH was a "use at your own risk" tech preview in Xen 4.8 and kernel 4.9. Luckily, my infrastructure didn't rely on PVH to start with; I can go back to conventional PV or HVM with no problem. Thanks for investigating! -Michael

Bug#887676: Stretch kernel 4.9.0-5-amd64 breaks Xen PVH support

Package: linux-image-amd64 Version: 4.9+80+deb9u Not sure if this needs to go to the Debian Kernel team or Debian Xen team, so please feel free to reclassify as necessary. I'm leaning toward this being a kernel bug, as the Xen packages had not changed when this issue was introduced; only the

Bug#871702: Acknowledgement (Latest Stretch qemu-system-i386 process balloons in Xen Dom0 RAM, crashes DomU)

Now that qemu-system-x86 1:2.8+dfsg-6+deb9u3 has been released, I have upgraded and tested. So far, so good! The CPU and RAM utilization of the `qemu-system-i386` process seems very normal: ~4% CPU usage and ~9% RAM usage. The HVM domU is booted and active. If it goes comatose again, I will let

Bug#871702: Latest Stretch qemu-system-i386 process balloons in Xen Dom0 RAM, crashes DomU

> Does this happen with version 1:2.8+dfsg-6+deb9u1 too? That's a good question. I did not see that version of the package available in `apt-cache` when I performed my rollback, so I cannot say. > Does this happen with qemu-system-x86_64? The architecture being run *is* 64-bit. As I understand

Bug#871702: Acknowledgement (Latest Stretch qemu-system-i386 process balloons in Xen Dom0 RAM, crashes DomU)

Package: qemu-system-x86 Version: 1:2.8+dfsg-6+deb9u2 My apologies for mistakenly sending the original ticket in HTML format. Adding proper header tags here to hopefully make categorization easier. The original HTML transcript (message part 2) is readable.

Bug#871702: Latest Stretch qemu-system-i386 process balloons in Xen Dom0 RAM, crashes DomU

Package: qemu-system-x86Version: 1:2.8+dfsg-6+deb9u2 Problem:==Latest Stretch `qemu-system-i386` process consumes the majority of Xen Dom0's RAM, ultimately crashes DomU. Symptoms:When starting a Xen HVM guest with qemu-system-x86 version 1:2.8+dfsg-6+deb9u2 installed, the