Roger Price (12024-11-26):

UUID sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid
array, I would not be able to use the UUID, only the unique SDxn.

UUIDs are important if you want the system to choose the right drive
with nu human supervision. Do you often retire drives from a RAID array
without human supervision?

Aren't UUIDs supposed to be unique? Roger

Yes, they are: somebody did something wrong on your suystem. Odds it was
you. It sure was not me :-�

When did you add the most recent of these drives? How did you add it?

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice ! Thanks.

I tried this and noticed UUID duplication in the output. Here is part of what I
saw:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
...
sdg
...
├─sdg6 linux_raid_member 1.0 10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home
...
sdh
...
├─sdh6 linux_raid_member 1.0 10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home

UUID sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique? Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Price composed on 2024-11-26 08:51 (UTC+0100):

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice ! Thanks.

I tried this and noticed UUID duplication in the output. Here is part of what I
saw:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
...
sdg
...
├─sdg6 linux_raid_member 1.0 10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home
...
sdh
...
├─sdh6 linux_raid_member 1.0 10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home

UUID sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid array, I
would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique? Roger

Members of a raid filesystem have to be seen as an integral part of one filesystem,
a special case. It's another reason I stick to use of LABELs.

# lsblk -f | egrep -A1 'raid|NAME'
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
sda
--
├─sda5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…
├─sda6 linux_raid_member 1.0 msi85:1usrl f4e4…
│ └─md1 ext4 1.0 hr18md1usrl c3f3… 934.9M 75% /usr/local
├─sda7 linux_raid_member 1.0 msi85:2srv b290…
│ └─md2 ext4 1.0 hr18md2srv 7043… 5.9G 23% /srv
├─sda8 linux_raid_member 1.0 msi85:3hom 6594…
│ └─md3 ext4 1.0 hr18md3hom 71bc… 27.8G 59% /home
├─sda9 linux_raid_member 1.0 msi85:4 32c4…
│ └─md4 ext4 1.0 hr18md4 2d7d… 42.7G 79%
└─sda10 linux_raid_member 1.0 msi85:5iso 7f46…
└─md5 ext4 1.0 hr18md5iso 05f1… 32.4G 95% /isos
--
├─sdb5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…
├─sdb6 linux_raid_member 1.0 msi85:1usrl f4e4…
│ └─md1 ext4 1.0 hr18md1usrl c3f3… 934.9M 75% /usr/local
├─sdb7 linux_raid_member 1.0 msi85:2srv b290…
│ └─md2 ext4 1.0 hr18md2srv 7043… 5.9G 23% /srv
├─sdb8 linux_raid_member 1.0 msi85:3hom 6594…
│ └─md3 ext4 1.0 hr18md3hom 71bc… 27.8G 59% /home
├─sdb9 linux_raid_member 1.0 msi85:4 32c4…
│ └─md4 ext4 1.0 hr18md4 2d7d… 42.7G 79%
└─sdb10 linux_raid_member 1.0 msi85:5iso 7f46…
└─md5 ext4 1.0 hr18md5iso 05f1… 32.4G 95% /isos
#
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

Sorry, the formatting was messed up and the message unreadable.

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice ! Thanks.

I tried this and noticed UUID duplication in the output. I attach a small text file which shows what I saw. UUID sdg6 = UUID sdh6 !

NAME FSTYPE UUID
...
├─sdg6 linux_raid_membe3 f5e37a29-357a-e3f2-c731-e29eddce5e
│ └─md3 ext4 1.039c24711-ab43-497c-bf3e-12b4032575a.4G
...
├─sdh6 linux_raid_membe3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 39c39c24711-ab43-497c-bf3e-12b403257.4G

