fsck Unable to resolve UUID

I am having the same problem since I updated to 2.6.20.-14.23. Two of my hard drives (sdc 1 and sdd1) have completely disappeared.
I have tried replacing the UUIDs in /etc/fstab with traditional names for the devices i.e. sdc sdd (apparently in feisty all hard disks are called sda, sdb etc. regardless if they are SATA, PATA or SCSI) but when I did this, I got a "no such device" error on boot.

Here is my fsck log.

Log of fsck -C -R -A -a
Fri Apr 13 15:53:17 2007

fsck 1.40-WIP (14-Nov-2006)
/dev/sda3: clean, 1523/661248 files, 593505/1317330 blocks
/dev/sdb1: clean, 306/9781248 files, 3950372/19537040 blocks
/dev/sda4: clean, 956/8650752 files, 15390772/17279915 blocks
fsck.ext2: Unable to resolve 'UUID=f7ff6873-ba10-4780-9b94-ddb19f788ebc'

fsck.ext2: Unable to resolve 'UUID=516c2d55-7f06-4224-bcc4-1f673030ab00'

fsck died with exit status 8

Fri Apr 13 15:53:17 2007
----------------

Thanks for taking the time to report this bug and helping to make Ubuntu better. One command that may be helpful in resolving this issue is 'vol_id' by running 'sudo vol_id /dev/sdaX' you can find out the current volume id of the partition and see if it differs from what is in '/etc/fstab'. Thanks in advance.

Found the cause of the fsck failures:

This is a quad boot system, hda1 Win98, hda2 Dapper, hdb1 Edgy, hdb3 Feisty.

When I re-installed hdb1 Edgy after a failed attempt at installing Xubuntu Feisty ( Feisty ext3 format fails, Edgy's works ), must be the UUID changes? /dev/hdb1 didn't.

Anyway, the /etc/fstab on Feisty still had the UUID from the previous installed Edgy. fstab must use this as an input and of course couldn't find it because it's not there any more, so in booting Feisty fsck fails. The /dev/hdb1 partition is still there but fsck doesn't use that.

Moreover, I had removed the 3rd hard drive to resurrect another system so I'd have more configurations to test new builds.

The Feisty /etc/fstab still had the UUID from the removed drive, so fsck couldn't find that one either.

So I commented out the left over entries in Feisty's /etc/fstab. Booted up fine, no fsck failures.

Do note the Dapper in hda2 didn't have fsck problems with the installs in the 2nd hard drive because the /dev/hdbx's didn't change.
Feisty is going to have a problem every time I install another build in a different partition, since it uses UUID's and not /dev's.

Therefore in a dual or multi boot system, when a new install is done on one of the partitions, the "ordinary desktop computer user" is going to have to know how to manually edit /etc/fstab in the other partitions in order to boot without fsck failures? Is this a Feisty Install Bug or a Feisty Feature?

Cheers, Jerry

I am experiencing this bug with Kubuntu i386 20070417.

Prior to starting an install test this system had sda1 = swap, sda2 = boot, sda4 = /home, sda5 = edgy, sda6 = feisty, fully up to date. All working just fine and /home happily shared between edgy and feisty. Decided to test manual partitioning by replacing edgy with todays Kubuntu desktop daily build on sda5. Started ubiquity from the desktop icon, chose manual partitioning. Set sda5 as the new '/' partition set the other mount points accordingly, checked the boxes for sda5, swap and boot to be reformatted and proceeded with the install. The install completes without any obvious errors.

The new feisty install on sda5 boots and runs just fine. /home is still intact on sda4 and all my settings seem to be installed. The pre-existing feisty install on sda6 now fails to boot with the error:
Log of fsck -C -R -A -a
Tue Apr 17 19:22:39 2007

fsck 1.40-WIP (14-Nov-2006)
/dev/sda4: clean, 8344/7031360 files, 4488072/14058883 blocks
fsck.ext3: Unable to resolve 'UUID=c46aa308-75ca-435e-a036-8452cc09f867'
fsck.ext3: Unable to resolve 'UUID=c0a3d2d5-f4fb-434f-855d-c76adf08357c'
fsck died with exit status 8

Tue Apr 17 19:22:39 2007
----------------
That's the entire contents of /var/log/fsck/checkfs. Then I get dropped to a command prompt. Typing reboot takes me to the graphical login screen for sda6. If I try to login I get a blank desktop with a grey dialog box reading 'Could not start kstartupconfig. check your installation. I will attach the fstabs for both installs and the logs from todays installation, just in case they are useful

For some reason I cannot upload /var/log/installer/syslog or partman for sda5. Launchpad insists they are empty files when they are clearly not.

Update. As mentioned previously, using vol_id to find the ids then editing fstab on sda6 to match the one on sda5 fixed the issue

Forgot to add earlier that when I get dropped to a command prompt it's actually a root shell, not sure if this makes it a security problem

I encountered the same problem after I'd removed an earlier version (Dapper I think). Jerry's suggestion (2007-04-17) solved the problem for me - thanks Jerry

I had the same problem. Brian Murray's suggestion fixed it. Thanx! It seems like this is a problem everyone will encounter if they format any of the partitions which are automaticaly mounted through fstab. I would think it very helpfull if fsck could be a little bit more verbose about it. Well well this is probably not the right place. Thanx again!

Hi!

I'm also experiencing this problem, I upgraded a 6.10 release and startup recognizes one of three partitions. In rescue console, I can manually mount /home and continue the startup process.

Checked UUID with volid and trying to update the UUID with a udev (?) command did not help me.

Will attach dmesg tonight.

lundatok you might want to take a look at https://help.ubuntu.com/community/UsingUUID .

The bug: Gutsy Tribe 5 Just hit this "fsck.ext3 unable to resolve UUID= 4a60babf.......
"fsck.ext3 unable to resolve UUID = 15251c65 ....
then boot stops.

This is a triple boot system.
Installed Gutsy Tribe 5 Ubuntu on sda1. Was Ubuntu Tribe 1.
Then Installed Gutsy Tribe 5 Kubuntu on sda5. Was Kubuntu Tribe 1.
Kubuntu's fstab shows sda5 UUID now e804340d... not 15251c65...
Then Installed Gutsy Tribe 5 Xubuntu on sda3. Was Xubuntu Tribe 2.
Xubuntu's fstab shows sda3 UUID now b66fd82.... not 4a60babf.....

Now, booting Ubuntu sda1, boot stops because the UUID's in Ubuntu's /etc/fstab do not match what Kubuntu and Xubuntu installs did to the UUID's.

The screen said to do Control D. That didn't work.
Just guessing I typed in:
exit
and boot continues.
My fix was to do sudo gedit /etc/fstab and comment out the offending UUID's.

Could it be that the programmer(s) that wrote the UUID code to keep changing the UUID's did not provide for installing more than one Ubuntu Linux on a system, and did not provide for installing later releases fixing up previous releases fstab when UUID was changed?

A year ago I didn't have this problem since fstab used hda1, hda3, hda5.

Thanks, Jerry Amos

I have just met this problem upon installing gutsy alongside my feisty install. As far as I understand it, the problem is caused by the installation process changing the UUID's of existing disk partitions, causing fsck to fail on the original system. Making any manual changes to the partition table without updating fstab also causes the boot sequence to drop into a maintenance shell. So in addition to the problem of the UUID changes, the fact that any inaccuracies in fstab halts the boot sequence is an issue in itself. There are many new users who would equate the absence of a X server with total system failure.

Unlinking from bug 110138, which should have been fixed for Gutsy. Gutsy has e2fsprogs 1.40.2-1, now.

jerrylamos, can you take a look at bug 110138 and see if you can get some hint from there, e.g. what does "blkid /dev/..." display for you (try all partitions)?

This is a three boot system. Booting Xubuntu, the middle partition, and the last one installed, gives this on blkid:
root@NetVistaXubuntu:~# blkid /dev/sda1
/dev/sda1: UUID="9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1" SEC_TYPE="ext2" TYPE="ext3"
root@NetVistaXubuntu:~# blkid /dev/sda3
/dev/sda3: UUID="b66f5d82-95a1-4efe-a410-55bc62e29a38" SEC_TYPE="ext2" TYPE="ext3"
root@NetVistaXubuntu:~# blkid /dev/sda5
/dev/sda5: UUID="e804340d-a020-4bf0-87cf-6683ed868417" SEC_TYPE="ext2" TYPE="ext3"
Let me attach fstab as well
Let me boot up another partition to see what it gets.
Jerry

Here's the blkid's from the first partition, the Tribe 5 Ubuntu on sda1:
jerry@NetVistaGutsy:~$ blkid /dev/sda1
/dev/sda1: UUID="9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1" SEC_TYPE="ext2" TYPE="ext3"
jerry@NetVistaGutsy:~$ blkid /dev/sda3
/dev/sda3: UUID="b66f5d82-95a1-4efe-a410-55bc62e29a38" SEC_TYPE="ext2" TYPE="ext3"
jerry@NetVistaGutsy:~$ blkid /dev/sda5
/dev/sda5: UUID="e804340d-a020-4bf0-87cf-6683ed868417" SEC_TYPE="ext2" TYPE="ext3"
jerry@NetVistaGutsy:~$
Same as Xubuntu from sda3 saw, but not the same as in sda1's fstab attached. Some code changes the UUID's on install.
Jerry

Here's blkid's from Kubuntu Tribe 5 sda5
jerry@NetVistaKubuntu:~$ blkid /dev/sda1
/dev/sda1: UUID="9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1" SEC_TYPE="ext2" TYPE="ext3"
jerry@NetVistaKubuntu:~$ blkid /dev/sda3
/dev/sda3: UUID="b66f5d82-95a1-4efe-a410-55bc62e29a38" SEC_TYPE="ext2" TYPE="ext3"
jerry@NetVistaKubuntu:~$ blkid /dev/sda5
/dev/sda5: UUID="e804340d-a020-4bf0-87cf-6683ed868417" SEC_TYPE="ext2" TYPE="ext3"

Same as Ubuntu and Kubuntu saw, but not the same as in Kubuntu's fstab attached.

All three are Tribe 5 and installed on existing partitions using edit to change mount point to / and checking format in each case. All installed within a day or so, as I remember, presumably the date is on the partitions someplace.

Next I had planned on downloading the 20070906 as Tribe 6 (if they fit on a CD, 20070905 Ubuntu is pushing it at 699 mb); from what I read, it may not be officially called Tribe 6?
If the Ubuntu CD Live works, I'll try install; two bits the UUID's won't be the same as in this post.

If the Ubuntu install works, I'll download the Xubuntu and Kubuntu as time permits, and try the installs and marvel over the UUID's. Somebody tell me why they should ever change? What code decides what they are, anyway?

Based on Tribe 5, as soon as I install Kubuntu, the previously installed Ubuntu will have UUID problems again. We'll see.

Jerry

I'm installing Tribe 6 into partition 1 of a three boot system. Another partition has a running Tribe 5 in case Tribe 6 has a problem, and also has master copy of saved files.

UUID culprits: Install to a partition requires formatting that partition. Format changes the UUID, example Gutsy Tribe 6 install into sda1 of a three boot system:
Before install
/dev/sda1: UUID="9e6ffe2f-67d9-4c74-8d47-0f17044d1fb1" SEC_TYPE="ext2" TYPE="ext3"
After install
/dev/sda1: UUID="f23f7c06-5228-4b6e-8103-0adbc524f920" SEC_TYPE="ext2" TYPE="ext3"

Further muddying the water, Install puts the UUID's of all three partitions in fstab.

Now when I go back to boot the Tribe 5 in the other partition, boot fails because its fsck tries to do a file systems check on a UUID that no longer exists.

Now Install is smart enough to recognize another Ubuntu and wants to know if I want to model things from it, like bookmarks. Why isn't it smart enough to know the fstab in the other Ubuntu is going to be wrong now, since it points to the old UUID not the new UUID that Install just created?

Where in the Ubuntu instructions or in Install does it then say, "formatting this partition changes the UUID so you have to manually edit any other fstab's to match, otherwise the other Ubuntu stops when it is booted"?

By the way, multi boot is the way to go, when trying out new distro's or new builds so there is an old partition that works in case the new one doesn't. Example on this system Tribes 1 & 2 did, Tribe 4 wouldn't install and botched up the partition, but I had a partition with Tribe 2 to fall back on.

Jerry

This isn't an e2fsprogs bug. This is a bug in the Ubuntu installation scripts, in that:

(a) Ubuntu by default greedily tries to pull all partitions that are present in the system in /etc/fstab. (Maybe that isn't a good idea if you don't need a particular partition for a particular multiboot setup... i.e., if /dev/sda1 is your Tribe1 install, and /dev/sda2 is your Tribe2 install, and you are installing /dev/sda3 with Tribe 3, you DON'T want to put /dev/sda1 and /dev/sda2 in Tribe 3's /etc/fstab --- since you don't need multiple system's root filesystems mounted in Tribe3, and at some point you might overwrite your Tribe1 install in /dev/sda1 with Tribe 4, and at that point the /etc/fstab in your Tribe 3 install is totally bogus. On the other hand if /dev/sda4 is your /home directory, then obviously that should be in the Tribe 3 install.)

(b) Ubuntu insists on re-running mkswap on each new install, so if you have multiple boot systems all sharing the same swap partition, you don't want to break the other ones by re-running mkswap and blowing away the UUID used for the swap partition, because then you have to update all of the other systems' /etc/fstab files.

So yes, multi-boot is a great way to test multiple versions of distros --- I don't argue with that. But the problem is that fsck has no way of knowing whether or not /dev/sda1 was *really* important (i.e., it's an old Tribe1 install, it's OK if the filesystem with uuid FOO is no longer present), or whether it's some critical part of the filesystem where if it is no longer present, bringing up the system would result in a non-functional server, and so it's better to keep the system down and NOT let it to come up all the way. For example, if you have a critical e-commerce server, and you lose the filesystem containing the database, it's better to let your High Availability system let your backup servers take over, than to let a machine which is just going to answer http requests with "help I've fallen and I can't get up responses"; it's considered poor form. :-)

One thing I am willing to do is to add support for an fstab mount options field, "non-essential", which will cause fsck to simply skip a filesystem which can't be found. Then on desktop systems, system administrators or Desktop distros could by default mark filesystems as "non-essential" so that systems with missing filesystems can continue coming up. Note that this could be quite confusing even on Desktop system if your /home partition is missing, since users will then log in and not have any home directories, but that transfer the responsibility to whoever is setting up the /etc/fstab file --- it definitively makes it the Distro installer's fault.

Also, teaching the non-essential mount option may not be enough, since I suspect it will still cause mount -a to barf, and I believe that will cause the init scripts to bomb out, just later --- so if people really want this, they will probably also have to teach mount to understand the non-essential mount option. But, short of fixing the Ubuntu installer not do dumb things such as greadily including other root filesystems for other Linux installs in /etc/fstab by default...

Even in Sweden we find the same problem. I have used Ubuntu 7.04 and Xubuntu without problems. After that I installed Kubuntu. After some updates this problem starts. I cannot use Ubuntu 7.04 or Xubuntu if I will not write in terminal, init 3 or init5 or sometimes I use reboot, it does not matter. How do I make it work? On the same PC I run XP, Fedora6 and Mandriva without any problems. It is Kubuntu which has got the /GRUB/menu.lst

From a user's standpoint, Install should not ever automatically put UUID's in fstab that Ubuntu does not need to run. If I want to mount some file system I can do it, I don't need Ubuntu making it a boot requirement for some file system that is not integral to the Ubuntu being installed.

A good example is Places, Network. That finds out what systems are on the network without doing an obligatory fsck during boot and demanding that every system on the network that was there during install be there as a condition of boot. I think I can do all I need if Places Network or something similar found the other file systems that are not needed for boot.

Personally I have no problem with making a directory on /media and mounting /dev/sd whatever when I need to.

I do have a problem with boot stalling because fsck can't find a file system I don't need anyway.

As it is, every time I do a new install, I go back and reboot previously installed systems which then hang on boot because fsck can't check a UUID that format changed, I do exit or whatever to get by that, then sudo gedit /etc/fstab and comment out the obsoleted UUID's. I presume I could patch in the current UUID's but by this time I'm usually angry at having to do it at all.

This whole mess would be much less complicated if format didn't change the UUID's. What's the absolute requirement to change the UUID's anyway?

On this three boot system, there's one swap partition that is used by whichever Ubuntu I'm booting at the moment. Every install always reformats the one swap. Again. I don't recall the swap ever being a problem on boot.

Jerry

Take a look at /etc/fstab and see if the swap is being specified via a UUID or not. Then use "swapon -s" to see if you are actually using swap. Fortunately, if the swap partition isn't found, the system will stlil boot correctly. I agree that there's no point in changing the UUID for the swap partition --- actually the right thing to do is if there is a valid swap signature, the install procedure should simply skip the mkswap entirely.

For filesystems, the reason why we change the UUID when we reformat the partition is because it is fundamentally a different filesystem at one point. For example, suppose at one point the filesystem contains the critical data files for a MySQL e-commerce database. Now suppose a college intern is given the root password to the server and typo's a mke2fs command, and blows away the filesystem and uses it to restore some backup tapes. Fundamentally, that filesystem now contains something else. Hence, it should have a new UUID.

You've just guaranteed that dual boot Ubuntu's will fail to boot as is without user intervention.

With a new UUID, and Install putting every UUID's it can find in fstab, boot's automatic fsck is guaranteed to fail when booting the second image.

How do you propose to fix the problem you've created?

You've got choices like:

1. Install not putting the UUID's it doesn't need into fstab.

2. fstab not causing a boot failure when it can't find a UUID that's listed in fstab.

3. At least put a message on boot that says how the user is supposed to get by the failure, i.e. Ubuntu development doesn't want to fix the problem, dump it onto the user.

Thanks, Jerry

p.s this is a triple boot, just installed a Gutsy Tribe 6 now I'll boot the other two images to fix their fstab's.

Yep, I'd call it an installer bug, especially if Ubuntu is actively encouraging users to do install multiple systems.

Either the installer should be less "greedy" about installing filesystems into its fstab, or the installer should #1, ask the user if they are sure about reformatting a filesystem, and #2, ask the user whether they want to keep the UUID (in which case it should save the original UUID, and then restore it via tune2fs after running mke2fs), or #3, if the user answered no to #2, search all other filesystems if they have an fstab file referencing that UUID, and ask the user if they would like to remove or modify the line in the other filesystem's fstab file.

Note that no other distribution has had this problem, probably because they as aggressively using UUID's in /etc/fstab, and they aren't encouraging users to install alternative boot filesystems on their system for successive beta releases (and hence causing those filesystems to be reformatted). For example, most Debian testers just use "apt-get dist-upgrade", and so they won't run into this particular problem. I suspect that Ubuntu is also reaching out to more novice users, who don't automatically consider the need to modify /etc/fstab or to omit unneeded filesystems in /etc/fstab in the first place.

Comment preceding asked about the UUID on the swap partition. I use the same swap for all three Ubuntu's. Looking in /etc/fstab on each, the swap UUID came out the same for the three installs; I wasn't paying that close attention, but I'd conclude format didn't change the UUID for the swap partition. After some activity like downloading updates the swap does show "Used". Next install I'll look a bit more closely at the swap UUID.

Trying several Linux distro's and levels of Ubuntu, sometimes they don't work very well at all on one or another of our computers. Sure saves a lot of grief having a backup Ubuntu so the computer isn't dead altogether.

Now it can be messy, for example Tribe 4 blew up partway thru install but after botching Grub so I had to use CD Live to re-install Grub, but as soon as that was fixed my other partition was running fine.

How do we get Install to consider some means where the boot of the existing system doesn't always fail? The current Ubuntu Tribe 6 boot message after the fsck fail says a maintenance shell is being started, use Control-D to resume. That doesn't work. "Exit" does. Is this a new bug for launchpad?
Jerry

I am an inexperienced user. Yes, you can call me a n00bie, the label doesn't bother me. What does bother me is that this bug goes back to APRIL of 2007 without a resolution. To a programmer or developer who has experience with dealing with all sorts of strange bugs, this isn't a problem. Just hit <CTL>D and continue on. No sweat. Then bring up 2 terminals. In one, enter blkid. In the other, enter sudo gedit /etc/fstab and compare the UUID's in each, and revise as necessary. See? Problem solved.

Except that an inexperienced user wouldn't know that it's that simple to do. Nor would they feel comfortable with going in and manually editing a system file like that. Especially if the user is fresh out of that "other OS" that has taught him/her so well NOT to touch system files. To an inexperienced user, this is a SERIOUS bug.

I run a dual boot system. That gives me a valid partition for serious work, and a second partition to use as a playground. When a playground partition proves itself to be stable, and set up the way I want, then the purposing of the two partitions switches. I currently have 4 partitions: swap (of course), /home (ok, so I finally got smart), and 2 installation partitions. I am running Ubuntu 7.10 Final (Gutsy Gibbon) on both installation partitions. I recently had a problem with one partition, and did a clean install. The new installation came up with no problem. When I went back to the old partition, I encountered the, "fsck Unable to resulve UUID=. . ." problem. I then spent the better part of a day searching through the Ubuntu Community Forum for a solution. That, and asking some of the wizz-kids that frequent #ubuntu-arizona on irc.freenode.net. After finally gathering up the courage to change the /etc/fstab file (using the procedure in paragraph 1), and with fear and trembling, I rebooted into the old partition. I was relieved to see that the problem had gone away. I'd actually done something right.

Two days ago, I came across another problem that decided me it was time to reinstall on the "playground" partition (I'm hard on playgrounds). Yesterday, I booted back into the old partition (my stable source) and encountered the same problem of "fsck Unable to resolve UUID=. . .". So, today, I went looking for a bug report on the problem, and discovered the above long list of bugs, comments, and possible solutions. I respectfully request that this situation be addressed and corrected. It's gone on way too long.

Thank you,
Craig A. Eddy (tyche)
Member, Ubuntu-Arizona LoCo Team
Member, Ubuntu Marketing Team
https://launchpad.net/~tyche

Part of the reason why this problem hasn't been fixed is that it has been tagged incorrectly. It is not an e2fsprogs bug, but, as described above it is an Ubuntu installer issue. Unfortunately, I have not been able to find a way correctly tag this problem inside Launchpad as an installer issue, so the wrong people are paying attention to this bug.

To be fair to the installation people, this is somewhat of a hard problem, since different people use different partition schemes, and partitions that should be shared (such as /home) and partitions that shouldn't (like /var) aren't necessarily easily determinable by a program not possessing artificial intelligence. You can use heuristics, of course, but heuristics are often incorrect.

Theodore, thanks for the reply. And I think you have nailed part of the problem, if it's been tagged wrong. Yes, I understand that the problem could be hard if it were handled solely by a program. But an interaction between a program and a user might be possible, similar to the way the manual partitioning is done. Plus, a search for an /etc/fstab file shouldn't be that difficult to do. I know, I'm not a programmer (though I have done some limited shell scripting in UNIX SVR4, about 20 years ago, as well as some limited Lisp programming). It just seems to me that a conditional search would rule out many types of partitions. Just as equally, the default would be for the boot sequence to flag the problem, with a potential fix, and/or a "comment it out" choice for the user (defaulting to "comment it out"). That could avoid the confusion, and the image of our distro that such a problem creates.

Is there some way that an individual can alert the right people, in this case, to what's happening? I'm too new to membership in Ubuntu to know the right people to address, or to have made such contacts. But if I'm going to be going around with an Ubuntu-Arizona golf shirt, trying to interest people in trying our distribution, then I don't want it reflecting poorly on Ubuntu because this bug exists.

Thanks again,
Craig

This appears to be no bug of "e2fsprogs", as per comments.

The one thing I don't understand about this bug is that Ted has said (e.g. in https://bugs.launchpad.net/ubuntu/+bug/106209/comments/20) that Ubuntu trashes swap UUIDs by running mkswap, but as far as I know this isn't true any more. Since Ubuntu 7.04, we don't just run mkswap; we extract the old UUID with dd, run mkswap, and reinsert the old UUID again. (The reason we run mkswap at all is that it turns out to be a lot faster than asking libparted to check whether the swap partition is valid.)

If we discount swap as a red herring - or at the very least a bug that's been fixed for some time, even if it still hangs around due to 6.06 and 6.10 - then there are two parts to this bug:

  1) Some component of partman, probably partman-target, should check before formatting whether any of the partitions you're formatting are referred to by /etc/fstab in any of the other filesystems on the system, and issue a warning that doing this will confuse those other installations. The suggestion to add an option to save the UUID and put it back after formatting is intriguing, though of course we can only do this for sure if we're still using the same filesystem.

  2) Arguably, partman-auto should not automatically mount filesystems that contain (say) /etc/fstab. I'm a little more sceptical about this, because I think we're going to be caught between a rock and a hard place. Let's say you're migrating from Red Hat to Ubuntu, and your Red Hat installation doesn't have a separate /home. In that case, it's convenient to be able to get at /home anyway, and certainly it feels inconsistent to have /home automounted only if it's on a separate partition. (Jerry may be happy to mount it by hand, but we added the automounting precisely because not everyone knew how to do that.) That said, I take Ted's point that there's no way to specify the difference between something that's in fstab for convenience and something that's there out of necessity, short perhaps of setting fs_passno to 0.

