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 1 of 2  [1] 2  Next page →

#274859 — Re: Adding a new boot disk while keeping old disk

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

Charlie,

I think this is what you are looking for (and what I use).

# nano /etc/default/grub

https://wiki.debian.org/Grub
The configuration file is /boot/grub/grub.cfg, but you shouldn't edit
it directly. This file is generated by grub v2's update-grub(8)...
To configure grub "v2", you should edit /etc/default/grub, then run
update-grub. 

 You are far more adventurous than myself. I would have unpluged the
HD, install an nice clean, fresh Debian Linux to the nice new NVMe,
then after the installation worked well, plugged in the HD and mounted
it through the GUI. If I got frustrated mounting the drive frequently,
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.



In /etc/fstab add entry something like, depending on what ext or other
format your drive is:

UUID=ecbf69dd-e238-42f4-9ee9-043044cc0953 /home/[username]/videos/HD
ext4    defaults,noatime        0       2


I hope the "nano /etc/default/grub" info helps? 



As far as changing the UUIDs in "/etc/default/grub", that is not
something I bother to do, so I am not much help in that regard.  Good
luck on your efforts !



George.







On Monday, 25-11-2024 at 12:56 Charlie Gibbs wrote:
> I have a 20-year-old box which was nonetheless enough to run Debian
> Bookworm (12.5) - but the video card, equipped with an Nvidia
GeForce
> 610 GPU, was too old.  I was getting messages on boot saying that
it
> was only supported by drivers up to version 390, while Bookworm
doesn't
> support drivers that old.
> 
> The box was getting flaky on boot anyway, so I figured it was time
to
> spring for a new motherboard, complete with an AMD Ryzen 5
processor,
> 32GB of RAM, and GeForce 1030 video card.
> 
> I was getting nothing on the screen when I first fired it up, but a
> friend and I eventually tracked it down to a RAM module that wasn't
> properly seated.  Once we corrected that, the machine happily came
up,
> found the existing hard drive and everything on it, and was fully
> operational.  Things really have progressed since the bad old
days.
> 
> But here's the catch.  Since I was laying out the bucks for lots
of new
> hardware anyway, the salesman talked me into throwing in a 1TB NVMe
SSD.
> What the heck, might as well really speed things up.  However, I
want
> to keep my existing hard drive; it's a fairly new 4TB unit and /home
> contains large archives of music and video files.  What I'd like
to
> do is move everything to the SSD - including the /home partition but
> without the music and video files, which I'd leave on the spinning
rust
> in a renamed set of directories mounted elsewhere.
> 
> Rather than doing a full re-install and copying massive amounts of
data
> back and forth, I'm trying to take a shortcut - which may or may not
be
> a good idea, but I'll let you guys judge.
> 
> Here's the output of lsblk:
> 
> NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
> sda           8:0    0   3.6T  0 disk
> ├─sda1        8:1    0     1M  0 part
> ├─sda2        8:2    0  27.9G  0 part /
> ├─sda3        8:3    0   7.5G  0 part [SWAP]
> └─sda4        8:4    0   3.6T  0 part /home
> sdb           8:16   1     0B  0 disk
> sdc           8:32   1     0B  0 disk
> sdd           8:48   1     0B  0 disk
> sde           8:64   1     0B  0 disk
> sr0          11:0    1  1024M  0 rom
> nvme0n1     259:0    0 931.5G  0 disk
> ├─nvme0n1p1 259:5    0     1M  0 part
> ├─nvme0n1p2 259:6    0    30G  0 part
> ├─nvme0n1p3 259:7    0     8G  0 part
> └─nvme0n1p4 259:8    0 893.5G  0 part
> 
> As you can see, I've duplicated the partitions on the SSD.  I also
> copied the 30GB / partition to the SSD with dd, and changed the
> UUID of the copy to avoid conflicts due to the cloning.  I mounted
> /dev/nvme0n1p2 (which I hope to make the new / partition) and
> changed the UUIDs in its copy of /etc/fstab to point to the
> partitions on the SSD.
> 
> I think my problem is getting GRUB to go to the SSD.  I tried the
> following:
> 
>      sudo grub-install /dev/nvme0n1
> 
> The following messages came out (with a delay of several seconds
between
> them):
> 
>      Installing for i386-pc platform.
>      Installation finished. No error reported.
> 
> (Is that first message correct?  That sounds like old hardware.)
> 
> When re-booting, I went into the BIOS screen, and saw that the SSD
was
> first in the boot order.  However, this probably doesn't mean much
if
> I didn't get it set up properly.  The machine boots, but
apparently
> falls back to the hard drive.  The first two lines of dmesg are:
> 
> [    0.000000] Linux version 6.1.0-23-amd64 
> (debian-kernel@lists.debian.org) (gcc-12 (Debian 12.2.0-14) 12.2.0,
GNU 
> ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC Debian 
> 6.1.99-1 (2024-07-15)
> [    0.000000] Command line:
BOOT_IMAGE=/boot/vmlinuz-6.1.0-23-amd64 
> root=UUID=fb2c9cb9-1737-4bbf-b3e8-c5e88b40877e ro quiet
> 
> According to blkid, that UUID corresponds to /dev/sda2, i.e. the /
> partition on the hard drive.  I'm obviously missing an incantation
> to make the machine go to the SSD instead.  In /boot/grub/grub.cfg
> I find all sorts of references to the UUID of /dev/sda2, but the
> file starts with a big scary "DO NOT EDIT THIS FILE" message.
> 
> I've been looking up GRUB documentation, but my eyes are starting to
> glaze over.  I get the feeling that I'm close, but don't quite
have
> the GRUB fu.  Could someone provide some pointers?
> 
> -- 
> /~\  Charlie Gibbs                  |  We'll
go down in history as
> \ /        |  the first society that wouldn't
>   X   I'm really at ac.dekanfrus     |  save itself
because it wasn't
> / \  if you read it the right way.  |  cost-effective.  --
Kurt Vonnegut
> 
>

[toc] | [next] | [standalone]

#274862

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.

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

#274863

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?

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

Cheers,
David.

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

#274864

David Wright composed on 2024-11-25 09:21 (UTC-0600):

> On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:

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

> (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 have to think eben wasn't conscious of the difference between PARTLABEL and
LABEL when composing.

All manual configuration I do involving Linux native filesystems is done using
LABELs, swapspace too. I favor lsblk -f over blkid most of the time.
-- 
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]

#274876

On Tuesday, 26-11-2024 at 02:33 Felix Miata wrote:
> David Wright composed on 2024-11-25 09:21 (UTC-0600):
> 
> > On Mon 25 Nov 2024 at 10:07:35 (-0500), eben wrote:
> 
> >> 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?
> 
> > (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 have to think eben wasn't conscious of the difference between PARTLABEL and
> LABEL when composing.
> 
> All manual configuration I do involving Linux native filesystems is done using
> LABELs, swapspace too. I favor lsblk -f over blkid most of the time.

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

George.

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

#274881 — The "uniqueness" of UUIDs

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

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

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

#274882 — Re: The "uniqueness" of UUIDs

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

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

#274886 — Re: The "uniqueness" of UUIDs

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

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

#274888 — Re: The "uniqueness" of UUIDs

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

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

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

#274884 — Re: The "uniqueness" of UUIDs

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

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

#274890 — Re: The "uniqueness" of UUIDs

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

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

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

#274891 — Re: The "uniqueness" of UUIDs

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

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

#274898 — Re: The "uniqueness" of UUIDs

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

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

#274899 — Re: The "uniqueness" of UUIDs

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

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

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

#274900 — Re: The "uniqueness" of UUIDs

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

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

#274893 — Re: The "uniqueness" of UUIDs

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

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

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

#274896 — Re: The "uniqueness" of UUIDs

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

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

#274904 — Re: The "uniqueness" of UUIDs

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

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

#274906 — Re: The "uniqueness" of UUIDs

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

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

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

#274909 — Re: The "uniqueness" of UUIDs

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

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web