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

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

Where do I find the definitive man page for mdadm?

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

Contents

  Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 14:10 +0100
    Re: Where do I find the definitive man page for mdadm? Dan Ritter <dsr@randomstring.org> - 2021-11-12 15:10 +0100
      Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 15:30 +0100
      Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 15:50 +0100
        Re: Where do I find the definitive man page for mdadm? Dan Ritter <dsr@randomstring.org> - 2021-11-12 16:40 +0100
          Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 17:50 +0100
            Re: Where do I find the definitive man page for mdadm? The Wanderer <wanderer@fastmail.fm> - 2021-11-12 17:50 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 18:20 +0100
            Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-13 13:40 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 14:10 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 14:40 +0100
                Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-13 15:00 +0100
                  Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 15:30 +0100
                    Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-13 16:00 +0100
                      Re: Where do I find the definitive man page for mdadm? David Wright <deblis@lionunicorn.co.uk> - 2021-11-13 17:40 +0100
                      Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 19:20 +0100
                        Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-13 21:50 +0100
                          Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 23:00 +0100
                            Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-14 00:10 +0100
                              Re: Where do I find the definitive man page for mdadm? Greg Wooledge <greg@wooledge.org> - 2021-11-14 00:40 +0100
                                Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-14 01:30 +0100
                                  Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-14 09:10 +0100
                                Re: Where do I find the definitive man page for mdadm? David Wright <deblis@lionunicorn.co.uk> - 2021-11-14 18:00 +0100
                                  Re: Where do I find the definitive man page for mdadm? "Thomas Schmitt" <scdbackup@gmx.net> - 2021-11-14 19:40 +0100
                                    Re: Where do I find the definitive man page for mdadm? David Wright <deblis@lionunicorn.co.uk> - 2021-11-15 02:40 +0100
                                  Re: Where do I find the definitive man page for mdadm? "Thomas Schmitt" <scdbackup@gmx.net> - 2021-11-15 09:10 +0100
                                    Re: Where do I find the definitive man page for mdadm? David Wright <deblis@lionunicorn.co.uk> - 2021-11-16 05:30 +0100
                            Re: Where do I find the definitive man page for mdadm? Tom Dial <tddial@comcast.net> - 2021-11-14 05:00 +0100
                              Re: Where do I find the definitive man page for mdadm? Greg Wooledge <greg@wooledge.org> - 2021-11-14 05:10 +0100
                              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-14 05:40 +0100
        Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 18:10 +0100
          Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 19:00 +0100
        Re: Where do I find the definitive man page for mdadm? "Andrew M.A. Cater" <amacater@einval.com> - 2021-11-12 18:10 +0100
          Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 20:10 +0100
            Re: Where do I find the definitive man page for mdadm? Dan Ritter <dsr@randomstring.org> - 2021-11-12 21:40 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 23:00 +0100
                Re: Where do I find the definitive man page for mdadm? The Wanderer <wanderer@fastmail.fm> - 2021-11-12 23:10 +0100
                  Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 01:00 +0100
      Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 22:30 +0100
        Re: Where do I find the definitive man page for mdadm? Dan Ritter <dsr@randomstring.org> - 2021-11-13 12:30 +0100
          Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 13:30 +0100
            Re: Where do I find the definitive man page for mdadm? The Wanderer <wanderer@fastmail.fm> - 2021-11-13 13:50 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 15:00 +0100
            Re: Where do I find the definitive man page for mdadm? David Wright <deblis@lionunicorn.co.uk> - 2021-11-13 17:50 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 19:40 +0100
    Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 15:10 +0100
      Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 15:30 +0100
        Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-12 16:40 +0100
          Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 18:10 +0100
            Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 19:20 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 20:20 +0100
                Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-13 00:10 +0100
                  Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-13 12:40 +0100
          Re: Where do I find the definitive man page for mdadm? Dan Ritter <dsr@randomstring.org> - 2021-11-12 18:20 +0100
            Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 19:50 +0100
              Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 23:50 +0100
                Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-13 01:10 +0100
            Re: Where do I find the definitive man page for mdadm? Andy Smith <andy@strugglers.net> - 2021-11-13 12:50 +0100
        Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 17:50 +0100
          Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 18:10 +0100
            Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-12 19:00 +0100
              Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 20:30 +0100
                Re: Where do I find the definitive man page for mdadm? Charles Curley <charlescurley@charlescurley.com> - 2021-11-13 00:20 +0100
    Re: Where do I find the definitive man page for mdadm? David Wright <deblis@lionunicorn.co.uk> - 2021-11-12 15:30 +0100
      Re: Where do I find the definitive man page for mdadm? Gene Heskett <gheskett@shentel.net> - 2021-11-12 16:10 +0100

Page 1 of 4  [1] 2 3 4  Next page →

#242052 — Where do I find the definitive man page for mdadm?

Greetings raid experts;

The man page we have goes on and on for megabytes without ever giving an 
example.

I thought maybe it could scan for devices so that I could build an 
mdadm.conf but it wont do a --scan by itself.

I have installed 4 1T samsung EVo 870's on their own non-raid sata 
controller, but with 11 days uptime and the logrotate  manager having a 
10k is too big attitude, all data from the last reboot has scrolled off 
the end of /var/log/syslog-7.gz.

But I don't see an option (or recognize it if it is there) to give it a 
controller id and let it make a raid10 out of the 4 identical drives it 
could find there.

If there is such a critter, point me at it please.

What I'd like to do when I install bullseye, is use this raid10 for 
the /home partition in the bullseye install.

Thanks.
  
Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [next] | [standalone]

#242059

Gene Heskett wrote: 
> The man page we have goes on and on for megabytes without ever giving an 
> example.
> 
> I thought maybe it could scan for devices so that I could build an 
> mdadm.conf but it wont do a --scan by itself.

You are looking for

mdadm --detail  --scan

It is in that man page, as an example under --detail.


> But I don't see an option (or recognize it if it is there) to give it a 
> controller id and let it make a raid10 out of the 4 identical drives it 
> could find there.
> 
> If there is such a critter, point me at it please.

You have to feed mdadm the drives you want specifically; there's
no scattershot approach.

Let's say that the drives are /dev/sdf, /dev/sdg, /dev/sdh and
/dev/sdi.

(You can re-confirm what drive is what via hdparm -i, or
smartctl.)

If you have data on them, it will be wiped out. You should copy
off anything important, and then run wipefs on each of them.

Then, creation is

# mdadm -C /dev/md0 --level=10 --raid-devices=4 /dev/sdf /dev/sdg /dev/sdh /dev/sdi

(assuming you want it named /dev/md0 and there isn't one
already)

Then you can make a filesystem on /dev/md0 and put it in your
fstab, mount it, and copy data over to it.

> What I'd like to do when I install bullseye, is use this raid10 for 
> the /home partition in the bullseye install.

The installer will recognize it as an md RAID and can be told that you
want to use it as-is, or you can destroy it and re-create it without
data.

-dsr-

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

#242065

On Friday 12 November 2021 08:49:21 Dan Ritter wrote:

> Gene Heskett wrote:
> > The man page we have goes on and on for megabytes without ever
> > giving an example.
> >
> > I thought maybe it could scan for devices so that I could build an
> > mdadm.conf but it wont do a --scan by itself.
>
> You are looking for
>
> mdadm --detail  --scan
>
> It is in that man page, as an example under --detail.
>
> > But I don't see an option (or recognize it if it is there) to give
> > it a controller id and let it make a raid10 out of the 4 identical
> > drives it could find there.
> >
> > If there is such a critter, point me at it please.
>
> You have to feed mdadm the drives you want specifically; there's
> no scattershot approach.
>
> Let's say that the drives are /dev/sdf, /dev/sdg, /dev/sdh and
> /dev/sdi.
>
> (You can re-confirm what drive is what via hdparm -i, or
> smartctl.)
>
> If you have data on them, it will be wiped out. You should copy
> off anything important, and then run wipefs on each of them.
>
> Then, creation is
>
> # mdadm -C /dev/md0 --level=10 --raid-devices=4 /dev/sdf /dev/sdg
> /dev/sdh /dev/sdi
>
> (assuming you want it named /dev/md0 and there isn't one
> already)
>
> Then you can make a filesystem on /dev/md0 and put it in your
> fstab, mount it, and copy data over to it.
>
Thats was my next Q...

> > What I'd like to do when I install bullseye, is use this raid10 for
> > the /home partition in the bullseye install.
>
> The installer will recognize it as an md RAID and can be told that you
> want to use it as-is, or you can destroy it and re-create it without
> data.
>
> -dsr-

Thanks Dan

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242066

On Friday 12 November 2021 08:49:21 Dan Ritter wrote:

> Gene Heskett wrote:
> > The man page we have goes on and on for megabytes without ever
> > giving an example.
> >
> > I thought maybe it could scan for devices so that I could build an
> > mdadm.conf but it wont do a --scan by itself.
>
> You are looking for
>
> mdadm --detail  --scan
>
Null return on stretch version of mdadm. Supposedly up to date as of an 
hour ago.

> It is in that man page, as an example under --detail.

Not in the stretch man page.  And its sounding as if I should do that 
during the bullseye install to get the more capable mdadm, but will the 
devices have the same names? With the reputation for volatility of 
device names a mistake there could destroy 23 years of data.

> > But I don't see an option (or recognize it if it is there) to give
> > it a controller id and let it make a raid10 out of the 4 identical
> > drives it could find there.
> >
> > If there is such a critter, point me at it please.
>
> You have to feed mdadm the drives you want specifically; there's
> no scattershot approach.
>
> Let's say that the drives are /dev/sdf, /dev/sdg, /dev/sdh and
> /dev/sdi.
>
> (You can re-confirm what drive is what via hdparm -i, or
> smartctl.)
>
> If you have data on them, it will be wiped out. You should copy
> off anything important, and then run wipefs on each of them.
>
> Then, creation is
>
> # mdadm -C /dev/md0 --level=10 --raid-devices=4 /dev/sdf /dev/sdg
> /dev/sdh /dev/sdi
>
> (assuming you want it named /dev/md0 and there isn't one
> already)
>
> Then you can make a filesystem on /dev/md0 and put it in your
> fstab, mount it, and copy data over to it.

So mkfs.ext4 /md0 is required, ok

> > What I'd like to do when I install bullseye, is use this raid10 for
> > the /home partition in the bullseye install.
>
> The installer will recognize it as an md RAID and can be told that you
> want to use it as-is, or you can destroy it and re-create it without
> data.
>
> -dsr-
Thanks Dan.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242069

Gene Heskett wrote: 
> On Friday 12 November 2021 08:49:21 Dan Ritter wrote:
> 
> > Gene Heskett wrote:
> > > The man page we have goes on and on for megabytes without ever
> > > giving an example.
> > >
> > > I thought maybe it could scan for devices so that I could build an
> > > mdadm.conf but it wont do a --scan by itself.
> >
> > You are looking for
> >
> > mdadm --detail  --scan
> >
> Null return on stretch version of mdadm. Supposedly up to date as of an 
> hour ago.

That would be expected if you don't have any current mdadm
devices.


> Not in the stretch man page.  And its sounding as if I should do that 
> during the bullseye install to get the more capable mdadm, but will the 
> devices have the same names? With the reputation for volatility of 
> device names a mistake there could destroy 23 years of data.

After you have set them up, mdadm.conf has things like this:

ARRAY /dev/md/0 metadata=1.2 name=debian:0 UUID=aeac6271:676b1852:04f077d6:fcd285d6
ARRAY /dev/md/1 metadata=1.2 name=debian:1 UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce
ARRAY /dev/md/2 metadata=1.2 name=debian:2 UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c

And during boot, the system will look for all drives/partitions that fit
that UUID for assembly, regardless of whether they are currently
named /dev/hdc3,  /dev/sdq, or /dev/nvme0np1.

-dsr-

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

#242074

On Friday 12 November 2021 10:18:07 Dan Ritter wrote:

> Gene Heskett wrote:
> > On Friday 12 November 2021 08:49:21 Dan Ritter wrote:
> > > Gene Heskett wrote:
> > > > The man page we have goes on and on for megabytes without ever
> > > > giving an example.
> > > >
> > > > I thought maybe it could scan for devices so that I could build
> > > > an mdadm.conf but it wont do a --scan by itself.
> > >
> > > You are looking for
> > >
> > > mdadm --detail  --scan
> >
> > Null return on stretch version of mdadm. Supposedly up to date as of
> > an hour ago.
>
> That would be expected if you don't have any current mdadm
> devices.
Explains that, thanks.

> > Not in the stretch man page.  And its sounding as if I should do
> > that during the bullseye install to get the more capable mdadm, but
> > will the devices have the same names? With the reputation for
> > volatility of device names a mistake there could destroy 23 years of
> > data.
>
> After you have set them up, mdadm.conf has things like this:
>
> ARRAY /dev/md/0 metadata=1.2 name=debian:0
> UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1 metadata=1.2
> name=debian:1 UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce ARRAY /dev/md/2
> metadata=1.2 name=debian:2 UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c
That doesn't appear to be true. I have run the create which seemed to be 
ok, then mkfs -text4 /dev/md0, then mounted it at /home2.

But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this:

gene@coyote:~$ cat /etc/mdadm/mdadm.conf
# mdadm.conf
#
# Please refer to mdadm.conf(5) for information about this file.
#

# by default (built-in), scan all partitions (/proc/partitions) and all
# containers for MD superblocks. alternatively, specify devices to scan, 
using
# wildcards if desired.
#DEVICE partitions containers

# automatically tag new arrays as belonging to the local system
HOMEHOST <system>

# instruct the monitoring daemon where to send mail alerts
MAILADDR root

# definitions of existing MD arrays

# This configuration was auto-generated on Sun, 08 Aug 2021 
01:18:22 -0400 by mkconf

Which from your descriptions is not complete. No ARRAY statements at all.
What did I do wrong?

And again, I don't trust UUID's as moving a drive cable to a different 
socket has invalidated the whole lot of them once before. I would much 
rather LABEL the array, and mount it in /etc/fstab by that label.

At the instant its mounted as /dev/md0 to /home2 and looks like an empty 
nearly 2 T-byte drive to an ls -la:

gene@coyote:~$ ls -la /home2
total 24
drwxr-xr-x  3 root root  4096 Nov 12 11:12 .
drwxr-xr-x 29 root root  4096 Nov 12 11:16 ..
drwx------  2 root root 16384 Nov 12 11:12 lost+found

LABEL as I recall is a journalctl function? Does it work on raid10's?
Humm, now:
gene@coyote:~/AppImages$ sudo mdadm --detail  --scan
[sudo] password for gene:
ARRAY /dev/md0 metadata=1.2 name=coyote:0 
UUID=8ad67ef1:a14d63ab:c684ec2b:42a0c011

So I should add that last line to which category in mdadm.conf? And for 
the time being use that UUID in /etc/fstab to mount it to /home2, right?

> And during boot, the system will look for all drives/partitions that
> fit that UUID for assembly, regardless of whether they are currently
> named /dev/hdc3,  /dev/sdq, or /dev/nvme0np1.
>
> -dsr-
Thanks Dan

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242075

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

On 2021-11-12 at 11:42, Gene Heskett wrote:

> On Friday 12 November 2021 10:18:07 Dan Ritter wrote:
> 
>> Gene Heskett wrote:

>> > Not in the stretch man page.  And its sounding as if I should do
>> > that during the bullseye install to get the more capable mdadm, but
>> > will the devices have the same names? With the reputation for
>> > volatility of device names a mistake there could destroy 23 years of
>> > data.
>>
>> After you have set them up, mdadm.conf has things like this:
>>
>> ARRAY /dev/md/0 metadata=1.2 name=debian:0
>> UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1 metadata=1.2
>> name=debian:1 UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce ARRAY /dev/md/2
>> metadata=1.2 name=debian:2 UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c
> That doesn't appear to be true. I have run the create which seemed to be 
> ok, then mkfs -text4 /dev/md0, then mounted it at /home2.
> 
> But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this:

<snip>

> Which from your descriptions is not complete. No ARRAY statements at
> all. What did I do wrong?

Not sure if you did anything wrong, but now that you've done the
--create operation, you might try running

# mdadm --detail --scan

again. You might see that it now outputs definition lines like the ones
Dan presented as examples; if so, you can append those lines to
mdadm.conf, and if I'm not mistaken the result should (in theory) be valid.

> And again, I don't trust UUID's as moving a drive cable to a
> different socket has invalidated the whole lot of them once before.

Eh? That doesn't make any sense at all. The UUID is supposed to be
stored *on* the drive, so that it is independent of connection. I can
testify that this has been the case in my experience with mdadm
RAID-array UUIDs.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man.         -- George Bernard Shaw

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

#242082

On Friday 12 November 2021 11:49:29 The Wanderer wrote:

> On 2021-11-12 at 11:42, Gene Heskett wrote:
> > On Friday 12 November 2021 10:18:07 Dan Ritter wrote:
> >> Gene Heskett wrote:
> >> > Not in the stretch man page.  And its sounding as if I should do
> >> > that during the bullseye install to get the more capable mdadm,
> >> > but will the devices have the same names? With the reputation for
> >> > volatility of device names a mistake there could destroy 23 years
> >> > of data.
> >>
> >> After you have set them up, mdadm.conf has things like this:
> >>
> >> ARRAY /dev/md/0 metadata=1.2 name=debian:0
> >> UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1
> >> metadata=1.2 name=debian:1 UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce
> >> ARRAY /dev/md/2 metadata=1.2 name=debian:2
> >> UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c
> >
> > That doesn't appear to be true. I have run the create which seemed
> > to be ok, then mkfs -text4 /dev/md0, then mounted it at /home2.
> >
> > But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this:
>
> <snip>
>
> > Which from your descriptions is not complete. No ARRAY statements at
> > all. What did I do wrong?
>
> Not sure if you did anything wrong, but now that you've done the
> --create operation, you might try running
>
> # mdadm --detail --scan
>
> again. You might see that it now outputs definition lines like the
> ones Dan presented as examples; if so, you can append those lines to
> mdadm.conf, and if I'm not mistaken the result should (in theory) be
> valid.
>
> > And again, I don't trust UUID's as moving a drive cable to a
> > different socket has invalidated the whole lot of them once before.
>
> Eh? That doesn't make any sense at all. The UUID is supposed to be
> stored *on* the drive, so that it is independent of connection. I can
> testify that this has been the case in my experience with mdadm
> RAID-array UUIDs.

Does re-running blockid rewrite those?

I recall I did that when the moved cable didn't mount on reboot.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242121

Hello,

On Fri, Nov 12, 2021 at 11:42:32AM -0500, Gene Heskett wrote:
> On Friday 12 November 2021 10:18:07 Dan Ritter wrote:
> > After you have set them up, mdadm.conf has things like this:
> >
> > ARRAY /dev/md/0 metadata=1.2 name=debian:0
> > UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1 metadata=1.2
> > name=debian:1 UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce ARRAY /dev/md/2
> > metadata=1.2 name=debian:2 UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c
> That doesn't appear to be true. I have run the create which seemed to be 
> ok, then mkfs -text4 /dev/md0, then mounted it at /home2.
> 
> But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this:

You don't need to list the arrays in /etc/mdadm/mdadm.conf since
udev assembles arrays based on the metadata that exists on each
device. It's fine for there to be no ARRAY lines in there. These
days it's only really useful in recovery situations or for setting
some special options per array.

You can still do the

# mdadm --detail --scan

to find the lines to put in the mdadm.conf yourself.

> And again, I don't trust UUID's as moving a drive cable to a different 
> socket has invalidated the whole lot of them once before. I would much 
> rather LABEL the array, and mount it in /etc/fstab by that label.

There may be some conceptual error here. The UUIDs you would put in
/etc/fstab are FILESYSTEM UUIDs, not array UUIDs. Lots of things in
computing have UUIDs.

After you put a filesystem on each array you can refer to the
FILESYSTEM label in /etc/fstab. These labels are internal to each
filesystem and nothing to do with any layer below, such as md.

> LABEL as I recall is a journalctl function? Does it work on raid10's?