However ... the desktop has got better since we did all this automounting stuff originally. Nowadays you can go to Places -> Computer, double-click on the filesystem you want to use, enter your sudo password, et voilà. That wasn't the case in 5.10 when this was first implemented. Thus, perhaps it's no longer worth it, and I'm moving this bug over to partman-auto and targetting it to Hardy for further consideration.

If you still want the automounting done in the installer, then speak now or forever hold your peace ...

Er, yeah, the automounting is actually in partman-basicfilesystems, not partman-auto. Whoops.

Colin, thanks for looking at this broken situation.

For whatever reason, when I install another Ubuntu into an existing triple boot system, swap UUID's have not been a problem to fsck. The new Ubuntu happily uses whatever swap(s) it can find.

Booting one of the existing partitons fails because the UUID's don't match since fsck insists on looking for a superceded UUID it doesn't need. My reaction is "What the ??" then fumble around to get the system booted, remember what the problem is, and then do some tedious editing and copying. If I've been doing a bunch of installs like in the later stages of Gutsy, I may remember to do the tedious editing and copying on the other partitions while the latest install is booted up. And again the next install a few days later.

It would be a whole lot less trouble for me if boot didn't automatically do that; if I happen to want to access the new partition when booted on the older, I can just sudo mkdir /media/x, then sudo mount /dev/hda1 (or sda1) /media/x. If I remember the syntax right.