If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique? Roger TkFNRSAgICBGU1RZUEUgICAgICAgICAgICBGU1ZFUiBMQUJFTCAgICAgICAg ICBVVUlEICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgRlNBVkFJ TCBGU1VTRSUgTU9VTlRQT0lOVA0KLi4uDQrilJzilIBzZGc2ICBsaW51eF9y YWlkX21lbWJlciAxLjAgICAxMC4yMTguMC4xMDA6MyBmNWUzN2EyOS0zNTdh LWUzZjItYzczMS1lMjllZGRjZTVlOTEgICAgICAgICAgICAgICAgDQrilIIg 4pSU4pSAbWQzIGV4dDQgICAgICAgICAgICAgIDEuMCAgICAgICAgICAgICAg ICAgIDM5YzI0NzExLWFiNDMtNDk3Yy1iZjNlLTEyYjQwMzI1NzVhYyAgNzU4 LjRHICAgICA3JSAvbW50L2hvbWUNCi4uLg0K4pSc4pSAc2RoNiAgbGludXhf cmFpZF9tZW1iZXIgMS4wICAgMTAuMjE4LjAuMTAwOjMgZjVlMzdhMjktMzU3 YS1lM2YyLWM3MzEtZTI5ZWRkY2U1ZTkxICAgICAgICAgICAgICAgIA0K4pSC IOKUlOKUgG1kMyBleHQ0ICAgICAgICAgICAgICAxLjAgICAgICAgICAgICAg ICAgICAzOWMyNDcxMS1hYjQzLTQ5N2MtYmYzZS0xMmI0MDMyNTc1YWMgIDc1 OC40RyAgICAgNyUgL21udC9ob21lDQoNCg==

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Roger,

Am 26.11.2024 um 08:51 schrieb Roger Price:

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice !   Thanks.

I tried this and noticed UUID duplication in the output.  Here is part
of what I saw:

NAME    FSTYPE            FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINT
...
sdg
... ├─sdg6  linux_raid_member 1.0   10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91 │ └─md3 ext4 1.0                  39c24711-ab43-497c-bf3e-12b4032575ac  758.4G     7%
/mnt/home
...
sdh
... ├─sdh6  linux_raid_member 1.0   10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91 │ └─md3 ext4 1.0                  39c24711-ab43-497c-bf3e-12b4032575ac  758.4G     7%
/mnt/home

UUID sdg6 = UUID sdh6 !  If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique?  Roger

The UUID reported might be the one of the file system. As the lsblk
output is truncated I can not really guess the context of those lines;
in all cases I checked here, non-unique UUIDs show up on components that
are reported several times (i.e., file systems backed by several backed
by several partitions that are members of one RAID array). If you want
to have a list of all things with their UUIDs in a less ambigous view,
try blkid.

Cheers,

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Nicolas George (12024-11-26):

Yes, they are: somebody did something wrong on your suystem. Odds it was
you. It sure was not me :-�

When did you add the most recent of these drives? How did you add it?

My bad, I read the output on my system incorrectly. Forget these two
paragraphs please.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 08:51:21AM +0100, Roger Price wrote:

[...]

Aren't UUIDs supposed to be unique? Roger

Not if someone copies them, not. They are numbers. There's no magic.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0WKYQAKCRAFyCz1etHa RtrxAJ9cP9hXW0UnOTR0mNWTYEWnwgDcmwCfcDx9pTUQZVo6omeTFHCeXK1UYoU=
=DelD
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

On Tue, 26 Nov 2024, Nicolas George wrote:

Roger Price (12024-11-26):

UUID sdg6 = UUID sdh6 !
Aren't UUIDs supposed to be unique?

Yes, they are: somebody did something wrong on your suystem. Odds it was
you. It sure was not me :-�

When did you add the most recent of these drives? How did you add it?

The Raid was built with Debian 9 using the usual tools, mdadm. It has run smoothly ever since. I recently installed Debian 12 on the box. The installation process discovered the existing Raid and asked for the mount points. It continued to run smoothly. I have never had to change or re-assign the drives.

I do not fiddle with UUIDs, ever. So if someone did something wrong, it was mdadm in Debian 9 or the Debian 12 installation. As I said, I do not mess with UUIDs.

Roger

My apologies again for the wretched formatting of lsblk -f

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

This message is in MIME format. The first part should be readable text,
while the remaining parts are likely unreadable without MIME-aware tools.

On Tue, 26 Nov 2024, Felix Miata wrote:

Members of a raid filesystem have to be seen as an integral part of one filesystem,
a special case. It's another reason I stick to use of LABELs.

