linux: How can I view all UUIDs for all available disks on my system?
My /etc/fstab
contains this:
# / was on /dev/sda1 during installation
UUID=77d8da74-a690-481a-86d5-9beab5a8e842 / ext4 errors=remount-ro 0 1
There are several other disks on this system, and not all disks are being mounted to the correct location (For example, /dev/sda1 and /dev/sdb1 are sometimes reversed).
How can I see the UUIDs for all disks on my system? Can I see the UUID for the third disk on this system?
linux storage
add a comment |
My /etc/fstab
contains this:
# / was on /dev/sda1 during installation
UUID=77d8da74-a690-481a-86d5-9beab5a8e842 / ext4 errors=remount-ro 0 1
There are several other disks on this system, and not all disks are being mounted to the correct location (For example, /dev/sda1 and /dev/sdb1 are sometimes reversed).
How can I see the UUIDs for all disks on my system? Can I see the UUID for the third disk on this system?
linux storage
@setzamora answer is better. Please change accepted answer.
– nslntmnx
Nov 22 '18 at 9:33
add a comment |
My /etc/fstab
contains this:
# / was on /dev/sda1 during installation
UUID=77d8da74-a690-481a-86d5-9beab5a8e842 / ext4 errors=remount-ro 0 1
There are several other disks on this system, and not all disks are being mounted to the correct location (For example, /dev/sda1 and /dev/sdb1 are sometimes reversed).
How can I see the UUIDs for all disks on my system? Can I see the UUID for the third disk on this system?
linux storage
My /etc/fstab
contains this:
# / was on /dev/sda1 during installation
UUID=77d8da74-a690-481a-86d5-9beab5a8e842 / ext4 errors=remount-ro 0 1
There are several other disks on this system, and not all disks are being mounted to the correct location (For example, /dev/sda1 and /dev/sdb1 are sometimes reversed).
How can I see the UUIDs for all disks on my system? Can I see the UUID for the third disk on this system?
linux storage
linux storage
edited Aug 19 '10 at 16:59
Stefan Lasiewski
asked Aug 18 '10 at 4:14
Stefan LasiewskiStefan Lasiewski
8,882196179
8,882196179
@setzamora answer is better. Please change accepted answer.
– nslntmnx
Nov 22 '18 at 9:33
add a comment |
@setzamora answer is better. Please change accepted answer.
– nslntmnx
Nov 22 '18 at 9:33
@setzamora answer is better. Please change accepted answer.
– nslntmnx
Nov 22 '18 at 9:33
@setzamora answer is better. Please change accepted answer.
– nslntmnx
Nov 22 '18 at 9:33
add a comment |
11 Answers
11
active
oldest
votes
In /dev/disk/by-uuid
there are symlinks mapping each drive's UUID to its entry in /dev
(e.g. /dev/sda1
)
3
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
1
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
2
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
add a comment |
There's a tool called blkid
(use it as root or with sudo
),
# blkid /dev/sda1
/dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
you can check this link for more info
1
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
11
Just a minor comment: looks like being a member of groupdisk
is sufficient to runblkid
; no need for full superuser privileges.
– arielf
Dec 14 '13 at 23:19
9
If you want only the UUID (like for parsing in a script), you can doblkid /dev/sda1 -s UUID -o value
.
– Jack O'Connor
Jun 20 '16 at 21:35
3
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
1
This one saves a great deal of time, though I prefer to doblkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)
– ZaLiTHkA
Jul 1 '17 at 8:04
|
show 1 more comment
The best command to use is
lsblk -f
.
It will list all the devices and partitions, how they are mounted (if at all) and the tree structure of the devices in the case of using LVM, crypto_LUKS, or multiple volume groups on the same drive.
add a comment |
This works for me:
ls -la /dev/disk/by-uuid
If you want to check what type the partition is, use:
df -Th
and it will show you if you have ext3 or ext2. Today it helped me because there was a formatted ext2 partition and I thought it was ext3, which was causing the mount to fail.
You could always trymount -t auto /dev/sda1 /media/sda1
.
– ott--
Dec 28 '12 at 21:16
add a comment |
To only get the UUID
of a specific disk device (for example to be used in a script) you can use:
sudo blkid -s UUID -o value /dev/sdXY
where /dev/sdXY
is the name of the device.
add a comment |
lsblk -o +uuid,name
You can see all the outputs that can be added to the -o
(--output
) with
lsblk --help
Also this will do the job
# blkid
Isn'tname
printed by default ?
– don_crissti
Jul 20 '17 at 20:50
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
add a comment |
The previous answers do not work for multiple devices or for devices with identical UUIDs.
Try this:
sudo blkid /dev/sd*
1
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
4
If you clone a partition with thedd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.
– Kevin
Sep 18 '16 at 9:22
add a comment |
With the following command line you can see UUID plus the mapping to partitions.
ls /dev/disk/by-uuid -lt
lrwxrwxrwx 1 root root 10 Sep 1 18:51 57eacf4e-1940-436e-b945-85f8d4833aa5 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 1 18:51 656f4cae-8527-43a0-a80f-00ac82818744 -> ../../sda1
lrwxrwxrwx 1 root root 9 Sep 1 18:51 d627595d-4060-440e-8380-a1fe9f3f2a81 -> ../../md0
lrwxrwxrwx 1 root root 10 Sep 1 18:51 0dfd6dfe-1852-460d-852c-676a5b9035ed -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep 1 18:51 b1ddf850-8f81-429f-a653-38ae4a4ebb6f -> ../../sda3
lrwxrwxrwx 1 root root 9 Sep 1 18:51 b4b729f7-5699-411c-8f5a-424bbc7c89fc -> ../../sdb
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
add a comment |
I have the same problem as you:
renaming by kernel of /dev/sd**
after a reboot:
Of course all my automatic mounting in /etc/fstab
are referenced by LABEL or by UUID, so basically there is no problem for that.
And all the commands above ,blkid or lsblk, give this kind of information.
But the trouble begins as in my case, when you are using partition in RAW mode, in the currently booted system point-of-view:
for example either:
the partition is used as raw device, to make a virtual disk for VirtualBox
(so the reference to this partition is something like: /dev/sdf3
)
or
the partition is used as raw device, to make a LUN for iSCSI
(so the reference to this partition is something like: /dev/sdc6
)
So now at boot , for example in rc.local, you have to find in a reliable manner, what is the /dev/sdXX
device of your dedicated RAW partition, and adapt some file:
EXAMPLE 1
The VirtualBox disk *.vmk description of this raw disk, in the part something like:
# Extent description
RW 488397167 FLAT "/dev/sdXX" 0
and then restart the VirtualBox service
EXAMPLE 2
in tgtd configuration, a target :target0 was associated to /dev/sdd6
at build time.
After reboot you get the same partition renamed /deb/sdc6
This happens with a removable disk, USB or eSATA!
So how to find the new device automatically ?
Again in /etc/rc.d/rc.local
So in this case we need a reliable manner to find what is the new device name.
GPT partition offers unique GUID for any GPT partition, written in GPT table.
gdisk does not provide this info with listing mode, but only in interactive mode with: i command. Fortunately, blkid does it!
So you need to write a shell script, to look in all your disks, which is the device /dev/sdXX
, associated to the GUID noticed at partition creation time.
Something like, search_device_by_partUUID.sh:
#!/bin/bash
PART_UUID=$1
if [ "$PART_UUID" = "" ]
then
echo "Syntax: $0 <a valid partition UUID>"
exit 3
fi
lsblk | grep '^sd' | awk '{print $1}' | while read DISK_DEVICE
do
INFO=`blkid /dev/${DISK_DEVICE}* | grep "PARTUUID="$PART_UUID"" `
if [ "$INFO" != "" ]
then
echo INFO : "$INFO"
BLK_DEVICE=`echo "$INFO" | awk '{print $1}'`
echo $BLK_DEVICE > /dev/shm/blkdevice
echo -n "BLK_DEVICE : " ; cat /dev/shm/blkdevice
fi
done
and then use /dev/shm/blkdevice
, in your rc.local script.
add a comment |
To see the uuid of a hard disk partition I just boot the system up with a Linux CD and goto my computer mount, click on, the partition I want to see.
The uuid number of the Linux partition will be displayed.
You can also see disk uuid by running Linux Disk utility after the Linux CD boot up.
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
add a comment |
you can use:
xfs_admin -u /dev/sdx
New contributor
1
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "106"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f658%2flinux-how-can-i-view-all-uuids-for-all-available-disks-on-my-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
11 Answers
11
active
oldest
votes
11 Answers
11
active
oldest
votes
active
oldest
votes
active
oldest
votes
In /dev/disk/by-uuid
there are symlinks mapping each drive's UUID to its entry in /dev
(e.g. /dev/sda1
)
3
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
1
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
2
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
add a comment |
In /dev/disk/by-uuid
there are symlinks mapping each drive's UUID to its entry in /dev
(e.g. /dev/sda1
)
3
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
1
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
2
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
add a comment |
In /dev/disk/by-uuid
there are symlinks mapping each drive's UUID to its entry in /dev
(e.g. /dev/sda1
)
In /dev/disk/by-uuid
there are symlinks mapping each drive's UUID to its entry in /dev
(e.g. /dev/sda1
)
answered Aug 18 '10 at 4:29
Michael Mrozek♦Michael Mrozek
61.8k29192212
61.8k29192212
3
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
1
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
2
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
add a comment |
3
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
1
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
2
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
3
3
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
It's not readable when LVM partitions.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:22
1
1
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
LVM already uses long UUID-like identifiers (although presented differently) in its structure. I think the only reason for using filesystem UUIDs with LVM would be as an unified interface for some sort of automation, as LVM already does the mapping of LVs to human-friendly names for you.
– telcoM
Jan 28 '18 at 1:27
2
2
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
ls -lha /dev/disk/by-uuid
– deFreitas
Apr 10 '18 at 2:03
add a comment |
There's a tool called blkid
(use it as root or with sudo
),
# blkid /dev/sda1
/dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
you can check this link for more info
1
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
11
Just a minor comment: looks like being a member of groupdisk
is sufficient to runblkid
; no need for full superuser privileges.
– arielf
Dec 14 '13 at 23:19
9
If you want only the UUID (like for parsing in a script), you can doblkid /dev/sda1 -s UUID -o value
.
– Jack O'Connor
Jun 20 '16 at 21:35
3
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
1
This one saves a great deal of time, though I prefer to doblkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)
– ZaLiTHkA
Jul 1 '17 at 8:04
|
show 1 more comment
There's a tool called blkid
(use it as root or with sudo
),
# blkid /dev/sda1
/dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
you can check this link for more info
1
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
11
Just a minor comment: looks like being a member of groupdisk
is sufficient to runblkid
; no need for full superuser privileges.
– arielf
Dec 14 '13 at 23:19
9
If you want only the UUID (like for parsing in a script), you can doblkid /dev/sda1 -s UUID -o value
.
– Jack O'Connor
Jun 20 '16 at 21:35
3
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
1
This one saves a great deal of time, though I prefer to doblkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)
– ZaLiTHkA
Jul 1 '17 at 8:04
|
show 1 more comment
There's a tool called blkid
(use it as root or with sudo
),
# blkid /dev/sda1
/dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
you can check this link for more info
There's a tool called blkid
(use it as root or with sudo
),
# blkid /dev/sda1
/dev/sda1: LABEL="/" UUID="ee7cf0a0-1922-401b-a1ae-6ec9261484c0" SEC_TYPE="ext2" TYPE="ext3"
you can check this link for more info
edited Nov 12 '13 at 15:19
Gilles
542k12810991616
542k12810991616
answered Aug 18 '10 at 4:26
setzamorasetzamora
1,6062118
1,6062118
1
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
11
Just a minor comment: looks like being a member of groupdisk
is sufficient to runblkid
; no need for full superuser privileges.
– arielf
Dec 14 '13 at 23:19
9
If you want only the UUID (like for parsing in a script), you can doblkid /dev/sda1 -s UUID -o value
.
– Jack O'Connor
Jun 20 '16 at 21:35
3
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
1
This one saves a great deal of time, though I prefer to doblkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)
– ZaLiTHkA
Jul 1 '17 at 8:04
|
show 1 more comment
1
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
11
Just a minor comment: looks like being a member of groupdisk
is sufficient to runblkid
; no need for full superuser privileges.
– arielf
Dec 14 '13 at 23:19
9
If you want only the UUID (like for parsing in a script), you can doblkid /dev/sda1 -s UUID -o value
.
– Jack O'Connor
Jun 20 '16 at 21:35
3
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
1
This one saves a great deal of time, though I prefer to doblkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)
– ZaLiTHkA
Jul 1 '17 at 8:04
1
1
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
I like blkid, especially when LVM2.
– Grzegorz Wierzowiecki
Sep 18 '11 at 21:23
11
11
Just a minor comment: looks like being a member of group
disk
is sufficient to run blkid
; no need for full superuser privileges.– arielf
Dec 14 '13 at 23:19
Just a minor comment: looks like being a member of group
disk
is sufficient to run blkid
; no need for full superuser privileges.– arielf
Dec 14 '13 at 23:19
9
9
If you want only the UUID (like for parsing in a script), you can do
blkid /dev/sda1 -s UUID -o value
.– Jack O'Connor
Jun 20 '16 at 21:35
If you want only the UUID (like for parsing in a script), you can do
blkid /dev/sda1 -s UUID -o value
.– Jack O'Connor
Jun 20 '16 at 21:35
3
3
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
Quick comment here : in my distro (Debian 8) this yields UUID as well as "PARTUUID", which is rather confusing. I used {lsblk} commands which gives only one value.
– takumar
Sep 12 '16 at 11:57
1
1
This one saves a great deal of time, though I prefer to do
blkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)– ZaLiTHkA
Jul 1 '17 at 8:04
This one saves a great deal of time, though I prefer to do
blkid /dev/sd*
to list all drives.. The info that spits out is generally more than enough to find the drive you need. :)– ZaLiTHkA
Jul 1 '17 at 8:04
|
show 1 more comment
The best command to use is
lsblk -f
.
It will list all the devices and partitions, how they are mounted (if at all) and the tree structure of the devices in the case of using LVM, crypto_LUKS, or multiple volume groups on the same drive.
add a comment |
The best command to use is
lsblk -f
.
It will list all the devices and partitions, how they are mounted (if at all) and the tree structure of the devices in the case of using LVM, crypto_LUKS, or multiple volume groups on the same drive.
add a comment |
The best command to use is
lsblk -f
.
It will list all the devices and partitions, how they are mounted (if at all) and the tree structure of the devices in the case of using LVM, crypto_LUKS, or multiple volume groups on the same drive.
The best command to use is
lsblk -f
.
It will list all the devices and partitions, how they are mounted (if at all) and the tree structure of the devices in the case of using LVM, crypto_LUKS, or multiple volume groups on the same drive.
answered Nov 17 '16 at 19:00
John ReaJohn Rea
29132
29132
add a comment |
add a comment |
This works for me:
ls -la /dev/disk/by-uuid
If you want to check what type the partition is, use:
df -Th
and it will show you if you have ext3 or ext2. Today it helped me because there was a formatted ext2 partition and I thought it was ext3, which was causing the mount to fail.
You could always trymount -t auto /dev/sda1 /media/sda1
.
– ott--
Dec 28 '12 at 21:16
add a comment |
This works for me:
ls -la /dev/disk/by-uuid
If you want to check what type the partition is, use:
df -Th
and it will show you if you have ext3 or ext2. Today it helped me because there was a formatted ext2 partition and I thought it was ext3, which was causing the mount to fail.
You could always trymount -t auto /dev/sda1 /media/sda1
.
– ott--
Dec 28 '12 at 21:16
add a comment |
This works for me:
ls -la /dev/disk/by-uuid
If you want to check what type the partition is, use:
df -Th
and it will show you if you have ext3 or ext2. Today it helped me because there was a formatted ext2 partition and I thought it was ext3, which was causing the mount to fail.
This works for me:
ls -la /dev/disk/by-uuid
If you want to check what type the partition is, use:
df -Th
and it will show you if you have ext3 or ext2. Today it helped me because there was a formatted ext2 partition and I thought it was ext3, which was causing the mount to fail.
edited Dec 29 '12 at 2:36
Michael Mrozek♦
61.8k29192212
61.8k29192212
answered Dec 28 '12 at 19:49
MIrraMIrra
7802923
7802923
You could always trymount -t auto /dev/sda1 /media/sda1
.
– ott--
Dec 28 '12 at 21:16
add a comment |
You could always trymount -t auto /dev/sda1 /media/sda1
.
– ott--
Dec 28 '12 at 21:16
You could always try
mount -t auto /dev/sda1 /media/sda1
.– ott--
Dec 28 '12 at 21:16
You could always try
mount -t auto /dev/sda1 /media/sda1
.– ott--
Dec 28 '12 at 21:16
add a comment |
To only get the UUID
of a specific disk device (for example to be used in a script) you can use:
sudo blkid -s UUID -o value /dev/sdXY
where /dev/sdXY
is the name of the device.
add a comment |
To only get the UUID
of a specific disk device (for example to be used in a script) you can use:
sudo blkid -s UUID -o value /dev/sdXY
where /dev/sdXY
is the name of the device.
add a comment |
To only get the UUID
of a specific disk device (for example to be used in a script) you can use:
sudo blkid -s UUID -o value /dev/sdXY
where /dev/sdXY
is the name of the device.
To only get the UUID
of a specific disk device (for example to be used in a script) you can use:
sudo blkid -s UUID -o value /dev/sdXY
where /dev/sdXY
is the name of the device.
answered Apr 3 '17 at 15:13
Strahinja KustudicStrahinja Kustudic
30625
30625
add a comment |
add a comment |
lsblk -o +uuid,name
You can see all the outputs that can be added to the -o
(--output
) with
lsblk --help
Also this will do the job
# blkid
Isn'tname
printed by default ?
– don_crissti
Jul 20 '17 at 20:50
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
add a comment |
lsblk -o +uuid,name
You can see all the outputs that can be added to the -o
(--output
) with
lsblk --help
Also this will do the job
# blkid
Isn'tname
printed by default ?
– don_crissti
Jul 20 '17 at 20:50
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
add a comment |
lsblk -o +uuid,name
You can see all the outputs that can be added to the -o
(--output
) with
lsblk --help
Also this will do the job
# blkid
lsblk -o +uuid,name
You can see all the outputs that can be added to the -o
(--output
) with
lsblk --help
Also this will do the job
# blkid
edited Jul 20 '17 at 20:48
answered Jul 20 '17 at 20:40
Nico RodsevichNico Rodsevich
430159
430159
Isn'tname
printed by default ?
– don_crissti
Jul 20 '17 at 20:50
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
add a comment |
Isn'tname
printed by default ?
– don_crissti
Jul 20 '17 at 20:50
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
Isn't
name
printed by default ?– don_crissti
Jul 20 '17 at 20:50
Isn't
name
printed by default ?– don_crissti
Jul 20 '17 at 20:50
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
it is. Added it just for educational purposes (add the comma to separate the fields you want)
– Nico Rodsevich
Jul 20 '17 at 22:30
add a comment |
The previous answers do not work for multiple devices or for devices with identical UUIDs.
Try this:
sudo blkid /dev/sd*
1
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
4
If you clone a partition with thedd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.
– Kevin
Sep 18 '16 at 9:22
add a comment |
The previous answers do not work for multiple devices or for devices with identical UUIDs.
Try this:
sudo blkid /dev/sd*
1
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
4
If you clone a partition with thedd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.
– Kevin
Sep 18 '16 at 9:22
add a comment |
The previous answers do not work for multiple devices or for devices with identical UUIDs.
Try this:
sudo blkid /dev/sd*
The previous answers do not work for multiple devices or for devices with identical UUIDs.
Try this:
sudo blkid /dev/sd*
answered Sep 14 '16 at 7:37
KevinKevin
211
211
1
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
4
If you clone a partition with thedd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.
– Kevin
Sep 18 '16 at 9:22
add a comment |
1
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
4
If you clone a partition with thedd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.
– Kevin
Sep 18 '16 at 9:22
1
1
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
Really ? You mean, the most voted answer does not work ?
– don_crissti
Sep 14 '16 at 8:04
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
A universally unique identifier (UUID) should always be unique. The entire purpose of a UUID is to be a unique, universally. If not, there's a problem. I have seen duplicated UUIDs in cloned VMs, at least for network devices.
– Stefan Lasiewski
Sep 14 '16 at 17:00
4
4
If you clone a partition with the
dd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.– Kevin
Sep 18 '16 at 9:22
If you clone a partition with the
dd
command the copy will have the same uuid and yes, that is a problem. The other answers here wouldn't show that.– Kevin
Sep 18 '16 at 9:22
add a comment |
With the following command line you can see UUID plus the mapping to partitions.
ls /dev/disk/by-uuid -lt
lrwxrwxrwx 1 root root 10 Sep 1 18:51 57eacf4e-1940-436e-b945-85f8d4833aa5 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 1 18:51 656f4cae-8527-43a0-a80f-00ac82818744 -> ../../sda1
lrwxrwxrwx 1 root root 9 Sep 1 18:51 d627595d-4060-440e-8380-a1fe9f3f2a81 -> ../../md0
lrwxrwxrwx 1 root root 10 Sep 1 18:51 0dfd6dfe-1852-460d-852c-676a5b9035ed -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep 1 18:51 b1ddf850-8f81-429f-a653-38ae4a4ebb6f -> ../../sda3
lrwxrwxrwx 1 root root 9 Sep 1 18:51 b4b729f7-5699-411c-8f5a-424bbc7c89fc -> ../../sdb
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
add a comment |
With the following command line you can see UUID plus the mapping to partitions.
ls /dev/disk/by-uuid -lt
lrwxrwxrwx 1 root root 10 Sep 1 18:51 57eacf4e-1940-436e-b945-85f8d4833aa5 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 1 18:51 656f4cae-8527-43a0-a80f-00ac82818744 -> ../../sda1
lrwxrwxrwx 1 root root 9 Sep 1 18:51 d627595d-4060-440e-8380-a1fe9f3f2a81 -> ../../md0
lrwxrwxrwx 1 root root 10 Sep 1 18:51 0dfd6dfe-1852-460d-852c-676a5b9035ed -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep 1 18:51 b1ddf850-8f81-429f-a653-38ae4a4ebb6f -> ../../sda3
lrwxrwxrwx 1 root root 9 Sep 1 18:51 b4b729f7-5699-411c-8f5a-424bbc7c89fc -> ../../sdb
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
add a comment |
With the following command line you can see UUID plus the mapping to partitions.
ls /dev/disk/by-uuid -lt
lrwxrwxrwx 1 root root 10 Sep 1 18:51 57eacf4e-1940-436e-b945-85f8d4833aa5 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 1 18:51 656f4cae-8527-43a0-a80f-00ac82818744 -> ../../sda1
lrwxrwxrwx 1 root root 9 Sep 1 18:51 d627595d-4060-440e-8380-a1fe9f3f2a81 -> ../../md0
lrwxrwxrwx 1 root root 10 Sep 1 18:51 0dfd6dfe-1852-460d-852c-676a5b9035ed -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep 1 18:51 b1ddf850-8f81-429f-a653-38ae4a4ebb6f -> ../../sda3
lrwxrwxrwx 1 root root 9 Sep 1 18:51 b4b729f7-5699-411c-8f5a-424bbc7c89fc -> ../../sdb
With the following command line you can see UUID plus the mapping to partitions.
ls /dev/disk/by-uuid -lt
lrwxrwxrwx 1 root root 10 Sep 1 18:51 57eacf4e-1940-436e-b945-85f8d4833aa5 -> ../../sda2
lrwxrwxrwx 1 root root 10 Sep 1 18:51 656f4cae-8527-43a0-a80f-00ac82818744 -> ../../sda1
lrwxrwxrwx 1 root root 9 Sep 1 18:51 d627595d-4060-440e-8380-a1fe9f3f2a81 -> ../../md0
lrwxrwxrwx 1 root root 10 Sep 1 18:51 0dfd6dfe-1852-460d-852c-676a5b9035ed -> ../../sda4
lrwxrwxrwx 1 root root 10 Sep 1 18:51 b1ddf850-8f81-429f-a653-38ae4a4ebb6f -> ../../sda3
lrwxrwxrwx 1 root root 9 Sep 1 18:51 b4b729f7-5699-411c-8f5a-424bbc7c89fc -> ../../sdb
answered Sep 1 '15 at 16:59
Nicolas GuérinetNicolas Guérinet
1214
1214
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
add a comment |
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
Why can we see the uuid of sda
– Honghe.Wu
Aug 10 '17 at 13:10
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
There is one UUID for a file system per partition. On sda, i have 4 partitions so, I had 4 UUID. wiki.debian.org/Part-UUID
– Nicolas Guérinet
Aug 10 '17 at 15:02
add a comment |
I have the same problem as you:
renaming by kernel of /dev/sd**
after a reboot:
Of course all my automatic mounting in /etc/fstab
are referenced by LABEL or by UUID, so basically there is no problem for that.
And all the commands above ,blkid or lsblk, give this kind of information.
But the trouble begins as in my case, when you are using partition in RAW mode, in the currently booted system point-of-view:
for example either:
the partition is used as raw device, to make a virtual disk for VirtualBox
(so the reference to this partition is something like: /dev/sdf3
)
or
the partition is used as raw device, to make a LUN for iSCSI
(so the reference to this partition is something like: /dev/sdc6
)
So now at boot , for example in rc.local, you have to find in a reliable manner, what is the /dev/sdXX
device of your dedicated RAW partition, and adapt some file:
EXAMPLE 1
The VirtualBox disk *.vmk description of this raw disk, in the part something like:
# Extent description
RW 488397167 FLAT "/dev/sdXX" 0
and then restart the VirtualBox service
EXAMPLE 2
in tgtd configuration, a target :target0 was associated to /dev/sdd6
at build time.
After reboot you get the same partition renamed /deb/sdc6
This happens with a removable disk, USB or eSATA!
So how to find the new device automatically ?
Again in /etc/rc.d/rc.local
So in this case we need a reliable manner to find what is the new device name.
GPT partition offers unique GUID for any GPT partition, written in GPT table.
gdisk does not provide this info with listing mode, but only in interactive mode with: i command. Fortunately, blkid does it!
So you need to write a shell script, to look in all your disks, which is the device /dev/sdXX
, associated to the GUID noticed at partition creation time.
Something like, search_device_by_partUUID.sh:
#!/bin/bash
PART_UUID=$1
if [ "$PART_UUID" = "" ]
then
echo "Syntax: $0 <a valid partition UUID>"
exit 3
fi
lsblk | grep '^sd' | awk '{print $1}' | while read DISK_DEVICE
do
INFO=`blkid /dev/${DISK_DEVICE}* | grep "PARTUUID="$PART_UUID"" `
if [ "$INFO" != "" ]
then
echo INFO : "$INFO"
BLK_DEVICE=`echo "$INFO" | awk '{print $1}'`
echo $BLK_DEVICE > /dev/shm/blkdevice
echo -n "BLK_DEVICE : " ; cat /dev/shm/blkdevice
fi
done
and then use /dev/shm/blkdevice
, in your rc.local script.
add a comment |
I have the same problem as you:
renaming by kernel of /dev/sd**
after a reboot:
Of course all my automatic mounting in /etc/fstab
are referenced by LABEL or by UUID, so basically there is no problem for that.
And all the commands above ,blkid or lsblk, give this kind of information.
But the trouble begins as in my case, when you are using partition in RAW mode, in the currently booted system point-of-view:
for example either:
the partition is used as raw device, to make a virtual disk for VirtualBox
(so the reference to this partition is something like: /dev/sdf3
)
or
the partition is used as raw device, to make a LUN for iSCSI
(so the reference to this partition is something like: /dev/sdc6
)
So now at boot , for example in rc.local, you have to find in a reliable manner, what is the /dev/sdXX
device of your dedicated RAW partition, and adapt some file:
EXAMPLE 1
The VirtualBox disk *.vmk description of this raw disk, in the part something like:
# Extent description
RW 488397167 FLAT "/dev/sdXX" 0
and then restart the VirtualBox service
EXAMPLE 2
in tgtd configuration, a target :target0 was associated to /dev/sdd6
at build time.
After reboot you get the same partition renamed /deb/sdc6
This happens with a removable disk, USB or eSATA!
So how to find the new device automatically ?
Again in /etc/rc.d/rc.local
So in this case we need a reliable manner to find what is the new device name.
GPT partition offers unique GUID for any GPT partition, written in GPT table.
gdisk does not provide this info with listing mode, but only in interactive mode with: i command. Fortunately, blkid does it!
So you need to write a shell script, to look in all your disks, which is the device /dev/sdXX
, associated to the GUID noticed at partition creation time.
Something like, search_device_by_partUUID.sh:
#!/bin/bash
PART_UUID=$1
if [ "$PART_UUID" = "" ]
then
echo "Syntax: $0 <a valid partition UUID>"
exit 3
fi
lsblk | grep '^sd' | awk '{print $1}' | while read DISK_DEVICE
do
INFO=`blkid /dev/${DISK_DEVICE}* | grep "PARTUUID="$PART_UUID"" `
if [ "$INFO" != "" ]
then
echo INFO : "$INFO"
BLK_DEVICE=`echo "$INFO" | awk '{print $1}'`
echo $BLK_DEVICE > /dev/shm/blkdevice
echo -n "BLK_DEVICE : " ; cat /dev/shm/blkdevice
fi
done
and then use /dev/shm/blkdevice
, in your rc.local script.
add a comment |
I have the same problem as you:
renaming by kernel of /dev/sd**
after a reboot:
Of course all my automatic mounting in /etc/fstab
are referenced by LABEL or by UUID, so basically there is no problem for that.
And all the commands above ,blkid or lsblk, give this kind of information.
But the trouble begins as in my case, when you are using partition in RAW mode, in the currently booted system point-of-view:
for example either:
the partition is used as raw device, to make a virtual disk for VirtualBox
(so the reference to this partition is something like: /dev/sdf3
)
or
the partition is used as raw device, to make a LUN for iSCSI
(so the reference to this partition is something like: /dev/sdc6
)
So now at boot , for example in rc.local, you have to find in a reliable manner, what is the /dev/sdXX
device of your dedicated RAW partition, and adapt some file:
EXAMPLE 1
The VirtualBox disk *.vmk description of this raw disk, in the part something like:
# Extent description
RW 488397167 FLAT "/dev/sdXX" 0
and then restart the VirtualBox service
EXAMPLE 2
in tgtd configuration, a target :target0 was associated to /dev/sdd6
at build time.
After reboot you get the same partition renamed /deb/sdc6
This happens with a removable disk, USB or eSATA!
So how to find the new device automatically ?
Again in /etc/rc.d/rc.local
So in this case we need a reliable manner to find what is the new device name.
GPT partition offers unique GUID for any GPT partition, written in GPT table.
gdisk does not provide this info with listing mode, but only in interactive mode with: i command. Fortunately, blkid does it!
So you need to write a shell script, to look in all your disks, which is the device /dev/sdXX
, associated to the GUID noticed at partition creation time.
Something like, search_device_by_partUUID.sh:
#!/bin/bash
PART_UUID=$1
if [ "$PART_UUID" = "" ]
then
echo "Syntax: $0 <a valid partition UUID>"
exit 3
fi
lsblk | grep '^sd' | awk '{print $1}' | while read DISK_DEVICE
do
INFO=`blkid /dev/${DISK_DEVICE}* | grep "PARTUUID="$PART_UUID"" `
if [ "$INFO" != "" ]
then
echo INFO : "$INFO"
BLK_DEVICE=`echo "$INFO" | awk '{print $1}'`
echo $BLK_DEVICE > /dev/shm/blkdevice
echo -n "BLK_DEVICE : " ; cat /dev/shm/blkdevice
fi
done
and then use /dev/shm/blkdevice
, in your rc.local script.
I have the same problem as you:
renaming by kernel of /dev/sd**
after a reboot:
Of course all my automatic mounting in /etc/fstab
are referenced by LABEL or by UUID, so basically there is no problem for that.
And all the commands above ,blkid or lsblk, give this kind of information.
But the trouble begins as in my case, when you are using partition in RAW mode, in the currently booted system point-of-view:
for example either:
the partition is used as raw device, to make a virtual disk for VirtualBox
(so the reference to this partition is something like: /dev/sdf3
)
or
the partition is used as raw device, to make a LUN for iSCSI
(so the reference to this partition is something like: /dev/sdc6
)
So now at boot , for example in rc.local, you have to find in a reliable manner, what is the /dev/sdXX
device of your dedicated RAW partition, and adapt some file:
EXAMPLE 1
The VirtualBox disk *.vmk description of this raw disk, in the part something like:
# Extent description
RW 488397167 FLAT "/dev/sdXX" 0
and then restart the VirtualBox service
EXAMPLE 2
in tgtd configuration, a target :target0 was associated to /dev/sdd6
at build time.
After reboot you get the same partition renamed /deb/sdc6
This happens with a removable disk, USB or eSATA!
So how to find the new device automatically ?
Again in /etc/rc.d/rc.local
So in this case we need a reliable manner to find what is the new device name.
GPT partition offers unique GUID for any GPT partition, written in GPT table.
gdisk does not provide this info with listing mode, but only in interactive mode with: i command. Fortunately, blkid does it!
So you need to write a shell script, to look in all your disks, which is the device /dev/sdXX
, associated to the GUID noticed at partition creation time.
Something like, search_device_by_partUUID.sh:
#!/bin/bash
PART_UUID=$1
if [ "$PART_UUID" = "" ]
then
echo "Syntax: $0 <a valid partition UUID>"
exit 3
fi
lsblk | grep '^sd' | awk '{print $1}' | while read DISK_DEVICE
do
INFO=`blkid /dev/${DISK_DEVICE}* | grep "PARTUUID="$PART_UUID"" `
if [ "$INFO" != "" ]
then
echo INFO : "$INFO"
BLK_DEVICE=`echo "$INFO" | awk '{print $1}'`
echo $BLK_DEVICE > /dev/shm/blkdevice
echo -n "BLK_DEVICE : " ; cat /dev/shm/blkdevice
fi
done
and then use /dev/shm/blkdevice
, in your rc.local script.
edited Jun 21 '18 at 12:36
karel
751819
751819
answered Jun 21 '18 at 10:19
эруан абграловэруан абгралов
111
111
add a comment |
add a comment |
To see the uuid of a hard disk partition I just boot the system up with a Linux CD and goto my computer mount, click on, the partition I want to see.
The uuid number of the Linux partition will be displayed.
You can also see disk uuid by running Linux Disk utility after the Linux CD boot up.
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
add a comment |
To see the uuid of a hard disk partition I just boot the system up with a Linux CD and goto my computer mount, click on, the partition I want to see.
The uuid number of the Linux partition will be displayed.
You can also see disk uuid by running Linux Disk utility after the Linux CD boot up.
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
add a comment |
To see the uuid of a hard disk partition I just boot the system up with a Linux CD and goto my computer mount, click on, the partition I want to see.
The uuid number of the Linux partition will be displayed.
You can also see disk uuid by running Linux Disk utility after the Linux CD boot up.
To see the uuid of a hard disk partition I just boot the system up with a Linux CD and goto my computer mount, click on, the partition I want to see.
The uuid number of the Linux partition will be displayed.
You can also see disk uuid by running Linux Disk utility after the Linux CD boot up.
edited May 16 '13 at 6:00
Anthon
61.2k17104168
61.2k17104168
answered May 16 '13 at 5:43
man puk tamman puk tam
1
1
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
add a comment |
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
What's "my computer mount"? And what's "Linux Disk utility", sounds like gnome-disk-utility aka Disks?
– Xen2050
Nov 30 '18 at 4:15
add a comment |
you can use:
xfs_admin -u /dev/sdx
New contributor
1
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
add a comment |
you can use:
xfs_admin -u /dev/sdx
New contributor
1
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
add a comment |
you can use:
xfs_admin -u /dev/sdx
New contributor
you can use:
xfs_admin -u /dev/sdx
New contributor
edited 40 mins ago
Jeff Schaller
43.4k1160140
43.4k1160140
New contributor
answered 1 hour ago
S.DuygunS.Duygun
1
1
New contributor
New contributor
1
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
add a comment |
1
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
1
1
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
I'm not sure an xfs command would be much use for an ext4 filesystem, though.
– Jeff Schaller
41 mins ago
add a comment |
Thanks for contributing an answer to Unix & Linux Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f658%2flinux-how-can-i-view-all-uuids-for-all-available-disks-on-my-system%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
@setzamora answer is better. Please change accepted answer.
– nslntmnx
Nov 22 '18 at 9:33