No long winded UUID's required. I think I could explain this to a newbie easier than explaining how to edit UUID's in /etc/fstab and /boot/grub/menu.lst without screwing up these system files. Easist for me is gedit. Under Xubuntu, remembering vim commands is a contest. What is it under Kubuntu, Kate?

For the next bunch of Ubuntu tribes or eggs or flights whatever they are, maybe I'll remember to go into the existing /etc/fstab's and comment out the test partition.

Is there anything in the Installation & Upgrades" stickies that has a preferred solution for newbie's?
Jerry

Right, as I said, swap shouldn't be a problem.

We are going to stick with UUIDs because the kernel has a fun habit of changing device names every so often. Frankly, we'd much rather have a problem on a relatively small number of multi-boot systems than on all upgrades on whatever disk controllers have had their drivers ported over to libata this release - or whatever else might happen in future. I know the result is a bit tedious, and I'm not dismissing your problem, but going back to device names at this point would regress a lot of other stuff unless we wrote a significant chunk of (very likely long-winded and error-prone) migration code.

As I said in my previous post, I think my preference is to stop automounting altogether and recommend that new users use the point-and-click desktop facilities rather than explaining how to use the command line. People who know how to use mount can obviously continue to do so.

Colin,

That sounds like a reasonable solution to me. It would certainly end the current problem. I'm not against CLI, though I prefer not to use it. And being forced to use it and alter system files can be scary, without knowledge and experience behind it. It's too bad that Gutsy can't be modified to do that, now.

