Possibly related (if 3499ba8198ca ("xen: Fix event channel callback via
INTX/GSI") was backported to 5.4.0-67 ):
https://gitlab.alpinelinux.org/alpine/aports/-/issues/12373
https://lore.kernel.org/xen-devel/4c9af052a6e0f6485d1de43f2c38b1461996db99.ca...@infradead.org/
** Bug watch added: gitlab.
Public bug reported:
Fort segfaults after multiple "doesn't have files with extension
'.slurm'" events
Also see upstream report:
https://github.com/NICMx/FORT-validator/issues/41
This is fixed in v1.4.1
Debian already ships v1.4.1:
https://packages.debian.org/bullseye/fort-validator
Please upg
Would probably fix:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1890951
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1889669
Title:
Focal update: v5.4.54 upstream stable release
To manag
Also see:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1889669
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1890951
Title:
btrfs not writable when mounted without "skip_balance"
To manage
The kernel now longer passes vlan tag information as-is to libpcap,
instead BPF needs to access ancillary data.
That is the reason "vlan 114" works (because it does the right thing),
and a manual filter doesn't, because libpcap never actually sees this.
Offsets are negative because this is the wa
I tried Xenial. Yes it does fix the simplified test case in this bug
(when booting doesn't require the second encrypted volume to be open),
but it doesn't fix my real issue, which is encrypting multiple devices
and putting btrfs on top of it. Adding initramfs doesn't help.
So whenever you try boot
** Attachment added: "installer-partitions.png"
https://bugs.launchpad.net/ubuntu/+source/cryptsetup/+bug/1525724/+attachment/4534338/+files/installer-partitions.png
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.laun
Public bug reported:
When /etc/crypttab has more than one luks device, the boot process locks
up (hangs) after the decryption of the first luks device. A password
prompt for the second luks device never appears.
Affected:
Ubuntu 15.04 (vivid)
Ubuntu 15.10 (wily)
Works fine in:
Ubuntu 14.10 (utop
