Loading

×Sorry to interrupt
CSS Error

Refresh

Cookie Preference Center

General Information on cookies

When you visit our website, we use cookies to ensure that we give you the best experience. This information does not usually directly identify you, but it can give you a more personalized web experience. Because we respect your right to privacy, you can choose not to allow some types of cookies by clicking on the different category headings to find out more and change your settings. However, blocking some types of cookies may impact your experience on the site and the services we are able to offer. Further information can be found in our

Cookie Policy.

Strictly Necessary

Strictly Necessary

Always Active

Strictly Necessary

Strictly necessary cookies are always enabled since they are essential for our website to function. They enable core functionality such as security, network management, and website accessibility. You can set your browser to block or alert you about these cookies, but this may affect how the website functions. For more information please visit www.aboutcookies.org or www.allaboutcookies.org.

Cookie Details‎

Performance

Performance

Performance

Performance cookies are used to analyze the user experience to improve our website by collecting and reporting information on how you use it. They allow us to know which pages are the most and least popular, see how visitors move around the site, optimize our website and make it easier to navigate.

Cookie Details‎

Please confirm your settings by refreshing the page.

Functional

Functional

Functional

Functional cookies help us keep track of your past browsing choices so we can improve usability and customize your experience. These cookies enable the website to remember your preferred settings, language preferences, location and other customizable elements such as font or text size. If you do not allow these cookies, then some or all of these services may not function properly.

Cookie Details‎

Advertising

Advertising

Advertising

Advertising cookies are used to send you relevant advertising and promotional information. They may be set through our site by third parties to build a profile of your interests and show you relevant advertisements on other sites. These cookies do not directly store personal information, but their function is based on uniquely identifying your browser and internet device.

Cookie Details‎

Advertising Cookies

Consent Leg.Interest

Select All Vendors

Select All Vendors

Select All Hosts

Select All

Clear Filters

Information storage and access

Apply

Confirm My Choices Reject All Allow All

My Subscriptions

Loading

Knowledge Base

ESX 4.x host fails to boot after power operation with the error: fsck.ext3: Unable to resolve UUID (1017162)

Last Updated: 3/20/2024Categories: TroubleshootingTotal Views: 41657Language:
Chinese (Simplified)JapaneseSpanishEnglish

1 like this article

Subscribe to get an email
newsletter with new updates

1 people found this helpful Please provide article feedback:

Symptoms

After power-cycling or rebooting an ESX 4.x server, this error is produced during boot:

fsck.ext3: Unable to resolve 'UUID=34d192db-17eb-442e-9613-c5c24c6fa9fa'

And

*** An error occurred during the file system check.
*** Dropping you to a shell; the system will reboot
*** when you leave the shell.

After encountering this error, you are unable to boot into ESX or Troubleshooting mode.

The unresolvable EXT file systems or partitions most commonly later appear to have mount points such as /var, /opt and /tmp.

Resolution

This issue is resolved in vSphere 4.1 Update3.

For prior releases, this issue occurs when the boot-time file system check utility ( fsck) for EXT-3 file systems cannot resolve a file system (by UUID) defined in /etc/fstab.

Issues that can result in this may include:

The default roll-back option is left enabled when a subsequent upgrade is being performed.

The device not present during system boot.

The unresolvable EXT file systems appear to reside on disks/devices that are initialized later during system boot (e.g. the last LUN).

Note: If you are experiencing an outage with virtual machines down, consider resolving the situation in a timely manner through the re-installation of VMware ESX. Troubleshooting may take more time than a re-installation, which is in the order of approximately 20 minutes.

Otherwise refer to instructions below for submission of information to VMware Technical Support for technical analysis.

Further troubleshooting is available in the shell:

Confirm the UUIDs which were not resolvable, and remain so, by running fsck again without additional arguments. This information (or similar information) is displayed:

# fsck

fsck 1.39 (29-May-2006)
e2fsck 1.39 (29-May-2006)
esx-root: clean, 32953/641280 files, 414801/1281175 blocks
e2fsck 1.39 (29-May-2006)
/dev/sdt1: clean, 35/140832 files, 25323/281596 blocks
fsck.ext3: Unable to resolve 'UUID=34d192db-17eb-442e-9613-c5c24c6fa9fa'
e2fsck 1.39 (29-May-2006)
/dev/sdt6: clean, 31/250368 files, 27851/500220 blocks
e2fsck 1.39 (29-May-2006)
/dev/sdt7: clean, 22/250368 files, 16815/500220 blocks