Colin, on the surface, stopping automounting sounds like a good direction for the situation - what are the consequences?

Would seem to me, it would be O.K. if booting a previous installed partition didn't try to automount the newly installed partition (right now it stops the boot anyway).

Hopefully it wouldn't be too complex for the user to point and click to mount when desired. Point and click for new users or even old ones is fine. I've been doing command line (or even machine code) for over 40 years but my mistake rate is higher on command line than point and click.
Thanks, Jerry

I am having this trouble in Gutsy when I use kernel 2.6.22-14. I get the message from fsck that it is unable to resolve a uuid, but the uuid exists.
I have reverted to 2.6.20-16, which does boot - although there are some problems with booting at times with that kernel a swell.

I've had this same problem for months after upgrading from edgy to feisty and have been hitting Ctl+D to bypass.

I'm not sure why this worked, but I was having issues with /dev/hdd. It would show up fine in /etc/fstab and in vol_id.

I noticed that if I ran blkid, it would NOT show /dev/hdd. Running "blkid /dev/hdd" seemed to detect it. When running blkid this time, it showed up!

I rebooted to verify things worked and they did... no UUID errors this time.

I guess when fsck runs on boot, it must look to the information in blkid to reference the UUID's/

Anyways, hope this helps people out there. I'm glad to rid this "annoyance".