# lsblk -f | egrep -A1 'raid|NAME'
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
--
├─sda5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…
--
├─sdb5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…

It makes sense to me that md0 should be reported twice with the same UUID, but surely the underlying hardware should be getting a unique UUID?

The use of LABELs is attractive, but I notice you have the same label for sda5 and sdb5. This means you cannot intervene on "msi85:0tmp". You have to specify
sda5 or sdb5.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Am Dienstag, 26. November 2024, 09:11:58 CET schrieb Roger Price:
What about juste enter

blkid

as root?

Will also give UUID and Label.

Best

Hans

Sorry, the formatting was messed up and the message unreadable.

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice ! Thanks.

I tried this and noticed UUID duplication in the output. I attach a small text file which shows what I saw. UUID sdg6 = UUID sdh6 !

NAME FSTYPE UUID
...
├─sdg6 linux_raid_membe3 f5e37a29-357a-e3f2-c731-e29eddce5e
│ └─md3 ext4 1.039c24711-ab43-497c-bf3e-12b4032575a.4G
...
├─sdh6 linux_raid_membe3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 39c39c24711-ab43-497c-bf3e-12b403257.4G

If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique? Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 26 Nov 2024, Hans wrote:

What about juste enter blkid as root?
Will also give UUID and Label.

# blkid /dev/sdg6
/dev/sdg6: UUID="f5e37a29-357a-e3f2-c731-e29eddce5e91"
UUID_SUB="8ae02b9d-d818-1d8a-88f6-5cb77b15d0eb"
LABEL="10.218.0.100:3" TYPE="linux_raid_member" PARTUUID="000871f1-06"

# blkid /dev/sdh6
/dev/sdh6: UUID="f5e37a29-357a-e3f2-c731-e29eddce5e91"
UUID_SUB="7821cc06-e7f5-358b-cf95-fb0ec2f34585"
LABEL="10.218.0.100:3" TYPE="linux_raid_member" PARTUUID="0000b24f-06"

# blkid /dev/md0
/dev/md0: UUID="8a31b513-cd62-4639-b5e5-3a8f8879164f" BLOCK_SIZE="4096"
TYPE="ext4"

The UUIDs are the same for sdg6 and sdh6 but there is a UUID_SUB to distinguish them. blkid sees a new value for md0's UUID, not the same as lsblk.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Price (12024-11-26):

You have
to specify sda5 or sdb5.

There is nothing wrong with having to specify sda5 or sdb5.

It is only a problem if you want to specify now and expect it to be
still valid after the next reboot.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tuesday, 26-11-2024 at 20:08 Roger Price wrote:

On Tue, 26 Nov 2024, Hans wrote:

What about juste enter blkid as root?
Will also give UUID and Label.

# blkid /dev/sdg6
/dev/sdg6: UUID="f5e37a29-357a-e3f2-c731-e29eddce5e91"
UUID_SUB="8ae02b9d-d818-1d8a-88f6-5cb77b15d0eb"
LABEL="10.218.0.100:3" TYPE="linux_raid_member" PARTUUID="000871f1-06"

# blkid /dev/sdh6
/dev/sdh6: UUID="f5e37a29-357a-e3f2-c731-e29eddce5e91"
UUID_SUB="7821cc06-e7f5-358b-cf95-fb0ec2f34585"
LABEL="10.218.0.100:3" TYPE="linux_raid_member" PARTUUID="0000b24f-06"

# blkid /dev/md0
/dev/md0: UUID="8a31b513-cd62-4639-b5e5-3a8f8879164f" BLOCK_SIZE="4096"
TYPE="ext4"

The UUIDs are the same for sdg6 and sdh6 but there is a UUID_SUB to distinguish
them. blkid sees a new value for md0's UUID, not the same as lsblk.

Thanks for the clarification, Roger.

This is important to understand if working with RAID.

What does /etc/fstab have, I wonder?

RAID, like LVM, to me is a type of virtualisation of storage, hence is not exactly the same as a physical disk drive or partition on the disk drive.

I am guessing UUID is for the OS to see the visualised (RAID) storage, where as UUID_SUB is for the actual partition on the physical disk?

Today I learned a bit more about /dev/disk, but that left me realising there is much more to learn. I really don't know what to think of all of these folders.

# ls -hal /dev/disk/
# ls -hal /dev/disk/by-id
# ls -hal /dev/disk/by-uuid

But the following worked well for me when putting a boot ISO to a USB memory stick.
# cp [isoimagefile.iso] /dev/disk/by-id/usb-SMI_USB_DISK-0:0
# sync

The world is full of mysteries for those too lazy to do heaps of reading and research.

George.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 09:57:59AM +0100, Roger Price wrote:

On Tue, 26 Nov 2024, Felix Miata wrote:

Members of a raid filesystem have to be seen as an integral part of one filesystem,
a special case. It's another reason I stick to use of LABELs.

# lsblk -f | egrep -A1 'raid|NAME'
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
--
├─sda5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…
--
├─sdb5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…

It makes sense to me that md0 should be reported twice with the same UUID, but surely the underlying hardware should be getting a unique UUID?

The UUID is in a slot of the /file system/. The "hardware" (what do you
mean by that?) most probably doesn't know what an UUID is.

The use of LABELs is attractive, but I notice you have the same label for sda5 and sdb5. This means you cannot intervene on "msi85:0tmp". You have
to specify sda5 or sdb5.

LABELS exist at two levels: partitions (if your partition table allows for
it) and file systems.

All things which are "in" the file system will be "in" the RAID, because
you make the file system "on top" of the RAID device.

Of course, if the RAID system allows to attach individual "things" (perhaps UUIDs?) to each of its components you could do that (no idea whether Linux
RAID allows that, though).

But the file system UUIDs and LABELs are "above" this. You can't differentiate RAID components by this. It's as if you ask for the plate number of your rear left tyre. The whole car has one.

Keep the layers apart. It gets confusing quickly.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0WThQAKCRAFyCz1etHa RtAlAJ9Xf7gfNK6HRdpGvpO0R2YktF7powCfdrRj9uk93ItFvw3soQF7Lv1Fsfw=
=8pjj
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi again,

Am 26.11.2024 um 09:24 schrieb Arno Lehmann:

Hi Roger,

Am 26.11.2024 um 08:51 schrieb Roger Price:

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice !   Thanks.

I tried this and noticed UUID duplication in the output.  Here is part
of what I saw:

...

Aren't UUIDs supposed to be unique?  Roger

The UUID reported might be the one of the file system.

Actually and as usual, the documentation clarifies the situation:

-f, --fs
Output info about filesystems. This option is equiva‐
lent to -o NAME,FSTYPE,LABEL,UUID,FSAVAIL,FSUSE%,MOUNT‐
POINT. The authoritative information about filesystems
and raids is provided by the blkid(8) command.
(my manual pager, Debian 11)

The UUID is the one of the file system. The file system is shown as
existing on both partitions, thus both partitions show the same UUID.

Among all other file systems, you should indeed not find that same UUID
again.

Arno

--
Arno Lehmann

IT-Service Lehmann
Sandstr. 6, 49080 Osnabrück

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

tomas@tuxteam.de (12024-11-26):

The UUID is in a slot of the /file system/.

Not only.

There is an UUID in the header of swap partitions (and files). Swap is
not a file system.

There is an UUID in the header of LVM physical volumes. PVs are not filesystems.

Of course, if the RAID system allows to attach individual "things" (perhaps UUIDs?) to each of its components you could do that (no idea whether Linux RAID allows that, though).

Of course it does. MD raid devices contain both an UUID for the array
and an UUID for the device.

I will let somebody with more time than me to spend on find the right invocation of lsblk or other to print both.

Regards,

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 12:16:59PM +0100, Roger Price wrote:

On Tue, 26 Nov 2024, Nicolas George wrote:

Roger Price (12024-11-26):

You have to specify sda5 or sdb5.

There is nothing wrong with having to specify sda5 or sdb5.

Indeed, and it's the only way for Raid specification. For example /proc/mdstat contains no mention of device UUIDs.

It is only a problem if you want to specify now and expect it to be
still valid after the next reboot.

I'm guessing that this feature is something systemd has given us.

No. It has always been a problem [1]. It has become more acute the more
dynamic hardware has become. Nowadays, if you dangle off your machine
a bunch of storage devices on USB, the order they are seen depends on
the USB bus enumeration.

I'm not very happy with the so-called "persistent device names" myself
(that's why my disk is still /dev/sda, and my net interfaces wlan0 and
eth0), but I have the luxury to /know/ my hardware setup and it being
fairly stable.

Those stable device names were invented to solve a problem, and they
were there long before systemd.

Not a friend of systemd myself either, but it's important to stick
to the facts.

Cheers

[1] I stumbled first time upon this around the early 2000s, when we
were making a small-series firewall device with 4 ethernet cards
on it. Now which one is for "outside", which ones "inside"? Could
we guarantee that, say, the first slot was always eth0? Turned out,
no. Any BIOS update could mess up the order.
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0WyHQAKCRAFyCz1etHa RrQxAJ9WvUWLxtsk2kVFGNUyBQ4wio108wCfTZAem0BwODr3mX2CeklyYn8ZGpg=
=gcl5
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 26 Nov 2024, Nicolas George wrote:

Roger Price (12024-11-26):

You have to specify sda5 or sdb5.

There is nothing wrong with having to specify sda5 or sdb5.

Indeed, and it's the only way for Raid specification. For example /proc/mdstat contains no mention of device UUIDs.

It is only a problem if you want to specify now and expect it to be
still valid after the next reboot.

I'm guessing that this feature is something systemd has given us.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Price (12024-11-26):

I'm guessing that this feature is something systemd has given us.

Your hate is making you guess wrong.

--
Nicolas George

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Sent: Tuesday, November 26, 2024 at 2:51 AM
From: "Roger Price" <debian@rogerprice.org>
To: "debian-user Mailing List" <debian-user@lists.debian.org>
Subject: The "uniqueness" of UUIDs

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice ! Thanks.

I tried this and noticed UUID duplication in the output. Here is part of what I
saw:

NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINT
...
sdg
...
├─sdg6 linux_raid_member 1.0 10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home
...
sdh
...
├─sdh6 linux_raid_member 1.0 10.218.0.100:3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 1.0 39c24711-ab43-497c-bf3e-12b4032575ac 758.4G 7% /mnt/home

UUID sdg6 = UUID sdh6 ! If I wanted to retire /dev/sdg6 from the Raid array, I
would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique? Roger

/dev/sdb1: UUID="502aa1c4-77ec-04f2-5f9d-4f5db95ba570" UUID_SUB="7d10136a-cecd-603f-8f27-1fbb39adba5a" LABEL="alarm:Storage" TYPE="linux_raid_member" PARTUUID="11c13521-01"
/dev/sdc1: UUID="502aa1c4-77ec-04f2-5f9d-4f5db95ba570" UUID_SUB="e54cd488-9660-86af-a947-b13d645d1d4d" LABEL="alarm:Storage" TYPE="linux_raid_member"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Price composed on 2024-11-26 03:57 (UTC-0500):

Felix Miata wrote:

Members of a raid filesystem have to be seen as an integral part of one filesystem,
a special case. It's another reason I stick to use of LABELs.

# lsblk -f | egrep -A1 'raid|NAME'
NAME FSTYPE FSVER LABEL UUID FSAVAIL FSUSE% MOUNTPOINTS
--
├─sda5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…
--
├─sdb5 linux_raid_member 1.0 msi85:0tmp 6cb3…
│ └─md0 ext4 1.0 hr18md0tmp 8aea…

It makes sense to me that md0 should be reported twice with the same UUID, but
surely the underlying hardware should be getting a unique UUID?

Answered well upthread by others.

The use of LABELs is attractive, but I notice you have the same label for sda5
and sdb5. This means you cannot intervene on "msi85:0tmp". You have to specify
sda5 or sdb5.

Not at all. hr18md0tmp is an ext4 filesystem LABEL. I wouldn't want to disturb its
two underlying partitions separately except via mdadm.
--
Evolution as taught in public schools is, like religion,
based on faith, not based on science.

Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!

