Re: How to debug Yubikey communication

[Kamil Jońca]

Kamil Jońca  writes:

> I have strange problem.
>
> I use Yubikey 5 with OATH and gpg key applications configured on it.
>
> In general it works (i.e. I got oath codes and can use gpg to
> encrypt/decrypt messages.)
> But when this key is in usb port it "gold circle" lights withut any
> visible reason.

After some deeper digging I think I found "guilty"

It was "security device" in firefox
--8<---cut here---start->8---
library=/usr/lib/x86_64-linux-gnu/onepin-opensc-pkcs11.so
name=OpenSC smartcard framework (0.22)
--8<---cut here---end--->8---

which used library from opensc-pkcs11 package.


KJ

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: preseeding Bullseye

[john doe]

On 11/13/2021 5:39 PM, André Rodier wrote:


Hello all,

I am building a preseed file for Debian Bullseye.

I am able to configure many advanced features, like LUKS / LVM, etc.

However, I still have one question asked at the beginning of the
installer, about the keyboard variant (see the attached image)

For instance, I can select British, and then, the installation continues.

I am attaching the full preseed file I use.



Does it work if you do what is suggested at (1):


"### Localization
# Preseeding only locale sets language, country and locale.
d-i debian-installer/locale string en_US

# The values can also be preseeded individually for greater flexibility.
#d-i debian-installer/language string en
#d-i debian-installer/country string NL
#d-i debian-installer/locale string en_GB.UTF-8
# Optionally specify additional locales to be generated.
#d-i localechooser/supported-locales multiselect en_US.UTF-8, nl_NL.UTF-8

# Keyboard selection.
d-i keyboard-configuration/xkb-keymap select us
# d-i keyboard-configuration/toggle select No toggling"


Also look at the logs (2) to see what's going on!

Note that this e-mail is folded by my mailer.

1)  https://www.debian.org/releases/bullseye/example-preseed.txt
2)  https://www.debian.org/releases/stable/i386/ch05s04

--
John Doe

Re: PAM two factors authentication

[Kamil Jońca]

Kamil Jońca  writes:

> 2. and probably use substack
> (http://linux-pam.org/Linux-PAM-html/sag-configuration-file.html) but,
> honestly I did tested it.
> KJ
Should be "I did NOT tested it" :( Sorry.
KJ


-- 
http://stopstopnop.pl/stop_stopnop.pl_o_nas.html

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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-

Re: Where do I find the definitive man page for mdadm?

[Greg Wooledge]

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

Re: Where do I find the definitive man page for mdadm?

[Tom Dial]

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: 

Re: PAM two factors authentication

[Celejar]

On Sat, 13 Nov 2021 19:13:27 +0100
Kamil Jońca  wrote:

> André Rodier  writes:
> 
> > Hello all,
> >
> > I can use various second factors authentications on Debian:
> >
> > - google authenticator
> > - u2f key
> > - yubikey
> >
> > I would like to configure pam sessions to have 1) password
> > authentication, and then 2) one of the second factor described above.
> >
> > How this can be achieved, please ?
> >
> > Thanks for your answers.
> >
> > André Rodier.
> >
> 
> Well.
> I can say that I follow:
> https://support.yubico.com/hc/en-us/articles/360016649099-Ubuntu-Linux-Login-Guide-U2F
> and I can use my ubikey (I believe its u2f application) to login/unlock.

And see:

https://wiki.debian.org/Security/U2F

(I've written bits of that page.)

> KJ

Celejar

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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  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:00 931.5G  0 disk
> ├─sda1   8:10   260M  0 part /boot/efi  4C30-7972
> ├─sda2   8:2016M  0 part
> ├─sda3   8:30  92.2G  0 part7294B93794B8FEA3
> ├─sda4   8:40   980M  0 part609E71C79E71966E
> ├─sda5   8:50  11.5G  0 part6858F6A458F66FE4
> ├─sda6   8:60  11.2G  0 part [SWAP]
> 08c87bdb-17f4-40ab-9b2f-5cb2f29149fb ├─sda7   8:70  23.3G  0 part
> /  c4691ccb-2090-491e-8e82-d7cc822db04a ├─sda8   8:80 
> 23.3G  0 part /home  19fb397b-a113-4536-a03d-d60e176cbfdf └─sda9  
> 8:90 651.9G  0 part /stuff
> 95058c4a-44e2-4a90-87b5-2a5fe40d3cdb sr0 11:01 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
NAMEMAJ:MIN RM   SIZE RO TYPE   MOUNTPOINT   UUID
sda   8:00   1.8T  0 disk
├─sda18:10   953M  0 part   /boot
06aa3215-a6a6-4fbb-86ca-186c47e1334c
├─sda28:20  14.9G  0 part   [SWAP]   
8b675a91-5aa5-401b-bf50-d8afc3e8115a
├─sda38:30  46.6G  0 part   /var 
ee491e5c-7394-434f-b50a-f4354f6c9869
├─sda48:40 1K  0 part
└─sda58:50   1.8T  0 part   /
0e698024-1cf3-4dbc-812d-10552c01caab
sdb   8:16   0 223.6G  0 disk
└─sdb18:17   0 223.6G  0 part   /sdb 
4982ee4c-58c4-4d2b-b9d5-69344c3cb090
sdc   8:32   0   1.8T  0 disk
└─sdc18:33   0   1.8T  0 part   /amandatapes 
3b6848c1-7b09-43be-a7aa-ae63d82f5f26
sde   8:64   0 931.5G  0 disk
├─sde18:65   0 878.9G  0 part
3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:00   1.7T  0 raid10 /home2   
708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sde28:66   0  48.8G  0 part
ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:10  97.6G  0 raid10 /snapshot
733718b2-e7f8-4b00-a390-264e5c73c453
sdf   8:80   0 931.5G  0 disk
├─sdf18:81   0 878.9G  0 part
3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:00   1.7T  0 raid10 /home2   
708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sdf28:82   0  48.8G  0 part
ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:10  97.6G  0 raid10 /snapshot
733718b2-e7f8-4b00-a390-264e5c73c453
sdg   8:96   0 931.5G  0 disk
├─sdg18:97   0 878.9G  0 part
3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:00   1.7T  0 raid10 /home2   
708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sdg28:98   0  48.8G  0 part
ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:10  97.6G  0 raid10 /snapshot
733718b2-e7f8-4b00-a390-264e5c73c453
sdh   8:112  0 931.5G  0 disk
├─sdh18:113  0 878.9G  0 part
3d5a3621-c0e3-2c8a-e3f7-ebb3318edbfb
│ └─md0   9:00   1.7T  0 raid10 /home2   
708320b3-10af-4c15-b5b1-a9ff7be06d99
└─sdh28:114  0  48.8G  0 part
ddb6ffa2-e068-b701-f316-cc5f83938a13
  └─md1   9:10  97.6G  0 raid10 /snapshot
733718b2-e7f8-4b00-a390-264e5c73c453
sr0  11:01  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 

Re: Where do I find the definitive man page for mdadm?

[Greg Wooledge]

On Sat, Nov 13, 2021 at 04:06:43PM -0700, Charles Curley wrote:
> On Sat, 13 Nov 2021 16:57:01 -0500
> Gene Heskett  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:00 931.5G  0 disk
├─sda1   8:10   260M  0 part /boot/efi  4C30-7972
├─sda2   8:2016M  0 part
├─sda3   8:30  92.2G  0 part7294B93794B8FEA3
├─sda4   8:40   980M  0 part609E71C79E71966E
├─sda5   8:50  11.5G  0 part6858F6A458F66FE4
├─sda6   8:60  11.2G  0 part [SWAP] 08c87bdb-17f4-40ab-9b2f-5cb2f29149fb
├─sda7   8:70  23.3G  0 part /  c4691ccb-2090-491e-8e82-d7cc822db04a
├─sda8   8:80  23.3G  0 part /home  19fb397b-a113-4536-a03d-d60e176cbfdf
└─sda9   8:90 651.9G  0 part /stuff 95058c4a-44e2-4a90-87b5-2a5fe40d3cdb
sr0 11:01 418.7M  0 rom

Re: Where do I find the definitive man page for mdadm?

[Charles Curley]

On Sat, 13 Nov 2021 16:57:01 -0500
Gene Heskett  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/

Re: set the number of inodes during FS creation via pressed

[David]

On Sun, 14 Nov 2021 at 04:10, David Wright  wrote:
> On Sat 13 Nov 2021 at 00:31:42 (+), phoebus phoebus wrote:

> > Do you know if it possible to set the number of inodes  to create in
> > the filesystem during the installalation with the pressed file?

> > If i start from this example for the filesystem /var/log, how to set
> > numbers of inodes inside it ?

> > 500 550 1024 ext4 \lv_name{ varlog } \
> > method{ lvm } format{ } \
> > use_filesystem{ } filesystem{ ext4 } \
> > label{ varlog } \
> > mountpoint{ /var/log } \
> > options/nodev{ nodev } \
> > options/nosuid{ nosuid } \
> > options/noexec{ noexec } \
> > options/relatime{ relatime } \
> > $lvmok{ } \
> > . \

> > Hope to do it as mkfs do it: mkfs -t ext4 -N iNumberOfINodes /dev/XdY ?

> I don't know about the actual number, but I think there's a crude
> switch under   use_filesystem{ }   which can be set, from memory,
> to one of three options, Standard, large files (fewer inodes for,
> say, multimedia) and lots of files (more inodes, say, mail server).
> I've only seen the choice (years ago) in the interactive d-i,
> and don't know the magic preseed terms.

This site is quite useful:
  https://preseed.debian.net/debian-preseed/

>From there I found this file for bullseye:
  https://preseed.debian.net/debian-preseed/bullseye/amd64-main-full.txt

which contains this stanza which appears to match your description:

### Description: Typical usage of this partition:
#   Please specify how the file system is going to be used, so that
#   optimal file system parameters can be chosen for that use.
#   .
#   standard = standard parameters,
#   news = one inode per 4KB block,
#   largefile = one inode per megabyte,
#   largefile4 = one inode per 4 megabytes.
# d-i partman-basicfilesystems/specify_usage select 
# Possible choices: ${CHOICES}

Which is not what the OP requested, but maybe it helps.  It is the only
occurrence of "inode" in that file.  I did not check the other two files
that contain the "contrib" and "non-free" data.

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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

Re: processor compatibility

[Georgi Naplatanov]

On 11/13/21 22:39, deutsch_da...@tuta.io wrote:
> Hello! Is the Intel Core i7-9750H processor supported by your operating
> system?
> 

Hi!

The architecture of this processor is AMD64 so it's supported and you
can use this image -

https://cdimage.debian.org/cdimage/unofficial/non-free/cd-including-firmware/11.1.0+nonfree/amd64/iso-cd/firmware-11.1.0-amd64-netinst.iso

Kind regards
Georgi

Re: processor compatibility

[Andy Smith]

Hello,

On Sat, Nov 13, 2021 at 09:39:16PM +0100, deutsch_da...@tuta.io wrote:
> Hello! Is the Intel Core i7-9750H processor supported by your operating 
> system?

I don't have one but this suggests yes:

https://linux-hardware.org/index.php?id=cpu:intel-6-158-10-core-i7-9750h

That CPU is a couple of years old now so I would not expect it to
have any feature or quirk that makes it difficult to use with Linux,
and the many pages of Linux distributions there that say they work
support that.

Cheers,
Andy

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

processor compatibility

[deutsch_danya]

Hello! Is the Intel Core i7-9750H processor supported by your operating system?

-- 
.

Re: Where do I find the definitive man page for mdadm?

[Andy Smith]

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

Re: Problem with Synaptic

[Brian]

On Sat 13 Nov 2021 at 11:50:00 -0500, Stephen P. Molnar wrote:

> On 11/13/2021 11:33 AM, Brian wrote:
> > Eduardo M KALINOWSKI provided what looks like a useful link. Any help
> > there?
> > 
> I am certainly embarrassed. Solution #1 of the 6 in that link solved the
> problem.

Very satisfying.

BTW, in my first post I was was not urging you to upgrade to bullseye
but presenting the facts concerning printing and scanning on buster
bullseye. Should you wish to free yourself from the non-free Brother
drivers the choice is yours.

-- 
Brian.

Re: How to debug Yubikey communication

[Kamil Jońca]

Teemu Likonen  writes:

> * 2021-11-13 18:23:13+0100, Kamil Jońca wrote:
>
>> I use Yubikey 5 with OATH and gpg key applications configured on it.
>
>> How can I debug communication with this key?
>
> Edit ~/.gnupg/scdaemon.conf file and add lines there:
>
> debug-level 8
> log-file /tmp/scdaemon.log
>
> You should probably read some of the "man scdaemon" manual too.
>
> I don't know about your actual problem and probably can't help with PGP

So do I :/
I even does not know if it is related to u2f/gpg/oath
KJ

http://wolnelektury.pl/wesprzyj/teraz/

Re: PAM two factors authentication

[Kamil Jońca]

André Rodier  writes:

> Hello Kamil,
>
> This is not exactly what I asked.
>
> I want two factors authentication, with the first factor (the
> password) and the second one being one of many (Yubikey, google auth
> or u2f)

Please do not top post.
One thing: what do you mean "yubikey" in this context?
Yubikey (at least 5 which I own) have some "applications" and can act as
u2f key or generate codes compatible with google auth (I least I was
able to use it as a replacement for google auth).
Or you mean its own challenge-response protocol?
And if I understand you correctly you should:
1. verify if there are pam modules (at least for u2f and yubico answer
is "yes")
2. and probably use substack
(http://linux-pam.org/Linux-PAM-html/sag-configuration-file.html) but,
honestly I did tested it.
KJ



>
> Thanks,
>
> On 13/11/2021 18:13, Kamil Jońca wrote:
>> André Rodier  writes:
>> 
>>> Hello all,
>>>
>>> I can use various second factors authentications on Debian:
>>>
>>> - google authenticator
>>> - u2f key
>>> - yubikey
>>>
>>> I would like to configure pam sessions to have 1) password
>>> authentication, and then 2) one of the second factor described above.
>>>
>>> How this can be achieved, please ?
>>>
>>> Thanks for your answers.
>>>
>>> André Rodier.
>>>
>> Well.
>> I can say that I follow:
>> https://support.yubico.com/hc/en-us/articles/360016649099-Ubuntu-Linux-Login-Guide-U2F
>> and I can use my ubikey (I believe its u2f application) to login/unlock.
>> 
>> KJ
>> 

-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: How to debug Yubikey communication

[Teemu Likonen]

* 2021-11-13 18:23:13+0100, Kamil Jońca wrote:

> I use Yubikey 5 with OATH and gpg key applications configured on it.

> How can I debug communication with this key?

Edit ~/.gnupg/scdaemon.conf file and add lines there:

debug-level 8
log-file /tmp/scdaemon.log

You should probably read some of the "man scdaemon" manual too.

I don't know about your actual problem and probably can't help with PGP
smart cards. In addition to this mailing list gnupg-users list is a good
option too.

https://lists.gnupg.org/mailman/listinfo/gnupg-users

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 6965F03973F0D4CA22B9410F0F2CAE0E07608462


signature.asc
Description: PGP signature

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

On Saturday 13 November 2021 11:41:00 David Wright wrote:

> On Sat 13 Nov 2021 at 07:26:04 (-0500), Gene Heskett wrote:
> > My mdadm manpage does not show the -S command. Scanniing it again to
> > make sure, probably for about the 10th time and I finally found it
> > but many megabytes of relatively unimportant drivel down from the
> > top, IMO the manpage is missleading as such an important option
> > ought to be shown on the first screenfull.
>
> You could sponsor it—just reply to one of those junk emails,
> "Get top page ranking!"

Sure, and its a good thing these jerks can't be located, as I know where 
an old mine cache is, with several 1 cup containers of 75 yo nitro that 
ought to be really unstable by now in it. Probably someones sick idea 
for darwin award bait. I would have spoiled their fun by backing off a 
couple hundred meters and seeing what effect an Ackley-06 rattling 
around inside it had, but it looked like I might be ducking a 200lb 
steel door if I did. So I walked off and went back to deer hunting.  
Safer.

> Serously, you need only type /\-S into less, if you set it as
> your manpage viewer,  export MANOPT="-P less"
>
> I would make one small criticism of some manpages; for example:
> chmod has its arguments documented in running text, whereas a
> table would be much easier to scan:
>
>   A combination of the letters ugoa controls which users' access
>   to the file will be changed:
> u the user who owns it,
> g other users in the file's group,
> o other users not in the file's group,
> a all users.
> none  the effect is as if (a) were given, but bits
>   that are set in the umask are not affected.
>
> compared with:
>
>   A combination of the letters ugoa controls which users'
>   access to the file will be changed: the user  who  owns
>   it  (u),  other  users  in  the file's group (g), other
>   users not in the file's group (o), or  all  users  (a).
>   If  none  of  these  are given, the effect is as if (a)
>   were given, but bits that are set in the umask are  not
>   affected.
>
> Cheers,
> David.

Plus 100 or more, David.  That wall of text has confused me since red hat 
5.0 in 1998. Soon to be 25 years. This has been a linux only house for 
that long.

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 

Re: PAM two factors authentication

[André Rodier]

Hello Kamil,

This is not exactly what I asked.

I want two factors authentication, with the first factor (the password) 
and the second one being one of many (Yubikey, google auth or u2f)


Thanks,

On 13/11/2021 18:13, Kamil Jońca wrote:

André Rodier  writes:


Hello all,

I can use various second factors authentications on Debian:

- google authenticator
- u2f key
- yubikey

I would like to configure pam sessions to have 1) password
authentication, and then 2) one of the second factor described above.

How this can be achieved, please ?

Thanks for your answers.

André Rodier.



Well.
I can say that I follow:
https://support.yubico.com/hc/en-us/articles/360016649099-Ubuntu-Linux-Login-Guide-U2F
and I can use my ubikey (I believe its u2f application) to login/unlock.


KJ




--
𝓐𝓡 - André Rodier

Re: PAM two factors authentication

[Kamil Jońca]

André Rodier  writes:

> Hello all,
>
> I can use various second factors authentications on Debian:
>
> - google authenticator
> - u2f key
> - yubikey
>
> I would like to configure pam sessions to have 1) password
> authentication, and then 2) one of the second factor described above.
>
> How this can be achieved, please ?
>
> Thanks for your answers.
>
> André Rodier.
>

Well.
I can say that I follow:
https://support.yubico.com/hc/en-us/articles/360016649099-Ubuntu-Linux-Login-Guide-U2F
and I can use my ubikey (I believe its u2f application) to login/unlock.


KJ


-- 
http://wolnelektury.pl/wesprzyj/teraz/

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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 

Re: preseeding Bullseye

[Brian]

On Sat 13 Nov 2021 at 16:39:55 +, André Rodier wrote:

> 
> Hello all,
> 
> I am building a preseed file for Debian Bullseye.
> 
> I am able to configure many advanced features, like LUKS / LVM, etc.
> 
> However, I still have one question asked at the beginning of the installer,
> about the keyboard variant (see the attached image)
> 
> For instance, I can select British, and then, the installation continues.

Perhaps not exactly what you want, but I preseed language and keyboard
with boot paramters:

  locale=en_GB.UTF-8 keymap=gb

-- 
Brian.

How to debug Yubikey communication

[Kamil Jońca]

I have strange problem.

I use Yubikey 5 with OATH and gpg key applications configured on it.

In general it works (i.e. I got oath codes and can use gpg to
encrypt/decrypt messages.)
But when this key is in usb port it "gold circle" lights withut any
visible reason.

How can I debug communication with this key?
I tried something like:

find /dev/ -mmin -10 |grep -v '^/dev/pts'|grep -v -x '/dev/'|xargs -d '\n' 
inotifywait -m -r --format '%T %w <%f> %e' --timefmt '%Y%m%d %H%M%S' 
/dev/hidraw2
(after putting yubikey into usb port) but without success

Any ideas?
KJ


-- 
http://wolnelektury.pl/wesprzyj/teraz/

PAM two factors authentication

[André Rodier]

Hello all,

I can use various second factors authentications on Debian:

- google authenticator
- u2f key
- yubikey

I would like to configure pam sessions to have 1) password 
authentication, and then 2) one of the second factor described above.


How this can be achieved, please ?

Thanks for your answers.

André Rodier.

Re: set the number of inodes during FS creation via pressed

[David Wright]

On Sat 13 Nov 2021 at 00:31:42 (+), phoebus phoebus wrote:

> Do you know if it possible to set the number of inodes  to create in the 
> filesystem during the installalation with the pressed file? 
> 
> If i start from this example for the filesystem /var/log, how to set numbers 
> of inodes inside it ?
> 
>     500 550 1024 ext4 \    lv_name{ varlog } \
>     method{ lvm } format{ } \
>     use_filesystem{ } filesystem{ ext4 } \
>     label{ varlog } \
>     mountpoint{ /var/log } \
>     options/nodev{ nodev } \
>     options/nosuid{ nosuid } \
>     options/noexec{ noexec } \
>     options/relatime{ relatime } \
>     $lvmok{ } \
>     . \
> Hope to do it as mkfs do it: mkfs -t ext4 -N iNumberOfINodes /dev/XdY ?

I don't know about the actual number, but I think there's a crude
switch under   use_filesystem{ }   which can be set, from memory,
to one of three options, Standard, large files (fewer inodes for,
say, multimedia) and lots of files (more inodes, say, mail server).
I've only seen the choice (years ago) in the interactive d-i,
and don't know the magic preseed terms.

Cheers,
David.

Re: Problem with Synaptic

[Stephen P. Molnar]

On 11/13/2021 11:33 AM, Brian wrote:

On Sat 13 Nov 2021 at 09:53:41 -0500, Stephen P. Molnar wrote:



On 11/12/2021 02:01 PM, Brian wrote:

On Fri 12 Nov 2021 at 07:30:36 -0500, Stephen P. Molnar wrote:


On 11/11/2021 03:11 PM, Brian wrote:

On Thu 11 Nov 2021 at 14:34:20 -0500, Stephen P. Molnar wrote:


On 11/11/2021 02:06 PM, Brian wrote:

On Thu 11 Nov 2021 at 12:38:33 -0500, Stephen P. Molnar wrote:


I am running buster on my Linux platform.

I have installed a new Brother Laser print using the current Brother
Linux installer.

The MFC-L2710DW is a modern device and is completely supported by
packages shipped with Debian 11 (bullseye). It is also completely
supported for printing via a wireless connection on buster.

The packages needed for USB connections and scanning do not come
with buster but can easily be obtained from

  https://github.com/alexpevzner/sane-airscan

Do yourself a favour and read

  https://wiki.debian.org/CUPSQuickPrintQueues

A user with a device such as yours does not need proprietary,
non-free printing or scanning drivers in 2021.


Very interesting. Thank you.

Interesting indeed. Reaching for printing and scanning drivers,
whether free or non-free, is still a user's first thought. I
suppose one should work to tackle the issue you outline but
switching to driverless printing and scanning is a lot easier
and makes most problems involving drivers go away. Additionally,
it future-proofs the printing and scanning systems.


This is the immediate problem that I need to fix:

comp@AbNormal:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: The package brscan4 needs to be reinstalled, but I can't find an archive
for it.

Did this command then complete and give a prompt?

sudo apt update ran without any problems.

Did the output say how many packages needed to be upgraded?

Can you scan?


sudo apt update ran and:

2 packages can be upgraded. Run 'apt list --upgradable' to see them.

Sudo apt upgrade asked for a prompt and then spat out:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: The package brscan4 needs to be reinstalled, but I can't find an archive
for it.
comp@AbNormal:~$

Eduardo M KALINOWSKI provided what looks like a useful link. Any help
there?

I am certainly embarrassed. Solution #1 of the 6 in that link solved the 
problem.


I am very grateful for all of t he assistance. It's one of teh many 
things that makes Debian great.


--
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1

preseeding Bullseye

[André Rodier]

Hello all,

I am building a preseed file for Debian Bullseye.

I am able to configure many advanced features, like LUKS / LVM, etc.

However, I still have one question asked at the beginning of the 
installer, about the keyboard variant (see the attached image)


For instance, I can select British, and then, the installation continues.

I am attaching the full preseed file I use.

Thanks for your help.

André Rodier.
 Preseed for one drive, using just an LVM partitioning scheme


# The values can also be preseeded individually for greater flexibility.
d-i debian-installer/language string en_GB:en
d-i debian-installer/country string UK
d-i debian-installer/locale string en_GB

# Optionally specify additional locales to be generated.
# d-i localechooser/supported-locales multiselect en_GB.UTF-8

# Keyboard selection.
# d-i console-keymaps-at/keymap string gb
d-i keyboard-configuration/xkb-keymap select gb
d-i keyboard-configuration/variant select British English
d-i keyboard-configuration/toggle select No toggling

# Do not scan for another CD
d-i apt-setup/use_mirror boolean false
d-i apt-setup/cdrom/set-first boolean false
d-i apt-setup/cdrom/set-next boolean false
d-i apt-setup/cdrom/set-failed boolean false


### Apt setup
# You can choose to install non-free and contrib software.
d-i apt-setup/non-free boolean true
d-i apt-setup/contrib boolean true
d-i apt-setup/use_mirror boolean true

# Select which update services to use; define the mirrors to be used.
# Values shown below are the normal defaults.
d-i apt-setup/services-select multiselect security, updates
d-i apt-setup/security_host string security.debian.org

# Additional repositories, local[0-9] available
# d-i apt-setup/local0/repository string \
# http://dl.google.com/linux/chrome/deb/ stable main
# d-i apt-setup/local0/comment string Google chrome

# URL to the public key of the local repository; you must provide a key or
# apt will complain about the unauthenticated repository and so the
# sources.list line will be left commented out
# d-i apt-setup/local0/key string 
https://dl.google.com/linux/linux_signing_key.pub

# Enable deb-src lines
#d-i apt-setup/local0/source boolean true

# By default the installer requires that repositories be authenticated
# using a known gpg key. This setting can be used to disable that
# authentication. Warning: Insecure, not recommended.
#d-i debian-installer/allow_unauthenticated boolean true

# Uncomment this to add multiarch configuration for i386
#d-i apt-setup/multiarch string i386
### Network configuration
# Disable network configuration entirely. This is useful for cdrom
# installations on non-networked devices where the network questions,
# warning and long timeouts are a nuisance.
#d-i netcfg/enable boolean false

# netcfg will choose an interface that has link if possible. This makes it
# skip displaying a list if there is more than one interface.
# d-i netcfg/choose_interface select auto
d-i netcfg/choose_interface select auto

# To set a different link detection timeout (default is 3 seconds).
# Values are interpreted as seconds.
#d-i netcfg/link_wait_timeout string 10

# If you have a slow dhcp server and the installer times out waiting for
# it, this might be useful.
#d-i netcfg/dhcp_timeout string 60
#d-i netcfg/dhcpv6_timeout string 60

# If you prefer to configure the network manually, uncomment this line and
# the static network configuration below.
#d-i netcfg/disable_autoconfig boolean true

# Any hostname and domain names assigned from dhcp take precedence over
# values set here. However, setting the values still prevents the questions
# from being shown, even if values come from dhcp.
d-i netcfg/get_hostname string mail
d-i netcfg/get_domain string rodier.me

# If you want to force a hostname, regardless of what either the DHCP
# server returns or what the reverse DNS entry for the IP is, uncomment
# and adjust the following line.
#d-i netcfg/hostname string somehost

# Disable that annoying WEP key dialog.
d-i netcfg/wireless_wep string

# The wacky dhcp hostname that some ISPs use as a password of sorts.
#d-i netcfg/dhcp_hostname string radish

# If non-free firmware is needed for the network or other hardware, you can
# configure the installer to always try to load it, without prompting. Or
# change to false to disable asking.
d-i hw-detect/load_firmware boolean false
### Network console1
# Use the following settings if you wish to make use of the network-console
# component for remote installation over SSH. This only makes sense if you
# intend to perform the remainder of the installation manually.
#d-i anna/choose_modules string network-console
#d-i network-console/authorized_keys_url string http://10.0.0.1/openssh-key
#d-i network-console/password password r00tme
#d-i network-console/password-again password r00tme

### Mirror settings
# If you select ftp, the mirror/country string does not need to be set.
#d-i mirror/protocol string ftp
d-i mirror/country string manual
d-i

Re: why autoremove doesn't work

[David Wright]

It helps to attach the scripts!