MikeB

I forgot to mention that I am not using a multi-boot system.

Also when using 2.6.20-16 I get the same problem - but interminably.

I also forgot to mention that I am using RAID 1

Was just hit by this problem in fully updated Ubuntu 7.10

Apparently, for whatever reason, the UUID of my Windows NTFS partision changed name
from
UUID=49862ec3-2b4b-4f20-a8b6-a57c75ee9952
to
UUID=B460AD0660ACD082

1) OBVIOUSLY not automounting a windows partition should NOT halt booting into Linux (CTRL-D/d didnt do anything, had to ALT-CTRL-DEL... which then BTW took me to the desktop?!?... talk about unexpected behaviour).

2) Were on earth is the UUID change coming from? Is it some changes to ntfs-3g? The drive has obviously NOT been formated or had the UUID changed by me manually.

3) Somehow, after getting into the desktop, and opening /etc/fstab the NEW UUID has replaced the old UUID (in the console the old UUID was still there). Is this some kind of autofix/recovery? If it is, then it's still a bit broken since the update happens only AFTER the boot grinds to a halt and you manage to bypass it... by ALT-CTRL-DEL... (?!?!?)

-------
Log of fsck -C -R -A -a
Sat Mar 1 07:02:08 2008

fsck 1.40.2 (12-Jul-2007)
/dev/sda5: clean, 38/44176 files, 39660/88294 blocks
/dev/sdc5: clean, 26900/61063168 files, 101604714/122095992 blocks
/dev/sdb5: clean, 29431/30539776 files, 51986176/61048992 blocks
/dev/sda7: clean, 21514/1310720 files, 1060626/2620595 blocks
/dev/sda9: clean, 61076/24363008 files, 44087874/48705055 blocks
fsck.ext3: Unable to resolve 'UUID=49862ec3-2b4b-4f20-a8b6-a57c75ee9952'
fsck died with exit status 8
----
Excerpt from /etc/fstab
...
# Entry for /dev/sda1 :
UUID=B460AD0660ACD082 /media/WinXP ntfs-3g defaults,locale=en_US.UTF-8 0 0
#WTF happened, below UUID got replaced by above automatcally...
#UUID=49862ec3-2b4b-4f20-a8b6-a57c75ee9952
----

