You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Linux anystation 5.11.15-arch1pf8-1 #2 SMP PREEMPT Thu, 01 Jan 1970 00:00:00 +0000 x86_64 GNU/Linux
CPU architecture issue was seen on
x86_64
Expected behaviour you didn't see
After btrfs replace, system should operate normally.
Unexpected behaviour you saw
After completion of btrfs replace, systemd attempted to unmount the filesystem in question from all mountpoints (filesystem in question is the root filesystem, but with several bind-mounts and subvolume mounts to other locations) and stop all dependent units:
Additionally, the .device unit corresponding to the new volume (replace target) got stuck in the activating (tentative) state.
Steps to reproduce the problem
Set up an Arch installation with btrfs root on LUKS on GPT (not sure if either of this is relevant, but including for completeness)
Create additional subvolumes, add them to /etc/fstab to be mounted at separate locations and mount them
Optionally, create and start services dependent on these mountpoints (Requires=, RequiresMountsFor=) for better demonstration purposes
Add another disk or partition into the system, create and open a LUKS container on it
Initiate a btrfs replace to the new LUKS volume and wait for it to finish
Additional program output to the terminal or log subsystem illustrating the issue
Probably related to #14674, #14454.
systemd version the issue has been seen with
Used distribution
Linux kernel version used (
uname -a
)CPU architecture issue was seen on
Expected behaviour you didn't see
After
btrfs replace
, system should operate normally.Unexpected behaviour you saw
After completion of
btrfs replace
, systemd attempted to unmount the filesystem in question from all mountpoints (filesystem in question is the root filesystem, but with several bind-mounts and subvolume mounts to other locations) and stop all dependent units:Additionally, the
.device
unit corresponding to the new volume (replace target) got stuck in theactivating (tentative)
state.Steps to reproduce the problem
/etc/fstab
to be mounted at separate locations and mount themRequires=
,RequiresMountsFor=
) for better demonstration purposesbtrfs replace
to the new LUKS volume and wait for it to finishAdditional program output to the terminal or log subsystem illustrating the issue
System log:
Bogus device unit states after replace operationL
Udev state dump of the replace target:
The text was updated successfully, but these errors were encountered: