FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Ubuntu User

 
 
LinkBack Thread Tools
 
Old 07-08-2010, 10:31 PM
NoOp
 
Default UUID anomaly

On 07/08/2010 02:39 PM, R Kimber wrote:
> Following some partition resizing that appeared to go well, I've discovered
> that gparted reports the id of sdc7 as:
> ae8fcccb-59d9-4b7e-aa02-c301eee02c8f
> whereas blkid reports it as:
> ed0b56e7-7a08-4e94-8c52-3de8d5e5c6fb
>
> Which is correct? Are there other ways of finding the UUID that I can use
> to check?

I'd go with blkid. Sounds as if gparted has a bug? What does /etc/fstab
show?

FWIW: Mine do match.

>
> It's unsettling that apps can't report something as fundamental as the UUID
> consistently.
>
> - Richard.



--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-08-2010, 11:02 PM
Rashkae
 
Default UUID anomaly

NoOp wrote:
> On 07/08/2010 02:39 PM, R Kimber wrote:
>> Following some partition resizing that appeared to go well, I've discovered
>> that gparted reports the id of sdc7 as:
>> ae8fcccb-59d9-4b7e-aa02-c301eee02c8f
>> whereas blkid reports it as:
>> ed0b56e7-7a08-4e94-8c52-3de8d5e5c6fb
>>
>> Which is correct? Are there other ways of finding the UUID that I can use
>> to check?
>
> I'd go with blkid. Sounds as if gparted has a bug? What does /etc/fstab
> show?
>
> FWIW: Mine do match.
>
>> It's unsettling that apps can't report something as fundamental as the UUID
>> consistently.
>>
>> - Richard.
>
>
>

I once stumbled onto something like this changing an XFS filesystem to a
EXT3 filesystem. Most filesystems leave empty space in the partition
superblock (which can be used by a bootloader, for example) but XFS does
not.. presumably, XFS left filesystem meta-data in the 'dead' space not
used by ext.. I had to zero out that partition to prevent any left over
xfs meta-data from interfering. There might be other strange
combinations that might have this effect as well.




--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 05:39 AM
Nils Kassube
 
Default UUID anomaly

R Kimber wrote:
> Following some partition resizing that appeared to go well, I've
> discovered that gparted reports the id of sdc7 as:
> ae8fcccb-59d9-4b7e-aa02-c301eee02c8f
> whereas blkid reports it as:
> ed0b56e7-7a08-4e94-8c52-3de8d5e5c6fb
>
> Which is correct? Are there other ways of finding the UUID that I
> can use to check?

I suppose you used "blkid" and not "sudo blkid". Calling blkid without
sudo doesn't necessarily tell you the current state but the one from the
cache file /etc/blkid.tab which was written when blkid was last used
with sudo.


Nils

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 08:54 AM
R Kimber
 
Default UUID anomaly

On Thu, 08 Jul 2010 15:31:17 -0700
NoOp wrote:

>
> I'd go with blkid. Sounds as if gparted has a bug? What does /etc/fstab
> show?

I was looking at the UUIDs in order to put some new entries into fstab.

I'll try the blkid one.

- Richard.
--
Richard Kimber
Political Science Resources
http://www.PoliticsResources.net/

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 08:59 AM
R Kimber
 
Default UUID anomaly

On Fri, 9 Jul 2010 07:39:41 +0200
Nils Kassube wrote:

> I suppose you used "blkid" and not "sudo blkid". Calling blkid without
> sudo doesn't necessarily tell you the current state but the one from the
> cache file /etc/blkid.tab which was written when blkid was last used
> with sudo.

Ah! Thank you. Now they match. Gparted was right it seems. Maybe there's
a case for making blkid not useable without sudo (etc). I found the blkid
command on a webpage that made no mention of root privileges.

- Richard.
--
Richard Kimber
Political Science Resources
http://www.PoliticsResources.net/

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 09:42 AM
Markus Schönhaber
 
Default UUID anomaly

09.07.2010 10:59, R Kimber:

> On Fri, 9 Jul 2010 07:39:41 +0200