partman-basicfilesystems (56ubuntu4) hardy; urgency=low

  * Disable automounting unless partman/automount is preseeded to true. This
    makes LP #106209 much less likely to occur, since future installations
    are less likely to format a partition whose UUID we have in /etc/fstab.

 -- Colin Watson <email address hidden> Wed, 09 Apr 2008 08:18:47 +0100

The proposed partman-target change to make UUID adjustments to foreign OSes' /etc/fstab files is (a) not for Hardy and (b) possibly far too risky to contemplate at all.

Making sure that the system behaves gracefully if a partition in /etc/fstab goes missing is another facet of this bug; for example we could present some kind of UI in usplash for the user to resolve this, rather than just falling over to a prompt.

At any rate, disabling automounting will make sure that fresh 8.04 installations shouldn't encounter this class of problem.

I have this problem after a second installation of WinXP2 in another logical disk. I installed two separate copies of winxp and one ubuntu. When the system tried to do routine filesystem check, the terminal complained:
fsck.ext3: Unable to resolve 'UUID=xxxxx...'

I successfully fixed the problem by typing:
sudo vol_id /dev/sdaX

Thanks for everyone who makes Ubuntu better. I can completely migrate to Ubuntu now.

This is not a bug that will affect newbies since, very few if any, will already have an installation of linux installed in another partition. As matter of fact, one has to be an OS junkie to have enough partitions defined to be installing a new version of linux when you've already got one installed! I ran into this problem recently (Oct. 21, 2008) when I installed Intrepid to a partition where I had previously installed Hardy, with Gutsy being the version I use every day.