Filesystem labels have nothing to do with journalctl. And I don't
know what you mean by them being "a function".

Again, filesystems (can) have labels, these are a filesystem detail,
RAID doesn't know nor care.

> Humm, now:
> gene@coyote:~/AppImages$ sudo mdadm --detail  --scan
> [sudo] password for gene:
> ARRAY /dev/md0 metadata=1.2 name=coyote:0 
> UUID=8ad67ef1:a14d63ab:c684ec2b:42a0c011
> 
> So I should add that last line to which category in mdadm.conf?

mdamd.conf doesn't have categories. You would just append that line
at the end, ensuring it is all on one line.

> And for the time being use that UUID in /etc/fstab to mount it to /home2, right?

No, because that is not a filesystem UUID. And you said you wanted
to mount the filesystem by label anyway. So put whatever label you
chose when you did mkfs (or when you did it form the installer).

In a later email you did this:

# mkfs -Text4 …

and got an obscure error.

That's because you did "-T" instead of "-t", which means something
completely different. You may want to get into the habit of doing:

# mkfs.ext4 …

instead as it's clearer and easier to remember.

Cheers,
Andy

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

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

#242123

On Saturday 13 November 2021 07:33:49 Andy Smith wrote:

> Hello,
>
> On Fri, Nov 12, 2021 at 11:42:32AM -0500, Gene Heskett wrote:
> > On Friday 12 November 2021 10:18:07 Dan Ritter wrote:
> > > After you have set them up, mdadm.conf has things like this:
> > >
> > > ARRAY /dev/md/0 metadata=1.2 name=debian:0
> > > UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1
> > > metadata=1.2 name=debian:1
> > > UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce ARRAY /dev/md/2
> > > metadata=1.2 name=debian:2
> > > UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c
> >
> > That doesn't appear to be true. I have run the create which seemed
> > to be ok, then mkfs -text4 /dev/md0, then mounted it at /home2.
> >
> > But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this:
>
> You don't need to list the arrays in /etc/mdadm/mdadm.conf since
> udev assembles arrays based on the metadata that exists on each
> device. It's fine for there to be no ARRAY lines in there. These
> days it's only really useful in recovery situations or for setting
> some special options per array.
>
> You can still do the
>
> # mdadm --detail --scan
>
> to find the lines to put in the mdadm.conf yourself.
>
> > And again, I don't trust UUID's as moving a drive cable to a
> > different socket has invalidated the whole lot of them once before.
> > I would much rather LABEL the array, and mount it in /etc/fstab by
> > that label.
>
> There may be some conceptual error here. The UUIDs you would put in
> /etc/fstab are FILESYSTEM UUIDs, not array UUIDs. Lots of things in
> computing have UUIDs.
>
> After you put a filesystem on each array you can refer to the
> FILESYSTEM label in /etc/fstab. These labels are internal to each
> filesystem and nothing to do with any layer below, such as md.
>
> > LABEL as I recall is a journalctl function? Does it work on
> > raid10's?
Its been quite a while but fdisk didn't do labels, but I see it grew that 
along with GPT tables. But back in the day, ISTR adding a label to a 
drive was done by journalctl and I'd call adding a label to a drive a 
function.
> Filesystem labels have nothing to do with journalctl. And I don't
> know what you mean by them being "a function".
>
> Again, filesystems (can) have labels, these are a filesystem detail,
> RAID doesn't know nor care.

So I see, but the names for md0 and md1 are shown as hostname:0 and 
hostname:1

> > Humm, now:
> > gene@coyote:~/AppImages$ sudo mdadm --detail  --scan
> > [sudo] password for gene:
> > ARRAY /dev/md0 metadata=1.2 name=coyote:0
> > UUID=8ad67ef1:a14d63ab:c684ec2b:42a0c011
> >
> > So I should add that last line to which category in mdadm.conf?
>
> mdamd.conf doesn't have categories. You would just append that line
> at the end, ensuring it is all on one line.

Yup, that was kmails word wrap. I forgot to turn it off when I pasted 
that.
>
> > And for the time being use that UUID in /etc/fstab to mount it to
> > /home2, right?
>
> No, because that is not a filesystem UUID. And you said you wanted
> to mount the filesystem by label anyway. So put whatever label you
> chose when you did mkfs (or when you did it form the installer).
>
> In a later email you did this:
>
> # mkfs -Text4 …
>
> and got an obscure error.
>
> That's because you did "-T" instead of "-t", which means something
> completely different. You may want to get into the habit of doing:
>
> # mkfs.ext4 …
>
> instead as it's clearer and easier to remember.
>
> Cheers,
> Andy

Thanks Andy.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242125

On Saturday 13 November 2021 07:33:49 Andy Smith wrote:

> Hello,
>
> On Fri, Nov 12, 2021 at 11:42:32AM -0500, Gene Heskett wrote:
> > On Friday 12 November 2021 10:18:07 Dan Ritter wrote:
> > > After you have set them up, mdadm.conf has things like this:
> > >
> > > ARRAY /dev/md/0 metadata=1.2 name=debian:0
> > > UUID=aeac6271:676b1852:04f077d6:fcd285d6 ARRAY /dev/md/1
> > > metadata=1.2 name=debian:1
> > > UUID=d74ff881:2e966c37:ec6ef1ec:75b8cdce ARRAY /dev/md/2
> > > metadata=1.2 name=debian:2
> > > UUID=7c56166b:0d5aed8b:a9d03c45:e9b8080c
> >
> > That doesn't appear to be true. I have run the create which seemed
> > to be ok, then mkfs -text4 /dev/md0, then mounted it at /home2.
> >
> > But /etc/mdadm/mdadm.conf doesn't yet have any of that, only this:
>
> You don't need to list the arrays in /etc/mdadm/mdadm.conf since
> udev assembles arrays based on the metadata that exists on each
> device. It's fine for there to be no ARRAY lines in there. These
> days it's only really useful in recovery situations or for setting
> some special options per array.
>
> You can still do the
>
> # mdadm --detail --scan
>
> to find the lines to put in the mdadm.conf yourself.
>
> > And again, I don't trust UUID's as moving a drive cable to a
> > different socket has invalidated the whole lot of them once before.
> > I would much rather LABEL the array, and mount it in /etc/fstab by
> > that label.
>
> There may be some conceptual error here. The UUIDs you would put in
> /etc/fstab are FILESYSTEM UUIDs, not array UUIDs. Lots of things in
> computing have UUIDs.
>
> After you put a filesystem on each array you can refer to the
> FILESYSTEM label in /etc/fstab. These labels are internal to each
> filesystem and nothing to do with any layer below, such as md.
>
> > LABEL as I recall is a journalctl function? Does it work on
> > raid10's?
>
> Filesystem labels have nothing to do with journalctl. And I don't
> know what you mean by them being "a function".
>
> Again, filesystems (can) have labels, these are a filesystem detail,
> RAID doesn't know nor care.
>
> > Humm, now:
> > gene@coyote:~/AppImages$ sudo mdadm --detail  --scan
> > [sudo] password for gene:
> > ARRAY /dev/md0 metadata=1.2 name=coyote:0
> > UUID=8ad67ef1:a14d63ab:c684ec2b:42a0c011
> >
> > So I should add that last line to which category in mdadm.conf?
>
> mdamd.conf doesn't have categories. You would just append that line
> at the end, ensuring it is all on one line.