> Nils Kassube wrote:
>
>> I suppose you used "blkid" and not "sudo blkid". Calling blkid without
>> sudo doesn't necessarily tell you the current state but the one from the
>> cache file /etc/blkid.tab which was written when blkid was last used
>> with sudo.

That's interesting, indeed.
I've never fallen into this trap since I wasn't aware that blkid uses a
cache file. Therefore, for me, running blkid was associated with "must
access raw device" and in turn "needs root privileges".

> Ah! Thank you. Now they match. Gparted was right it seems. Maybe there's
> a case for making blkid not useable without sudo (etc). I found the blkid
> command on a webpage that made no mention of root privileges.

I guess, there's a reason for making blkid usable as unprivileged user.
Or, to put it the other way round, something might break if it wasn't.
I'm not exactly sure if this really is the case, though.

Nevertheless, this possible pitfall might be documented more prominently.
Information is there:
the blkid(8) man page
http://manpages.ubuntu.com/manpages/lucid/en/man8/blkid.8.html
mentions the cache file and says
| The blkid program is the command-line interface to working
| with libblkid(3) library
and if you look at the libblkid(3) man page
http://manpages.ubuntu.com/manpages/lucid/en/man3/libblkid.3.html
you'll find
| Block device information is normally kept in a cache file
| /etc/blkid.tab and is verified to still be valid before being
| returned to the user (if the user has read permission on the raw
| block device, otherwise not).
So, if you read carefully and think about it, this essentially says "if
device information has changed since the last run of blkid as privileged
user and you run blkid as user without access to the raw device, the
information returned will be wrong".
But that's not what I'd call extremely and absolutely obvious.

Maybe blkid, when run under an unprivileged account, should display a
warning and tell the user that the information returned wasn't verified.

--
Regards
mks

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 11:14 AM
Nils Kassube
 
Default UUID anomaly

Markus Schönhaber wrote:
> > Nils Kassube wrote:
> >> I suppose you used "blkid" and not "sudo blkid". Calling blkid
> >> without sudo doesn't necessarily tell you the current state but
> >> the one from the cache file /etc/blkid.tab which was written when
> >> blkid was last used with sudo.
>
> That's interesting, indeed.
> I've never fallen into this trap since I wasn't aware that blkid uses
> a cache file. Therefore, for me, running blkid was associated with
> "must access raw device" and in turn "needs root privileges".

The behaviour of blkid changed about a year ago and I remember a
discussion about it (I think on this list). Previously there was no
output for unprivileged users. But after the change, the output came
from the cache file. Nowadays I avoid the blkid command and use

ls -l /dev/disk/by-*/

instead. I'm quite confident that the output of this command is real and
not from a cache file.


Nils

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 12:23 PM
Markus Schönhaber
 
Default UUID anomaly

09.07.2010 13:14, Nils Kassube:

> Nowadays I avoid the blkid command and use
>
> ls -l /dev/disk/by-*/
>
> instead. I'm quite confident that the output of this command is real and
> not from a cache file.

IIRC those disk/by-* symlinks to actual device nodes are generated by
udev. So, there's probably no cache file involved. But the interesting
question is: does udev update those symlinks immediately when device
info changes?
This seems to be the case. For testing purposes (on Lucid), I created a
new LV and did a
# mkfs -t ext4 /dev/<vg>/<lv>
twice. After each invocation of mkfs a new/updated symlink existed in
/dev/disk/by-uuid
whose name was what blkid (as root) reported to be the UUID of the device.

All in all: good point!

--
Regards
mks

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 
Old 07-09-2010, 01:44 PM
R Kimber
 
Default UUID anomaly

On Fri, 09 Jul 2010 11:42:49 +0200
Markus Schönhaber wrote:

> Maybe blkid, when run under an unprivileged account, should display a
> warning and tell the user that the information returned wasn't verified.

Yes, I think this might be the best way.

- Richard.
--
Richard Kimber
Political Science Resources
http://www.PoliticsResources.net/

--
ubuntu-users mailing list
ubuntu-users@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-users
 

Thread Tools




All times are GMT. The time now is 12:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org