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

Where do I find the definitive man page for mdadm?

Started by	Gene Heskett <gheskett@shentel.net>
First post	2021-11-12 14:10 +0100
Last post	2021-11-12 16:10 +0100
Articles	20 on this page of 65 — 10 participants

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

  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 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

#242158

From	Gene Heskett <gheskett@shentel.net>
Date	2021-11-14 01:30 +0100
Message-ID	<Djbzc-mx-3@gated-at.bofh.it>
In reply to	#242156

On Saturday 13 November 2021 18:37:34 Greg Wooledge wrote:

> 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
Is not me thats confused but both lsblk and blkid spitting out 4 sets of identical UUID's as all drives are identical.  

Example:
root@coyote:etc$ lsblk -o +UUID
NAME    MAJ:MIN RM   SIZE RO TYPE   MOUNTPOINT   UUID
sda       8:0    0   1.8T  0 disk
├─sda1    8:1    0   953M  0 part   /boot        06aa3215-a6a6-4fbb-86ca-186c47e1334c
├─sda2    8:2    0  14.9G  0 part   [SWAP]       8b675a91-5aa5-401b-bf50-d8afc3e8115a
├─sda3    8:3    0  46.6G  0 part   /var         ee491e5c-7394-434f-b50a-f4354f6c9869
├─sda4    8:4    0     1K  0 part
└─sda5    8:5    0   1.8T  0 part   /            0e698024-1cf3-4dbc-812d-10552c01caab
sdb       8:16   0 223.6G  0 disk
└─sdb1    8:17   0 223.6G  0 part   /sdb         4982ee4c-58c4-4d2b-b9d5-69344c3cb090
sdc       8:32   0   1.8T  0 disk
└─sdc1    8:33   0   1.8T  0 part   /amandatapes 3b6848c1-7b09-43be-a7aa-ae63d82f5f26
sde       8:64   0 931.5G  0 disk
├─sde1    8:65   0 878.9G  0 part                3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:0    0   1.7T  0 raid10 /home2       708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sde2    8:66   0  48.8G  0 part                ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:1    0  97.6G  0 raid10 /snapshot    733718b2-e7f8-4b00-a390-264e5c73c453
sdf       8:80   0 931.5G  0 disk
├─sdf1    8:81   0 878.9G  0 part                3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:0    0   1.7T  0 raid10 /home2       708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sdf2    8:82   0  48.8G  0 part                ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:1    0  97.6G  0 raid10 /snapshot    733718b2-e7f8-4b00-a390-264e5c73c453
sdg       8:96   0 931.5G  0 disk
├─sdg1    8:97   0 878.9G  0 part                3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:0    0   1.7T  0 raid10 /home2       708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sdg2    8:98   0  48.8G  0 part                ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:1    0  97.6G  0 raid10 /snapshot    733718b2-e7f8-4b00-a390-264e5c73c453
sdh       8:112  0 931.5G  0 disk
├─sdh1    8:113  0 878.9G  0 part                3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:0    0   1.7T  0 raid10 /home2       708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sdh2    8:114  0  48.8G  0 part                ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:1    0  97.6G  0 raid10 /snapshot    733718b2-e7f8-4b00-a390-264e5c73c453
sr0      11:0    1  1024M  0 rom

So we are talking at cross purposes here as this did not answer my question well enough
to make it work on the first try.

I'll use labels, /home2 and /snapshot, thank you.

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]

#242167

From	Andy Smith <andy@strugglers.net>
Date	2021-11-14 09:10 +0100
Message-ID	<DjiKl-4Rz-5@gated-at.bofh.it>
In reply to	#242158

On Sat, Nov 13, 2021 at 07:26:11PM -0500, Gene Heskett wrote:
> Is not me thats confused

Yes, it still is.

> but both lsblk and blkid spitting out 4 sets of identical UUID's as all drives are identical.

Like I have told you many many times in this thread, the *context*
of the UUID matters. Both blkid and lsblk are showing you UUIDs for
RAID array members, so that's the UUID of the array *not* an fs
UUID.

So again, as I have said multiple times, lots of things have UUIDs;
just because you see the term "UUID" doesn't mean that it is the
UUID of a filesystem. It is the UUID of whatever it is you're
looking at. If you are working with filesystems only take
the UUID of filesystems.

Using a different tool isn't going to make the other UUIDs go away!
You have to ask only for the type of thing you're interested in
(filesystems)!

I'll annotate each one to show you where you are confused:

> Example:
> root@coyote:etc$ lsblk -o +UUID
> NAME    MAJ:MIN RM   SIZE RO TYPE   MOUNTPOINT   UUID

[…]

> sde       8:64   0 931.5G  0 disk
> ├─sde1    8:65   0 878.9G  0 part                3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb

^ UUID of a RAID array. So We know sde1 belongs to an array with
UUID 3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb.

> │ └─md0   9:0    0   1.7T  0 raid10 /home2       708320b3-10af-4c15-b5b1-a9ff7be06d99

^ UUID of the *filesystem* on /dev/md0.