Record the UUID or UUIDs which failed to resolve. You may take a screen shot of your System Management Interface, take a picture, or write the values down.

Confirm these same values in the /etc/fstab file.

# cat /etc/fstab

UUID=79815890-f11c-4907-80fe-d1cd6bf061f8 / ext3 defaults 1 1
UUID=45460133-027b-40b6-8b4d-e52aaf4c417f /boot ext3 defaults 1 2
None /dev/pts devpts defaults 0 0
/dev/cdrom /mnt/cdrom udf,iso9660 noauto,owner,kudzu,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner,kudzu 0 0
None /proc proc defaults 0 0
None /sys sysfs defaults 0 0
UUID= 34d192db-17eb-442e-9613-c5c24c6fa9fa /var/log ext3 defaults,errors=panic 1 2
UUID=e32ec5f4-d795-414a-8d73-a2bb3ea86342 swap swap defaults 0 0

Note: Highlighted in blue is the mount point for the respective unresolvable UUID, in red.

Verify what UUIDs the system is currently aware of by running the command:

# ls -l /dev/disk/by-uuid

total 0
lrwxrwxrwx 1 root root 10 Nov 9 14:36 45460133-027b-40b6-8b4d-e52aaf4c417f -> ../../sdm1
lrwxrwxrwx 1 root root 10 Nov 9 14:36 e32ec5f4-d795-414a-8d73-a2bb3ea86342 -> ../../sdr1
lrwxrwxrwx 1 root root 10 Nov 9 14:36 34d192db-17eb-442e-9613-c5c24c6fa9fa -> ../../sdr2
lrwxrwxrwx 1 root root 10 Nov 9 14:36 79815890-f11c-4907-80fe-d1cd6bf061f8 -> ../../sdr5

Notes:

This output reveals the UUID-to-partition relationship for all discovered EXT partitions in the system. Affected mount points or content can be associated using the previous step.

It is possible in some environments that none of the known partitions reported by listing /dev/disk/by-uuid match the unresolved UUID. This is correctable; for additional instructions, proceed to the following sections and correct the content of the /etc/fstab file.

