fsck.ext3: Unable to resolve

[Matt Henley]

I upgraded my Dapper distribution last night (12 Oct 2006) using the gksu "update-manager -c -d" . Now, whenever I boot it reports an error during startup regarding fsck. I hit control-D and it boots fine. The fsck log looks like this:

Log of fsck -C -R -A -a
Fri Oct 13 18:47:06 2006

fsck 1.39 (29-May-2006)
/dev/md0: clean, 68276/14663680 files, 17166234/29304544 blocks
/dev/hda1: clean, 60/52208 files, 74622/104391 blocks
fsck.ext3: Unable to resolve 'UUID=f603d3ac-1123-0065-3c66-8d99ecf9d8f2'
fsck died with exit status 8

I do not know what UUID's are doing in the fstab so I dont know how to fix. The fstab looks like:
# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
# /dev/hda3 -- converted during upgrade to edgy
UUID=822ab516-e8d7-449b-9ef1-11e5532f05d4 / ext3 defaults,errors=remount-ro 0 1
/dev/md0 /home ext3 defaults 0 1
# /dev/hda1 -- converted during upgrade to edgy
UUID=a849c0c8-82d9-41da-8882-d2ad133f7ab6 /boot ext3 defaults 0 2
# /dev/hda4 -- converted during upgrade to edgy
UUID=f603d3ac-1123-0065-3c66-8d99ecf9d8f2 /media/hda4 ext3 defaults 0 2
# /dev/sda1 -- converted during upgrade to edgy
UUID=f603d3ac-1123-0065-3c66-8d99ecf9d8f2 /media/sda1 ext3 defaults 0 2
# /dev/hda2 -- converted during upgrade to edgy
UUID=469eb926-0a1d-4915-b4ba-28904b959ec4 none swap sw 0 0
/dev/hdc /media/cdrom0 udf,iso9660 user,noauto 0 0

It seems the installer is doing something wrong with my fstab.

[Bernhard Kappler (bkappler)]

Hi,

Im facing the same problem with the release candidate.

“Fsck –a” is working fine for all with the UUIDs for all my partitions except for /dev/hda1 (/boot):

fsck.ext3: Unable to resolve 'UUID=7389bc92-c7d5-4e03-a3a0-fd85456210e6'

vol_id is working fine for this volume:

# vol_id /dev/hda1
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=7389bc92-c7d5-4e03-a3a0-fd85456210e6
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

But “findfs” fails:

# findfs UUID=7389bc92-c7d5-4e03-a3a0-fd85456210e6
findfs: Unable to resolve 'UUID=7389bc92-c7d5-4e03-a3a0-fd85456210e6'

For my other volumes everything is working as expected:

# vol_id /dev/hda3
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=12d976bc-a5d1-4b94-b08b-fcfac62901c3
ID_FS_LABEL=
ID_FS_LABEL_SAFE=

# findfs UUID=12d976bc-a5d1-4b94-b08b-fcfac62901c3
/dev/hda3

Best Regards
 Bernhard

[Bart Kroon (bart-kroon)]

My system worked perfectly with Edgy and new Feisty up to the updates recently including kernel 2.6.19 which required me to reboot. Edgy changed my /etc/fstab to mount by UUID and now none of my non-root partitions are found anymore.

Also I now noticed that fdisk -l reports /dev/sda, /dev/sdb, etc. instead of /dev/hda, /dev/hdb. Maybe there is a relation?

I can get more information if helpful because my system is still in this silly state waiting for help :)

[Bart Kroon (bart-kroon)]

In addition to my comment:

I pressed Ctrl+D and everything gets mounted and everything is fine. I checked the UUID's with vol_id and they match with /etc/fstab.

[Eric Christiansen (ericmartinchristiansen+sites)]

I have the same problem.

I'm running Ubuntu Edgy, clean install, completely updated as of this post.

My disk: 160 GB
     158GB ext3 /dev/sda6
     2GB swap /dev/sda5
     (both partitions are logical)

[metres (metres)]

I had the same error on kubuntu,

I used blkid to find the good UUID which differ from the one returned by vol_id which return the UUID used by ubuntu.

I replace the good UUID in my fstab but now I have to create a symlink every time I boot...

[Sense Egbert Hofstede (sense)]

I got also the message that fsck could not resolve the UID, but it turned out that that were the UID's of a harddisk I removed.

[Bart Kroon (bart-kroon)]

So for some months now, every time there is a kernel update and I have to reboot my system, fsck failes because my fstab lists UUID's and I have to press Ctrl+D to continue booting. If I can contribute in any way to help solve this bug, tell me what to do.

Here is my fstab:

# /etc/fstab: static file system information.
#
# <file system> <mount point> <type> <options> <dump> <pass>
proc /proc proc defaults 0 0
UUID=a21d589c-4949-49fe-a776-fa8f969a1888 / ext3 errors=remount-ro 0 1
UUID=812128ce-bfe0-4906-abef-678792815a76 /home/bart reiserfs defaults 0 2
UUID=8A2881E22881CD9F /home/bart/Windows ntfs-3g nls=utf8,umask=007,gid=46 0 2
UUID=5149e1dc-4738-4be1-aa97-1fdfe959b7f7 /home/bart/Extra reiserfs defaults 0 3
UUID=839308e2-6223-4970-8c73-42ce04625701 /home/bart/WWW reiserfs defaults 0 3
UUID=94d50302-4242-47b2-b980-32bf03694d57 /home/bart/Downloads reiserfs defaults 0 3
UUID=d2e41a24-87ca-4f6f-a065-a2a52813928e /home/bart/Music reiserfs defaults 0 3
UUID=ac2be621-cfc8-4ea5-8d57-4cf5671f97fa /home/bart/Video reiserfs defaults 0 3
UUID=eba560c1-9494-4f84-849a-2bf32ac17191 none swap sw 0 0
/dev/hdd /media/cdrom0 udf,iso9660 user,noauto 0 0

Here the list of UUID's while mounted:

$ for i in /dev/evms/*; do echo -n "$i : "; sudo vol_id -u $i; done
/dev/evms/dm : /dev/evms/dm: unknown volume type
/dev/evms/hda1 : 8A2881E22881CD9F
/dev/evms/hda5 : 5149e1dc-4738-4be1-aa97-1fdfe959b7f7
/dev/evms/hda6 : 812128ce-bfe0-4906-abef-678792815a76
/dev/evms/hda7 : 839308e2-6223-4970-8c73-42ce04625701
/dev/evms/hdb1 : a21d589c-4949-49fe-a776-fa8f969a1888
/dev/evms/hdb2 : eba560c1-9494-4f84-849a-2bf32ac17191
/dev/evms/hdb3 : 94d50302-4242-47b2-b980-32bf03694d57
/dev/evms/hdb5 : d2e41a24-87ca-4f6f-a065-a2a52813928e
/dev/evms/hdc1 : ac2be621-cfc8-4ea5-8d57-4cf5671f97fa

Some system info:

ASUS A7V333 mainboard with VIA chipset (http://www.hothardware.com/viewarticle.aspx?articleid=58&catid=3)
AMD Athlon XP 2500+
2x512 MB DDR 333
Three PATA harddisks (120, 120 and 200 GB)

I read somewhere that including pata_via in /etc/initramfs-tools/modules should work so I did and kept this for some kernel updates before removing it again. It did not help nor harm.

[Bart Kroon (bart-kroon)]

Forgot to mention I upgraded to Feisty Fawn in the meantime :)

[Paul Perkins (thirdspace)]

I recently updated a Dapper installation to Edgy using the recommended "gksu update-manager -c" procedure. On booting into Edgy, it failed to the "enter root password to repair" prompt, obviously a bad message for Ubuntu to show a newbie since root isn't supposed to have a password. Above that the error message was that fsck.ext3 could not resolve a UUID. This computer had 3 old IDE fixed disks as /dev/hd{a,b,d} and a CD-RW drive as /dev/hdc. I entered the root password (I'm old fashioned in some ways) and saw in /etc/fstab that the unresolved UUID was supposed to refer to /dev/hdd1. I also saw that there was an /etc/fstab.pre-uuid file that looked like it would work, so I renamed /etc/fstab to fstab.bad, copied fstab.pre-uuid to fstab, and rebooted, successfully this time.

It looks like this is only one of several ways that Ubuntu can become confused when it tries to use UUIDs in the fstab. Maybe a little more testing and debugging should have been done before dropping this change on unsuspecting users.

[Daniel Hahler (blueyed)]

Setting to confirmed. I have the same issue on my server, where it is really annoying - a server hanging during boot!

[Antonio (acardh)]

OK, this is what happened to me. I installed Ubuntu 7.04 with a dual boot with Windows XP and I had an extra partition (sda8) to install another linux distribution on it. Ubuntu had no complaints at the beginning but after I did an extra partition in sda8 to install the other linux, Ubuntu start complaining at the boot saying:
fsck.ext3: Unable to resolve 'UUID= etc, etc "
And with just a Ctrl-D my system resumes the boot without any other problem.

To solve this issue I just edited /etc/fstab and commented the line related to sda8.

[Eric Christiansen (ericmartinchristiansen+sites)]

I was able to resolve this problem.

/etc/fstab still had entries that corresponded to old partitions that I had deleted. To fix this, I simply commented them out.

If you're dealing with a UUID mismatch, use "sudo vol_id <the partition>" to figure out the correct UUID for each partition, so that you can overwrite the incorrect UUIDs in fstab.

[lokesh (lokeshwer)]

Eric Christiansen fix worked. Thanks
I have edgy. I planned to give fiesty a try. I installed it seerately in a new partition. But i got fsck errors like ppl mentioned in thread. And it was incorrect UUID tht fsck was not able to resolve.

[Theodore Ts'o (tytso)]

I'm pretty sure this bug is related to bug #110138, where the partition is getting mis-identified as an NTFS parition.

Due to a bug in e2fsprogs previous to version 1.30, the initial bootsector (which is where the NTFS signature is stored) wasn't getting erased. This could cause blkid to misidentify the filesystem as NTFS. This would only happen on old partitions which had previously contained NTFS, and which were formated as ext2/ext3 using an old mke2fs binary.

A quick workaround to this problem is: dd if=/dev/zero of=/dev/hdXX bs=1 count=512

I have a patch which makes blkid less likely to report a false positive; it has been attached to bug #110138.

Regards,

[Tim T. (tim-timmerman)]

Data point:

 I ran into a similar error on a recent feisty install. I checked the fstab for this UID, and found that it mapped to hdd1, which I'd just
 pulled from the system. (Old disk, failed during or right after the install.)

 After removing the mount point for hdd1 from /etc/fstab, along with the corresponding UID, the problem was solved.

Hope this helps some one.

[Theodore Ts'o (tytso)]

If you have a filesystem mentioned in /etc/fstab, and you remove it, then of course you will have this failure.

At this point, I believe that this bug was fixed in 1.40, for people who had problems with filesystems that were getting misidentified by NTFS. There may also be some users who are sufferring from the Feisty install code grabbing all filesystems and stuffing them in /etc/fstab, and then when people pull a removable disk or some such, the system won't boot.

so at this point I think the right thing to do is just to declare this a dup of #110138, and that it has been fixed in e2fsprogs 1.40 and in Gutsy.

[Thomas Bilgram (thomas-bilgram)]

Hi,
I had the same error message, and now I found the solution for my problem, hope it will help you.
I installed Ubuntu 9.04 and created 2 partitions, the first one encrypted and the second one unencrypted with ext3 in order to store and access large files. The encrypted partition was fine. The unencrypted partition was mountable and writable, but fsck said "fsck.ext3: Unable to resolve..."
vol_id /dev/sdaX for the second partition said:
ID_FS_USAGE=crypto
ID_FS_TYPE=crypto_LUKS
ID_FS_VERSION=2
ID_FS_UUID=fe7eeabf-89de-4afb-902c-b382c53edf0a
ID_FS_UUID_ENC=fe7eeabf-89de-4afb-902c-b382c53edf0a
ID_FS_LABEL=
ID_FS_LABEL_ENC=
I wondered why it says "crypto_LUKS", because I didn't encrypt it, and it even was mountable without a key input. I installed gparted and reformatted the partition as ext3. Then vol_id /dev/sdaX said:
ID_FS_USAGE=filesystem
ID_FS_TYPE=ext3
ID_FS_VERSION=1.0
ID_FS_UUID=342e48db-2575-4f98-939f-fea798e49140
ID_FS_UUID_ENC=342e48db-2575-4f98-939f-fea798e49140
ID_FS_LABEL=
ID_FS_LABEL_ENC=
Now I copied the new UUID and replaced the obsolete one in /etc/fstab -> solved!