Searching for a solution, I found https://bugs.launchpad.net/bugs/132762 and it's duplicate https://bugs.launchpad.net/bugs/134763 , both of which appear to me to be duplicates of this bug. I added my comment at https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/132762/comments/5

As asked in my comment on bug #132762, is there any harm in not altering the UUID of partitions that are referenced in fstabs on other partitions? I think it would be a nice touch if partman could scan for fstabs in other partitions and report back to the user, for example:

 "/dev/sda7 is mounted as /home for an installation on /dev/sda6.
Are you sure you want to format this partition? Warning! You will lose any data you have stored on that partition!".

 Another example for this laptop I am using to post this:

 "/dev/sda5 is mounted on the followining
as /media/sda5 for an installation on /dev/sda6.
as / for an installation on /dev/sda5
Are you sure you want to format this partition? Warning! You will lose any data you have stored on that partition!"

Another nice touch would be to have a "Preserve UUID" check box in the "Prepare Partitions" dialog (see http://img.xrmb2.net/images/801816.png for an example of the current dialog).This check box could be made unavailable if the results of preserving the UUID would be dangerous or if the file system being used has changed. This check box could also be informative in the case of indicating that swap partitions will have their UUIDs preserved, but at the same time made unavailable so that it just serves to inform. That would have prevented this https://bugs.launchpad.net/bugs/287539.

An option to comment out references to obsolete UUIDs in fstabs that contain them would round out a set of patches that could possibly eliminate this problem.

I continue to be amazed at the progress of linux and ubuntu in particular. It's just that this is one of two relatively straightforward issues were the only negatives in an otherwise absolutely flawles install procees. Apart from this issue and an issue with my installed version of grub not handling the 256bit inodes on the newly formatted ext3 root partition, everything worked "out of the box", iincluding wireless networking!

Alan

OFFTOPIC

I've run into the

fsck.ext3: Unable to resolve 'UUID=d073d821-427e-4aea-bd1f-53fcad4e0e81'

error and halting on boot, and found this bug report. I have a hotswap bay and sometimes drives are not in the bay during boot. I wanted boot to continue without checking these absent drives. The solution, as described in the fsck man page was to make sure that there was 0 in the 6th field of fstab, rather than non-zero. (The 6th field specified the order for boot-time filesystem check, with 0 being skip.) I'm not sure if this helps out with any of the situations described here, but basically what I did was change

UUID=7855008b-966e-4e4f-85ca-21f84ff13a03 /media/nearline ext3 noauto,rw,suid,dev,exec,nouser,async 0 1

to

UUID=7855008b-966e-4e4f-85ca-21f84ff13a03 /media/nearline ext3 noauto,rw,suid,dev,exec,nouser,async 0 0