> sdf       8:80   0 931.5G  0 disk
> ├─sdf1    8:81   0 878.9G  0 part                3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb

^ UUID of a RAID array. So we know that sdf1 belongs to RAID array
3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb. We already saw this array UUID
before, so we know that both sde1 and sdf1 are part of the same
array. This is BTW how udev knows which arrays to assemble.

> │ └─md0   9:0    0   1.7T  0 raid10 /home2       708320b3-10af-4c15-b5b1-a9ff7be06d99

^ UUID of filesystem on md0. md0 mentioned again because sde1 and
sf1 are both part of md0.

And so on.

All of your problems with UUIDs can be explained by you simply
reading and trying to use the UUID of things that aren't
filesystems.

I think part of the problem is you being overwhelmed with data. You
keep using blkid (and now lsblk) to look at every single block
device on your system. That can be a really large amount of things
that are all inter-related.

$ sudo lsblk | wc -l
481

Do I want to look at 481 lines of output just to find something
specific?

You can get the device nodes of all your RAID arrays from:

$ cat /proc/mdstat

and then just focus on those, not all of their constituent member
devices.

Andy

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

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

#242177

From	David Wright <deblis@lionunicorn.co.uk>
Date	2021-11-14 18:00 +0100
Message-ID	<Djr1f-1br-3@gated-at.bofh.it>
In reply to	#242156

On Sat 13 Nov 2021 at 18:37:34 (-0500), Greg Wooledge wrote:
> On Sat, Nov 13, 2021 at 04:06:43PM -0700, Charles Curley wrote:
> > 
> > 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

You shouldn't require root for either blkid or lsblk,
though the former needs a path, and does include a
warning that the information may be read from cache.

One question about lsblk, though: why does it always
use the xterm width to format the output, regardless of
whether you redirect the output and the value of COLUMNS.

Is there a workaround beyond resizing the window?

Cheers,
David.

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

#242188

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2021-11-14 19:40 +0100
Message-ID	<DjsA1-2du-1@gated-at.bofh.it>
In reply to	#242177

Hi,

Greg Wooledge wrote:
> > unicorn:~$ sudo lsblk -o +UUID

David Wright wrote:
> You shouldn't require root for either blkid or lsblk,
> though the former needs a path, and does include a
> warning that the information may be read from cache.

This depends highly on the age of the system.
On Debian 8 you don't get much UUID from the system disks without the
permission to read them.
On Debian 10 lsblk seems to depend mostly on udev's assessment.

> > ├─sda1   8:1    0   260M  0 part /boot/efi  4C30-7972

The universe must be small where this FAT UUID is unique.

> One question about lsblk, though: why does it always
> use the xterm width to format the output, regardless of
> whether you redirect the output and the value of COLUMNS.

For me on Debian 10 it does not care about the terminal size.
If i request a few sometimes lengthy fields from lsblk -h i get 206 bytes
per line (plus newline) printed to stdout:

  $ lsblk -o NAME,KNAME,FSTYPE,LABEL,UUID,PARTTYPE,PARTLABEL,PARTUUID,MODEL,SIZE | head -1 | wc -c
  207

In the newest version of the man page
  https://sources.debian.org/src/util-linux/2.37.2-4/misc-utils/lsblk.8/#L179
i see an option which is not in the Debian 10 man page:

  \fB\-w\fP, \fB\-\-width\fP \fInumber\fP
  .RS 4
  Specifies output width as a number of characters. The default is the
  number of the terminal columns, and if not executed on a terminal,
  then output width is not restricted at all by default. This option
  also forces \fBlsblk\fP to assume that terminal control characters
  and unsafe characters are not allowed. The expected use\-case is for
  example when \fBlsblk\fP is used by the \fBwatch\fP(1) command.

Have a nice day :)

Thomas

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

#242193

From	David Wright <deblis@lionunicorn.co.uk>
Date	2021-11-15 02:40 +0100
Message-ID	<Djz8t-6gP-5@gated-at.bofh.it>
In reply to	#242188

On Sun 14 Nov 2021 at 19:35:57 (+0100), Thomas Schmitt wrote:
> Greg Wooledge wrote:
> > > unicorn:~$ sudo lsblk -o +UUID
> 
> David Wright wrote:
> > You shouldn't require root for either blkid or lsblk,
> > though the former needs a path, and does include a
> > warning that the information may be read from cache.
> 
> This depends highly on the age of the system.
> On Debian 8 you don't get much UUID from the system disks without the
> permission to read them.
> On Debian 10 lsblk seems to depend mostly on udev's assessment.

I should have mentioned that I'm using buster here.

> > > ├─sda1   8:1    0   260M  0 part /boot/efi  4C30-7972
> 
> The universe must be small where this FAT UUID is unique.

I don't think there's any need for it to be more than locally unique.
I think I can live with odds of 1:4294967296. What's more important
is that ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b (or
0xef on MBRs), which of course is anything but unique.

> > One question about lsblk, though: why does it always
> > use the xterm width to format the output, regardless of
> > whether you redirect the output and the value of COLUMNS.
> 
> For me on Debian 10 it does not care about the terminal size.
> If i request a few sometimes lengthy fields from lsblk -h i get 206 bytes
> per line (plus newline) printed to stdout:
> 
>   $ lsblk -o NAME,KNAME,FSTYPE,LABEL,UUID,PARTTYPE,PARTLABEL,PARTUUID,MODEL,SIZE | head -1 | wc -c
>   207

Ah yes, you're right. The redirected output is always the minimum
required for columnating the headings and data. It's the /screen/
output that I can't control, ie the amount of overlap employed is
always that which just fills the lines in the xterm.

> In the newest version of the man page
>   https://sources.debian.org/src/util-linux/2.37.2-4/misc-utils/lsblk.8/#L179
> i see an option which is not in the Debian 10 man page:

[-w, --width number]

Yes, not in buster's version at all. I must play with that in bullseye.
Thanks.

Cheers,
David.

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

#242199

From	"Thomas Schmitt" <scdbackup@gmx.net>
Date	2021-11-15 09:10 +0100
Message-ID	<DjFdT-1IJ-1@gated-at.bofh.it>
In reply to	#242177

Hi,

Greg Wooledge wrote:
> > > ├─sda1   8:1    0   260M  0 part /boot/efi  4C30-7972

i wrote:
> > The universe must be small where this FAT UUID is unique.

David Wright wrote:
> I think I can live with odds of 1:4294967296.

Don't forget the birthday paradox. For getting a first collision you
need roughly as many random tries as the square root of the space size.
  https://en.wikipedia.org/wiki/Birthday_problem#Square_approximation

I.e. a hash of 32 bit is good for roughly 2 exp 16 = 65336 tries before
you have to expect two of them to match.

Ok. I confess that having ten thousands of partitions is unlikely on a
single computer. But mathematically a 32 bit number is far from being a
Universally Unique IDentifier.

> What's more important
> is that ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b (or
> 0xef on MBRs), which of course is anything but unique.

Yeah. The long one is on about any computer which boots by EFI from a
disk that's partitioned by GPT. Partition type UUIDs are not random but
rather intended to be the same for any partition of the same type. Even
the MBR partition type 0xef is supposed not to be used for anything but
EFI System Partitions.
(We have 0xef partitions in the Debian installation ISOs. But many old
EFI partitions on disk have MBR partition types like 0x06. Microsoft is
always a bit stronger than public specs.)

Have a nice day :)

Thomas

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

#242204

From	David Wright <deblis@lionunicorn.co.uk>
Date	2021-11-16 05:30 +0100
Message-ID	<DjYgx-4AP-1@gated-at.bofh.it>
In reply to	#242199

On Mon 15 Nov 2021 at 09:04:55 (+0100), Thomas Schmitt wrote:
> Greg Wooledge wrote:
> > > > ├─sda1   8:1    0   260M  0 part /boot/efi  4C30-7972
> 
> i wrote:
> > > The universe must be small where this FAT UUID is unique.
> 
> David Wright wrote:
> > I think I can live with odds of 1:4294967296.
> 
> Don't forget the birthday paradox. For getting a first collision you
> need roughly as many random tries as the square root of the space size.
>   https://en.wikipedia.org/wiki/Birthday_problem#Square_approximation
> 
> I.e. a hash of 32 bit is good for roughly 2 exp 16 = 65336 tries before
> you have to expect two of them to match.

Sure, but birthdays are immutible. Though the idea behind lengthy
GUIDs is that you can choose one at random without needing to take
others into consideration, if a collision were to be created against
the odds, you could replace it easily enough.

> Ok. I confess that having ten thousands of partitions is unlikely on a
> single computer. But mathematically a 32 bit number is far from being a
> Universally Unique IDentifier.

As you said, its universe is very small; so too its significance.

> > What's more important
> > is that ID_PART_ENTRY_TYPE=c12a7328-f81f-11d2-ba4b-00a0c93ec93b (or
> > 0xef on MBRs), which of course is anything but unique.
> 
> Yeah. The long one is on about any computer which boots by EFI from a
> disk that's partitioned by GPT. Partition type UUIDs are not random but
> rather intended to be the same for any partition of the same type. Even
> the MBR partition type 0xef is supposed not to be used for anything but
> EFI System Partitions.
> (We have 0xef partitions in the Debian installation ISOs. But many old
> EFI partitions on disk have MBR partition types like 0x06. Microsoft is
> always a bit stronger than public specs.)

And we even coped with linux fs partitions sharing their type-GUID
with that of Basic Data Partitions in Windows.

Cheers,
David.

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

#242160

From	Tom Dial <tddial@comcast.net>
Date	2021-11-14 05:00 +0100
Message-ID	<DjeQp-2fQ-1@gated-at.bofh.it>
In reply to	#242153


On 11/13/21 14:57, Gene Heskett wrote:
> 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"

>From my experience, those identified by 'UUID=' and 'TYPE="ext4"' are
the likely candidates. My presumption is that if something is reported
to have a recognizable file system specifier, you probably can mount
it. And you would use the value associated with 'UUID=', not 'PARTUUID='
or 'UUID_SUB=,' the meaning of which I do not know.

As supporting evidence I present the fstab from a Gnu/Linux image that
began life sometime earlier than 2002 on a dual Pentium Pro running
Woody (3.0), was upgraded successively to Lenny (5.0), during which it
was moved from 20 GiB disks to 120 GiB. I do not remember when I
switched to UUID identifiers for the non-lvm devices, but someone else
may recall when the contents of the /dev file system became dynamic and
/dev/hda sometimes became /dev/hdb when both were present; it would be a
bit later than that.

# /etc/fstab: static file system information.
#
#<file system>	<mount>	<type>	<options>		<dump>	<pass>
# /dev/hdb3	/	ext2	errors=remount-ro	0	1
UUID=4b009940-2e38-4562-b135-b5e40b5f2546	/	ext2	errors=remount-ro	0	1
# /dev/hda2	none	swap	sw			0	0
UUID=b6f89718-730c-4d93-ba4d-8f001bcc300d	none	swap	sw			0	0
# /dev/hdb2	none	swap	sw			0	0
UUID=46cba318-7ecb-40f8-9815-2d2b5a3aff43	none	swap	sw			0	0
proc		/proc	proc	defaults		0	0
/dev/fd0	/floppy	auto	user,noauto		0	0
/dev/cdrom	/cdrom	iso9660	ro,user,noauto		0	0
# /dev/hdb1	/boot	ext2	defaults		0	2
UUID=9d43af93-395f-4a6e-a65c-790efb755fac	/boot	ext2	defaults		0	2
/dev/vg00/lvol0 /usr    jfs     defaults		0       2
/dev/vg00/lvol1	/var	jfs	defaults		0	2
/dev/vg00/lvol2	/tmp	jfs	defaults		0	2
/dev/vg00/lvol3 /opt    jfs     defaults		0       2
/dev/vg01/lvol1	/home	jfs	defaults		0	2
#
/dev/vg01/lvol0 /u01    jfs     defaults		0       2
#
/dev/vgmedia/lvol1 /backup jfs  noauto                  0       0

(Apology for the ugly line wrapping.)

The system was retired for a while when superseded by a larger system
built around a Q6600 four-core. I resurected the disks a few months ago,
copied them to new "disks" built from iSCSI exports from a NAS. The 120
GiB disks were copied using dd, and booted without significant issues in
a VM, with all file systems mounted rw. The UUIDs, at least those used
in the fstab, were copied without error, as Andy said.

The (now virtual) system has since been upgraded successively to Jessie
(Debian 8), and will, if things go well, be upgraded to Bullseye and
beyond, after being moved again to larger disks. I expect the UUIDs will
be copied correctly again.

Device UUIDs are kind of ugly, but in my experience they are stable
across both OS updates and physical movement of the file systems they
contain as long as what is copied is the disk partition. I do not think
copying a file system (e. g., with cp)  to a new (partitioned) disk
would retain the block device UUID. My practice has been to copy raw
partitions, to a new disk, then expand the file system as appropriate.

Best regards,
Tom


> 
> there are UUID's, PARTUUID's and UUID_SUB's in the above blkid
> output.
> 
> Thanks Andy.
> 
> Cheers, Gene Heskett.
>

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

#242161

From	Greg Wooledge <greg@wooledge.org>
Date	2021-11-14 05:10 +0100
Message-ID	<Djf06-2yj-5@gated-at.bofh.it>
In reply to	#242160

On Sat, Nov 13, 2021 at 08:37:19PM -0700, Tom Dial wrote:
> Device UUIDs are kind of ugly, but in my experience they are stable
> across both OS updates and physical movement of the file systems they
> contain as long as what is copied is the disk partition. I do not think
> copying a file system (e. g., with cp)  to a new (partitioned) disk
> would retain the block device UUID. My practice has been to copy raw
> partitions, to a new disk, then expand the file system as appropriate.

Copying the contents of a file system, by using rsync or cp -a or
similar commands, would not retain the file system's UUID.

Copying the raw file system itself, by using "cp /dev/sda1 /dev/sdb1"
or similar, should copy the file system's UUID over along with the
contents, and the empty space, and the deleted data, and so on.

I don't know anything about "block device UUIDs".

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

#242162

From	Gene Heskett <gheskett@shentel.net>
Date	2021-11-14 05:40 +0100
Message-ID	<Djft8-2HA-3@gated-at.bofh.it>
In reply to	#242160

On Saturday 13 November 2021 22:37:19 Tom Dial wrote:

> On 11/13/21 14:57, Gene Heskett wrote:
[...]
> >>> 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.

That I found. Getting rid of avahi and its git fixed that right up. I 
think in the intervening years, its gotten some TLC because its not been 
a problem since wheezy. The problem was that it was assigning an ipv6 
route to a system 200 miles from the nearest ipv6 socket.

> >> 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"
>
> From my experience, those identified by 'UUID=' and 'TYPE="ext4"' are
> the likely candidates. My presumption is that if something is reported
> to have a recognizable file system specifier, you probably can mount
> it. And you would use the value associated with 'UUID=', not
> 'PARTUUID=' or 'UUID_SUB=,' the meaning of which I do not know.
>
Thats easy, PARTUUID's are identifiers for the partition if the drive has 
more than 1. And I believe for partitioned drives, invalid

> As supporting evidence I present the fstab from a Gnu/Linux image that
> began life sometime earlier than 2002 on a dual Pentium Pro running
> Woody (3.0), was upgraded successively to Lenny (5.0), during which it
> was moved from 20 GiB disks to 120 GiB. I do not remember when I
> switched to UUID identifiers for the non-lvm devices, but someone else
> may recall when the contents of the /dev file system became dynamic
> and /dev/hda sometimes became /dev/hdb when both were present; it
> would be a bit later than that.
>
> # /etc/fstab: static file system information.
> #
> #<file system>	<mount>	<type>	<options>		<dump>	<pass>
> # /dev/hdb3	/	ext2	errors=remount-ro	0	1
> UUID=4b009940-2e38-4562-b135-b5e40b5f2546	/	ext2	errors=remount-ro	0	1
> # /dev/hda2	none	swap	sw			0	0
> UUID=b6f89718-730c-4d93-ba4d-8f001bcc300d	none	swap	sw			0	0
> # /dev/hdb2	none	swap	sw			0	0
> UUID=46cba318-7ecb-40f8-9815-2d2b5a3aff43	none	swap	sw			0	0
> proc		/proc	proc	defaults		0	0
> /dev/fd0	/floppy	auto	user,noauto		0	0
> /dev/cdrom	/cdrom	iso9660	ro,user,noauto		0	0
> # /dev/hdb1	/boot	ext2	defaults		0	2
> UUID=9d43af93-395f-4a6e-a65c-790efb755fac	/boot	ext2	defaults		0	2
> /dev/vg00/lvol0 /usr    jfs     defaults		0       2
> /dev/vg00/lvol1	/var	jfs	defaults		0	2
> /dev/vg00/lvol2	/tmp	jfs	defaults		0	2
> /dev/vg00/lvol3 /opt    jfs     defaults		0       2
> /dev/vg01/lvol1	/home	jfs	defaults		0	2
> #
> /dev/vg01/lvol0 /u01    jfs     defaults		0       2
> #
> /dev/vgmedia/lvol1 /backup jfs  noauto                  0       0
>
> (Apology for the ugly line wrapping.)
>
> The system was retired for a while when superseded by a larger system
> built around a Q6600 four-core. I resurected the disks a few months
> ago, copied them to new "disks" built from iSCSI exports from a NAS.
> The 120 GiB disks were copied using dd, and booted without significant
> issues in a VM, with all file systems mounted rw. The UUIDs, at least
> those used in the fstab, were copied without error, as Andy said.
>
> The (now virtual) system has since been upgraded successively to
> Jessie (Debian 8), and will, if things go well, be upgraded to
> Bullseye and beyond, after being moved again to larger disks. I expect
> the UUIDs will be copied correctly again.
>
> Device UUIDs are kind of ugly, but in my experience they are stable
> across both OS updates and physical movement of the file systems they
> contain as long as what is copied is the disk partition. I do not
> think copying a file system (e. g., with cp)  to a new (partitioned)
> disk would retain the block device UUID. My practice has been to copy
> raw partitions, to a new disk, then expand the file system as
> appropriate.
>
> Best regards,
> Tom
>
> > there are UUID's, PARTUUID's and UUID_SUB's in the above blkid
> > output.
> >
> > Thanks Andy.
> >
> > Cheers, Gene Heskett.


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]

#242076

From	Charles Curley <charlescurley@charlescurley.com>
Date	2021-11-12 18:10 +0100
Message-ID	<DiIdQ-81H-9@gated-at.bofh.it>
In reply to	#242066

On Fri, 12 Nov 2021 09:48:01 -0500
Gene Heskett <gheskett@shentel.net> wrote:

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

My experience reinstalling Bullseye is that the name of the array
didn't change.

-- 
Does anybody read signatures any more?

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

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

#242085

From	Charles Curley <charlescurley@charlescurley.com>
Date	2021-11-12 19:00 +0100
Message-ID	<DiJ0e-8hR-15@gated-at.bofh.it>
In reply to	#242076

On Fri, 12 Nov 2021 09:38:42 -0700
Charles Curley <charlescurley@charlescurley.com> wrote:

> My experience reinstalling Bullseye is that the name of the array
> didn't change.

Once more, with clarity.

I created my array as a RAID1 under Buster. I then installed Bullseye.
The name of the array did not change.

-- 
Does anybody read signatures any more?

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

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

#242079

From	"Andrew M.A. Cater" <amacater@einval.com>
Date	2021-11-12 18:10 +0100
Message-ID	<DiIdR-81H-23@gated-at.bofh.it>
In reply to	#242066

On Fri, Nov 12, 2021 at 09:48:01AM -0500, 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.
> 
> > 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>
> 

Gene

At the point when you want to install Bullseye:

Use an expert install.

set up the disks as RAID 10 first, then use the partition editor to assign
the RAID as /home

At that point, you're done :)

All the very best, as ever,

Andy C.

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

#242091

From	Gene Heskett <gheskett@shentel.net>
Date	2021-11-12 20:10 +0100
Message-ID	<DiK5Y-Ia-11@gated-at.bofh.it>
In reply to	#242079

On Friday 12 November 2021 11:57:28 Andrew M.A. Cater wrote:

> On Fri, Nov 12, 2021 at 09:48:01AM -0500, 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.
> >
> > > 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>
>
> Gene
>
> At the point when you want to install Bullseye:
>
> Use an expert install.
>
> set up the disks as RAID 10 first, then use the partition editor to
> assign the RAID as /home
>
> At that point, you're done :)

That will be good, but getting rid of the first raid10 I built is needing 
tactical nukes.  Its taking almost 40 minutes a drive to zero them and 
start over. And this machine is acting like an 8086 machine doing it. 
very very slow. gkrellm is showing all 6 core in bright orange. Not any 
great temp rises though, staying below 35C for all 6 cores. The heat 
sink/radiator is huge, so huge I can't put the side panel back on the 
tower. 5" fan is turning silently at maybe 400 revs. I think I overbuilt 
it ;o)

> All the very best, as ever,

Of coarse, to you too Andy.  Stay well.

> Andy C.


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]

#242098

From	Dan Ritter <dsr@randomstring.org>
Date	2021-11-12 21:40 +0100
Message-ID	<DiLv4-1qK-13@gated-at.bofh.it>
In reply to	#242091

Gene Heskett wrote: 
> On Friday 12 November 2021 11:57:28 Andrew M.A. Cater wrote:
> 
> >
> > Use an expert install.
> >
> > set up the disks as RAID 10 first, then use the partition editor to
> > assign the RAID as /home
> >
> > At that point, you're done :)
> 
> That will be good, but getting rid of the first raid10 I built is needing 
> tactical nukes.  Its taking almost 40 minutes a drive to zero them and 
> start over. And this machine is acting like an 8086 machine doing it. 
> very very slow. gkrellm is showing all 6 core in bright orange. Not any 
> great temp rises though, staying below 35C for all 6 cores. The heat 
> sink/radiator is huge, so huge I can't put the side panel back on the 
> tower. 5" fan is turning silently at maybe 400 revs. I think I overbuilt 
> it ;o)

No need to do it the hard way: 

For each disk, run 

# wipefs /dev/sdX

which will not destroy anything ; it will list the commands
needed to remove the existing filesystems.

Then run that command, generally of the form wipdefs -o 0x1000
or such, which will complete in seconds.

Repeat for the next disk.

-dsr-

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

#242100

From	Gene Heskett <gheskett@shentel.net>
Date	2021-11-12 23:00 +0100
Message-ID	<DiMKt-25Z-11@gated-at.bofh.it>
In reply to	#242098

On Friday 12 November 2021 15:12:15 Dan Ritter wrote:

> Gene Heskett wrote:
> > On Friday 12 November 2021 11:57:28 Andrew M.A. Cater wrote:
> > > Use an expert install.
> > >
> > > set up the disks as RAID 10 first, then use the partition editor
> > > to assign the RAID as /home
> > >
> > > At that point, you're done :)
> >
> > That will be good, but getting rid of the first raid10 I built is
> > needing tactical nukes.  Its taking almost 40 minutes a drive to
> > zero them and start over. And this machine is acting like an 8086
> > machine doing it. very very slow. gkrellm is showing all 6 core in
> > bright orange. Not any great temp rises though, staying below 35C
> > for all 6 cores. The heat sink/radiator is huge, so huge I can't put
> > the side panel back on the tower. 5" fan is turning silently at
> > maybe 400 revs. I think I overbuilt it ;o)
>
> No need to do it the hard way:
>
> For each disk, run
>
> # wipefs /dev/sdX
>
> which will not destroy anything ; it will list the commands
> needed to remove the existing filesystems.
>
> Then run that command, generally of the form wipdefs -o 0x1000
> or such, which will complete in seconds.
>
> Repeat for the next disk.
>
> -dsr-
root@coyote:~$ wipefs /dev/sde -o 0x1000
wipefs: error: /dev/sde: probing initialization failed: Device or 
resource busy
And I have to reboot as mdadm has no stop command. Thats BS.
I did cobble up a wipefs with dd, wipefs cannot do it without yet another 
reboot. dd does not  check, it just zeros the first 1000 hex blocks.

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]

#242101

From	The Wanderer <wanderer@fastmail.fm>
Date	2021-11-12 23:10 +0100
Message-ID	<DiMU9-2oY-1@gated-at.bofh.it>
In reply to	#242100

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

On 2021-11-12 at 16:52, Gene Heskett wrote:

> On Friday 12 November 2021 15:12:15 Dan Ritter wrote:
> 
>> Gene Heskett wrote:

>>> That will be good, but getting rid of the first raid10 I built
>>> is needing tactical nukes.  Its taking almost 40 minutes a drive
>>> to zero them and start over. And this machine is acting like an
>>> 8086 machine doing it. very very slow. gkrellm is showing all 6
>>> core in bright orange. Not any great temp rises though, staying
>>> below 35C for all 6 cores. The heat sink/radiator is huge, so
>>> huge I can't put the side panel back on the tower. 5" fan is
>>> turning silently at maybe 400 revs. I think I overbuilt it ;o)
>> 
>> No need to do it the hard way:
>> 
>> For each disk, run
>> 
>> # wipefs /dev/sdX
>> 
>> which will not destroy anything ; it will list the commands needed
>> to remove the existing filesystems.
>> 
>> Then run that command, generally of the form wipdefs -o 0x1000 or
>> such, which will complete in seconds.
>> 
>> Repeat for the next disk.
>> 
>> -dsr-
> 
> root@coyote:~$ wipefs /dev/sde -o 0x1000
> wipefs: error: /dev/sde: probing initialization failed: Device or 
> resource busy
> And I have to reboot as mdadm has no stop command. Thats BS.

Eh?

From the mdadm man page (at least on my machine):

       -S, --stop
              deactivate array, releasing all resources.

And from the EXAMPLES section:

         mdadm --stop --scan
       This will shut down all arrays that can be shut down (i.e. are
not cur‐
       rently in use).  This will typically go in a system shutdown script.

While it's probably not possible to stop the mdraid backend (since IIRC
it's part of the kernel?), it should certainly be possible to tell it to
let go of the devices it's managing.

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

#242105

From	Gene Heskett <gheskett@shentel.net>
Date	2021-11-13 01:00 +0100
Message-ID	<DiOCC-3dR-3@gated-at.bofh.it>
In reply to	#242101

On Friday 12 November 2021 17:01:01 The Wanderer wrote:

> On 2021-11-12 at 16:52, Gene Heskett wrote:
> > On Friday 12 November 2021 15:12:15 Dan Ritter wrote:
> >> Gene Heskett wrote:
> >>> That will be good, but getting rid of the first raid10 I built
> >>> is needing tactical nukes.  Its taking almost 40 minutes a drive
> >>> to zero them and start over. And this machine is acting like an
> >>> 8086 machine doing it. very very slow. gkrellm is showing all 6
> >>> core in bright orange. Not any great temp rises though, staying
> >>> below 35C for all 6 cores. The heat sink/radiator is huge, so
> >>> huge I can't put the side panel back on the tower. 5" fan is
> >>> turning silently at maybe 400 revs. I think I overbuilt it ;o)
> >>
> >> No need to do it the hard way:
> >>
> >> For each disk, run
> >>
> >> # wipefs /dev/sdX
> >>
> >> which will not destroy anything ; it will list the commands needed
> >> to remove the existing filesystems.
> >>
> >> Then run that command, generally of the form wipdefs -o 0x1000 or
> >> such, which will complete in seconds.
> >>
> >> Repeat for the next disk.
> >>
> >> -dsr-
> >
> > root@coyote:~$ wipefs /dev/sde -o 0x1000
> > wipefs: error: /dev/sde: probing initialization failed: Device or
> > resource busy
> > And I have to reboot as mdadm has no stop command. Thats BS.
>
> Eh?
>
> From the mdadm man page (at least on my machine):

But not on mine but I'll be switched, it worked and I was then able to 
format both and have the bigger one mounted, this time w/o any fussing 
after typeing yes,

Like I've said 2 or 3 times, my man pages for a lot of this are NOT 
uptodate. Very frustrating.

And thank you, a bunch!

>
>        -S, --stop
>               deactivate array, releasing all resources.
>
> And from the EXAMPLES section:
>
>          mdadm --stop --scan
>        This will shut down all arrays that can be shut down (i.e. are
> not cur‐
>        rently in use).  This will typically go in a system shutdown
> script.
>
> While it's probably not possible to stop the mdraid backend (since
> IIRC it's part of the kernel?), it should certainly be possible to
> tell it to let go of the devices it's managing.

It sure did. Thank you again. Now I can proceed.

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]

#242099

From	Gene Heskett <gheskett@shentel.net>
Date	2021-11-12 22:30 +0100
Message-ID	<DiMhs-1Wk-5@gated-at.bofh.it>
In reply to	#242059

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

Ok, zeroed them, nuked mdadm.conf & rebooted.
gparted each one, setting 2 partitions in GPT format on each of 900000 
MIB (sde1) with label MDV1 and 5000 MIB (sde2) labeled MDV2 and applied 
that to each of the 4 drives. Double check as /dev/sdf somehow swapped 
positions on the drive, fixed that: Wash rinse and repeat for sdf, sdg, 
and sdh with labels of MDX1, MDX2, MDY1, MDY2 and MDZ1 and MDZ2. And of 
course gparted makes a file system when Apply is clicked.

but:
root@coyote:~$ 
mdadm -C /dev/md0 --level=10 --raid-devices=4 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1
mdadm: /dev/sde1 appears to contain an ext2fs file system
       size=921600000K  mtime=Wed Dec 31 19:00:00 1969
mdadm: /dev/sdf1 appears to contain an ext2fs file system
       size=921600000K  mtime=Wed Dec 31 19:00:00 1969
mdadm: /dev/sdg1 appears to contain an ext2fs file system
       size=921600000K  mtime=Wed Dec 31 19:00:00 1969
mdadm: /dev/sdh1 appears to contain an ext2fs file system
       size=921600000K  mtime=Wed Dec 31 19:00:00 1969
Continue creating array? yes
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md0 started.
root@coyote:~$ 
mdadm -C /dev/md1 --level=10 --raid-devices=4 /dev/sde2 /dev/sdf2 /dev/sdg2 /dev/sdh2
mdadm: /dev/sde2 appears to contain an ext2fs file system
       size=51200000K  mtime=Wed Dec 31 19:00:00 1969
mdadm: /dev/sdf2 appears to contain an ext2fs file system
       size=51200000K  mtime=Wed Dec 31 19:00:00 1969
mdadm: /dev/sdg2 appears to contain an ext2fs file system
       size=51200000K  mtime=Wed Dec 31 19:00:00 1969
mdadm: /dev/sdh2 appears to contain an ext2fs file system
       size=51200000K  mtime=Wed Dec 31 19:00:00 1969
Continue creating array? yes
mdadm: Defaulting to version 1.2 metadata
mdadm: array /dev/md1 started.
root@coyote:~$ mkfs -Text4 /dev/md0
mke2fs 1.43.4 (31-Jan-2017)
mkfs.ext2: invalid blocks '/dev/md0' on device 'mkfs'

There are a few unallocated blocks at the ends of all drives. gparted 
chose alignment and prespace in MiB. Do I need to add a 3rd partition to 
use them up? All drives seem to be identical sizewise but the pages 
recommend identical partition sizes. Theoreticly I could expand the 
smaller partition to use it up.

rerunning gparted, I find 4 870 GIB partitions labeled coyote:0 and 4 47 
GiB paartitions all labeled coyote:1. Which isn't what I told gparted to 
label them as with about 3.5 GIB unallocated on each one.

So I am lost as to Whats next? Or do I start doing it all over again 
using some other partitioning tool?

Thanks all.

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]

#242117

From	Dan Ritter <dsr@randomstring.org>
Date	2021-11-13 12:30 +0100
Message-ID	<DiZol-1tf-3@gated-at.bofh.it>
In reply to	#242099

Gene Heskett wrote: 
> On Friday 12 November 2021 08:49:21 Dan Ritter wrote:
> 
> Ok, zeroed them, nuked mdadm.conf & rebooted.
> gparted each one, setting 2 partitions in GPT format on each of 900000 
> MIB (sde1) with label MDV1 and 5000 MIB (sde2) labeled MDV2 and applied 
> that to each of the 4 drives. Double check as /dev/sdf somehow swapped 
> positions on the drive, fixed that: Wash rinse and repeat for sdf, sdg, 
> and sdh with labels of MDX1, MDX2, MDY1, MDY2 and MDZ1 and MDZ2. And of 
> course gparted makes a file system when Apply is clicked.
> 
> but:
> root@coyote:~$ 
> mdadm -C /dev/md0 --level=10 --raid-devices=4 /dev/sde1 /dev/sdf1 /dev/sdg1 /dev/sdh1
> mdadm: /dev/sde1 appears to contain an ext2fs file system
>        size=921600000K  mtime=Wed Dec 31 19:00:00 1969
> mdadm: /dev/sdf1 appears to contain an ext2fs file system
>        size=921600000K  mtime=Wed Dec 31 19:00:00 1969
> mdadm: /dev/sdg1 appears to contain an ext2fs file system
>        size=921600000K  mtime=Wed Dec 31 19:00:00 1969
> mdadm: /dev/sdh1 appears to contain an ext2fs file system
>        size=921600000K  mtime=Wed Dec 31 19:00:00 1969
> Continue creating array? yes

You should stop there and run wipefs. I note from later mail in
this thread that you didn't; and then you had to reboot.

With the array not started, or stopped, run wipefs on each of
the partitions.

Then these -C commands should work well without warnings, and
creating a filesystem on the /dev/mdX devices will proceed
without warnings or errors.

> There are a few unallocated blocks at the ends of all drives. gparted 
> chose alignment and prespace in MiB. Do I need to add a 3rd partition to 
> use them up? All drives seem to be identical sizewise but the pages 
> recommend identical partition sizes. Theoreticly I could expand the 
> smaller partition to use it up.

I would not bother.

-dsr-

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

Page 2 of 4 — ← Prev page 1 [2] 3 4 Next page →

csiph-web

Where do I find the definitive man page for mdadm?

Contents

#242158

#242167

#242177

#242188

#242193

#242199

#242204

#242160

#242161

#242162

#242076

#242085

#242079

#242091

#242098

#242100

#242101

#242105

#242099

#242117