New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
On first boot systemd believes some successfully mounted block devices have been unplugged and unmounts them #26254
Comments
|
[Canned reply follows] This is the upstream bug and feature request tracker of systemd. Please use this only for issues in the two most current upstream systemd versions. See this link for the list of current releases. https://github.com/systemd/systemd/releases For support for older versions please contact your distribution instead. In order to keep frustration at a minimum the submission form tried to make this all very clear. |
|
talk to your distro! |
|
Sure, let me do that instead. Adding some logs for more info in case someone else comes across this issue that show the devices changing state between dead->plugged->dead->plugged. The final plugged state does not seem to kick off a remount. The kernel does not think this device has been unplugged per dmesg, device is accessible as well. |
|
We had similar issues, and we have modified the device enumeration logic recently to fix the issues. So, please try to reproduce the issue with an recent release or the current git HEAD. I hope the issue is already fixed. |
|
@yuwata will do. Is there a specific set of fixes I should be looking for ? |
|
I guess the related issues are #12953, #23208, and #23429. These issues are fixed by 75d7b59 (cherry-picked as c293996, in v250.9), cf1ac0c (cherry-picked as a96ef94, in v250.9), and 4fc69e8 (Not backported to v250-stable yet). I have not deeply checked your issue is actually the same as one of the above issues, but sounds similar. |
|
thanks, I will try a cherry pick of 4fc69e8 to systemd-250-12.el9_1 |
|
Yes. Please. The above list may not complete. If 4fc69e8 does not help you, then please try to find relative commits for src/core/device.c, or try to reproduce the issue with newer release or the current git HEAD. Thank you. (Or, of course, as @poettering said, please contact to your distro.) |
|
I'm doing both at the same time. On the distro side, tried launching systemd under strace and the delay introduced by strace does mitigate this to a large extent, pointing to some kinda of race condition. Still no clue as to why first boot would make a difference. I'll post back after testing with cherry picks as well as tip of tree both |
systemd version the issue has been seen with
250
Used distribution
Rhel 9/systemd-250-12.el9_1
Linux kernel version used
5.14.0-162.6.1.el9_1.x86_64
CPU architectures issue was seen on
x86_64
Component
systemd-udevd
Expected behaviour you didn't see
On first boot, systemd should successfully mount all devices specified in fstab
Unexpected behaviour you saw
On first boot systemd mounts all devices in fstab, then believes that some devices, consequently propagating the error to the mdraid devices on top, marking them offline and unmounts the corresponding mount points, eventually stopping local-fs.target. This also affects other devices (like systemd thinking the nic/terminal device are also unplugged)
Steps to reproduce the problem
Additional program output to the terminal or log subsystem illustrating the issue
The text was updated successfully, but these errors were encountered: