Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #274859 > unrolled thread

Re: Adding a new boot disk while keeping old disk

Back to article view | Back to linux.debian.user

Contents

  Re: Adding a new boot disk while keeping old disk George at Clug <Clug@goproject.info> - 2024-11-25 08:30 +0100
    Re: Adding a new boot disk while keeping old disk eben@gmx.us - 2024-11-25 16:10 +0100
      Re: Adding a new boot disk while keeping old disk David Wright <deblis@lionunicorn.co.uk> - 2024-11-25 16:30 +0100
        Re: Adding a new boot disk while keeping old disk Felix Miata <mrmazda@stanis.net> - 2024-11-25 16:40 +0100
          Re: Adding a new boot disk while keeping old disk George at Clug <Clug@goproject.info> - 2024-11-26 01:50 +0100
            The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 09:00 +0100
              Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 09:10 +0100
                Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 09:40 +0100
                Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 09:50 +0100
              Re: The "uniqueness" of UUIDs Felix Miata <mrmazda@stanis.net> - 2024-11-26 09:30 +0100
                Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 10:00 +0100
                  Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 10:10 +0100
                    Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 12:20 +0100
                      Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 12:40 +0100
                      Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 12:40 +0100
                  Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 10:30 +0100
                    Re: The "uniqueness" of UUIDs Nicolas George <george@nsup.org> - 2024-11-26 11:00 +0100
                  Re: The "uniqueness" of UUIDs Felix Miata <mrmazda@stanis.net> - 2024-11-26 15:00 +0100
                    Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 16:00 +0100
                      Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 16:40 +0100
                        Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 18:50 +0100
                        Re: The "uniqueness" of UUIDs Michael Stone <mstone@debian.org> - 2024-11-27 18:00 +0100
                    Re: The "uniqueness" of UUIDs Roger Price <debian@rogerprice.org> - 2024-11-26 16:00 +0100
              Re: The "uniqueness" of UUIDs Arno Lehmann <al@its-lehmann.de> - 2024-11-26 09:30 +0100
                Re: The "uniqueness" of UUIDs Arno Lehmann <al@its-lehmann.de> - 2024-11-26 10:50 +0100
              Re: The "uniqueness" of UUIDs <tomas@tuxteam.de> - 2024-11-26 09:50 +0100
              Re: The "uniqueness" of UUIDs pocket@homemail.com - 2024-11-26 13:20 +0100
        Re: Adding a new boot disk while keeping old disk eben@gmx.us - 2024-11-25 18:30 +0100
          Re: Adding a new boot disk while keeping old disk Hans <hans.ullrich@loop.de> - 2024-11-25 21:00 +0100
      Re: Adding a new boot disk while keeping old disk <tomas@tuxteam.de> - 2024-11-25 18:00 +0100
        Re: Adding a new boot disk while keeping old disk Default User <hunguponcontent@gmail.com> - 2024-11-25 18:40 +0100
          Re: Adding a new boot disk while keeping old disk <tomas@tuxteam.de> - 2024-11-25 19:00 +0100
            Re: Adding a new boot disk while keeping old disk Default User <hunguponcontent@gmail.com> - 2024-11-25 20:10 +0100
          Re: Adding a new boot disk while keeping old disk eben@gmx.us - 2024-11-25 23:40 +0100
            Re: Adding a new boot disk while keeping old disk Greg Wooledge <greg@wooledge.org> - 2024-11-26 00:00 +0100
              Re: Adding a new boot disk while keeping old disk Felix Miata <mrmazda@stanis.net> - 2024-11-26 00:30 +0100
        Re: Adding a new boot disk while keeping old disk Max Nikulin <manikulin@gmail.com> - 2024-11-26 03:40 +0100

Page 2 of 2 — ← Prev page 1 [2]

#274910 — Re: The "uniqueness" of UUIDs

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#274938 — Re: The "uniqueness" of UUIDs

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].) 

[toc] | [prev] | [next] | [standalone]

#274907 — Re: The "uniqueness" of UUIDs

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

[toc] | [prev] | [next] | [standalone]

#274885 — Re: The "uniqueness" of UUIDs

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

[toc] | [prev] | [next] | [standalone]

#274895 — Re: The "uniqueness" of UUIDs

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

[toc] | [prev] | [next] | [standalone]

#274887 — Re: The "uniqueness" of UUIDs

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#274903 — Re: The "uniqueness" of UUIDs

> 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" 

[toc] | [prev] | [next] | [standalone]

#274867

On 11/25/24 10:21, David Wright wrote:
> On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:
>> On 11/25/24 02:26, George at Clug wrote:
>>> I would create a folder into which to mount the HD's relevant
>>> partition, then used "blkid" to find the UUID and manually added a
>>> mount point to "/etc/fstab".  The resulting paths may be a bit ugly,
>>> but I am lazy.
>>
>> I find PARTLABELs to be a lot more human-friendly than UUIDs.
>
> Can you put PARTLABELs on an MBR disk?

Ah, apparently you have to use LABEL, but otherwise yes, at least in fstab:

eben@cerberus:~$ sudo fdisk -l /dev/sdc | grep label
Disklabel type: dos

eben@cerberus:~$ sudo blkid /dev/sdc1
/dev/sdc1: LABEL="Partition_1" UUID="ab7e9bee-27f4-4f4f-94c4-5d19d8413074"
BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="b1604273-01"

eben@cerberus:~$ grep Partition_1 /etc/fstab
LABEL=Partition_1			/mnt/temp2		ext4	defaults,noauto	0 0

eben@cerberus:~$ mount | grep temp2

eben@cerberus:~$ sudo mount /mnt/temp2

eben@cerberus:~$ mount | grep temp2
/dev/sdc1 on /mnt/temp2 type ext4 (rw,relatime,stripe=8191)

> (I'm not condoning such a disk. I'd take the opportunity to
> switch to UEFI booting from a GPT SSD if that's possible.
> Some explanation of the partitioning would be useful, rather
> that slavishly copying them.)

I repartitioned in GPT because the 4 partition limit in MBR without jumping
through hoops made them hard to deal with.  My motherboard doesn't boot in
UEFI, but still.

[toc] | [prev] | [next] | [standalone]

#274871

I am not sure, what you are intend to do.

If you want a new bootable harddrive, I suggest, to clone the old (maybe 
smaller one) to the new one using clonezilla.

After it you can resize the partitions of new one to your needs and then mount 
the old one to any folder you want (maybe "/space" or "/data", whatever)

Or just format it.

If you then want it automatically mounted, I suggest, to enter the device 
(like "/dev/sdc1") into /etc/fstab, but the UUID.

If you are using the devicename, it may happen when several harrdtrives, the 
BIOS will not recognize the correct order. So /dev/sdc1 is /dev/sdd1 suddenly.
(I have 4 harddrives in my computer and ran in this issue)


Using UUID will avoid this.

An entry in /etc/fstab would then look like this:

UUID=XXXXX-XXXX-XXXX-XXXX-XXXXXXXXX       /home    ext4    defaults        0

Just an example.

Dunno, if it is that, what you want. If not, just ignore my mail.

Best

Hans
 


 

[toc] | [prev] | [next] | [standalone]

#274865

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 25, 2024 at 10:07:35AM -0500, eben@gmx.us wrote:
> On 11/25/24 02:26, George at Clug wrote:
> > I would create a folder into which to mount the HD's relevant
> > partition, then used "blkid" to find the UUID and manually added a
> > mount point to "/etc/fstab".  The resulting paths may be a bit ugly,
> > but I am lazy.
> 
> I find PARTLABELs to be a lot more human-friendly than UUIDs.

As Felix pointed out in this thread, you're possibly talking about
(file system) LABELS. The idea of UUIDs is that they are "unique",
so you can run two OS installs automatically without the disk IDs
colliding. We leave the collision probability of UUIDs as an exercise
for the reader. Suffice it to say that the probability of /very
weird/ things happening (let alone an alpha particle flipping a few
bits in your RAM) is higher than a UUID collision.

A label is something you come up to slap onto something. So using
the same label is most of the time intended.

Of course, this UUID uniqueness thing starts looking ever more
flimsy once you start bit-copying file systems (people do this!
I know I do!).

Civilised file systems have a slot for each, so you can use both
of them, at the same time, for different purposes.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274868

On Mon, 2024-11-25 at 17:59 +0100, tomas@tuxteam.de wrote:
> On Mon, Nov 25, 2024 at 10:07:35AM -0500, eben@gmx.us wrote:
> > On 11/25/24 02:26, George at Clug wrote:
> > > I would create a folder into which to mount the HD's relevant
> > > partition, then used "blkid" to find the UUID and manually added
> > > a
> > > mount point to "/etc/fstab".  The resulting paths may be a bit
> > > ugly,
> > > but I am lazy.
> > 
> > I find PARTLABELs to be a lot more human-friendly than UUIDs.
> 
> As Felix pointed out in this thread, you're possibly talking about
> (file system) LABELS. The idea of UUIDs is that they are "unique",
> so you can run two OS installs automatically without the disk IDs
> colliding. We leave the collision probability of UUIDs as an exercise
> for the reader. Suffice it to say that the probability of /very
> weird/ things happening (let alone an alpha particle flipping a few
> bits in your RAM) is higher than a UUID collision.
> 
> A label is something you come up to slap onto something. So using
> the same label is most of the time intended.
> 
> Of course, this UUID uniqueness thing starts looking ever more
> flimsy once you start bit-copying file systems (people do this!
> I know I do!).
> 
> Civilised file systems have a slot for each, so you can use both
> of them, at the same time, for different purposes.
> 
> Cheers


--------------------


Thomas, would you mind elaborating on, or give a link to an 
explanation of: 

"Of course, this UUID uniqueness thing starts looking ever more
flimsy once you start bit-copying file systems . . . "

I'm not sure I understand what bit-copying of file systems is, 
and why it would be flimsy.

[toc] | [prev] | [next] | [standalone]

#274869

[Multipart message — attachments visible in raw view] — view raw

On Mon, Nov 25, 2024 at 12:36:55PM -0500, Default User wrote:

