UbuntuThis forum is for the discussion of Ubuntu Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Here is a nuissance, a solution and some unanswered questions
The problem
Each device, say a partition /dev/hdaN, has a UUID label which might be retrieved as the name of the associated file in /dev/disk/bu-uuid directory. On the other hand, Ubuntu&Kubuntu identify the same device /dev/hdaN, by its UUID label, inside the /etc/fstab file. Now, assuming the abnormal situation when the two UUID strings differ, the boot process of Ubuntu&Kubuntu will hang when checking the file system:
Code:
Unable to resolve 'UUID=XXXX...'
fsck died with exit status 8
where 'XXXX...' is the associated UUID value in /etc/fstab. The solution
Just edit /etc/fstab to correct the UUID value 'XXXX...' from there; one might retrieve the right value from the directory /dev/disk/by-uuid or by running the command sudo vol_id -u /dev/hdaN. That's all. Do such errors occur in Ubuntu&Kubuntu?
Yes they do. In my computer, such accidents produce whenever another Linux system installs after Kubuntu, even in case the new installation process does not modify either the partition table or the file systems inside. Who is responsive?
It might be either Kubuntu or the "intruder" (i.e. the new Linux distribution) but I can not say who. The complete answer could be obtained by comparing the same Ubuntu/Kubuntu information, at three different moments. The information would consist of: A. The content of /etc/fstab file; B. The content of /dev/disk/by-uuid directory.
The three moments I have in mind would be the following: 1. Just before installing/reinstalling another Linux system, after Ubuntu/Kubuntu; 2. Immediately after the new installation process but before any rebooting of Ubuntu/Kubuntu. Such a 'forensic' reading may be obtained by running a live distribution such as Knoppix; 3. Immediately after the first reboot of Ubuntu/Kubuntu.
This way one could say at which moment /etc/fstab and /dev/disk/by-uuid begin to disagree and who is responsive for that. If somebody knows the answer I think it would be great to post it here.
Thanks!
P.S. By installation, my Linux distributions do share the same swap partition but nothing else (I never tell the installers to use partitions which belong to other distributions).
I don't really understand what you're doing but you can find UUID numbers in /dev/.udev/db. Open the file ending in the partition name you're interested in.
The reason you'll get a new UUID assigned to a partition after another install is that it's generated when a partition is formatted. E.G: in the case of a shared swap partition, the new install formats the swap partition and generates a new UUID. In that case you'll need to edit the fstab of the old install to reflect the new UUID.
Hi I seem to be having related problem but the UUIDs seem to correspond and yet fsck still exits with error 8.
fsck error:
Code:
*************************************************************
** If you are using the latest reiserfsprogs and it fails **
** please email bug reports to reiserfs-list@namesys.com, **
** providing as much information as possible -- your **
** hardware, kernel, patches, settings, all reiserfsck **
** messages (including version), the reiserfsck logfile, **
** check the syslog file for any related information. **
** If you would like advice on using this program, support **
** is available for $25 at www.namesys.com/support.html. **
*************************************************************
Will read-only check consistency of the filesystem on UUID=23f148cb-bdfb-4d1f-ae09-abf593709556
Will put log info to 'stdout'
Do you want to run this program?[N/Yes] (note need to type Yes if you do):Yes
Failed to open the device 'UUID=23f148cb-bdfb-4d1f-ae09-abf593709556': No such file or directory
jschiwal: Do you mean take the value returned after the ID_FS UUID = bit and paste it into fstab?
This gives me the same value.
binary_y2k2:
Quote:
Originally Posted by binary_y2k2
When running fsck manually you need to either give the actual device name, or give the /dev/disk/by-uuid/(UUID) location.
In the fsck man page it says
Quote:
If no filesystems are specified on the command line, and the -A option is not specified, fsck will default to checking filesystems in /etc/fstab serially. This is equivalent to the -As options.
Plus I'm experiencing this problem at boot, I merely included the manual fsck to show the output at boot time.
Yes, I do. That should be the correct file system UUID. It should also be identical to what is used by udev to construct the by-uuid devices on the fly. If they are off, then you might try restarting the dbus, udev, and hal daemons. The /etc/fstab entry is static, and if you have changed the filesystem, it may be wrong, so update the /etc/fstab file to match the other dynamic values. About the length, different file systems have uuid numbers of different lengths. A pendrive will have a short one, while an xfs partition will be longer.
Here is a the UUID number of a usb drive with the xfs filesystem:
b545812a-57af-43e8-bbd8-f9b43dd25fc8
Here is the UUID number for a fat32 SanDisk pendrive:
3B69-1AFD
If the fstab entry is wrong, it is probably due to reformatting the partition, in which case, you probably are using it for something else and need to edit the fstab entry anyway.
Also, if the UUID number changes, since this is what is being used to reference where to find the filesystem, you couldn't reliably automate a correction reliable because that would involve a guess. If you had installed one distro, but with several, looking for a /boot partition by performing trial mount of partitions and looking for certain files could come up with the wrong answer. A rescue disk could offer choices however. When I used Mandrake Linux, it would examine the devices and mount them under /mnt. The SuSE install program has a repair program that might repair a bad fstab entry as well. However, I don't think that anything that involves educated guesses should be performed automatically behind the users back. Because if the wrong guess is made, the user would really have a hard time understanding how or why the system changed after a reboot. Imagine dual booting and booting up Ubuntu to have the /home partition of Mandriva come up instead.
If the information from hal & udev doesn't match the number used in /dev/disk/by-uuid, then you may have a problem with your system. It is the udev rules that activate the creation of the /dev/disk/by-uuid symlinks.
On my SuSE laptop:
The udevinfo's ID_FS_UUID should match the number found in /dev/disk/by-uuid, because ID_FS_UUID is what is used to create the link with the "SYMLINK+="disk/by-uuid/$env{ID_FS_UUID}" rule.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.