Sometimes " ls -l /dev/disk/by-uuid" does not list the instance of the UUID available in /etc/fstab and you may find one device which has a UUID but no mount/label in /etc/fstab (e.g. /dev/sdb#). It may be the /tmp partition which is not resolved by ESXi host. After editing the /etc/fstab file to correctly reflecting the mount point for /tmp partition to the actual device instance ( /dev/sdb#), you can list that partition correctly with proper UUID.

(Note: Here in the example we referred /dev/sdb# but you need to verify the output of /etc/fstab to see the actual device instance with the number ( #) at the end.)

Workarounds
There are 2 recommended workarounds. Both workarounds involve the modification of the /etc/fstab file. You can either:

Generate a new UUID for the affected file system(s) and update /etc/fstab to match the new value(s).

Update /etc/fstab to incorporate the correct UUID from the file system.

Applying a new UUID
Apply a new UUID to the EXT-3 file systems which fail to resolve and update the /etc/fstab file.

Run tune2fs against each Linux partition on the suspected disk device. For example:

# tune2fs -l /dev/sdr2 | grep UUID
Filesystem UUID: 34d192db-17eb-442e-9613-c5c24c6fa9fa

# tune2fs -U random /dev/sdr2
tune2fs 1.39 (29-May-2006)

# tune2fs -l /dev/sdr2 | grep UUID
Filesystem UUID: 25a18c70-ffcb-4b15-9d2d-1cfab1754d86

Update /etc/fstab with the updated UUID. From earlier steps, /dev/sdr2 partition was determined to be the /var/log mount point:

Remount the root partition in read-write mode:

# mount / -o remount,rw

Open the /etc/fstab file in a text editor. For more information, see Editing configuration files in VMware ESXi and ESX (1017022).

Search for, and change, the original UUID to the newly-generated UUID from earlier steps, above.

Save the file and remount the root partition in read-only mode:

# mount / -o remount,ro

Reboot the server:

# shutdown -r now

Applying a UUID to /etc/fstab

Remount the filesystem to a read/write state with the command:

# mount / -o remount,rw

Open the /etc/fstab file in a text editor. For more information, see Editing configuration files in VMware ESXi and ESX (1017022).

Comment out the line referring to the older ESX installation by putting a hash symbol (#) before it.

Save the file and exit the editor.

Reboot the ESX host.

To prevent this issue from occurring again, after the system is booted, follow the steps in Clean Up the ESX Bootloader Menu After Upgrade in the vSphere Upgrade Guide.

Removing residual roll-back installation UUIDs in /etc/fstab

Perform these steps to remove past installations from the /etc/fstab file. This may be necessary if roll-back data is preventing the ESX host from starting successfully.

Log into the server using the root password.

Remount the root filesystem in read-write mode with the command:

# mount -o remount,rw /

Open the /etc/fstab file in a text editor. For more information, see Editing configuration files in VMware ESXi and ESX (1017022).

Comment out or remove the line referring to the previous ESX installation by inserting a hash symbol (#) at the beginning of the line.

Save the file and exit the editor.

Reboot the ESX host.

To prevent this issue from recurring, follow the steps in Clean Up the ESX Bootloader Menu After Upgrade in the vSphere Upgrade Guide after rebooting.

Related Information

To be alerted when this document is updated, click the Subscribe to Article link in the Actions box

To list partitions in the system, run:

# fdisk -l | less

Note: All known partitions are shown. In many cases where this issue has occurred, the resolved and unresolved partitions reside on the same block or disk device. Specifically, they most commonly reside on the same device as the ESX Console OS or the ESX host's system disk. For example:

System Disk

Disk /dev/sdm: 64.4 GB, 64424509440 bytes
64 heads, 32 sectors/track, 61440 cylinders
Units = cylinders of 2048 * 512 = 1048576 bytes

Device Boot Start End Blocks Id System
/dev/sdm1 * 1 1100 1126384 83 Linux
/dev/sdm2 1101 1210 112640 fc VMware VMKCORE
/dev/sdm3 1211 61440 61675520 5 Extended
/dev/sdm5 1211 40960 40703984 fb VMware VMFS

Console OS Disk
Disk /dev/sdr: 7973 MB, 7973371904 bytes
255 heads, 63 sectors/track, 969 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdr1 1 76 610438+ 82 Linux swap / Solaris
/dev/sdr2 77 331 2048287+ 83 Linux
/dev/sdr3 332 969 5124735 5 Extended
/dev/sdr5 332 969 5124703+ 83 Linux

Notes:

In these steps, the chosen disks/partitions should typically be ones known to be utilized by the ESX host operating system; RDMs used by Linux virtual machines can be skipped.

ESX host system disks typically contain type FB (VMFS) or FC (VMKCore) partitions.

ESX Console OS disks usually appear to be relatively small, to the order of 8 GB or slightly larger.

Press q to quit the less utility when you are done reviewing partitioning information.

Enabling serial-line logging for an ESXi/ESXi host
Editing configuration files in VMware ESXi and ESX
El host ESX 4.x falla su proceso de inicio con el error: fsck.ext3: Unable to resolve UUID
How to file a Support Request in Customer Connect
電源操作後、ESX 4.x ホストを次のエラーで起動できない： fsck.ext3: Unable to resolve UUID
ESX 4.x 主机在电源操作后无法引导，并显示以下错误：fsck.ext3: 无法解析 UUID

Detectable by VMware SkylineTM

Actions

Copy

link to clipboard
copied!

Print

Language:
Chinese (Simplified)JapaneseSpanishEnglish

Attachments

Additional Resources

KB
•
End Of General Availability of the Free vSphere Hypervisor (ESXi 7.x and 8.x) (2107518)

KB
•
在 ESXi 5.x 主机上配置 HA 失败，并出现错误“无法安装 vCenter 代理服务。未知安装程序错误” (2032101)

KB
•
安装 VMware vSphere Web Client 5.5 失败并显示错误：无法连接到 VMware vCenter Server Single Sign-On (2062921)

Results 1-3 of 3

Ask The Community

Get answers quickly from VMware experts in the community

Post Subject

CONTINUE IN COMMUNITIES

Related Products:

VMware ESX Server

Related Versions:

VMware ESX 4.1.x

VMware ESX 4.0.x

Take Our Survey

Support Assistant