[...]

> Thomas, would you mind elaborating on, or give a link to an 
> explanation of: 
> 
> "Of course, this UUID uniqueness thing starts looking ever more
> flimsy once you start bit-copying file systems . . . "
> 
> I'm not sure I understand what bit-copying of file systems is, 
> and why it would be flimsy.

It's more trivial than it seems. If you copy a whole file system
bit-for-bit (e.g. with dd or similar), since the UUID is "in there",
it travels along. Now you have two identical file systems with the
same UUID.

If you now, for example, mount one and write things to it, you have
two different file systems with the same UUID.

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

#274870

On Mon, 2024-11-25 at 18:59 +0100, tomas@tuxteam.de wrote:
> On Mon, Nov 25, 2024 at 12:36:55PM -0500, Default User wrote:
> 
> [...]
> 
> > Thomas, would you mind elaborating on, or give a link to an 
> > explanation of: 
> > 
> > "Of course, this UUID uniqueness thing starts looking ever more
> > flimsy once you start bit-copying file systems . . . "
> > 
> > I'm not sure I understand what bit-copying of file systems is, 
> > and why it would be flimsy.
> 
> It's more trivial than it seems. If you copy a whole file system
> bit-for-bit (e.g. with dd or similar), since the UUID is "in there",
> it travels along. Now you have two identical file systems with the
> same UUID.
> 
> If you now, for example, mount one and write things to it, you have
> two different file systems with the same UUID.
> 
> Cheers

--------------------

Okay, got it.
Thanks!

[toc] | [prev] | [next] | [standalone]

#274873

On 11/25/24 12:36, Default User wrote:
>
> Thomas, would you mind elaborating on, or give a link to an
> explanation of:
>
> "Of course, this UUID uniqueness thing starts looking ever more
> flimsy once you start bit-copying file systems . . . "
>
> I'm not sure I understand what bit-copying of file systems is,
> and why it would be flimsy.

I'm not Thomas, but here you go.  If you do

dd if=/dev/sda1 of=/dev/sdb1

to copy sda1 to sdb1, they get the same UUID.  Which makes one question the
Uniqueness part.  I ran into that, and my solution was to use the actual
device names everywhere, something of the sdXY format.  Which worked great
until I installed Debian, and something in the boot process makes the names
switch randomly.

[toc] | [prev] | [next] | [standalone]

#274874

On Mon, Nov 25, 2024 at 17:37:28 -0500, eben@gmx.us wrote:
> I'm not Thomas, but here you go.  If you do
> 
> dd if=/dev/sda1 of=/dev/sdb1
> 
> to copy sda1 to sdb1, they get the same UUID.  Which makes one question the
> Uniqueness part.  I ran into that, and my solution was to use the actual
> device names everywhere, something of the sdXY format.  Which worked great
> until I installed Debian, and something in the boot process makes the names
> switch randomly.

Using "sda1" in fstab is a bad idea, for exactly the reasons you
discovered the hard way.  The names will not necessarily be assigned
to the same devices each time you boot.

Given that you dd-copied a file system, you might consider changing
the UUID of the new copy.  Assuming this is an ext4 file system,
tune2fs(8) has a -U option that looks like it should do the job.
Specifically, "-U random" looks promising, though I haven't tested it.

If it's not ext4, then consult your documentation for whichever type
of file system this is.

[toc] | [prev] | [next] | [standalone]

#274875

Greg Wooledge composed on 2024-11-25 17:50 (UTC-0500):

> Given that you dd-copied a file system, you might consider changing
> the UUID of the new copy.  Assuming this is an ext4 file system,
> tune2fs(8) has a -U option that looks like it should do the job.
> Specifically, "-U random" looks promising, though I haven't tested it.

Well tested here:
# grep U .bash_history | head -1
tune2fs -U random -L p20deb12 /dev/sda20
# grep U .bash_history | wc -l
42
#

Another PC:
# grep U .bash_history | wc -l
34
# grep U .bash_history | head -1
tune2fs -U random -L p13trixie /dev/sda13
#

I've been getting rid of 128 byte inode filesystems lately in long term prep for
2038 32bit time rollover.
-- 
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

[toc] | [prev] | [next] | [standalone]

#274878

On 25/11/2024 23:59, tomas@tuxteam.de wrote:
> On Mon, Nov 25, 2024 at 10:07:35AM -0500, eben@gmx.us wrote:
>> I find PARTLABELs to be a lot more human-friendly than UUIDs.
> 
> The idea of UUIDs is that they are "unique",
> so you can run two OS installs automatically without the disk IDs
> colliding. We leave the collision probability of UUIDs as an exercise
> for the reader.

I recall a couple of reports on this mailing list when data recovery was 
necessary due to usage of UUIDs. Snapshots have the same filesystem 
UUID, so some old version may be accidentally mounted during boot. Do 
not use them in the case of LVM. Certainly FS labels are affected by the 
same issue.

Do not take it wrong, in other cases I still recommend UUID as first 
option to consider.

Specifically to partition UUIDs, sgdisk has an option for cloned drives:
-G, --randomize-guids

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web