Cheers,
David.
aptitude why libperl5.32 
echo
aptitude why libtimedate-perl 
echo
aptitude why libhtml-tagset-perl 
echo
aptitude why libgdbm-compat4 
echo
aptitude why libtie-ixhash-perl 
echo
aptitude why libnet-ssleay-perl 
echo
aptitude why libauthen-sasl-perl 
echo
aptitude why libio-socket-ssl-perl 
echo
aptitude why libwww-robotrules-perl 
echo
aptitude why cpp 
echo
aptitude why libhtml-form-perl 
echo
aptitude why liblwp-protocol-https-perl 
echo
aptitude why libwww-perl 
echo
aptitude why libtry-tiny-perl 
echo
aptitude why perl 
echo
aptitude why gir1.2-freedesktop 
echo
aptitude why libx11-protocol-perl 
echo
aptitude why libfile-mimeinfo-perl 
echo
aptitude why libgtk3-perl 
echo
aptitude why libhttp-negotiate-perl 
echo
aptitude why libfont-afm-perl 
echo
aptitude why gir1.2-glib-2.0 
echo
aptitude why gir1.2-gdkpixbuf-2.0 
echo
aptitude why libxml-xpathengine-perl 
echo
aptitude why libencode-locale-perl 
echo
aptitude why bzip2 
echo
aptitude why libdata-dump-perl 
echo
aptitude why liblwp-mediatypes-perl 
echo
aptitude why libfile-desktopentry-perl 
echo
aptitude why libhtml-tree-perl 
echo
aptitude why libmpfr6 
echo
aptitude why libmailtools-perl 
echo
aptitude why gir1.2-gtk-3.0 
echo
aptitude why libextutils-depends-perl 
echo
aptitude why libmpc3 
echo
aptitude why xz-utils 
echo
aptitude why libextutils-pkgconfig-perl 
echo
aptitude why liburi-perl 
echo
aptitude why libhttp-cookies-perl 
echo
aptitude why libgirepository-1.0-1 
echo
aptitude why libio-html-perl 
echo
aptitude why libfile-fcntllock-perl 
echo
aptitude why libnet-http-perl 
echo
aptitude why libio-stringy-perl 
echo
aptitude why libipc-system-simple-perl 
echo
aptitude why libhtml-format-perl 
echo
aptitude why libhttp-date-perl 
echo
aptitude why libfile-basedir-perl 
echo
aptitude why libhtml-parser-perl 
echo
aptitude why pkg-config 
echo
aptitude why cpp-10 
echo
aptitude why gir1.2-atk-1.0 
echo
aptitude why perl-openssl-defaults 
echo
aptitude why libdpkg-perl 
echo
aptitude why gir1.2-pango-1.0 
echo
aptitude why x11-xserver-utils 
echo
aptitude why libclone-perl 
echo
aptitude why libisl23 
echo
aptitude why xdg-utils 
echo
aptitude why libxml-twig-perl 
echo
aptitude why libcairo-gobject-perl 
echo
aptitude why libpangoxft-1.0-0 
echo
aptitude why libhttp-message-perl 
echo
aptitude why libfile-listing-perl 
echo
aptitude why gir1.2-harfbuzz-0.0 
echo
aptitude why libxml-parser-perl 
echo
aptitude why perl-modules-5.32 
echo
aptitude why libglib-object-introspection-perl 
echo
aptitude why libnet-dbus-perl 
echo
aptitude why libglib-perl 
echo
aptitude why libcairo-perl 
echo
aptitude why libnet-smtp-ssl-perl 
echo
aptitude why libhttp-daemon-perl 
apt-get -s remove libperl5.32 libtimedate-perl libhtml-tagset-perl 
libgdbm-compat4 libtie-ixhash-perl libnet-ssleay-perl libauthen-sasl-perl 
libio-socket-ssl-perl libwww-robotrules-perl cpp libhtml-form-perl 
liblwp-protocol-https-perl libwww-perl libtry-tiny-perl perl gir1.2-freedesktop 
libx11-protocol-perl libfile-mimeinfo-perl libgtk3-perl libhttp-negotiate-perl 
libfont-afm-perl gir1.2-glib-2.0 gir1.2-gdkpixbuf-2.0 libxml-xpathengine-perl 
libencode-locale-perl bzip2 libdata-dump-perl liblwp-mediatypes-perl 
libfile-desktopentry-perl libhtml-tree-perl libmpfr6 libmailtools-perl 
gir1.2-gtk-3.0 libextutils-depends-perl libmpc3 xz-utils 
libextutils-pkgconfig-perl liburi-perl libhttp-cookies-perl 
libgirepository-1.0-1 libio-html-perl libfile-fcntllock-perl libnet-http-perl 
libio-stringy-perl libipc-system-simple-perl libhtml-format-perl 
libhttp-date-perl libfile-basedir-perl libhtml-parser-perl pkg-config cpp-10 
gir1.2-atk-1.0 perl-openssl-defaults libdpkg-perl gir1.2-pango-1.0 
x11-xserver-utils libclone-perl libisl23 xdg-utils libxml-twig-perl 
libcairo-gobject-perl libpangoxft-1.0-0 libhttp-message-perl 
libfile-listing-perl gir1.2-harfbuzz-0.0 libxml-parser-perl perl-modules-5.32 
libglib-object-introspection-perl libnet-dbus-perl libglib-perl libcairo-perl 
libnet-smtp-ssl-perl libhttp-daemon-perl 

Re: Where do I find the definitive man page for mdadm?

[David Wright]

On Sat 13 Nov 2021 at 07:26:04 (-0500), Gene Heskett wrote:

> My mdadm manpage does not show the -S command. Scanniing it again to make 
> sure, probably for about the 10th time and I finally found it but many 
> megabytes of relatively unimportant drivel down from the top, IMO the 
> manpage is missleading as such an important option ought to be shown on 
> the first screenfull.

You could sponsor it—just reply to one of those junk emails,
"Get top page ranking!"

Serously, you need only type /\-S into less, if you set it as
your manpage viewer,  export MANOPT="-P less"

I would make one small criticism of some manpages; for example:
chmod has its arguments documented in running text, whereas a
table would be much easier to scan:

  A combination of the letters ugoa controls which users' access
  to the file will be changed:
u the user who owns it,
g other users in the file's group,
o other users not in the file's group,
a all users.
none  the effect is as if (a) were given, but bits
  that are set in the umask are not affected.

compared with:

  A combination of the letters ugoa controls which users'
  access to the file will be changed: the user  who  owns
  it  (u),  other  users  in  the file's group (g), other
  users not in the file's group (o), or  all  users  (a).
  If  none  of  these  are given, the effect is as if (a)
  were given, but bits that are set in the umask are  not
  affected.

Cheers,
David.

Re: Where do I find the definitive man page for mdadm?

[David Wright]

On Sat 13 Nov 2021 at 14: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.

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.

Re: why autoremove doesn't work

[David Wright]

On Sat 13 Nov 2021 at 06:18:53 (+), Long Wind wrote:
> Thanks again!
> here is my /var/log/apt/history.log, many packages are not auto removed
> do you think autoremove option work as promised in apt's manual?

AFAICT, but I haven't looked too deeply, it's Recommends by other
packages that usually cause a problem.

Anyway, here are two scripts. Save them to /tmp, and run with
$ bash why
$ bash remove
as a user. Both may produce a lot of output. The first will tell you
why each package is being kept. The second will pretend that it's
removing them all, and ought to "succeed" if there are no Depends
outside of each other, but only Recommends.

Cheers,
David.

Re: Problem with Synaptic

[Brian]

On Sat 13 Nov 2021 at 09:53:41 -0500, Stephen P. Molnar wrote:

