Odd mkbtrfs behavior inside of chroot

PATCH New J G 3 participants 6 messages Jan 2, 2011 – Jan 4, 2011 Btrfs file system

Share & tools

J G

author

2011-01-02 19:52 UTC #0 lore raw

I just encountered some odd behavior from mkbtrfs.
The end goal is to restore a backup to newly created BTRFS partitions while using the latest btrfs-tools. Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12 partitions each)
* Created an extra partition on sda as a temporary holding place for the backed up files and so I can update btrfs-tools
* Formatted/mounted/restored backup files to the temporary partition which I mounted on /mnt/backup
* mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from today (v0.19-35-g1b444cd-dirty).
* mkbtrfs /dev/sda5 /dev/sdb5 -L root

mkbtrfs returned with:

error checking /dev/sda5 mount status

So I used strace to find out how it was checking for the mount status. Now, I'm no expert here, but I'm confused as to just why it failed. The last thing of note:

lstat("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/boot/sysrcd.dat", 0x7fffb29681e0) = -1 ENOENT (No such file or directory)
close(3) = 0
munmap(0x7f11df372000, 4096) = 0
write(2, "error checking /dev/sda5 mount s"..., 38error checking /dev/sda5 mount status ) = 38

doesn't explain much. I see that it's checking /proc/mounts to see what's mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist in the non-chrooted FS, btw).

To make this even weirder, if I format sda5/sdb5 using the SysRescCD version of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it works fine.

Any ideas here? I would expect that mkbtrfs would work inside of a chroot without any assistance from the original root.

I have the full strace from the chrooted mkbtrfs failing and from it succeeding, if that's helpful.

.:Justin:.

Jérôme Poulin

2011-01-02 21:06 UTC #1 lore raw

Did you try using -o bind on /proc and /sys as well? Just in case mkfs uses /sys too, I'm not sure if /proc reacts differently to multiple mounts or bind neither?

Envoy=E9 de mon appareil mobile.

J=E9r=F4me Poulin
Solutions G.A.

Quoted 2 lines · J G

I just encountered some odd behavior from mkbtrfs.
The end goal is to restore a backup to newly created BTRFS partitions=

while using the latest btrfs-tools.

Quoted 4 lines

Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12 partitions each)
* Created an extra partition on sda as a temporary holding place for =

the backed up files and so I can update btrfs-tools

Quoted 1 line

* Formatted/mounted/restored backup files to the temporary partition =

which I mounted on /mnt/backup

Quoted 1 line

* mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup=

/dev

Quoted 2 lines

* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from today (v0.19-35-g1b=

444cd-dirty).

Quoted 7 lines

* mkbtrfs /dev/sda5 /dev/sdb5 -L root
mkbtrfs returned with:
error checking /dev/sda5 mount status
So I used strace to find out how it was checking for the mount status=

=2E Now, I'm no expert here, but I'm confused as to just why it failed.=
The last thing of note:

Quoted 3 lines

lstat("/boot", {st_mode=3DS_IFDIR|0755, st_size=3D4096, ...}) =3D 0 lstat("/boot/sysrcd.dat", 0x7fffb29681e0) =3D -1 ENOENT (No such file=

or directory)

Quoted 3 lines

close(3) =3D 0
munmap(0x7f11df372000, 4096) =3D 0
write(2, "error checking /dev/sda5 mount s"..., 38error checking /dev=

/sda5 mount status

Quoted 4 lines

) =3D 38
doesn't explain much. I see that it's checking /proc/mounts to see wh=

at's mounted, and then it fails on stating /boot/sysrcd.dat (which does= n't exist in the non-chrooted FS, btw).

Quoted 2 lines

To make this even weirder, if I format sda5/sdb5 using the SysRescCD =

version of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot v= ersion, it works fine.

Quoted 2 lines

Any ideas here? I would expect that mkbtrfs would work inside of a ch=

root without any assistance from the original root.

Quoted 2 lines

I have the full strace from the chrooted mkbtrfs failing and from it =

succeeding, if that's helpful.

Quoted 8 lines

.:Justin:.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs=

" in

Quoted 2 lines

the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

J G

author

2011-01-04 23:12 UTC #2 lore raw

Binding /sys proved futile.

=2E:Justin:.

Quoted 77 lines · --- On Sun, 1/2/11, J=E9r=F4me Poulin <[email protected]> wrote:

From: J=E9r=F4me Poulin <[email protected]>
Subject: Re: Odd mkbtrfs behavior inside of chroot
To: "J G" <[email protected]>
Cc: "[email protected]" <[email protected]>
Date: Sunday, January 2, 2011, 1:06 PM
Did you try using -o bind on /proc
and /sys as well? Just in case mkfs
uses /sys too, I'm not sure if /proc reacts differently to multiple
mounts or bind neither?
=20
Envoy=E9 de mon appareil mobile.
=20
J=E9r=F4me Poulin
Solutions G.A.
=20
On 2011-01-02, at 14:53, J G <[email protected]> wrote:
=20
Quoted 2 lines
I just encountered some odd behavior from mkbtrfs. The end goal is to restore a backup to newly created
BTRFS partitions while using the latest btrfs-tools.
Quoted 3 lines
Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12
partitions each)
Quoted 1 line
* Created an extra partition on sda as a temporary
holding place for the backed up files and so I can update btrfs-tools
Quoted 1 line
* Formatted/mounted/restored backup files to the
temporary partition which I mounted on /mnt/backup
Quoted 1 line
* mount -t proc none /mnt/backup/proc; mount -o bind
/dev /mnt/backup/dev
Quoted 2 lines
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from
today (v0.19-35-g1b444cd-dirty).
Quoted 7 lines
* mkbtrfs /dev/sda5 /dev/sdb5 -L root
mkbtrfs returned with:
error checking /dev/sda5 mount status
So I used strace to find out how it was checking for
the mount status. Now, I'm no expert here, but I'm confused as to just why it failed. The last thing of note:
Quoted 2 lines
lstat("/boot", {st_mode=3DS_IFDIR|0755, st_size=3D4096,
...}) =3D 0
Quoted 1 line
lstat("/boot/sysrcd.dat", 0x7fffb29681e0) =3D -1 ENOENT
(No such file or directory)
Quoted 1 line
close(3)=A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =3D 0
Quoted 1 line
munmap(0x7f11df372000, 4096)=A0 =A0 =A0
=A0 =A0 =A0 =3D 0
Quoted 1 line
write(2, "error checking /dev/sda5 mount s"...,
38error checking /dev/sda5 mount status
Quoted 4 lines
) =3D 38
doesn't explain much. I see that it's checking
/proc/mounts to see what's mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist in the non-chrooted FS, btw).
Quoted 2 lines
To make this even weirder, if I format sda5/sdb5 using
the SysRescCD version of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it works fine.
Quoted 2 lines
Any ideas here? I would expect that mkbtrfs would work
inside of a chroot without any assistance from the original root.
Quoted 2 lines
I have the full strace from the chrooted mkbtrfs
failing and from it succeeding, if that's helpful.
Quoted 2 lines

Quoted 9 lines

Quoted 6 lines
.:Justin:.
--
To unsubscribe from this list: send the line
"unsubscribe linux-btrfs" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at=A0 http://vger.kernel.org/majordomo-info.htm=

Quoted 1 line

=20

=20

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Goffredo Baroncelli

2011-01-02 23:14 UTC #3 lore raw

In reply to J G

Quoted 26 lines · J G

I just encountered some odd behavior from mkbtrfs.
The end goal is to restore a backup to newly created BTRFS partitions while using the latest btrfs-tools. Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12 partitions each)
* Created an extra partition on sda as a temporary holding place for the backed up files and so I can update btrfs-tools
* Formatted/mounted/restored backup files to the temporary partition which I mounted on /mnt/backup
* mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from today (v0.19-35-g1b444cd-dirty).
* mkbtrfs /dev/sda5 /dev/sdb5 -L root
mkbtrfs returned with:
error checking /dev/sda5 mount status
So I used strace to find out how it was checking for the mount status. Now, I'm no expert here, but I'm confused as to just why it failed. The last thing of note:
lstat("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/boot/sysrcd.dat", 0x7fffb29681e0) = -1 ENOENT (No such file or directory)
close(3) = 0
munmap(0x7f11df372000, 4096) = 0
write(2, "error checking /dev/sda5 mount s"..., 38error checking /dev/sda5 mount status ) = 38

Quoted 7 lines

doesn't explain much. I see that it's checking /proc/mounts to see what's mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist in the non-chrooted FS, btw).
To make this even weirder, if I format sda5/sdb5 using the SysRescCD version of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it works fine.
Any ideas here? I would expect that mkbtrfs would work inside of a chroot without any assistance from the original root.
I have the full strace from the chrooted mkbtrfs failing and from it succeeding, if that's helpful.

On the basis of the provided information, and on the code it seems that mkfs.btrfs tries hard to check that the user is not formatting a mounted disk (or loop). So mkfs.btrfs scan the /proc/mount file and checks every devices. To do the check it needs to access the original file if this is a "loop backend". This is reasonable.

In this case in a chroot-ed environment the loop file is not accessible.

If you need a [dirty] "quick hack" to by-pass the problem (not tested):
- unmount the proc filesystem
- create an empty file /proc/mounts
- run btrfs.fsck
- mount the proc filesystem (removing the fake mounts file)
- perform a "btrfs device scan"
- mount the filesystem

Of course the "right" solution is to add a "--force" switch which permits to by-pass these checks. Other mkfs.* tools have this switch.

Quoted 1 line

From the mkfs.ext4 man page:

[...]
-F Force mke2fs to create a filesystem,
even if the specified device is not
a partition on a block special
device, or if other parameters do not make sense. In order to force mke2fs to create a filesystem even if the filesystem appears to be in use or is mounted (a truly dangerous thing to do), this option must be specified twice.

[...]

Quoted 11 lines

.:Justin:.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.

Goffredo Baroncelli

2011-01-03 19:05 UTC #4 lore raw

PATCH 1/1 add a --force option to mkfs.btrf [was Re: Odd mkbtrfs behavior inside of chroot]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all and happy new year.

this is my first patch of the new year. Hooping that this is a good sign. :-)

The enclosed patch try to address the problem raised by Justin: how circumvent the check performed by mkfs.btrfs ?
I add a "-f|--force" switch which permits to bypass the check if a device is already mounted. I update the man page too.

You can pull the change from

http://cassiopea.homelinux.net/git/btrfs-progs-unstable.git

branch

force-mkfs

commit (2900a150cde604f82f1437c931792bfa59c4780b)

Comments are welcome
Regards
G.Baroncelli

- --
gpg key: Goffredo Baroncelli (ghigo) <[email protected]> Key fingerprint = 4769 7E51 5293 D36C 814E C054 BF04 F161 3DC5 0512

Quoted 82 lines · Goffredo Baroncelli

Quoted 26 lines · J G
I just encountered some odd behavior from mkbtrfs.
The end goal is to restore a backup to newly created BTRFS partitions while using the latest btrfs-tools. Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12 partitions each)
* Created an extra partition on sda as a temporary holding place for the backed up files and so I can update btrfs-tools
* Formatted/mounted/restored backup files to the temporary partition which I mounted on /mnt/backup
* mount -t proc none /mnt/backup/proc; mount -o bind /dev /mnt/backup/dev
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from today (v0.19-35-g1b444cd-dirty).
* mkbtrfs /dev/sda5 /dev/sdb5 -L root
mkbtrfs returned with:
error checking /dev/sda5 mount status
So I used strace to find out how it was checking for the mount status. Now, I'm no expert here, but I'm confused as to just why it failed. The last thing of note:
lstat("/boot", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0 lstat("/boot/sysrcd.dat", 0x7fffb29681e0) = -1 ENOENT (No such file or directory)
close(3) = 0
munmap(0x7f11df372000, 4096) = 0
write(2, "error checking /dev/sda5 mount s"..., 38error checking /dev/sda5 mount status ) = 38
Quoted 7 lines
doesn't explain much. I see that it's checking /proc/mounts to see what's mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist in the non-chrooted FS, btw).
To make this even weirder, if I format sda5/sdb5 using the SysRescCD version of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it works fine.
Any ideas here? I would expect that mkbtrfs would work inside of a chroot without any assistance from the original root.
I have the full strace from the chrooted mkbtrfs failing and from it succeeding, if that's helpful.
On the basis of the provided information, and on the code it seems that mkfs.btrfs tries hard to check that the user is not formatting a mounted disk (or loop). So mkfs.btrfs scan the /proc/mount file and checks every devices. To do the check it needs to access the original file if this is a "loop backend". This is reasonable.
In this case in a chroot-ed environment the loop file is not accessible.
If you need a [dirty] "quick hack" to by-pass the problem (not tested):
- unmount the proc filesystem
- create an empty file /proc/mounts
- run btrfs.fsck
- mount the proc filesystem (removing the fake mounts file)
- perform a "btrfs device scan"
- mount the filesystem
Of course the "right" solution is to add a "--force" switch which permits to by-pass these checks. Other mkfs.* tools have this switch.
Quoted 1 line
From the mkfs.ext4 man page:
[...]
-F Force mke2fs to create a filesystem,
even if the specified device is not
a partition on a block special
device, or if other parameters do not make sense. In order to force mke2fs to create a filesystem even if the filesystem appears to be in use or is mounted (a truly dangerous thing to do), this option must be specified twice.
[...]
Quoted 11 lines
.:Justin:.
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.

Quoted 6 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFNIh34vwTxYT3FBRIRAl1tAJ9k1LVUfahdlvLvK7b4gct55fom3QCfd1Ab 0JfVbWgKf7DXd0Gg1YzaPdU=
=Jt+e
-----END PGP SIGNATURE-----

man/mkfs.btrfs.8.in +11 -8

index 1e14c6c..f51291c 100644
@@ -5,14 +5,14 @@ mkfs.btrfs \- create an btrfs filesystem
 .B mkfs.btrfs
 [ \fB\-A\fP\fI alloc-start\fP ]
 [ \fB\-b\fP\fI byte-count\fP ]
-[ \fB \-d\fP\fI data-profile\fP ]
-[ \fB \-l\fP\fI leafsize\fP ]
-[ \fB \-L\fP\fI label\fP ]
-[ \fB \-m\fP\fI metadata profile\fP ]
-[ \fB \-n\fP\fI nodesize\fP ]
-[ \fB \-s\fP\fI sectorsize\fP ]
-[ \fB \-h\fP ]
-[ \fB \-V\fP ] \fI device\fP [ \fI device ...\fP ]
+[ \fB\-d\fP\fI data-profile\fP ]
+[ \fB\-f\fP ]
+[ \fB\-l\fP\fI leafsize\fP ]
+[ \fB\-L\fP\fI label\fP ]
+[ \fB\-m\fP\fI metadata profile\fP ]
+[ \fB\-n\fP\fI nodesize\fP ]
+[ \fB\-s\fP\fI sectorsize\fP ]
+[ \fB\-V\fP ] \fIdevice\fP [ \fIdevice ...\fP ]
 .SH DESCRIPTION
 .B mkfs.btrfs
 is used to create an btrfs filesystem (usually in a disk partition, or an array

@@ -34,6 +34,9 @@ mkfs.btrfs uses all the available storage for the filesystem.
 Specify how the data must be spanned across the devices specified. Valid
 values are raid0, raid1, raid10 or single.
 .TP
+\fB\-f\fR, \fB\-\-force \fR
+Don't check if the device is already mounted.
+.TP
 \fB\-l\fR, \fB\-\-leafsize \fIsize\fR
 Specify the leaf size, the least data item in which btrfs stores data. The
 default value is the page size.

mkfs.c +28 ~~-17~~

84 lines not on this page · raw message

J G

author

2011-01-04 23:16 UTC #5 lore raw

In reply to Goffredo Baroncelli

You're little trick with touching a blank /proc/mounts works, FWIW.

You're "--force" patch works even better however ;) Thanks!

=2E:Justin:.

Quoted 118 lines · Goffredo Baroncelli

From: Goffredo Baroncelli <[email protected]>
Subject: Re: Odd mkbtrfs behavior inside of chroot
To: "J G" <[email protected]>
Cc: [email protected]
Date: Sunday, January 2, 2011, 3:14 PM
Quoted 2 lines · J G
I just encountered some odd behavior from mkbtrfs. The end goal is to restore a backup to newly created
BTRFS partitions while using the latest btrfs-tools.=20
Quoted 3 lines
Here's the steps to what I did:
* Booted SystemRescueCD
* Partitioned the drives (two 750GB drives with 12
partitions each)
Quoted 1 line
* Created an extra partition on sda as a temporary
holding place for the backed up files and so I can update btrfs-tools
Quoted 1 line
* Formatted/mounted/restored backup files to the
temporary partition which I mounted on /mnt/backup
Quoted 1 line
* mount -t proc none /mnt/backup/proc; mount -o bind
/dev /mnt/backup/dev
Quoted 2 lines
* chroot /mnt/backup /bin/bash
* Updated btrfs-tools to the latest git pull from
today (v0.19-35-g1b444cd-dirty).
Quoted 7 lines
* mkbtrfs /dev/sda5 /dev/sdb5 -L root
=20
mkbtrfs returned with:
=20
error checking /dev/sda5 mount status
=20
So I used strace to find out how it was checking for
the mount status. Now, I'm no expert here, but I'm confused as to just why it failed. The last thing of note:
Quoted 2 lines
=20
lstat("/boot", {st_mode=3DS_IFDIR|0755, st_size=3D4096,
...}) =3D 0
Quoted 1 line
lstat("/boot/sysrcd.dat", 0x7fffb29681e0) =3D -1 ENOENT
(No such file or directory)
Quoted 1 line
close(3)=A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
=A0 =A0 =3D 0
Quoted 1 line
munmap(0x7f11df372000, 4096)=A0 =A0 =A0
=A0 =A0 =A0 =3D 0
Quoted 1 line
write(2, "error checking /dev/sda5 mount s"...,
38error checking /dev/sda5 mount status
Quoted 4 lines
) =3D 38
=20
=20
doesn't explain much. I see that it's checking
/proc/mounts to see what's mounted, and then it fails on stating /boot/sysrcd.dat (which doesn't exist in the non-chrooted FS, btw).
Quoted 2 lines
=20
To make this even weirder, if I format sda5/sdb5 using
the SysRescCD version of mkbtrfs (v0.19) and then format sda5/sdb5 using the chroot version, it works fine.
Quoted 2 lines
=20
Any ideas here? I would expect that mkbtrfs would work
inside of a chroot without any assistance from the original root.
Quoted 2 lines
=20
I have the full strace from the chrooted mkbtrfs
failing and from it succeeding, if that's helpful. =20
On the basis of the provided information, and on the code it seems that
mkfs.btrfs tries hard to check that the user is not formatting a mounted
disk (or loop). So mkfs.btrfs scan the /proc/mount file and checks every
devices. To do the check it needs to access the original file if this is
a "loop backend". This is reasonable.
=20
In this case in a chroot-ed environment the loop file is not accessible.
=20
If you need a [dirty] "quick hack" to by-pass the problem (not tested):
- unmount the proc filesystem
- create an empty file /proc/mounts
- run btrfs.fsck
- mount the proc filesystem (removing the fake mounts file)
- perform a "btrfs device scan"
- mount the filesystem
=20
Of course the "right" solution is to add a "--force" switch which
permits to by-pass these checks. Other mkfs.* tools have this switch.
=20
From the mkfs.ext4 man page:
[...]
=A0 =A0 =A0=A0=A0-F=A0
=A0=A0=A0Force mke2fs to create a filesystem,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 even if
the specified device is=A0 not
=A0 =A0 =A0 =A0 =A0 =A0 =A0
a=A0=A0=A0partition=A0 on=A0 a=A0
block=A0 special
=A0 =A0 =A0 =A0 =A0 =A0 =A0 device, or
if=A0 other=A0 parameters=A0 do
=A0 =A0 =A0 =A0 =A0 =A0 =A0 not=A0
make=A0 sense.=A0 In order to force
=A0 =A0 =A0 =A0 =A0 =A0 =A0 mke2fs to
create a=A0 filesystem=A0 even
=A0 =A0 =A0 =A0 =A0 =A0 =A0 if=A0
the=A0 filesystem appears to be in
=A0 =A0 =A0 =A0 =A0 =A0 =A0 use or is
mounted (a truly dangerous
=A0 =A0 =A0 =A0 =A0 =A0 =A0
thing=A0 to=A0 do),=A0 this option must be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 specified
twice.
=20
[...]
=20
=20

Quoted 10 lines

Quoted 7 lines
=20
.:Justin:.
=20
=20
=A0 =A0 =A0=A0=A0
--
To unsubscribe from this list: send the line
"unsubscribe linux-btrfs" in
Quoted 2 lines
the body of a message to [email protected]
More majordomo info at=A0 http://vger.kernel.org/majordomo-info.htm=

Quoted 4 lines

Quoted 2 lines
.
=20
=20
=20

--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" = in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html