2

I have been using various flavors of Linux (ubuntu, debian, and Kali) under VMware Workstation, running Windows 10 as the host, and have been experiencing the file systems of the guest OS's going "Read only" intermittently - I think it happened 2 times yesterday and once today.

At first I thought it was just a bad install as it was happening under Kali only to start - however then it began affecting Ubuntu and Debian as well.

I have run SMART tests on the Windows side and they do not reveal any issues.

Below is what I see in dmesg after the most recent revert to read only:

[    4.684740] random: crng init done
[    5.357246] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    5.361262] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[    5.370915] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[    5.371618] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[    7.391713] e1000: eth0 NIC Link is Down
[   15.455356] e1000: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: None
[  317.358720] EXT4-fs warning (device sda1): ext4_dirent_csum_verify:352: inode #155789: comm updatedb.mlocat: No space for directory leaf checksum. Please run e2fsck -D.
[  317.358722] EXT4-fs error (device sda1): htree_dirblock_to_tree:962: inode #155789: comm updatedb.mlocat: Directory block failed checksum
[  317.358944] Aborting journal on device sda1-8.
[  317.359230] EXT4-fs (sda1): Remounting filesystem read-only
[  317.361153] EXT4-fs warning (device sda1): ext4_dirent_csum_verify:352: inode #155843: comm updatedb.mlocat: No space for directory leaf checksum. Please run e2fsck -D.
[  317.361154] EXT4-fs error (device sda1): htree_dirblock_to_tree:962: inode #155843: comm updatedb.mlocat: Directory block failed checksum
[  317.373714] EXT4-fs warning (device sda1): ext4_dirent_csum_verify:352: inode #154974: comm updatedb.mlocat: No space for directory leaf checksum. Please run e2fsck -D.
[  317.373716] EXT4-fs error (device sda1): htree_dirblock_to_tree:962: inode #154974: comm updatedb.mlocat: Directory block failed checksum

To fix this I have been rebooting and running "fsck /dev/sda1 -y" and it seems to be fine after that, for a while at least.

What might be causing this behavior, or is there anything more I can do to diagnose it given that this is in a VM and not a SMART capable drive?

Also note that I have not experienced any issues under windows that would indicate a failing SSD.

Improve this question
2
  • Updated info from some comments below: > The VMs are both on the main Windows 10 Pro (x64) partition, which is NTFS format > The VMs themselves are both x64 > I experienced this "read only" condition twice yesterday, on two separate VM's
    – Nick
    Dec 6, 2017 at 18:36
  • I've had the very same problems for years under different VMWareWorkstation versions and hardware configurations. My guess is that VMWare's vhd-format or open-vm-tools/vmware-tools is buggy. I don't think it has anything to do with free space or wbadmin backup jobs, since I've seen this under such different conditions. It is independent of the hardware and it is not relevant where you store the vhd file (system hd or data hd). Because of the above post, I changed the vhd disk to a preallocated disk.
    – user265798
    Dec 14, 2017 at 5:23

1 Answer 1

Reset to default
1

As you are suspecting, the most probable case of a VM going read only would be a bad disk.

SMART is not the best metric in a consumer grade disk, and in fact there is supported evidence of several manufacturers lying at firmware level, and SMART saying always the disk is in a good health.

However, from the logs I suspect you selected thin provisioning for the Linux virtual disks, and you do not have more real disk free space/SSD space for the virtual disk/ virtual filesystem to grow - thus the VM kernel handling it as "inconsistent" - as thin provisioning only grows the virtual disks as needed on the fly.

Remember that in several OSes, a portion of the disk if often reserved for housekeeping, if you are low in free space on the host VM.

If that it is not the case, I would handle that disk as untrustworthy, and would start thinking about a replacement. Furthermore, remember than SSD disks usually fail completely without much warnings compared to mechanical disks.

Improve this answer
5
  • Please add to the question how much free space to you have in the host machine in the drive/file system hosting the VMs
    – Rui F Ribeiro
    Dec 5, 2017 at 15:44
  • Hmmm - I am indeed "low-ish" on free space, but not to a critical level from what I would guess. Current free space on host disk is 104/754 GB. Is that low enough to be of concern? You are correct, however, that the disk is thin-provisioned.
    – Nick
    Dec 5, 2017 at 19:02
  • It does not seem so low indeed. Are you absolutely sure the VMs are not in another partition, or that you have some other kind of limits? What type of filesystem are you using in the host?
    – Rui F Ribeiro
    Dec 5, 2017 at 23:26
  • @Nick (please add to the question how big are those partitions and if the VM is 32 or 64 bits)
    – Rui F Ribeiro
    Dec 6, 2017 at 12:49
  • It's all on the main WIndows 10 NTFS partition. There are other partitions on the disk, but they are used for dual-booting linux. The VM's are both 64 bits.
    – Nick
    Dec 6, 2017 at 18:35

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .