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

Incorrect Options listed in /etc/fstab for Shared Folder Mount entry for vmhgfs-fuse causes Debian to crash on boot #710

Open
Shawn1357 opened this issue Feb 6, 2024 · 4 comments
Labels

Comments

@Shawn1357
Copy link

Shawn1357 commented Feb 6, 2024

Describe the bug

Windows 10 Host
VMWare Workstation Pro 16.1.2 build-17966106
Debian 12 Guest with Gnome Desktop (with inactive root account)
Open VM Tools: 2.12.2.0-1+deb12u2 amd64

Followed instructions in:

Reproduction steps

  1. Create a directory on the host to be shared with a virtual machine such as D:\TEMP\Debian-Test

  2. Populate that host directory with at least one file.

  3. Create a vanilla VMWare guest installation of Debian 12. (Likely the problem can be replicated in any existing Debian guest - or even other Linux flavors)

  4. Create a mount point directory in the virtual machine (such as /mnt/hgfs/debian-tst)

  5. Enable and create a Shared Folder in the Virtual Machine Settings:
    For example:
    Host Dir: D:\TEMP\Debian-Test, Name: debian-test, Enabled

  6. Create a valid /etc/fstab entry such as:
    .host:/debian-test /mnt/hgfs/debian-tst fuse.vmhgfs-fuse defaults,allow-other 0 0

  7. Reboot machine and validate mount point works.

  8. Take a snapshot of the virtual machine so you can recover from bricking it in the next step.

  9. Modify the fstab entry to contain an invalid option such as adding "ttl=5" to the options:
    .host:/debian-test /mnt/hgfs/debian-tst fuse.vmhgfs-fuse defaults,ttl=5,allow-other 0 0

  10. Reboot and virtual machine crashes on boot.
    ...

Expected behavior

At the very minimum, the boot process should be able to continue, perhaps in an emergency mode, to a point where a shell is possible. Preferably, the boot should continue with out that specific fstab entry being mounted and appropriate errors logged somewhere.

Additional context

I have not tried this process with the 'root' account being active.

I am unable to review system logs because the system does not allow me to get to a shell to examine them.

Screen Boot Log indicating crash - this crash effectively bricks the guest machine as far as I can tell:
image

Pressing Enter results in a seemingly endless cycle of attempting to launch a console but 'root' is not active.

@Shawn1357 Shawn1357 added the bug label Feb 6, 2024
@Shawn1357 Shawn1357 changed the title Incorrect Options listed in /etc/fstab for Shared Folder Mount entry causes Debian to crash on boot Incorrect Options listed in /etc/fstab for Shared Folder Mount entry for vmhgfs-fuse causes Debian to crash on boot Feb 6, 2024
@Shawn1357
Copy link
Author

Shawn1357 commented Feb 6, 2024

If instead of rebooting in Step 10, I issue the command 'mount -a':
`mount -a

fuse: unknown option(s): '-o ttl=5'
mount: (hint) your fstab has been modified, but systemd still uses
the old version; use 'systemctl daemon-reload' to reload.

`

This seems a clean reaction to the problem. However, a reboot at this point exhibits the same boot crash.

@vmwkruti1111
Copy link
Contributor

Hi Shawn,
Incase your root account is locked (or inactive), you can try passing ",nofail" to the fstab entry for the shared folder to continue boot process even if drive fails to mount due to unknown option.

.host:/debian-test /mnt/hgfs/debian-tst fuse.vmhgfs-fuse defaults,ttl=5,allow-other,nofail 0 0

Thanks

@lousybrit
Copy link

We will update the mentioned https://kb.vmware.com/s/article/60262 article.
Thanks!

@Shawn1357
Copy link
Author

Hi Shawn, Incase your root account is locked (or inactive), you can try passing ",nofail" to the fstab entry for the shared folder to continue boot process even if drive fails to mount due to unknown option.

Thanks for the work-around and it indeed works.

However, in my case the work-around is too late - root is not enabled. The machine is effectively bricked because it will not boot beyond Press Enter to Continue prompt during the boot process (because the root account is not enabled). I suppose it might be possible to boot from a Live Distribution ISO and recover that way but I would argue that the effect of this problem is too severe: entering "allow-other" rather than the correct "allow_other" option effectively renders the virtual machine unusable.

If "nofail" is going to be the suggested work-around (and it does exhibit, in my head at least, an acceptable response), shouldn't "nofail" then be the default behavior unless otherwise stated in the list of options?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants