|
[SOLVED] "fsck.ext3: Unable to resolve 'UUID="
The output of 'fsck' and accompany outputs follow. The system boots okay, but I would like to resolve the UUID error. Anyone run across this before? Thanks.
================FSCK================== fsck 1.40.8 (13-Mar-2008) fsck.ext3: Unable to resolve 'UUID=d8533154-cef1-4cce-a823-9f3f74aab65b' ================FSTAB================= # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 # /dev/sda1 UUID=d8533154-cef1-4cce-a823-9f3f74aab65b / ext3 relatime,errors=remount-ro 0 1 # /dev/sda5 UUID=0703bda2-3d0b-42e5-9d49-5c2634a4bd53 none swap sw 0 0 /dev/scd0 /media/cdrom0 udf,iso9660 user,noauto,exec,utf8 0 0 ================FDISK================= Device Boot Start End Blocks Id System /dev/sda1 * 1 3200 25703968+ 83 Linux /dev/sda2 3201 3576 3020220 5 Extended /dev/sda5 3201 3576 3020188+ 82 Linux swap / Solaris =================vol_id /dev/sda1===== ID_FS_USAGE=filesystem ID_FS_TYPE=ext3 ID_FS_VERSION=1.0 ID_FS_UUID=d8533154-cef1-4cce-a823-9f3f74aab65b ID_FS_UUID_ENC=d8533154-cef1-4cce-a823-9f3f74aab65b ID_FS_LABEL= ID_FS_LABEL_ENC= ID_FS_LABEL_SAFE= ====================================== |
Does substituting /dev/devicenames for UUIDs work?
|
Perhaps the volume ID has changed. Is this a partition that you reformatted? You can use the vol_id command to find out what the UUID is at the moment for that partition. I posted on my blog about that a while ago. HERE's a link to it. If its changed, just replace the UUID in your /etc/fstab file with this new one. Probably, it would be a good idea to rewrite the line and comment out the original, to be on the safe side.
|
Quote:
|
Quote:
Edit: It appears that swap doesn't have a UUID. Shouldn't all partitions have one? See below: Device Boot Start End Blocks Id System /dev/sda1 * 1 3200 25703968+ 83 Linux /dev/sda2 3201 3576 3020220 5 Extended /dev/sda5 3201 3576 3020188+ 82 Linux swap / Solaris vmc@vmc-desktop:~$ sudo vol_id /dev/sda1 ID_FS_USAGE=filesystem ID_FS_TYPE=ext3 ID_FS_VERSION=1.0 ID_FS_UUID=d8533154-cef1-4cce-a823-9f3f74aab65b ID_FS_UUID_ENC=d8533154-cef1-4cce-a823-9f3f74aab65b ID_FS_LABEL= ID_FS_LABEL_ENC= ID_FS_LABEL_SAFE= vmc@vmc-desktop:~$ sudo vol_id /dev/sda5 ID_FS_USAGE=other ID_FS_TYPE=swap ID_FS_VERSION=2 ID_FS_UUID= ID_FS_UUID_ENC= ID_FS_LABEL= ID_FS_LABEL_ENC= ID_FS_LABEL_SAFE= I'm going to check out your blog, but in the mean time I want to open another topic regarding swap. thanks for your reply. |
If you resized it, that would change the UUID, then. That must have blasted your swap. Have you tried to make the swap again?
mkswap /dev/sda5 swapon /dev/sda5 Check with the top or free command and see if its recognized. if so, do the vol_id command on the partition and get the UUID and plug that into your /etc/fstab file. Good luck. |
Quote:
Just being curious, is there any compelling reason why you use UUIDs? While there probably are legitimate situations where one would want to, I still find using /dev/devicenames more dependable, stable compared to using labels or UUIDs. |
Distros that use UUID (probably) use a patched mkswap - I haven't bothered checking as, like unSpawn, I dislike both UUID and LABEL. There is even a patch in circulation to enable the user to specify the UUID to save it being overwritten all the time.
|
A reasonably good answer can be found HERE on the Ubuntu forums, answering just that question.
It needs a small expansion, though. With UUID, you can ensure that if you add and remove drives, as in a rack system, or with a portable drive (especially when you can get a TB external for a bit over $100 in some places), its "location" in the /dev may change, but the drive is the same. So, its still possible to mount it, whether its /dev/hda1 or /dev/sdd7. The UUID stays the same for the filesystem, unless you change the physical qualities of the filesystem, like resizing or reformatting. |
Thanks for the explanatory follow-up.
|
Quote:
By the way, it works now because I 'hard coded' it using /dev/sdax. Edit:Another thing I don't understand is why the system booted okay, even though I resized the partition but only effected the swap? This whole shebang came about because I wanted to image my system using Acronis and not knowing much about UUID's I resized my partitions. Now I see that I can just image the main ext3 partition and rebuild swap using what you suggested :mkswap /dev/sda5,swapon /dev/sda5 after I'm done. |
Sorry for double post but I just remembered that the 'fsck' I did was on a live system! Yea, I know now, and when I rebooted and used Puppy livecd to run command 'fsck' it came back with no errors. If I did that in the first place I wouldn't have realized that my swap wasn't working. So further investigation revealed my swap error.
|
You can't resize swap - well, you can, but it won't do what you want. Every time you run mkswap, the UUID gets regenerated. Just do a swapon.
|
Success! After reading some of vectordrake's comments, I went ahead and deleted both the extended and swap partition using gparted. I then added again extended and swap partition.
Clicked swapon. Exited gparted. and volia! sudo blkid revealed a UUID for swap once again. I edit fstab to now include UUID for all my drives. blkid revealed UUID and free revealed that swap was indeed working correctly again. I could have used the command level mkswap and swapon as vectordrake suggested, but I wanted to see if gparted was up to the task, as I read somewhere else it would work. So now I know I can just image my one partition using Acronis or partimage and rebuild swap easly using either method. Thanks for all the help and points of interest! ======== $ sudo blkid /dev/sda1: UUID="d8533154-cef1-4cce-a823-9f3f74aab65b" TYPE="ext3" /dev/sda5: TYPE="swap" UUID="ea4ab429-32b2-4152-bf2e-d537f49d7da3" ======== $ free total used free shared buffers cached Mem: 1033816 412012 621804 0 10524 207892 -/+ buffers/cache: 193596 840220 Swap: 3020180 0 3020180 |
| All times are GMT -5. The time now is 10:58 AM. |