And I just found I didn't have an mdadm.conf, and I had figure a new -C would have created it. But 
the last time I ran it, no mdadm.conf was created.

So I made a 2 liner from the --scan output. What else should it have?
ARRAY /dev/md0 metadata=1.2 name=coyote:0 UUID=3d5a3621:c0e32c8a:e3f7ebb3:318edbfb
ARRAY /dev/md1 metadata=1.2 name=coyote:1 UUID=ddb6ffa2:e068b701:f316cc5f:83938a13
You indicate that these are not the UUID's to put in fstab, or do I 
miss-understand?

Experiment after putting those UUID's into fstab
@coyote:etc$ mount /home2
mount: can't find UUID=3d5a3621:c0e32c8a:e3f7ebb3:318edbfb
root@coyote:etc$ mount /snapshot
mount: can't find UUID=ddb6ffa2:e068b701:f316cc5f:83938a13
root@coyote:etc$ mount /dev/md0 -text4 /home2
root@coyote:etc$ mount /dev/md1 -text4 /snapshot
@coyote:etc$ df
Filesystem      1K-blocks      Used  Available Use% Mounted on
udev             16380992         0   16380992   0% /dev
tmpfs             3280240      9516    3270724   1% /run
/dev/sda5      1857400436 317616932 1445362976  19% /
tmpfs            16401180         0   16401180   0% /dev/shm
tmpfs                5120         4       5116   1% /run/lock
tmpfs            16401180         0   16401180   0% /sys/fs/cgroup
/dev/sdb1       229699916     61472  217900640   1% /sdb
/dev/sdc1      1921802432 879249728  944860648  49% /amandatapes
/dev/sda3        47799020   6444388   38896828  15% /var
/dev/sda1          944120    188864     690080  22% /boot
tmpfs             3280236         4    3280232   1% /run/user/1000
/dev/md0       1812963068     77852 1720721940   1% /home2
/dev/md1        100203600     61464   95009032   1% /snapshot

Which nicely demos why I don't trust UUID's. But, why didn't it work?
Why did I have to revert to md0/md1 names to remount them?

> > And for the time being use that UUID in /etc/fstab to mount it to
> > /home2, right?
>
> No, because that is not a filesystem UUID. And you said you wanted
> to mount the filesystem by label anyway. So put whatever label you
> chose when you did mkfs (or when you did it from the installer).

I didn't know mkfs can do labels.

> In a later email you did this:
>
> # mkfs -Text4 …
>
> and got an obscure error.
>
> That's because you did "-T" instead of "-t", which means something
> completely different. You may want to get into the habit of doing:
>
> # mkfs.ext4 …
>
> instead as it's clearer and easier to remember.
>
> Cheers,
> Andy


Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242128

On Sat, Nov 13, 2021 at 08:39:15AM -0500, Gene Heskett wrote:
> And I just found I didn't have an mdadm.conf, and I had figure a
> new -C would have created it. But the last time I ran it, no
> mdadm.conf was created.
> 
> So I made a 2 liner from the --scan output. What else should it have?

It can be empty or missing. So the answer to your question is,
"nothing". Mine have this:

    CREATE owner=root group=disk mode=0660 auto=yes
    HOMEHOST <system>
    MAILADDR root

"man mdadm.conf" should tell you what each of those things does.

> ARRAY /dev/md0 metadata=1.2 name=coyote:0 UUID=3d5a3621:c0e32c8a:e3f7ebb3:318edbfb
> ARRAY /dev/md1 metadata=1.2 name=coyote:1 UUID=ddb6ffa2:e068b701:f316cc5f:83938a13
> You indicate that these are not the UUID's to put in fstab, or do I 
> miss-understand?

You've clearly read the email you are replying to which said "array
UUIDs are not filesystem UUIDs and do not go in fstab", so I don't
know why you are asking the same thing again.

Array UUIDs are not filesystem UUIDs and do not go in fstab. What is
unclear about this statement that you felt the need to do it anyway?

> Experiment after putting those UUID's into fstab

I still don't understand why, after reading me tell you that they
don't go in fstab, you then put them in fstab.

> @coyote:etc$ mount /home2
> mount: can't find UUID=3d5a3621:c0e32c8a:e3f7ebb3:318edbfb

Guess what - if you put arbitrary nonsense in /etc/fstab, it won't
work.

> root@coyote:etc$ mount /snapshot

> Which nicely demos why I don't trust UUID's.

All you've demonstrated is that if you put garbage in your fstab
then it won't work.

But no one cares whether you "trust UUIDs" or not. You already said
that you wanted to use fs labels, not UUIDs. Great. Do that then.

> But, why didn't it work?

I'm at a loss as to why you have to ask. You are replying to an
email that tells you not to put nonsense in your fstab, you then
show a transcript of you putting nonsense in your fstab, and then
ask why it didn't work. You even, further down, quote me telling you
not to put array UUIDs in your fstab. Is this performance art?

> Why did I have to revert to md0/md1 names to remount them?

'cos given a choice between nonsense and a device node, mounting a
device node is more likely to work.

> > > And for the time being use that UUID in /etc/fstab to mount it to
> > > /home2, right?
> >
> > No, because that is not a filesystem UUID. And you said you wanted
> > to mount the filesystem by label anyway. So put whatever label you
> > chose when you did mkfs (or when you did it from the installer).
> 
> I didn't know mkfs can do labels.

If only any of these tools had a man page.

$ man mkfs.ext4

[…]

       -L new-volume-label
         Set the volume label for the filesystem to
         new-volume-label.  The maximum length of the volume label
         is 16 bytes.

Andy

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

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

#242129

On Saturday 13 November 2021 08:58:15 Andy Smith wrote:

> On Sat, Nov 13, 2021 at 08:39:15AM -0500, Gene Heskett wrote:
> > And I just found I didn't have an mdadm.conf, and I had figure a
> > new -C would have created it. But the last time I ran it, no
> > mdadm.conf was created.
> >
> > So I made a 2 liner from the --scan output. What else should it
> > have?
>
> It can be empty or missing. So the answer to your question is,
> "nothing". Mine have this:
>
>     CREATE owner=root group=disk mode=0660 auto=yes
>     HOMEHOST <system>
>     MAILADDR root
>
> "man mdadm.conf" should tell you what each of those things does.
>
> > ARRAY /dev/md0 metadata=1.2 name=coyote:0
> > UUID=3d5a3621:c0e32c8a:e3f7ebb3:318edbfb ARRAY /dev/md1 metadata=1.2
> > name=coyote:1 UUID=ddb6ffa2:e068b701:f316cc5f:83938a13 You indicate
> > that these are not the UUID's to put in fstab, or do I
> > miss-understand?
>
> You've clearly read the email you are replying to which said "array
> UUIDs are not filesystem UUIDs and do not go in fstab", so I don't
> know why you are asking the same thing again.
>
> Array UUIDs are not filesystem UUIDs and do not go in fstab. What is
> unclear about this statement that you felt the need to do it anyway?
>
> > Experiment after putting those UUID's into fstab
>
> I still don't understand why, after reading me tell you that they
> don't go in fstab, you then put them in fstab.
>
> > @coyote:etc$ mount /home2
> > mount: can't find UUID=3d5a3621:c0e32c8a:e3f7ebb3:318edbfb
>
> Guess what - if you put arbitrary nonsense in /etc/fstab, it won't
> work.
>
> > root@coyote:etc$ mount /snapshot
> >
> > Which nicely demos why I don't trust UUID's.
>
> All you've demonstrated is that if you put garbage in your fstab
> then it won't work.
>
> But no one cares whether you "trust UUIDs" or not. You already said
> that you wanted to use fs labels, not UUIDs. Great. Do that then.

I just did. Works.

> > But, why didn't it work?
>
> I'm at a loss as to why you have to ask. You are replying to an
> email that tells you not to put nonsense in your fstab, you then
> show a transcript of you putting nonsense in your fstab, and then
> ask why it didn't work. You even, further down, quote me telling you
> not to put array UUIDs in your fstab. Is this performance art?
>
> > Why did I have to revert to md0/md1 names to remount them?
>
> 'cos given a choice between nonsense and a device node, mounting a
> device node is more likely to work.

So I've changed it. I guess the next question is why does
 --scan even report it if its no good? blkid returns different UUID's.
Would those work?

Generally moot now, I just umounted them, LABEL'd them with mkfs.ext4 -L 
and can mount by labels now.

> > > > And for the time being use that UUID in /etc/fstab to mount it
> > > > to /home2, right?
> > >
> > > No, because that is not a filesystem UUID. And you said you wanted
> > > to mount the filesystem by label anyway. So put whatever label you
> > > chose when you did mkfs (or when you did it from the installer).
> >
> > I didn't know mkfs can do labels.
>
> If only any of these tools had a man page.
>
> $ man mkfs.ext4

That is an alias to mkfs which covers all.

> […]
>
>        -L new-volume-label
>          Set the volume label for the filesystem to
>          new-volume-label.  The maximum length of the volume label
>          is 16 bytes.
>
> Andy

Thanks Andy.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242130

On Sat, Nov 13, 2021 at 09:28:46AM -0500, Gene Heskett wrote:
> the next question is why does
>  --scan even report it if its no good? blkid returns different UUID's.
> Would those work?

Why are you under the impression that every single thing called a
UUID must work as a *filesystem* UUID?

Lots of things have a UUID. Universally Unique IDentifiers are
useful things. But not every UUID is a filesystem UUID. This is like
taking the VIN from your car and putting it in fstab then asking why
it didn't mount your car as a filesystem.

MD arrays aren't filesystems, they are block devices.

"blkid" does report filesystem UUIDs, according to its manpage, so
the answer to that one is is yes.

Andy

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

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

#242134

On Sat 13 Nov 2021 at 14:51:05 (+0000), Andy Smith wrote:
> On Sat, Nov 13, 2021 at 09:28:46AM -0500, Gene Heskett wrote:
> > the next question is why does
> >  --scan even report it if its no good? blkid returns different UUID's.
> > Would those work?
> 
> Why are you under the impression that every single thing called a
> UUID must work as a *filesystem* UUID?
> 
> Lots of things have a UUID. Universally Unique IDentifiers are
> useful things. But not every UUID is a filesystem UUID. This is like
> taking the VIN from your car and putting it in fstab then asking why
> it didn't mount your car as a filesystem.
> 
> MD arrays aren't filesystems, they are block devices.
> 
> "blkid" does report filesystem UUIDs, according to its manpage, so
> the answer to that one is is yes.

This is, of course, the explanation for posts such as:
https://lists.debian.org/debian-user/2018/01/msg00787.html
https://lists.debian.org/debian-user/2018/01/msg00791.html
https://lists.debian.org/debian-user/2020/02/msg00155.html

Because you have to dream up (PART)LABELs yourself, it's easy
to recognise them in any context. Because UUIDs mean nothing
to humans, and are ubiquitous everywhere (tautological, I know),
you have to understand which ones have meaning in which context,
otherwise it's tempting just to throw your hands in the air
and say they keep changing.

Cheers,
David.

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

#242141

On Saturday 13 November 2021 09:51:05 Andy Smith wrote:

> On Sat, Nov 13, 2021 at 09:28:46AM -0500, Gene Heskett wrote:
> > the next question is why does
> >  --scan even report it if its no good? blkid returns different
> > UUID's. Would those work?
>
> Why are you under the impression that every single thing called a
> UUID must work as a *filesystem* UUID?
>
> Lots of things have a UUID. Universally Unique IDentifiers are
> useful things. But not every UUID is a filesystem UUID. This is like
> taking the VIN from your car and putting it in fstab then asking why
> it didn't mount your car as a filesystem.
>
> MD arrays aren't filesystems, they are block devices.
>
> "blkid" does report filesystem UUIDs, according to its manpage, so
> the answer to that one is is yes.
>
> Andy

I wouldn't argue near as loud if it hadn't already been proven to me that 
what you call filesystem UUID's are volatile. It happened when I moved a 
drive from sda to sdd several years ago. Getting ready to switch to the 
next version of debian because I always install to a new drive, which I 
installed wheezy on, then put the old drive back in on a different sata 
port to get my data copied to the new drive. No boot but single. It took 
me 3 days to build an fstab that mounted everything by Labels. When I 
finally had a working system again, I ran blkid again, and with the same 
drives except the boot drive re-arranged, every UUID blkid reported was 
different from what it was in the now commented out lines in fstab.

The downside of now using mkfs to install a label, I didn't use it then 
but something else, but mkfs also wipes the drive, so in this case I 
hadn't moved anything to it, so I lost nothing reformating to install 
the label. The utility, if it wasn't journal-something or other I don't 
recall, but it could label a partition that already had content, without 
losing that data. 

rant on:

That isn't moving forward in any field including computers. This stretch 
install uses UUID's to mount the system, and bullseye might also be left 
that way, but you can take it to the bank that anything associated with 
amanda is mounted by labels.  Its simply too big a risk to do UUID 
mounts with something that important.

I wrote a wrapper for amanda, and its data is several gigs that are also 
backed up after amanda is done. I can lose the boot drive, get in the 
pickup and go get a fresh one, put it in and re-install to bare metal, 
using a net-install dvd, get the amanda from the repo's and with 
amanda's backups, have this system restored to about 2:20 this morning 
in time to cook dinner.

Computers were designed to work for you, not against you.  This email, 
minus the typing I'm doing, will be sent with one click, and one more 
takes me to the next unread message. If I can answer, one more click 
selects a pm or list reply. Everything else is being done by scripts I 
wrote, because computers are supposed to work "for you", not "make work" 
for you.
/rant off:

Thanks Andy.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242149

On Sat, Nov 13, 2021 at 01:14:56PM -0500, Gene Heskett wrote:
> I wouldn't argue near as loud if it hadn't already been proven to me that 
> what you call filesystem UUID's are volatile.

What I and everyone else call filesystem UUIDs do not change unless
you force them to change, because they only exist inside the
filesystem. It seems far more likely that you are confused, in the
same way you have been confused throughout this whole thread. If
you've got something outside of your control scribbling in your
filesystems then that is a very serious bug.

I think you are and have been confused between different things that
have UUIDs. Filesystems, MD arrays, GPT partitions and lots of other
things all can have UUIDs.

In this thread you have repeatedly shown that you don't understand
the difference between those UUIDs and have tried to use them in
your fstab, so it seems far more likely that any prior issue you
have had with filesystem UUIDs is going to be down to similar
confusions and not some serious bug.

> It happened when I moved a drive from sda to sdd several years
> ago.

Barring some strange bug that only you have ever seen, it is not
possible, so I believe you are mistaken. This is going to be
another one of those things where you swear software behaved in
incredibly improbable ways, you are asked to reproduce it and can't.
I will gladly eat humble pie if you can reproduce this one and show
us. I will be excited for the bug report we can make together,
because that would be a real doozy.

Like that time you said that having an IPv6 address configured
prevented you from compiling some software, a claim you kept
repeating in multiple unrelated threads any time IPv6 was mentioned,
until you were asked to reproduce the issue and couldn't.

We all make mistakes from time to time but filling the archives with
bold assertions like "filesystem UUIDs are volatile" I think would
come under the category of an extraordinary claim that would require
extraordinary proof.

> Getting ready to switch to the next version of debian because I
> always install to a new drive, which I installed wheezy on, then
> put the old drive back in on a different sata port to get my data
> copied to the new drive. No boot but single. It took me 3 days to
> build an fstab that mounted everything by Labels. When I finally
> had a working system again, I ran blkid again, and with the same
> drives except the boot drive re-arranged, every UUID blkid
> reported was different from what it was in the now commented out
> lines in fstab.

"blkid" also reports things called PARTUUIDs, so I think this is
explained by it doing that, and you being confused. Nothing you have
described could cause a filesystem UUID to change.

> The downside of now using mkfs to install a label, I didn't use it then 
> but something else, but mkfs also wipes the drive, so in this case I 
> hadn't moved anything to it, so I lost nothing reformating to install 
> the label. The utility, if it wasn't journal-something or other I don't 
> recall, but it could label a partition that already had content, without 
> losing that data. 

You have not once in this thread asked how to label an existing
filesystem without re-creating it. Although you don't even need to
ask us, because:

    https://lmgtfy.app/?q=how+do+I+label+an+ext4+filesystem

So instead of doing a trivial search, or even asking, you just
assume that it can't be done and have a nice old rant. Weird flex,
but OK.

The above is for ext* filesystems; other filesystems have their own
tools for changing the label. A similar search will find them, too.

People have been putting and changing labels on filesystem in Linux
for decades. It's well understood and well documented. If you look.
First you complain that fs UUIDs are volatile, now you complain that
fs labelling is hard without even doing the most basic research. At
least these topics have been adequately covered, so unwary searchers
are unlikely to stumble upon this thread in future and be led down a
very long garden path by the bizarre claims within.

> Its simply too big a risk to do UUID mounts with something that
> important.

For you, maybe, but I guarantee this is down to some confusion on
your part. Confusion is still a valid reason to shy away from
something, especially when there is an alternate approach (mount by
label) that works much better for you, but blaming it on
mysteriously changing UUIDs and/or the mdadm man pages is not
helping.

Andy

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

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

#242153

On Saturday 13 November 2021 15:44:35 Andy Smith wrote:

> On Sat, Nov 13, 2021 at 01:14:56PM -0500, Gene Heskett wrote:
> > I wouldn't argue near as loud if it hadn't already been proven to me
> > that what you call filesystem UUID's are volatile.
>
> What I and everyone else call filesystem UUIDs do not change unless
> you force them to change, because they only exist inside the
> filesystem. It seems far more likely that you are confused, in the
> same way you have been confused throughout this whole thread. If
> you've got something outside of your control scribbling in your
> filesystems then that is a very serious bug.
>
> I think you are and have been confused between different things that
> have UUIDs. Filesystems, MD arrays, GPT partitions and lots of other
> things all can have UUIDs.
>
> In this thread you have repeatedly shown that you don't understand
> the difference between those UUIDs and have tried to use them in
> your fstab, so it seems far more likely that any prior issue you
> have had with filesystem UUIDs is going to be down to similar
> confusions and not some serious bug.
>
> > It happened when I moved a drive from sda to sdd several years
> > ago.
>
> Barring some strange bug that only you have ever seen, it is not
> possible, so I believe you are mistaken. This is going to be
> another one of those things where you swear software behaved in
> incredibly improbable ways, you are asked to reproduce it and can't.
> I will gladly eat humble pie if you can reproduce this one and show
> us. I will be excited for the bug report we can make together,
> because that would be a real doozy.
>
> Like that time you said that having an IPv6 address configured
> prevented you from compiling some software, a claim you kept
> repeating in multiple unrelated threads any time IPv6 was mentioned,
> until you were asked to reproduce the issue and couldn't.
>
> We all make mistakes from time to time but filling the archives with
> bold assertions like "filesystem UUIDs are volatile" I think would
> come under the category of an extraordinary claim that would require
> extraordinary proof.
>
> > Getting ready to switch to the next version of debian because I
> > always install to a new drive, which I installed wheezy on, then
> > put the old drive back in on a different sata port to get my data
> > copied to the new drive. No boot but single. It took me 3 days to
> > build an fstab that mounted everything by Labels. When I finally
> > had a working system again, I ran blkid again, and with the same
> > drives except the boot drive re-arranged, every UUID blkid
> > reported was different from what it was in the now commented out
> > lines in fstab.
>
> "blkid" also reports things called PARTUUIDs, so I think this is
> explained by it doing that, and you being confused. Nothing you have
> described could cause a filesystem UUID to change.
>
> > The downside of now using mkfs to install a label, I didn't use it
> > then but something else, but mkfs also wipes the drive, so in this
> > case I hadn't moved anything to it, so I lost nothing reformating to
> > install the label. The utility, if it wasn't journal-something or
> > other I don't recall, but it could label a partition that already
> > had content, without losing that data.
>
> You have not once in this thread asked how to label an existing
> filesystem without re-creating it. Although you don't even need to
> ask us, because:
>
>     https://lmgtfy.app/?q=how+do+I+label+an+ext4+filesystem
>
> So instead of doing a trivial search, or even asking, you just
> assume that it can't be done and have a nice old rant. Weird flex,
> but OK.
>
> The above is for ext* filesystems; other filesystems have their own
> tools for changing the label. A similar search will find them, too.
>
> People have been putting and changing labels on filesystem in Linux
> for decades. It's well understood and well documented. If you look.
> First you complain that fs UUIDs are volatile, now you complain that
> fs labelling is hard without even doing the most basic research. At
> least these topics have been adequately covered, so unwary searchers
> are unlikely to stumble upon this thread in future and be led down a
> very long garden path by the bizarre claims within.
>
> > Its simply too big a risk to do UUID mounts with something that
> > important.
>
> For you, maybe, but I guarantee this is down to some confusion on
> your part. Confusion is still a valid reason to shy away from
> something, especially when there is an alternate approach (mount by
> label) that works much better for you, but blaming it on
> mysteriously changing UUIDs and/or the mdadm man pages is not
> helping.
>
> Andy
Wordwrap off. So which of these various UUID's is actually valid in an fstab?

root@coyote:etc$ blkid
/dev/sda1: LABEL="stretchboot" UUID="06aa3215-a6a6-4fbb-86ca-186c47e1334c" TYPE="ext4" PARTUUID="6603f591-01"
/dev/sda2: UUID="8b675a91-5aa5-401b-bf50-d8afc3e8115a" TYPE="swap" PARTUUID="6603f591-02"
/dev/sda3: LABEL="stretchvar" UUID="ee491e5c-7394-434f-b50a-f4354f6c9869" TYPE="ext4" PARTUUID="6603f591-03"
/dev/sda5: UUID="0e698024-1cf3-4dbc-812d-10552c01caab" TYPE="ext4" PARTUUID="6603f591-05"
/dev/sdb1: LABEL="adumps" UUID="4982ee4c-58c4-4d2b-b9d5-69344c3cb090" TYPE="ext4" PARTUUID="3bb7fc74-01"
/dev/sdc1: LABEL="amandatapes-2T" UUID="3b6848c1-7b09-43be-a7aa-ae63d82f5f26" TYPE="ext4" PARTUUID="5997197d-01"
/dev/sde1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="9cd6d3b5-6d13-8d46-a7e6-6f9847846d24" LABEL="coyote:0" 
TYPE="linux_raid_member"
/dev/sde2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="64609477-3041-8169-feab-73809dd337c6" LABEL="coyote:1" 
TYPE="linux_raid_member"
/dev/sdg1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="38030389-42bc-f933-3945-8b22db9de87e" LABEL="coyote:0" 
TYPE="linux_raid_member"
/dev/sdg2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="dfd980a3-a155-4f50-f82d-02cbbe289891" LABEL="coyote:1" 
TYPE="linux_raid_member"
/dev/sdh1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="ef0ffd69-5ce4-9629-ccd4-81b1f6431571" LABEL="coyote:0" 
TYPE="linux_raid_member"
/dev/sdh2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="b4d25ae6-fc68-1ce5-a08b-92df22c9030b" LABEL="coyote:1" 
TYPE="linux_raid_member"
/dev/sdf1: UUID="3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb" UUID_SUB="baca3a30-e9a5-f5e1-57e1-c197252c3500" LABEL="coyote:0" 
TYPE="linux_raid_member"
/dev/sdf2: UUID="ddb6ffa2-e068-b701-f316-cc5f83938a13" UUID_SUB="ff02585f-cafc-2d7a-3780-6cba4b48b0cb" LABEL="coyote:1" 
TYPE="linux_raid_member"
/dev/md1: LABEL="snapshot" UUID="733718b2-e7f8-4b00-a390-264e5c73c453" TYPE="ext4"
/dev/md0: LABEL="home2" UUID="708320b3-10af-4c15-b5b1-a9ff7be06d99" TYPE="ext4"

there are UUID's, PARTUUID's and UUID_SUB's in the above blkid output.

Thanks Andy.

Cheers, Gene Heskett.
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>

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

#242155

On Sat, 13 Nov 2021 16:57:01 -0500
Gene Heskett <gheskett@shentel.net> wrote:

> So which of these various UUID's is actually valid in an fstab

Thanks, Andy. This is nice to know about.

Gene, the answer is, anythng the TYPE of which is a valid file system.
Try, e.g.:

blkid | grep -E -i \(ext\|ntfs\|fat\)

And probably others I don't have. For a list of file systems your
kernel supports, run

cat /proc/filesystems

and see the discussion of -t in man 8 mount.

-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

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

#242156

On Sat, Nov 13, 2021 at 04:06:43PM -0700, Charles Curley wrote:
> On Sat, 13 Nov 2021 16:57:01 -0500
> Gene Heskett <gheskett@shentel.net> wrote:
> 
> > So which of these various UUID's is actually valid in an fstab
> 
> Thanks, Andy. This is nice to know about.
> 
> Gene, the answer is, anythng the TYPE of which is a valid file system.
> Try, e.g.:
> 
> blkid | grep -E -i \(ext\|ntfs\|fat\)

lsblk is a lot easier and prettier for this purpose.

unicorn:~$ sudo lsblk -o +UUID
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT UUID
sda      8:0    0 931.5G  0 disk            
├─sda1   8:1    0   260M  0 part /boot/efi  4C30-7972
├─sda2   8:2    0    16M  0 part            
├─sda3   8:3    0  92.2G  0 part            7294B93794B8FEA3
├─sda4   8:4    0   980M  0 part            609E71C79E71966E
├─sda5   8:5    0  11.5G  0 part            6858F6A458F66FE4
├─sda6   8:6    0  11.2G  0 part [SWAP]     08c87bdb-17f4-40ab-9b2f-5cb2f29149fb
├─sda7   8:7    0  23.3G  0 part /          c4691ccb-2090-491e-8e82-d7cc822db04a
├─sda8   8:8    0  23.3G  0 part /home      19fb397b-a113-4536-a03d-d60e176cbfdf
└─sda9   8:9    0 651.9G  0 part /stuff     95058c4a-44e2-4a90-87b5-2a5fe40d3cdb
sr0     11:0    1 418.7M  0 rom

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

Page 1 of 4  [1] 2 3 4  Next page →

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

csiph-web