Felix Miata

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 03:53:28PM +0100, Roger Price wrote:

On Tue, 26 Nov 2024, Felix Miata wrote:

The use of LABELs is attractive, but I notice you have the same label for sda5
and sdb5. This means you cannot intervene on "msi85:0tmp". You have to specify
sda5 or sdb5.

Not at all. hr18md0tmp is an ext4 filesystem LABEL. I wouldn't want to disturb its
two underlying partitions separately except via mdadm.

"except via mdadm" : exactly the point I would like to make. mdadm needs to be able to address the individual underlying devices. Only /dev/sdxn style addressing can do this, not duplicate UUIDs, or duplicate LABELs.

If those we are talking about are file system UUIDs/LABELs (and all evidence supports that), they *are not* duplicate. They are *the same*. Change "one"
and *poof* the "other" will change along. Because they are on the file system, which is sitting astride your MD devices.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0XiQwAKCRAFyCz1etHa Rn86AJ9DB0DgazHPhKiT1soa2a/4FMNi7ACbBsRSNzTxSUAxO/ZnDuut/GuSCMA=
=UUXH
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 26 Nov 2024, Felix Miata wrote:

The use of LABELs is attractive, but I notice you have the same label for sda5
and sdb5. This means you cannot intervene on "msi85:0tmp". You have to specify
sda5 or sdb5.

Not at all. hr18md0tmp is an ext4 filesystem LABEL. I wouldn't want to disturb its
two underlying partitions separately except via mdadm.

"except via mdadm" : exactly the point I would like to make. mdadm needs to be able to address the individual underlying devices. Only /dev/sdxn style addressing can do this, not duplicate UUIDs, or duplicate LABELs.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, 26 Nov 2024, tomas@tuxteam.de wrote:

On Tue, Nov 26, 2024 at 03:53:28PM +0100, Roger Price wrote:

"except via mdadm" : exactly the point I would like to make. mdadm needs to >> be able to address the individual underlying devices. Only /dev/sdxn style >> addressing can do this, not duplicate UUIDs, or duplicate LABELs.

If those we are talking about are file system UUIDs/LABELs (and all evidence supports that), they *are not* duplicate. They are *the same*. Change "one" and *poof* the "other" will change along. Because they are on the file system,
which is sitting astride your MD devices.

My understanding is that a Linux file system is a hierachical structure starting
with the root directory (/) which organises the directories and files. The files are stored on various devices which have identities such as /dev/sdxn, UUID or LABEL. These identities are for the devices, not parts of the file system.

The file system and the underlying devices are separate notions, which is why I don't understand your phrase "file system UUIDs/LABELs".

The directory with name /home could be on device with identity /dev/sda2 (or UUID xxxx), but although closely associated in /etc/mtab, neither /dev/sda2 nor UUID xxxx is the identity of the directory.

Roger

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

On Tue, Nov 26, 2024 at 09:11:58AM +0100, Roger Price wrote:

On Tue, 26 Nov 2024, George at Clug wrote:

"$ lsblk -f" output is very nice ! Thanks.

I tried this and noticed UUID duplication in the output. I attach a small text file which shows what I saw. UUID sdg6 = UUID sdh6 !

NAME FSTYPE UUID
...
├─sdg6 linux_raid_membe3 f5e37a29-357a-e3f2-c731-e29eddce5e
│ └─md3 ext4 1.039c24711-ab43-497c-bf3e-12b4032575a.4G
...
├─sdh6 linux_raid_membe3 f5e37a29-357a-e3f2-c731-e29eddce5e91
│ └─md3 ext4 39c39c24711-ab43-497c-bf3e-12b403257.4G

If I wanted to retire /dev/sdg6 from the Raid array, I would not be able to use the UUID, only the unique SDxn.

Aren't UUIDs supposed to be unique?

People see the phrase "UUID" and think every UUID is the same. Your
computer has lots of different UUIDs.

What you see above is the mdadm array UUID. It is meant to be unique PER
ARRAY (on that system). Those devices are part of the same array thus
they have the same ARRAY UUID. You don't have a filesystem on /dev/sdg6
or /dev/sdh6. If you did then it would have a FILESYSTEM UUID.