> 
> 
> On 11/12/2021 02:01 PM, Brian wrote:
> > On Fri 12 Nov 2021 at 07:30:36 -0500, Stephen P. Molnar wrote:
> > 
> > > 
> > > On 11/11/2021 03:11 PM, Brian wrote:
> > > > On Thu 11 Nov 2021 at 14:34:20 -0500, Stephen P. Molnar wrote:
> > > > 
> > > > > On 11/11/2021 02:06 PM, Brian wrote:
> > > > > > On Thu 11 Nov 2021 at 12:38:33 -0500, Stephen P. Molnar wrote:
> > > > > > 
> > > > > > > I am running buster on my Linux platform.
> > > > > > > 
> > > > > > > I have installed a new Brother Laser print using the current 
> > > > > > > Brother
> > > > > > > Linux installer.
> > > > > > The MFC-L2710DW is a modern device and is completely supported by
> > > > > > packages shipped with Debian 11 (bullseye). It is also completely
> > > > > > supported for printing via a wireless connection on buster.
> > > > > > 
> > > > > > The packages needed for USB connections and scanning do not come
> > > > > > with buster but can easily be obtained from
> > > > > > 
> > > > > >  https://github.com/alexpevzner/sane-airscan
> > > > > > 
> > > > > > Do yourself a favour and read
> > > > > > 
> > > > > >  https://wiki.debian.org/CUPSQuickPrintQueues
> > > > > > 
> > > > > > A user with a device such as yours does not need proprietary,
> > > > > > non-free printing or scanning drivers in 2021.
> > > > > > 
> > > > > Very interesting. Thank you.
> > > > Interesting indeed. Reaching for printing and scanning drivers,
> > > > whether free or non-free, is still a user's first thought. I
> > > > suppose one should work to tackle the issue you outline but
> > > > switching to driverless printing and scanning is a lot easier
> > > > and makes most problems involving drivers go away. Additionally,
> > > > it future-proofs the printing and scanning systems.
> > > > 
> > > This is the immediate problem that I need to fix:
> > > 
> > > comp@AbNormal:~$ sudo apt upgrade
> > > Reading package lists... Done
> > > Building dependency tree
> > > Reading state information... Done
> > > E: The package brscan4 needs to be reinstalled, but I can't find an 
> > > archive
> > > for it.
> > Did this command then complete and give a prompt?
> > > sudo apt update ran without any problems.
> > Did the output say how many packages needed to be upgraded?
> > 
> > Can you scan?
> > 
> sudo apt update ran and:
> 
> 2 packages can be upgraded. Run 'apt list --upgradable' to see them.
> 
> Sudo apt upgrade asked for a prompt and then spat out:
> 
> Reading package lists... Done
> Building dependency tree
> Reading state information... Done
> E: The package brscan4 needs to be reinstalled, but I can't find an archive
> for it.
> comp@AbNormal:~$

Eduardo M KALINOWSKI provided what looks like a useful link. Any help
there?

-- 
Brian.
> 
> -- 
> Stephen P. Molnar, Ph.D.
> www.molecular-modeling.net
> 614.312.7528 (c)
> Skype:  smolnar1
> 

Re: Problem with Synaptic

[Stephen P. Molnar]

On 11/12/2021 02:01 PM, Brian wrote:

On Fri 12 Nov 2021 at 07:30:36 -0500, Stephen P. Molnar wrote:



On 11/11/2021 03:11 PM, Brian wrote:

On Thu 11 Nov 2021 at 14:34:20 -0500, Stephen P. Molnar wrote:


On 11/11/2021 02:06 PM, Brian wrote:

On Thu 11 Nov 2021 at 12:38:33 -0500, Stephen P. Molnar wrote:


I am running buster on my Linux platform.

I have installed a new Brother Laser print using the current Brother
Linux installer.

The MFC-L2710DW is a modern device and is completely supported by
packages shipped with Debian 11 (bullseye). It is also completely
supported for printing via a wireless connection on buster.

The packages needed for USB connections and scanning do not come
with buster but can easily be obtained from

 https://github.com/alexpevzner/sane-airscan

Do yourself a favour and read

 https://wiki.debian.org/CUPSQuickPrintQueues

A user with a device such as yours does not need proprietary,
non-free printing or scanning drivers in 2021.


Very interesting. Thank you.

Interesting indeed. Reaching for printing and scanning drivers,
whether free or non-free, is still a user's first thought. I
suppose one should work to tackle the issue you outline but
switching to driverless printing and scanning is a lot easier
and makes most problems involving drivers go away. Additionally,
it future-proofs the printing and scanning systems.


This is the immediate problem that I need to fix:

comp@AbNormal:~$ sudo apt upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: The package brscan4 needs to be reinstalled, but I can't find an archive
for it.

Did this command then complete and give a prompt?
  

sudo apt update ran without any problems.

Did the output say how many packages needed to be upgraded?

Can you scan?


sudo apt update ran and:

2 packages can be upgraded. Run 'apt list --upgradable' to see them.

Sudo apt upgrade asked for a prompt and then spat out:

Reading package lists... Done
Building dependency tree
Reading state information... Done
E: The package brscan4 needs to be reinstalled, but I can't find an 
archive for it.

comp@AbNormal:~$

--
Stephen P. Molnar, Ph.D.
www.molecular-modeling.net
614.312.7528 (c)
Skype:  smolnar1

Re: Where do I find the definitive man page for mdadm?

[Andy Smith]

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

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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

Re: Where do I find the definitive man page for mdadm?

[Andy Smith]

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

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

On Saturday 13 November 2021 07:42:40 The Wanderer wrote:

> apt-cache policy mdadm
mdadm:
  Installed: 3.4-4+b1
  Candidate: 3.4-4+b1
  Version table:
 *** 3.4-4+b1 500
500 http://deb.debian.org/debian stretch/main amd64 Packages
100 /var/lib/dpkg/status

I have another 1T SSD coming, and will remove sda and replace it as sda 
for a new debian 11.1 install, then put it back on an sdd cable to get 
my data back, so now I'm waiting for that drive to arrive. I'm tired of 
the new spinning rust and their volatile errors that go with SMR drives.
They'd make good target practice for my new 6.5 creedmoor barrel.

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 

Re: Dcopserver not loading

[deloptes]

Ken Heard wrote:

> It is consequently my understanding that running the 'dcopserver'
> command is presumably required as part of the initial boot-up.  If such
> is usually the case I would appreciate knowing what I need to do to have
> my computer, named Morcom, do so as well.  Can anyone tell me?

Hi Ken,
how are you starting TDE, do you use the Login Manager TDM?
Usually dcopserver is started by tdeinit AFAIR.

If it is not starting, it mean, something is going wrong between login into
the windows manager and running tde

-- 
FCD6 3719 0FFB F1BF 38EA 4727 5348 5F1F DCFE BCB0

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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  95163270724   1% /run
/dev/sda5  1857400436 317616932 1445362976  19% /
tmpfs16401180 0   16401180   0% /dev/shm
tmpfs5120 4   5116   1% /run/lock
tmpfs16401180 0   16401180   0% /sys/fs/cgroup
/dev/sdb1   229699916 61472  217900640   1% /sdb
/dev/sdc1  1921802432 879249728  944860648  49% /amandatapes
/dev/sda347799020   6444388   38896828  15% /var
/dev/sda1  944120188864 690080  22% /boot
tmpfs 3280236 43280232   1% /run/user/1000
/dev/md0   1812963068 77852 1720721940   1% /home2
/dev/md1100203600 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, j

Dcopserver not loading

[Ken Heard]

Very soon after I started to use the TDE 14.0.11 version I began
receiving DCOP error messages, having the effect of preventing use of
various applications like Firefox and LibreOffice. After online research
and experimentation on my part I discovered that I could solve such
preventions if before opening TDE I ran in a tty as root the following
three commands:
'dcopserver -- serverid', which returned nothing, then 'dropserver' and
finally again 'dcopserver -- serverid'.  This time however that command
returned something like the following:
'[dcopserver] local/Morcom:/tmp/.ICE-unix/dcop5698-1636014592'

>From this point on there were no longer any more DCOP error messages. I
had full use of the TDE and various applications until when I next
closed completely the computer.

It is consequently my understanding that running the 'dcopserver'
command is presumably required as part of the initial boot-up.  If such
is usually the case I would appreciate knowing what I need to do to have
my computer, named Morcom, do so as well.  Can anyone tell me?

Regards, Ken

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

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 

Re: Where do I find the definitive man page for mdadm?

[The Wanderer]

On 2021-11-13 at 07:26, Gene Heskett wrote:

> On Saturday 13 November 2021 06:02:35 Dan Ritter wrote:
> 
>> Gene Heskett wrote:

>> 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.
> 
> My mdadm manpage does not show the -S command. Scanniing it again to make 
> sure, probably for about the 10th time and I finally found it but many 
> megabytes of relatively unimportant drivel down from the top,

You keep citing this ("many megabytes"), but it doesn't sound right to
me.

$ lh /usr/share/man/man8/mdadm.8.gz
-rw-r--r-- 1 root root 33K Sep 26 00:57 /usr/share/man/man8/mdadm.8.gz

On my computer, the mdadm man page (which you say includes things that
aren't in yours, so must be bigger) is only 33K when compressed, and
more like 100K when uncompressed ('zcat /path/to/mdadm.8.gz | wc -c').

What version of mdadm do you have installed? In particular, what does

$ apt-cache policy mdadm

say?

Have you tried a Web search for 'man mdadm'? On my computer (using
Google), the very first hit from that is
https://linux.die.net/man/8/mdadm and looks substantially the same as
what I have on disk; there are also other hits which look to also
present the contents of the man page.

If your local copy is really so lacking, you might find it useful to
search these Web-based versions instead, rather than asking on the
mailing list and having us search our local copies and share excerpts.

> IMO the manpage is missleading as such an important option ought to
> be shown on the first screenfull.

There are *lots* of important options, depending on exactly what you're
doing. They can't all be presented up-front. The man page presents them
organized by type, and has a useful EXAMPLES section; by convention,
that section is near the end.

I'll agree that it isn't always easy to find the right options and the
right syntax to construct a usable command for what one wants to do,
with this structure and layout - but the EXAMPLES section is often
helpful in circumventing that, and I haven't managed to come up with an
alternative structure that would actually be better (and still be
coherent).

With any lengthy man page, there are really only two useful ways to use
it, in my experience: A: read the whole damn thing through
cover-to-cover until you find what you're after, or B: try various
search terms, exhaustively, until you find something relevant. The
latter is what I usually do with mdadm, when necessary.

> So wipefs failed.
> 
> dd doesn't care so zeroed the first 1000 blocks of each drive, nuke 
> mdadm.conf then rebooted,  gparted was then able to reconfigure the 
> drives. But then mdadm wouldn't accept because gparted had formatted
>  them,

I don't usually use gparted, but by the name I'd expect it to be just a
GUI wrapper around parted, and in my experince with parted it doesn't
format a newly-created partition unless you tell it to.

> not to mention miss-labeled them, so yet another reboot, and keep 
> rebooting unil somebody, Wanderer I believe, told me about "mdadm -S
> /dev/ice" command.

Actually, I didn't mention '-S' (except in passing, as part of an
excerpt from the man page), or at least didn't intend to; I mentioned
'--stop', which is synonymous, but is also easier to meaningfully search
for. (And is how I found the excerpt, by searching the man page for
'--stop'.)

I also didn't mention the "specifying a device" syntax, although I think
the man page does imply that. I cited an example which uses '--stop --scan'.

>> Then these -C commands should work well without warnings, and 
>> creating a filesystem on the /dev/mdX devices will proceed without
>> warnings or errors.
> 
> Yes, finally, but the mdadm man page and its poor formatting were far
>  more hindrance than help. Experienced people here are to be thanked,
> and I do, but not that disastrous man page.

Please stop slamming the mdadm man page. It's certainly not perfect, but
it's not nearly as bad as you're making it out to be.

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



signature.asc
Description: OpenPGP digital signature

Re: Where do I find the definitive man page for mdadm?

[Andy Smith]

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

Re: Where do I find the definitive man page for mdadm?

[Gene Heskett]

On Saturday 13 November 2021 06:02:35 Dan Ritter wrote:

> 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
> > 90 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=92160K  mtime=Wed Dec 31 19:00:00 1969
> > mdadm: /dev/sdf1 appears to contain an ext2fs file system
> >size=92160K  mtime=Wed Dec 31 19:00:00 1969
> > mdadm: /dev/sdg1 appears to contain an ext2fs file system
> >size=92160K  mtime=Wed Dec 31 19:00:00 1969
> > mdadm: /dev/sdh1 appears to contain an ext2fs file system
> >size=92160K  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.

My mdadm manpage does not show the -S command. Scanniing it again to make 
sure, probably for about the 10th time and I finally found it but many 
megabytes of relatively unimportant drivel down from the top, IMO the 
manpage is missleading as such an important option ought to be shown on 
the first screenfull.

So wipefs failed.

dd doesn't care so zeroed the first 1000 blocks of each drive, nuke 
mdadm.conf then rebooted,  gparted was then able to reconfigure the 
drives. But then mdadm wouldn't accept because gparted had formatted 
them, not to mention miss-labeled them, so yet another reboot, and keep 
rebooting unil somebody, Wanderer I believe, told me 
about "mdadm -S /dev/ice" command.

Turns out I had to use fdisk to create a GPT partition table, one at 
+900G and one at +30G on each drive without formatting, then reboot 
again after nukeing mdadm.conf for the 9th or so time, at which point I 
was able to create a raid10 using sde1,sdf1,sfg1,and sdh1 as md0, and an 
md1 as sde2,sdf2,sdg2 and sdh2, and then format them both to ext4.

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

Yes, finally, but the mdadm man page and its poor formatting were far 
more hindrance than help. Experienced people here are to be thanked, and 
I do, but not that disastrous man page.

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

Thanks Dan. And everyone else who came to my rescue in this long thread.
Nearly everyone was Cc: ing me, but I'm subscribed, close to a decade, 
maybe more.  So I have duplicates to clean up. NBD. 

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 

Re: Where do I find the definitive man page for mdadm?

[Andy Smith]

Hello,

On Fri, Nov 12, 2021 at 11:56:48AM -0500, Dan Ritter wrote:
> There's also the fact that disk manufacturers are notoriously
> unable to commit to the same size disks across models.

I was interested to discover a couple of years ago that there has
for some time been a standard for storage capacity so that any
stated capacity will be consistent even between manufacturers. It's
called IDEMA LBA1-03:

http://www.idema.org/wp-content/downloads/2169.pdf

Basically it says that the actual capacity in bytes will always be
the stated GB * 1000194048 + 10838016.

Thinking back over the last 10 years or so I couldn't remember when
I had ever had a problem with differing capacities, this with
hundreds of different drives from different vendors, so I thought
that with this standard this problem was behind us.

Then, two months ago I saw some people on the zfs-linux mailing list
saying they'd had this problem so I asked around:

https://twitter.com/grifferz/status/1438269336418930688

…and indeed, it seems that some some are still not abiding by this
standard. Yet for most of their drives they do. :(

Cheers,
Andy

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

Re: Where do I find the definitive man page for mdadm?

[Andy Smith]

Hello,

On Fri, Nov 12, 2021 at 03:41:15PM -0700, Charles Curley wrote:
> On Fri, 12 Nov 2021 14:12:58 -0500
> Gene Heskett  wrote:
> > Despite nuking mdadm.conf, and zeroing the drive with dd, its still 
> > locked and untouchable by gparted. And I cannot rmmod the raid stuff, 
> > its busy. Blanking the third one now with dd a 34 minute job. I'll 
> > reboot again when the 4th drive has been zeroed.
> 
> There is a daemon that maintains the array for you. That has to be shut
> down. So rebooting may be the way to go.

I have found that if trying to work on the underlying block devices
of an mdadm array, the array needs to be stopped first. So:

# mdadm --stop /dev/md0 # or whatever it is called

You may still find that you have intermittent issues with the
underlying device being "in use", as udev will keep trying to
assemble things due to seeing the mdadm metadata on the block devices.

To remove mdadm metadata (and everything else), I find it easiest to
use wipefs:

# wipefs -a /dev/sda1 # or whatever each block device is called

mdadm does detect previous metadata and ask you if you want to
remove it / go ahead, but because of being in a race with udev I do
tend to just do a wipefs instead.

Normally I can stop an array and repurpose its underlying devices
without having to reboot. As long as it's all unmounted of course.

Cheers,
Andy

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

Re: Where do I find the definitive man page for mdadm?

[Dan Ritter]

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 90 
> 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=92160K  mtime=Wed Dec 31 19:00:00 1969
> mdadm: /dev/sdf1 appears to contain an ext2fs file system
>size=92160K  mtime=Wed Dec 31 19:00:00 1969
> mdadm: /dev/sdg1 appears to contain an ext2fs file system
>size=92160K  mtime=Wed Dec 31 19:00:00 1969
> mdadm: /dev/sdh1 appears to contain an ext2fs file system
>size=92160K  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-

Re: rsync failing to back up to synology server

[Dan Ritter]

Sharon Kimble wrote: 
> 
> After enduring a home move, I'm now trying to restart my rsync backups
> to my synology server, but none are working!
> 
> I have this command for backing up my emacs -
> 
> - --8<---cut here---start->8---
> /usr/bin/rsync -avhz --update --delete --partial --password-file="$PASS" 
> ~/.emacs.d/ boudiccas@192.168.1.106::home/back-emacs/
> - --8<---cut here---end--->8---
> 
> but every time it shows this error message -
> 
> - --8<---cut here---start->8---
> @ERROR: auth failed on module home
> rsync error: error starting client-server protocol (code 5) at 
> main.c(1817) [sender=3.2.3]
> - --8<---cut here---end--->8---
> 
> It seems that its not getting the correct password to enable the backup
> to happen, but what password? Is it my password on my source machine, or
> the log-in password for my synology server, or what? I've tried various
> passwords, but I still can't get it to backup, so help please?

rsync either uses ssh or its own protocol to connect across
networks. Almost everyone uses ssh.

Using double colons 
boudiccas@192.168.1.106::home/back-emacs
indicates that you want the rsync protocol, which required rsync
to be running in daemon mode on the other side.

Use one colon there, which indicates SSH, and use boudicca's
login password on the 192.168.1.106 box. 

If 
ssh boudiccas@192.168.1.106
doesn't work, debug that first.


-dsr-

Re: set the number of inodes during FS creation via pressed

[Stanislav Vlasov]

2021-11-13 5:31 GMT+05:00, phoebus phoebus :

> Do you know if it possible to set the number of inodes  to create in the
> filesystem during the installalation with the pressed file?

You may try create fs in another console and use in without formatting.

-- 
Stanislav

rsync failing to back up to synology server

[Sharon Kimble]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512


After enduring a home move, I'm now trying to restart my rsync backups
to my synology server, but none are working!

I have this command for backing up my emacs -

- --8<---cut here---start->8---
/usr/bin/rsync -avhz --update --delete --partial --password-file="$PASS" 
~/.emacs.d/ boudiccas@192.168.1.106::home/back-emacs/
- --8<---cut here---end--->8---

but every time it shows this error message -

- --8<---cut here---start->8---
@ERROR: auth failed on module home
rsync error: error starting client-server protocol (code 5) at main.c(1817) 
[sender=3.2.3]
- --8<---cut here---end--->8---

It seems that its not getting the correct password to enable the backup
to happen, but what password? Is it my password on my source machine, or
the log-in password for my synology server, or what? I've tried various
passwords, but I still can't get it to backup, so help please?

Thanks
Sharon.
- -- 
Debian 11, fluxbox 1.3.7, emacs 28.0.50, org 9.5
-BEGIN PGP SIGNATURE-

iQJPBAEBCgA5FiEELSc/6QwVBIYugJDbNoGAGQr4g1sFAmGPfeYbHGJvdWRpY2Nh
c0Bza2ltYmxlLnBsdXMuY29tAAoJEDaBgBkK+INbg1MP/jVg/9GmwS2i4Ev6R4ss
hbwPDFkQM8g16se4Qih82OzhBN6NhAZzSegx7M0+NIo31QoF0FMYt0zleMJHlT5+
wMKQFcVBSa9u6HBl48I7aMTNv7QJ0YgOT/pis2nu5EBduU8OppWwZsZGSRn7//mP
plVjV34X1xNjDCA2minuQE+/EsC6qpiVDss5q0+6ZjZvhE4PvIpC6aCZWos3GyB8
thXD2Qn8BgpcfrjXE2sh9fw8NQeJUcV3kHJo17Re4EKlWgd7N/Y/ybPPoTMMxZ9y
Mrs4VLP0Q3uSi8VWT23VvBpxVNkS0zuDNNi2Vi1tToHLW2S5Idx8iBSLgO7aoMJC
ii+1tmDhXj2khqXHvjGeNtbA/z1gTja3jRIc/inNxJr4OZBtemZz5/lW3tmiSfkI
ivpaOnSUijuDpVfj/qy6siav1EceSCs+waqpSH4dwqG4xtzjy8h+tJPEAOdz/+Nx
nAuME+OeV2ut7Zc2RGviYsf2x7ioPPrq3ra5Z1bFHk7++psfIOCOw5Z9Cn1Ep7U3
a33PKGFe9R7vC7JkVfrOL9j6OEW1mmE+Mmi+X8y3uUzwbeMZJF7TRMZFExuKEZrb
LaYTaV+HMLYAuoTRMxnlQH1xe/XQx8hEv/e7YGrt/wPUKzBh86FVUYEBLhceYNeQ
JSCifcWlieVJh3TEPDmIlGKP
=aG/R
-END PGP SIGNATURE-