Hi,
My system had Ubuntu Hardy and Win Vista when I decided to check out Fedora 9.

My system is a Dell Inspiron with an eSATA Hitachi 120GB internal hard disk and an external USB Seagate 250GB hard disk.

I had the / and the /boot partitions of Ubuntu on /dev/sda(Hitachi) and the /usr and /home partitions on /dev/sdb(Seagate). I had decided to do the same for Fedora 9, and instead of creating another /home partition for Fedora, decided to share it with Ubuntu. I thought that I had done the partitioning properly and proceeded for install.

After the install was done and I rebooted the machine and wanted to boot Fedora 9, it complained at the 'Checking filesystems' stage: fsck.ext3: Unable to resolve: UUID=xxxxxxxxxx. This UUID resolution problem was reported for two partitions. Subsequently, I was dropped to a prompt.

There, I entered the command: 'ls -l /dev/disk/by-uuid'. I found that both the UUIDs that cause the error are UUIDs of partitions on /dev/sdb, one UUID points to /dev/sdb3(/home) and another UUID points to /dev/sdb6(/usr). Then I checked up /etc/fstab and in that the mount points of those UUIDs are mentioned correctly.

I tried replacing the UUIDs with /dev/sdb3 and /dev/sdb6 as applicable, in fstab, and then tried to reboot. Now, Fedora complains that the partition superblocks are bad and e2fsck needs to be executed and I am brought to the same prompt, albeit through a different error message now.

I know that I haven't provided the actual logs, but I will surely do that on request. Can anyone please point out where I am going wrong?

In ending, this is my first post in LQ. I wish LQ all the best.
Thanks in advance

It sounds to me that the file systems are indeed corrupt. Running e2fsck may resolve the problem.
It may have been disconnected before the filesystems were synced. An external drive may not be the best place for the /usr partition. If it was just the /home partition, you could comment out the home partition in the fstab file and then boot up in the single mode and run e2fsck from the booted system. There may have been minor feature enhancements in recent ext3 versions and an older e2fsck program may not work if these features (options) are used. So you may need to boot up using the FC9 install disk and enter "rescue" instead booting up to Ubuntu.

jschiwal...Thanks a lot for your reply.

Please note that I booted into Ubuntu and could mount the /usr and /home partitions. This led me to think that there is no inherent problem with the hardware as such. Please correct me if I am wrong. The one issue that is baffling me is: why am I having this problem with the partitions on the external USB HDD only?

Now a question from a rookie. Sorry if I sound ridiculous. You advised not to keep the /usr partition in the external drive. Do you say this because it is prone to corruption and some daemons whose elf images are in /usr may not execute thus bringing the system down? Could you please elaborate?

Thanks a lot for your patience and your help.

Most software you install will install under the /usr hierarchy. If you look at the directories under /usr, they reflect the same ones that are under root, including "lib". Besides the problem you are having with possible corruption, if the device isn't plugged in you may not be able to boot, even in single mode.

You could run a test and enter "single" as a kernel option when booting up. That will be a non-networked, single-user operating mode. Then enter "lsof | grep '/usr'" to see if the /usr hierarchy is used. If it isn't, then I am wrong, and you will be able to comment out the /usr and /home lines from /etc/fstab to be able to boot up into init level 1 without these partitions.

If you have a corruption problem with the usb drive that you need to resolve, then you would most likely boot up into init level 1 to resolve it.

I think I may be confused about what partitions you are sharing. You shouldn't share /usr between two distro's. Sharing /home would be OK, but one potential gotcha that I mentioned earlier is if the version of ext3 on one distro is more recent than a later one, and new features are used, then the fsck program of the older distro may refuse to run, for fear that doing so may corrupt the file system. If this is the case, then change the last two entries in FC's /etc/fstab file to "0 0" to prevent the filesystem from being checked when you boot up.

Fedora doesn't know about UUID in the initrd. I'm loathe to share /home like that, but if I did I'd use raw device specifications (the old /dev/...) or LABEL in the Fedora fstab - Fedora knows about them.