Skip to content
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

[240] Some mount units are reported as failed but they are succesfull #11362

Closed
Maryse47 opened this issue Jan 8, 2019 · 7 comments · Fixed by #11364
Closed

[240] Some mount units are reported as failed but they are succesfull #11362

Maryse47 opened this issue Jan 8, 2019 · 7 comments · Fixed by #11364
Labels
bug 🐛 Programming errors, that need preferential fixing pid1

Comments

@Maryse47
Copy link

Maryse47 commented Jan 8, 2019

systemd version the issue has been seen with

240

Used distribution

Arch Linux

Expected behavior you didn't see

All .mount units are reported as successful .

Unexpected behavior you saw

Some .mount units are reported as failed even as they are mounted just fine.

Steps to reproduce the problem

# /etc/fstab
/                              /                          ext4     defaults,noatime,errors=remount-ro,journal_checksum          0   1
UUID=xxx                       /boot/efi                  vfat     defaults,noatime,nosuid,noexec,nodev,fmask=0077,dmask=0077   0   2
/boot                          /boot                      none     bind,nosuid,nodev,noexec			                            0   0
/home                          /home                      none     bind,nosuid,nodev,noexec                                     0   0
/var                           /var                       none     bind,nosuid,nodev,noexec			                            0   0
/home/user/.cache              /home/user/.cache          tmpfs    nosuid,nodev,noexec,mode=0700,uid=user,gid=users             0   0
/tmp                           /var/tmp                   none     bind,nosuid,nodev,noexec	                                    0   0
$ journalctl -b -1 -u var-tmp.mount
systemd[1]: Mounting /var/tmp...
systemd[1]: var-tmp.mount: Mount process finished, but there is no mount.
systemd[1]: var-tmp.mount: Failed with result 'protocol'.
systemd[1]: Failed to mount /var/tmp.
systemd[1]: Mounting /var/tmp...
systemd[1]: var-tmp.mount: Mount process finished, but there is no mount.
systemd[1]: var-tmp.mount: Failed with result 'protocol'.
systemd[1]: Failed to mount /var/tmp.
$ journalctl -b -1 -u home-user-.cache.mount
systemd[1]: home-user-.cache.mount: Directory /home/user/.cache to mount over is not empty, mounting anyway.
systemd[1]: Mounting /home/user/.cache...
systemd[1]: home-user-.cache.mount: Mount process finished, but there is no mount.
systemd[1]: home-user-.cache.mount: Failed with result 'protocol'.
systemd[1]: Failed to mount /home/user/.cache.
systemd[1]: Mounting /home/user/.cache...
systemd[1]: home-user-.cache.mount: Mount process finished, but there is no mount.
systemd[1]: home-user-.cache.mount: Failed with result 'protocol'.
systemd[1]: Failed to mount /home/user/.cache.
$ journalctl -b -1 -u boot-efi.mount
systemd[1]: boot-efi.mount: Directory /boot/efi to mount over is not empty, mounting anyway.
systemd[1]: Mounting /boot/efi...
systemd[1]: boot-efi.mount: Mount process finished, but there is no mount.
systemd[1]: boot-efi.mount: Failed with result 'protocol'.
systemd[1]: Failed to mount /boot/efi.
systemd[1]: boot-efi.mount: Directory /boot/efi to mount over is not empty, mounting anyway.
systemd[1]: Mounting /boot/efi...
mount[1028]: mount: /boot/efi: /dev/sda1 already mounted on /boot/efi.
systemd[1]: boot-efi.mount: Mount process exited, code=exited, status=32/n/a
systemd[1]: boot-efi.mount: Failed with result 'exit-code'.
systemd[1]: Failed to mount /boot/efi.

Booting system throws me into emergency console because of above failures but I checked that all above mounts are fine. I use bindmount-generator to handle binds.

The error message is similar to #10872 but I'm not sure if they're related as it didn't happen before 240.

@yuwata yuwata added the pid1 label Jan 8, 2019
yuwata added a commit to yuwata/systemd that referenced this issue Jan 8, 2019
…_MOUNTED flag from units

This fixes a bug introduced by ec88d1e.

Fixes systemd#11362.
@yuwata yuwata added has-pr ✨ bug 🐛 Programming errors, that need preferential fixing labels Jan 8, 2019
@yuwata
Copy link
Member

yuwata commented Jan 8, 2019

I've posted #11364. If possible, could you test the PR?

@Maryse47
Copy link
Author

Maryse47 commented Jan 8, 2019

@yuwata your patch fixes my issue, thank you very much!

keszybz pushed a commit that referenced this issue Jan 9, 2019
…_MOUNTED flag from units

This fixes a bug introduced by ec88d1e.

Fixes #11362.
@ssolidus
Copy link

This is still broken, all my Archlinux systems broke due to this. I tried compiling the latest commit from source 4e4bbc4.

The error I received on all my Archlinux boxes was:

‘Error: device UUID=<snip> not found. Skipping fsck
mount : /new_root : can’t found UUID’

Downgrading to 239 for now. Please fix it.

@yuwata
Copy link
Member

yuwata commented Jan 10, 2019

@ssolidus Your issue seems to be different from this, and is related to #11314.

wkennington pushed a commit to triton/systemd that referenced this issue Jan 20, 2019
…_MOUNTED flag from units

This fixes a bug introduced by ec88d1e.

Fixes systemd#11362.

(cherry picked from commit d253a45)
@cagnulein
Copy link

@Maryse47 did this happen all the times or randomly? i guess i have the same bug on the version 241 on debian 10 and it happens to me once every 100+ boot. so i guess i can fix it with the last version of systemd

@Maryse47
Copy link
Author

IIRC it happened o every boot. Also v241 should have the fix already so maybe you hit something slightly different.

@cagnulein
Copy link

@Maryse47 yes you were right: the patch was alredy applied to v241. Now i'm debugging it and i will open a new one when i will find something. Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug 🐛 Programming errors, that need preferential fixing pid1
4 participants