If you want to refer to sdg6 or sdh6 without using /dev/sd* then you can
use any of the /dev/disk/by-* paths for them.

See also the output of "mdadm --examine /dev/sdg6" and "mdadm --detail /dev/md3".

Thanks,
Andy

--
https://bitfolk.com/ -- No-nonsense VPS hosting

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 04:35:13PM +0100, Roger Price wrote:

On Tue, 26 Nov 2024, tomas@tuxteam.de wrote:

On Tue, Nov 26, 2024 at 03:53:28PM +0100, Roger Price wrote:

"except via mdadm" : exactly the point I would like to make. mdadm needs to
be able to address the individual underlying devices. Only /dev/sdxn style
addressing can do this, not duplicate UUIDs, or duplicate LABELs.

If those we are talking about are file system UUIDs/LABELs (and all evidence
supports that), they *are not* duplicate. They are *the same*. Change "one" and *poof* the "other" will change along. Because they are on the file system,
which is sitting astride your MD devices.

My understanding is that a Linux file system is a hierachical structure starting with the root directory (/) which organises the directories and files. The files are stored on various devices which have identities such
as /dev/sdxn, UUID or LABEL. These identities are for the devices, not
parts of the file system.

File system is indeed ambiguous here. In this context it was meant as
the data structure existing in a block device organizing its files.

For example, in my case:

tomas@caliban:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 1.8T 0 disk
├─sda1 8:1 0 512M 0 part /boot/efi
├─sda2 8:2 0 488M 0 part /boot
└─sda3 8:3 0 1.8T 0 part
└─sda3_crypt 254:0 0 1.8T 0 crypt
├─caliban--vg-root 254:1 0 23.3G 0 lvm /
├─caliban--vg-home 254:2 0 1.6T 0 lvm /home
├─caliban--vg-var 254:3 0 160G 0 lvm /var
└─caliban--vg-tmp 254:4 0 40.3G 0 lvm /tmp

all of /dev/sda1, /dev/sda2, /dev/mapper/caliban--vg-root (which is
actually /dev/dm-1, but let's pretend) and so on have a file system
on them; most of them actually ext4, except /dev/sda2, which is ext2,
and /dev/sda1, which is vfat (as efi, it has to).

Thanks to mount, their file system trees are grafted together into
one single big file system tree (what you rightfully call "the file
system" above).

The file system and the underlying devices are separate notions, which is
why I don't understand your phrase "file system UUIDs/LABELs".

Each of those file systems has a slot for a label. Ext has also a slot for
an UUID, which gets generated afresh whenever you mkfs.ext. ISTR that the
FATs don't have that, but I'm too lazy to look it up now.

Here [1] is the ext4 superblock structure: at offsets 0x68 and 0x78 you
can find the places for the UUID and the name, aka label.

Cheers
[1] https://www.kernel.org/doc/html/latest/filesystems/ext4/globals.html
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ0YItQAKCRAFyCz1etHa RhM6AJ9oiIrQ7EzKK1eB+to+qprWtgykBwCeKJEkpPCas49EwwkCudO/G8w8/0E=
=Hxn8
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Nov 26, 2024 at 04:35:13PM +0100, Roger Price wrote:

My understanding is that a Linux file system is a hierachical
structure starting with the root directory (/) which organises the >directories and files. The files are stored on various devices which
have identities such as /dev/sdxn, UUID or LABEL. These identities
are for the devices, not parts of the file system.

Your understanding is wrong: the UUIDs you are talking about are a
feature of the filesystem--that's why they appear in lsblk -f
(filesystem) output. You can find the same UUID in filesystem-specific
tools such as dumpe2fs; lsblk has logic to extract a UUID from each
filesystem that it knows how to parse and which contains a UUID. There
are other UUIDs associated with some storage devices, partitions, and
all sorts of other things on a modern system, but they are not the
filesystem UUID and are not what is displayed in lsblk -f. (lsblk -f
does include some UUIDs which aren't in filesystems, but which are in
some other on-disk structure logically similar to a filesystem; an
example is LVM physical volumes [also visible via pvs -v].)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)