date:20221115


On 11/15/22 10:32, to...@tuxteam.de wrote:


[1] https://btrfs.wiki.kernel.org/images-btrfs/6/68/Btree_TOS.pdf



Thank you for the link.


Thank you IBM for making that paper public (and not behind a pay wall).


David

Re: Explaining snapshots (for backup)


On 11/15/22 06:27, rhkra...@gmail.com wrote:

I'm not really clear on the concept of a snapshot (for backup) -- I've done a
little googling but haven't found an explanation that "satisfies" me.

In this email I want to hyptothesize on what a snapshot might be in the hope
that others can correct / amplify it when I go wrong.

Starting from a beginning, I suppose I could copy the entire contents of
whatever I wanted to make a snapshot of (by any of a variety of tools -- dd,
cp, ...) and call that a snapshot, although the more common name for it would
be a "full backup".

Later, I could copy any files (as files) that have changed since the date I made
the full backup and call that a snapshot.  (I might use find to identify the
files that have changed, and then any of a variety of tools to actually copy
them somewhere (and call that a shapshot).)

I suppose it wouild be possible to do something like this at a block level,
that is copying only blocks of a file which have changed.  (Not sure which
commands might help me do that, but I don't think I'd really be interested in
doing that.)

I also hear (i.e., read) statements from which I infer that some snapshots
included only the metadata of the files (or blocks???), but I'm not sure of the
value of either of those to me -- how can you reconstruct a possibly missing
file (or block) from the metadata?



In the content of computers, "backup" has many meanings for myself:

1.  Copying files and directories from one filesystem to another 
filesystem, using tools such as cp(1), scp(1), and rsync(1).  Both 
filesystems are mounted.


2.  Copying files and directories to a database or file structure, using 
tools such as amanda(8) and borg(1).  The source filesystem is mounted 
and the destination may be files and directories on a mounted filesystem.


3.  Serializing files and directories to a file, using tools such as 
cpio(1) and tar(1).  (I tend to use the term "archive".)  The source 
filesystem is mounted and the destination file is on a mounted filesystem.


4.  Serializing a filesystem to a file, using tools such as dump(8). (I 
tend to use the term "dump".)  The source filesystem is not mounted and 
the destination file is on a mounted filesystem.


5.  Storage media used to store "backups", created by whatever means; 
umounted or unmounted.


6. Secondary networks, hardware, software, data, etc. ("resources") that 
can be used in place of primary resources.



I expect there are many more meanings for "backup"; both those that I 
have forgotten and meanings known to other people.



Of course, a reverse operation is desirable -- e.g. "restore".


For myself, "snapshot" is a feature of advanced filesystems and volume 
managers, such as btrfs(8), zfs(8), and lvm(8).  My understanding is 
that snapshots are internal to the filesystem or volume manager. 
Additional operations include "roll back", "send", "receive", 
"replicate", and "destroy".  Of course, snapshots can be backed up, to 
backup media or servers, etc..



Related terms include "image" and "clone", which operate at the device 
(block) level using tools such as dd(1).  Operations include copying one 
device to another device ("cloning"), serializing a device to a file 
("taking an image"), and deserializing a file to a device ("restoring an 
image").   Sophisticated tools such as clonezilla 
(https://clonezilla.org/) understand and can perform partitioning, 
volume, filesystem, bootloader, and other operations.



To further add confusion, people can and do use the above terms both as 
verbs and as nouns, in multiple contexts, in the same sentence.



David

Re: RFC: What would be the "correct debian way" to clean up unwanted languages from an installation?

2022-11-15 Thread David Wright

On Tue 15 Nov 2022 at 16:37:58 (-0800), David Christensen wrote:
> On 11/15/22 00:22, DdB wrote:
> > Am 15.11.2022 um 05:21 schrieb David Christensen:
> > > I installed the localepurge package.  Storage usage did not change. Then
> > > I realized that I had chosen the "C" locale during installation, so
> > > perhaps there is nothing to be removed (?).  So, I removed the
> > > localepurge package.
> 
> > I just read (from /usr/share/doc/localepurge/README.dpkg-path):
> > > localepurge dpkg support
> > > 
> > > 
> > > Starting with version 1.15.8, dpkg supports --path-include and
> > (...)
> > > 
> > >   * It cannot be used to purge locale files from already installed
> > > packages.
> > > - Though it will be fixed on next upgrade (or reinstall) of the
> > >   packages.
> > (...)
> > 
> > which indicates, that your observations had to be expected, if you opted
> > for dpkg-path :-)
> 
> Well, that explains it.  Thanks for pointing that out.
> 
> Is it possible to not install locale files in the first place?  E.g.
> when running d-i, and whenever using the package system thereafter?

https://lists.debian.org/debian-user/2020/10/msg00308.html

recommends that you stick to eliminating files listed in
/var/lib/dpkg/info/*.md5sums because they're easy to restore,
and their contents shouldn't ever have been changed (or they
wouldn't be listed here).

So it should be easy to devise grep patterns that hit the files that
you don't want, while preserving those you do, like say:

$ grep -v 'en_GB/LC_MESSAGES' /var/lib/dpkg/info/*.md5sums | grep  
'LC_MESSAGES.*\.mo$' | less

or, if you're from Cornwall:

$ grep -v '_GB/LC_MESSAGES' /var/lib/dpkg/info/*.md5sums | grep  
'LC_MESSAGES.*\.mo$' | less

The OP removed 1½GB, which is far more than I matched, but I didn't
run or trace the OP's script to investigate the quantity and contents.
Perhaps my not running a DE has something to do with the quantity.

Cheers,
David.

Re: Intel X540-AT2 and Debian: intermittent connection

On 11/15/22 07:15, hw wrote:

On Tue, 2022-11-15 at 12:38 +0100, hw wrote:

On Mon, 2022-11-14 at 13:21 +0100, hw wrote:

On Mon, 2022-11-14 at 12:28 +0100, stefano gozzi wrote:

Please loot at this:
https://www.linuxquestions.org/questions/linux-networking-3/intel-x540-t2-network-card-installed-but-only-at-100mbit-cant-change-or-improve-4175686736/

It seems that you need a 8x pcie slot to work fine

Thanks, the card is in an 8x slot and has been working fine with Fedora. I
didn't change anything but using Debian instead of Fedora.

Ok I pulled the server from the rack and put another fan to blow directly on
the
card in case it might overheat.

And I have to correct myself. The card is in an 8x slot and according to the
manual of the mainboard it's supposed to be 8x and not 4x. I pulled it and
put
it back in.

However, lspci says "LnkSta: Speed 5GT/s (ok), Width x4 (downgraded)".

Usually cards in PCI slots with 4 instead of 8 lanes still work fine, and the
card did work in that slot with Fedora.

I found that I had to unplug the network cable and to plug it back in before I
could send/receive pings. I already tried a different network cable and it
didn't make a difference.

I suspect that Debian might be doing something differently or not doing that
Fedora does which causes the intermittent connections.

Any ideas? Backups over an 1GB link are excruciatingly slow ...

Update: I booted a Fedora live system and the connection is also intermittent.
So it's not a Debian issue. It's still an issue, though ...

What is the cable type? Length? Factory or home made?

What is connected to the other end of the cable? If it is a NIC in
another server, what happens if you swap the two NIC's?

David

Re: RFC: What would be the "correct debian way" to clean up unwanted languages from an installation?


On 11/15/22 00:22, DdB wrote:

Am 15.11.2022 um 05:21 schrieb David Christensen:

I installed the localepurge package.  Storage usage did not change. Then
I realized that I had chosen the "C" locale during installation, so
perhaps there is nothing to be removed (?).  So, I removed the
localepurge package.



I just read (from /usr/share/doc/localepurge/README.dpkg-path):

localepurge dpkg support


Starting with version 1.15.8, dpkg supports --path-include and

(...)


  * It cannot be used to purge locale files from already installed
packages.
- Though it will be fixed on next upgrade (or reinstall) of the
  packages.

(...)

which indicates, that your observations had to be expected, if you opted
for dpkg-path :-)



Well, that explains it.  Thanks for pointing that out.


Is it possible to not install locale files in the first place?  E.g. 
when running d-i, and whenever using the package system thereafter?



Davud

Re: initrd sizes mushroomed several months ago

2022-11-15 Thread David Wright

On Sun 13 Nov 2022 at 06:54:47 (-0500), The Wanderer wrote:
> On 2022-11-12 at 01:57, Felix Miata wrote:
> 
> > # grep MODULES= /etc/initramfs-tools/initramfs.conf
> > MODULES=dep
> > # ls -Ggh /boot/initrd.img-[5,6]*
> > -rw-r--r-- 1 6.8M May  8  2022 /boot/initrd.img-5.17.0-1-686
> > -rw-r--r-- 1  31M Aug  2 03:06 /boot/initrd.img-5.18.0-3-686
> > -rw-r--r-- 1  31M Sep 30 15:43 /boot/initrd.img-5.19.0-2-686
> > -rw-r--r-- 1  36M Nov 12 01:36 /boot/initrd.img-6.0.0-3-686
> > 
> > Does anyone here have an explanation for the mega-change in size of initrds 
> > after
> > kernel 5.17? My initramfs.conf has had MODULES=dep since before 
> > testing/bullseye
> > became testing/bookworm.
> 
> Just a stab in the dark, but:
> 
> The changelog history for linux-image-5.18.0-4-amd64, on my system,
> gives the change from 5.17 to 5.18 as having happened in May of 2022.
> 
> The changelog for initramfs-tools, on my system, shows exactly one
> version newer than May of 2022, released in July of 2022.
> 
> The changelog for that version of initramfs-tools (0.142) includes the
> entry:
> 
>   [ Dimitri John Ledkov ]
>   * [d8c5864] mkinitramfs: decompress compressed kernel modules
> 
> with no reason or other information given. (There are a few other
> changes listed, which could also be relevant, but seem less obviously so
> from the brief descriptions - although it is of course hard to judge.)
> 
> Just at first blush, it looks like something like that could produce an
> increase in size, potentially a notable one.
> 
> (The previous version's changelog entry also switches compression to
> zstd, but that version came out in April, so it's unlikely to be the
> culprit.)

AIUI¹ if you include compressed modules in the initramfs, then the
compressed archive that is generated will be larger than that with
uncompressed modules, so it makes sense to decompress the modules
while building the initramfs. I think that is the step that is
being added above.

That said, I dont see any xz-compressed modules in either
/lib/modules/ itself, or the initramfs archives I've mentioned.
(My bullseye mkinitramfs 0.140 dates from before the change above.)

The initramfs archives do contain /usr/bin/{xz,unxz,xzcat}, so
they could handle any potentially necessary steps.

¹ The final compression step takes advantage of patterns of data
  common to different (uncompressed) modules. However, when each
  module is individually compressed first, then these compressed
  modules will appear to be composed of pseudorandom data, with
  no patterns in common.

Cheers,
David.

Re: gpg says no user ID

Am 15.11.2022 um 19:20 schrieb Jeffrey Walton:
> It's not you. The whole key server architecture is a mess nowadays.
> 
> Jeff

Thank you, Jeff, for your explanation and hints.

Just one additional viewpoint from me (an afficionado for data
protection) ;-)

As i see it, the european law suffers from using wrong understanding and
wording, a problem, that is very difficult to fix, as long as teachers,
universities, and many professionals are not even aware of the cause of
their troubles.

I was hoping, that the corona epidemic would demonstrate clearly, how
that new law hinders science and other communities to collect useful and
sometimes necessary information, much to the detriment of social sanity.

But life goes on and people do not seem to notice the errors of their
ways. And the resolution is not a technical problem, it is an awareness
and an agreement moderation problem. But AFAICT there are very few
people even noticing the misdirection of our policies, and certainly not
enough people to push a change ... uptil now.

So society goes on onto the misguided path, creating further problems
along the way. i myself am rather desperate when i see people involved
in computer security regularly failing at ringing the bell. Not really
wondering, that keyservers now display noticeable problems, that would
make a global change in perspective desirable.

just my 2 cents (probably not on the best list to air this)
stopping now (AFK) :-))

DdB

Re: Explaining snapshots (for backup)

2022-11-15 Thread tomas

On Tue, Nov 15, 2022 at 11:10:16AM -0500, rhkra...@gmail.com wrote:
> Intentionally top-posting;  Thanks to all who replied, I think I have a 
> pretty 
> good understanding and I think the biggest thing I was missing was how a file 
> could be reconstructed using only the metadata, but I now see the explanation 
> that filesystems that can do snapshots are COW and now things make sense.

The underlying mechanism for all that is, most of the time, some variant
of a B-tree, where you just build up a modified B-tree up from the leaves
up to the root. The new root is just the new file system's state. If you
want to hold onto the old one (aka snapshot), you hold onto the old root.

This is an idea which generated in the database world (called MVCC, Multi
Version Concurrency Control); Postgres (PostgreSQL's grandma) was one of
the pioneers in that area, AFAIK. Back then you could do "time travel",
rolling back the whole database. Needless to say, it ate storage for
breakfast. An expensive breakfast, back then ;-)

Here's a paper [1] on how btrfs does that. I'd expect the other snapshot
capable file systems to work similarly (they have some pretty pics :)

So a snapshot itself is extremely fast and cheap -- just holding on to many
of them will exhaust your disk at some point.

Cheers

[1] https://btrfs.wiki.kernel.org/images-btrfs/6/68/Btree_TOS.pdf
-- 
t

signature.asc
Description: PGP signature

Re: gpg says no user ID

2022-11-15 Thread Jeffrey Walton

On Tue, Nov 15, 2022 at 1:01 PM DdB
 wrote:
> ...
> i just experienced the same problem, same difficulty understanding the
> man pages. Googling suggested to try a different keyserver.
> I had to try several ... until i found one, that succeeded.
> Apparently, the cause was found to be in the rules in place at the
> servers. Some do no longer allow connections from sources without
> self-signed pubkeys.

Yes, the key server pools are a mess. Part of it is because of Europe
and GPPR. And the GnuPG folks have not done a good job updating the
server code to meet the demands of the current landscape. I just shake
my head in disbelief at what things have come to. It makes me want to
unsubscribe from the GnuPG mailing lists...

For example, from "keyserver receive failed: No name - for gpg
--keyserver hkp://pool.sks-keyservers.net,"
https://lists.gnupg.org/pipermail/gnupg-users/2021-June/065261.html:

The keyserver *pools* at sks-keyservers.net are no longer maintained for
legal reasons. sks-keyservers.net was receiving GDPR requests, e.g. for
RTBF [Right to be Forgotten], that it could not satisfy because the pools
had no formal structure that could compel individual operators to comply
with legal requests.

Or, more discussions at
https://www.google.com/search?q=keyserver+gdpr+site:lists.gnupg.org/pipermail/gnupg-users

> But just adding the corresponding switch did not
> help either. i had to find a server with an older config in place (like
> ubuntu's).

It's not you. The whole key server architecture is a mess nowadays.

Jeff

Re: Explaining snapshots (for backup)

2022-11-15 Thread Dan Ritter

pa...@quillandmouse.com wrote: 
> On Tue, 15 Nov 2022 09:40:11 -0500
> Dan Ritter  wrote:
> 
> > rhkra...@gmail.com wrote: 
> > > I'm not really clear on the concept of a snapshot (for backup) --
> > > I've done a little googling but haven't found an explanation that
> > > "satisfies" me.
> > > 
> > > Starting from a beginning, I suppose I could copy the entire
> > > contents of whatever I wanted to make a snapshot of (by any of a
> > > variety of tools -- dd, cp, ...) and call that a snapshot, although
> > > the more common name for it would be a "full backup".
> > 
> > Let's look at the larger circumstances.
> > 
> > In ordinary usage, there are tens to thousands of processes
> > runnning on your system. Some of them are emitting logs or
> > writing files.
> > 
> > Taking a backup takes some time. During that time, some files
> > get written, some get opened, and some are related to each other
> > (by the processes) in ways which are inconsistent until all of
> > them are written.
> > 
> > A snapshot differs from a backup in two important regards:
> > 
> > - first, it requires the filesystem to bring writes to a halt.
> > There is now a consistent view.
> > 
> > - second, it doesn't actually copy things. It just records their
> > state and, when done, allows future writes to continue -- writes
> > which are not part of this snapshot.
> > 
> > As a result, you can take a snapshot and then:
> > 
> > - discard it (trivial)
> > 
> > - look through it and copy off any file or group of files, thus
> > getting what they contained at the time of the snapshot, not the
> > what they contain now (excellent for recovering from an
> > accidental delete)
> > 
> > - copy all of it off elsewhere, producing a consistent full
> > backup.
> > 
> 
> Assuming a snapshot is taken so that you can recover a filesystem to a
> previous state (or the current state). Is that correct?

Yes.

> I don't understand "recording the state" of files. To me, this means
> the ownership, size, etc., not the contents. That doesn't seem valuable
> for recovering the state of a system.

That's the metadata. A snapshot fixes the data as well as the
metadata. State is everything written to disk.

> Let's assume, as the OP says, you do an original full backup. A
> snapshot ought to record either the contents of all the files which
> have changed, or record the delta of each file which has changed.
> Thus, you'd be able to recover a filesystem to either some prior state
> or its current state, using the snapshot.
> 
> Am I missing something?

Well, you don't need to recover it to the current state, because
you already have that. But, yes, a snapshot from yesterday
allows you to copy from that snapshot any or all changed files
to the current filesystem.

-dsr-

Re: Explaining snapshots (for backup)

2022-11-15 Thread debian-user

> On Tue, 15 Nov 2022 09:40:11 -0500
> Dan Ritter  wrote:
> 
> > rhkra...@gmail.com wrote:   
> > > I'm not really clear on the concept of a snapshot (for backup) --
> > > I've done a little googling but haven't found an explanation that
> > > "satisfies" me.
> > > 
> > > Starting from a beginning, I suppose I could copy the entire
> > > contents of whatever I wanted to make a snapshot of (by any of a
> > > variety of tools -- dd, cp, ...) and call that a snapshot,
> > > although the more common name for it would be a "full backup".  
> > 
> > Let's look at the larger circumstances.
> > 
> > In ordinary usage, there are tens to thousands of processes
> > runnning on your system. Some of them are emitting logs or
> > writing files.
> > 
> > Taking a backup takes some time. During that time, some files
> > get written, some get opened, and some are related to each other
> > (by the processes) in ways which are inconsistent until all of
> > them are written.
> > 
> > A snapshot differs from a backup in two important regards:
> > 
> > - first, it requires the filesystem to bring writes to a halt.
> > There is now a consistent view.
> > 
> > - second, it doesn't actually copy things. It just records their
> > state and, when done, allows future writes to continue -- writes
> > which are not part of this snapshot.
> > 
> > As a result, you can take a snapshot and then:
> > 
> > - discard it (trivial)
> > 
> > - look through it and copy off any file or group of files, thus
> > getting what they contained at the time of the snapshot, not the
> > what they contain now (excellent for recovering from an
> > accidental delete)
> > 
> > - copy all of it off elsewhere, producing a consistent full
> > backup.
> >   
> 
> Assuming a snapshot is taken so that you can recover a filesystem to a
> previous state (or the current state). Is that correct?
> 
> I don't understand "recording the state" of files. To me, this means
> the ownership, size, etc., not the contents. That doesn't seem
> valuable for recovering the state of a system.
> 
> Let's assume, as the OP says, you do an original full backup. A
> snapshot ought to record either the contents of all the files which
> have changed, or record the delta of each file which has changed.
> Thus, you'd be able to recover a filesystem to either some prior state
> or its current state, using the snapshot.
> 
> Am I missing something?

I think what you're missing is that 'snapshots' are usually an
attribute of a copy-on-write (COW) filesystem such as btrfs or zfs. So
a snapshot is a list of the blocks that belong to particular files at
some particular moment. Once the snapshot has been taken, the
filesystem can resume writes by copying any blocks that need to be
written subsequently and updating the current map of which blocks
belong to which files, but not touching the snapshot's map. And when
looking for empty space on the disk to use, it ignores any block that
appears in any map.

Re: ZFS performance (was: Re: deduplicating file systems: VDO withDebian?)

On Mon, 2022-11-14 at 15:08 -0500, Michael Stone wrote:
> On Mon, Nov 14, 2022 at 08:40:47PM +0100, hw wrote:
> > Not really, it was just an SSD.  Two of them were used as cache and they
> > failed
> > was not surprising.  It's really unfortunate that SSDs fail particulary fast
> > when used for purposes they can be particularly useful for.
> 
> If you buy hard drives and use them in the wrong application, they also 
> fail quickly.

And?

>  And, again, you weren't using the right SSD so it *wasn't*
> particularly useful.

Sure it was.  An SSD that is readily available and relatively inexpensive can be
very useful and be the right one for the purpose.  Another one that isn't
readily available and relatively expensive may last longer, and that doesn't
mean that it's the right one for the purpose.

>  But at this point you seem to just want to argue 
> in circles for no reason, so like others I'm done with this waste of 
> time.

IIRC, you're the one trying to argue against experience, claiming that the
experience wasn't how it was while it was as it was, and that conclusions drawn
from the experience are invalid while they aren't.

Re: gpg says no user ID

Am 14.11.2022 um 23:17 schrieb Thomas George:
> I am still trying to do a fully verified installation of debian-11.5.0.
> 
> gpg --verify SHA512SUMS.sign SHA512SUMS responded with DF98...BE9B
> 
> gpg --recv-keys DF98...BE9B responded key DF98...BE9B: new key but
> contains no user ID - skipped.
> 
> Another source suggested gpg --key-server keyring.debian.org --recv-keys
> long numeric key
> 
> but this responded invalid option --key-server
> 
> The gpg man page is beyond me, I need help
> 
> 

Hi,
i just experienced the same problem, same difficulty understanding the
man pages. Googling suggested to try a different keyserver.
I had to try several ... until i found one, that succeeded.
Apparently, the cause was found to be in the rules in place at the
servers. Some do no longer allow connections from sources without
self-signed pubkeys. But just adding the corresponding switch did not
help either. i had to find a server with an older config in place (like
ubuntu's).

Re: gpg says no user ID

2022-11-15 Thread Thomas Schmitt

Hi,

Thomas George wrote:
> gpg2 --verify SHA512SUMS.sign debian-11.5.0-amd64-netinst.iso
> ...gpg: BAD signature from "Debian CD signing key

Consider to re-read my mail of yesterday:
  Date: Mon, 14 Nov 2022 09:19:29 +0100
  Subject: Re: No Public Key
  https://lists.debian.org/debian-user/2022/11/msg00422.html


Have a nice day :)

Thomas

Re: else or Debian (Re: ZFS performance (was: Re: deduplicating file systems: VDO with Debian?))

On Mon, 2022-11-14 at 20:37 +0100, Linux-Fan wrote:
> hw writes:
> 
> > On Fri, 2022-11-11 at 22:11 +0100, Linux-Fan wrote:
> > > hw writes:
> > > > On Thu, 2022-11-10 at 22:37 +0100, Linux-Fan wrote:
> [...]
> > How do you intend to copy files at any other level than at file level?  At  
> > that
> > level, the only thing you know about is files.
> 
> You can copy only a subset of files but you cannot mirror only a subset of a  
> volume in a RAID unless you specifically designed that in at the time of  
> partitioning. With RAID redundancy you have to decide upfront what you  
> want to have mirrored. With files, you can change it any time.

You can do that with RAID as well.  It might take more work, though.

> [...]
> 
> > > Multiple, well established tools exist for file tree copying. In RAID 
> > > scenarios the mode of operation is integral to the solution.
> > 
> > What has file tree copying to do with RAID scenarios?
> 
> Above, I wrote that making copies of the data may be recommendable over  
> using a RAID. You answered “Huh?” which I understood as a question to expand  
> on the advantages of copying files rather than using RAID.

So file tree copying doesn't have anything to with RAID scenarios.

> [...]
> 
> > > File trees can be copied to slow target storages without slowing down the 
> > > source file system significantly. On the other hand, in RAID scenarios, 
> 
> [...]
> 
> > Copying the VM images to the slow HDD would slow the target down just as it
> > might slow down a RAID array.
> 
> This is true and does not contradict what I wrote.

I didn't say that it contradicts.  Only it doesn't matter what kind of files
you're copying to a disk for the disk to slow down while you seemed to make a
distinction that doesn't seem necessary for slowing down disks.

> 
> > > ### when
> > > 
> > > For file copies, the target storage need not always be online. You can 
> > > connect it only for the time of synchronization. This reduces the chance 
> > > that line overvoltages and other hardware faults destroy both copies at  
> > > the same time. For a RAID, all drives must be online at all times (lest
> > > the 
> > > array becomes degraded).
> > 
> > No, you can always turn off the array just as you can turn off single disks.
> > When I'm done making backups, I shut down the server and not much can
> > happen  
> > to
> > the backups.
> 
> If you try this in practice, it is quite limited compared to file copies.

What's the difference between the target storage being offline and the target
storage server being switched off?  You can't copy the files either way because
there's nothing available to copy them to.

> 
> > > Additionally, when using files, only the _used_ space matters. Beyond  
> > > that, the size of the source and target file systems are decoupled. On the
> > > other 
> > > hand, RAID mandates that the sizes of disks adhere to certain properties 
> > > (like all being equal or wasting some of the storage).
> > 
> > And?
> 
> If these limitations are insignificant to you then lifting them provides no  
> advantage to you. You can then safely ignore this point :)

Since you can't copy files into thin air, limitations always apply.

> 
> [...]
> 
> > > > Hm, I haven't really used Debian in a long time.  There's probably no
> > > > reason 
> > > > to change that.  If you want something else, you can always go for it.
> > > 
> > > Why are you asking on a Debian list when you neiter use it nor intend to  
> > > use it?
> > 
> > I didn't say that I don't use Debian, nor that I don't intend to use it.
> 
> This must be a language barrier issue. I do not understand how your  
> statements above do not contradict each other.

It's possible that the context has escaped you because it hasn't been quoted.

> [...]
> 
> > > Now check with 
> > > 
> > > I get the following (smaller number => more popular):
> > > 
> > > 87   e2fsprogs
> > > 1657 btrfs-progs
> > > 2314 xfsprogs
> > > 2903 zfs-dkms
> > > 
> > > Surely this does not really measure if people are actually use these 
> > > file systems. Feel free to provide a more accurate means of measurement.  
> > > For me this strongly suggests that the most popular FS on Debian is ext4.
> > 
> > ext4 doesn't show up in this list.  And it doesen't matter if ext4 is most
> 
> e2fsprogs contains the related tools like `mkfs.ext4`.

So one could think that not many people use ext4.

> 
> [...]
> 
> > 
> > 
> > I was referring to snapshots of backups.  Keeping many full copies requires
> > a
> > lot more disk space than using snapshots.
> 
> Modern backup tools write their backups to files and still manage to be  
> similarly efficient compared the snapshot based technolgoies when it comes  
> to storage usage with the additional benefit that you can copy or  
> synchronize the output of these tools to almost any file system.

When they make full copies they'll also require at least as mu

Re: gpg says no user ID

2022-11-15 Thread Jeffrey Walton

On Tue, Nov 15, 2022 at 12:22 PM Thomas George  wrote:
>
> Close, almost there.  At the end something goes wrong. Here is the output:
>
> gpg2 keyserver keyring.debian.org --recv DF98...BE9B
>
> gpg: /root/.gnupg/trustdb.gpg: trust.db created
>
> gpg: key DA87E80D6294BE9B: public key "Debian CD signing  key
> " imported
>
> gpg: Total number processed: 1
>
> gpg: Imported: 1
>
> gpg2 --verify SHA512SUMS.sign SHA512SUMS
>
> gpg: Signature made Sat 10 Oct 07:00:08 PM EDT
>
> ..using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> gpg: Good signature from "Debian CD signing key
> " [unknown]
>
> ...gpg: WARNING: This key is not certified with a trusted signature!
>
> ..There is no indication that the signature belongs to the owner
>
> ...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> gpg2 --verify SHA512SUMS.sign debian-11.5.0-amd64-netinst.iso
>
> ...gpg: Signature made Sat 10 Oct 07:00:08  PM EDT
>
> ...gpg:  using RSA DF9B9C49EAA9298432589D76DA87E80D6294BE9B
>
> ...gpg: BAD signature from "Debian CD signing key
> "  [unknown]

It sounds a lot like https://askubuntu.com/q/1110673 and
https://forums.linuxmint.com/viewtopic.php?t=293108 .

Jeff

Re: gpg says no user ID

2022-11-15 Thread Thomas George


Close, almost there.  At the end something goes wrong. Here is the output:

gpg2 keyserver keyring.debian.org --recv DF98...BE9B

   gpg: /root/.gnupg/trustdb.gpg: trust.db created

   gpg: key DA87E80D6294BE9B: public key "Debian CD signing  key 
" imported


   gpg: Total number processed: 1

   gpg: Imported: 1

gpg2 --verify SHA512SUMS.sign SHA512SUMS

   gpg: Signature made Sat 10 Oct 07:00:08 PM EDT

..using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B

   gpg: Good signature from "Debian CD signing key 
" [unknown]


...gpg: WARNING: This key is not certified with a trusted signature!

..There is no indication that the signature belongs to the owner

...Primary key fingerprint: DF9B9C49EAA9298432589D76DA87E80D6294BE9B

gpg2 --verify SHA512SUMS.sign debian-11.5.0-amd64-netinst.iso

...gpg: Signature made Sat 10 Oct 07:00:08  PM EDT

...gpg:  using RSA DF9B9C49EAA9298432589D76DA87E80D6294BE9B

...gpg: BAD signature from "Debian CD signing key 
"  [unknown]














On 11/15/22 02:59, Henning Follmann wrote:

On Mon, Nov 14, 2022 at 05:17:25PM -0500, Thomas George wrote:

I am still trying to do a fully verified installation of debian-11.5.0.

gpg --verify SHA512SUMS.sign SHA512SUMS responded with DF98...BE9B

gpg --recv-keys DF98...BE9B responded key DF98...BE9B: new key but contains
no user ID - skipped.

Another source suggested gpg --key-server keyring.debian.org --recv-keys
long numeric key

but this responded invalid option --key-server


sorry that was a typo.
gpg --keyserver keyring.debian.org --recv-keys ...
would be correct.



The gpg man page is beyond me, I need help


Well,
gpg is very complex software now. And the man page tries to be
all-encompassing. So it seems daunting to look at the man pages.
But I still would encourage anybody to use the manpages to better
understand and use their tools.
Which the will also tell you that --keyserver is deprecated (even though it
still should work as intended for your use case). dirmanager these days is
responsible for managing key/certificate dependencies.

Good luck,

-H

Re: blacklist mei_me?

On Tue, 2022-11-15 at 12:27 +, Tixy wrote:
> On Tue, 2022-11-15 at 11:10 +0100, hw wrote:
> > Hi,
> > 
> > this module causes delays when booting and I'm finding this in dmesg:
> > 
> > 
> > [   14.889003] mei_me :00:16.0: hw_reset failed ret = -62
> > [   20.009003] mei_me :00:16.0: hw_reset failed ret = -62
> > [   25.129003] mei_me :00:16.0: hw_reset failed ret = -62
> > [   25.129315] mei_me :00:16.0: reset: reached maximal consecutive
> > resets:
> > disabling the device
> > [   25.129797] mei_me :00:16.0: reset failed ret = -19
> > [   25.130086] mei_me :00:16.0: link layer initialization failed.
> > [   25.130431] mei_me :00:16.0: init hw failure.
> > [   25.130745] mei_me :00:16.0: initialization failed.
> > 
> > 
> > Should I just blacklist it or is that a bad idea?  Apparently whatever it is
> > for
> > gets disabled anyway and it doesn't seem to be a disadvantage other than
> > causing
> > delays.
> > 
> 
> If you use Google to search for mei_me you'll lots o similar reports
> going back a decade, e.g. https://bbs.archlinux.org/viewtopic.php?id=168403
> 
> These seem to suggest blacklisting the module or disabling Management
> Engine Interface in the BIOS.
> 

Thanks.  Of course I did search and it was unclear if I should just disable the
module, so I thought I'd better ask.

Re: Explaining snapshots (for backup)

2022-11-15 Thread Joe

On Tue, 15 Nov 2022 09:27:05 -0500
rhkra...@gmail.com wrote:

> I'm not really clear on the concept of a snapshot (for backup) --
> I've done a little googling but haven't found an explanation that
> "satisfies" me.
> 
> In this email I want to hyptothesize on what a snapshot might be in
> the hope that others can correct / amplify it when I go wrong.
> 
> Starting from a beginning, I suppose I could copy the entire contents
> of whatever I wanted to make a snapshot of (by any of a variety of
> tools -- dd, cp, ...) and call that a snapshot, although the more
> common name for it would be a "full backup".
> 
> Later, I could copy any files (as files) that have changed since the
> date I made the full backup and call that a snapshot.  (I might use
> find to identify the files that have changed, and then any of a
> variety of tools to actually copy them somewhere (and call that a
> shapshot).)
> 
> I suppose it wouild be possible to do something like this at a block
> level, that is copying only blocks of a file which have changed.
> (Not sure which commands might help me do that, but I don't think I'd
> really be interested in doing that.)
> 
> I also hear (i.e., read) statements from which I infer that some
> snapshots included only the metadata of the files (or blocks???), but
> I'm not sure of the value of either of those to me -- how can you
> reconstruct a possibly missing file (or block) from the metadata? 
> 
> Thanks!
> 

LVM can be used to make a snapshot, which can then be copied to make a
consistent backup. Here's one tutorial, there are others:

https://devconnected.com/lvm-snapshots-backup-and-restore-on-linux/

It's obviously easier if you already use LVM for your filesystems. You
need unallocated space, preferably as large as the entity you are
copying, though on a quiet system you can get away with less. If you
run out of space during the snapshot, it is worthless, and you need to
start again. You can create an LVM volume on an external drive.

Here are a couple of explanations of LVM snaphots, which is somewhat
similar to how the Shadow Copy function of Windows works:

https://www.thomas-krenn.com/en/wiki/LVM_Snapshots_Information

https://documentation.suse.com/sles/12-SP4/html/SLES-all/cha-lvm-snapshots.html

-- 
Joe

Re: Explaining snapshots (for backup)

2022-11-15 Thread rhkramer

Intentionally top-posting;  Thanks to all who replied, I think I have a pretty 
good understanding and I think the biggest thing I was missing was how a file 
could be reconstructed using only the metadata, but I now see the explanation 
that filesystems that can do snapshots are COW and now things make sense.

Thanks again to all who replied!

On Tuesday, November 15, 2022 10:36:59 AM Thomas Schmitt wrote:
> Nitpicking mode on.

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma included at no 
charge.)  If you change topics, change the Subject: line. 

Writing is often meant for others to read and understand (legal agreements 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace and minimal use of (obscure?) jargon, abbreviations, 
acronyms, and references.

If someone else has already responded to a question, decide whether any 
response you add will be helpful or not ...

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: Explaining snapshots (for backup)

2022-11-15 Thread Thomas Schmitt

Hi,

rhkra...@gmail.com wrote:
> In this email I want to hyptothesize on what a snapshot might be in the hope
> that others can correct / amplify it when I go wrong.

Nitpicking mode on.

> I suppose I could copy the entire contents of
> whatever I wanted to make a snapshot of (by any of a variety of tools -- dd,
> cp, ...) and call that a snapshot,

This lacks the single-point-in-time aspect of a snapshot.

The copy process will last some time in which changes may occur which will
only partly be backuped, because some parts of the change did not yet
exist, when their affected files were backuped.
A filesystem snapshot should reduce the risk for such inconsistencies by
freezing the filesystem in a state with no pending write operations.
(There still remains the risk that the filesystem gets frozen while e.g.
a large file is being written by multiple write operations. The snapshot
will then show the file as incomplete, as if you tried to read it too early.)

The freezing of the overall filesystem will normally not last long, because
a common aspect of most snapshot concepts is copy-on-write. I.e. the data
blocks get marked read-only. When a write operation is desired, then the
affected old block loses its active job to a copy which is created in
a previously unused block. The write operation then happens on the new
block, while the old block remains valid only in the snapshot.

> I also hear (i.e., read) statements from which I infer that some snapshots
> included only the metadata of the files (or blocks???), but I'm not sure of 
> the
> value of either of those to me -- how can you reconstruct a possibly missing
> file (or block) from the metadata?

I think these statements refer to the copy-on-write concept:
Mark as read-only now, copy later.
For such a mark, you need some a kind of block management system, which of
course needs to maintain data about the data blocks, i.e. metadata.

pa...@quillandmouse.com wrote:
> Assuming a snapshot is taken so that you can recover a filesystem to a
> previous state (or the current state). Is that correct?

Not necessarily. In backup scenarios, which involve real copying, the
snapshot shall reduce the risk for consistency mishaps.

> Let's assume, as the OP says, you do an original full backup. A
> snapshot ought to record either the contents of all the files which
> have changed, or record the delta of each file which has changed.

No. That's "incremental" or "differential" backup.
  https://en.wikipedia.org/wiki/Incremental_backup
  https://en.wikipedia.org/wiki/Differential_backup

Snapshots can be used to emulate such backups. (I'd frown on a backup
concept, though, which does not store copies at some other storage medium.)

Have a nice day :)

Thomas

Missing libs???

2022-11-15 Thread Hans

Dear list,

an installer for an external apps is telling me of missing extensions. These 
are "glx_sgix_fbconfig" and "glx_sgix_pbuffer".

As far as I could explore, these are NVidia related libs and belong to some 
packages named "glew".

As I am using an old NVidia card, which is running 340xx-legacy, I am not 
sure, if thius is an extension, the card and the driver is related to, or if 
this is an external lib, which can be installed manually. 

Does someone know more to these libs mentioned above?

I saw a these libs mentioned in the source package of debian called "glew", 
but I found no binary package called "glew", just "glew-utils" or "libglew".

Note, I am running debian/stable, so it might be available in testing or 
unstable - however packages.debian.org did not know any package called "glew" 
or "glx_sgix-*".

Thanks for any enlightening!

Best regards

Hans

Re: Intel X540-AT2 and Debian: intermittent connection

On Tue, 2022-11-15 at 12:38 +0100, hw wrote:
> On Mon, 2022-11-14 at 13:21 +0100, hw wrote:
> > On Mon, 2022-11-14 at 12:28 +0100, stefano gozzi wrote:
> > > Please loot at this:
> > > https://www.linuxquestions.org/questions/linux-networking-3/intel-x540-t2-network-card-installed-but-only-at-100mbit-cant-change-or-improve-4175686736/
> > > 
> > > It seems that you need a 8x pcie slot to work fine
> > 
> > Thanks, the card is in an 8x slot and has been working fine with Fedora.  I
> > didn't change anything but using Debian instead of Fedora.
> 
> Ok I pulled the server from the rack and put another fan to blow directly on
> the
> card in case it might overheat.
> 
> And I have to correct myself.  The card is in an 8x slot and according to the
> manual of the mainboard it's supposed to be 8x and not 4x.  I pulled it and
> put
> it back in.
> 
> However, lspci says "LnkSta: Speed 5GT/s (ok), Width x4 (downgraded)".
> 
> Usually cards in PCI slots with 4 instead of 8 lanes still work fine, and the
> card did work in that slot with Fedora.
> 
> I found that I had to unplug the network cable and to plug it back in before I
> could send/receive pings.  I already tried a different network cable and it
> didn't make a difference.
> 
> I suspect that Debian might be doing something differently or not doing that
> Fedora does which causes the intermittent connections.
> 
> Any ideas?  Backups over an 1GB link are excruciatingly slow ...
> 

Update: I booted a Fedora live system and the connection is also intermittent. 
So it's not a Debian issue.  It's still an issue, though ...

Re: Explaining snapshots (for backup)

2022-11-15 Thread paulf

On Tue, 15 Nov 2022 09:40:11 -0500
Dan Ritter  wrote:

> rhkra...@gmail.com wrote: 
> > I'm not really clear on the concept of a snapshot (for backup) --
> > I've done a little googling but haven't found an explanation that
> > "satisfies" me.
> > 
> > Starting from a beginning, I suppose I could copy the entire
> > contents of whatever I wanted to make a snapshot of (by any of a
> > variety of tools -- dd, cp, ...) and call that a snapshot, although
> > the more common name for it would be a "full backup".
> 
> Let's look at the larger circumstances.
> 
> In ordinary usage, there are tens to thousands of processes
> runnning on your system. Some of them are emitting logs or
> writing files.
> 
> Taking a backup takes some time. During that time, some files
> get written, some get opened, and some are related to each other
> (by the processes) in ways which are inconsistent until all of
> them are written.
> 
> A snapshot differs from a backup in two important regards:
> 
> - first, it requires the filesystem to bring writes to a halt.
> There is now a consistent view.
> 
> - second, it doesn't actually copy things. It just records their
> state and, when done, allows future writes to continue -- writes
> which are not part of this snapshot.
> 
> As a result, you can take a snapshot and then:
> 
> - discard it (trivial)
> 
> - look through it and copy off any file or group of files, thus
> getting what they contained at the time of the snapshot, not the
> what they contain now (excellent for recovering from an
> accidental delete)
> 
> - copy all of it off elsewhere, producing a consistent full
> backup.
> 

Assuming a snapshot is taken so that you can recover a filesystem to a
previous state (or the current state). Is that correct?

I don't understand "recording the state" of files. To me, this means
the ownership, size, etc., not the contents. That doesn't seem valuable
for recovering the state of a system.

Let's assume, as the OP says, you do an original full backup. A
snapshot ought to record either the contents of all the files which
have changed, or record the delta of each file which has changed.
Thus, you'd be able to recover a filesystem to either some prior state
or its current state, using the snapshot.

Am I missing something?

Paul

-- 
Paul M. Foster
Personal Blog: http://noferblatz.com
Company Site: http://quillandmouse.com
Software Projects: https://gitlab.com/paulmfoster

Re: Explaining snapshots (for backup)

2022-11-15 Thread Dan Ritter

rhkra...@gmail.com wrote: 
> I'm not really clear on the concept of a snapshot (for backup) -- I've done a 
> little googling but haven't found an explanation that "satisfies" me.
> 
> Starting from a beginning, I suppose I could copy the entire contents of 
> whatever I wanted to make a snapshot of (by any of a variety of tools -- dd, 
> cp, ...) and call that a snapshot, although the more common name for it would 
> be a "full backup".

Let's look at the larger circumstances.

In ordinary usage, there are tens to thousands of processes
runnning on your system. Some of them are emitting logs or
writing files.

Taking a backup takes some time. During that time, some files
get written, some get opened, and some are related to each other
(by the processes) in ways which are inconsistent until all of
them are written.

A snapshot differs from a backup in two important regards:

- first, it requires the filesystem to bring writes to a halt.
There is now a consistent view.

- second, it doesn't actually copy things. It just records their
state and, when done, allows future writes to continue -- writes
which are not part of this snapshot.

As a result, you can take a snapshot and then:

- discard it (trivial)

- look through it and copy off any file or group of files, thus
getting what they contained at the time of the snapshot, not the
what they contain now (excellent for recovering from an
accidental delete)

- copy all of it off elsewhere, producing a consistent full
backup.

Does that help?

-dsr-

Re: Explaining snapshots (for backup)

Am 15.11.2022 um 15:27 schrieb rhkra...@gmail.com:
> I'm not really clear on the concept of a snapshot (for backup) -- I've done a 
> little googling but haven't found an explanation that "satisfies" me.

I am familiar with snapshots on zfs. There might be different meanings
in other contexts, idk ...

zfs is s COW filesystem, meaning "copy-on-write". Whenever you write to
an already existing block (piece of a file), a new block gets created
(copied and modified) and on closing the write (or on sync), the
(metadata-) pointer/directory entry changes to point to the new block.
This algorithm primarily implements transactions on the filesystem to
garantee, it has a consistent state at all times. but one side effect
is, that the old filesystem state still hangs around. And a snapshot
basically points to that outdated state of a filesystem and keeping a
shapshot means to prevent the reuse of those blocks until the snapshot
gets freed up again.

Does that help your understanding?

Re: how to add more ipv6 addresses to an interface that is being configured through dhcpv6

2022-11-15 Thread Curt

On 2022-11-15, mick.crane  wrote:
> On 2022-11-15 14:03, Curt wrote:
> I recommend a reboot at this point to remove the currently running
>>  network and to ensure that your network comes up properly.
>> 
>>  This is all it takes for a simple case.
>> 
>> Good luck.
>
> I used to look how long uptime was but now I reboot in case I broke 
> something that shows up on a reboot and it's still fresh in mind how it 
> might have broke.
>
> mick
>
>

You could record changes in a file (though I do wonder whether removing all
traces of the running network is so fastidious that it requires bringing
everything down and then up once again to be thorough).

Explaining snapshots (for backup)

2022-11-15 Thread rhkramer

I'm not really clear on the concept of a snapshot (for backup) -- I've done a 
little googling but haven't found an explanation that "satisfies" me.

In this email I want to hyptothesize on what a snapshot might be in the hope 
that others can correct / amplify it when I go wrong.

Starting from a beginning, I suppose I could copy the entire contents of 
whatever I wanted to make a snapshot of (by any of a variety of tools -- dd, 
cp, ...) and call that a snapshot, although the more common name for it would 
be a "full backup".

Later, I could copy any files (as files) that have changed since the date I 
made 
the full backup and call that a snapshot.  (I might use find to identify the 
files that have changed, and then any of a variety of tools to actually copy 
them somewhere (and call that a shapshot).)

I suppose it wouild be possible to do something like this at a block level, 
that is copying only blocks of a file which have changed.  (Not sure which 
commands might help me do that, but I don't think I'd really be interested in 
doing that.)

I also hear (i.e., read) statements from which I infer that some snapshots 
included only the metadata of the files (or blocks???), but I'm not sure of the 
value of either of those to me -- how can you reconstruct a possibly missing 
file (or block) from the metadata? 

Thanks!

-- 
rhk

If you reply: snip, snip, and snip again; leave attributions; avoid HTML; 
avoid top posting; and keep it "on list".  (Oxford comma included at no 
charge.)  If you change topics, change the Subject: line. 

Writing is often meant for others to read and understand (legal agreements 
excepted?) -- make it easier for your reader by various means, including 
liberal use of whitespace and minimal use of (obscure?) jargon, abbreviations, 
acronyms, and references.

If someone else has already responded to a question, decide whether any 
response you add will be helpful or not ...

A picture is worth a thousand words -- divide by 10 for each minute of video 
(or audio) or create a transcript and edit it to 10% of the original.

Re: how to add more ipv6 addresses to an interface that is being configured through dhcpv6

2022-11-15 Thread tomas

On Tue, Nov 15, 2022 at 02:21:01PM +, mick.crane wrote:
> On 2022-11-15 14:03, Curt wrote:
> I recommend a reboot at this point to remove the currently running
> >  network and to ensure that your network comes up properly.
> > 
> >  This is all it takes for a simple case.
> > 
> > Good luck.
> 
> I used to look how long uptime was but now I reboot in case I broke
> something that shows up on a reboot and it's still fresh in mind how it
> might have broke.

You put it more concisely than me :)

Cheers
-- 
t


signature.asc
Description: PGP signature

Rebooting [was: how to add more ipv6 addresses to an interface that is being configured through dhcpv6]

2022-11-15 Thread tomas

On Tue, Nov 15, 2022 at 02:03:19PM -, Curt wrote:

> [...] (whether this is a somehow invalidating reminder of
> Microsoft Windows is left as the traditional exercise):

I know that smugness. I'm old, after all :-)

That said, as age accrues, I've learnt an upside of rebooting after
sweeping config changes: you fail early and know you've rendered
your system unbootable at a point in time where you still remember
what you've done, and not half-a-year-later when the data centre
has a power failure at 3AM and you are finding it difficult to
remember your own name.

Cheers
-- 
t

signature.asc
Description: PGP signature

Re: how to add more ipv6 addresses to an interface that is being configured through dhcpv6

2022-11-15 Thread mick.crane


On 2022-11-15 14:03, Curt wrote:
I recommend a reboot at this point to remove the currently running

 network and to ensure that your network comes up properly.

 This is all it takes for a simple case.

Good luck.


I used to look how long uptime was but now I reboot in case I broke 
something that shows up on a reboot and it's still fresh in mind how it 
might have broke.


mick

Re: how to add more ipv6 addresses to an interface that is being configured through dhcpv6

2022-11-15 Thread Curt

On 2022-11-14, jeremy ardley  wrote:
>
> On 15/11/22 00:22, Curt wrote:
>> On 2022-11-14, jeremy ardley  wrote:
>>>
>>> Network Manager is terrible. Some of the instructions include you having
>>> to reboot your system to make chages take.
>> What "instructions" would those be, and of what provenance, that require a
>> system reboot rather than a restart of networking to make changes "take"
>> in Network Manager?
>>
> Just search for NetworkManager bug
> But for one example of many for rebooting, see 
> https://wiki.archlinux.org/title/NetworkManager
>

Except that, as DW pointed out, this doesn't appear to demonstrate
anything but your lack of attention to detail.

To belabor the point, the Debian wiki for systemd-networkd, the service
you recommend and use, (https://wiki.debian.org/SystemdNetworkd) *does*,
on the contrary, specifically recommend a reboot after setting up a
basic configuration (whether this is a somehow invalidating reminder of
Microsoft Windows is left as the traditional exercise):

 Setting up Systemd-Networkd
 basic configuration
 
 ...

 I recommend a reboot at this point to remove the currently running
 network and to ensure that your network comes up properly.

 This is all it takes for a simple case.

Good luck.

Re: blacklist mei_me?

2022-11-15 Thread Tixy

On Tue, 2022-11-15 at 11:10 +0100, hw wrote:
> Hi,
> 
> this module causes delays when booting and I'm finding this in dmesg:
> 
> 
> [   14.889003] mei_me :00:16.0: hw_reset failed ret = -62
> [   20.009003] mei_me :00:16.0: hw_reset failed ret = -62
> [   25.129003] mei_me :00:16.0: hw_reset failed ret = -62
> [   25.129315] mei_me :00:16.0: reset: reached maximal consecutive resets:
> disabling the device
> [   25.129797] mei_me :00:16.0: reset failed ret = -19
> [   25.130086] mei_me :00:16.0: link layer initialization failed.
> [   25.130431] mei_me :00:16.0: init hw failure.
> [   25.130745] mei_me :00:16.0: initialization failed.
> 
> 
> Should I just blacklist it or is that a bad idea?  Apparently whatever it is 
> for
> gets disabled anyway and it doesn't seem to be a disadvantage other than 
> causing
> delays.
> 

If you use Google to search for mei_me you'll lots o similar reports
going back a decade, e.g. https://bbs.archlinux.org/viewtopic.php?id=168403

These seem to suggest blacklisting the module or disabling Management
Engine Interface in the BIOS.

-- 
Tixy

Re: Intel X540-AT2 and Debian: intermittent connection

On Mon, 2022-11-14 at 13:21 +0100, hw wrote:
> On Mon, 2022-11-14 at 12:28 +0100, stefano gozzi wrote:
> > Please loot at this:
> > https://www.linuxquestions.org/questions/linux-networking-3/intel-x540-t2-network-card-installed-but-only-at-100mbit-cant-change-or-improve-4175686736/
> > 
> > It seems that you need a 8x pcie slot to work fine
> 
> Thanks, the card is in an 8x slot and has been working fine with Fedora.  I
> didn't change anything but using Debian instead of Fedora.

Ok I pulled the server from the rack and put another fan to blow directly on the
card in case it might overheat.

And I have to correct myself.  The card is in an 8x slot and according to the
manual of the mainboard it's supposed to be 8x and not 4x.  I pulled it and put
it back in.

However, lspci says "LnkSta: Speed 5GT/s (ok), Width x4 (downgraded)".

Usually cards in PCI slots with 4 instead of 8 lanes still work fine, and the
card did work in that slot with Fedora.

I found that I had to unplug the network cable and to plug it back in before I
could send/receive pings.  I already tried a different network cable and it
didn't make a difference.

I suspect that Debian might be doing something differently or not doing that
Fedora does which causes the intermittent connections.

Any ideas?  Backups over an 1GB link are excruciatingly slow ...

blacklist mei_me?



Hi,

this module causes delays when booting and I'm finding this in dmesg:


[   14.889003] mei_me :00:16.0: hw_reset failed ret = -62
[   20.009003] mei_me :00:16.0: hw_reset failed ret = -62
[   25.129003] mei_me :00:16.0: hw_reset failed ret = -62
[   25.129315] mei_me :00:16.0: reset: reached maximal consecutive resets:
disabling the device
[   25.129797] mei_me :00:16.0: reset failed ret = -19
[   25.130086] mei_me :00:16.0: link layer initialization failed.
[   25.130431] mei_me :00:16.0: init hw failure.
[   25.130745] mei_me :00:16.0: initialization failed.


Should I just blacklist it or is that a bad idea?  Apparently whatever it is for
gets disabled anyway and it doesn't seem to be a disadvantage other than causing
delays.

Re: RFC: What would be the "correct debian way" to clean up unwanted languages from an installation?